Re: [OE-core] systemd services in the rootfs
On 02/13/2013 05:33 PM, Florin Sarbu wrote:
Hi all,
following the transition of the systemd.bbclass from meta-openembedded
to oe-core, I stumbled upon on what seems to me a missing feature that
has not been brought along in the new systemd.bbclass in oe-core.
Seems that if one does not explicitly specify the inclusion of the
packages containing the systemd services in a packagegroup or image
recipe or use some other mechanism that will determine the addition of
these packages in the final rootfs, then the root filesystem will not
contain the systemd services. Even though
DISTRO_FEATURES_INITMAN=systemd is set. The meta-openembedded
systemd.bbclass, needed no additional adding of the systemd related
packages, just RRECOMMENDED and things worked as expected. Shouldn't
the DISTRO_FEATURES_INITMAN do just that? Is it something that still
needs to be done on the systemd.bbclass or would you suggest that from
now on we will have to manually add the systemd packages in
packagegroups, image recipes etc?
Each recipe should install it's service files in the appropriate
location, like ${D}${systemd-unitdir}/system (check out searchpaths in
systemd.bbclass)
For reference you can check on my branch enabling patches
http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rmoisan/systemd-rossid=38dfb4ec00aa87ab20065de7b391572f19679ca8
Radu
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] systemd services in the rootfs
The issue I was referring to was that the individual packages (that
contain the systemd service files) generated from various recipes, do
not end up in the rootfs solely by having them declared in the
SYSTEMD_PACKAGES and having DISTRO_FEATURES_INITMAN =systemd. You need
now to explicitly add these ${PN}-systemd (or whatever name you choose
for the packages that will hold the systemd services) in some
packagegroups or image recipes to have them in the rootfs. It is not a
question of where to have them in the rootfs, but rather to have them
added in the do_rootfs stage.
Hope I cleared things up a little better now.
Thanks,
Florin
On 02/14/2013 10:47 AM, Radu Moisan wrote:
On 02/13/2013 05:33 PM, Florin Sarbu wrote:
Hi all,
following the transition of the systemd.bbclass from
meta-openembedded to oe-core, I stumbled upon on what seems to me a
missing feature that has not been brought along in the new
systemd.bbclass in oe-core. Seems that if one does not explicitly
specify the inclusion of the packages containing the systemd services
in a packagegroup or image recipe or use some other mechanism that
will determine the addition of these packages in the final rootfs,
then the root filesystem will not contain the systemd services. Even
though DISTRO_FEATURES_INITMAN=systemd is set. The
meta-openembedded systemd.bbclass, needed no additional adding of the
systemd related packages, just RRECOMMENDED and things worked as
expected. Shouldn't the DISTRO_FEATURES_INITMAN do just that? Is it
something that still needs to be done on the systemd.bbclass or would
you suggest that from now on we will have to manually add the systemd
packages in packagegroups, image recipes etc?
Each recipe should install it's service files in the appropriate
location, like ${D}${systemd-unitdir}/system (check out searchpaths in
systemd.bbclass)
For reference you can check on my branch enabling patches
http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rmoisan/systemd-rossid=38dfb4ec00aa87ab20065de7b391572f19679ca8
Radu
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] systemd services in the rootfs
On 14 February 2013 09:09, Florin Sarbu florin.sa...@windriver.com wrote:
The issue I was referring to was that the individual packages (that contain
the systemd service files) generated from various recipes, do not end up in
the rootfs solely by having them declared in the SYSTEMD_PACKAGES and having
DISTRO_FEATURES_INITMAN =systemd. You need now to explicitly add these
${PN}-systemd (or whatever name you choose for the packages that will hold
the systemd services) in some packagegroups or image recipes to have them in
the rootfs. It is not a question of where to have them in the rootfs, but
rather to have them added in the do_rootfs stage.
Put the service files into the relevant package (i.e. $PN, instead of
into a separate package of their own.
This is different to how meta-systemd worked, because in oe-core
systemd is a DISTRO_FEATURE and not something you can decide at image
construction time.
Ross
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] mulitilib_header: Avoid sstate checksum issues for -native recipes
The use of arch specific variables like MIPSPKGSFX_ABI was creeping
into the -native sstate checksums of package like ncurses-native.
This is pointless and undesireable. We could add specific variable
exclusions but we might as well just brute force the code to be disabled
in the -native case since we don't use multilibs in the native case.
[YOCTO #3827]
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/classes/multilib_header.bbclass
b/meta/classes/multilib_header.bbclass
index 639ed4b..4d049a8 100644
--- a/meta/classes/multilib_header.bbclass
+++ b/meta/classes/multilib_header.bbclass
@@ -39,3 +39,9 @@ oe_multilib_header() {
sed -e s#ENTER_HEADER_FILENAME_HERE#${stem}#g
${COREBASE}/scripts/multilib_header_wrapper.h ${D}/${includedir}/$each_header
done
}
+
+# Dependencies on arch variables like MIPSPKGSFX_ABI can be problematic.
+# We don't need multilib headers for native builds so brute force things.
+oe_multilib_header_class-native () {
+ return
+}
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] systemd services in the rootfs
So choosing, for example ${PN} to hold the systemd services, and also
choose to use sysvinit as the init manager, then I'd end up with a
rootfs containing useless systemd services.
Then can someone detail what is SYSTEMD_PACKAGES used for? If it's only
for adding the packages to PACKAGES, then it doesn't make too much sense
to exist in my opinion, as it would just be an extra variable defined to
do something that can be achieved without defining a extra variable.
Florin
On 02/14/2013 12:17 PM, Burton, Ross wrote:
On 14 February 2013 09:09, Florin Sarbu florin.sa...@windriver.com wrote:
The issue I was referring to was that the individual packages (that contain
the systemd service files) generated from various recipes, do not end up in
the rootfs solely by having them declared in the SYSTEMD_PACKAGES and having
DISTRO_FEATURES_INITMAN =systemd. You need now to explicitly add these
${PN}-systemd (or whatever name you choose for the packages that will hold
the systemd services) in some packagegroups or image recipes to have them in
the rootfs. It is not a question of where to have them in the rootfs, but
rather to have them added in the do_rootfs stage.
Put the service files into the relevant package (i.e. $PN, instead of
into a separate package of their own.
This is different to how meta-systemd worked, because in oe-core
systemd is a DISTRO_FEATURE and not something you can decide at image
construction time.
Ross
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] How to implement systemd
So far i've been using good old initscripts for my systems. I want to try out systemd. Having zero experience with that, I just added systemd to the DISTRO_FEATURES and started a fresh build. The build ran fine, but it produced something that still seems to be using initscripts, albeit that a few things stopped working (the network did not start, for example). Is there some openembedded guide on what one has to do to actually use systemd? I've tried google, but because i don't have a clue what keywords to look for, I got only irrelevant results on various Linux distributions while searching with oe-core initscripts to systemd and variations on that theme. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] What do these warnings mean?
I imported libav from meta-oe into my build so I can have additional gstreamer support. Now I'm seeing these warnings: WARNING: QA Issue: ELF binary '/home/local/p82_soft/tmp/work/cortexa9-vfp-neon-amltd-linux-gnueabi/gst-plugins-bad/0.10.23-r3.ti1.6.4.3/packages-split/gst-plugins-bad-vp8/usr/lib/gstreamer-0.10/libgstvp8.so' has relocations in .text WARNING: QA Issue: ELF binary '/home/local/p82_soft/tmp/work/cortexa9-vfp-neon-amltd-linux-gnueabi/libav/0.8.3-r0/packages-split/libavcodec/usr/lib/libavcodec.so.53.35.0' has relocations in .text Exactly what do these mean? What do I do to get rid of them? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] How to implement systemd
W dniu 14.02.2013 13:35, Mike Looijmans pisze: So far i've been using good old initscripts for my systems. I want to try out systemd. Having zero experience with that, I just added systemd to the DISTRO_FEATURES and started a fresh build. The build ran fine, but it produced something that still seems to be using initscripts, albeit that a few things stopped working (the network did not start, for example). DISTRO_FEATURES_INITMAN = systemd is what you want. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] What do these warnings mean?
On Thu, 2013-02-14 at 05:35 -0700, Gary Thomas wrote: I imported libav from meta-oe into my build so I can have additional gstreamer support. Now I'm seeing these warnings: WARNING: QA Issue: ELF binary '/home/local/p82_soft/tmp/work/cortexa9-vfp-neon-amltd-linux-gnueabi/gst-plugins-bad/0.10.23-r3.ti1.6.4.3/packages-split/gst-plugins-bad-vp8/usr/lib/gstreamer-0.10/libgstvp8.so' has relocations in .text WARNING: QA Issue: ELF binary '/home/local/p82_soft/tmp/work/cortexa9-vfp-neon-amltd-linux-gnueabi/libav/0.8.3-r0/packages-split/libavcodec/usr/lib/libavcodec.so.53.35.0' has relocations in .text Exactly what do these mean? What do I do to get rid of them? It means the linker has to perform relocations on the .text segment at runtime. This slows down loads and means more memory usage if two applications use the library since the kernel can't share the mappings. It will work its just inefficient. The fix us usually to compile as position independent code using the pic compiler option. Cheers, Richard (far from an expert on this) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] How to implement systemd
On 02/14/2013 01:42 PM, Marcin Juszkiewicz wrote: W dniu 14.02.2013 13:35, Mike Looijmans pisze: So far i've been using good old initscripts for my systems. I want to try out systemd. Having zero experience with that, I just added systemd to the DISTRO_FEATURES and started a fresh build. The build ran fine, but it produced something that still seems to be using initscripts, albeit that a few things stopped working (the network did not start, for example). DISTRO_FEATURES_INITMAN = systemd is what you want. Sorry, I have to amend my original post. DISTRO_FEATURES_INITMAN = systemd is just what I did (added it to my distro .conf file), because from the source I gathered that that was the way to get it into DISTRO_FEATURES. How can I check whether it's using systemd? I don't see any obvious difference in the rootfs, and I never saw any systemd package being built either. Mike. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] What do these warnings mean?
On Thu, 2013-02-14 at 05:35 -0700, Gary Thomas wrote: WARNING: QA Issue: ELF binary '/home/local/p82_soft/tmp/work/cortexa9-vfp-neon-amltd-linux-gnueabi/gst-plugins-bad/0.10.23-r3.ti1.6.4.3/packages-split/gst-plugins-bad-vp8/usr/lib/gstreamer-0.10/libgstvp8.so' has relocations in .text WARNING: QA Issue: ELF binary '/home/local/p82_soft/tmp/work/cortexa9-vfp-neon-amltd-linux-gnueabi/libav/0.8.3-r0/packages-split/libavcodec/usr/lib/libavcodec.so.53.35.0' has relocations in .text Exactly what do these mean? What do I do to get rid of them? Generally they mean that some non-PIC code has leaked into a shared library. The most common way for that to happen is for a DSO final link to accidentally pull in some members from a static library. There are a few other possible causes as well, mostly toolchain bugs or limitations (you used to get this under some circumstances when enabling full unwind tables on MIPS for example), but non-PIC code is the most likely one. You can use readelf or objdump to inspect the relocation table for the files in question. In most cases there is a fairly obvious culprit, e.g. an R_ARM_PC24 reloc with an incriminating function name. Having relocations in .text is undesirable because it wastes memory and slows down program startup. They can occasionally cause more severe problems: for example, if were using SELinux then you might find that your security policy didn't allow those binaries to be run at all. (This was the default policy on Fedora for a while; I've no idea if it still is.) p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Broken dependency processing?
I have an customized image which explicitly names 'pulseaudio-server' Building my image will break if I don't also explicitly name 'consolekit' root@my_target:~# opkg whatdepends consolekit Root set: consolekit What depends on root set pulseaudio-module-console-kit 2.1-r15 depends on consolekit root@my_target:~# opkg whatdepends pulseaudio-module-console-kit Root set: pulseaudio-module-console-kit What depends on root set pulseaudio-server 2.1-r15 depends on pulseaudio-module-console-kit I can see that building pulseaudio does not force consolekit although it will be required in order to install pulseaudio-server. [gthomas@titan p82_soft]$ bitbake -g pulseaudio Loading cache: 100% || ETA: 00:00:00 Loaded 1415 entries from dependency cache. NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: PN build list saved to 'pn-buildlist' NOTE: PN dependencies saved to 'pn-depends.dot' NOTE: Package dependencies saved to 'package-depends.dot' NOTE: Task dependencies saved to 'task-depends.dot' [gthomas@titan p82_soft]$ grep consolekit pn-buildlist ... nothing (not present) Note: my image/system does not normally include 'consolekit' and this behaviour causes the image to fail to build. I'm using the Poky/Yocto tree from a few weeks ago in case that matters: meta = master:09359e6ec00901abfe49157f1f9730117b4d284b -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] How to implement systemd
On 02/14/2013 01:57 PM, Mike Looijmans wrote: On 02/14/2013 01:42 PM, Marcin Juszkiewicz wrote: W dniu 14.02.2013 13:35, Mike Looijmans pisze: So far i've been using good old initscripts for my systems. I want to try out systemd. Having zero experience with that, I just added systemd to the DISTRO_FEATURES and started a fresh build. The build ran fine, but it produced something that still seems to be using initscripts, albeit that a few things stopped working (the network did not start, for example). DISTRO_FEATURES_INITMAN = systemd is what you want. Sorry, I have to amend my original post. DISTRO_FEATURES_INITMAN = systemd is just what I did (added it to my distro .conf file), because from the source I gathered that that was the way to get it into DISTRO_FEATURES. How can I check whether it's using systemd? I don't see any obvious difference in the rootfs, and I never saw any systemd package being built either. Ah, to (probably) answer my own question, there was a hidden VIRTUAL-RUNTIME_init_manager = sysvinit in my config chain, which was probably the cause. Running another build, and I've seen a systemd task being run now... ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] state of systemd in oe
Hey, I noticed that systemd service files are going back into the oe-core layer and not always compatible with meta-oe. What is the official policy on systemd right now? Is it supposed to be confined to the meta-oe/meta-systemd layer? Or what cases will they be pulled in and/or duplicated in oe-core? Thanks! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] systemd: /run directory not created
On 25/01/13 08:28, Radu Moisan wrote: On 01/24/2013 04:52 PM, Burton, Ross wrote: On 24 January 2013 13:03, Radu Moisan radu.moi...@intel.com wrote: ok, thanks Enrico, this clears the picture for me. Well then it looks like Jack's problems is coming from some other place. No - /run needs to exist for the mount to happen, and there isn't a /run in the filesystem. Whatever creates the root filesystem structure should also create /run I guess. I agree, but what I meant was that my initial assumptions were wrong with concern to Jack's problem. I run it on qemu and /run is there. His problem related to /run creation while I was thinking about mounting issue. Radu Did this ever go anywhere? I have just tried again today with exactly the same result, all I did was change the DISTRO_FEATURES_INITMAN to systemd. Regards -- Jack Mitchell (j...@embed.me.uk) Embedded Systems Engineer http://www.embed.me.uk -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] connman: Have connman package systemd service.
On 13 February 2013 15:52, Florin Sarbu florin.sa...@windriver.com wrote:
connman.inc was missing the SYSTEMD_PACKAGES variable. Declared
${PN}-systemd as the package containing the systemd service
file and also added this package to PACKAGES variable.
NACK.
SYSTEMD_PACKAGES defaults to $PN so the systemd service files are in
the connman package:
$ bb contents connman
connman
/etc/dbus-1/system.d/connman.conf
/lib/systemd/system/connman.service
/usr/sbin/connmand
The systemd support in oe-core wasn't literally copied from
meta-systemd, so please stop trying to add back the $PN-systemd
packages.
Ross
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] systemd services in the rootfs
On 14 February 2013 12:32, Florin Sarbu florin.sa...@windriver.com wrote:
So choosing, for example ${PN} to hold the systemd services, and also choose
to use sysvinit as the init manager, then I'd end up with a rootfs
containing useless systemd services.
That would be a packaging bug.
The systemd class only does work if the systemd feature is enabled.
When installing service files manually, respect the systemd feature.
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=rmoisan/systemd-rossid=d6a9fe2e980eb996c36712983b151b04774438df
is an example of systemd integration for dropbear that does the right
thing.
Ross
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] systemd: /run directory not created
On 14 February 2013 14:31, Jack Mitchell m...@communistcode.co.uk wrote: Did this ever go anywhere? I have just tried again today with exactly the same result, all I did was change the DISTRO_FEATURES_INITMAN to systemd. Odd, as I just built and booted a systemd image (core-image-sato, in poky master), and it worked fine. Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] state of systemd in oe
On 14 February 2013 14:02, Ian Geiser igei...@devonit.com wrote: Hey, I noticed that systemd service files are going back into the oe-core layer and not always compatible with meta-oe. What is the official policy on systemd right now? Is it supposed to be confined to the meta-oe/meta-systemd layer? Or what cases will they be pulled in and/or duplicated in oe-core? Thanks! I'm pulling as much as makes sense into oe-core, and the meta-systemd maintainers are doing a sterling job at keeping up with changes we've been making in oe-core, or deleting appends that have been merged into oe-core. Hopefully by the time 1.4 is released meta-systemd won't exist. Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] systemd: /run directory not created
On 14/02/13 15:31, Burton, Ross wrote: On 14 February 2013 14:31, Jack Mitchell m...@communistcode.co.uk wrote: Did this ever go anywhere? I have just tried again today with exactly the same result, all I did was change the DISTRO_FEATURES_INITMAN to systemd. Odd, as I just built and booted a systemd image (core-image-sato, in poky master), and it worked fine. Ross I have a custom distro definition that cuts a lot of features out. Can you find out which package is supposed to create run and I can check if it is pulled in properly on my setup? I think something must be assumed somewhere and I don't have the features enabled to trigger it. -- Jack Mitchell (j...@embed.me.uk) Embedded Systems Engineer http://www.embed.me.uk -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] Solved package namespace errors in PRS
For some packages PRS reported incorrect upstream version
as it was either the raw string or it mismatched some
alternative groups.
Signed-off-by: Emilia Ciobanu emilia.maria.silvia.ciob...@intel.com
---
meta/classes/distrodata.bbclass |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/classes/distrodata.bbclass b/meta/classes/distrodata.bbclass
index e25eeab..276ca03 100644
--- a/meta/classes/distrodata.bbclass
+++ b/meta/classes/distrodata.bbclass
@@ -291,8 +291,8 @@ python do_checkpkg() {
suffix =
(tar\.gz|tgz|tar\.bz2|zip|xz|rpm|bz2|orig\.tar\.gz|tar\.xz|src\.tar\.gz|src\.tgz|svnr\d+\.tar\.bz2|stable\.tar\.gz|src\.rpm)
suffixtuple = (tar.gz, tgz, zip, tar.bz2, tar.xz, bz2,
orig.tar.gz, src.tar.gz, src.rpm, src.tgz, svnr\d+.tar.bz2,
stable.tar.gz, src.rpm)
-sinterstr = (?Pname%s?)v?(?Pver%s)(source)? % (prefix, ver_regex)
-sdirstr = (?Pname%s)\.?v?(?Pver%s)(source)?[\.\-](?Ptype%s$) %
(prefix, ver_regex, suffix)
+sinterstr = (?Pname%s?)v?(?Pver%s)(\-source)? % (prefix,
ver_regex)
+sdirstr = (?Pname%s)\.?v?(?Pver%s)(\-source)?[\.\-](?Ptype%s$)
% (prefix, ver_regex, suffix)
def parse_inter(s):
m = re.search(sinterstr, s)
@@ -504,7 +504,7 @@ python do_checkpkg() {
status = ErrParseDir
else:
newver still contains a full package name
string
-status = newver[1]
+status = re.sub('_', '.', newver[1])
elif not len(fhtml):
status = ErrHostNoDir
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] systemd: /run directory not created
On 14/02/13 15:44, Jack Mitchell wrote: On 14/02/13 15:31, Burton, Ross wrote: On 14 February 2013 14:31, Jack Mitchell m...@communistcode.co.uk wrote: Did this ever go anywhere? I have just tried again today with exactly the same result, all I did was change the DISTRO_FEATURES_INITMAN to systemd. Odd, as I just built and booted a systemd image (core-image-sato, in poky master), and it worked fine. Ross I have a custom distro definition that cuts a lot of features out. Can you find out which package is supposed to create run and I can check if it is pulled in properly on my setup? I think something must be assumed somewhere and I don't have the features enabled to trigger it. From a quick look it seems as though volatiles in initscripts-1.0 should create the run directory if it's not found. However the initscripts package doesn't get pulled in on my image at all, and I can't see an equivalent in the systemd package. -- Jack Mitchell (j...@embed.me.uk) Embedded Systems Engineer http://www.embed.me.uk -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] state of systemd in oe
Just out of curiosity: - will systemd be the default? - will it be possible to still use/choose sysvinit (i.e. is sysvinit going away)? How does systemd fit in with busybox? My understanding is that busybox has its own init system. If someone enables/chooses systemd, does it disable busybox's init from being built? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] state of systemd in oe
On 14 February 2013 16:03, Trevor Woerner twoer...@gmail.com wrote: Just out of curiosity: - will systemd be the default? - will it be possible to still use/choose sysvinit (i.e. is sysvinit going away)? No and yes. How does systemd fit in with busybox? My understanding is that busybox has its own init system. If someone enables/chooses systemd, does it disable busybox's init from being built? At the moment busybox's init isn't used - that's one of the many options for an init system including sysvinit, which is the default. Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Question about hanging after git clone try in Prelink
Hi, due to local company restrictions, I cannot clone external git repository. During prelink-native fetch I catch the warning about that (given that the SRC_URI point to git) but then, trying other mirrors, system is able to download a tar.gz of the prelink. The strange thing is that however bitbake hangs with the error (that was a warning first) about the failure of SRC_URI catch. Why this? Should system be aware the given package was downloaded using mirrors? This happens also for mtd-utils. Please can you help me? Thanks, Giuseppe PS: if I rerun the process than it goes ok, obviously because it finds the tar.gz in download directory. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Broken dependency processing?
On Thu, Feb 14, 2013 at 06:19:34AM -0700, Gary Thomas wrote: I have an customized image which explicitly names 'pulseaudio-server' Building my image will break if I don't also explicitly name 'consolekit' see http://lists.linuxtogo.org/pipermail/openembedded-core/2012-November/032203.html root@my_target:~# opkg whatdepends consolekit Root set: consolekit What depends on root set pulseaudio-module-console-kit 2.1-r15 depends on consolekit root@my_target:~# opkg whatdepends pulseaudio-module-console-kit Root set: pulseaudio-module-console-kit What depends on root set pulseaudio-server 2.1-r15 depends on pulseaudio-module-console-kit I can see that building pulseaudio does not force consolekit although it will be required in order to install pulseaudio-server. [gthomas@titan p82_soft]$ bitbake -g pulseaudio Loading cache: 100% || ETA: 00:00:00 Loaded 1415 entries from dependency cache. NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: PN build list saved to 'pn-buildlist' NOTE: PN dependencies saved to 'pn-depends.dot' NOTE: Package dependencies saved to 'package-depends.dot' NOTE: Task dependencies saved to 'task-depends.dot' [gthomas@titan p82_soft]$ grep consolekit pn-buildlist ... nothing (not present) Note: my image/system does not normally include 'consolekit' and this behaviour causes the image to fail to build. I'm using the Poky/Yocto tree from a few weeks ago in case that matters: meta = master:09359e6ec00901abfe49157f1f9730117b4d284b -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/3] Allow xserver-xf86-config to ship no xorg.conf
Hi, This series lets a BSP not ship a xorg.conf as not all BSPs need them. This is implemented by not installing empty xorg.conf files, and making the generic xorg.conf empty (which is a good move, as it specified the intel driver). There's a patch to package_ipkg that's required to sanity check the CONFFILES variable, as otherwise building an opkg fails when the package is empty. Ross The following changes since commit b15730caf0d4c40271796887505507f2501958bb: mulitilib_header: Avoid sstate checksum issues for -native recipes (2013-02-14 12:36:08 +) are available in the git repository at: git://git.yoctoproject.org/poky-contrib ross/xorg for you to fetch changes up to d6c444561597e8546a7ae39aaa14da578456ab7d: xserver-xf86-config: empty generic xorg.conf (2013-02-14 17:48:56 +) Ross Burton (3): package_ipk: check CONFFILES exist before adding them to metadata xserver-xf86-config: don't ship empty xorg.conf xserver-xf86-config: empty generic xorg.conf meta/classes/package_ipk.bbclass |3 ++- .../xorg-xserver/xserver-xf86-config/xorg.conf | 26 .../xorg-xserver/xserver-xf86-config_0.1.bb| 10 +--- 3 files changed, 8 insertions(+), 31 deletions(-) Ross Burton (3): package_ipk: check CONFFILES exist before adding them to metadata xserver-xf86-config: don't ship empty xorg.conf xserver-xf86-config: empty generic xorg.conf meta/classes/package_ipk.bbclass |3 ++- .../xorg-xserver/xserver-xf86-config/xorg.conf | 26 .../xorg-xserver/xserver-xf86-config_0.1.bb| 10 +--- 3 files changed, 8 insertions(+), 31 deletions(-) -- 1.7.10.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] xserver-xf86-config: empty generic xorg.conf
The idea of a generic xorg.conf is meaningless, especially when they specify the intel driver. Empty this file so that unless the BSP specifies it's own xorg.conf, no xorg.conf file is installed. Signed-off-by: Ross Burton ross.bur...@intel.com --- .../xorg-xserver/xserver-xf86-config/xorg.conf | 26 1 file changed, 26 deletions(-) diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-config/xorg.conf b/meta/recipes-graphics/xorg-xserver/xserver-xf86-config/xorg.conf index 9c3d490..e69de29 100644 --- a/meta/recipes-graphics/xorg-xserver/xserver-xf86-config/xorg.conf +++ b/meta/recipes-graphics/xorg-xserver/xserver-xf86-config/xorg.conf @@ -1,26 +0,0 @@ - -Section Device -IdentifierIntel Graphics Driver -Driverintel -EndSection - -Section Monitor -IdentifierGeneric Monitor -OptionDPMS -EndSection - -Section Screen -IdentifierDefault Screen -DeviceIntel Graphics Driver -MonitorGeneric Monitor -DefaultDepth24 -EndSection - -Section ServerLayout -IdentifierDefault Layout -ScreenDefault Screen -EndSection - -Section ServerFlags -OptionDontZap 0 -EndSection -- 1.7.10.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] package_ipk: check CONFFILES exist before adding them to metadata
opkg-build verifies that conffiles exist, so verify that the specified files
actually exist before writing them to conffiles.
This mirrors the behaviour of FILES and package_rpm's CONFFILES handling.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/classes/package_ipk.bbclass |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/classes/package_ipk.bbclass b/meta/classes/package_ipk.bbclass
index d735051..e5e76ef 100644
--- a/meta/classes/package_ipk.bbclass
+++ b/meta/classes/package_ipk.bbclass
@@ -440,7 +440,8 @@ python do_package_ipk () {
bb.utils.unlockfile(lf)
raise bb.build.FuncFailed(unable to open conffiles for
writing.)
for f in conffiles_str.split():
-conffiles.write('%s\n' % f)
+if os.path.exists(oe.path.join(root, f)):
+conffiles.write('%s\n' % f)
conffiles.close()
os.chdir(basedir)
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] xserver-xf86-config: don't ship empty xorg.conf
Many hardware platforms can autodetect their hardware and don't need a xorg.conf
at all. Make it easy for BSPs to not ship a xorg.conf by not installing empty
xorg.conf files.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
.../recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb
b/meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb
index 3c29f8b..90d6f56 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb
@@ -7,12 +7,14 @@ PR = r11
SRC_URI = file://xorg.conf
-CONFFILES_${PN} += ${sysconfdir}/X11/xorg.conf
+CONFFILES_${PN} = ${sysconfdir}/X11/xorg.conf
PACKAGE_ARCH = ${MACHINE_ARCH}
+ALLOW_EMPTY_${PN} = 1
do_install () {
- install -d ${D}/${sysconfdir}/X11
- install -m 0644 ${WORKDIR}/xorg.conf ${D}/${sysconfdir}/X11/
+ if test -s ${WORKDIR}/xorg.conf; then
+ install -d ${D}/${sysconfdir}/X11
+ install -m 0644 ${WORKDIR}/xorg.conf ${D}/${sysconfdir}/X11/
+ fi
}
-
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] insane: remove unused variable
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/classes/insane.bbclass |1 -
1 file changed, 1 deletion(-)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index d285e56..f52fcea 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -165,7 +165,6 @@ def package_qa_check_rpath(file,name, d, elf, messages):
return
bad_dirs = [d.getVar('TMPDIR', True) + /work,
d.getVar('STAGING_DIR_TARGET', True)]
-bad_dir_test = d.getVar('TMPDIR', True)
if not bad_dirs[0] in d.getVar('WORKDIR', True):
bb.fatal(This class assumed that WORKDIR is ${TMPDIR}/work... Not
doing any check)
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Question about hanging after git clone try in Prelink
What version of OE-Core/POoky are you using? It would be helpful to know that. If you are not using the Poky Distro, then you could try setting PREMIRRORS and/or use the own-mirrors.bbclass and set SOURCE_MIRROR_URL to something like http://downloads.yoctoproject.org/mirror/sources/; Sau! On 02/14/2013 08:44 AM, Giuseppe CONDORELLI wrote: Hi, due to local company restrictions, I cannot clone external git repository. During prelink-native fetch I catch the warning about that (given that the SRC_URI point to git) but then, trying other mirrors, system is able to download a tar.gz of the prelink. The strange thing is that however bitbake hangs with the error (that was a warning first) about the failure of SRC_URI catch. Why this? Should system be aware the given package was downloaded using mirrors? This happens also for mtd-utils. Please can you help me? Thanks, Giuseppe PS: if I rerun the process than it goes ok, obviously because it finds the tar.gz in download directory. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] package_ipk: check CONFFILES exist before adding them to metadata
On Thu, Feb 14, 2013 at 05:52:50PM +, Ross Burton wrote:
opkg-build verifies that conffiles exist, so verify that the specified files
actually exist before writing them to conffiles.
Shouldn't this show at least a warning about missing conffile?
opkg-build error saved me few times before adding CONFFILES with wrong
pattern not matching anything in FILES.
I understand that you cannot use fatal error here for that xorg.conf
use-case, but warning would be nice.
This mirrors the behaviour of FILES and package_rpm's CONFFILES handling.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/classes/package_ipk.bbclass |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/classes/package_ipk.bbclass
b/meta/classes/package_ipk.bbclass
index d735051..e5e76ef 100644
--- a/meta/classes/package_ipk.bbclass
+++ b/meta/classes/package_ipk.bbclass
@@ -440,7 +440,8 @@ python do_package_ipk () {
bb.utils.unlockfile(lf)
raise bb.build.FuncFailed(unable to open conffiles for
writing.)
for f in conffiles_str.split():
-conffiles.write('%s\n' % f)
+if os.path.exists(oe.path.join(root, f)):
+conffiles.write('%s\n' % f)
conffiles.close()
os.chdir(basedir)
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] package_ipk: check CONFFILES exist before adding them to metadata
On 14 February 2013 18:31, Martin Jansa martin.ja...@gmail.com wrote: Shouldn't this show at least a warning about missing conffile? opkg-build error saved me few times before adding CONFFILES with wrong pattern not matching anything in FILES. I'm pretty certain rpm doesn't produce a warning, so we'd want to fix that up too. Anyway, do we want to introduce warnings that by design will always cause errors on a set of packages? Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] acpid: modify CFLAGS
Override the hard-coded CFLAGS used in Makefile
to reference our CFLAGS.
Upstream-Status: Pending
Signed-off-by: Joe Slater jsla...@windriver.com
---
meta/recipes-bsp/acpid/acpid.inc |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-bsp/acpid/acpid.inc b/meta/recipes-bsp/acpid/acpid.inc
index 3c0219f..1ffe6ff 100644
--- a/meta/recipes-bsp/acpid/acpid.inc
+++ b/meta/recipes-bsp/acpid/acpid.inc
@@ -13,7 +13,9 @@ inherit update-rc.d
INITSCRIPT_NAME = acpid
INITSCRIPT_PARAMS = defaults
-EXTRA_OEMAKE =
+# Makefile ignores our CFLAGS, so override it.
+#
+EXTRA_OEMAKE = CFLAGS='-W -Wall -Werror -Wundef -Wshadow ${CFLAGS} $(DEFS)'
do_compile () {
oe_runmake 'CC=${CC} -D_GNU_SOURCE' 'CROSS=${HOST_PREFIX}'
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] acpid: modify CFLAGS
On 02/14/2013 09:09 AM, Joe Slater wrote:
Override the hard-coded CFLAGS used in Makefile
to reference our CFLAGS.
Can you be clearer about this?
I just checked the output of the compile log and these flags are set
correctly. I also looked at the make -n output via a devshell.
This seems to be hardcoding the CFLAGS into this recipe.
Sounds like something else is going on.
Thanks
Sau!
Upstream-Status: Pending
Signed-off-by: Joe Slater jsla...@windriver.com
---
meta/recipes-bsp/acpid/acpid.inc |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-bsp/acpid/acpid.inc b/meta/recipes-bsp/acpid/acpid.inc
index 3c0219f..1ffe6ff 100644
--- a/meta/recipes-bsp/acpid/acpid.inc
+++ b/meta/recipes-bsp/acpid/acpid.inc
@@ -13,7 +13,9 @@ inherit update-rc.d
INITSCRIPT_NAME = acpid
INITSCRIPT_PARAMS = defaults
-EXTRA_OEMAKE =
+# Makefile ignores our CFLAGS, so override it.
+#
+EXTRA_OEMAKE = CFLAGS='-W -Wall -Werror -Wundef -Wshadow ${CFLAGS} $(DEFS)'
do_compile () {
oe_runmake 'CC=${CC} -D_GNU_SOURCE' 'CROSS=${HOST_PREFIX}'
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] systemd: /run directory not created
On 02/14/13 15:57, Jack Mitchell wrote: On 14/02/13 15:44, Jack Mitchell wrote: On 14/02/13 15:31, Burton, Ross wrote: On 14 February 2013 14:31, Jack Mitchell m...@communistcode.co.uk wrote: Did this ever go anywhere? I have just tried again today with exactly the same result, all I did was change the DISTRO_FEATURES_INITMAN to systemd. Odd, as I just built and booted a systemd image (core-image-sato, in poky master), and it worked fine. Ross I have a custom distro definition that cuts a lot of features out. Can you find out which package is supposed to create run and I can check if it is pulled in properly on my setup? I think something must be assumed somewhere and I don't have the features enabled to trigger it. From a quick look it seems as though volatiles in initscripts-1.0 should create the run directory if it's not found. However the initscripts package doesn't get pulled in on my image at all, and I can't see an equivalent in the systemd package Doing a manual ln -s var/run run on my mounted SD card gets systemd to the first [OK] part but then the board dies on me, it's a usb ftdi serial and even that connection gets wiped. I think there is something fundamentally wrong somewhere, which is causing the systemd setup to not execute properly, or the fact that there are minimal packages and minimal features in my distro image is causing the problem. What I will maybe try to do tomorrow is build a stock core-image-minimal with systemd, then remove distro features one by one and see if it breaks. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] remake: do not create po files
The 'make update' was using wget to get the gmo and other gnu files from
upstream, since need to work cleanly in a non-networked or proxy environment
this does not so well. Remove the list of languages from the LINGUAS file.
[YOCTO #3745]
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/recipes-devtools/remake/remake_git.bb | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/meta/recipes-devtools/remake/remake_git.bb
b/meta/recipes-devtools/remake/remake_git.bb
index 7e9857e9..42c4d48 100644
--- a/meta/recipes-devtools/remake/remake_git.bb
+++ b/meta/recipes-devtools/remake/remake_git.bb
@@ -13,13 +13,11 @@ DEPENDS += readline
PROVIDES += make
do_configure_prepend() {
+# remove the default LINGUAS since we are not going to generate languages
+rm po/LINGUAS
+touch po/LINGUAS
# create config.rpath which required by configure.ac
autopoint || touch config.rpath
}
-do_compile_prepend() {
-# updating .po and other gnu build files
-make update
-}
-
BBCLASSEXTEND = native
--
1.8.0.2
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH for danny] glib: disable selinux for native builds
From: Matthew McClintock m...@freescale.com
This improves reusabiliy of sstate-cache across different hosts
Signed-odd-by: Matthew McClintock m...@freescale.com
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/recipes-core/glib-2.0/glib-2.0_2.32.4.bb | 2 +-
meta/recipes-core/glib-2.0/glib.inc | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/glib-2.0/glib-2.0_2.32.4.bb
b/meta/recipes-core/glib-2.0/glib-2.0_2.32.4.bb
index 10c0b61..a939045 100644
--- a/meta/recipes-core/glib-2.0/glib-2.0_2.32.4.bb
+++ b/meta/recipes-core/glib-2.0/glib-2.0_2.32.4.bb
@@ -1,6 +1,6 @@
require glib.inc
-PR = r6
+PR = r7
PE = 1
DEPENDS += libffi python-argparse-native zlib
diff --git a/meta/recipes-core/glib-2.0/glib.inc
b/meta/recipes-core/glib-2.0/glib.inc
index 8b099f2..8086c86 100644
--- a/meta/recipes-core/glib-2.0/glib.inc
+++ b/meta/recipes-core/glib-2.0/glib.inc
@@ -28,7 +28,7 @@ S = ${WORKDIR}/glib-${PV}
CORECONF = --disable-dtrace --disable-fam --disable-libelf
--disable-systemtap
EXTRA_OECONF = --enable-included-printf=no ${CORECONF}
-EXTRA_OECONF_virtclass-native = ${CORECONF}
+EXTRA_OECONF_virtclass-native = ${CORECONF} --disable-selinux
EXTRA_OECONF_linuxstdbase = --enable-included-printf=no ${CORECONF}
FILES_${PN} = ${libdir}/lib*${SOLIBS} ${datadir}/glib-2.0/schemas \
--
1.8.1.2
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] New ugly parsing error, when SRCPV fails to expand
Failing to get recipe from upstream svn repository now fails with ugly
stack trace.
I have bitbake/master from today and it's not really google-glog fault I had
network
issue when bitbake was parsing, but error message should look better (it looked
better
before)
Parsing recipes...ERROR: Error executing a python function in code:
ExpansionError: Failure expanding variable SRCPV, expression was
${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher
failure: Fetch command failed with exit
code 1, output:
svn: E175002: Unable to connect to a repository at URL
'http://google-glog.googlecode.com/svn/trunk'
svn: E175002: OPTIONS of 'http://google-glog.googlecode.com/svn/trunk': Could
not resolve hostname `google-glog.googlecode.com': Host not found
(http://google-glog.googlecode.com
)
ERROR: The stack trace of python calls that resulted in this exception/failure
was:
ERROR: File code, line 1, in module
ERROR:
ERROR: File
__anon_620__OE_shr_core_openembedded_core_meta_classes_base_bbclass, line
209, in __anon_620__OE_shr_core_openembedded_core_meta_classes_base_bbclass
ERROR:
ERROR: File /OE/shr-core/bitbake/lib/bb/data_smart.py, line 503, in getVar
ERROR: return self.expand(value, var)
ERROR:
ERROR: File /OE/shr-core/bitbake/lib/bb/data_smart.py, line 336, in expand
ERROR: return self.expandWithRefs(s, varname).value
ERROR:
ERROR: File /OE/shr-core/bitbake/lib/bb/data_smart.py, line 317, in
expandWithRefs
ERROR: s = __expand_var_regexp__.sub(varparse.var_sub, s)
ERROR:
ERROR: File /OE/shr-core/bitbake/lib/bb/data_smart.py, line 97, in var_sub
ERROR: var = self.d.getVar(key, True)
ERROR:
ERROR: File /OE/shr-core/bitbake/lib/bb/data_smart.py, line 503, in getVar
ERROR: return self.expand(value, var)
ERROR:
ERROR: File /OE/shr-core/bitbake/lib/bb/data_smart.py, line 336, in expand
ERROR: return self.expandWithRefs(s, varname).value
ERROR:
ERROR: File /OE/shr-core/bitbake/lib/bb/data_smart.py, line 317, in
expandWithRefs
ERROR: s = __expand_var_regexp__.sub(varparse.var_sub, s)
ERROR:
ERROR: File /OE/shr-core/bitbake/lib/bb/data_smart.py, line 97, in var_sub
ERROR: var = self.d.getVar(key, True)
ERROR:
ERROR: File /OE/shr-core/bitbake/lib/bb/data_smart.py, line 503, in getVar
ERROR: return self.expand(value, var)
ERROR:
ERROR: File /OE/shr-core/bitbake/lib/bb/data_smart.py, line 336, in expand
ERROR: return self.expandWithRefs(s, varname).value
ERROR:
ERROR: File /OE/shr-core/bitbake/lib/bb/data_smart.py, line 317, in
expandWithRefs
ERROR: s = __expand_var_regexp__.sub(varparse.var_sub, s)
ERROR:
ERROR: File /OE/shr-core/bitbake/lib/bb/data_smart.py, line 97, in var_sub
ERROR: var = self.d.getVar(key, True)
ERROR:
ERROR: File /OE/shr-core/bitbake/lib/bb/data_smart.py, line 503, in getVar
ERROR: return self.expand(value, var)
ERROR:
ERROR: File /OE/shr-core/bitbake/lib/bb/data_smart.py, line 336, in expand
ERROR: return self.expandWithRefs(s, varname).value
ERROR:
ERROR: File /OE/shr-core/bitbake/lib/bb/data_smart.py, line 326, in
expandWithRefs
ERROR: raise ExpansionError(varname, s, exc)
ERROR:
ERROR: The code that was being executed was:
ERROR: ***
0001:__anon_620__OE_shr_core_openembedded_core_meta_classes_base_bbclass(d)
ERROR:
0002:__anon_227__OE_shr_core_openembedded_core_meta_classes_package_bbclass(d)
ERROR:
0003:__anon_20__OE_shr_core_openembedded_core_meta_classes_blacklist_bbclass(d)
ERROR:
0004:__anon_20__OE_shr_core_openembedded_core_meta_classes_debian_bbclass(d)
ERROR:
0005:__anon_474__OE_shr_core_openembedded_core_meta_classes_package_ipk_bbclass(d)
ERROR: [From file: 'code', lineno: 1, function: module]
ERROR: 0205:#
ERROR: 0206:override = d.getVar('SRC_URI_OVERRIDES_PACKAGE_ARCH', True)
ERROR: 0207:if override != '0':
ERROR: 0208:paths = []
ERROR: *** 0209:fpaths = (d.getVar('FILESPATH', True) or '').split(':')
ERROR: 0210:machine = d.getVar('MACHINE', True)
ERROR: 0211:for p in fpaths:
ERROR: 0212:if os.path.basename(p) == machine and
os.path.isdir(p):
ERROR: 0213:paths.append(p)
ERROR: [From file:
'__anon_620__OE_shr_core_openembedded_core_meta_classes_base_bbclass', lineno:
209, function:
__anon_620__OE_shr_core_openembedded_core_meta_classes_base_bbclass]
ERROR: Failed to parse recipe:
/OE/shr-core/meta-openembedded/meta-oe/recipes-support/google-glog/google-glog_svn.bb
ERROR: Command execution failed: Exited with 1
Summary: There were 70 ERROR messages shown, returning a non-zero exit code.
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 00/22] Package Updates Fixes
Richard,
This is mostly a set of package updates with a couple of fixes
fro systemd from Khem and Ross.
Please review Peter's rename patch.
I have build and booted sato locally with most of the udpated pacakges,
the Auotbuilder is currently running with Master under Test.
Thanks
Sau!
The following changes since commit 6c6568e47d6b3b0edaba569bfa4e38f9d72b5122:
tzcode/tzdata: Update to 2012j (2013-02-14 23:17:18 +)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib sgw/stage
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/stage
Constantin Musca (1):
qemu: upgrade to 1.3.1
Cristian Iorga (1):
alsa-lib: upgrade to 1.0.26
Cristiana Voicu (1):
sanity.bbclass: when bblayers.conf is updated, it invokes a reparse
Franklin S. Cooper Jr (1):
scripts/bitbake: Remove all instances of paths to a layer's scripts
directory.
Khem Raj (1):
systemd.bbclass: Dont use libdir and base_libdir for units
Laurentiu Palcu (7):
xf86-video-intel: upgrade to 2.21.0
xf86-input-vmmouse: upgrade to 13.0.0
libdrm: upgrade to 2.4.42
xkeyboard-config: upgrade to 2.8
xf86-input-synaptics: upgrade to 1.6.3
xf86-video-vmware: upgrade to 13.0.0
xev: upgrade to 1.2.1
Marko Lindqvist (4):
webkit-gtk: update to upstream version 1.8.3
gtk+: update to upstream version 2.24.15
harfbuzz: update to upstream version 0.9.12
libpng: update to upstream version 1.5.14
Peter Seebach (1):
libc-common.bbclass: rename ALL the packages
Ross Burton (4):
systemd: add udev-extraconf and USB/PCI IDs to RRECOMMENDS
package_ipk: check CONFFILES exist before adding them to metadata
xserver-xf86-config: don't ship empty xorg.conf
xserver-xf86-config: empty generic xorg.conf
Saul Wold (1):
gnupg: fix CVE-2012-6085
meta/classes/libc-common.bbclass | 19 +-
meta/classes/package_ipk.bbclass |3 +-
meta/classes/sanity.bbclass| 18 +-
meta/classes/systemd.bbclass | 13 +-
meta/recipes-core/systemd/systemd_197.bb |1 +
.../qemu/{qemu_1.3.0.bb = qemu_1.3.1.bb} |4 +-
meta/recipes-devtools/qemu/qemu_git.bb |2 +-
.../gtk+/gtk+-2.24.14/hardcoded_libtool.patch | 33 -
.../gtk+-2.24.14/obsolete_automake_macros.patch| 23 -
...utton-do-not-prelight-in-touchscreen-mode.patch |0
...Duplicate-the-exec-string-returned-by-gtk.patch |0
.../cellrenderer-cairo.patch |0
.../configure-nm.patch | 11 +-
.../configurefix.patch |0
.../{gtk+-2.24.14 = gtk+-2.24.15}/doc-fixes.patch |0
.../entry-cairo.patch |0
.../gtk+/gtk+-2.24.15/hardcoded_libtool.patch | 1814
.../{gtk+-2.24.14 = gtk+-2.24.15}/no-demos.patch |0
.../run-iconcache.patch|0
.../toggle-font.diff |0
.../{gtk+-2.24.14 = gtk+-2.24.15}/xsettings.patch |0
.../gtk+/{gtk+_2.24.14.bb = gtk+_2.24.15.bb} |7 +-
.../drm/{libdrm_2.4.40.bb = libdrm_2.4.42.bb} |4 +-
.../avoid_double_version_h.patch |0
.../disable_graphite.patch |0
.../{harfbuzz_0.9.10.bb = harfbuzz_0.9.12.bb} |8 +-
meta/recipes-graphics/xorg-app/xev_1.2.0.bb| 12 -
meta/recipes-graphics/xorg-app/xev_1.2.1.bb| 12 +
...tics_1.6.2.bb = xf86-input-synaptics_1.6.3.bb} |6 +-
...ouse_12.9.0.bb = xf86-input-vmmouse_13.0.0.bb} |4 +-
...intel_2.20.17.bb = xf86-video-intel_2.21.0.bb} |4 +-
...ware-port-vmware-driver-to-new-compat-API.patch | 655 ---
...mware_12.0.2.bb = xf86-video-vmware_13.0.0.bb} |7 +-
...board-config_2.7.bb = xkeyboard-config_2.8.bb} |4 +-
.../xorg-xserver/xserver-xf86-config/xorg.conf | 26 -
.../xorg-xserver/xserver-xf86-config_0.1.bb| 10 +-
.../fix-tstamp-declaration.patch |0
.../obsolete_automake_macros.patch |0
.../unbreak_plugindir.patch|0
.../{alsa-lib_1.0.25.bb = alsa-lib_1.0.26.bb} |7 +-
.../libpng-1.5.13/obsolete_automake_macros.patch | 15 -
.../libpng/{libpng_1.5.13.bb = libpng_1.5.14.bb} | 11 +-
.../{webkit-gtk_1.8.2.bb = webkit-gtk_1.8.3.bb} |6 +-
.../gnupg/gnupg-1.4.7/GnuPG1-CVE-2012-6085.patch | 63 +
.../gnupg/gnupg-2.0.19/GnuPG2-CVE-2012-6085.patch | 63 +
meta/recipes-support/gnupg/gnupg_1.4.7.bb |3 +-
meta/recipes-support/gnupg/gnupg_2.0.19.bb |5 +-
scripts/bitbake|2 +-
48 files changed, 2041 insertions(+), 834 deletions(-)
rename meta/recipes-devtools/qemu/{qemu_1.3.0.bb = qemu_1.3.1.bb} (64%)
delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.24.14/hardcoded_libtool.patch
delete mode 100644
