date:20160211

Re: [yocto] wic: Setting partition id value?

2016-02-11 Thread Ed Bartosh

On Wed, Feb 10, 2016 at 10:23:13PM +0500, Usman, Fahad wrote:
> Hi,
> Is there a way to create a partition with an arbitrary partition id,
> using wic tool. We want to create a disk image using wic for Altera
> Cyclone V. It require the partition id to be set to a particular hex
> value for the partition it reads the boot loader binary from. The
> partition id does get set automatically to the correct value
> depending on the value of fstype (eg. 0x83 for ext3 or 0x0c for
> fat32), but I couldn't find a way to set it to an arbitrary value.
>

This is not supported by wic, but shouldn't be hard to implement.
Please create an issue in bugzilla and assign to me if you want me to
do it.

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

[yocto] native tool is not installed before it is used

2016-02-11 Thread Sridhar Pitchai

Hi,I have a recipe, where It need protobuf-c-compiler (natvily) to auto 
generate files before it can be compiled. i have added protobuf-c-native in the 
DEPENDS list. but the compilation is failling at do_autogen, compiling the 
proto-c is not installed in staging_bindir_native.But if  bitbake 
protobuf-c-native manually and then bitbake the recipe it is working fine. 
how to enforce protobuf-c-native is installed in the this recipe ? 
SECTION = "SWOS"PRIORITY = "optional"LICENSE = "CLOSED"
PROVIDES = "swos-app"
PR = "r0"DEPENDS = " protobuf-c-native libev protobuf-c protobuf zeromq "
FILESEXTRAPATHS_prepend = "${THISDIR}:"SRC_URI = "file://${PV}/swos.tar.gz"
inherit cmake pkgconfigS = "${WORKDIR}/swos"
FILES_${PN} = "${libdir}/*.so"FILES_${PN} += "${bindir}/*"
do_autogen () {${STAGING_BINDIR_NATIVE}/protoc-c 
--proto_path=${S}/common/pbuf --c_out=${S}/common/pbuf/autogen-c 
${S}/common/pbuf/*.proto}
addtask do_autogen after do_configure before do_compile

thanks,Sridhar Pitchai-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Dropping Debian 7 as supported?

2016-02-11 Thread Burton, Ross

On 11 February 2016 at 14:21, Nick Leverton  wrote:

> Possibly a little early - Debian 7 will be going onto LTS security support
> for
> two years, starting some time this month.  Quoting from
> https://wiki.debian.org/LTS
>

Ah yes, I'd forgotten about the LTS project and was looking at the security
team.

This does make it less clear, but it's still an old release and we can't
support/test on everything.

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

Re: [yocto] Selecting a specific tuning in an application recipe?

2016-02-11 Thread Khem Raj


> On Feb 11, 2016, at 11:25 AM, Stroz, Glenn  wrote:
> 
> Hi,
> 
> We’re trying to build a 64 bit arm project. However, one of our applications 
> needs to be built in 32 bit mode as it isn’t supported in 64 bit yet. I’ve 
> looked around and it looks like I need to adjust the tuning to be for armv7 
> instead of the default. However, when I set DEFAULTTUNE in the application 
> recipe it does not compile the 32 bit cross compiler and bails out with a 
> dependency error. Is there a system in place where we can adjust the tuning 
> for a specific recipe?
> 
> Multilib doesn’t appear to be the solution since it’s tailored towards 
> libraries and not applications. Not sure if there’s anything else that would 
> work.

infact multilib is the solution, its not limited to libraries. If multilib 
worked for your arch you would

bitbake lib32-
and it will bring in all needed dependencies + compile your app in 32bit mode 
or whatever the multilib warrants.

Question however is if combination that you are expecting is supported or not.

> 
> Thanks,
> Glenn
> 
> --
> ___
> 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

[yocto] Selecting a specific tuning in an application recipe?

2016-02-11 Thread Stroz, Glenn

Hi,

We're trying to build a 64 bit arm project. However, one of our applications 
needs to be built in 32 bit mode as it isn't supported in 64 bit yet. I've 
looked around and it looks like I need to adjust the tuning to be for armv7 
instead of the default. However, when I set DEFAULTTUNE in the application 
recipe it does not compile the 32 bit cross compiler and bails out with a 
dependency error. Is there a system in place where we can adjust the tuning for 
a specific recipe?

Multilib doesn't appear to be the solution since it's tailored towards 
libraries and not applications. Not sure if there's anything else that would 
work.

Thanks,
Glenn

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

Re: [yocto] valgrind-native

2016-02-11 Thread Burton, Ross

Hi,

On 11 February 2016 at 10:44, Woronicz, Bartosz ( NSN - PL/Wroclaw) <
bartosz.woron...@nokia.com> wrote:

> Any ideas why I cannot build native valgrind ?
> http://pastebin.com/e2h6AWxN
> "Missing or unbuildable dependency chain was: ['valgrind-native',
> 'glibc-dbg-native']"
>
> Also tried bitbake glibc-dbg . nothing provides that, but it is required
> in recipe
>

The short answer is because valgrind doesn't have a native form yet.
Presumably you added BBCLASSEXTEND=native yourself, so you get to fix it. :)

valgrind RRECOMMENDS $(TCLIBC)-dbg as without debugging symbols it's fairly
useless, and TCLIBC is the variable for the libc being used (in your case,
glibc).  As a recommends, it will be built.

However, native recipes don't usually depend on the C library (base.bbclass
handles the addition of those core dependencies, and doesn't run on native
builds) so you've hit a new corner case.

The easy fix would be to remove the recommends in the native build case:

RRECOMMENDS_${PN}_class-native = ""

Surprisingly enough it then builds!

Also remember that we strip the native sysroot, so if you want a native
valgrind to be useful in any way you'll have to disable that too
(INHIBIT_SYSROOT_STRIP).

(it would probably be easier to use the host valgrind, to be honest)

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

[yocto] Adding SCM'ed files to image

2016-02-11 Thread Lars Larsen


Hello world

I've been struggling a bit, but I'm sure there must be a generic 
solution to my problem (as a bbclass perhaps ??)


I'm building a bootable  image (NOT a distribution) for our product.

But I need a simple recipe to copy some files
I have a bunch of files (scripts, configuration files etc)  these files 
are under git control, I want the directory  structure in the 
repository, populated on to the image


so in my git I have something that could look  like this
.
├── bin
├── etc
│   └── file_in-etc
└── usr

I want it overlayed on the target image,

It proved surprisingly difficult when the files are not a precanned part 
of the recipe (in a files directory). the recipe doesn't know the dirs & 
files in advance.
I managed to get the structure  checked out in WORKDIR/git but getting 
from  her to  the image still troubles me



I'm sure somebody else had the same issues, but I can t find an elegant 
solution


any pointers will be highly appreciated

BR
-Lars








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

Re: [yocto] wic: Setting partition id value?

2016-02-11 Thread Usman, Fahad


On 02/11/2016 11:36 AM, Ed Bartosh wrote:

This is not supported by wic, but shouldn't be hard to implement.
Please create an issue in bugzilla and assign to me if you want me to
do it.

Thanks Ed,
I have created this bug, 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=9096. Do let me know 
if you need any more information.


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

[yocto] valgrind-native

2016-02-11 Thread Woronicz, Bartosz ( NSN - PL/Wroclaw)


Any ideas why I cannot build native valgrind ? http://pastebin.com/e2h6AWxN
"Missing or unbuildable dependency chain was: ['valgrind-native', 
'glibc-dbg-native']"


Also tried bitbake glibc-dbg . nothing provides that, but it is required 
in recipe



--
Kind regards,
Bartosz Woronicz
Engineer, Software Configuration (SCM)
NSN - PL/Wroclaw

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

Re: [yocto] valgrind-native

2016-02-11 Thread Woronicz, Bartosz ( NSN - PL/Wroclaw)


Hi Ross,

many thanks for nice explanation. At my shallow research, I notice, that 
valgrind is somewhat special demanding packages with debugging symbols, 
sooo... I actually don't need all packages to be unstripped. Only those 
I am developing and testing. Therefore i might need create some class 
that will require debug symbols.

And, propalby I will also need glibc with DBG symbols... or not ?


"Presumably you added BBCLASSEXTEND=native yourself, so you get to fix 
it. :)"

Indeed, I did so ;-]

Kind regards,
Bartosz Woronicz
Engineer, Software Configuration (SCM)
NSN - PL/Wroclaw

On 11.02.2016 11:57, EXT Burton, Ross wrote:

Hi,

On 11 February 2016 at 10:44, Woronicz, Bartosz ( NSN - PL/Wroclaw) 
> wrote:


Any ideas why I cannot build native valgrind ?
http://pastebin.com/e2h6AWxN
"Missing or unbuildable dependency chain was: ['valgrind-native',
'glibc-dbg-native']"

Also tried bitbake glibc-dbg . nothing provides that, but it is
required in recipe


The short answer is because valgrind doesn't have a native form yet.  
Presumably you added BBCLASSEXTEND=native yourself, so you get to fix 
it. :)


valgrind RRECOMMENDS $(TCLIBC)-dbg as without debugging symbols it's 
fairly useless, and TCLIBC is the variable for the libc being used (in 
your case, glibc). As a recommends, it will be built.


However, native recipes don't usually depend on the C library 
(base.bbclass handles the addition of those core dependencies, and 
doesn't run on native builds) so you've hit a new corner case.


The easy fix would be to remove the recommends in the native build case:

RRECOMMENDS_${PN}_class-native = ""

Surprisingly enough it then builds!

Also remember that we strip the native sysroot, so if you want a 
native valgrind to be useful in any way you'll have to disable that 
too (INHIBIT_SYSROOT_STRIP).


(it would probably be easier to use the host valgrind, to be honest)

Ross


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

Re: [yocto] Eclipse IDE plugin failure

2016-02-11 Thread Teodor Madan

A patch has been proposed at 
https://lists.yoctoproject.org/pipermail/yocto/2016-January/027951.html
I just have verified the patch and it worked for me.

Teo


From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Marius
Sent: Wednesday, February 10, 2016 20:22
To: yocto@yoctoproject.org
Subject: [yocto] Eclipse IDE plugin failure

I installed the latest Eclipse (Mars) and attempted to install the plugin. The 
installation failed and the reported error was that it could not locate the TM 
Terminal version 3.xxx. The TM terminal is installed but it is version 4.00xxx

Should I rather install older versions of the software or is there a workaround 
for this problem? If so what is suggested to be good and working?


-
Regards / Groete

Marius D. Liebenberg
+27 82 698 3251
+27 12 743 6064

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

Re: [yocto] Eclipse IDE plugin failure

2016-02-11 Thread Marius

Ah thanks Teo. Do you know of an instruction somewhere to get the patch 
affected. I dont really know how to do that as I am installing directly 
from repositories on the net.

-- Original Message --
From: "Teodor Madan" 
To: "Marius" ; "yocto@yoctoproject.org" 

Sent: 2016-02-11 13:13:39
Subject: RE: [yocto] Eclipse IDE plugin failure

A patch has been proposed at 
https://lists.yoctoproject.org/pipermail/yocto/2016-January/027951.html

I just have verified the patch and it worked for me.

Teo

From:yocto-boun...@yoctoproject.org 
[mailto:yocto-boun...@yoctoproject.org] On Behalf Of Marius

Sent: Wednesday, February 10, 2016 20:22
To:yocto@yoctoproject.org
Subject: [yocto] Eclipse IDE plugin failure

I installed the latest Eclipse (Mars) and attempted to install the 
plugin. The installation failed and the reported error was that it 
could not locate the TM Terminal version 3.xxx. The TM terminal is 
installed but it is version 4.00xxx

Should I rather install older versions of the software or is there a 
workaround for this problem? If so what is suggested to be good and 
working?

-

Regards / Groete

Marius D. Liebenberg

+27 82 698 3251

+27 12 743 6064

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

[yocto] Dropping Debian 7 as supported?

2016-02-11 Thread Burton, Ross

Hi,

I'm proposing that we drop Debian 7 from the supported distributions list
in master, so that the 2.1 release supports Debian 8.  Debian 7 was
released in 2013, Debian 8 superceded it in April 2015 so will have been
out for a year when 2.1 is released, which also means that is when Debian 7
stops receiving security fixes. Nobody should be running Debian 7 after
April 2016!

Any objections?

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

Re: [yocto] valgrind-native

2016-02-11 Thread Burton, Ross

On 11 February 2016 at 12:38, Woronicz, Bartosz ( NSN - PL/Wroclaw) <
bartosz.woron...@nokia.com> wrote:

> many thanks for nice explanation. At my shallow research, I notice, that
> valgrind is somewhat special demanding packages with debugging symbols,
> sooo... I actually don't need all packages to be unstripped. Only those I
> am developing and testing. Therefore i might need create some class that
> will require debug symbols.
> And, propalby I will also need glibc with DBG symbols... or not ?
>

Yes, if you set INHIBIT_SYSROOT_STRIP then all of the sysroots will be
unstripped, but you'll want all the debug symbols for the libraries that
are used from the host (such as glibc).

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

Re: [yocto] Dropping Debian 7 as supported?

2016-02-11 Thread Nick Leverton

On Thursday 11 Feb 2016 14:11:36 Burton, Ross wrote:
> Hi,
> 
> I'm proposing that we drop Debian 7 from the supported distributions list
> in master, so that the 2.1 release supports Debian 8.  Debian 7 was
> released in 2013, Debian 8 superceded it in April 2015 so will have been
> out for a year when 2.1 is released, which also means that is when Debian 7
> stops receiving security fixes. Nobody should be running Debian 7 after
> April 2016!
> 
> Any objections?

Possibly a little early - Debian 7 will be going onto LTS security support for 
two years, starting some time this month.  Quoting from 
https://wiki.debian.org/LTS

"Debian 6 “Squeeze” until February 2016
Debian 7 “Wheezy” from February 2016 to May 2018
Debian 8 “Jessie“ from May 2018 to April/May 2020"

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

[linux-yocto] [PATCH] selftests/capabilities: Add tests for capability evolution

2016-02-11 Thread Saul Wold

From: Andy Lutomirski 

commit 32ae976ed3b5ba39c9208ace41bcdf4157d21db3 upstream.

This test focuses on ambient capabilities.  It requires either root or
the ability to create user namespaces.  Some of the test cases will be
skipped for nonroot users.

Signed-off-by: Andy Lutomirski 
Acked-by: Kees Cook 
Cc: Christoph Lameter  # Original author
Cc: Serge E. Hallyn 
Cc: James Morris 
Cc: Shuah Khan 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 

diff --git a/tools/testing/selftests/capabilities/.gitignore 
b/tools/testing/selftests/capabilities/.gitignore
new file mode 100644
index 000..b732dd0
--- /dev/null
+++ b/tools/testing/selftests/capabilities/.gitignore
@@ -0,0 +1,2 @@
+test_execve
+validate_cap
diff --git a/tools/testing/selftests/capabilities/Makefile 
b/tools/testing/selftests/capabilities/Makefile
new file mode 100644
index 000..8c8f0c1
--- /dev/null
+++ b/tools/testing/selftests/capabilities/Makefile
@@ -0,0 +1,18 @@
+all:
+
+include ../lib.mk
+
+.PHONY: all clean
+
+TARGETS := validate_cap test_execve
+TEST_PROGS := test_execve
+
+CFLAGS := -O2 -g -std=gnu99 -Wall -lcap-ng
+
+all: $(TARGETS)
+
+clean:
+   $(RM) $(TARGETS)
+
+$(TARGETS): %: %.c
+   $(CC) -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $^ -lrt -ldl
diff --git a/tools/testing/selftests/capabilities/test_execve.c 
b/tools/testing/selftests/capabilities/test_execve.c
new file mode 100644
index 000..10a21a9
--- /dev/null
+++ b/tools/testing/selftests/capabilities/test_execve.c
@@ -0,0 +1,427 @@
+#define _GNU_SOURCE
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifndef PR_CAP_AMBIENT
+#define PR_CAP_AMBIENT 47
+# define PR_CAP_AMBIENT_IS_SET 1
+# define PR_CAP_AMBIENT_RAISE  2
+# define PR_CAP_AMBIENT_LOWER  3
+# define PR_CAP_AMBIENT_CLEAR_ALL  4
+#endif
+
+static int nerrs;
+
+static void vmaybe_write_file(bool enoent_ok, char *filename, char *fmt, 
va_list ap)
+{
+   char buf[4096];
+   int fd;
+   ssize_t written;
+   int buf_len;
+
+   buf_len = vsnprintf(buf, sizeof(buf), fmt, ap);
+   if (buf_len < 0) {
+   err(1, "vsnprintf failed");
+   }
+   if (buf_len >= sizeof(buf)) {
+   errx(1, "vsnprintf output truncated");
+   }
+
+   fd = open(filename, O_WRONLY);
+   if (fd < 0) {
+   if ((errno == ENOENT) && enoent_ok)
+   return;
+   err(1, "open of %s failed", filename);
+   }
+   written = write(fd, buf, buf_len);
+   if (written != buf_len) {
+   if (written >= 0) {
+   errx(1, "short write to %s", filename);
+   } else {
+   err(1, "write to %s failed", filename);
+   }
+   }
+   if (close(fd) != 0) {
+   err(1, "close of %s failed", filename);
+   }
+}
+
+static void maybe_write_file(char *filename, char *fmt, ...)
+{
+   va_list ap;
+
+   va_start(ap, fmt);
+   vmaybe_write_file(true, filename, fmt, ap);
+   va_end(ap);
+}
+
+static void write_file(char *filename, char *fmt, ...)
+{
+   va_list ap;
+
+   va_start(ap, fmt);
+   vmaybe_write_file(false, filename, fmt, ap);
+   va_end(ap);
+}
+
+static bool create_and_enter_ns(uid_t inner_uid)
+{
+   uid_t outer_uid;
+   gid_t outer_gid;
+   int i;
+   bool have_outer_privilege;
+
+   outer_uid = getuid();
+   outer_gid = getgid();
+
+   /*
+* TODO: If we're already root, we could skip creating the userns.
+*/
+
+   if (unshare(CLONE_NEWNS) == 0) {
+   printf("[NOTE]\tUsing global UIDs for tests\n");
+   if (prctl(PR_SET_KEEPCAPS, 1, 0, 0, 0) != 0)
+   err(1, "PR_SET_KEEPCAPS");
+   if (setresuid(inner_uid, inner_uid, -1) != 0)
+   err(1, "setresuid");
+
+   // Re-enable effective caps
+   capng_get_caps_process();
+   for (i = 0; i < CAP_LAST_CAP; i++)
+   if (capng_have_capability(CAPNG_PERMITTED, i))
+   capng_update(CAPNG_ADD, CAPNG_EFFECTIVE, i);
+   if (capng_apply(CAPNG_SELECT_CAPS) != 0)
+   err(1, "capng_apply");
+
+   have_outer_privilege = true;
+   } else if (unshare(CLONE_NEWUSER | CLONE_NEWNS) == 0) {
+   printf("[NOTE]\tUsing a user namespace for tests\n");
+   maybe_write_file("/proc/self/setgroups", "deny");
+   write_file("/proc/self/uid_map", "%d %d 1", inner_uid, 
outer_uid);
+

[yocto] How to create do_populate_sysroot_append task

2016-02-11 Thread Vivek Per

Hi,
I want to add some additional kernel files to sysroot directory . I
want to extend do_populate_sysroot task , I want to copy few more files in
to sysroot after do_populate_sysroot and before do_package. I tried to
create do_populate_sysroot_append() in recipe  but it is getting parsing
error . how could i add file in sysroot after populate_sysroot and before
do_package.

Thanks in advance
   Vivek
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to build for various boards from one yocto installatio

2016-02-11 Thread Roman Shaposhnikov

Hi Mariues,

Yes, you can do this. At least you should create separate machine config.
For more details please check -
http://www.yoctoproject.org/docs/1.8/bsp-guide/bsp-guide.html (this will
provide you general process overview)

On Thu, Feb 2, 2016 at 3:20 AM, Marius  wrote:

> I have a custom board (similar to BBB) that has no HDMI and no network
> as well as a standard BBB. I want to build images for each from my yocto
> (poky-jethro) installation.
> Can it be done and if so how do I go about that?
>
> Regards
> Marius
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> 
>
>
-- 
Regards,

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

Re: [yocto] Debugging shared libraries

2016-02-11 Thread Mark Hatle

On 2/10/16 9:41 PM, Gary Thomas wrote:
> On 2016-02-10 21:08, Khem Raj wrote:
>>
>>> On Feb 10, 2016, at 8:35 AM, Mark Hatle  wrote:
>>>
>>> On 2/10/16 1:31 AM, Gary Thomas wrote:
 I'm trying to debug some code (mplayer) which uses some shared
 libraries from ffmpeg.  When I use GDB (via gdbserver), I don't
 get all the debug information I need - note that many of the shared
 libraries do not have any symbolic debugging info:
>>>
>>> Is your system using the the split debug binaries, and if so, do you have 
>>> them
>>> all installed on the system that GDB is running on?
>>>
>>> (When GDB starts, you should see it load the symbols, or error it can't 
>>> find them.)
>>>
>>> Assuming you DO have the symbol files available, and some things are lacking
>>> debuginfo, it's possible those recipes are not properly building with full
>>> symbols (they should be, the whole system should be.)
>>>
>>> Easiest way to check is do a readelf/objdump on the .debug version of the
>>> library and check that there are dwarf symbols present... if not, it's 
>>> probably
>>> a recipe error.
>>>
>>> --Mark
>>>
 (gdb) info sharedlibrary
  FromTo  Syms Read   Shared Object Library
 0xb6fcf800  0xb6feaf08  Yes /tmp/p0382.img/lib/ld-linux-armhf.so.3
 0xb6fa6fa8  0xb6fb2b40  Yes (*) /tmp/p0382.img/lib/libtinfo.so.5
 0xb6f6d210  0xb6f8c200  Yes /tmp/p0382.img/usr/lib/libpng16.so.16
 0xb6f488e8  0xb6f54a60  Yes /tmp/p0382.img/lib/libz.so.1
 0xb6f069f0  0xb6f34264  Yes /tmp/p0382.img/usr/lib/libjpeg.so.8
 0xb6edbaf0  0xb6eee29c  Yes /tmp/p0382.img/usr/lib/libdvdread.so.4
 0xb6eb6108  0xb6ec7ae8  Yes /tmp/p0382.img/usr/lib/libass.so.4
 0xb6e808b8  0xb6e95384  Yes /tmp/p0382.img/usr/lib/libvorbis.so.0
 0xb6e6b4b4  0xb6e6d7e4  Yes /tmp/p0382.img/usr/lib/libogg.so.0
 0xb6e48978  0xb6e55eb4  Yes /tmp/p0382.img/usr/lib/libspeex.so.1
 0xb6dfe818  0xb6e1b8b4  Yes (*) /tmp/p0382.img/usr/lib/libfaad.so.2
 0xb6d92df0  0xb6dd4e78  Yes (*) /tmp/p0382.img/usr/lib/libavutil.so.54
 0xb5de0640  0xb64a2e18  Yes (*) /tmp/p0382.img/usr/lib/libavcodec.so.56
 0xb5c17528  0xb5d65840  Yes (*) 
 /tmp/p0382.img/usr/lib/libavformat.so.56
 0xb5b81688  0xb5be8db8  Yes (*) /tmp/p0382.img/usr/lib/libswscale.so.3
 0xb5b5f578  0xb5b6c718  Yes (*) 
 /tmp/p0382.img/usr/lib/libswresample.so.1
 0xb5b44998  0xb5b4b490  Yes (*) 
 /tmp/p0382.img/usr/lib/libpostproc.so.53
 0xb5b1f0e0  0xb5b2e194  Yes /tmp/p0382.img/lib/libpthread.so.0
 0xb5aa4c00  0xb5ad46d0  Yes /tmp/p0382.img/lib/libm.so.6
 0xb5a859ec  0xb5a8fc34  Yes /tmp/p0382.img/usr/lib/libXext.so.6
 0xb597b728  0xb59f92bc  Yes /tmp/p0382.img/usr/lib/libX11.so.6
 0xb5946fc8  0xb59573d0  Yes 
 /tmp/p0382.img/usr/lib/libtheoradec.so.1
 0xb5887910  0xb591bbb8  Yes (*) /tmp/p0382.img/usr/lib/libasound.so.2
 0xb58579f8  0xb58586ac  Yes /tmp/p0382.img/usr/lib/libXss.so.1
 0xb5844ca0  0xb5846bac  Yes /tmp/p0382.img/usr/lib/libXv.so.1
 0xb57e7700  0xb58265e0  Yes /tmp/p0382.img/usr/lib/libSDL-1.2.so.0
 0xb56bae00  0xb57abb28  Yes /tmp/p0382.img/lib/libc.so.6
 0xb569292c  0xb5693724  Yes /tmp/p0382.img/lib/libdl.so.2
 0xb5650a70  0xb566e6a4  Yes 
 /tmp/p0382.img/usr/lib/libfontconfig.so.1
 0xb561e324  0xb563951c  Yes /tmp/p0382.img/usr/lib/libexpat.so.1
 0xb559d36c  0xb55f5cb4  Yes /tmp/p0382.img/usr/lib/libfreetype.so.6
 0xb55622b0  0xb5567e84  Yes /tmp/p0382.img/usr/lib/libenca.so.0
 0xb541fbc0  0xb54b5a08  Yes (*) /tmp/p0382.img/usr/lib/libx264.so.144
 0xb53d4df0  0xb53fa0b0  Yes 
 /tmp/p0382.img/usr/lib/libtheoraenc.so.1
 0xb53a72b0  0xb53bd258  Yes (*) /tmp/p0382.img/usr/lib/liblzma.so.5
 0xb5386050  0xb5392cc0  Yes (*) /tmp/p0382.img/usr/lib/libbz2.so.0
 0xb5367810  0xb5373b30  Yes /tmp/p0382.img/usr/lib/libxcb.so.1
 0xb534da00  0xb534e5a8  Yes /tmp/p0382.img/usr/lib/libXau.so.6
 0xb5339f80  0xb533b69c  Yes /tmp/p0382.img/usr/lib/libXdmcp.so.6
 0xb5323720  0xb5326ea0  Yes /tmp/p0382.img/lib/librt.so.1
 0xb530b6e0  0xb5311234  Yes /tmp/p0382.img/usr/lib/libXrandr.so.2
 0xb52f3530  0xb52f9060  Yes /tmp/p0382.img/usr/lib/libXrender.so.1
 0xb52d3160  0xb52e18a4  Yes /tmp/p0382.img/lib/libgcc_s.so.1
 (*): Shared library is missing debugging information.

 Is this a function of how those libraries were built (by the recipe)
 or something else?  How can I get the symbolic debugging info enabled?

 Thanks for any pointers
>>
>>
>> Usually it works well if you add
>>
>> EXTRA_IMAGE_FEATURES_append = “ dbg-pkgs”
>>
>> image size grows but you get good debug

Re: [yocto] ERROR: busybox-udhcpd not found in the base feeds

2016-02-11 Thread Martin Townsend

Hi,

I think I understand what has happened.
It's just occured to me that the udhcpd code is probably part of busybox by
default and is in the busybox package, so I checked the defconfig and
CONFIG_UDHCPD is set to y.   I'm assuming that the busybox-udhcpd package
contains just the init script which of course doesn't get installed as
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit" has been set which means I
have an empty package which then results in the not found in base feeds
error.
Does this sound right??

I can remove busybox-udhcpd from the image but it does seem wrong to remove
this from the image when in fact all I'm removing is in the initscript.

Maybe something like
IMAGE_REMOVE += "
${@bb.utils.contains('DISTRO_FEATURES','systemd','busybox-udhcpd','',d)}"
in busybox recipe, if there is such a thing to stop people like me hitting
this problem again

One question that springs to mind is that if udhcpd is part of busybox by
default how do you override this with another DHCP server? Which is
something I may have to look into.

Many Thanks,
Martin.

On Thu, Feb 11, 2016 at 5:57 PM, Martin Townsend 
wrote:

> Hi,
>
> I've just moved over to using systemd on a project but am seeing the error
> listed in the subject.
> I added the following to local.conf as there is no distribution config
> file.
>
> VIRTUAL-RUNTIME_init_manager = "systemd"
> DISTRO_FEATURES_append = " systemd"
> # Prevent the SysVinit distribution feature from being automatically
> enabled
> # Breaks busybox-udhcpd for some reason.
> DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
>
> My understanding is that the last line will stop init scripts being
> installed if the recipe has systemd support.  Adding
> VIRTUAL-RUNTIME_initscripts = "" would completely disable init scripts I
> think so I didn't put this in.  So the above should use systemd where
> appropriate otherwise use sysV init scripts.
>
> I then blew away all sstate, cache and tmp directories and rebuilt and get
> the error.  If I comment out the last line the error goes away but I get
> all the sys V init scripts.  I checked the recipe and it inherits systemd
> and update-rc.d and I think the problem may be that busybox builds syslog
> with a systemd service but all the remaining components use init scripts as
> far as I can see, including udhcpd.  I looked in packages-split and
> busybox-udhcpd is empty.
>
> Any help appreciated,
> Martin.
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Debugging shared libraries

2016-02-11 Thread Gary Thomas


On 2016-02-11 22:48, Mark Hatle wrote:

On 2/10/16 9:41 PM, Gary Thomas wrote:

On 2016-02-10 21:08, Khem Raj wrote:



On Feb 10, 2016, at 8:35 AM, Mark Hatle  wrote:

On 2/10/16 1:31 AM, Gary Thomas wrote:

I'm trying to debug some code (mplayer) which uses some shared
libraries from ffmpeg.  When I use GDB (via gdbserver), I don't
get all the debug information I need - note that many of the shared
libraries do not have any symbolic debugging info:


Is your system using the the split debug binaries, and if so, do you have them
all installed on the system that GDB is running on?

(When GDB starts, you should see it load the symbols, or error it can't find 
them.)

Assuming you DO have the symbol files available, and some things are lacking
debuginfo, it's possible those recipes are not properly building with full
symbols (they should be, the whole system should be.)

Easiest way to check is do a readelf/objdump on the .debug version of the
library and check that there are dwarf symbols present... if not, it's probably
a recipe error.

--Mark


(gdb) info sharedlibrary
  FromTo  Syms Read   Shared Object Library
0xb6fcf800  0xb6feaf08  Yes /tmp/p0382.img/lib/ld-linux-armhf.so.3
0xb6fa6fa8  0xb6fb2b40  Yes (*) /tmp/p0382.img/lib/libtinfo.so.5
0xb6f6d210  0xb6f8c200  Yes /tmp/p0382.img/usr/lib/libpng16.so.16
0xb6f488e8  0xb6f54a60  Yes /tmp/p0382.img/lib/libz.so.1
0xb6f069f0  0xb6f34264  Yes /tmp/p0382.img/usr/lib/libjpeg.so.8
0xb6edbaf0  0xb6eee29c  Yes /tmp/p0382.img/usr/lib/libdvdread.so.4
0xb6eb6108  0xb6ec7ae8  Yes /tmp/p0382.img/usr/lib/libass.so.4
0xb6e808b8  0xb6e95384  Yes /tmp/p0382.img/usr/lib/libvorbis.so.0
0xb6e6b4b4  0xb6e6d7e4  Yes /tmp/p0382.img/usr/lib/libogg.so.0
0xb6e48978  0xb6e55eb4  Yes /tmp/p0382.img/usr/lib/libspeex.so.1
0xb6dfe818  0xb6e1b8b4  Yes (*) /tmp/p0382.img/usr/lib/libfaad.so.2
0xb6d92df0  0xb6dd4e78  Yes (*) /tmp/p0382.img/usr/lib/libavutil.so.54
0xb5de0640  0xb64a2e18  Yes (*) /tmp/p0382.img/usr/lib/libavcodec.so.56
0xb5c17528  0xb5d65840  Yes (*) /tmp/p0382.img/usr/lib/libavformat.so.56
0xb5b81688  0xb5be8db8  Yes (*) /tmp/p0382.img/usr/lib/libswscale.so.3
0xb5b5f578  0xb5b6c718  Yes (*) /tmp/p0382.img/usr/lib/libswresample.so.1
0xb5b44998  0xb5b4b490  Yes (*) /tmp/p0382.img/usr/lib/libpostproc.so.53
0xb5b1f0e0  0xb5b2e194  Yes /tmp/p0382.img/lib/libpthread.so.0
0xb5aa4c00  0xb5ad46d0  Yes /tmp/p0382.img/lib/libm.so.6
0xb5a859ec  0xb5a8fc34  Yes /tmp/p0382.img/usr/lib/libXext.so.6
0xb597b728  0xb59f92bc  Yes /tmp/p0382.img/usr/lib/libX11.so.6
0xb5946fc8  0xb59573d0  Yes /tmp/p0382.img/usr/lib/libtheoradec.so.1
0xb5887910  0xb591bbb8  Yes (*) /tmp/p0382.img/usr/lib/libasound.so.2
0xb58579f8  0xb58586ac  Yes /tmp/p0382.img/usr/lib/libXss.so.1
0xb5844ca0  0xb5846bac  Yes /tmp/p0382.img/usr/lib/libXv.so.1
0xb57e7700  0xb58265e0  Yes /tmp/p0382.img/usr/lib/libSDL-1.2.so.0
0xb56bae00  0xb57abb28  Yes /tmp/p0382.img/lib/libc.so.6
0xb569292c  0xb5693724  Yes /tmp/p0382.img/lib/libdl.so.2
0xb5650a70  0xb566e6a4  Yes /tmp/p0382.img/usr/lib/libfontconfig.so.1
0xb561e324  0xb563951c  Yes /tmp/p0382.img/usr/lib/libexpat.so.1
0xb559d36c  0xb55f5cb4  Yes /tmp/p0382.img/usr/lib/libfreetype.so.6
0xb55622b0  0xb5567e84  Yes /tmp/p0382.img/usr/lib/libenca.so.0
0xb541fbc0  0xb54b5a08  Yes (*) /tmp/p0382.img/usr/lib/libx264.so.144
0xb53d4df0  0xb53fa0b0  Yes /tmp/p0382.img/usr/lib/libtheoraenc.so.1
0xb53a72b0  0xb53bd258  Yes (*) /tmp/p0382.img/usr/lib/liblzma.so.5
0xb5386050  0xb5392cc0  Yes (*) /tmp/p0382.img/usr/lib/libbz2.so.0
0xb5367810  0xb5373b30  Yes /tmp/p0382.img/usr/lib/libxcb.so.1
0xb534da00  0xb534e5a8  Yes /tmp/p0382.img/usr/lib/libXau.so.6
0xb5339f80  0xb533b69c  Yes /tmp/p0382.img/usr/lib/libXdmcp.so.6
0xb5323720  0xb5326ea0  Yes /tmp/p0382.img/lib/librt.so.1
0xb530b6e0  0xb5311234  Yes /tmp/p0382.img/usr/lib/libXrandr.so.2
0xb52f3530  0xb52f9060  Yes /tmp/p0382.img/usr/lib/libXrender.so.1
0xb52d3160  0xb52e18a4  Yes /tmp/p0382.img/lib/libgcc_s.so.1
(*): Shared library is missing debugging information.

Is this a function of how those libraries were built (by the recipe)
or something else?  How can I get the symbolic debugging info enabled?

Thanks for any pointers



Usually it works well if you add

EXTRA_IMAGE_FEATURES_append = “ dbg-pkgs”

image size grows but you get good debug view on target.

another option, I usually use is setup feeds
and then

opkg install -dbg

which pulls in a section of debug info needed to debug a given package.



I've done all this already.  The problem is that for the libraries which
have no symbols there are no corresponding -dbg packages :-(  I looked
at the ffmpeg recipe (where the libswresample library

Re: [yocto] Debugging shared libraries

2016-02-11 Thread Khem Raj


> On Feb 11, 2016, at 7:11 PM, Gary Thomas  wrote:
> 
> On 2016-02-11 22:48, Mark Hatle wrote:
>> On 2/10/16 9:41 PM, Gary Thomas wrote:
>>> On 2016-02-10 21:08, Khem Raj wrote:
 
> On Feb 10, 2016, at 8:35 AM, Mark Hatle  wrote:
> 
> On 2/10/16 1:31 AM, Gary Thomas wrote:
>> I'm trying to debug some code (mplayer) which uses some shared
>> libraries from ffmpeg.  When I use GDB (via gdbserver), I don't
>> get all the debug information I need - note that many of the shared
>> libraries do not have any symbolic debugging info:
> 
> Is your system using the the split debug binaries, and if so, do you have 
> them
> all installed on the system that GDB is running on?
> 
> (When GDB starts, you should see it load the symbols, or error it can't 
> find them.)
> 
> Assuming you DO have the symbol files available, and some things are 
> lacking
> debuginfo, it's possible those recipes are not properly building with full
> symbols (they should be, the whole system should be.)
> 
> Easiest way to check is do a readelf/objdump on the .debug version of the
> library and check that there are dwarf symbols present... if not, it's 
> probably
> a recipe error.
> 
> --Mark
> 
>> (gdb) info sharedlibrary
>>  FromTo  Syms Read   Shared Object Library
>> 0xb6fcf800  0xb6feaf08  Yes 
>> /tmp/p0382.img/lib/ld-linux-armhf.so.3
>> 0xb6fa6fa8  0xb6fb2b40  Yes (*) /tmp/p0382.img/lib/libtinfo.so.5
>> 0xb6f6d210  0xb6f8c200  Yes /tmp/p0382.img/usr/lib/libpng16.so.16
>> 0xb6f488e8  0xb6f54a60  Yes /tmp/p0382.img/lib/libz.so.1
>> 0xb6f069f0  0xb6f34264  Yes /tmp/p0382.img/usr/lib/libjpeg.so.8
>> 0xb6edbaf0  0xb6eee29c  Yes 
>> /tmp/p0382.img/usr/lib/libdvdread.so.4
>> 0xb6eb6108  0xb6ec7ae8  Yes /tmp/p0382.img/usr/lib/libass.so.4
>> 0xb6e808b8  0xb6e95384  Yes /tmp/p0382.img/usr/lib/libvorbis.so.0
>> 0xb6e6b4b4  0xb6e6d7e4  Yes /tmp/p0382.img/usr/lib/libogg.so.0
>> 0xb6e48978  0xb6e55eb4  Yes /tmp/p0382.img/usr/lib/libspeex.so.1
>> 0xb6dfe818  0xb6e1b8b4  Yes (*) /tmp/p0382.img/usr/lib/libfaad.so.2
>> 0xb6d92df0  0xb6dd4e78  Yes (*) 
>> /tmp/p0382.img/usr/lib/libavutil.so.54
>> 0xb5de0640  0xb64a2e18  Yes (*) 
>> /tmp/p0382.img/usr/lib/libavcodec.so.56
>> 0xb5c17528  0xb5d65840  Yes (*) 
>> /tmp/p0382.img/usr/lib/libavformat.so.56
>> 0xb5b81688  0xb5be8db8  Yes (*) 
>> /tmp/p0382.img/usr/lib/libswscale.so.3
>> 0xb5b5f578  0xb5b6c718  Yes (*) 
>> /tmp/p0382.img/usr/lib/libswresample.so.1
>> 0xb5b44998  0xb5b4b490  Yes (*) 
>> /tmp/p0382.img/usr/lib/libpostproc.so.53
>> 0xb5b1f0e0  0xb5b2e194  Yes /tmp/p0382.img/lib/libpthread.so.0
>> 0xb5aa4c00  0xb5ad46d0  Yes /tmp/p0382.img/lib/libm.so.6
>> 0xb5a859ec  0xb5a8fc34  Yes /tmp/p0382.img/usr/lib/libXext.so.6
>> 0xb597b728  0xb59f92bc  Yes /tmp/p0382.img/usr/lib/libX11.so.6
>> 0xb5946fc8  0xb59573d0  Yes 
>> /tmp/p0382.img/usr/lib/libtheoradec.so.1
>> 0xb5887910  0xb591bbb8  Yes (*) /tmp/p0382.img/usr/lib/libasound.so.2
>> 0xb58579f8  0xb58586ac  Yes /tmp/p0382.img/usr/lib/libXss.so.1
>> 0xb5844ca0  0xb5846bac  Yes /tmp/p0382.img/usr/lib/libXv.so.1
>> 0xb57e7700  0xb58265e0  Yes 
>> /tmp/p0382.img/usr/lib/libSDL-1.2.so.0
>> 0xb56bae00  0xb57abb28  Yes /tmp/p0382.img/lib/libc.so.6
>> 0xb569292c  0xb5693724  Yes /tmp/p0382.img/lib/libdl.so.2
>> 0xb5650a70  0xb566e6a4  Yes 
>> /tmp/p0382.img/usr/lib/libfontconfig.so.1
>> 0xb561e324  0xb563951c  Yes /tmp/p0382.img/usr/lib/libexpat.so.1
>> 0xb559d36c  0xb55f5cb4  Yes 
>> /tmp/p0382.img/usr/lib/libfreetype.so.6
>> 0xb55622b0  0xb5567e84  Yes /tmp/p0382.img/usr/lib/libenca.so.0
>> 0xb541fbc0  0xb54b5a08  Yes (*) /tmp/p0382.img/usr/lib/libx264.so.144
>> 0xb53d4df0  0xb53fa0b0  Yes 
>> /tmp/p0382.img/usr/lib/libtheoraenc.so.1
>> 0xb53a72b0  0xb53bd258  Yes (*) /tmp/p0382.img/usr/lib/liblzma.so.5
>> 0xb5386050  0xb5392cc0  Yes (*) /tmp/p0382.img/usr/lib/libbz2.so.0
>> 0xb5367810  0xb5373b30  Yes /tmp/p0382.img/usr/lib/libxcb.so.1
>> 0xb534da00  0xb534e5a8  Yes /tmp/p0382.img/usr/lib/libXau.so.6
>> 0xb5339f80  0xb533b69c  Yes /tmp/p0382.img/usr/lib/libXdmcp.so.6
>> 0xb5323720  0xb5326ea0  Yes /tmp/p0382.img/lib/librt.so.1
>> 0xb530b6e0  0xb5311234  Yes /tmp/p0382.img/usr/lib/libXrandr.so.2
>> 0xb52f3530  0xb52f9060  Yes 
>> /tmp/p0382.img/usr/lib/libXrender.so.1
>> 0xb52d3160  0xb52e18a4  Yes /tmp/p0382.img/lib/libgcc_s.so.1
>> (*): Shared library is

Re: [yocto] Debugging shared libraries

2016-02-11 Thread Gary Thomas


On 2016-02-12 04:18, Khem Raj wrote:



On Feb 11, 2016, at 7:11 PM, Gary Thomas  wrote:

On 2016-02-11 22:48, Mark Hatle wrote:

On 2/10/16 9:41 PM, Gary Thomas wrote:

On 2016-02-10 21:08, Khem Raj wrote:



On Feb 10, 2016, at 8:35 AM, Mark Hatle  wrote:

On 2/10/16 1:31 AM, Gary Thomas wrote:

I'm trying to debug some code (mplayer) which uses some shared
libraries from ffmpeg.  When I use GDB (via gdbserver), I don't
get all the debug information I need - note that many of the shared
libraries do not have any symbolic debugging info:


Is your system using the the split debug binaries, and if so, do you have them
all installed on the system that GDB is running on?

(When GDB starts, you should see it load the symbols, or error it can't find 
them.)

Assuming you DO have the symbol files available, and some things are lacking
debuginfo, it's possible those recipes are not properly building with full
symbols (they should be, the whole system should be.)

Easiest way to check is do a readelf/objdump on the .debug version of the
library and check that there are dwarf symbols present... if not, it's probably
a recipe error.

--Mark


(gdb) info sharedlibrary
  FromTo  Syms Read   Shared Object Library
0xb6fcf800  0xb6feaf08  Yes /tmp/p0382.img/lib/ld-linux-armhf.so.3
0xb6fa6fa8  0xb6fb2b40  Yes (*) /tmp/p0382.img/lib/libtinfo.so.5
0xb6f6d210  0xb6f8c200  Yes /tmp/p0382.img/usr/lib/libpng16.so.16
0xb6f488e8  0xb6f54a60  Yes /tmp/p0382.img/lib/libz.so.1
0xb6f069f0  0xb6f34264  Yes /tmp/p0382.img/usr/lib/libjpeg.so.8
0xb6edbaf0  0xb6eee29c  Yes /tmp/p0382.img/usr/lib/libdvdread.so.4
0xb6eb6108  0xb6ec7ae8  Yes /tmp/p0382.img/usr/lib/libass.so.4
0xb6e808b8  0xb6e95384  Yes /tmp/p0382.img/usr/lib/libvorbis.so.0
0xb6e6b4b4  0xb6e6d7e4  Yes /tmp/p0382.img/usr/lib/libogg.so.0
0xb6e48978  0xb6e55eb4  Yes /tmp/p0382.img/usr/lib/libspeex.so.1
0xb6dfe818  0xb6e1b8b4  Yes (*) /tmp/p0382.img/usr/lib/libfaad.so.2
0xb6d92df0  0xb6dd4e78  Yes (*) /tmp/p0382.img/usr/lib/libavutil.so.54
0xb5de0640  0xb64a2e18  Yes (*) /tmp/p0382.img/usr/lib/libavcodec.so.56
0xb5c17528  0xb5d65840  Yes (*) /tmp/p0382.img/usr/lib/libavformat.so.56
0xb5b81688  0xb5be8db8  Yes (*) /tmp/p0382.img/usr/lib/libswscale.so.3
0xb5b5f578  0xb5b6c718  Yes (*) /tmp/p0382.img/usr/lib/libswresample.so.1
0xb5b44998  0xb5b4b490  Yes (*) /tmp/p0382.img/usr/lib/libpostproc.so.53
0xb5b1f0e0  0xb5b2e194  Yes /tmp/p0382.img/lib/libpthread.so.0
0xb5aa4c00  0xb5ad46d0  Yes /tmp/p0382.img/lib/libm.so.6
0xb5a859ec  0xb5a8fc34  Yes /tmp/p0382.img/usr/lib/libXext.so.6
0xb597b728  0xb59f92bc  Yes /tmp/p0382.img/usr/lib/libX11.so.6
0xb5946fc8  0xb59573d0  Yes /tmp/p0382.img/usr/lib/libtheoradec.so.1
0xb5887910  0xb591bbb8  Yes (*) /tmp/p0382.img/usr/lib/libasound.so.2
0xb58579f8  0xb58586ac  Yes /tmp/p0382.img/usr/lib/libXss.so.1
0xb5844ca0  0xb5846bac  Yes /tmp/p0382.img/usr/lib/libXv.so.1
0xb57e7700  0xb58265e0  Yes /tmp/p0382.img/usr/lib/libSDL-1.2.so.0
0xb56bae00  0xb57abb28  Yes /tmp/p0382.img/lib/libc.so.6
0xb569292c  0xb5693724  Yes /tmp/p0382.img/lib/libdl.so.2
0xb5650a70  0xb566e6a4  Yes /tmp/p0382.img/usr/lib/libfontconfig.so.1
0xb561e324  0xb563951c  Yes /tmp/p0382.img/usr/lib/libexpat.so.1
0xb559d36c  0xb55f5cb4  Yes /tmp/p0382.img/usr/lib/libfreetype.so.6
0xb55622b0  0xb5567e84  Yes /tmp/p0382.img/usr/lib/libenca.so.0
0xb541fbc0  0xb54b5a08  Yes (*) /tmp/p0382.img/usr/lib/libx264.so.144
0xb53d4df0  0xb53fa0b0  Yes /tmp/p0382.img/usr/lib/libtheoraenc.so.1
0xb53a72b0  0xb53bd258  Yes (*) /tmp/p0382.img/usr/lib/liblzma.so.5
0xb5386050  0xb5392cc0  Yes (*) /tmp/p0382.img/usr/lib/libbz2.so.0
0xb5367810  0xb5373b30  Yes /tmp/p0382.img/usr/lib/libxcb.so.1
0xb534da00  0xb534e5a8  Yes /tmp/p0382.img/usr/lib/libXau.so.6
0xb5339f80  0xb533b69c  Yes /tmp/p0382.img/usr/lib/libXdmcp.so.6
0xb5323720  0xb5326ea0  Yes /tmp/p0382.img/lib/librt.so.1
0xb530b6e0  0xb5311234  Yes /tmp/p0382.img/usr/lib/libXrandr.so.2
0xb52f3530  0xb52f9060  Yes /tmp/p0382.img/usr/lib/libXrender.so.1
0xb52d3160  0xb52e18a4  Yes /tmp/p0382.img/lib/libgcc_s.so.1
(*): Shared library is missing debugging information.

Is this a function of how those libraries were built (by the recipe)
or something else?  How can I get the symbolic debugging info enabled?

Thanks for any pointers



Usually it works well if you add

EXTRA_IMAGE_FEATURES_append = “ dbg-pkgs”

image size grows but you get good debug view on target.

another option, I usually use is setup feeds
and then

opkg install -dbg

which pulls in a section of debug info needed to debug a given package.



I've done all this already.  The problem is that for the libraries which
have no symbols

[yocto] ERROR: busybox-udhcpd not found in the base feeds

2016-02-11 Thread Martin Townsend

Hi,

I've just moved over to using systemd on a project but am seeing the error
listed in the subject.
I added the following to local.conf as there is no distribution config file.

VIRTUAL-RUNTIME_init_manager = "systemd"
DISTRO_FEATURES_append = " systemd"
# Prevent the SysVinit distribution feature from being automatically enabled
# Breaks busybox-udhcpd for some reason.
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"

My understanding is that the last line will stop init scripts being
installed if the recipe has systemd support.  Adding
VIRTUAL-RUNTIME_initscripts = "" would completely disable init scripts I
think so I didn't put this in.  So the above should use systemd where
appropriate otherwise use sysV init scripts.

I then blew away all sstate, cache and tmp directories and rebuilt and get
the error.  If I comment out the last line the error goes away but I get
all the sys V init scripts.  I checked the recipe and it inherits systemd
and update-rc.d and I think the problem may be that busybox builds syslog
with a systemd service but all the remaining components use init scripts as
far as I can see, including udhcpd.  I looked in packages-split and
busybox-udhcpd is empty.

Any help appreciated,
Martin.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH][yocto-autobuilder] buildbot/status/web/templates/build.html

2016-02-11 Thread Graydon, Tracy

From: Tracy Graydon 

[YOCTO #8098]

The resubmit build button on the build status page, when used with exact same
revisions generates an exception. Fixed by removing the Resubmit Build button.

Signed-off-by: Tracy Graydon 
---
 .../buildbot/status/web/templates/build.html | 5 -
 1 file changed, 5 deletions(-)

diff --git 
a/lib/python2.7/site-packages/buildbot-0.8.8-py2.7.egg/buildbot/status/web/templates/build.html
 
b/lib/python2.7/site-packages/buildbot-0.8.8-py2.7.egg/buildbot/status/web/templates/build.html
index a01d4b0..0f50888 100644
--- 
a/lib/python2.7/site-packages/buildbot-0.8.8-py2.7.egg/buildbot/status/web/templates/build.html
+++ 
b/lib/python2.7/site-packages/buildbot-0.8.8-py2.7.egg/buildbot/status/web/templates/build.html
@@ -213,11 +213,6 @@ SourceStamps:
   Elapsed{{ 
elapsed }}
 
 
-  {% if authz.advertiseAction('forceBuild', request) %}
-Resubmit Build:
-{{ forms.rebuild_build(build_url+"/rebuild", authz, sourcestamps[0]) }}
-  {% endif %}
-
 
 
 
-- 
2.4.3

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

[yocto] Need some info regarding parsing all recipe files

2016-02-11 Thread Bhanagay, Sagar

Hello,

I'm Sagar & I work for the HPE Openswitch project.
I'm new to Yocto & do forgive my naivety.

We use Yocto for building our NOS images & I plan to do the following -
I want to go through all the recipe files & print out one field (say SRCREV) 
from them (if it exists) to a file.
I also want this file to be packaged in the image (at say - /etc/srcrev.txt).
I can do that by writing a Python script, but I was exploring if there's any 
native way that Yocto supports to do that.

I don't want to change any recipe file to include any "config_prepend" clause 
or so.
Is there some way (maybe tweaking the base class?) in which I can achieve this?

If I were to write a custom Python script, how do I trigger it during make?

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

Re: [yocto] wic: Setting partition id value?

[yocto] native tool is not installed before it is used

Re: [yocto] Dropping Debian 7 as supported?

Re: [yocto] Selecting a specific tuning in an application recipe?

[yocto] Selecting a specific tuning in an application recipe?

Re: [yocto] valgrind-native

[yocto] Adding SCM'ed files to image

Re: [yocto] wic: Setting partition id value?

[yocto] valgrind-native

Re: [yocto] valgrind-native

Re: [yocto] Eclipse IDE plugin failure

Re: [yocto] Eclipse IDE plugin failure

[yocto] Dropping Debian 7 as supported?

Re: [yocto] valgrind-native

Re: [yocto] Dropping Debian 7 as supported?

[linux-yocto] [PATCH] selftests/capabilities: Add tests for capability evolution

[yocto] How to create do_populate_sysroot_append task

Re: [yocto] How to build for various boards from one yocto installatio

Re: [yocto] Debugging shared libraries

Re: [yocto] ERROR: busybox-udhcpd not found in the base feeds

Re: [yocto] Debugging shared libraries

Re: [yocto] Debugging shared libraries

Re: [yocto] Debugging shared libraries

[yocto] ERROR: busybox-udhcpd not found in the base feeds

[yocto] [PATCH][yocto-autobuilder] buildbot/status/web/templates/build.html

[yocto] Need some info regarding parsing all recipe files

26 matches

Site Navigation

Mail list logo

Footer information