Re: [OE-core] [RFC PATCH] package.bbclass: omit .pyc and .pyo file
On Wed, 2015-01-07 at 17:32 +0800, Robert Yang wrote: On 01/07/2015 05:23 PM, Mike Looijmans wrote: On 01/07/2015 09:07 AM, Richard Purdie wrote: On Tue, 2015-01-06 at 17:07 -0800, Robert Yang wrote: We should not ship .pyc or .pyo file, but there are a few packages ship .pyc, should we: Why should we not ship them? Doesn't python create these at runtime if they're not present? What happens on a read only filesystem? You definitely SHOULD ship the .pyc files. If they don't exist, the interpreter is forced to re-compile the .py source, and will attempt to write the result to the filesystem. It won't cause harm, it won't fail, but it's very inefficient. It's better to let the host do the py-pyc conversion anyway. AFAIK, the .pyc is not version compatible, the .pyc created with the build host's python may not work with the target python. I thought that was true for pyo but not pyc? Do you have a pointer to documentation on that? Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] What is expected of a kernel recipe nowadays?
On Tue, Jan 06, 2015 at 11:08:53AM +, Burton, Ross wrote: On 6 January 2015 at 08:57, Martin Jansa martin.ja...@gmail.com wrote: 2) do_configure failing: ERROR: Function failed: do_configure (log file is located at /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/work/mako-webos-linux-gnueabi/linux-lg-mako/3.4.0+gitrAUTOINC+38bdbfe224-r0/temp/log.do_configure.17498) ERROR: Logfile of failure stored in: /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/work/mako-webos-linux-gnueabi/linux-lg-mako/3.4.0+gitrAUTOINC+38bdbfe224-r0/temp/log.do_configure.17498 Log data follows: | DEBUG: Executing python function sysroot_cleansstate | DEBUG: Python function sysroot_cleansstate finished | DEBUG: Executing shell function do_configure | NOTE: make oldconfig | make: *** No rule to make target `oldconfig'. Stop. | ERROR: oe_runmake failed | WARNING: exit code 1 from a shell command. | ERROR: Function failed: do_configure (log file is located at /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/work/mako-webos-linux-gnueabi/linux-lg-mako/3.4.0+gitrAUTOINC+38bdbfe224-r0/temp/log.do_configure.17498) NOTE: recipe linux-lg-mako-3.4.0+gitrAUTOINC+38bdbfe224-r0: task do_configure: Failed ERROR: Task 491 (/home/jenkins/workspace/luneos-unstable/webos-ports/meta-smartphone/meta-lg/recipes-kernel/linux/ linux-lg-mako_git.bb, do_configure) failed with exit code '1' I'll Me Too here, often hitting this on rebuilds: DEBUG: Executing shell function do_configure NOTE: make -C /data/poky-master/tmp/sysroots/qemuarm64/usr/src/kernel O=/data/poky-master/tmp/work/qemuarm64-poky-linux/linux-yocto/3.14.24+gitAUTOINC+a227f20eff_902f34d361-r0/linux-qemuarm64-standard-build oldnoconfig make: Entering directory `/data/poky-master/tmp/sysroots/qemuarm64/usr/src/kernel' make: *** No rule to make target `oldnoconfig'. Stop. make: Leaving directory `/data/poky-master/tmp/sysroots/qemuarm64/usr/src/kernel' ERROR: Task 77 (/home/ross/Yocto/poky/meta/recipes-kernel/linux/linux-yocto_3.14.bb, do_configure) failed with exit code '1' last world build revealed new kind of error: both qemux86 and qemux86-64 failed like this ERROR: Function failed: do_kernel_configme (log file is located at /home/jenkins/oe/world/shr-core/tmp-glibc/work/qemux86_64-oe-linux/linux-yocto/3.17.6+gitAUTOINC+b81030f9ec_5ff54d8fbf-r0/temp/log.do_kernel_configme.6974) ERROR: Logfile of failure stored in: /home/jenkins/oe/world/shr-core/tmp-glibc/work/qemux86_64-oe-linux/linux-yocto/3.17.6+gitAUTOINC+b81030f9ec_5ff54d8fbf-r0/temp/log.do_kernel_configme.6974 Log data follows: | DEBUG: Executing shell function do_kernel_configme | NOTE: kernel configme | [INFO] Configuring target/machine combo: standard/qemux86-64 | [INFO] collecting configs in .meta/meta-series | ERROR: could not sanitize configuration fragments |errors are logged in /home/jenkins/oe/world/shr-core/tmp-glibc/sysroots/qemux86-64/usr/src/kernel/.meta/cfg/standard/common-pc-64/config.log | WARNING: exit code 1 from a shell command. | ERROR: Function failed: do_kernel_configme (log file is located at /home/jenkins/oe/world/shr-core/tmp-glibc/work/qemux86_64-oe-linux/linux-yocto/3.17.6+gitAUTOINC+b81030f9ec_5ff54d8fbf-r0/temp/log.do_kernel_configme.6974) NOTE: recipe linux-yocto-3.17.6+gitAUTOINC+b81030f9ec_5ff54d8fbf-r0: task do_kernel_configme: Failed -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] State of bitbake world, Failed tasks 2015-01-07
This time not very useful as qemux86* are failing to build kernel.
http://www.openembedded.org/wiki/Bitbake_World_Status
== Failed tasks 2015-01-07 ==
INFO: jenkins-job.sh-1.1.0 Complete log available at
http://logs.nslu2-linux.org/buildlogs/oe/world/log.report.20150107_100747.log
=== common (9) ===
*
/meta-openembedded/meta-networking/recipes-protocols/openwsman/openwsman_2.4.12.bb,
do_compile
*
/meta-openembedded/meta-oe/recipes-graphics/xorg-font/font-adobe-100dpi_1.0.3.bb,
do_compile
*
/meta-openembedded/meta-oe/recipes-graphics/xorg-font/font-adobe-utopia-100dpi_1.0.4.bb,
do_compile
*
/meta-openembedded/meta-oe/recipes-graphics/xorg-font/font-bh-100dpi_1.0.3.bb,
do_compile
*
/meta-openembedded/meta-oe/recipes-graphics/xorg-font/font-bh-lucidatypewriter-100dpi_1.0.3.bb,
do_compile
*
/meta-openembedded/meta-oe/recipes-graphics/xorg-font/font-misc-misc_1.1.2.bb,
do_compile
*
/meta-openembedded/meta-oe/recipes-support/libutempter/libutempter_1.1.6.bb,
do_compile
* /meta-openembedded/meta-xfce/recipes-bindings/vala/xfce4-vala_4.10.3.bb,
do_configure
* /meta-qt5/recipes-qt/examples/qt5-opengles2-test_git.bb, do_compile
=== common-x86 (1) ===
* /openembedded-core/meta/recipes-kernel/linux/linux-yocto_3.17.bb,
do_kernel_configme
=== qemuarm (0) ===
=== qemux86 (0) ===
=== qemux86_64 (0) ===
=== Number of failed tasks (29) ===
{| class=wikitable
|-
|| qemuarm || 9 ||
http://logs.nslu2-linux.org/buildlogs/oe/world//log.world.20150106_212602.log//
|| http://errors.yoctoproject.org:80/Errors/Search/1/3916/
|-
|| qemux86 || 10||
http://logs.nslu2-linux.org/buildlogs/oe/world//log.world.20150106_231530.log//
|| http://errors.yoctoproject.org:80/Errors/Search/1/3929/
|-
|| qemux86_64 || 10||
http://logs.nslu2-linux.org/buildlogs/oe/world//log.world.20150107_015729.log//
|| http://errors.yoctoproject.org:80/Errors/Search/1/3931/
|}
=== PNBLACKLISTs (50) ===
=== QA issues (53) ===
{| class=wikitable
!| Count||Issue
|-
||0 ||already-stripped
|-
||0 ||libdir
|-
||1 ||textrel
|-
||42||version-going-backwards
|-
||5 ||build-deps
|-
||5 ||file-rdeps
|}
PNBLACKLISTs:
openembedded-core/:
meta-browser:
meta-openembedded:
meta-filesystems/recipes-filesystems/ifuse/ifuse_1.1.2.bb:PNBLACKLIST[ifuse] ?=
depends on blacklisted libimobiledevice
meta-gnome/recipes-apps/gnome-mplayer/gnome-mplayer_1.0.5.bb:PNBLACKLIST[gnome-mplayer]
?= rdepends on blacklisted mplayer
meta-gnome/recipes-connectivity/network-manager-applet/network-manager-applet_0.9.8.10.bb:PNBLACKLIST[network-manager-applet]
?= Depends on broken polkit-gnome
meta-gnome/recipes-gnome/gcr/gcr_3.8.2.bb:PNBLACKLIST[gcr] ?= CONFLICT: 4
files conflict with gnome-keyring
meta-gnome/recipes-gnome/gdm/gdm_2.32.2.bb:PNBLACKLIST[gdm] ?= Depends on
broken polkit-gnome
meta-gnome/recipes-gnome/gnome-bluetooth/gnome-bluetooth_2.32.0.bb:PNBLACKLIST[gnome-bluetooth]
?= dbus-binding-tool fails with: Unable to load
gnome-bluetooth-2.32.0/lib/bluetooth-client.xml: manager is not a valid
D-Bus interface name
meta-gnome/recipes-gnome/gnome-menus/gnome-menus3_3.10.1.bb:PNBLACKLIST[gnome-menus3]
?= CONFLICT: 24 files are conflicting with gnome-menus
meta-gnome/recipes-gnome/gnome-panel/gnome-panel3_3.0.2.bb:PNBLACKLIST[gnome-panel3]
?= CONFLICT: depends on libgweather3 which conflicts with libgweather
meta-gnome/recipes-gnome/gweather/libgweather3_3.0.2.bb:PNBLACKLIST[libgweather3]
?= CONFLICT: 876 files are conflicting with libgweather
meta-gnome/recipes-gnome/zenity/zenity_2.32.1.bb:PNBLACKLIST[zenity] ?=
BROKEN: doesn't build with B!=S
meta-multimedia/recipes-mediacentre/xbmc/xbmc_git.bb:PNBLACKLIST[xbmc] ?=
/usr/include/c++/ctime:70:11: error: '::gmtime' has not been declared
meta-multimedia/recipes-multimedia/coriander/coriander_2.0.2.bb:PNBLACKLIST[coriander]
?= BROKEN: fails to use SDL probably because libsdl-config was removed,
error: unknown type name 'SDL_Overlay'
meta-multimedia/recipes-multimedia/dleyna/renderer-service-upnp_0.3.0.bb:PNBLACKLIST[renderer-service-upnp]
?= BROKEN: doesn't build with B!=S (trying to install rendererconsole.py from
${B} instead of ${S})
meta-networking/recipes-support/lksctp-tools/lksctp-tools_1.0.16.bb:PNBLACKLIST[lksctp-tools]
?= BROKEN: fails to link against sctp_connectx symbol
meta-oe/recipes-connectivity/libimobiledevice/libimobiledevice_1.1.4.bb:PNBLACKLIST[libimobiledevice]
?= cannot run test program while cross compiling
meta-oe/recipes-connectivity/soft66/soft66_git.bb:PNBLACKLIST[soft66] ?=
BROKEN: depends on broken libftdi
meta-oe/recipes-connectivity/zeroc-ice/zeroc-ice_3.5.1.bb:PNBLACKLIST[zeroc-ice]
?= BROKEN: not compatible with default db version
meta-oe/recipes-extended/polkit/polkit-gnome_0.102.bb:PNBLACKLIST[polkit-gnome]
?= Fails to build, m4:configure.ac:125: recursion limit of 1024 exceeded, use
-LN to change it
Re: [OE-core] [PATCH 1/1] layerindex.bbclass: Add ability to fetch layers from layer index
Hi Chong, On Wednesday 07 January 2015 14:35:42 Chong Lu wrote: It maybe depends on other layers when one layer is added to BBLAYERS. If define LAYERDEPENDS variable in this layer, we will get error from bitbake. But sometimes, we don't have defined. Add a mechanism to fetch layers from layer index and update bblayers.conf as appropriate. The layer index stores dependencies of all layers. Query dependency from layer index and fetch layer repo, then add this layer to BBLAYERS. Hmm, this is certainly interesting but not quite what I had in mind - I was thinking rather that bitbake-layers would be extended and it would be an explicit operation to add a layer from the layer index + all of its dependencies. We can of course also have something semi-automatic like this class, but the manual tool ought to come first IMHO (which the class could then make use of). Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] package.bbclass: omit .pyc and .pyo file
On 01/07/2015 09:07 AM, Richard Purdie wrote: On Tue, 2015-01-06 at 17:07 -0800, Robert Yang wrote: We should not ship .pyc or .pyo file, but there are a few packages ship .pyc, should we: Why should we not ship them? Doesn't python create these at runtime if they're not present? What happens on a read only filesystem? You definitely SHOULD ship the .pyc files. If they don't exist, the interpreter is forced to re-compile the .py source, and will attempt to write the result to the filesystem. It won't cause harm, it won't fail, but it's very inefficient. It's better to let the host do the py-pyc conversion anyway. The opposite works just fine: You can omit the .py files and ship only .pyc files. We do that on settopboxes that use Python for the GUI, this saves several megabytes of flash space. To accomplish that, we put the .py files into a $PN-src package. There has been general agreement that .pyo files are utterly pointless. I'm sure we've had issues raised by someone with a read only filesystem before FWIW. I agree there is probably an issue here but deleting them may not be the best option. I'm open to ideas though. My idea would be to standardize on shipping ONLY compiled files, and put the source .py files into a separate package named $PN-src by default. There is no need to install megabytes of python source files that neither users nor the interpreter will ever read. Met vriendelijke groet / kind regards, Mike Looijmans System Expert TOPIC Embedded Systems Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: (+31) (0) 499 33 69 79 Telefax: (+31) (0) 499 33 69 70 E-mail: mike.looijm...@topic.nl Website: www.topic.nl Please consider the environment before printing this e-mail Topic zoekt gedreven (embedded) software specialisten! http://topic.nl/vacatures/topic-zoekt-software-engineers/ -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Bug reporting and good bug reports
I was informed on irc yesterday that bug reports are hard and that debugging via irc is easier. I think I need to remind people why good bug reports are important and how they do actually help immensely. I do actually believe that not everything has to have bug report. If you mention an issue, someone says hey, I know how to fix that and sends a patch out, a bug report is wasted overhead IMO. I know some programme managers who disagree strongly with me and would suggest *every* bugfix commit should have a defect tracking item. We're not going there I understand the idea, its not practical. That said, if its not immediately clear what the problem is, it should become a bug report. Why? Firstly, the random selection of people on irc at the time probably aren't the right people to fix it. Telling those people to read 48 hours of irc log for the details is disrespectful of their time. It also happens that the first people referred to a bug may not be the person who actually can fix it. If someone else needs to come to a bug, having a summary of the issue, the salient facts and the current status is immensley useful for handover. As a case in point, I tried to debug a qt4 build failure yesterday for which there is no bug report. I lost hours building the wrong things, experimenting to try and find the reproducer steps and generally chasing my tail, losing the autobuilder log of the failure, the name of the qt4 recipe that was failing (which task was it again?) and so on. I do now have a set of reproducer steps, its quite simple: MACHINE=imx53qsb bitbake virtual/kernel MACHINE=imx53qsb bitbake virtual/kernel -c clean MACHINE=imx53qsb bitbake qt4-x11-free I also have a patch. Where should I share them? How do I ensure everyone with an interest in this defect actually gets the patch? Sure I can create email and send to the people who I think need to know. The bugzilla lets interested parties add themselves to bugs though. I should also note that QA actually go through bugs in the bugzilla, including closed ones, looking for test cases. We're not great at this yet but it does happen. If there is a well documented test case like that above, we might write an automated QA test for it. Having it documented is therefore a good thing. I do appreciate writing a bug report is hard, especially if you don't know where the problem is, or how to reproduce it exactly. It takes time and effort. You can however document what you know and discussion can happen in a common place to figure out how to reproduce it. I do except the submitters to fully understand the bug, if they did they'd probably write a patch instead. So fair warning, I am going to start ignoring things on irc and ask for bug numbers in future, assuming something isn't a 5 minute fix with an immediate patch. I will back and encourage anyone else doing this too. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] package.bbclass: omit .pyc and .pyo file
On 01/07/2015 05:23 PM, Mike Looijmans wrote: On 01/07/2015 09:07 AM, Richard Purdie wrote: On Tue, 2015-01-06 at 17:07 -0800, Robert Yang wrote: We should not ship .pyc or .pyo file, but there are a few packages ship .pyc, should we: Why should we not ship them? Doesn't python create these at runtime if they're not present? What happens on a read only filesystem? You definitely SHOULD ship the .pyc files. If they don't exist, the interpreter is forced to re-compile the .py source, and will attempt to write the result to the filesystem. It won't cause harm, it won't fail, but it's very inefficient. It's better to let the host do the py-pyc conversion anyway. AFAIK, the .pyc is not version compatible, the .pyc created with the build host's python may not work with the target python. // Robert The opposite works just fine: You can omit the .py files and ship only .pyc files. We do that on settopboxes that use Python for the GUI, this saves several megabytes of flash space. To accomplish that, we put the .py files into a $PN-src package. There has been general agreement that .pyo files are utterly pointless. I'm sure we've had issues raised by someone with a read only filesystem before FWIW. I agree there is probably an issue here but deleting them may not be the best option. I'm open to ideas though. My idea would be to standardize on shipping ONLY compiled files, and put the source .py files into a separate package named $PN-src by default. There is no need to install megabytes of python source files that neither users nor the interpreter will ever read. Met vriendelijke groet / kind regards, Mike Looijmans System Expert TOPIC Embedded Systems Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: (+31) (0) 499 33 69 79 Telefax: (+31) (0) 499 33 69 70 E-mail: mike.looijm...@topic.nl Website: www.topic.nl Please consider the environment before printing this e-mail Topic zoekt gedreven (embedded) software specialisten! http://topic.nl/vacatures/topic-zoekt-software-engineers/ -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] package.bbclass: omit .pyc and .pyo file
On Tue, 2015-01-06 at 17:07 -0800, Robert Yang wrote: We should not ship .pyc or .pyo file, but there are a few packages ship .pyc, should we: Why should we not ship them? Doesn't python create these at runtime if they're not present? What happens on a read only filesystem? I'm sure we've had issues raised by someone with a read only filesystem before FWIW. I agree there is probably an issue here but deleting them may not be the best option. I'm open to ideas though. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] openssh on read-only systemd rootfs
Hello, in 'image.bbclass', I found some logic for openssh running on readonly rootfs, but only in sysvinit branch. do we need similar logic in systemd branch? -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] package.bbclass: omit .pyc and .pyo file
On 7 January 2015 at 09:23, Mike Looijmans mike.looijm...@topic.nl wrote: You definitely SHOULD ship the .pyc files. If they don't exist, the interpreter is forced to re-compile the .py source, and will attempt to write the result to the filesystem. It won't cause harm, it won't fail, but it's very inefficient. It's better to let the host do the py-pyc conversion anyway. The opposite works just fine: You can omit the .py files and ship only .pyc files. We do that on settopboxes that use Python for the GUI, this saves several megabytes of flash space. To accomplish that, we put the .py files into a $PN-src package. I agree with Mike, there is a use-case for just shipping .pyc. Whether oe-core should do something to assist with this or not is debatable. There's an open bug report about this: https://bugzilla.yoctoproject.org/show_bug.cgi?id=6434. https://docs.python.org/2/tutorial/modules.html#compiled-python-files has the details we're after. Summary: .pyc is Python bytecode, which is an implementation detail of CPython. As such it's version-dependent but explicitly architecture-independent. .pyo generated with -O is simply .pyc but with asserts removed. .pyo generated with -O -O has asserts and docstrings removed. I think it's fair to say we should just ignore .pyo - no point generating and shipping it. It does seem that if we want to ship usable .pyc we need to ensure that they are compiled with python-native. I guess this could be done by calling python-native's compileall module to recompile the sources at package time. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] insane.bbclass: fix desktop
The following changes since commit dba30c2395792b553b69ce0b44cc75ff2dbdb317: kernel.bbclass: fix do_unpack function when S ends with slash (2015-01-07 14:30:13 +) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib rbt/desktop http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/desktop Robert Yang (1): insane.bbclass: fix desktop meta/classes/insane.bbclass |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] making a list of the *fundamental* variables used by image.bbclass
for class purposes, i want to make a *short* list of the really fundamental variables used to define the final content of an image as used by image.bbclass, and i want to know if there's anything i've missed from this list. first, the obvious ones: * IMAGE_FEATURES (image features, processed by image.bbclass) * IMAGE_INSTALL (names of individual packages) as i read it, those two variables pretty much define the final content of the image. i *don't* include things like EXTRA_IMAGE_FEATURES as that variable is already processed by bitbake.conf before image processing starts; that is, image.bbclass makes no reference to that variable, so it's not relevant here. other variables that make a smaller difference but still processed by image.bbclass: * ROOTFS_PKGMANAGE * SPLASH there are also all those *_PROCESS_COMMAND variables (preprocess, postprocess), but i haven't checked yet which of those are simply processed within image.bbclass based on the contents of IMAGE_FEATURES, or possibly something else. ah, here's another one: * DISTRO_FEATURES which is tested for processing of systemd/sysvinit. (for similar reasons, MACHINE_FEATURES is not listed here as all of its processing is done outside the file.) i'm still perusing the file but are there any variables i've overlooked that are treated as *input* to image.bbclass that control the final image content? (i'm also ignoring things like fstype-related variables, not interested in the *format* of the final image, just the content.) so what have i missed? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] how to create new core image recipes [pt 2]
again for purposes of tutorial, to clarify the second way to create
new core image recipes, rather than requireing an existing recipe
file (as before), inherit the fundamental class file with:
inherit core-image
and here's the first question. here's the fundamental definition of
the image contents from core-image.bbclass:
CORE_IMAGE_BASE_INSTALL = '\
packagegroup-core-boot \
packagegroup-base-extended \
\
${CORE_IMAGE_EXTRA_INSTALL} \
'
CORE_IMAGE_EXTRA_INSTALL ?=
IMAGE_INSTALL ?= ${CORE_IMAGE_BASE_INSTALL}
inherit image
i've whined about this before ... can the above not be written more
clearly as:
CORE_IMAGE_EXTRA_INSTALL ?= [is this even necessary?]
IMAGE_INSTALL ?= '\
packagegroup-core-boot \
packagegroup-base-extended \
${CORE_IMAGE_EXTRA_INSTALL} \
'
inherit image
the current code is confusing since you have to read it twice to see
what's going on ... is the second snippet not equivalent? and if not,
what subtlety is going on there? but wait ... there's more.
if this can be simplified as i've written, that drops any need for
CORE_IMAGE_BASE_INSTALL, which doesn't look necessary in the first
place. consider some examples of OE's use of this. here's
core-image-minimal.bb, whose definition i have always hated since it
inherits core-image, only to just stomp on IMAGE_INSTALL:
IMAGE_INSTALL = packagegroup-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP}
${CORE_IMAGE_EXTRA_INSTALL}
IMAGE_LINGUAS =
LICENSE = MIT
inherit core-image
i've learned to live with that, but let's continue. here's
core-image-sato.bb:
IMAGE_FEATURES += splash package-management x11-base x11-sato
ssh-server-dropbear hwcodecs
LICENSE = MIT
inherit core-image
IMAGE_INSTALL += packagegroup-core-x11-sato-games
while the above is certainly technically correct, would it not make
more sense to have written that last line as:
CORE_IMAGE_EXTRA_INSTALL = packagegroup-core-x11-sato-games
i mean, isn't that the whole point of the variable
CORE_IMAGE_EXTRA_INSTALL ... to give recipe writers a simple and
*clear* way of adding extra content to the core-image class?
now look at core-image-weston.bb, which reads (in part):
IMAGE_FEATURES += splash package-management ssh-server-dropbear hwcodecs
inherit core-image ...
CORE_IMAGE_BASE_INSTALL += weston weston-init weston-examples gtk+3-demo
clutter-1.0-examples
at this point, how many different way are there to add content to a
core-image that all seem to work? and here's core-image-directfb:
IMAGE_INSTALL += \
${CORE_IMAGE_BASE_INSTALL} \
packagegroup-core-full-cmdline \
packagegroup-core-directfb \
and here's core-image-clutter:
IMAGE_INSTALL = \
${CORE_IMAGE_BASE_INSTALL} \
packagegroup-core-clutter-core \
everyone seems to have their own idea for how to extend core-image ...
can this not be standardized so it's easier for people to RTFS? is
there no preferred way to do the above for the sake of visual
consistency?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] bind: Update libxml2 check to make it deterministic.
From: Noor noor_ah...@mentor.com
* Firstly configure scritp was testing files from bin folder.
In our case we don't copy bin folder to sysroot for target
recipes. So added extra check to validate .pc file from lib
folder via a patch to configure.in file.
* Secondly linxml2 dependency was missing. So added PACKAGECONFIG
for libxml2.
Signed-off-by: Noor Ahsan noor_ah...@mentor.com
---
...d-crosscripts-search-path-for-xml2-config.patch | 35
meta/recipes-connectivity/bind/bind_9.9.5.bb |9 +++--
2 files changed, 42 insertions(+), 2 deletions(-)
diff --git
a/meta/recipes-connectivity/bind/bind/bind-add-crosscripts-search-path-for-xml2-config.patch
b/meta/recipes-connectivity/bind/bind/bind-add-crosscripts-search-path-for-xml2-config.patch
new file mode 100644
index 000..4f1a3f8
--- /dev/null
+++
b/meta/recipes-connectivity/bind/bind/bind-add-crosscripts-search-path-for-xml2-config.patch
@@ -0,0 +1,35 @@
+From 8fa549fe5390875d56f75e20d364394cd5ccf388 Mon Sep 17 00:00:00 2001
+From: Joe MacDonald joe_macdon...@mentor.com
+Date: Mon, 3 Nov 2014 21:52:02 -0500
+Subject: [PATCH] bind: add crosscripts search path for xml2-config
+
+The configure script was testing xml2-config from bin but in openembedded
+bin folder is not copied to sysroot so the test was failing. Added another
+condition to test libxml-2.0.pc which is present in lib folder. Used pkg-config
+to get libs and cflags information.
+
+Upstream-Status: Inappropriate [ openembedded specific ]
+
+Signed-off-by: Joe MacDonald joe_macdon...@mentor.com
+Signed-off-by: Noor Ahsan noor_ah...@mentor.com
+---
+ configure.in | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/configure.in b/configure.in
+index 3d04f4c..6032f67 100644
+--- a/configure.in
b/configure.in
+@@ -1433,6 +1433,9 @@ case $use_libxml2 in
+ if test -f $use_libxml2/bin/xml2-config ; then
+ libxml2_libs=`$use_libxml2/bin/xml2-config --libs`
+ libxml2_cflags=`$use_libxml2/bin/xml2-config --cflags`
++ elif test -f $use_libxml2/lib/pkgconfig/libxml-2.0.pc ; then
++ libxml2_libs=`pkg-config libxml-2.0 --libs`
++ libxml2_cflags=`pkg-config libxml-2.0 --cflags`
+ fi
+ ;;
+ esac
+--
+1.9.1
+
diff --git a/meta/recipes-connectivity/bind/bind_9.9.5.bb
b/meta/recipes-connectivity/bind/bind_9.9.5.bb
index 8e04f8a..eacb23f 100644
--- a/meta/recipes-connectivity/bind/bind_9.9.5.bb
+++ b/meta/recipes-connectivity/bind/bind_9.9.5.bb
@@ -18,6 +18,7 @@ SRC_URI =
ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://bind9 \
file://init.d-add-support-for-read-only-rootfs.patch \
file://bind9_9_5-CVE-2014-8500.patch \
+ file://bind-add-crosscripts-search-path-for-xml2-config.patch \
SRC_URI[md5sum] = e676c65cad5234617ee22f48e328c24e
@@ -29,10 +30,14 @@ EXTRA_OECONF = ${ENABLE_IPV6}
--with-randomdev=/dev/random --disable-threads \
--disable-devpoll --disable-epoll --with-gost=no \
--with-gssapi=no --with-ecdsa=yes \
--sysconfdir=${sysconfdir}/bind \
- --with-openssl=${STAGING_LIBDIR}/..
--with-libxml2=${STAGING_LIBDIR}/.. \
+ --with-openssl=${STAGING_LIBDIR}/.. \
--enable-exportlib --with-export-includedir=${includedir}
--with-export-libdir=${libdir} \
-inherit autotools-brokensep update-rc.d systemd useradd
+inherit autotools-brokensep update-rc.d systemd useradd pkgconfig
+
+PACKAGECONFIG ?= libxml2
+
+PACKAGECONFIG[libxml2] =
--with-libxml2=${STAGING_LIBDIR}/..,--with-libxml2=no,libxml2
USERADD_PACKAGES = ${PN}
USERADD_PARAM_${PN} = --system --home /var/cache/bind --no-create-home \
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] guile: fixed installed-vs-shipped error (parallel issue)
The following changes since commit dba30c2395792b553b69ce0b44cc75ff2dbdb317: kernel.bbclass: fix do_unpack function when S ends with slash (2015-01-07 14:30:13 +) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib rbt/guile http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/guile Robert Yang (1): guile: fixed installed-vs-shipped error .../guile/files/libguile-Makefile.am-depends.patch | 39 meta/recipes-devtools/guile/guile_2.0.11.bb|1 + 2 files changed, 40 insertions(+) create mode 100644 meta/recipes-devtools/guile/files/libguile-Makefile.am-depends.patch -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] cogl: fix .pc file packaging
Some .pc files were not being correctly moved into the right sub-package, so fix
this.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-graphics/cogl/cogl-1.0.inc |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-graphics/cogl/cogl-1.0.inc
b/meta/recipes-graphics/cogl/cogl-1.0.inc
index cc51bb4..af06484 100644
--- a/meta/recipes-graphics/cogl/cogl-1.0.inc
+++ b/meta/recipes-graphics/cogl/cogl-1.0.inc
@@ -71,18 +71,18 @@ FILES_libcogl-gles2 = ${libdir}/libcogl-gles2${SOLIBS}
FILES_libcogl-gles2-dev = ${includedir}/cogl/cogl-gles2 \
${libdir}/libcogl-gles2${SOLIBSDEV} \
${libdir}/libcogl-gles2.la \
- ${libdir}/pkgconfig/cogl-gles2-experimental.pc
+ ${libdir}/pkgconfig/cogl-gles2-*.pc
FILES_libcogl-pango = ${libdir}/libcogl-pango${SOLIBS}
FILES_libcogl-pango-dev = ${includedir}/cogl/cogl-pango \
${libdir}/libcogl-pango${SOLIBSDEV} \
${libdir}/libcogl-pango.la \
- ${libdir}/pkgconfig/cogl-pango-1.0.pc
+ ${libdir}/pkgconfig/cogl-pango-*.pc
FILES_libcogl-path = ${libdir}/libcogl-path${SOLIBS}
FILES_libcogl-path-dev = ${includedir}/cogl/cogl-path \
${libdir}/libcogl-path${SOLIBSDEV} \
${libdir}/libcogl-path.la \
- ${libdir}/pkgconfig/cogl-path-1.0.pc
+ ${libdir}/pkgconfig/cogl-path-*.pc
# For backwards compatibility after Debian-renaming
RPROVIDES_libcogl = cogl-1.0
--
1.7.10.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] What is expected of a kernel recipe nowadays?
On Wed, Jan 7, 2015 at 5:07 AM, Martin Jansa martin.ja...@gmail.com wrote: On Tue, Jan 06, 2015 at 11:08:53AM +, Burton, Ross wrote: On 6 January 2015 at 08:57, Martin Jansa martin.ja...@gmail.com wrote: 2) do_configure failing: ERROR: Function failed: do_configure (log file is located at /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/work/mako-webos-linux-gnueabi/linux-lg-mako/3.4.0+gitrAUTOINC+38bdbfe224-r0/temp/log.do_configure.17498) ERROR: Logfile of failure stored in: /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/work/mako-webos-linux-gnueabi/linux-lg-mako/3.4.0+gitrAUTOINC+38bdbfe224-r0/temp/log.do_configure.17498 Log data follows: | DEBUG: Executing python function sysroot_cleansstate | DEBUG: Python function sysroot_cleansstate finished | DEBUG: Executing shell function do_configure | NOTE: make oldconfig | make: *** No rule to make target `oldconfig'. Stop. | ERROR: oe_runmake failed | WARNING: exit code 1 from a shell command. | ERROR: Function failed: do_configure (log file is located at /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/work/mako-webos-linux-gnueabi/linux-lg-mako/3.4.0+gitrAUTOINC+38bdbfe224-r0/temp/log.do_configure.17498) NOTE: recipe linux-lg-mako-3.4.0+gitrAUTOINC+38bdbfe224-r0: task do_configure: Failed ERROR: Task 491 (/home/jenkins/workspace/luneos-unstable/webos-ports/meta-smartphone/meta-lg/recipes-kernel/linux/ linux-lg-mako_git.bb, do_configure) failed with exit code '1' I'll Me Too here, often hitting this on rebuilds: DEBUG: Executing shell function do_configure NOTE: make -C /data/poky-master/tmp/sysroots/qemuarm64/usr/src/kernel O=/data/poky-master/tmp/work/qemuarm64-poky-linux/linux-yocto/3.14.24+gitAUTOINC+a227f20eff_902f34d361-r0/linux-qemuarm64-standard-build oldnoconfig make: Entering directory `/data/poky-master/tmp/sysroots/qemuarm64/usr/src/kernel' make: *** No rule to make target `oldnoconfig'. Stop. make: Leaving directory `/data/poky-master/tmp/sysroots/qemuarm64/usr/src/kernel' ERROR: Task 77 (/home/ross/Yocto/poky/meta/recipes-kernel/linux/linux-yocto_3.14.bb, do_configure) failed with exit code '1' last world build revealed new kind of error: both qemux86 and qemux86-64 failed like this ERROR: Function failed: do_kernel_configme (log file is located at /home/jenkins/oe/world/shr-core/tmp-glibc/work/qemux86_64-oe-linux/linux-yocto/3.17.6+gitAUTOINC+b81030f9ec_5ff54d8fbf-r0/temp/log.do_kernel_configme.6974) ERROR: Logfile of failure stored in: /home/jenkins/oe/world/shr-core/tmp-glibc/work/qemux86_64-oe-linux/linux-yocto/3.17.6+gitAUTOINC+b81030f9ec_5ff54d8fbf-r0/temp/log.do_kernel_configme.6974 Log data follows: | DEBUG: Executing shell function do_kernel_configme | NOTE: kernel configme | [INFO] Configuring target/machine combo: standard/qemux86-64 | [INFO] collecting configs in .meta/meta-series | ERROR: could not sanitize configuration fragments |errors are logged in /home/jenkins/oe/world/shr-core/tmp-glibc/sysroots/qemux86-64/usr/src/kernel/.meta/cfg/standard/common-pc-64/config.log | WARNING: exit code 1 from a shell command. | ERROR: Function failed: do_kernel_configme (log file is located at /home/jenkins/oe/world/shr-core/tmp-glibc/work/qemux86_64-oe-linux/linux-yocto/3.17.6+gitAUTOINC+b81030f9ec_5ff54d8fbf-r0/temp/log.do_kernel_configme.6974) NOTE: recipe linux-yocto-3.17.6+gitAUTOINC+b81030f9ec_5ff54d8fbf-r0: task do_kernel_configme: Failed I have a fix for this one. I'll open a tracking case when I'm into the office. Bruce -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] kernel.bbclass: fix do_unpack function when S ends with slash
* slash at the end causes os.symlink(kernsrc, s) to use s as
directory name and fails with:
ERROR: Error executing a python function in
/OE/build/owpb/webos-ports/meta-smartphone/meta-samsung/recipes-kernel/linux/linux-samsung-tuna_git.bb:
The stack trace of python calls that resulted in this exception/failure was:
File: 'base_do_unpack', lineno: 26, function: module
0022:subprocess.call(d.expand(mv
/OE/build/owpb/webos-ports/tmp-glibc/work/maguro-webos-linux-gnueabi/linux-samsung-tuna/3_3.0.72+gitrAUTOINC+f8ed73f94a-r12/git/
/OE/build/owpb/webos-ports/tmp-glibc/sysroots/maguro/usr/src/kernel),
shell=True)
0023:os.symlink(kernsrc, s)
0024:
0025:
*** 0026:base_do_unpack(d)
0027:
File: 'base_do_unpack', lineno: 23, function: base_do_unpack
0019:bb.utils.mkdirhier(kernsrc)
0020:bb.utils.remove(kernsrc, recurse=True)
0021:import subprocess
0022:subprocess.call(d.expand(mv
/OE/build/owpb/webos-ports/tmp-glibc/work/maguro-webos-linux-gnueabi/linux-samsung-tuna/3_3.0.72+gitrAUTOINC+f8ed73f94a-r12/git/
/OE/build/owpb/webos-ports/tmp-glibc/sysroots/maguro/usr/src/kernel),
shell=True)
*** 0023:os.symlink(kernsrc, s)
0024:
0025:
0026:base_do_unpack(d)
0027:
Exception: OSError: [Errno 2] No such file or directory
ERROR: Function failed: base_do_unpack
ERROR: Logfile of failure stored in:
/OE/build/owpb/webos-ports/tmp-glibc/work/maguro-webos-linux-gnueabi/linux-samsung-tuna/3_3.0.72+gitrAUTOINC+f8ed73f94a-r12/temp/log.do_unpack.17042
ERROR: Task 0
(/OE/build/owpb/webos-ports/meta-smartphone/meta-samsung/recipes-kernel/linux/linux-samsung-tuna_git.bb,
do_unpack) failed with exit code '1'
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/classes/kernel.bbclass | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 3b77d00..5541c94 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -43,6 +43,9 @@ python __anonymous () {
do_unpack[cleandirs] += ${S} ${STAGING_KERNEL_DIR} ${B}
base_do_unpack_append () {
s = d.getVar(S, True)
+if s[-1] == '/':
+# drop trailing slash, so that os.symlink(kernsrc, s) doesn't use s as
directory name and fail
+s=s[:-1]
kernsrc = d.getVar(STAGING_KERNEL_DIR, True)
if s != kernsrc:
bb.utils.mkdirhier(kernsrc)
--
2.2.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] pulseaudio: use stricter PACKAGES_DYNAMIC
* I don't see any usage for libpulse-* packages
* adding '-' resolves the issue when we have separate recipe for
pulseaudio-modules-droid which isn't built to satisfy RDEPENDS
with the same name, because generic pulseaudio recipe seems to
RPROVIDE it through PACKAGES_DYNAMIC
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/recipes-multimedia/pulseaudio/pulseaudio.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
index db144a9..99cad76 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
@@ -79,7 +79,7 @@ PACKAGES =+ libpulsecore libpulsecommon libpulse
libpulse-simple libpulse-mainl
#upgrade path:
RREPLACES_pulseaudio-server = libpulse-bin libpulse-conf
-PACKAGES_DYNAMIC += ^pulseaudio-lib.* ^pulseaudio-module.* ^libpulse-lib.*
^libpulse-module.*
+PACKAGES_DYNAMIC += ^pulseaudio-lib-.* ^pulseaudio-module-.*
FILES_libpulsecore = ${libdir}/libpulsecore*.so
FILES_libpulsecommon = ${libdir}/pulseaudio/libpulsecommon*.so
--
2.2.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] insane.bbclass: fix desktop
The desktop-file-utils-native lacks a space.
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
meta/classes/insane.bbclass |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 0b45374..143ec46 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -1112,7 +1112,7 @@ do_configure[postfuncs] += do_qa_configure
python () {
tests = d.getVar('ALL_QA', True).split()
if desktop in tests:
-d.appendVar(PACKAGE_DEPENDS, desktop-file-utils-native)
+d.appendVar(PACKAGE_DEPENDS, desktop-file-utils-native)
###
# Check various variables
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] guile: fixed installed-vs-shipped error
Fixed:
guile-2.0.11: guile: Files/directories were installed but not shipped
/usr/lib64/libguile-2.0*-gdb.scm [installed-vs-shipped]
This is because when there is no file in the directory:
for f in libguile-2.0*; do
[snip]
done
The f would be libguile-2.0* itself, make sure the libs are installed
firstly will fix the problem.
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
.../guile/files/libguile-Makefile.am-depends.patch | 39
meta/recipes-devtools/guile/guile_2.0.11.bb|1 +
2 files changed, 40 insertions(+)
create mode 100644
meta/recipes-devtools/guile/files/libguile-Makefile.am-depends.patch
diff --git
a/meta/recipes-devtools/guile/files/libguile-Makefile.am-depends.patch
b/meta/recipes-devtools/guile/files/libguile-Makefile.am-depends.patch
new file mode 100644
index 000..1045cbe
--- /dev/null
+++ b/meta/recipes-devtools/guile/files/libguile-Makefile.am-depends.patch
@@ -0,0 +1,39 @@
+From 9c4e120a7a87db34d22a50883a5a525170b480d7 Mon Sep 17 00:00:00 2001
+From: Robert Yang liezhi.y...@windriver.com
+Date: Tue, 6 Jan 2015 23:10:51 -0800
+Subject: [PATCH] libguile/Makefile.am: install-data-hook: depends on
+ install-libLTLIBRARIES
+
+It may install such a file:
+/usr/lib64/libguile-2.0*-gdb.scm
+
+This is because when there is no file in the directory:
+for f in libguile-2.0*; do
+[snip]
+done
+
+The f would be libguile-2.0* itself.
+
+Upstream-Status: Pending
+
+Signed-off-by: Robert Yang liezhi.y...@windriver.com
+---
+ libguile/Makefile.am |2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/libguile/Makefile.am b/libguile/Makefile.am
+index 281faac..fe0a3ba 100644
+--- a/libguile/Makefile.am
b/libguile/Makefile.am
+@@ -449,7 +449,7 @@ EXTRA_libguile_@GUILE_EFFECTIVE_VERSION@_la_SOURCES =
_scm.h \
+ install-exec-hook:
+ rm -f $(DESTDIR)$(bindir)/guile-snarf.awk
+
+-install-data-hook: libguile-2.0-gdb.scm
++install-data-hook: libguile-2.0-gdb.scm install-libLTLIBRARIES
+ @$(MKDIR_P) $(DESTDIR)$(libdir)
+ ## We want to install libguile-2.0-gdb.scm as SOMETHING-gdb.scm.
+ ## SOMETHING is the full name of the final library. We want to ignore
+--
+1.7.9.5
+
diff --git a/meta/recipes-devtools/guile/guile_2.0.11.bb
b/meta/recipes-devtools/guile/guile_2.0.11.bb
index f2c0759..f5388aa 100644
--- a/meta/recipes-devtools/guile/guile_2.0.11.bb
+++ b/meta/recipes-devtools/guile/guile_2.0.11.bb
@@ -21,6 +21,7 @@ SRC_URI = ${GNU_MIRROR}/guile/guile-${PV}.tar.xz \
file://arm_endianness.patch \
file://arm_aarch64.patch \
file://workaround-ice-ssa-corruption.patch \
+ file://libguile-Makefile.am-depends.patch \
# file://debian/0001-Change-guile-to-guile-X.Y-for-info-pages.patch
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [dizzy][PATCH] coreutils: Fix CVE-2014-9471
Fiedler Roman discovered that coreutils' parse_datetime() function
has some flaws that may be exploitable if the date(1), touch(1),
or potentially other programs, accept untrusted input for certain
parameters. While researching this issue, he discovered that it
was independently discovered by Bertrand Jacquin and reported at
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16872
$ touch '--date=TZ=123345 @1'
*** Error in `touch': free(): invalid pointer: 0x7fffd33e55e0 ***
Aborted
$ date '--date=TZ=123345 @1'
date[394]: segfault at 7fff2400 ip 7f6dd5b73404 sp 7fff27cce8f8
error 4 in libc-2.20.so[7f6dd5af7000+199000]
Segmentation fault
Signed-off-by: Maxin B. John maxin.j...@enea.com
---
.../coreutils/coreutils-8.22/date-tz-crash.patch | 43 ++
meta/recipes-core/coreutils/coreutils_8.22.bb | 1 +
2 files changed, 44 insertions(+)
create mode 100644
meta/recipes-core/coreutils/coreutils-8.22/date-tz-crash.patch
diff --git a/meta/recipes-core/coreutils/coreutils-8.22/date-tz-crash.patch
b/meta/recipes-core/coreutils/coreutils-8.22/date-tz-crash.patch
new file mode 100644
index 000..570e4fd
--- /dev/null
+++ b/meta/recipes-core/coreutils/coreutils-8.22/date-tz-crash.patch
@@ -0,0 +1,43 @@
+This was reported in http://bugs.gnu.org/16872
+from the coreutils command: date -d 'TZ='
+
+The infinite loop for this case was present since the
+initial TZ= parsing support in commit de95bdc2 29-10-2004.
+This was changed to a crash or heap corruption depending
+on the platform with commit 2e3e4195 18-01-2010.
+
+* lib/parse-datetime.y (parse_datetime): Break out of the
+TZ= parsing loop once the second significant is found.
+Also skip over any subsequent whitespace to be consistent
+with the non TZ= case.
+
+Fixes: CVE-2014-9471
+
+Upstream-Status: backport
+
+Signed-off-by: Maxin B. John maxin.j...@enea.com
+Signed-off-by: Pádraig Brady p...@draigbrady.com
+---
+diff -Naur coreutils-8.22-origin/lib/parse-datetime.y
coreutils-8.22/lib/parse-datetime.y
+--- coreutils-8.22-origin/lib/parse-datetime.y 2013-12-04 15:53:33.0
+0100
coreutils-8.22/lib/parse-datetime.y2015-01-05 17:11:16.754358184
+0100
+@@ -1303,8 +1303,6 @@
+ char tz1buf[TZBUFSIZE];
+ bool large_tz = TZBUFSIZE tzsize;
+ bool setenv_ok;
+-/* Free tz0, in case this is the 2nd or subsequent time through.
*/
+-free (tz0);
+ tz0 = get_tz (tz0buf);
+ z = tz1 = large_tz ? xmalloc (tzsize) : tz1buf;
+ for (s = tzbase; *s != ''; s++)
+@@ -1317,6 +1315,10 @@
+ goto fail;
+ tz_was_altered = true;
+ p = s + 1;
++while (c = *p, c_isspace (c))
++ p++;
++
++break;
+ }
+ }
+
diff --git a/meta/recipes-core/coreutils/coreutils_8.22.bb
b/meta/recipes-core/coreutils/coreutils_8.22.bb
index f85baca..4a1aee6 100644
--- a/meta/recipes-core/coreutils/coreutils_8.22.bb
+++ b/meta/recipes-core/coreutils/coreutils_8.22.bb
@@ -17,6 +17,7 @@ SRC_URI = ${GNU_MIRROR}/coreutils/${BP}.tar.xz \
file://dummy_help2man.patch \
file://fix-for-dummy-man-usage.patch \
file://fix-selinux-flask.patch \
+ file://date-tz-crash.patch \
SRC_URI[md5sum] = 8fb0ae2267aa6e728958adc38f8163a2
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] rm_work: Fix RM_WORK_EXCLUDE for image/sdk recipes
A previous change meant image/sdk recipes were removed unconditionally
by the class and did not respect RM_WORK_EXCLUDE. This fixes that
problem.
[YOCTO #7114]
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
diff --git a/meta/classes/rm_work.bbclass b/meta/classes/rm_work.bbclass
index 7b1ec17..e68d02a 100644
--- a/meta/classes/rm_work.bbclass
+++ b/meta/classes/rm_work.bbclass
@@ -110,3 +110,11 @@ rm_work_rootfs () {
}
rm_work_rootfs[cleandirs] = ${WORKDIR}/rootfs
+python () {
+# If the recipe name is in the RM_WORK_EXCLUDE, skip the recipe.
+excludes = (d.getVar(RM_WORK_EXCLUDE, True) or ).split()
+pn = d.getVar(PN, True)
+if pn in excludes:
+d.delVarFlag('rm_work_rootfs', 'cleandirs')
+d.delVarFlag('rm_work_populatesdk', 'cleandirs')
+}
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] insane.bbclass: Added QA test for expanded ${D}
On 7 January 2015 at 22:02, Randy Witt randy.e.w...@linux.intel.com wrote:
Would it be simpler to do bbvar = d.getVar(var + _ + pak, False) so
you don't get the expanded value, and then just check for ${D}? I suppose
it would save one extra variable and a couple of expansions.
Alejandro answered this point in the original thread:
using the existing package variable handling infrastructure within the
class, ends up expanding the variables before being able to check them ,
using getVar('FOO', False) is useless in this case, any suggestions?
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] module.bbclass: Add KERNEL_SRC in EXTRA_OEMAKE
On Wed, 2015-01-07 at 13:45 -0500, Bruce Ashfield wrote: On Wed, Jan 7, 2015 at 12:25 PM, Otavio Salvador ota...@ossystems.com.br wrote: When the sstate hash changes for do_configure task, the do_configure default implementation triggers the 'clean' to be run. For it to succeed we need to have KERNEL_SRC defined in EXTRA_OEMAKE. Fixes following error: I wanted to reproduce this locally, since I've never seen the problem myself. What's the best way to trigger the sstate hash change ? bitbake virtual/kernel -c configure -f Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4] add variable INSTALL_ALL to install all packages in recipes
This tells me what the change does. What it doesn't say is why we need this? Its a fairly invasive set of changes but I don't see the usecase... Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Bug reporting and good bug reports
On Jan 7, 2015, at 1:25 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: I was informed on irc yesterday that bug reports are hard and that debugging via irc is easier. I think I need to remind people why good bug reports are important and how they do actually help immensely. I do actually believe that not everything has to have bug report. If you mention an issue, someone says hey, I know how to fix that and sends a patch out, a bug report is wasted overhead IMO. I know some programme managers who disagree strongly with me and would suggest *every* bugfix commit should have a defect tracking item. We're not going there I understand the idea, its not practical. That said, if its not immediately clear what the problem is, it should become a bug report. Why? Firstly, the random selection of people on irc at the time probably aren't the right people to fix it. Telling those people to read 48 hours of irc log for the details is disrespectful of their time. It also happens that the first people referred to a bug may not be the person who actually can fix it. If someone else needs to come to a bug, having a summary of the issue, the salient facts and the current status is immensley useful for handover. As a case in point, I tried to debug a qt4 build failure yesterday for which there is no bug report. I lost hours building the wrong things, experimenting to try and find the reproducer steps and generally chasing my tail, losing the autobuilder log of the failure, the name of the qt4 recipe that was failing (which task was it again?) and so on. I do now have a set of reproducer steps, its quite simple: MACHINE=imx53qsb bitbake virtual/kernel MACHINE=imx53qsb bitbake virtual/kernel -c clean MACHINE=imx53qsb bitbake qt4-x11-free I also have a patch. Where should I share them? How do I ensure everyone with an interest in this defect actually gets the patch? Sure I can create email and send to the people who I think need to know. The bugzilla lets interested parties add themselves to bugs though. I should also note that QA actually go through bugs in the bugzilla, including closed ones, looking for test cases. We're not great at this yet but it does happen. If there is a well documented test case like that above, we might write an automated QA test for it. Having it documented is therefore a good thing. I do appreciate writing a bug report is hard, especially if you don't know where the problem is, or how to reproduce it exactly. It takes time and effort. You can however document what you know and discussion can happen in a common place to figure out how to reproduce it. I do except the submitters to fully understand the bug, if they did they'd probably write a patch instead. So fair warning, I am going to start ignoring things on irc and ask for bug numbers in future, assuming something isn't a 5 minute fix with an immediate patch. I will back and encourage anyone else doing this too. What about developer mailing lists ?. isn’t it also a way to report problems via emails after all we use emails for patch work flow. Not all people working with OE-Core e.g. might be following yocto bugzilla -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Further kernel build process changes?
On Wed, 2015-01-07 at 10:33 -0800, Darren Hart wrote:
On 1/7/15, 5:22 AM, Bruce Ashfield bruce.ashfi...@windriver.com wrote:
On 2015-01-07 7:26 AM, Richard Purdie wrote:
External module builds do work in this configuration *if* you pass in
the correct options e.g.:
make -C work-shared/MACHINE/kernel-source
O=work-shared/MACHINE/kernel-build M=${S}
I've put together a quick proof of concept of this below.
I was concerned about how this would impact hello-mod and recipes modeled
after it, however, in reviewing the patch below, it looks to have this
covered. I¹ll verify this just as soon as my workstation is available
(it¹s ³busy² updatingŠ sigh).
I have not tested that yet, however it is something we need to do, if it
has issues, I think they should be solvable.
A couple of first pass questions belowŠ prior to applying and testing
myself...
diff --git a/meta/classes/kernel-module-split.bbclass
b/meta/classes/kernel-module-split.bbclass
index 9a95b72..2d43b51 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -70,7 +70,7 @@ python split_kernel_module_packages () {
m = kerverrexp.match(kernelver)
if m:
kernelver_stripped = m.group(1)
-staging_kernel_dir = d.getVar(STAGING_KERNEL_DIR, True)
+staging_kernel_dir = d.getVar(STAGING_KERNEL_BUILDDIR, True)
system_map_file = %s/boot/System.map-%s % (dvar, kernelver)
if not os.path.exists(system_map_file):
system_map_file = %s/System.map-%s %
(staging_kernel_dir, kernelver)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 5cabc2c..b1a1ccf 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -249,6 +249,10 @@ kernel_do_install() {
cp .config $kerneldir/
mkdir -p $kerneldir/include/config
cp include/config/kernel.release
$kerneldir/include/config/kernel.release
+ if [ -e include/linux/version.h ]; then
+ mkdir -p $kerneldir/include/linux
+ cp include/linux/version.h $kerneldir/include/linux/version.h
+ fi
I know this bit someone with the recent changes, let¹s make sure we add a
comment as to why this is required so we don¹t have to dig it out of the
archives in a year when we¹re doing another round of fixes in this area.
I know Bruce is not convinced about this part yet and talked with Otavio
a little. We could do something like this:
diff --git a/meta/classes/module-base.bbclass b/meta/classes/module-base.bbclass
index c34eee7..58ec3f4 100644
--- a/meta/classes/module-base.bbclass
+++ b/meta/classes/module-base.bbclass
@@ -11,10 +11,12 @@ PACKAGE_ARCH = ${MACHINE_ARCH}
do_configure[depends] += virtual/kernel:do_install
+EXTRA_KERNELSRC_TARGETS =
+
# Function to ensure the kernel scripts are created. Expected to
# be called before do_compile. See module.bbclass for an exmaple.
do_make_scripts() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
make CC=${KERNEL_CC} LD=${KERNEL_LD} AR=${KERNEL_AR} \
- -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR} scripts
+ -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR}
scripts ${EXTRA_KERNELSRC_TARGETS}
}
and then Otavio could add EXTRA_KERNELSRC_TARGETS +=
linux/kernel/version.h to the two problematic recipes.
# As of Linux kernel version 3.0.1, the clean target removes
# arch/powerpc/lib/crtsavres.o which is present in
@@ -268,6 +272,45 @@ kernel_do_install() {
}
do_install[prefuncs] += package_get_auto_pr
+addtask do_shared_workdir after do_compile before do_install
+
+do_shared_workdir () {
+ cd ${B}
+
+ kerneldir=${STAGING_KERNEL_BUILDDIR}
+ install -d $kerneldir
+
+ #
+ # Store the kernel version in sysroots for module-base.bbclass
+ #
+
OK, how does this impact the dependency on do_installŠ As we¹re doing
stuff for building modules here, can that now depend on do_shared_workdir?
Yes, it can and the contents of do_install can be further pruned.
+ echo ${KERNEL_VERSION} $kerneldir/kernel-abiversion
+
+ # Copy files required for module builds
+ cp System.map $kerneldir/System.map-${KERNEL_VERSION}
+ cp Module.symvers $kerneldir/
+ cp .config $kerneldir/
+ mkdir -p $kerneldir/include/config
+ cp include/config/kernel.release
$kerneldir/include/config/kernel.release
+
+ # As of Linux kernel version 3.0.1, the clean target removes
+ # arch/powerpc/lib/crtsavres.o which is present in
+ # KBUILD_LDFLAGS_MODULE, making it required to build external modules.
+ if [ ${ARCH} = powerpc ]; then
+ mkdir -p $kerneldir/arch/powerpc/lib/
+ cp arch/powerpc/lib/crtsavres.o
$kerneldir/arch/powerpc/lib/crtsavres.o
+ fi
+
+ mkdir -p $kerneldir/include/generated/
+ cp -fR include/generated/* $kerneldir/include/generated/
+
+ if [ -d
[OE-core] [PATCH 1/4] file: upgrade to 5.22
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
.../file/{file_5.21.bb = file_5.22.bb}|4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-devtools/file/{file_5.21.bb = file_5.22.bb} (86%)
diff --git a/meta/recipes-devtools/file/file_5.21.bb
b/meta/recipes-devtools/file/file_5.22.bb
similarity index 86%
rename from meta/recipes-devtools/file/file_5.21.bb
rename to meta/recipes-devtools/file/file_5.22.bb
index 702ea87..9c6bb38 100644
--- a/meta/recipes-devtools/file/file_5.21.bb
+++ b/meta/recipes-devtools/file/file_5.22.bb
@@ -15,8 +15,8 @@ SRC_URI = ftp://ftp.astron.com/pub/file/file-${PV}.tar.gz \
file://debian-742262.patch \
-SRC_URI[md5sum] = 549fe96e09041eabece9de2bb28ef923
-SRC_URI[sha256sum] =
1a48741d3923c4cc73267109b8a396c0ce3aebe004181f3efb1b0a228d230bb6
+SRC_URI[md5sum] = 8fb13e5259fe447e02c4a37bc7225add
+SRC_URI[sha256sum] =
c4e3a8e44cb888c5e4b476e738503e37fb9de3b25a38c143e214bfc12109fc0b
inherit autotools
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/4] libtool: upgrade to 2.4.4
* Upgrade:
- libtool-native
- libtool-cross
- nativesdk-libtool
- libtool
* Remove 2 patches:
- respect-fstack-protector.patch: already in the new source.
- avoid_absolute_paths_for_general_utils.patch: no general.m4sh any
more.
* Update other patches
* The LIC_FILES_CHKSUM is changed because of the indent, the contents
are the same.
* The libtool config files are put in libtool/build-aux now, it was
libtool/config in the past.
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
.../{libtool-2.4.2.inc = libtool-2.4.4.inc} | 16 +--
...btool-cross_2.4.2.bb = libtool-cross_2.4.4.bb} | 19 ++-
...ool-native_2.4.2.bb = libtool-native_2.4.4.bb} |1 -
.../avoid_absolute_paths_for_general_utils.patch | 39 ---
.../libtool/libtool/dont-depend-on-help2man.patch | 32 +++---
.../libtool/libtool/fix-final-rpath.patch | 22 ++--
.../libtool/libtool/fix-resolve-lt-sysroot.patch | 15 +--
.../libtool/libtool/fix-rpath.patch|8 +-
.../libtool/libtool/fixinstall.patch | 35 +++---
.../libtool/libtool/norm-rpath.patch |8 +-
meta/recipes-devtools/libtool/libtool/prefix.patch | 121 +---
.../libtool/libtool/rename-with-sysroot.patch | 68 +--
.../libtool/libtool/respect-fstack-protector.patch | 53 -
.../libtool/libtool/trailingslash.patch| 11 +-
.../libtool/libtool/use-sysroot-in-libpath.patch | 12 +-
.../libtool/{libtool_2.4.2.bb = libtool_2.4.4.bb} |4 +-
...libtool_2.4.2.bb = nativesdk-libtool_2.4.4.bb} |2 -
17 files changed, 182 insertions(+), 284 deletions(-)
rename meta/recipes-devtools/libtool/{libtool-2.4.2.inc = libtool-2.4.4.inc}
(77%)
rename meta/recipes-devtools/libtool/{libtool-cross_2.4.2.bb =
libtool-cross_2.4.4.bb} (57%)
rename meta/recipes-devtools/libtool/{libtool-native_2.4.2.bb =
libtool-native_2.4.4.bb} (96%)
delete mode 100644
meta/recipes-devtools/libtool/libtool/avoid_absolute_paths_for_general_utils.patch
delete mode 100644
meta/recipes-devtools/libtool/libtool/respect-fstack-protector.patch
rename meta/recipes-devtools/libtool/{libtool_2.4.2.bb = libtool_2.4.4.bb}
(91%)
rename meta/recipes-devtools/libtool/{nativesdk-libtool_2.4.2.bb =
nativesdk-libtool_2.4.4.bb} (97%)
diff --git a/meta/recipes-devtools/libtool/libtool-2.4.2.inc
b/meta/recipes-devtools/libtool/libtool-2.4.4.inc
similarity index 77%
rename from meta/recipes-devtools/libtool/libtool-2.4.2.inc
rename to meta/recipes-devtools/libtool/libtool-2.4.4.inc
index 0f1964b..643fd52 100644
--- a/meta/recipes-devtools/libtool/libtool-2.4.2.inc
+++ b/meta/recipes-devtools/libtool/libtool-2.4.4.inc
@@ -5,31 +5,27 @@ Libtool hides the complexity of generating special library
types \
HOMEPAGE = http://www.gnu.org/software/libtool/libtool.html;
SECTION = devel
LICENSE = GPLv2 LGPLv2.1
-LIC_FILES_CHKSUM = file://COPYING;md5=751419260aa954499f7abaabaa882bbe \
-file://libltdl/COPYING.LIB;md5=e3eda01d9815f8d24aae2dbd89b68b06
-
-INC_PR = r6
+LIC_FILES_CHKSUM = file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
+file://libltdl/COPYING.LIB;md5=4fbd65380cdd255951079008b364516c
SRC_URI = ${GNU_MIRROR}/libtool/libtool-${PV}.tar.gz \
file://trailingslash.patch \
file://rename-with-sysroot.patch \
file://use-sysroot-in-libpath.patch \
file://fix-final-rpath.patch \
- file://avoid_absolute_paths_for_general_utils.patch \
file://fix-rpath.patch \
- file://respect-fstack-protector.patch \
file://norm-rpath.patch \
file://dont-depend-on-help2man.patch \
file://fix-resolve-lt-sysroot.patch \
-SRC_URI[md5sum] = d2f3b7d4627e69e13514a40e72a24d50
-SRC_URI[sha256sum] =
b38de44862a987293cd3d8dfae1c409d514b6c4e794ebc93648febf9afc38918
+SRC_URI[md5sum] = 353ed373fd3c6d7e47a1f4a8728d966b
+SRC_URI[sha256sum] =
159d4e20c201f929e3562536d3ae6b5e605403fa4bb4e72ef197a4e162c3fedf
do_compile_prepend () {
# Sometimes this file doesn't get rebuilt, force the issue
- rm -f ${S}/libltdl/config/ltmain.sh
- make libltdl/config/ltmain.sh
+ rm -f ${S}/build-aux/ltmain.sh
+ make build-aux/ltmain.sh
./config.status
}
diff --git a/meta/recipes-devtools/libtool/libtool-cross_2.4.2.bb
b/meta/recipes-devtools/libtool/libtool-cross_2.4.4.bb
similarity index 57%
rename from meta/recipes-devtools/libtool/libtool-cross_2.4.2.bb
rename to meta/recipes-devtools/libtool/libtool-cross_2.4.4.bb
index 34aae0b..72426e4 100644
--- a/meta/recipes-devtools/libtool/libtool-cross_2.4.2.bb
+++ b/meta/recipes-devtools/libtool/libtool-cross_2.4.4.bb
@@ -1,6 +1,5 @@
require libtool-${PV}.inc
-PR = ${INC_PR}.1
PACKAGES =
SRC_URI += file://prefix.patch
SRC_URI += file://fixinstall.patch
@@ -19,16 +18,16 @@ do_install () {
install -m 0755 ${HOST_SYS}-libtool
[OE-core] [PATCH 4/4] opkg: fix error for new libtoolize
Fixed:
libtoolize: error: AC_CONFIG_MACRO_DIRS([m4]) conflicts with
ACLOCAL_AMFLAGS=-I shave.
They are already included by configure.ac:
AC_CONFIG_MACRO_DIR([m4])
AC_CONFIG_MACRO_DIR([shave])
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
.../opkg/remove-ACLOCAL_AMFLAGS-I-shave-I-m4.patch | 32
meta/recipes-devtools/opkg/opkg_0.2.4.bb |1 +
2 files changed, 33 insertions(+)
create mode 100644
meta/recipes-devtools/opkg/opkg/remove-ACLOCAL_AMFLAGS-I-shave-I-m4.patch
diff --git
a/meta/recipes-devtools/opkg/opkg/remove-ACLOCAL_AMFLAGS-I-shave-I-m4.patch
b/meta/recipes-devtools/opkg/opkg/remove-ACLOCAL_AMFLAGS-I-shave-I-m4.patch
new file mode 100644
index 000..8bde02a
--- /dev/null
+++ b/meta/recipes-devtools/opkg/opkg/remove-ACLOCAL_AMFLAGS-I-shave-I-m4.patch
@@ -0,0 +1,32 @@
+From d480d837ff57e855d1cf0b63054d6b1ad7aaf2ee Mon Sep 17 00:00:00 2001
+From: Robert Yang liezhi.y...@windriver.com
+Date: Tue, 6 Jan 2015 17:54:43 -0800
+Subject: [PATCH] Makefile.am: remove ACLOCAL_AMFLAGS = -I shave -I m4
+
+Fixed:
+libtoolize: error: AC_CONFIG_MACRO_DIRS([m4]) conflicts with
ACLOCAL_AMFLAGS=-I shave.
+
+They are already included by configure.ac:
+AC_CONFIG_MACRO_DIR([m4])
+AC_CONFIG_MACRO_DIR([shave])
+
+Upstream-Status: Pending
+
+Signed-off-by: Robert Yang liezhi.y...@windriver.com
+---
+ Makefile.am |2 --
+ 1 file changed, 2 deletions(-)
+
+diff --git a/Makefile.am b/Makefile.am
+index 8baa62c..6679f77 100644
+--- a/Makefile.am
b/Makefile.am
+@@ -1,5 +1,3 @@
+-ACLOCAL_AMFLAGS = -I shave -I m4
+-
+ SUBDIRS = libbb libopkg src tests utils man
+
+
+--
+1.7.9.5
+
diff --git a/meta/recipes-devtools/opkg/opkg_0.2.4.bb
b/meta/recipes-devtools/opkg/opkg_0.2.4.bb
index 2cca63c..0d08bf9 100644
--- a/meta/recipes-devtools/opkg/opkg_0.2.4.bb
+++ b/meta/recipes-devtools/opkg/opkg_0.2.4.bb
@@ -5,6 +5,7 @@ SRC_URI =
http://downloads.yoctoproject.org/releases/${BPN}/${BPN}-${PV}.tar.gz
file://add-exclude.patch \
file://opkg-configure.service \
file://libopkg-opkg_remove.c-avoid-remove-pkg-repeatly-with.patch \
+ file://remove-ACLOCAL_AMFLAGS-I-shave-I-m4.patch \
S = ${WORKDIR}/${BPN}-${PV}
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/4] Upgrade libtool, git and file
Tested:
$ bitbake core-image-minimal core-image-sato meta-toolchain adt-installer
meta-ide-support world core-image-sato-sdk
// Robert
The following changes since commit 95f7d2c8fd5ee6ad0b7d202906073066f35a268d:
insane.bbclass: fix desktop (2015-01-07 14:52:48 +)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib rbt/pu
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/pu
Robert Yang (4):
file: upgrade to 5.22
git: upgrade to 2.2.1
libtool: upgrade to 2.4.4
opkg: fix error for new libtoolize
.../file/{file_5.21.bb = file_5.22.bb}|4 +-
.../git/{git_2.2.0.bb = git_2.2.1.bb} |4 +-
.../{libtool-2.4.2.inc = libtool-2.4.4.inc} | 16 +--
...btool-cross_2.4.2.bb = libtool-cross_2.4.4.bb} | 19 ++-
...ool-native_2.4.2.bb = libtool-native_2.4.4.bb} |1 -
.../avoid_absolute_paths_for_general_utils.patch | 39 ---
.../libtool/libtool/dont-depend-on-help2man.patch | 32 +++---
.../libtool/libtool/fix-final-rpath.patch | 22 ++--
.../libtool/libtool/fix-resolve-lt-sysroot.patch | 15 +--
.../libtool/libtool/fix-rpath.patch|8 +-
.../libtool/libtool/fixinstall.patch | 35 +++---
.../libtool/libtool/norm-rpath.patch |8 +-
meta/recipes-devtools/libtool/libtool/prefix.patch | 121 +---
.../libtool/libtool/rename-with-sysroot.patch | 68 +--
.../libtool/libtool/respect-fstack-protector.patch | 53 -
.../libtool/libtool/trailingslash.patch| 11 +-
.../libtool/libtool/use-sysroot-in-libpath.patch | 12 +-
.../libtool/{libtool_2.4.2.bb = libtool_2.4.4.bb} |4 +-
...libtool_2.4.2.bb = nativesdk-libtool_2.4.4.bb} |2 -
.../opkg/remove-ACLOCAL_AMFLAGS-I-shave-I-m4.patch | 32 ++
meta/recipes-devtools/opkg/opkg_0.2.4.bb |1 +
21 files changed, 219 insertions(+), 288 deletions(-)
rename meta/recipes-devtools/file/{file_5.21.bb = file_5.22.bb} (86%)
rename meta/recipes-devtools/git/{git_2.2.0.bb = git_2.2.1.bb} (61%)
rename meta/recipes-devtools/libtool/{libtool-2.4.2.inc = libtool-2.4.4.inc}
(77%)
rename meta/recipes-devtools/libtool/{libtool-cross_2.4.2.bb =
libtool-cross_2.4.4.bb} (57%)
rename meta/recipes-devtools/libtool/{libtool-native_2.4.2.bb =
libtool-native_2.4.4.bb} (96%)
delete mode 100644
meta/recipes-devtools/libtool/libtool/avoid_absolute_paths_for_general_utils.patch
delete mode 100644
meta/recipes-devtools/libtool/libtool/respect-fstack-protector.patch
rename meta/recipes-devtools/libtool/{libtool_2.4.2.bb = libtool_2.4.4.bb}
(91%)
rename meta/recipes-devtools/libtool/{nativesdk-libtool_2.4.2.bb =
nativesdk-libtool_2.4.4.bb} (97%)
create mode 100644
meta/recipes-devtools/opkg/opkg/remove-ACLOCAL_AMFLAGS-I-shave-I-m4.patch
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] glib-2.0: add HOMEPAGE
The following changes since commit 95f7d2c8fd5ee6ad0b7d202906073066f35a268d: insane.bbclass: fix desktop (2015-01-07 14:52:48 +) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib rbt/glib http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/glib Robert Yang (1): glib-2.0: add HOMEPAGE meta/recipes-core/glib-2.0/glib.inc |2 ++ 1 file changed, 2 insertions(+) -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] glib-2.0: add HOMEPAGE
It doesn't have a homepage except gtk.org, use its reference manual page as the homepage, which we can easily know whether it is a stable version or not. Signed-off-by: Robert Yang liezhi.y...@windriver.com --- meta/recipes-core/glib-2.0/glib.inc |2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/recipes-core/glib-2.0/glib.inc b/meta/recipes-core/glib-2.0/glib.inc index 2d81afc..072f790 100644 --- a/meta/recipes-core/glib-2.0/glib.inc +++ b/meta/recipes-core/glib-2.0/glib.inc @@ -1,5 +1,7 @@ SUMMARY = A general-purpose utility library DESCRIPTION = GLib is a general-purpose utility library, which provides many useful data types, macros, type conversions, string utilities, file utilities, a main loop abstraction, and so on. +HOMEPAGE = https://developer.gnome.org/glib/; + # pcre is under BSD; # docs/reference/COPYING is with a 'public domai'-like license! LICENSE = LGPLv2+ BSD PD -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] What is expected of a kernel recipe nowadays?
On Wed, Jan 07, 2015 at 10:48:50AM -0500, Bruce Ashfield wrote: On Wed, Jan 7, 2015 at 5:07 AM, Martin Jansa martin.ja...@gmail.com wrote: On Tue, Jan 06, 2015 at 11:08:53AM +, Burton, Ross wrote: On 6 January 2015 at 08:57, Martin Jansa martin.ja...@gmail.com wrote: 2) do_configure failing: ERROR: Function failed: do_configure (log file is located at /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/work/mako-webos-linux-gnueabi/linux-lg-mako/3.4.0+gitrAUTOINC+38bdbfe224-r0/temp/log.do_configure.17498) ERROR: Logfile of failure stored in: /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/work/mako-webos-linux-gnueabi/linux-lg-mako/3.4.0+gitrAUTOINC+38bdbfe224-r0/temp/log.do_configure.17498 Log data follows: | DEBUG: Executing python function sysroot_cleansstate | DEBUG: Python function sysroot_cleansstate finished | DEBUG: Executing shell function do_configure | NOTE: make oldconfig | make: *** No rule to make target `oldconfig'. Stop. | ERROR: oe_runmake failed | WARNING: exit code 1 from a shell command. | ERROR: Function failed: do_configure (log file is located at /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/work/mako-webos-linux-gnueabi/linux-lg-mako/3.4.0+gitrAUTOINC+38bdbfe224-r0/temp/log.do_configure.17498) NOTE: recipe linux-lg-mako-3.4.0+gitrAUTOINC+38bdbfe224-r0: task do_configure: Failed ERROR: Task 491 (/home/jenkins/workspace/luneos-unstable/webos-ports/meta-smartphone/meta-lg/recipes-kernel/linux/ linux-lg-mako_git.bb, do_configure) failed with exit code '1' I'll Me Too here, often hitting this on rebuilds: DEBUG: Executing shell function do_configure NOTE: make -C /data/poky-master/tmp/sysroots/qemuarm64/usr/src/kernel O=/data/poky-master/tmp/work/qemuarm64-poky-linux/linux-yocto/3.14.24+gitAUTOINC+a227f20eff_902f34d361-r0/linux-qemuarm64-standard-build oldnoconfig make: Entering directory `/data/poky-master/tmp/sysroots/qemuarm64/usr/src/kernel' make: *** No rule to make target `oldnoconfig'. Stop. make: Leaving directory `/data/poky-master/tmp/sysroots/qemuarm64/usr/src/kernel' ERROR: Task 77 (/home/ross/Yocto/poky/meta/recipes-kernel/linux/linux-yocto_3.14.bb, do_configure) failed with exit code '1' last world build revealed new kind of error: both qemux86 and qemux86-64 failed like this ERROR: Function failed: do_kernel_configme (log file is located at /home/jenkins/oe/world/shr-core/tmp-glibc/work/qemux86_64-oe-linux/linux-yocto/3.17.6+gitAUTOINC+b81030f9ec_5ff54d8fbf-r0/temp/log.do_kernel_configme.6974) ERROR: Logfile of failure stored in: /home/jenkins/oe/world/shr-core/tmp-glibc/work/qemux86_64-oe-linux/linux-yocto/3.17.6+gitAUTOINC+b81030f9ec_5ff54d8fbf-r0/temp/log.do_kernel_configme.6974 Log data follows: | DEBUG: Executing shell function do_kernel_configme | NOTE: kernel configme | [INFO] Configuring target/machine combo: standard/qemux86-64 | [INFO] collecting configs in .meta/meta-series | ERROR: could not sanitize configuration fragments |errors are logged in /home/jenkins/oe/world/shr-core/tmp-glibc/sysroots/qemux86-64/usr/src/kernel/.meta/cfg/standard/common-pc-64/config.log | WARNING: exit code 1 from a shell command. | ERROR: Function failed: do_kernel_configme (log file is located at /home/jenkins/oe/world/shr-core/tmp-glibc/work/qemux86_64-oe-linux/linux-yocto/3.17.6+gitAUTOINC+b81030f9ec_5ff54d8fbf-r0/temp/log.do_kernel_configme.6974) NOTE: recipe linux-yocto-3.17.6+gitAUTOINC+b81030f9ec_5ff54d8fbf-r0: task do_kernel_configme: Failed I spoke to soon before. Where can I find the config that triggered this ? I just built the latest master and my fragments/patches were all properly applied in the default build: It's random, the same oe-core revision first built it fine, then it failed, then it again built fine, see: http://www.openembedded.org/wiki/Bitbake_World_Status the successful build isn't there yet, but rebuilding from the same sstate finished kernel fine - DEBUG: Executing shell function do_kernel_configme NOTE: kernel configme [INFO] Configuring target/machine combo: standard/qemux86-64 [INFO] collecting configs in .meta/meta-series [INFO] Pre-processed cfg file qemux86-64-standard-config-3.17.6 created. [INFO] processing of raw cfg data completed. Configuration stored in /home/bruce/oe/build/tmp/work/qemux86_64-poky-linux/linux-yocto/3.17.6+gitAUTOINC+b81030f9ec_5ff54d8fbf-r0/linux-qemux86_64-standard-build/.config To build with this kernel configuration, ensure a suitable toolchain is in your path for x86_64, note its common command prefix, and do: make
[OE-core] [PATCH v2 2/2] combo-layer: support updating up to arbitrary commit
Support defining the top commit up to which to update. In other words,
this makes it possible to update up to certain point other than the
branch head. The update point (git commitish) is given on the command
line by appending the component name(s) with a colon and the commitish,
e.g.
$ combo-layer update my_component:sha1
Only the update action supports this.
Signed-off-by: Markus Lehtonen markus.lehto...@linux.intel.com
---
scripts/combo-layer | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/scripts/combo-layer b/scripts/combo-layer
index 37d1f47..851003d 100755
--- a/scripts/combo-layer
+++ b/scripts/combo-layer
@@ -26,6 +26,7 @@ import logging
import subprocess
import ConfigParser
import re
+from collections import OrderedDict
__version__ = 0.2.1
@@ -347,7 +348,13 @@ def action_update(conf, args):
generate the patch list
apply the generated patches
-repos = get_repos(conf, args[1:])
+components = [arg.split(':')[0] for arg in args[1:]]
+revisions = []
+for arg in args[1:]:
+revision= arg.split(':', 1)[1] if ':' in arg else None
+revisions.append(revision)
+# Map commitishes to repos
+repos = OrderedDict(zip(get_repos(conf, components), revisions))
# make sure combo repo is clean
check_repo_clean(os.getcwd())
@@ -361,9 +368,9 @@ def action_update(conf, args):
if conf.nopull:
logger.info(Skipping pull (-n))
else:
-action_pull(conf, args)
+action_pull(conf, ['arg0'] + components)
-for name in repos:
+for name, revision in repos.iteritems():
repo = conf.repos[name]
ldir = repo['local_repo_dir']
dest_dir = repo['dest_dir']
@@ -372,18 +379,21 @@ def action_update(conf, args):
# Step 2: generate the patch list and store to patch dir
logger.info(Generating patches from %s... % name)
+top_revision = revision or branch
+if not check_rev_branch(name, ldir, top_revision, branch):
+sys.exit(1)
if dest_dir != .:
prefix = --src-prefix=a/%s/ --dst-prefix=b/%s/ % (dest_dir,
dest_dir)
else:
prefix =
if repo['last_revision'] == :
logger.info(Warning: last_revision of component %s is not set,
starting from the first commit % name)
-patch_cmd_range = --root %s % branch
-rev_cmd_range = branch
+patch_cmd_range = --root %s % top_revision
+rev_cmd_range = top_revision
else:
if not check_rev_branch(name, ldir, repo['last_revision'], branch):
sys.exit(1)
-patch_cmd_range = %s..%s % (repo['last_revision'], branch)
+patch_cmd_range = %s..%s % (repo['last_revision'], top_revision)
rev_cmd_range = patch_cmd_range
file_filter = repo.get('file_filter',)
--
1.8.4.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] summarizing how to create new core images from existing ones [pt 1]
for purposes of tutorial, i want to clarify the two ways to create new core images and maybe submit a couple cleanups later (looking at all the core-image* recipe files under openembedded). first, there's just requireing an existing core-image recipe file and adding some mods. as an example, core-image-minimal-dev.bb consists trivially of just: require core-image-minimal.bb DESCRIPTION = A small image just capable of allowing a device to boot and is suitable for development work. IMAGE_FEATURES += dev-pkgs as i read it, using this technique, the primary variables you'd typically set for the new core image recipe (and, really, the only major ones i've seen) would be: * DESCRIPTION = blah blah * IMAGE_FEATURES += additional image features * IMAGE_INSTALL += additional packages in addition to those canonical settings, i can see some new recipes that will simply set specific variables, like this in core-image-sato-sdk.bb: QT4PKG = qt4-pkgs QT4PKG_mips64 = beyond that, am i missing anything that might show up in a new core image recipe file defined this way? the only curiosity is setting LICENSE in, say, core-image-rt.sdk.bb: require recipes-core/images/core-image-minimal.bb ... snip ... LICENSE = MIT given that the underlying core-image-minimal.bb already sets that LICENSE variable: LICENSE = MIT i'm assuming that variable setting in the new recipe file is superfluous, yes? the new core image recipe file will strictly inherit the underlying license, will it not? and is there any possibility that a new core image recipe file might *redefine* the license value of the underlying required file, perhaps to something more restrictive? i think that's it for part 1 ... rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-commits] Richard Tollerton : font-util: Fix incorrect PKG_CONFIG_PATH
On Fri, Dec 19, 2014 at 06:08:41PM +, g...@git.openembedded.org wrote:
Module: openembedded-core.git
Branch: master
Commit: 89a29a3ad0742cd713e739d3d460be7711966679
URL:
http://git.openembedded.org/?p=openembedded-core.gita=commit;h=89a29a3ad0742cd713e739d3d460be7711966679
Author: Richard Tollerton rich.toller...@ni.com
Date: Fri Dec 12 13:34:00 2014 -0600
font-util: Fix incorrect PKG_CONFIG_PATH
PKG_CONFIG_PATH always defaults to /usr/lib/pkgconfig, and the host
/usr/lib/pkgconfig is always checked as a fallback; however,
PKG_CONFIG_PATH is currently (incorrectly) set to /usr/lib/pkg-config in
the sysroot, which doesn't exist. On host distros where the font
encoding maps are stored under a different path than OE, this will break
font builds, because ucs2any will attempt to read the sysroot's encoding
maps with the host paths.
^ Is this description of what the patch is supposed to fix or expected
side-effect of this change?
Because all font recipes and meta-oe are failing since this change with
errors like this:
/home/jenkins/oe/world/shr-core/tmp-glibc/sysroots/x86_64-linux/usr/bin/ucs2any:
Can't read mapping file
'/home/jenkins/oe/world/shr-core/tmp-glibc/sysroots/x86_64-linux/usr/share/fonts/X11/util/map-ISO8859-1':
No such file or directory!
See http://www.openembedded.org/wiki/Bitbake_World_Status
Signed-off-by: Richard Tollerton rich.toller...@ni.com
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-graphics/xorg-font/font-util_1.3.0.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/xorg-font/font-util_1.3.0.bb
b/meta/recipes-graphics/xorg-font/font-util_1.3.0.bb
index 8b42991..cc4258a 100644
--- a/meta/recipes-graphics/xorg-font/font-util_1.3.0.bb
+++ b/meta/recipes-graphics/xorg-font/font-util_1.3.0.bb
@@ -17,7 +17,7 @@ RDEPENDS_${PN}_class-native = mkfontdir-native
mkfontscale-native
PR = ${INC_PR}.0
do_configure_prepend() {
-sed -i
s#MAPFILES_PATH=\`pkg-config#MAPFILES_PATH=\`PKG_CONFIG_PATH=\${STAGING_LIBDIR_NATIVE}/pkg-config\
pkg-config#g ${S}/fontutil.m4.in
+sed -i
s#MAPFILES_PATH=\`pkg-config#MAPFILES_PATH=\`PKG_CONFIG_PATH=\${STAGING_LIBDIR_NATIVE}/pkgconfig\
pkg-config#g ${S}/fontutil.m4.in
}
BBCLASSEXTEND = native
--
___
Openembedded-commits mailing list
openembedded-comm...@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-commits
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe][PATCH 1/3] libfm: update to 1.2.3
Hi Max,
On 2 January 2015 at 21:25, Max Krummenacher max.oss...@gmail.com wrote:
+do_install_append () {
+# remove files which are part of libfm-extra
+rm -f ${D}/usr/include/libfm-1.0/fm-xml-file.h
+rm -f ${D}/usr/include/libfm-1.0/fm-version.h
+rm -f ${D}/usr/include/libfm-1.0/fm-extra.h
+rm -f ${D}/usr/lib/pkgconfig/libfm-extra.pc
+rm -f ${D}/usr/lib/libfm-extra.so*
+rm -f ${D}/usr/lib/libfm-extra.a
+rm -f ${D}/usr/lib/libfm-extra.la
+}
Don't use absolute paths such as /usr/lib/ as those paths are not constant
- multilib environments or x32 for example use different values for
${libdir}.
https://autobuilder.yoctoproject.org/main/builders/nightly-x32/builds/150/steps/BuildImages/logs/stdio
is an example of how this can break the build.
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] What is expected of a kernel recipe nowadays?
On Wed, Jan 7, 2015 at 5:07 AM, Martin Jansa martin.ja...@gmail.com wrote: On Tue, Jan 06, 2015 at 11:08:53AM +, Burton, Ross wrote: On 6 January 2015 at 08:57, Martin Jansa martin.ja...@gmail.com wrote: 2) do_configure failing: ERROR: Function failed: do_configure (log file is located at /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/work/mako-webos-linux-gnueabi/linux-lg-mako/3.4.0+gitrAUTOINC+38bdbfe224-r0/temp/log.do_configure.17498) ERROR: Logfile of failure stored in: /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/work/mako-webos-linux-gnueabi/linux-lg-mako/3.4.0+gitrAUTOINC+38bdbfe224-r0/temp/log.do_configure.17498 Log data follows: | DEBUG: Executing python function sysroot_cleansstate | DEBUG: Python function sysroot_cleansstate finished | DEBUG: Executing shell function do_configure | NOTE: make oldconfig | make: *** No rule to make target `oldconfig'. Stop. | ERROR: oe_runmake failed | WARNING: exit code 1 from a shell command. | ERROR: Function failed: do_configure (log file is located at /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/work/mako-webos-linux-gnueabi/linux-lg-mako/3.4.0+gitrAUTOINC+38bdbfe224-r0/temp/log.do_configure.17498) NOTE: recipe linux-lg-mako-3.4.0+gitrAUTOINC+38bdbfe224-r0: task do_configure: Failed ERROR: Task 491 (/home/jenkins/workspace/luneos-unstable/webos-ports/meta-smartphone/meta-lg/recipes-kernel/linux/ linux-lg-mako_git.bb, do_configure) failed with exit code '1' I'll Me Too here, often hitting this on rebuilds: DEBUG: Executing shell function do_configure NOTE: make -C /data/poky-master/tmp/sysroots/qemuarm64/usr/src/kernel O=/data/poky-master/tmp/work/qemuarm64-poky-linux/linux-yocto/3.14.24+gitAUTOINC+a227f20eff_902f34d361-r0/linux-qemuarm64-standard-build oldnoconfig make: Entering directory `/data/poky-master/tmp/sysroots/qemuarm64/usr/src/kernel' make: *** No rule to make target `oldnoconfig'. Stop. make: Leaving directory `/data/poky-master/tmp/sysroots/qemuarm64/usr/src/kernel' ERROR: Task 77 (/home/ross/Yocto/poky/meta/recipes-kernel/linux/linux-yocto_3.14.bb, do_configure) failed with exit code '1' last world build revealed new kind of error: both qemux86 and qemux86-64 failed like this ERROR: Function failed: do_kernel_configme (log file is located at /home/jenkins/oe/world/shr-core/tmp-glibc/work/qemux86_64-oe-linux/linux-yocto/3.17.6+gitAUTOINC+b81030f9ec_5ff54d8fbf-r0/temp/log.do_kernel_configme.6974) ERROR: Logfile of failure stored in: /home/jenkins/oe/world/shr-core/tmp-glibc/work/qemux86_64-oe-linux/linux-yocto/3.17.6+gitAUTOINC+b81030f9ec_5ff54d8fbf-r0/temp/log.do_kernel_configme.6974 Log data follows: | DEBUG: Executing shell function do_kernel_configme | NOTE: kernel configme | [INFO] Configuring target/machine combo: standard/qemux86-64 | [INFO] collecting configs in .meta/meta-series | ERROR: could not sanitize configuration fragments |errors are logged in /home/jenkins/oe/world/shr-core/tmp-glibc/sysroots/qemux86-64/usr/src/kernel/.meta/cfg/standard/common-pc-64/config.log | WARNING: exit code 1 from a shell command. | ERROR: Function failed: do_kernel_configme (log file is located at /home/jenkins/oe/world/shr-core/tmp-glibc/work/qemux86_64-oe-linux/linux-yocto/3.17.6+gitAUTOINC+b81030f9ec_5ff54d8fbf-r0/temp/log.do_kernel_configme.6974) NOTE: recipe linux-yocto-3.17.6+gitAUTOINC+b81030f9ec_5ff54d8fbf-r0: task do_kernel_configme: Failed I spoke to soon before. Where can I find the config that triggered this ? I just built the latest master and my fragments/patches were all properly applied in the default build: - DEBUG: Executing shell function do_kernel_configme NOTE: kernel configme [INFO] Configuring target/machine combo: standard/qemux86-64 [INFO] collecting configs in .meta/meta-series [INFO] Pre-processed cfg file qemux86-64-standard-config-3.17.6 created. [INFO] processing of raw cfg data completed. Configuration stored in /home/bruce/oe/build/tmp/work/qemux86_64-poky-linux/linux-yocto/3.17.6+gitAUTOINC+b81030f9ec_5ff54d8fbf-r0/linux-qemux86_64-standard-build/.config To build with this kernel configuration, ensure a suitable toolchain is in your path for x86_64, note its common command prefix, and do: make O=/home/bruce/oe/build/tmp/work/qemux86_64-poky-linux/linux-yocto/3.17.6+gitAUTOINC+b81030f9ec_5ff54d8fbf-r0/linux-qemux86_64-standard-build ARCH=x86_64 \ CROSS_COMPILE=cross-compile-prefix DEBUG: Shell function do_kernel_configme finished - Bruce -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org
[OE-core] [PATCH v2 1/2] combo-layer: minor refactor
Change get_repos() to assume a list of repository names instead of full
list of command line arguments.
Signed-off-by: Markus Lehtonen markus.lehto...@linux.intel.com
---
scripts/combo-layer | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/scripts/combo-layer b/scripts/combo-layer
index 19d64e6..37d1f47 100755
--- a/scripts/combo-layer
+++ b/scripts/combo-layer
@@ -305,18 +305,17 @@ def check_rev_branch(component, repodir, rev, branch):
return False
return True
-def get_repos(conf, args):
+def get_repos(conf, repo_names):
repos = []
-if len(args) 1:
-for arg in args[1:]:
-if arg.startswith('-'):
-break
-else:
-repos.append(arg)
-for repo in repos:
-if not repo in conf.repos:
-logger.error(Specified component '%s' not found in
configuration % repo)
-sys.exit(0)
+for name in repo_names:
+if name.startswith('-'):
+break
+else:
+repos.append(name)
+for repo in repos:
+if not repo in conf.repos:
+logger.error(Specified component '%s' not found in configuration
% repo)
+sys.exit(0)
if not repos:
repos = conf.repos
@@ -327,7 +326,7 @@ def action_pull(conf, args):
update the component repos only
-repos = get_repos(conf, args)
+repos = get_repos(conf, args[1:])
# make sure all repos are clean
for name in repos:
@@ -348,7 +347,7 @@ def action_update(conf, args):
generate the patch list
apply the generated patches
-repos = get_repos(conf, args)
+repos = get_repos(conf, args[1:])
# make sure combo repo is clean
check_repo_clean(os.getcwd())
--
1.8.4.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Further kernel build process changes?
On 15-01-07 04:16 PM, Richard Purdie wrote:
On Wed, 2015-01-07 at 10:33 -0800, Darren Hart wrote:
On 1/7/15, 5:22 AM, Bruce Ashfield bruce.ashfi...@windriver.com wrote:
On 2015-01-07 7:26 AM, Richard Purdie wrote:
External module builds do work in this configuration *if* you pass in
the correct options e.g.:
make -C work-shared/MACHINE/kernel-source
O=work-shared/MACHINE/kernel-build M=${S}
I've put together a quick proof of concept of this below.
snip
KERNEL_OBJECT_SUFFIX = .ko
# kernel modules are generally machine specific
PACKAGE_ARCH = ${MACHINE_ARCH}
+do_configure[depends] += virtual/kernel:do_install
I¹m not clear on the separation of do_shared_workdir and do_install now...
See above, this probably needs to change.
The patch was really a test to see how badly a build would explode with
separate source and builddir and whether the kernel build system can
cope with three separate locations (source, build objects, module). From
that perspective it passed in that I could build oprofile, perf and some
kernel modules. From here we need a step back and to go through and do
it properly.
Agreed. I've queued all the known patches, and have proven that my
builds work with this applied with minor adaptations.
I've got a first pass through with the consolidation and some other
scribbles notes. I'll generate a topic branch and send it out when
it looks reasonably sane (but not complete .. since we don't want to
sit on large private changes).
Cheers,
Bruce
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] Bug reporting and good bug reports
On 01/07/15 04:25, Richard Purdie wrote: I also have a patch. Where should I share them? How do I ensure everyone with an interest in this defect actually gets the patch? Sure I can create email and send to the people who I think need to know. When I went through that whole let's add a MAINTAINERS file thing last year this is exactly what I had in mind at that time. A developer could configure git to automatically invoke the script that accompanied that patch during a git send-email The purpose of the script was to go through the MAINTAINERS file to create a list of relevant people. But the script was also smart enough to look at the lines of code the patch was modifying and include the people who wrote the lines the patch was going to modify. Unfortunately everyone seemed to think a MAINTAINERS file was only good for assigning responsibility, which is something that had never occurred to me at the time :-) The bugzilla lets interested parties add themselves to bugs though. ...and people could add themselves as R's in a MAINTAINERS file! :-) http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS#n73 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] Bug reporting and good bug reports
On Wed, 2015-01-07 at 16:21 -0500, Trevor Woerner wrote: On 01/07/15 04:25, Richard Purdie wrote: I also have a patch. Where should I share them? How do I ensure everyone with an interest in this defect actually gets the patch? Sure I can create email and send to the people who I think need to know. When I went through that whole let's add a MAINTAINERS file thing last year this is exactly what I had in mind at that time. But that isn't what I'm talking about. I'm talking about people being able to say I have some interest in a particular defect and I'd like updates about it. That is completely different to a MAINTAINERS file. The user and easily opt in to specific things using the web UI and its self maintaining to a large degree. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] insane.bbclass: Added QA test for expanded ${D}
On 12/11/2014 02:40 PM, Alejandro Hernandez wrote:
Checks in FILES and pkg_* variables, solves common mistake of
using ${D} instead of $D and warns the user accordingly.
[YOCTO #6642]
Signed-off-by: Alejandro Hernandez alejandro.hernan...@linux.intel.com
---
meta/classes/insane.bbclass | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 0b45374..8224124 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -34,7 +34,7 @@ WARN_QA ?= ldflags useless-rpaths rpaths staticdev libdir
xorg-driver-abi \
ERROR_QA ?= dev-so debug-deps dev-deps debug-files arch pkgconfig la \
perms dep-cmp pkgvarcheck perm-config perm-line perm-link \
split-strip packages-list pkgv-undefined var-undefined \
-version-going-backwards \
+version-going-backwards expanded_d \
ALL_QA = ${WARN_QA} ${ERROR_QA}
@@ -906,6 +906,34 @@ def package_qa_check_deps(pkg, pkgdest, skip, d):
return sane
+QAPATHTEST[expanded_d] = package_qa_check_expanded_d
+def package_qa_check_expanded_d(path,name,d,elf,messages):
+
+Check for the expanded D (${D}) value in pkg_* and FILES
+variables, warn the user to use it correctly.
+
+
+sane = True
+expanded_d = d.getVar('D',True)
+
+# Get packages for current recipe and iterate
+packages = d.getVar('PACKAGES', True).split( )
+for pak in packages:
+# Go through all variables and check if expanded D is found, warn the user
accordingly
+for var in 'FILES','pkg_preinst', 'pkg_postinst', 'pkg_prerm',
'pkg_postrm':
+# Variables are actually var_${PN}
+bbvar = d.getVar(var + _ + pak)
Would it be simpler to do bbvar = d.getVar(var + _ + pak, False) so you
don't get the expanded value, and then just check for ${D}? I suppose it would
save one extra variable and a couple of expansions.
+if bbvar:
+# Bitbake expands ${D} within bbvar during the previous step,
so we check for its expanded value
+if expanded_d in bbvar:
+if var == 'FILES':
+messages[expanded_d] = FILES should not contain the ${D}
variable as it references the local build directory not the target filesystem, best solution is to
remove the ${D} reference
+sane = False
+else:
+messages[expanded_d] = %s in %s recipe contains ${D}, it
should be replaced by $D instead % (var, pak)
+sane = False
+return sane
+
# The PACKAGE FUNC to scan each package
python do_package_qa () {
import subprocess
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe][PATCH 1/3] libfm: update to 1.2.3
Hi Ross
Thank you for looking into this.
2015-01-07 16:17 GMT+01:00 Burton, Ross ross.bur...@intel.com:
Don't use absolute paths such as /usr/lib/ as those paths are not constant -
multilib environments or x32 for example use different values for ${libdir}.
I will rework the patch along with the menu-cache one and resend a v2
of the patch set.
Regards
Max
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [oe][PATCH V2 3/3] pcmanfm: update to 1.2.3
From: Max Krummenacher max.oss...@gmail.com
Signed-off-by: Max Krummenacher max.oss...@gmail.com
---
meta/recipes-sato/pcmanfm/pcmanfm_1.1.2.bb | 33
meta/recipes-sato/pcmanfm/pcmanfm_1.2.3.bb | 35 ++
2 files changed, 35 insertions(+), 33 deletions(-)
delete mode 100644 meta/recipes-sato/pcmanfm/pcmanfm_1.1.2.bb
create mode 100644 meta/recipes-sato/pcmanfm/pcmanfm_1.2.3.bb
diff --git a/meta/recipes-sato/pcmanfm/pcmanfm_1.1.2.bb
b/meta/recipes-sato/pcmanfm/pcmanfm_1.1.2.bb
deleted file mode 100644
index 14c5cd5..000
--- a/meta/recipes-sato/pcmanfm/pcmanfm_1.1.2.bb
+++ /dev/null
@@ -1,33 +0,0 @@
-SUMMARY = Fast lightweight tabbed filemanager
-HOMEPAGE = http://pcmanfm.sourceforge.net/;
-
-LICENSE = GPLv2 GPLv2+ LGPLv2.1+
-LIC_FILES_CHKSUM = file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552 \
-
file://src/pcmanfm.h;endline=22;md5=417b3855771a3a87f8ad753d994491f0 \
-
file://src/gseal-gtk-compat.h;endline=21;md5=46922c8691f58d124f9420fe16149ce2
-
-SECTION = x11
-DEPENDS = gtk+ startup-notification libfm intltool-native
-DEPENDS_append_poky = libowl
-
-
-COMPATIBLE_HOST =
'(x86_64.*|i.86.*|aarch64.*|arm.*|mips.*|powerpc.*|sh.*)-(linux|freebsd.*)'
-
-SRC_URI = ${SOURCEFORGE_MIRROR}/pcmanfm/pcmanfm-${PV}.tar.gz \
- file://gnome-fs-directory.png \
- file://gnome-fs-regular.png \
- file://gnome-mime-text-plain.png \
- file://emblem-symbolic-link.png \
- file://no-desktop.patch
-
-SRC_URI[md5sum] = 41104699e653ff2b0a9a9e80a257d6a2
-SRC_URI[sha256sum] =
23ee33b34066ac83ce9a98bc9930049e69839438fb60489bd453bec8c2068950
-
-inherit autotools pkgconfig
-
-do_install_append () {
- install -d ${D}/${datadir}
- install -d ${D}/${datadir}/pixmaps/
-
- install -m 0644 ${WORKDIR}/*.png ${D}/${datadir}/pixmaps
-}
diff --git a/meta/recipes-sato/pcmanfm/pcmanfm_1.2.3.bb
b/meta/recipes-sato/pcmanfm/pcmanfm_1.2.3.bb
new file mode 100644
index 000..14f58ae
--- /dev/null
+++ b/meta/recipes-sato/pcmanfm/pcmanfm_1.2.3.bb
@@ -0,0 +1,35 @@
+SUMMARY = Fast lightweight tabbed filemanager
+HOMEPAGE = http://pcmanfm.sourceforge.net/;
+
+LICENSE = GPLv2 GPLv2+ LGPLv2.1+
+LIC_FILES_CHKSUM = file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552 \
+
file://src/pcmanfm.h;endline=22;md5=417b3855771a3a87f8ad753d994491f0 \
+
file://src/gseal-gtk-compat.h;endline=21;md5=46922c8691f58d124f9420fe16149ce2
+
+SECTION = x11
+DEPENDS = gtk+ startup-notification libfm intltool-native
+DEPENDS_append_poky = libowl
+
+
+COMPATIBLE_HOST =
'(x86_64.*|i.86.*|aarch64.*|arm.*|mips.*|powerpc.*|sh.*)-(linux|freebsd.*)'
+
+SRC_URI = ${SOURCEFORGE_MIRROR}/pcmanfm/pcmanfm-${PV}.tar.xz \
+ file://gnome-fs-directory.png \
+ file://gnome-fs-regular.png \
+ file://gnome-mime-text-plain.png \
+ file://emblem-symbolic-link.png \
+ file://no-desktop.patch
+
+SRC_URI[md5sum] = c993402d407b0a3fc076f842ac1bc5c9
+SRC_URI[sha256sum] =
cfa8d82fc63be147045174bef074807e1e32ce8c6bf4dbd8fad49e260bcf6380
+
+inherit autotools pkgconfig
+
+do_install_append () {
+ install -d ${D}/${datadir}
+ install -d ${D}/${datadir}/pixmaps/
+
+ install -m 0644 ${WORKDIR}/*.png ${D}/${datadir}/pixmaps
+}
+
+FILES_${PN} += ${libdir}/pcmanfm
--
1.8.4.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [oe][PATCH V2 2/3] menu-cache: update to 1.0.0
From: Max Krummenacher max.oss...@gmail.com
menu-cache depends on fmlib-extra and thus requires the split
of the libfm recipe in version 1.2.3.
This obsoletes Fix-segfault.patch.
menu-cache license has been changed by the authors from GPL to LGPL:
http://git.lxde.org/gitweb/?p=lxde/menu-cache.git;a=commit;h=7972913d8e47e4970b9aa70267cb87fe7eb3a8b4
http://git.lxde.org/gitweb/?p=lxde/menu-cache.git;a=commit;h=08fe520c52a79d425504ba631afbea5fd62cc735
Signed-off-by: Max Krummenacher max.oss...@gmail.com
---
.../menu-cache/files/Fix-segfault.patch| 31 --
.../menu-cache/menu-cache_0.4.1.bb | 21 ---
.../menu-cache/menu-cache_1.0.0.bb | 16 +++
3 files changed, 16 insertions(+), 52 deletions(-)
delete mode 100644 meta/recipes-graphics/menu-cache/files/Fix-segfault.patch
delete mode 100644 meta/recipes-graphics/menu-cache/menu-cache_0.4.1.bb
create mode 100644 meta/recipes-graphics/menu-cache/menu-cache_1.0.0.bb
diff --git a/meta/recipes-graphics/menu-cache/files/Fix-segfault.patch
b/meta/recipes-graphics/menu-cache/files/Fix-segfault.patch
deleted file mode 100644
index 74a0407..000
--- a/meta/recipes-graphics/menu-cache/files/Fix-segfault.patch
+++ /dev/null
@@ -1,31 +0,0 @@
-From a497ea6aae3994b7f6527ef7599dd95baf2ad841 Mon Sep 17 00:00:00 2001
-From: Laurentiu Palcu laurentiu.pa...@intel.com
-Date: Mon, 29 Apr 2013 12:04:20 +0300
-Subject: [PATCH] Fix segfault
-
-Apparently, g_io_channel_unref() was called twice: once in the
-menu-cache's on_client_closed() callback and once from the finalize
-function, g_io_unix_finalize()/g_io_win32_finalize(), which is called
-anyway when the source is removed.
-
-Upstream-Status: Pending
-Signed-off-by: Laurentiu Palcu laurentiu.pa...@intel.com
- menu-cache-daemon/menu-cached.c |1 -
- 1 file changed, 1 deletion(-)
-
-diff --git a/menu-cache-daemon/menu-cached.c b/menu-cache-daemon/menu-cached.c
-index e246bb4..a10b6db 100644
a/menu-cache-daemon/menu-cached.c
-+++ b/menu-cache-daemon/menu-cached.c
-@@ -579,7 +579,6 @@ static void on_client_closed(gpointer user_data)
- }
- }
- /* DEBUG(client closed); */
--g_io_channel_unref(ch);
- }
-
- static gboolean on_client_data_in(GIOChannel* ch, GIOCondition cond, gpointer
user_data)
---
-1.7.9.5
-
diff --git a/meta/recipes-graphics/menu-cache/menu-cache_0.4.1.bb
b/meta/recipes-graphics/menu-cache/menu-cache_0.4.1.bb
deleted file mode 100644
index 98bbe76..000
--- a/meta/recipes-graphics/menu-cache/menu-cache_0.4.1.bb
+++ /dev/null
@@ -1,21 +0,0 @@
-SUMMARY = Library for caching application menus
-DESCRIPTION = A library creating and utilizing caches to speed up
freedesktop.org application menus
-HOMEPAGE = http://lxde.sourceforge.net/;
-
-LICENSE = GPLv2 GPLv2+
-LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
-
file://libmenu-cache/menu-cache.h;endline=29;md5=26571532593adb17a37eac396260532c
\
-
file://menu-cache-daemon/menu-cached.c;endline=22;md5=fcecb7d315c57ef804103fa9cdab7111
-
-SECTION = x11/libs
-DEPENDS = glib-2.0 zlib
-
-SRC_URI = ${SOURCEFORGE_MIRROR}/lxde/menu-cache-${PV}.tar.gz \
- file://Fix-segfault.patch \
-
-
-SRC_URI[md5sum] = 20fed982f5d8e6ec8a56a5b48894ecf0
-SRC_URI[sha256sum] =
4fa9408e353fedba5b7314cbf6b6cd06d873a1424e281aa050d88bb9c0a0191e
-
-
-inherit autotools pkgconfig gtk-doc
diff --git a/meta/recipes-graphics/menu-cache/menu-cache_1.0.0.bb
b/meta/recipes-graphics/menu-cache/menu-cache_1.0.0.bb
new file mode 100644
index 000..ab909f7
--- /dev/null
+++ b/meta/recipes-graphics/menu-cache/menu-cache_1.0.0.bb
@@ -0,0 +1,16 @@
+SUMMARY = Library for caching application menus
+DESCRIPTION = A library creating and utilizing caches to speed up
freedesktop.org application menus
+HOMEPAGE = http://lxde.sourceforge.net/;
+
+LICENSE = LGPLv2.1+
+LIC_FILES_CHKSUM = file://COPYING;md5=0964c689fcf4c21c6797ea87408416b6
+
+SECTION = x11/libs
+DEPENDS = glib-2.0 intltool-native libfm-extra
+
+SRC_URI = ${SOURCEFORGE_MIRROR}/lxde/menu-cache-${PV}.tar.xz
+
+SRC_URI[md5sum] = 4a8e6c1a86d5e64ec725d850a4abfbad
+SRC_URI[sha256sum] =
ff7df437bbfd3119c5f662c6d209b98f15de03a7203308c6b56a4c1e1d419aaf
+
+inherit autotools gettext pkgconfig gtk-doc
--
1.8.4.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [oe][PATCH V2 1/3] libfm: update to 1.2.3
From: Max Krummenacher max.oss...@gmail.com
split out libfm-extra as a seperate recipe to break a circular dependency
with newer menu-cache recipe.
This obsoletes ignore_automake_warnings.patch.
This obsoletes fix-make-parallelism-issue.patch.
https://github.com/lxde/libfm/commit/24c8eab43cb5b79ca917d67a2c5924aca34c80c9
The library part of libfm has its license changed by the authors to LGPL:
http://git.lxde.org/gitweb/?p=lxde/libfm.git;a=commit;h=e0d250aeb40f26ceead82d4b4c7af3b58ab34930
Signed-off-by: Max Krummenacher max.oss...@gmail.com
---
.../libfm-1.1.2.2/fix-make-parallelism-issue.patch | 31 ---
.../libfm-1.1.2.2/ignore_automake_warnings.patch | 14 -
meta/recipes-support/libfm/libfm-extra_1.2.3.bb| 21 +
meta/recipes-support/libfm/libfm_1.1.2.2.bb| 25 ---
meta/recipes-support/libfm/libfm_1.2.3.bb | 36 ++
5 files changed, 57 insertions(+), 70 deletions(-)
delete mode 100644
meta/recipes-support/libfm/libfm-1.1.2.2/fix-make-parallelism-issue.patch
delete mode 100644
meta/recipes-support/libfm/libfm-1.1.2.2/ignore_automake_warnings.patch
create mode 100644 meta/recipes-support/libfm/libfm-extra_1.2.3.bb
delete mode 100644 meta/recipes-support/libfm/libfm_1.1.2.2.bb
create mode 100644 meta/recipes-support/libfm/libfm_1.2.3.bb
diff --git
a/meta/recipes-support/libfm/libfm-1.1.2.2/fix-make-parallelism-issue.patch
b/meta/recipes-support/libfm/libfm-1.1.2.2/fix-make-parallelism-issue.patch
deleted file mode 100644
index 5d39d19..000
--- a/meta/recipes-support/libfm/libfm-1.1.2.2/fix-make-parallelism-issue.patch
+++ /dev/null
@@ -1,31 +0,0 @@
-Fix make parallelism issue
-
-- remove pkginclude_HEADERS ( LIBFM_INCLUDES and LIBFM_GTK_INCLUDES
-variables are empty)
-- if we don't remove it then we will have a race condition between the code
-that tries to symlink ${includedir}/libfm-1.0 to ${includedir}/libfm and the
-am autogenerated code from the pkginclude_HEADERS definition which
-tries to create pkgincludedir (${includedir}/libfm);
-- if pkgincludedir is created before the symlink the symlink will be created
-in the ${includedir}/libfm dir and it will have libfm-1.0 as name which is
-wrong (we need the ${includedir}/libfm symlink for pcmanfm)
-
-Upstream-Status: Pending
-Signed-off-by: Constantin Musca constantinx.mu...@intel.com
-
-Index: libfm-1.1.0/src/Makefile.am
-===
libfm-1.1.0.orig/src/Makefile.am
-+++ libfm-1.1.0/src/Makefile.am
-@@ -211,11 +211,6 @@ libfmgtkinclude_HEADERS = \
- gtk/fm-gtk-marshal.h \
- $(NULL)
-
--pkginclude_HEADERS = \
-- $(LIBFM_INCLUDES) \
-- $(LIBFM_GTK_INCLUDES) \
-- $(NULL)
--
- EXTRA_LTLIBRARIES = libfm-gtk.la libfm-gtk3.la
-
- lib_LTLIBRARIES = libfm.la @LIBFM_GTK_LTLIBRARIES@
diff --git
a/meta/recipes-support/libfm/libfm-1.1.2.2/ignore_automake_warnings.patch
b/meta/recipes-support/libfm/libfm-1.1.2.2/ignore_automake_warnings.patch
deleted file mode 100644
index 58a2f09..000
--- a/meta/recipes-support/libfm/libfm-1.1.2.2/ignore_automake_warnings.patch
+++ /dev/null
@@ -1,14 +0,0 @@
-Upstream-Status: Inappropriate [configuration]
-
-Signed-off-by: Marko Lindqvist cazf...@gmail.com
-diff -Nurd libfm-1.1.2.2/configure.ac libfm-1.1.2.2/configure.ac
libfm-1.1.2.2/configure.ac 2013-08-22 23:16:09.0 +0300
-+++ libfm-1.1.2.2/configure.ac 2013-10-25 01:35:18.110323079 +0300
-@@ -3,7 +3,7 @@
-
- AC_PREREQ([2.63])
- AC_INIT([libfm], [1.1.2.2], [http://pcmanfm.sourceforge.net/])
--AM_INIT_AUTOMAKE([-Wall -Werror foreign])
-+AM_INIT_AUTOMAKE([-Wall foreign])
- AC_CONFIG_MACRO_DIR(m4)
- AC_CONFIG_HEADERS([config.h])
diff --git a/meta/recipes-support/libfm/libfm-extra_1.2.3.bb
b/meta/recipes-support/libfm/libfm-extra_1.2.3.bb
new file mode 100644
index 000..8bdb12c
--- /dev/null
+++ b/meta/recipes-support/libfm/libfm-extra_1.2.3.bb
@@ -0,0 +1,21 @@
+SUMMARY = Library for file management
+HOMEPAGE = http://pcmanfm.sourceforge.net/;
+
+LICENSE = LGPLv2+
+LIC_FILES_CHKSUM =
file://src/fm-extra.h;beginline=8;endline=21;md5=ef1f84da64b3c01cca447212f7ef6007
+
+SECTION = x11/libs
+DEPENDS = glib-2.0 intltool-native
+
+SRC_URI = ${SOURCEFORGE_MIRROR}/pcmanfm/libfm-${PV}.tar.xz
+
+SRC_URI[md5sum] = 3ff38200701658f7e80e25ed395d92dd
+SRC_URI[sha256sum] =
c692f1624a4cbc8d1dd55f3b3f3369fbf5d26f63a916e2c295230b2344e1fbf9
+
+S = ${WORKDIR}/libfm-${PV}
+
+EXTRA_OECONF = --with-extra-only --with-gtk=no
+
+inherit autotools-brokensep pkgconfig gtk-doc
+
+do_configure[dirs] =+ ${S}/m4
diff --git a/meta/recipes-support/libfm/libfm_1.1.2.2.bb
b/meta/recipes-support/libfm/libfm_1.1.2.2.bb
deleted file mode 100644
index 10f31d9..000
--- a/meta/recipes-support/libfm/libfm_1.1.2.2.bb
+++ /dev/null
@@ -1,25 +0,0 @@
-SUMMARY = Library for file management
-HOMEPAGE = http://pcmanfm.sourceforge.net/;
-
-LICENSE = GPLv2 GPLv2+
-LIC_FILES_CHKSUM =
[OE-core] [oe][PATCH v2 0/3] pcmanfm: update to 1.2.3
From: Max Krummenacher max.oss...@gmail.com
v2:
Changes according to Ross's review:
libfm: replace absolute paths with ${libdir} ${includedir}
menu-cache: replace ${PN} in download path
pcmanfm: unchanged
---
This updates pcmanfm and its supporting libraries libfm and menu-cache to
the latest version.
Tested with core-image-sato on a qemux86-64 machine and a custom image on
armv7 hardware.
Due to a circular dependency between menu-cache and libfm the menu-cache patch
requires the libfm patch.
This obsoletes the following two patches which have not (yet) been applied:
http://patchwork.openembedded.org/patch/79087/
http://patchwork.openembedded.org/patch/79089/
Max Krummenacher (3):
libfm: update to 1.2.3
menu-cache: update to 1.0.0
pcmanfm: update to 1.2.3
.../menu-cache/files/Fix-segfault.patch| 31 ---
.../menu-cache/menu-cache_0.4.1.bb | 21 -
.../menu-cache/menu-cache_1.0.0.bb | 16 ++
meta/recipes-sato/pcmanfm/pcmanfm_1.1.2.bb | 33
meta/recipes-sato/pcmanfm/pcmanfm_1.2.3.bb | 35 +
.../libfm-1.1.2.2/fix-make-parallelism-issue.patch | 31 ---
.../libfm-1.1.2.2/ignore_automake_warnings.patch | 14 -
meta/recipes-support/libfm/libfm-extra_1.2.3.bb| 21 +
meta/recipes-support/libfm/libfm_1.1.2.2.bb| 25 ---
meta/recipes-support/libfm/libfm_1.2.3.bb | 36 ++
10 files changed, 108 insertions(+), 155 deletions(-)
delete mode 100644 meta/recipes-graphics/menu-cache/files/Fix-segfault.patch
delete mode 100644 meta/recipes-graphics/menu-cache/menu-cache_0.4.1.bb
create mode 100644 meta/recipes-graphics/menu-cache/menu-cache_1.0.0.bb
delete mode 100644 meta/recipes-sato/pcmanfm/pcmanfm_1.1.2.bb
create mode 100644 meta/recipes-sato/pcmanfm/pcmanfm_1.2.3.bb
delete mode 100644
meta/recipes-support/libfm/libfm-1.1.2.2/fix-make-parallelism-issue.patch
delete mode 100644
meta/recipes-support/libfm/libfm-1.1.2.2/ignore_automake_warnings.patch
create mode 100644 meta/recipes-support/libfm/libfm-extra_1.2.3.bb
delete mode 100644 meta/recipes-support/libfm/libfm_1.1.2.2.bb
create mode 100644 meta/recipes-support/libfm/libfm_1.2.3.bb
--
1.8.4.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] About update binutils (2.24 to 2.25)
Hi Khem, I'm trying to upgrade binutils from 2.24 to 2.25, there is a patch binutils/libtool-2.4-update.patch which has 19317 lines, do you have any ideas on how did we make it in the past, please ? $ diffstat ./binutils/libtool-2.4-update.patch bfd/configure| 1314 +- bfd/configure.in |2 binutils/configure | 1312 +- configure|2 gas/configure| 1312 +- gprof/configure | 1317 +- ld/configure | 1693 ++--- libtool.m4 | 1094 +-- ltmain.sh| 2925 ++- ltoptions.m4 |2 ltversion.m4 | 12 lt~obsolete.m4 |2 opcodes/configure| 1314 +- opcodes/configure.in |2 14 files changed, 8937 insertions(+), 3366 deletions(-) -- Thanks Robert -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] About update binutils (2.24 to 2.25)
On Jan 7, 2015, at 5:44 PM, Robert Yang liezhi.y...@windriver.com wrote: Hi Khem, I'm trying to upgrade binutils from 2.24 to 2.25, there is a patch binutils/libtool-2.4-update.patch which has 19317 lines, do you have any ideas on how did we make it in the past, please ? what conflicts are you seeing ? if they are just in configure files then you need to autoteconf them manually one by one using the appropriate version of auototools as recommended for bintutils 2.25 usually gcc/binutils don’t use latest auto tools. but if they are reporting changes in other files then its a different problem needs to be looked at. $ diffstat ./binutils/libtool-2.4-update.patch bfd/configure| 1314 +- bfd/configure.in |2 binutils/configure | 1312 +- configure|2 gas/configure| 1312 +- gprof/configure | 1317 +- ld/configure | 1693 ++--- libtool.m4 | 1094 +-- ltmain.sh| 2925 ++- ltoptions.m4 |2 ltversion.m4 | 12 lt~obsolete.m4 |2 opcodes/configure| 1314 +- opcodes/configure.in |2 14 files changed, 8937 insertions(+), 3366 deletions(-) -- Thanks Robert -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] About update binutils (2.24 to 2.25)
On 01/08/2015 09:55 AM, Khem Raj wrote: On Jan 7, 2015, at 5:44 PM, Robert Yang liezhi.y...@windriver.com wrote: Hi Khem, I'm trying to upgrade binutils from 2.24 to 2.25, there is a patch binutils/libtool-2.4-update.patch which has 19317 lines, do you have any ideas on how did we make it in the past, please ? what conflicts are you seeing ? if they are just in configure files then you need to autoteconf them manually one by one using the appropriate version of auototools as recommended for bintutils 2.25 usually gcc/binutils don’t use latest auto tools. Conflicts in ld/configure, I fixed it manually, I was curious how we made this patch, and now you have explained, thanks. // Robert but if they are reporting changes in other files then its a different problem needs to be looked at. $ diffstat ./binutils/libtool-2.4-update.patch bfd/configure| 1314 +- bfd/configure.in |2 binutils/configure | 1312 +- configure|2 gas/configure| 1312 +- gprof/configure | 1317 +- ld/configure | 1693 ++--- libtool.m4 | 1094 +-- ltmain.sh| 2925 ++- ltoptions.m4 |2 ltversion.m4 | 12 lt~obsolete.m4 |2 opcodes/configure| 1314 +- opcodes/configure.in |2 14 files changed, 8937 insertions(+), 3366 deletions(-) -- Thanks Robert -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] About update binutils (2.24 to 2.25)
On Jan 7, 2015, at 6:05 PM, Robert Yang liezhi.y...@windriver.com wrote: On 01/08/2015 09:55 AM, Khem Raj wrote: On Jan 7, 2015, at 5:44 PM, Robert Yang liezhi.y...@windriver.com wrote: Hi Khem, I'm trying to upgrade binutils from 2.24 to 2.25, there is a patch binutils/libtool-2.4-update.patch which has 19317 lines, do you have any ideas on how did we make it in the past, please ? what conflicts are you seeing ? if they are just in configure files then you need to autoteconf them manually one by one using the appropriate version of auototools as recommended for bintutils 2.25 usually gcc/binutils don’t use latest auto tools. Conflicts in ld/configure, I fixed it manually, I was curious how we made this patch, and now you have explained, thanks. some portions are written and others are generated. since we do not autoreconf binutils, we do have to regenerate configure scripts so its a special case. Usually that would not be needed for autotooled recipes // Robert but if they are reporting changes in other files then its a different problem needs to be looked at. $ diffstat ./binutils/libtool-2.4-update.patch bfd/configure| 1314 +- bfd/configure.in |2 binutils/configure | 1312 +- configure|2 gas/configure| 1312 +- gprof/configure | 1317 +- ld/configure | 1693 ++--- libtool.m4 | 1094 +-- ltmain.sh| 2925 ++- ltoptions.m4 |2 ltversion.m4 | 12 lt~obsolete.m4 |2 opcodes/configure| 1314 +- opcodes/configure.in |2 14 files changed, 8937 insertions(+), 3366 deletions(-) -- Thanks Robert -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] About update binutils (2.24 to 2.25)
On 01/08/2015 10:10 AM, Khem Raj wrote: On Jan 7, 2015, at 6:05 PM, Robert Yang liezhi.y...@windriver.com wrote: On 01/08/2015 09:55 AM, Khem Raj wrote: On Jan 7, 2015, at 5:44 PM, Robert Yang liezhi.y...@windriver.com wrote: Hi Khem, I'm trying to upgrade binutils from 2.24 to 2.25, there is a patch binutils/libtool-2.4-update.patch which has 19317 lines, do you have any ideas on how did we make it in the past, please ? what conflicts are you seeing ? if they are just in configure files then you need to autoteconf them manually one by one using the appropriate version of auototools as recommended for bintutils 2.25 usually gcc/binutils don’t use latest auto tools. Conflicts in ld/configure, I fixed it manually, I was curious how we made this patch, and now you have explained, thanks. some portions are written and others are generated. since we do not autoreconf binutils, we do have to regenerate configure scripts so its a special case. Usually that would not be needed for autotooled recipes Thanks, got it. // Robert // Robert but if they are reporting changes in other files then its a different problem needs to be looked at. $ diffstat ./binutils/libtool-2.4-update.patch bfd/configure| 1314 +- bfd/configure.in |2 binutils/configure | 1312 +- configure|2 gas/configure| 1312 +- gprof/configure | 1317 +- ld/configure | 1693 ++--- libtool.m4 | 1094 +-- ltmain.sh| 2925 ++- ltoptions.m4 |2 ltversion.m4 | 12 lt~obsolete.m4 |2 opcodes/configure| 1314 +- opcodes/configure.in |2 14 files changed, 8937 insertions(+), 3366 deletions(-) -- Thanks Robert -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4] add variable INSTALL_ALL to install all packages in recipes
On 01/08/2015 07:54 AM, Richard Purdie wrote: This tells me what the change does. What it doesn't say is why we need this? Its a fairly invasive set of changes but I don't see the usecase... Hi Richard, I am sorry not to say it clearly, 1) We have been asked many times on how to install all the PACKAGES of a recipe, we can only list them one by one in the RDPENDS (or IMAGE_INSTALL and so on) currently, especially like dynamic generated packages (perl-modules, kernel-modules) which depends on many other packages, it is not easy to remember these package names for customer. It is helpful for user who does not take care the details that how many packages generated in a recipe, just want to directly install all of them. 2) Providing a mechanism to install all the PACKAGES of a recipe is helpful to test all generated packages of a recipe could work, such as the defect of '[PATCH 3/4]' was found by installing all packages of python3. 3) The fix is based on the usage of IMAGE_INSTALL, so it doesn't affect the users who do not want to use this feature (We disable it by default). //Hongxu Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] OpenEmbedded at FOSDEM
It is that time of the year again. FOSDEM 2015 is Jan 31/ Feb 1 in Brussels. https://fosdem.org/2015/ OpenEmbedded will have a stand again this year and we would like some help manning it. I've done a quick copy from the 2014 page on the wiki: http://openembedded.org/wiki/FOSDEM_2015 We need to get some interesting demos that use OpenEmbedded for the stand. I should be able to bring the latest USRP with a USB screen. I'd also like to thank Paul Eggleton for arranging the stand. The ev board has approved two travel grants of 200 euros (not to exceed, actual expenses only) for people willing to help at FOSDEM. These should go to people who cannot get support from their employers and you need to be prepared to contirbute a significant amount of time manning the stand. Philip -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe][PATCH 2/3] menu-cache: update to 1.0.0
On 2 January 2015 at 21:25, Max Krummenacher max.oss...@gmail.com wrote:
+SRC_URI = ${SOURCEFORGE_MIRROR}/lxde/${PN}-${PV}.tar.xz
Don't use ${PN} as in multilib environments that isn't what you expect:
DEBUG: Fetcher failure: Fetch command failed with exit code 8,
output:http://sources.openembedded.org/lib64-menu-cache-1.0.0.tar.xz:
BPN is PN without any magic prefixes, so use that in variables like
SRC_URI. For convenience, ${BP} is ${BPN}-${PV} so you can use that in
SRC_URI.
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] oeqa/parselogs: Added a check in case the folder location does not contain any log files
Signed-off-by: Lucian Musat george.l.mu...@intel.com --- meta/lib/oeqa/runtime/parselogs.py | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/meta/lib/oeqa/runtime/parselogs.py b/meta/lib/oeqa/runtime/parselogs.py index 42cb1b5..1cb9939 100644 --- a/meta/lib/oeqa/runtime/parselogs.py +++ b/meta/lib/oeqa/runtime/parselogs.py @@ -100,9 +100,10 @@ class ParseLogsTest(oeRuntimeTest): (status, output) = self.target.run(test -d +str(location)) if (status == 0): (status, output) = self.target.run(find +str(location)+/*.log -maxdepth 1 -type f) -output = output.splitlines() -for logfile in output: -logs.append(os.path.join(location,str(logfile))) +if (status == 0): +output = output.splitlines() +for logfile in output: +logs.append(os.path.join(location,str(logfile))) return logs #build the grep command to be used with filters and exclusions -- 2.1.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] kernel.bbclass: When linux/version.h exists, copy it
Unless anyone needs these really fast, I'll queue the two kernel
patches and take them
for a spin today.
I have a variant of the version.h here (and when the directories
shuffle again, we can drop
explicit copies all together), but will make the switch for this in
the short term.
Bruce
On Wed, Jan 7, 2015 at 12:25 PM, Otavio Salvador
ota...@ossystems.com.br wrote:
Old Linux kernel versions rely on linux/version.h for modules; this
needs to be published for external modules to use. Copy it when
available.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/classes/kernel.bbclass | 4
1 file changed, 4 insertions(+)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 88356b1..78c8c7c 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -252,6 +252,10 @@ kernel_do_install() {
cp .config $kerneldir/
mkdir -p $kerneldir/include/config
cp include/config/kernel.release
$kerneldir/include/config/kernel.release
+ if [ -e include/linux/version.h ]; then
+ mkdir -p $kerneldir/include/linux
+ cp include/linux/version.h $kerneldir/include/linux/version.h
+ fi
# As of Linux kernel version 3.0.1, the clean target removes
# arch/powerpc/lib/crtsavres.o which is present in
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] insane.bbclass: Added QA test for expanded ${D}
Hi Alejandro,
Looks good, but some small points:
On 11 December 2014 at 22:40, Alejandro Hernandez
alejandro.hernan...@linux.intel.com wrote:
-version-going-backwards \
+version-going-backwards expanded_d \
+QAPATHTEST[expanded_d] = package_qa_check_expanded_d
Rename this to expanded-d for consistency with the other symbols that use -
instead of _.
+# Variables are actually var_${PN}
No need to document idioms, remove this comment.
+messages[expanded_d] = FILES should not
contain the ${D} variable as it references the local build directory not
the target filesystem, best solution is to remove the ${D} reference
This doesn't name the package which makes it tricky to find in large builds.
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] module.bbclass: Add KERNEL_SRC in EXTRA_OEMAKE
On Wed, Jan 7, 2015 at 4:45 PM, Bruce Ashfield bruce.ashfi...@gmail.com wrote:
On Wed, Jan 7, 2015 at 12:25 PM, Otavio Salvador
ota...@ossystems.com.br wrote:
When the sstate hash changes for do_configure task, the do_configure
default implementation triggers the 'clean' to be run. For it to
succeed we need to have KERNEL_SRC defined in EXTRA_OEMAKE. Fixes
following error:
I wanted to reproduce this locally, since I've never seen the problem
myself.
What's the best way to trigger the sstate hash change ?
I also have a question below ...
This was triggered when I did a change in the kernel-module-mcc; so
when I changed the recipe it triggered the configure.
,
| DEBUG: Executing shell function do_configure
| NOTE: make -e MAKEFLAGS= clean
| make -C M=.../tmp/work/... clean
| make[1]: *** M=.../tmp/work/...: No such file or directory. Stop.
| Makefile:20: recipe for target 'clean' failed
| make: *** [clean] Error 2
| ERROR: oe_runmake failed
`
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/classes/module.bbclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes/module.bbclass b/meta/classes/module.bbclass
index ad6f7af..5cb8623 100644
--- a/meta/classes/module.bbclass
+++ b/meta/classes/module.bbclass
@@ -6,10 +6,11 @@ addtask make_scripts after do_patch before do_compile
do_make_scripts[lockfiles] = ${TMPDIR}/kernel-scripts.lock
do_make_scripts[deptask] = do_populate_sysroot
+EXTRA_OEMAKE += KERNEL_SRC=${STAGING_KERNEL_DIR}
+
I'm not seeing very well at the moment and my ability to browse the code
is restricted, so bear with a potentially stupid question.
No worries.
It's clear from the error message above why this is needed, but I'm not
seeing the code that is respecting/using KERNEL_SRC to trigger the
clean in the right directory. Where exactly is this being used (I know your
related base.bbclass change will pull in the extra make args, but I'm just
not seeing the Makefile that respects it).
Basically, I'm trying to decide if it would be better to handle this all in
the module class, and add a do_configure to the do_compile and
do_install we already have.
Since I'm not seeing it, others might not as well .. and we can enhance the
comments to make it clear.
It was triggered from the module Makefile. So it basically runned:
make clean
and it tried to load it from kernel source, which obviously failed.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] kernel.bbclass: When linux/version.h exists, copy it
On Wed, Jan 7, 2015 at 3:47 PM, Bruce Ashfield bruce.ashfi...@gmail.com wrote: Unless anyone needs these really fast, I'll queue the two kernel patches and take them for a spin today. I have a variant of the version.h here (and when the directories shuffle again, we can drop explicit copies all together), but will make the switch for this in the short term. We have failures due this in meta-fsl-arm; it is for master only so we can live with failures for some days. I am happy you have something in same line. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Further kernel build process changes?
On 1/7/15, 5:22 AM, Bruce Ashfield bruce.ashfi...@windriver.com wrote:
On 2015-01-07 7:26 AM, Richard Purdie wrote:
I'm hearing (somewhat justified) complaints that the recent kernel
changes have destablised builds. Part of the question is whether the
recent changes are as clear to users as they could be, we're also
running into some problems due to mixing kernel source and build
artefacts in some places and not in others.
And we've been bitten by the sheer diversity in the various additions
and tweaks to the kernel build process .. which when wading in to try
and make some improvements was always the risk :(
At this point I think it may be worth looking at making some more
invasive but decisive changes, specifically that:
STAGING_KERNEL_DIR moves
from sysroots/MACHINE/usr/src/kernel
to work-shared/MACHINE/kernel-source
This is to make it clearer that the source here is not under the control
of sstate. The reasons why we don't want it under the control of sstate
are in other emails.
I'm in agreement here.
I would prefer this approach as well.
The second change would be to split the kernel source into two:
work-shared/MACHINE/kernel-source
work-shared/MACHINE/kernel-build
where kernel-build is the kernel build output and kernel-source is kept
pristine.
This means the defconfig, the kernel-abiversion, System.map files and
output from make scripts would be in kernel-build.
Exactly. When setting up the minimal external module build environment,
to keep the impact in the shared directories small, I went with the
current approach.
Since we are breaking workflows with it .. this would be a good balance
between the old and new efforts. I started mocking this up over the
holidays
but lost a week due to illness. I'll continue running with this now.
Also in agreement here, keeping the sourcedir pristine should reduce
confusion and complexity elsewhere.
External module builds do work in this configuration *if* you pass in
the correct options e.g.:
make -C work-shared/MACHINE/kernel-source
O=work-shared/MACHINE/kernel-build M=${S}
I've put together a quick proof of concept of this below.
I was concerned about how this would impact hello-mod and recipes modeled
after it, however, in reviewing the patch below, it looks to have this
covered. I¹ll verify this just as soon as my workstation is available
(it¹s ³busy² updating sigh).
There are two other things up for discussion. There is of confusion on
how the kernel source gets into STAGING_KERNEL_DIR in the first place.
We've added in munging code which does this in kernel.bbclass,
linux-yocto also has its share of crazy mess in this regard.
:)
We could wipe the slate clean and require that people put a parameter
against the element in SRC_URI that represents the kernel indicating it
should be directly extracted to STAGING_KERNEL_DIR. There is a bitbake
issue with being unable to override the extraction directory at present
but that can be fixed. The upside is that it would be clean, relatively
clear and allow fragile code to be dropped. The downside is it means
tweaking all kernel recipes.
I¹m concerned about adding yet more complexity to the SRC_URI I don¹t
have a better proposal though. Part of this fix will need to include fixes
to the kernel-dev manual, I can take that on once we hash this out.
The second issue is that of the dependency to populate
STAGING_KERNEL_DIR which is now a depends flag on do_install. The
intent is to have kernelsrc.bbclass do this, looking at the things there
(such as setting S=), I suspect it may not be fit for purpose. We could
adjust the class to check for a variable and set up the dependency if
its set.
Anyhow, this does need thought and discussion but I'm putting it here as
a start to that, and to let people like Bruce see and experiment with
the code below.
I'll blend your RFC with what I have on the cooker today and see if I
can get a patch out ASAP.
I still think it is worth working through these issues and pushing
forward, we risk slipping deeper into the release if we drop everything
and start over.
As we all know, the code is complex and we have many workflows
to support, and I know I'm churning as fast as I can on fixes.
Bruce
A couple of first pass questions below prior to applying and testing
myself...
Cheers,
Richard
diff --git a/meta/classes/kernel-module-split.bbclass
b/meta/classes/kernel-module-split.bbclass
index 9a95b72..2d43b51 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -70,7 +70,7 @@ python split_kernel_module_packages () {
m = kerverrexp.match(kernelver)
if m:
kernelver_stripped = m.group(1)
-staging_kernel_dir = d.getVar(STAGING_KERNEL_DIR, True)
+staging_kernel_dir = d.getVar(STAGING_KERNEL_BUILDDIR, True)
system_map_file = %s/boot/System.map-%s % (dvar, kernelver)
if
Re: [OE-core] [PATCH 2/3] module.bbclass: Add KERNEL_SRC in EXTRA_OEMAKE
On Wed, Jan 7, 2015 at 12:25 PM, Otavio Salvador
ota...@ossystems.com.br wrote:
When the sstate hash changes for do_configure task, the do_configure
default implementation triggers the 'clean' to be run. For it to
succeed we need to have KERNEL_SRC defined in EXTRA_OEMAKE. Fixes
following error:
I wanted to reproduce this locally, since I've never seen the problem
myself.
What's the best way to trigger the sstate hash change ?
I also have a question below ...
,
| DEBUG: Executing shell function do_configure
| NOTE: make -e MAKEFLAGS= clean
| make -C M=.../tmp/work/... clean
| make[1]: *** M=.../tmp/work/...: No such file or directory. Stop.
| Makefile:20: recipe for target 'clean' failed
| make: *** [clean] Error 2
| ERROR: oe_runmake failed
`
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/classes/module.bbclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes/module.bbclass b/meta/classes/module.bbclass
index ad6f7af..5cb8623 100644
--- a/meta/classes/module.bbclass
+++ b/meta/classes/module.bbclass
@@ -6,10 +6,11 @@ addtask make_scripts after do_patch before do_compile
do_make_scripts[lockfiles] = ${TMPDIR}/kernel-scripts.lock
do_make_scripts[deptask] = do_populate_sysroot
+EXTRA_OEMAKE += KERNEL_SRC=${STAGING_KERNEL_DIR}
+
I'm not seeing very well at the moment and my ability to browse the code
is restricted, so bear with a potentially stupid question.
It's clear from the error message above why this is needed, but I'm not
seeing the code that is respecting/using KERNEL_SRC to trigger the
clean in the right directory. Where exactly is this being used (I know your
related base.bbclass change will pull in the extra make args, but I'm just
not seeing the Makefile that respects it).
Basically, I'm trying to decide if it would be better to handle this all in
the module class, and add a do_configure to the do_compile and
do_install we already have.
Since I'm not seeing it, others might not as well .. and we can enhance the
comments to make it clear.
Bruce
module_do_compile() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR} \
- KERNEL_SRC=${STAGING_KERNEL_DIR}\
KERNEL_VERSION=${KERNEL_VERSION}\
CC=${KERNEL_CC} LD=${KERNEL_LD} \
AR=${KERNEL_AR} \
@@ -19,7 +20,6 @@ module_do_compile() {
module_do_install() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
oe_runmake DEPMOD=echo INSTALL_MOD_PATH=${D} \
- KERNEL_SRC=${STAGING_KERNEL_DIR} \
CC=${KERNEL_CC} LD=${KERNEL_LD} \
modules_install
}
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] RFC: Further kernel build process changes?
I'm hearing (somewhat justified) complaints that the recent kernel
changes have destablised builds. Part of the question is whether the
recent changes are as clear to users as they could be, we're also
running into some problems due to mixing kernel source and build
artefacts in some places and not in others.
At this point I think it may be worth looking at making some more
invasive but decisive changes, specifically that:
STAGING_KERNEL_DIR moves
from sysroots/MACHINE/usr/src/kernel
to work-shared/MACHINE/kernel-source
This is to make it clearer that the source here is not under the control
of sstate. The reasons why we don't want it under the control of sstate
are in other emails.
The second change would be to split the kernel source into two:
work-shared/MACHINE/kernel-source
work-shared/MACHINE/kernel-build
where kernel-build is the kernel build output and kernel-source is kept
pristine.
This means the defconfig, the kernel-abiversion, System.map files and
output from make scripts would be in kernel-build.
External module builds do work in this configuration *if* you pass in
the correct options e.g.:
make -C work-shared/MACHINE/kernel-source O=work-shared/MACHINE/kernel-build
M=${S}
I've put together a quick proof of concept of this below.
There are two other things up for discussion. There is of confusion on
how the kernel source gets into STAGING_KERNEL_DIR in the first place.
We've added in munging code which does this in kernel.bbclass,
linux-yocto also has its share of crazy mess in this regard.
We could wipe the slate clean and require that people put a parameter
against the element in SRC_URI that represents the kernel indicating it
should be directly extracted to STAGING_KERNEL_DIR. There is a bitbake
issue with being unable to override the extraction directory at present
but that can be fixed. The upside is that it would be clean, relatively
clear and allow fragile code to be dropped. The downside is it means
tweaking all kernel recipes.
The second issue is that of the dependency to populate
STAGING_KERNEL_DIR which is now a depends flag on do_install. The
intent is to have kernelsrc.bbclass do this, looking at the things there
(such as setting S=), I suspect it may not be fit for purpose. We could
adjust the class to check for a variable and set up the dependency if
its set.
Anyhow, this does need thought and discussion but I'm putting it here as
a start to that, and to let people like Bruce see and experiment with
the code below.
Cheers,
Richard
diff --git a/meta/classes/kernel-module-split.bbclass
b/meta/classes/kernel-module-split.bbclass
index 9a95b72..2d43b51 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -70,7 +70,7 @@ python split_kernel_module_packages () {
m = kerverrexp.match(kernelver)
if m:
kernelver_stripped = m.group(1)
-staging_kernel_dir = d.getVar(STAGING_KERNEL_DIR, True)
+staging_kernel_dir = d.getVar(STAGING_KERNEL_BUILDDIR, True)
system_map_file = %s/boot/System.map-%s % (dvar, kernelver)
if not os.path.exists(system_map_file):
system_map_file = %s/System.map-%s % (staging_kernel_dir,
kernelver)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 5cabc2c..b1a1ccf 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -249,6 +249,10 @@ kernel_do_install() {
cp .config $kerneldir/
mkdir -p $kerneldir/include/config
cp include/config/kernel.release
$kerneldir/include/config/kernel.release
+ if [ -e include/linux/version.h ]; then
+ mkdir -p $kerneldir/include/linux
+ cp include/linux/version.h $kerneldir/include/linux/version.h
+ fi
# As of Linux kernel version 3.0.1, the clean target removes
# arch/powerpc/lib/crtsavres.o which is present in
@@ -268,6 +272,45 @@ kernel_do_install() {
}
do_install[prefuncs] += package_get_auto_pr
+addtask do_shared_workdir after do_compile before do_install
+
+do_shared_workdir () {
+ cd ${B}
+
+ kerneldir=${STAGING_KERNEL_BUILDDIR}
+ install -d $kerneldir
+
+ #
+ # Store the kernel version in sysroots for module-base.bbclass
+ #
+
+ echo ${KERNEL_VERSION} $kerneldir/kernel-abiversion
+
+ # Copy files required for module builds
+ cp System.map $kerneldir/System.map-${KERNEL_VERSION}
+ cp Module.symvers $kerneldir/
+ cp .config $kerneldir/
+ mkdir -p $kerneldir/include/config
+ cp include/config/kernel.release
$kerneldir/include/config/kernel.release
+
+ # As of Linux kernel version 3.0.1, the clean target removes
+ # arch/powerpc/lib/crtsavres.o which is present in
+ # KBUILD_LDFLAGS_MODULE, making it required to build external modules.
+ if [ ${ARCH} = powerpc ]; then
+ mkdir -p $kerneldir/arch/powerpc/lib/
+
Re: [OE-core] [RFC PATCH] package.bbclass: omit .pyc and .pyo file
On 01/07/2015 12:16 PM, Burton, Ross wrote:
On 7 January 2015 at 09:23, Mike Looijmans mike.looijm...@topic.nl
mailto:mike.looijm...@topic.nl wrote:
You definitely SHOULD ship the .pyc files. If they don't exist, the
interpreter is forced to re-compile the .py source, and will attempt to
write the result to the filesystem. It won't cause harm, it won't fail,
but it's very inefficient. It's better to let the host do the py-pyc
conversion anyway.
The opposite works just fine: You can omit the .py files and ship only
.pyc files. We do that on settopboxes that use Python for the GUI, this
saves several megabytes of flash space.
To accomplish that, we put the .py files into a $PN-src package.
I agree with Mike, there is a use-case for just shipping .pyc. Whether
oe-core should do something to assist with this or not is debatable.
We currently have this in a python_2.7.%.bbappend:
PACKAGES =+ ${PN}-src
RDEPENDS_{PN}-src = ${PN}
FILES_${PN}-src += ${libdir}/python${PYTHON_MAJMIN}/*.py
FILES_${PN}-src += ${libdir}/python${PYTHON_MAJMIN}/*/*.py
FILES_${PN}-src += ${libdir}/python${PYTHON_MAJMIN}/*/*/*.py
This moves all sources into a single package. I experimented with creating src
packages for each python sub-package, but all that accomplished was adding a
lot of packages to the feed that no one would ever install.
I patched the larger Python recipes (e.g. twisted) in similar ways to reduce
the image size (and network traffic).
A generic please remove or split all .py files flag or class would be a
useful addition.
There's an open bug report about this:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=6434.
https://docs.python.org/2/tutorial/modules.html#compiled-python-files has the
details we're after. Summary:
.pyc is Python bytecode, which is an implementation detail of CPython. As
such it's version-dependent but explicitly architecture-independent.
.pyo generated with -O is simply .pyc but with asserts removed.
.pyo generated with -O -O has asserts and docstrings removed.
For horrible historic reasons OpenPLi (and its many forks) still use a patch
that makes .pyo files the default instead of .pyc. It's been on my todo list
for over a year now to get rid of it, but too many plugins and 3rd party stuff
still count on this being the case.
I think it's fair to say we should just ignore .pyo - no point generating and
shipping it. It does seem that if we want to ship usable .pyc we need to
ensure that they are compiled with python-native. I guess this could be done
by calling python-native's compileall module to recompile the sources at
package time.
I'd expect any halfway decent recipe to have done that already in the
do_compile step. Most, if not all, Python recipes already do so. If anything,
the core could provide a class that provides a simple do_compile that calls
compileall on the source dir.
Moving this to packaging will lead to unexpected failures, there are some
situations where the source .py file must be installed and the .pyc will be
ignored. A simple example is when the .py script is the application entry
point, those aren't compiled into pyc at runtime, and adding a pyc would be a
waste. Only the package's makefile (or whatever) can be expected to know that.
Mike.
Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax: (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl
Please consider the environment before printing this e-mail
Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Further kernel build process changes?
On 2015-01-07 7:26 AM, Richard Purdie wrote:
I'm hearing (somewhat justified) complaints that the recent kernel
changes have destablised builds. Part of the question is whether the
recent changes are as clear to users as they could be, we're also
running into some problems due to mixing kernel source and build
artefacts in some places and not in others.
And we've been bitten by the sheer diversity in the various additions
and tweaks to the kernel build process .. which when wading in to try
and make some improvements was always the risk :(
At this point I think it may be worth looking at making some more
invasive but decisive changes, specifically that:
STAGING_KERNEL_DIR moves
from sysroots/MACHINE/usr/src/kernel
to work-shared/MACHINE/kernel-source
This is to make it clearer that the source here is not under the control
of sstate. The reasons why we don't want it under the control of sstate
are in other emails.
I'm in agreement here.
The second change would be to split the kernel source into two:
work-shared/MACHINE/kernel-source
work-shared/MACHINE/kernel-build
where kernel-build is the kernel build output and kernel-source is kept
pristine.
This means the defconfig, the kernel-abiversion, System.map files and
output from make scripts would be in kernel-build.
Exactly. When setting up the minimal external module build environment,
to keep the impact in the shared directories small, I went with the
current approach.
Since we are breaking workflows with it .. this would be a good balance
between the old and new efforts. I started mocking this up over the holidays
but lost a week due to illness. I'll continue running with this now.
External module builds do work in this configuration *if* you pass in
the correct options e.g.:
make -C work-shared/MACHINE/kernel-source O=work-shared/MACHINE/kernel-build
M=${S}
I've put together a quick proof of concept of this below.
There are two other things up for discussion. There is of confusion on
how the kernel source gets into STAGING_KERNEL_DIR in the first place.
We've added in munging code which does this in kernel.bbclass,
linux-yocto also has its share of crazy mess in this regard.
:)
We could wipe the slate clean and require that people put a parameter
against the element in SRC_URI that represents the kernel indicating it
should be directly extracted to STAGING_KERNEL_DIR. There is a bitbake
issue with being unable to override the extraction directory at present
but that can be fixed. The upside is that it would be clean, relatively
clear and allow fragile code to be dropped. The downside is it means
tweaking all kernel recipes.
The second issue is that of the dependency to populate
STAGING_KERNEL_DIR which is now a depends flag on do_install. The
intent is to have kernelsrc.bbclass do this, looking at the things there
(such as setting S=), I suspect it may not be fit for purpose. We could
adjust the class to check for a variable and set up the dependency if
its set.
Anyhow, this does need thought and discussion but I'm putting it here as
a start to that, and to let people like Bruce see and experiment with
the code below.
I'll blend your RFC with what I have on the cooker today and see if I
can get a patch out ASAP.
I still think it is worth working through these issues and pushing
forward, we risk slipping deeper into the release if we drop everything
and start over.
As we all know, the code is complex and we have many workflows
to support, and I know I'm churning as fast as I can on fixes.
Bruce
Cheers,
Richard
diff --git a/meta/classes/kernel-module-split.bbclass
b/meta/classes/kernel-module-split.bbclass
index 9a95b72..2d43b51 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -70,7 +70,7 @@ python split_kernel_module_packages () {
m = kerverrexp.match(kernelver)
if m:
kernelver_stripped = m.group(1)
-staging_kernel_dir = d.getVar(STAGING_KERNEL_DIR, True)
+staging_kernel_dir = d.getVar(STAGING_KERNEL_BUILDDIR, True)
system_map_file = %s/boot/System.map-%s % (dvar, kernelver)
if not os.path.exists(system_map_file):
system_map_file = %s/System.map-%s % (staging_kernel_dir,
kernelver)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 5cabc2c..b1a1ccf 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -249,6 +249,10 @@ kernel_do_install() {
cp .config $kerneldir/
mkdir -p $kerneldir/include/config
cp include/config/kernel.release
$kerneldir/include/config/kernel.release
+ if [ -e include/linux/version.h ]; then
+ mkdir -p $kerneldir/include/linux
+ cp include/linux/version.h $kerneldir/include/linux/version.h
+ fi
# As of Linux kernel version 3.0.1, the clean target removes
# arch/powerpc/lib/crtsavres.o which is present in
@@ -268,6
[OE-core] [PATCH 2/4] git: upgrade to 2.2.1
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
.../git/{git_2.2.0.bb = git_2.2.1.bb} |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-devtools/git/{git_2.2.0.bb = git_2.2.1.bb} (61%)
diff --git a/meta/recipes-devtools/git/git_2.2.0.bb
b/meta/recipes-devtools/git/git_2.2.1.bb
similarity index 61%
rename from meta/recipes-devtools/git/git_2.2.0.bb
rename to meta/recipes-devtools/git/git_2.2.1.bb
index 7341d98..2d47cda 100644
--- a/meta/recipes-devtools/git/git_2.2.0.bb
+++ b/meta/recipes-devtools/git/git_2.2.1.bb
@@ -1,7 +1,7 @@
require git.inc
-SRC_URI[md5sum] = 2d5bbcc3e887cc4ba499f80420e2d5f7
-SRC_URI[sha256sum] =
bea9548f5a39daaf7c3873b6a5be47d7f92cbf42d32957e1be955a2e0e7b83b4
+SRC_URI[md5sum] = ff41fdb094eed1ec430aed8ee9b9849c
+SRC_URI[sha256sum] =
367a77d0b10a5070b02a0fb0e942f26f25af61793128e0ddfd5c5c474de93589
EXTRA_OECONF += ac_cv_snprintf_returns_bogus=no ac_cv_c_c99_format=yes \
ac_cv_fread_reads_directories=${ac_cv_fread_reads_directories=yes} \
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 0/2] combo-layer: support updating up to arbitrary commit
I split my changeset into two separate patches. Also, fixed a bug when doing calling pull inside the update action. Markus Lehtonen (2): combo-layer: minor refactor combo-layer: support updating up to arbitrary commit scripts/combo-layer | 45 +++-- 1 file changed, 27 insertions(+), 18 deletions(-) -- 1.8.4.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] module.bbclass: Add KERNEL_SRC in EXTRA_OEMAKE
When the sstate hash changes for do_configure task, the do_configure
default implementation triggers the 'clean' to be run. For it to
succeed we need to have KERNEL_SRC defined in EXTRA_OEMAKE. Fixes
following error:
,
| DEBUG: Executing shell function do_configure
| NOTE: make -e MAKEFLAGS= clean
| make -C M=.../tmp/work/... clean
| make[1]: *** M=.../tmp/work/...: No such file or directory. Stop.
| Makefile:20: recipe for target 'clean' failed
| make: *** [clean] Error 2
| ERROR: oe_runmake failed
`
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/classes/module.bbclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes/module.bbclass b/meta/classes/module.bbclass
index ad6f7af..5cb8623 100644
--- a/meta/classes/module.bbclass
+++ b/meta/classes/module.bbclass
@@ -6,10 +6,11 @@ addtask make_scripts after do_patch before do_compile
do_make_scripts[lockfiles] = ${TMPDIR}/kernel-scripts.lock
do_make_scripts[deptask] = do_populate_sysroot
+EXTRA_OEMAKE += KERNEL_SRC=${STAGING_KERNEL_DIR}
+
module_do_compile() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR} \
- KERNEL_SRC=${STAGING_KERNEL_DIR}\
KERNEL_VERSION=${KERNEL_VERSION}\
CC=${KERNEL_CC} LD=${KERNEL_LD} \
AR=${KERNEL_AR} \
@@ -19,7 +20,6 @@ module_do_compile() {
module_do_install() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
oe_runmake DEPMOD=echo INSTALL_MOD_PATH=${D} \
- KERNEL_SRC=${STAGING_KERNEL_DIR} \
CC=${KERNEL_CC} LD=${KERNEL_LD} \
modules_install
}
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] kernel.bbclass: When linux/version.h exists, copy it
Old Linux kernel versions rely on linux/version.h for modules; this
needs to be published for external modules to use. Copy it when
available.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/classes/kernel.bbclass | 4
1 file changed, 4 insertions(+)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 88356b1..78c8c7c 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -252,6 +252,10 @@ kernel_do_install() {
cp .config $kerneldir/
mkdir -p $kerneldir/include/config
cp include/config/kernel.release
$kerneldir/include/config/kernel.release
+ if [ -e include/linux/version.h ]; then
+ mkdir -p $kerneldir/include/linux
+ cp include/linux/version.h $kerneldir/include/linux/version.h
+ fi
# As of Linux kernel version 3.0.1, the clean target removes
# arch/powerpc/lib/crtsavres.o which is present in
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] base.bbclass: Avoid explicit ${MAKE} in do_configure
The do_configure may eventually call 'make clean' when the sstate
signature does not match. We should respect EXTRA_OEMAKE when doing
so, so use 'oe_runmake' for it.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/classes/base.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index b8f61f3..de50be1 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -227,7 +227,7 @@ base_do_configure() {
if [ `cat ${CONFIGURESTAMPFILE}` != ${BB_TASKHASH} ]; then
cd ${B}
if [ ${CLEANBROKEN} != 1 -a \( -e Makefile -o -e
makefile -o -e GNUmakefile \) ]; then
- ${MAKE} clean
+ oe_runmake clean
fi
find ${B} -name \*.la -delete
fi
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
