Re: [OE-core] [PATCH v3] libsanitizer: Enable GCC sanitizers
On 10 December 2014 at 05:58, Burton, Ross wrote:
> Hi Dan,
>
> On 13 November 2014 at 23:35, Dan McGregor
> wrote:
>>
>> Looks like I needed to use the same security CFLAGS as gcc-runtime and
>> libgcc. There's a new version up on my bitbucket page.
>
>
> I see you're still using anonymous python instead of COMPATIBLE_HOST to mark
> what architectures the sanitizers work on, can you change that?
>
> For packagegroups, if my recollection is correct and the problem is that a
> packagegroup wants to depend on packages which are architecture-specific, a
> common trick is to do something like this:
Yeah, that was the problem. For this round I bit the bullet and made
the package group arch specific, and I got rid of the anonymous
python. I originally put that there so that it would parse the recipe
and not barf on arches where the sanitizer libraries are not
supported.
I think this looks better though, I was struggling with getting them
into a all arch package group.
>
> SANITIZERS="gcc-sanitizer"
> SANITIZSERS_mips = ""
>
> RDEPENDS_packagegroup_foo = "${SANITIZERS}"
>
> (see the tools-profile packagegroup which does this heavily)
>
> Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 0/7] Developer workflow improvements
On 12/11/14 16:35, Paul Eggleton wrote: > Thanks for the quick bisect - I've fixed it so that wrapper is only used when > running bitbake through "devtool build", and now "devtool add" works properly > again. This is why I should probably write some proper tests before trying to > do anything further... It works great now, thanks! -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 0/7] Developer workflow improvements
I think *this* thread (and question) got lost in the shuffle... On 12/09/14 10:47, Trevor Woerner wrote: > On 12/02/14 09:01, Paul Eggleton wrote: >> On Monday 01 December 2014 23:54:03 Trevor Woerner wrote: >>> On 11/25/14 12:28, Paul Eggleton wrote: I've then added a new recipe auto-creation script, recipetool, which can take a source tree or URL and create a skeleton recipe to build it. >>> ... >>> * "recipetool create" ideally needs to become smarter and fill in more details of the recipe. At some point we'll probably have to make the process interactive and possibly have it automate parts of the build process and examine the output; some things just can't be practically detected from the source tree without building. >>> There is a tool "autoscan" which might be of some use here. If nothing >>> else, the resulting configure.scan file could be parsed for DEPENDS >>> information and perhaps PACKAGECONFIG items too. >> Interesting - I was not aware of this tool. I've added support for running >> it >> as well as picking converting AC_CHECK_LIB lines over to DEPENDS (with a >> note >> about some of them possibly being optional). Thanks! >> > Finding "AC_PATH_X" in "configure.scan" is probably a good indication > there's an RDEPENDS on "libx11". Maybe "recipetool" could check for that? *ping*!! Oddly enough, the default recipe even says: # NOTE: the following library dependencies are unknown, ignoring: X11 Why is it ignoring x11? Coincidentally the code I'm testing this with has a dependency on X11 and when I try building, bitbake throws out an RDEPENDS warning. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] insane.bbclass: Added QA test for expanded ${D}
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
---
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)
+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
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 0/7] Developer workflow improvements
On Thursday 11 December 2014 14:43:40 Trevor Woerner wrote: > On 12/11/14 14:16, Trevor Woerner wrote: > > Oops! (this worked before the "git pull") > > > > $ devtool add xannounce ~/devel/yocto/build/workflow/xannounce/ > > NOTE: Creating workspace layer in > > /home/trevor/devel/yocto/build/workflow/build/workspace > > NOTE: Recipe > > /home/trevor/devel/yocto/build/workflow/build/workspace/recipes/xannou > > nce/xannounce.bb has been automatically created; further editing may > > be required to make it fully functional > > > > Traceback (most recent call last): > > File > > > > "/home/trevor/devel/yocto/build/workflow/meta-poky/scripts/devtool", > > line 274, in > > > > ret = main() > > > > File > > > > "/home/trevor/devel/yocto/build/workflow/meta-poky/scripts/devtool", > > line 267, in main > > > > ret = args.func(args, config, basepath, workspace) > > > > File > > > > "/home/trevor/devel/yocto/build/workflow/meta-poky/scripts/lib/devtool > > /standard.py", line 68, in add > > > > _add_md5(config, args.recipename, recipefile) > > > > File > > > > "/home/trevor/devel/yocto/build/workflow/meta-poky/scripts/lib/devtool > > /standard.py", line 218, in _add_md5 > > > > md5 = bb.utils.md5_file(filename) > > > > File > > > > "/home/trevor/devel/yocto/build/workflow/meta-poky/bitbake/lib/bb/util > > s.py", line 463, in md5_file > > > > with open(filename, "rb") as f: > > IOError: [Errno 2] No such file or directory: > > '/home/trevor/devel/yocto/build/workflow/build/workspace/recipes/xanno > > unce/xannounce.bb'> > > Sure enough... > > > > $ devtool-workflow> tree workspace/ > > workspace/ > > > > |-- appends > > |-- conf > > | > > | `-- layer.conf > > > > `-- recipes > > > > `-- xannounce > > > > 4 directories, 1 file > > > > whereas before it was: > > $ tree workspace/ > > workspace/ > > > > |-- appends > > | > > | `-- xannounce.bbappend > > | > > |-- conf > > | > > | `-- layer.conf > > > > `-- recipes > > > > `-- xannounce > > > > `-- xannounce.bb > > > > 4 directories, 3 files > > > > For some reason my recipe and bbappends are not getting created :-( > > bisecting (manually) leads to this commit being safe: > > ea50ec527483eb3a094588858baebd5fb23f71c6 devtool: rename deploy/undeploy > to deploy-target/undeploy-target > > and this one introducing the problem: > > 770f203f73f358ce3c6c5ac12fe2775b812bdc6b devtool: fool bitbake into > thinking it's outputting to a terminal Thanks for the quick bisect - I've fixed it so that wrapper is only used when running bitbake through "devtool build", and now "devtool add" works properly again. This is why I should probably write some proper tests before trying to do anything further... 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] [v2 PATCH 0/9] kernel: version updates
On Thu, Dec 11, 2014 at 10:35 AM, Burton, Ross wrote: > > On 11 December 2014 at 15:26, Bruce Ashfield > wrote: >> >> Do we want to leave the series as is, and I can send it as an incremental >> patch, or would you rather it squashed and the branches updated ? > > > Squash and re-push would be best. Done. Both the zedd/kernel and zedd/kernel-updates are repushed with the patches merged. Bruce > > Cheers, > Ross -- "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] [v2 PATCH 0/9] kernel: version updates
On Thu, 2014-12-11 at 10:45 -0600, Tom Zanussi wrote: > On Thu, 2014-12-11 at 14:56 +, Richard Purdie wrote: > > On Thu, 2014-12-11 at 13:58 +, Richard Purdie wrote: > > > On Thu, 2014-12-11 at 03:31 -0500, Bruce Ashfield wrote: > > > > On Wed, Dec 10, 2014 at 10:02 AM, Burton, Ross > > > > wrote: > > > > > > > > > > On 10 December 2014 at 14:16, Bruce Ashfield > > > > > > > > > > wrote: > > > > >> > > > > >> The following changes since commit > > > > >> 88dfcbf149dda89277e58ae4ec3a87500624cfff: > > > > >> > > > > >> kernel-yocto: make sure git tags get dereferenced properly in > > > > >> do_patch() > > > > >> (2014-12-10 08:12:56 -0500) > > > > >> > > > > >> are available in the git repository at: > > > > >> > > > > >> git://git.pokylinux.org/poky-contrib HEAD > > > > > > > > > > > > > > > I wonder what happened here! > > > > > > > > @#!$#@$ the script is insane. > > > > > > > > > > > > > >> > > > > >> for you to fetch changes up to > > > > >> 4be985be419f06f18c735d72ac4a4d00fea71dd8: > > > > >> > > > > >> linux-yocto/3.14: update to 3.14.26, integrate ltsi and -rt updates > > > > >> (2014-12-10 08:38:49 -0500) > > > > > > > > > > > > > > > That's zedd/kernel-updates, right? > > > > > > > > > > > > > Yah. Sorry about the confusion, > > > > > > I've been experimenting, the upgrades look good but we have a problem > > > with the new kernel class changes. > > > > > > The issue is that if you have an existing TMPDIR, the build will do "bad > > > things". > > > > > > Basically, there is usually an existing sstate manifest file which > > > covers the kernel source in the sysroot. do_configure will trigger > > > cleaning of that manifest, a large chunk of the source disappears and > > > then the build understandably fails. > > > > > > Whilst I can say what is happening, I can't say how we fix it at this > > > point :/. > > > > > > I would like people to test these patches, we'd better hold off merging > > > until we can get this issue figured out. Its part of a wider problem > > > with "stale" data in the sysroot which we really need to figure out but > > > its not been solved yet as its a very hard problem for which we don't > > > have a solution :(. > > > > After quite some thinking, I've come up with the patch below which > > should at least allow us to get this patch series merged. Obviously I > > need to split this up and send it out properly with a decent commit log > > but I thought I'd share it sooner than later. > > > > I tried this on an old romley build and got this: > > http://pastebin.com/WetCnesw > > I then switched to nuc using the same tmpdir and that kernel built fine. > > Note that the romley build uses the 3.10 kernel and the nuc build uses > the 3.17 kernel - I don't know if that could account for the difference, > or if it was more due to the fact that I did the romley build first and > then the nuc, and if I'd done it in the reverse order it would have been > the nuc failing instead. Or something else... > So, when I switched back to the romley machine and tried again, the kernel built without error. But.. I went back and reproduced the starting point, which I'll post here to make it easy for anyone to reproduce, using the following commits: poky: f19b4e995ea47f9243f152b39337330307453c9f meta-intel: a72da6350e7a77256ad597e8e8c40909590a2a40 And verified the romley case again, and also saw the same thing with nuc, which uses the 3.17 kernel. In both cases the build failed and the kernel source directory was empty e.g.: /usr/local/dev/yocto/isg-test/build/tmp/sysroots/romley/usr/src/kernel Switching to romley built fine, and switching back after that the nuc kernel built fine again, and the kernel source dirs were populated in both cases. Below is the output from the nuc build: [trz@medianoche build]$ bitbake virtual/kernel NOTE: Converting staging layout from version 8/9 to layout version 10 NOTE: Uninstalling manifest file /usr/local/dev/yocto/isg-test/build/tmp/sstate-control/manifest-nuc-linux-yocto.populate_sysroot Parsing recipes: 100% | ##| Time: 00:00:19 Parsing of 916 .bb files complete (0 cached, 916 parsed). 1314 targets, 46 skipped, 0 masked, 0 errors. NOTE: Resolving any missing task queue dependencies Build Configuration: BB_VERSION= "1.25.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Fedora-20" TARGET_SYS= "x86_64-poky-linux" MACHINE = "nuc" DISTRO= "poky" DISTRO_VERSION= "1.7" TUNE_FEATURES = "m64 corei7" TARGET_FPU= "" meta meta-yocto meta-yocto-bsp= "zedd-kernel-updates0:3554105e81a2084f23cae9fef8db8c7a1c4f7c04" meta-intel meta-crownbay meta-nuc meta-romley = "master20:a72da6350e7a77256ad597e8e8c40909590a2a40" NOTE: Preparing RunQueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks ERROR: Function failed: do_kernel_checkout (log file
Re: [OE-core] [RFC PATCH 0/7] Developer workflow improvements
bisecting (manually) leads to this commit being safe: ea50ec527483eb3a094588858baebd5fb23f71c6 devtool: rename deploy/undeploy to deploy-target/undeploy-target and this one introducing the problem: 770f203f73f358ce3c6c5ac12fe2775b812bdc6b devtool: fool bitbake into thinking it's outputting to a terminal On 12/11/14 14:16, Trevor Woerner wrote: > Oops! (this worked before the "git pull") > > $ devtool add xannounce ~/devel/yocto/build/workflow/xannounce/ > NOTE: Creating workspace layer in > /home/trevor/devel/yocto/build/workflow/build/workspace > NOTE: Recipe > > /home/trevor/devel/yocto/build/workflow/build/workspace/recipes/xannounce/xannounce.bb > has been automatically created; further editing may be required to > make it fully functional > Traceback (most recent call last): > File > "/home/trevor/devel/yocto/build/workflow/meta-poky/scripts/devtool", > line 274, in > ret = main() > File > "/home/trevor/devel/yocto/build/workflow/meta-poky/scripts/devtool", > line 267, in main > ret = args.func(args, config, basepath, workspace) > File > > "/home/trevor/devel/yocto/build/workflow/meta-poky/scripts/lib/devtool/standard.py", > line 68, in add > _add_md5(config, args.recipename, recipefile) > File > > "/home/trevor/devel/yocto/build/workflow/meta-poky/scripts/lib/devtool/standard.py", > line 218, in _add_md5 > md5 = bb.utils.md5_file(filename) > File > > "/home/trevor/devel/yocto/build/workflow/meta-poky/bitbake/lib/bb/utils.py", > line 463, in md5_file > with open(filename, "rb") as f: > IOError: [Errno 2] No such file or directory: > > '/home/trevor/devel/yocto/build/workflow/build/workspace/recipes/xannounce/xannounce.bb' > > Sure enough... > > $ devtool-workflow> tree workspace/ > workspace/ > |-- appends > |-- conf > | `-- layer.conf > `-- recipes > `-- xannounce > > 4 directories, 1 file > > > whereas before it was: > > $ tree workspace/ > workspace/ > |-- appends > | `-- xannounce.bbappend > |-- conf > | `-- layer.conf > `-- recipes > `-- xannounce > `-- xannounce.bb > > 4 directories, 3 files > > For some reason my recipe and bbappends are not getting created :-( -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 0/7] Developer workflow improvements
Oops! (this worked before the "git pull") $ devtool add xannounce ~/devel/yocto/build/workflow/xannounce/ NOTE: Creating workspace layer in /home/trevor/devel/yocto/build/workflow/build/workspace NOTE: Recipe /home/trevor/devel/yocto/build/workflow/build/workspace/recipes/xannounce/xannounce.bb has been automatically created; further editing may be required to make it fully functional Traceback (most recent call last): File "/home/trevor/devel/yocto/build/workflow/meta-poky/scripts/devtool", line 274, in ret = main() File "/home/trevor/devel/yocto/build/workflow/meta-poky/scripts/devtool", line 267, in main ret = args.func(args, config, basepath, workspace) File "/home/trevor/devel/yocto/build/workflow/meta-poky/scripts/lib/devtool/standard.py", line 68, in add _add_md5(config, args.recipename, recipefile) File "/home/trevor/devel/yocto/build/workflow/meta-poky/scripts/lib/devtool/standard.py", line 218, in _add_md5 md5 = bb.utils.md5_file(filename) File "/home/trevor/devel/yocto/build/workflow/meta-poky/bitbake/lib/bb/utils.py", line 463, in md5_file with open(filename, "rb") as f: IOError: [Errno 2] No such file or directory: '/home/trevor/devel/yocto/build/workflow/build/workspace/recipes/xannounce/xannounce.bb' Sure enough... $ devtool-workflow> tree workspace/ workspace/ |-- appends |-- conf | `-- layer.conf `-- recipes `-- xannounce 4 directories, 1 file whereas before it was: $ tree workspace/ workspace/ |-- appends | `-- xannounce.bbappend |-- conf | `-- layer.conf `-- recipes `-- xannounce `-- xannounce.bb 4 directories, 3 files For some reason my recipe and bbappends are not getting created :-( -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 0/7] Developer workflow improvements
On Thursday 11 December 2014 13:30:01 Trevor Woerner wrote:
> Awesome!! I'm giving this update a whirl right now...
>
> ...just one small nit... in commit
> 7d2c6430131ccf94b8bdc185b8cd849fe479d552 the warning message says:
>
> +lines_before.append('# NOTE: LICENSE is being set to "CLOSED"
> to allow you to at least start building - if')
> +lines_before.append('# this is not accurate with respect to the
> licensing of the software being built (it')
> +lines_before.append('# will not be for in most cases) you must
> specify the correct value before using this')
> +lines_before.append('# recipe for anything other than initial
> testing/development!')
>
> Is the "for" in "it will not be for in most cases" out of place? Perhaps
> replace with "so", "true" or "accurate"?
Ah yes - fixed, thanks :)
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
[OE-core] [PATCH] qemu: disable vte if gtk is also disabled
vte will pull in the gtk libs itself. This can cause build failures if the native gtk was build with glib>=2.41 while the sysroot native glib is <=2.40. Fix for [YOCTO #7077]. Signed-off-by: Richard Tollerton --- meta/recipes-devtools/qemu/qemu.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-devtools/qemu/qemu.inc b/meta/recipes-devtools/qemu/qemu.inc index 3f68a56..c9a5d32 100644 --- a/meta/recipes-devtools/qemu/qemu.inc +++ b/meta/recipes-devtools/qemu/qemu.inc @@ -104,7 +104,7 @@ PACKAGECONFIG[libcurl] = "--enable-curl,--disable-curl,libcurl," PACKAGECONFIG[nss] = "--enable-smartcard-nss,--disable-smartcard-nss,nss," PACKAGECONFIG[uuid] = "--enable-uuid,--disable-uuid,util-linux," PACKAGECONFIG[curses] = "--enable-curses,--disable-curses,ncurses," -PACKAGECONFIG[gtk+] = "--enable-gtk,--disable-gtk,gtk+ libvte," +PACKAGECONFIG[gtk+] = "--enable-gtk --enable-vte,--disable-gtk --disable-vte,gtk+ libvte," PACKAGECONFIG[libcap-ng] = "--enable-cap-ng,--disable-cap-ng,libcap-ng," PACKAGECONFIG[ssh2] = "--enable-libssh2,--disable-libssh2,libssh2," PACKAGECONFIG[libusb] = "--enable-libusb,--disable-libusb,libusb1" -- 2.1.3 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 0/7] Developer workflow improvements
Awesome!! I'm giving this update a whirl right now...
...just one small nit... in commit
7d2c6430131ccf94b8bdc185b8cd849fe479d552 the warning message says:
+lines_before.append('# NOTE: LICENSE is being set to "CLOSED"
to allow you to at least start building - if')
+lines_before.append('# this is not accurate with respect to the
licensing of the software being built (it')
+lines_before.append('# will not be for in most cases) you must
specify the correct value before using this')
+lines_before.append('# recipe for anything other than initial
testing/development!')
Is the "for" in "it will not be for in most cases" out of place? Perhaps
replace with "so", "true" or "accurate"?
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 0/7] Developer workflow improvements
On Wednesday 10 December 2014 17:51:16 Paul Eggleton wrote: > On Tuesday 09 December 2014 13:58:02 Trevor Woerner wrote: > > On 12/09/14 11:08, Paul Eggleton wrote: > > > "devtool build" isn't strictly required in this phase, I added it > > > primarily to support future usage in the SDK where the intention is to > > > do everything through the devtool command, although that is a usage > > > model that isn't enabled yet. However, it is a convenient shortcut for > > > "bitbake -c install " (which is all you need to do for > > > "devtool deploy" to be able to work.) > > > > True, we did talk about this before. All I'm saying is that the colour > > feature of bitbake is really nice, useful, and helpful (to visually > > parse output) and if we've lost colour because we've wrapped bitbake > > with "devtool build" then we're taking a step backwards. > > > > But I'll concede the point if the future usage in the SDK turns out to > > be really helpful. All I'm saying at this point is I have no idea what > > this future usage might be or what your ideas are for this step, and for > > the time-being (i.e. without knowing or working with this SDK usage) > > "devtool build" is a step backwards from "bitbake". > > OK, understood. I'll have a think about it. I've fixed this on the branch; turns out there is an easy way to fool processes into thinking they are connected to a real terminal and thus have bitbake use the normal colour and terminal handling. > > > "devtool deploy" is not related to do_deploy - it places files for the > > > recipe on a nominated target machine without having to worry about > > > packaging; we have no other equivalent for this at the moment. Perhaps > > > it > > > could have a different name in case the naming overlap is confusing. > > > > Ah yes, sorry I forgot... maybe something more explicit like > > "deploy_to_target"? ;-) > > push_to_target? > > upload_to_target? > > Hmm, perhaps deploy-target would be more in line with the git-style command > naming I've been using. Fixed on the branch. > > LICENSE > > If the tool that creates the recipe can't find any explicit licensing > > information, it leaves LICENCE blank. Would it be better, if there's no > > explicit license, to set it to "CLOSED"? Otherwise the first build will > > fail and the user will have to figure out what to do in order to get the > > recipe to build. > > Possibly yes. Ideally people would take an interest in setting this > properly, but I do recognise that it's not a high priority when you are > just getting started. What might be missing is some kind of modal operation > where during initial development you aren't bothered by all of these recipe > quality checks, but then when it comes to production the checks are > re-enabled. I've made this change on the branch (with an appropriate warning comment preceding it). > > code updates > > Maybe my inexperience with externalsrc is showing through here (I've > > never used it before), but as I play with this new feature, I'm testing > > it by trying to include a very old project I wrote years ago. As luck > > would have it, that project needs updates (it doesn't quite work as-is > > in qemux86/core-image-x11). So here I am going through the cycle of > > working on its source, and building new images. What I've noticed is > > when I create the image I keep getting the same old sources used over > > and over from when I first added this project "devtool add" (and it > > doesn't matter whether I use bitbake or devtool to build it, it even > > keeps using the old sources even when I perform commits in the sources > > and even when I perform a "bitbake -c cleansstate "!). The only > > way I can move forward is to "devtool reset" and then "devtool add". > > > > In my scenario I have a base image I have already built > > (core-image-x11). Now I want to add one package to that image from > > sources found on my local machine. I also want to go through the cycle > > of editing those sources, building a new image, and runqemu'ing the new > > image to test my changes. I can't seem to do that without knowing > > devtool and/or bitbake magic. I either have to "devtool reset" or I have > > to "bitbake -c clean core-image-x11" because just modifying the sources > > doesn't cause the image to be regenerated. > > It's not supposed to behave this way, although I have reproduced it here - I > think I hadn't actually tested rebuilding an image with a recipe in the > workspace added to the image. The problem is that the do_compile task is > being marked as nostamp, but the way bitbake behaves now, that doesn't > cause any dependent task signatures to be changed and thus no dependent > tasks get run afterwards. Either I'll have to change that or work out a > different way of ensuring do_compile and dependent tasks get run - either > way, you should only have to run a build that calls for the recipe (be it > the recipe itself or something that depends upon it), no cleaning/resettin
Re: [OE-core] [v2 PATCH 0/9] kernel: version updates
On Thu, 2014-12-11 at 14:56 +, Richard Purdie wrote:
> On Thu, 2014-12-11 at 13:58 +, Richard Purdie wrote:
> > On Thu, 2014-12-11 at 03:31 -0500, Bruce Ashfield wrote:
> > > On Wed, Dec 10, 2014 at 10:02 AM, Burton, Ross
> > > wrote:
> > > >
> > > > On 10 December 2014 at 14:16, Bruce Ashfield
> > > >
> > > > wrote:
> > > >>
> > > >> The following changes since commit
> > > >> 88dfcbf149dda89277e58ae4ec3a87500624cfff:
> > > >>
> > > >> kernel-yocto: make sure git tags get dereferenced properly in
> > > >> do_patch()
> > > >> (2014-12-10 08:12:56 -0500)
> > > >>
> > > >> are available in the git repository at:
> > > >>
> > > >> git://git.pokylinux.org/poky-contrib HEAD
> > > >
> > > >
> > > > I wonder what happened here!
> > >
> > > @#!$#@$ the script is insane.
> > >
> > > >
> > > >>
> > > >> for you to fetch changes up to
> > > >> 4be985be419f06f18c735d72ac4a4d00fea71dd8:
> > > >>
> > > >> linux-yocto/3.14: update to 3.14.26, integrate ltsi and -rt updates
> > > >> (2014-12-10 08:38:49 -0500)
> > > >
> > > >
> > > > That's zedd/kernel-updates, right?
> > > >
> > >
> > > Yah. Sorry about the confusion,
> >
> > I've been experimenting, the upgrades look good but we have a problem
> > with the new kernel class changes.
> >
> > The issue is that if you have an existing TMPDIR, the build will do "bad
> > things".
> >
> > Basically, there is usually an existing sstate manifest file which
> > covers the kernel source in the sysroot. do_configure will trigger
> > cleaning of that manifest, a large chunk of the source disappears and
> > then the build understandably fails.
> >
> > Whilst I can say what is happening, I can't say how we fix it at this
> > point :/.
> >
> > I would like people to test these patches, we'd better hold off merging
> > until we can get this issue figured out. Its part of a wider problem
> > with "stale" data in the sysroot which we really need to figure out but
> > its not been solved yet as its a very hard problem for which we don't
> > have a solution :(.
>
> After quite some thinking, I've come up with the patch below which
> should at least allow us to get this patch series merged. Obviously I
> need to split this up and send it out properly with a decent commit log
> but I thought I'd share it sooner than later.
>
I tried this on an old romley build and got this:
http://pastebin.com/WetCnesw
I then switched to nuc using the same tmpdir and that kernel built fine.
Note that the romley build uses the 3.10 kernel and the nuc build uses
the 3.17 kernel - I don't know if that could account for the difference,
or if it was more due to the fact that I did the romley build first and
then the nuc, and if I'd done it in the reverse order it would have been
the nuc failing instead. Or something else...
Tom
> Cheers,
>
> Richard
>
>
> From 2495650e76bdee971645b3049b6e65307e506e09 Mon Sep 17 00:00:00 2001
> From: Richard Purdie
> Date: Thu, 11 Dec 2014 14:36:05 +
> Subject: sanity: TMPDIR ABI change for kernel process
>
> Signed-off-by: Richard Purdie
>
> diff --git a/meta-yocto/conf/distro/poky.conf
> b/meta-yocto/conf/distro/poky.conf
> index 72db36d..bea8e04 100644
> --- a/meta-yocto/conf/distro/poky.conf
> +++ b/meta-yocto/conf/distro/poky.conf
> @@ -94,7 +94,7 @@ BB_SIGNATURE_HANDLER ?= 'OEBasicHash'
> # that breaks the format and have been previously discussed on the mailing
> list
> # with general agreement from the core team.
> #
> -OELAYOUT_ABI = "8"
> +OELAYOUT_ABI = "10"
>
> # add poky sanity bbclass
> INHERIT += "poky-sanity"
> diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
> index 5be5efb..71fd2e9 100644
> --- a/meta/classes/sanity.bbclass
> +++ b/meta/classes/sanity.bbclass
> @@ -519,6 +519,16 @@ def sanity_handle_abichanges(status, d):
> status.addresult("Your configuration is using stamp files
> including the sstate hash but your build directory was built with stamp files
> that do not include this.\nTo continue, either rebuild or switch back to the
> OEBasic signature handler with BB_SIGNATURE_HANDLER = 'OEBasic'.\n")
> elif (abi != current_abi and current_abi == "9"):
> status.addresult("The layout of the TMPDIR STAMPS directory has
> changed. Please clean out TMPDIR and rebuild (sstate will be still be valid
> and reused)\n")
> +elif (abi != current_abi and current_abi == "10" and (abi == "8" or
> abi == "9")):
> +bb.note("Converting staging layout from version 8/9 to layout
> version 10")
> +cmd = d.expand("grep -l sysroot-providers/virtual_kernel
> ${SSTATE_MANIFESTS}/*")
> +ret, result = oe.utils.getstatusoutput(cmd)
> +result = result.split()
> +for f in result:
> +bb.note("Uninstalling manifest file %s" % f)
> +sstate_clean_manifest(f, d)
> +with open(abifile, "w") as f:
> +f.write(current_abi)
> elif (abi != cur
Re: [OE-core] [v2 PATCH 0/9] kernel: version updates
On 11 December 2014 at 15:26, Bruce Ashfield wrote: > Do we want to leave the series as is, and I can send it as an incremental > patch, or would you rather it squashed and the branches updated ? > Squash and re-push would be best. Cheers, Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] mesa-demos: Fix building demos which require GLU.
Reverse the sense of the conditional to test for GLU support when built with "--enable-glu". Signed-off-by: Drew Moseley --- ...figure-Allow-to-disable-demos-which-require-GLEW-.patch | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/meta/recipes-graphics/mesa/mesa-demos/0003-configure-Allow-to-disable-demos-which-require-GLEW-.patch b/meta/recipes-graphics/mesa/mesa-demos/0003-configure-Allow-to-disable-demos-which-require-GLEW-.patch index 4b07193..b25f5ce 100644 --- a/meta/recipes-graphics/mesa/mesa-demos/0003-configure-Allow-to-disable-demos-which-require-GLEW-.patch +++ b/meta/recipes-graphics/mesa/mesa-demos/0003-configure-Allow-to-disable-demos-which-require-GLEW-.patch @@ -10,20 +10,21 @@ Subject: [PATCH 3/9] configure: Allow to disable demos which require GLEW or Upstream-Status: Pending Signed-off-by: Martin Jansa +Signed-off-by: Drew Moseley --- - configure.ac | 49 - - src/Makefile.am | 14 ++--- + configure.ac | 50 - + src/Makefile.am | 18 --- src/demos/Makefile.am | 73 --- src/egl/Makefile.am | 8 +++-- src/egl/opengles1/Makefile.am | 44 +++--- src/egl/opengles2/Makefile.am | 33 ++- - 6 files changed, 135 insertions(+), 86 deletions(-) + 6 files changed, 140 insertions(+), 86 deletions(-) diff --git a/configure.ac b/configure.ac index 9445424..bc4c8d1 100644 --- a/configure.ac +++ b/configure.ac -@@ -93,25 +93,44 @@ AC_EGREP_HEADER([glutInitContextProfile], +@@ -89,25 +89,45 @@ AC_EGREP_HEADER([glutInitContextProfile], [AC_DEFINE(HAVE_FREEGLUT)], []) @@ -66,7 +67,7 @@ index 9445424..bc4c8d1 100644 -DEMO_CFLAGS="$DEMO_CFLAGS $GLU_CFLAGS" -DEMO_LIBS="$DEMO_LIBS $GLU_LIBS" +if test "x$enable_glu" = xyes; then -+PKG_CHECK_MODULES(GLU, [glu], [], ++PKG_CHECK_MODULES(GLU, [glu], + [AC_CHECK_HEADER([GL/glu.h], + [], + AC_MSG_ERROR([GLU not found])) @@ -74,7 +75,8 @@ index 9445424..bc4c8d1 100644 + [gluBeginCurve], + [GLU_LIBS=-lGLU + glu_enabled=yes], -+ AC_MSG_ERROR([GLU required])) ]) ++ AC_MSG_ERROR([GLU required])) ], ++ []) + +DEMO_CFLAGS="$DEMO_CFLAGS $GLU_CFLAGS" +DEMO_LIBS="$DEMO_LIBS $GLU_LIBS" -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [v2 PATCH 0/9] kernel: version updates
On Thu, Dec 11, 2014 at 9:56 AM, Richard Purdie
wrote:
> On Thu, 2014-12-11 at 13:58 +, Richard Purdie wrote:
>> On Thu, 2014-12-11 at 03:31 -0500, Bruce Ashfield wrote:
>> > On Wed, Dec 10, 2014 at 10:02 AM, Burton, Ross
>> > wrote:
>> > >
>> > > On 10 December 2014 at 14:16, Bruce Ashfield
>> > >
>> > > wrote:
>> > >>
>> > >> The following changes since commit
>> > >> 88dfcbf149dda89277e58ae4ec3a87500624cfff:
>> > >>
>> > >> kernel-yocto: make sure git tags get dereferenced properly in
>> > >> do_patch()
>> > >> (2014-12-10 08:12:56 -0500)
>> > >>
>> > >> are available in the git repository at:
>> > >>
>> > >> git://git.pokylinux.org/poky-contrib HEAD
>> > >
>> > >
>> > > I wonder what happened here!
>> >
>> > @#!$#@$ the script is insane.
>> >
>> > >
>> > >>
>> > >> for you to fetch changes up to 4be985be419f06f18c735d72ac4a4d00fea71dd8:
>> > >>
>> > >> linux-yocto/3.14: update to 3.14.26, integrate ltsi and -rt updates
>> > >> (2014-12-10 08:38:49 -0500)
>> > >
>> > >
>> > > That's zedd/kernel-updates, right?
>> > >
>> >
>> > Yah. Sorry about the confusion,
>>
>> I've been experimenting, the upgrades look good but we have a problem
>> with the new kernel class changes.
>>
>> The issue is that if you have an existing TMPDIR, the build will do "bad
>> things".
>>
>> Basically, there is usually an existing sstate manifest file which
>> covers the kernel source in the sysroot. do_configure will trigger
>> cleaning of that manifest, a large chunk of the source disappears and
>> then the build understandably fails.
>>
>> Whilst I can say what is happening, I can't say how we fix it at this
>> point :/.
>>
>> I would like people to test these patches, we'd better hold off merging
>> until we can get this issue figured out. Its part of a wider problem
>> with "stale" data in the sysroot which we really need to figure out but
>> its not been solved yet as its a very hard problem for which we don't
>> have a solution :(.
>
> After quite some thinking, I've come up with the patch below which
> should at least allow us to get this patch series merged. Obviously I
> need to split this up and send it out properly with a decent commit log
> but I thought I'd share it sooner than later.
Nice. I'll stack it on here and let it sit through my kernel builds and jumping
between versions .. that tends to break what can be broken.
On a related note, I have a one line update to a patch that fixes the qemuppc
build (missing directory).
Do we want to leave the series as is, and I can send it as an incremental
patch, or would you rather it squashed and the branches updated ?
Bruce
>
> Cheers,
>
> Richard
>
>
> From 2495650e76bdee971645b3049b6e65307e506e09 Mon Sep 17 00:00:00 2001
> From: Richard Purdie
> Date: Thu, 11 Dec 2014 14:36:05 +
> Subject: sanity: TMPDIR ABI change for kernel process
>
> Signed-off-by: Richard Purdie
>
> diff --git a/meta-yocto/conf/distro/poky.conf
> b/meta-yocto/conf/distro/poky.conf
> index 72db36d..bea8e04 100644
> --- a/meta-yocto/conf/distro/poky.conf
> +++ b/meta-yocto/conf/distro/poky.conf
> @@ -94,7 +94,7 @@ BB_SIGNATURE_HANDLER ?= 'OEBasicHash'
> # that breaks the format and have been previously discussed on the mailing
> list
> # with general agreement from the core team.
> #
> -OELAYOUT_ABI = "8"
> +OELAYOUT_ABI = "10"
>
> # add poky sanity bbclass
> INHERIT += "poky-sanity"
> diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
> index 5be5efb..71fd2e9 100644
> --- a/meta/classes/sanity.bbclass
> +++ b/meta/classes/sanity.bbclass
> @@ -519,6 +519,16 @@ def sanity_handle_abichanges(status, d):
> status.addresult("Your configuration is using stamp files
> including the sstate hash but your build directory was built with stamp files
> that do not include this.\nTo continue, either rebuild or switch back to the
> OEBasic signature handler with BB_SIGNATURE_HANDLER = 'OEBasic'.\n")
> elif (abi != current_abi and current_abi == "9"):
> status.addresult("The layout of the TMPDIR STAMPS directory has
> changed. Please clean out TMPDIR and rebuild (sstate will be still be valid
> and reused)\n")
> +elif (abi != current_abi and current_abi == "10" and (abi == "8" or
> abi == "9")):
> +bb.note("Converting staging layout from version 8/9 to layout
> version 10")
> +cmd = d.expand("grep -l sysroot-providers/virtual_kernel
> ${SSTATE_MANIFESTS}/*")
> +ret, result = oe.utils.getstatusoutput(cmd)
> +result = result.split()
> +for f in result:
> +bb.note("Uninstalling manifest file %s" % f)
> +sstate_clean_manifest(f, d)
> +with open(abifile, "w") as f:
> +f.write(current_abi)
> elif (abi != current_abi):
> # Code to convert from one ABI to another could go here if
> possible.
> status.addresult("Error, TMPDIR has changed its layout version
> number (
Re: [OE-core] [v2 PATCH 0/9] kernel: version updates
On Thu, 2014-12-11 at 13:58 +, Richard Purdie wrote:
> On Thu, 2014-12-11 at 03:31 -0500, Bruce Ashfield wrote:
> > On Wed, Dec 10, 2014 at 10:02 AM, Burton, Ross
> > wrote:
> > >
> > > On 10 December 2014 at 14:16, Bruce Ashfield
> > >
> > > wrote:
> > >>
> > >> The following changes since commit
> > >> 88dfcbf149dda89277e58ae4ec3a87500624cfff:
> > >>
> > >> kernel-yocto: make sure git tags get dereferenced properly in
> > >> do_patch()
> > >> (2014-12-10 08:12:56 -0500)
> > >>
> > >> are available in the git repository at:
> > >>
> > >> git://git.pokylinux.org/poky-contrib HEAD
> > >
> > >
> > > I wonder what happened here!
> >
> > @#!$#@$ the script is insane.
> >
> > >
> > >>
> > >> for you to fetch changes up to 4be985be419f06f18c735d72ac4a4d00fea71dd8:
> > >>
> > >> linux-yocto/3.14: update to 3.14.26, integrate ltsi and -rt updates
> > >> (2014-12-10 08:38:49 -0500)
> > >
> > >
> > > That's zedd/kernel-updates, right?
> > >
> >
> > Yah. Sorry about the confusion,
>
> I've been experimenting, the upgrades look good but we have a problem
> with the new kernel class changes.
>
> The issue is that if you have an existing TMPDIR, the build will do "bad
> things".
>
> Basically, there is usually an existing sstate manifest file which
> covers the kernel source in the sysroot. do_configure will trigger
> cleaning of that manifest, a large chunk of the source disappears and
> then the build understandably fails.
>
> Whilst I can say what is happening, I can't say how we fix it at this
> point :/.
>
> I would like people to test these patches, we'd better hold off merging
> until we can get this issue figured out. Its part of a wider problem
> with "stale" data in the sysroot which we really need to figure out but
> its not been solved yet as its a very hard problem for which we don't
> have a solution :(.
After quite some thinking, I've come up with the patch below which
should at least allow us to get this patch series merged. Obviously I
need to split this up and send it out properly with a decent commit log
but I thought I'd share it sooner than later.
Cheers,
Richard
>From 2495650e76bdee971645b3049b6e65307e506e09 Mon Sep 17 00:00:00 2001
From: Richard Purdie
Date: Thu, 11 Dec 2014 14:36:05 +
Subject: sanity: TMPDIR ABI change for kernel process
Signed-off-by: Richard Purdie
diff --git a/meta-yocto/conf/distro/poky.conf b/meta-yocto/conf/distro/poky.conf
index 72db36d..bea8e04 100644
--- a/meta-yocto/conf/distro/poky.conf
+++ b/meta-yocto/conf/distro/poky.conf
@@ -94,7 +94,7 @@ BB_SIGNATURE_HANDLER ?= 'OEBasicHash'
# that breaks the format and have been previously discussed on the mailing
list
# with general agreement from the core team.
#
-OELAYOUT_ABI = "8"
+OELAYOUT_ABI = "10"
# add poky sanity bbclass
INHERIT += "poky-sanity"
diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index 5be5efb..71fd2e9 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -519,6 +519,16 @@ def sanity_handle_abichanges(status, d):
status.addresult("Your configuration is using stamp files
including the sstate hash but your build directory was built with stamp files
that do not include this.\nTo continue, either rebuild or switch back to the
OEBasic signature handler with BB_SIGNATURE_HANDLER = 'OEBasic'.\n")
elif (abi != current_abi and current_abi == "9"):
status.addresult("The layout of the TMPDIR STAMPS directory has
changed. Please clean out TMPDIR and rebuild (sstate will be still be valid and
reused)\n")
+elif (abi != current_abi and current_abi == "10" and (abi == "8" or
abi == "9")):
+bb.note("Converting staging layout from version 8/9 to layout
version 10")
+cmd = d.expand("grep -l sysroot-providers/virtual_kernel
${SSTATE_MANIFESTS}/*")
+ret, result = oe.utils.getstatusoutput(cmd)
+result = result.split()
+for f in result:
+bb.note("Uninstalling manifest file %s" % f)
+sstate_clean_manifest(f, d)
+with open(abifile, "w") as f:
+f.write(current_abi)
elif (abi != current_abi):
# Code to convert from one ABI to another could go here if
possible.
status.addresult("Error, TMPDIR has changed its layout version
number (%s to %s) and you need to either rebuild, revert or adjust it at your
own risk.\n" % (abi, current_abi))
diff --git a/meta/conf/abi_version.conf b/meta/conf/abi_version.conf
index e8cf9a3..2867850 100644
--- a/meta/conf/abi_version.conf
+++ b/meta/conf/abi_version.conf
@@ -4,4 +4,4 @@
# that breaks the format and have been previously discussed on the mailing
list
# with general agreement from the core team.
#
-OELAYOUT_ABI = "9"
+OELAYOUT_ABI = "10"
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mail
Re: [OE-core] [v2 PATCH 0/9] kernel: version updates
On Thu, 2014-12-11 at 03:31 -0500, Bruce Ashfield wrote: > On Wed, Dec 10, 2014 at 10:02 AM, Burton, Ross wrote: > > > > On 10 December 2014 at 14:16, Bruce Ashfield > > wrote: > >> > >> The following changes since commit > >> 88dfcbf149dda89277e58ae4ec3a87500624cfff: > >> > >> kernel-yocto: make sure git tags get dereferenced properly in do_patch() > >> (2014-12-10 08:12:56 -0500) > >> > >> are available in the git repository at: > >> > >> git://git.pokylinux.org/poky-contrib HEAD > > > > > > I wonder what happened here! > > @#!$#@$ the script is insane. > > > > >> > >> for you to fetch changes up to 4be985be419f06f18c735d72ac4a4d00fea71dd8: > >> > >> linux-yocto/3.14: update to 3.14.26, integrate ltsi and -rt updates > >> (2014-12-10 08:38:49 -0500) > > > > > > That's zedd/kernel-updates, right? > > > > Yah. Sorry about the confusion, I've been experimenting, the upgrades look good but we have a problem with the new kernel class changes. The issue is that if you have an existing TMPDIR, the build will do "bad things". Basically, there is usually an existing sstate manifest file which covers the kernel source in the sysroot. do_configure will trigger cleaning of that manifest, a large chunk of the source disappears and then the build understandably fails. Whilst I can say what is happening, I can't say how we fix it at this point :/. I would like people to test these patches, we'd better hold off merging until we can get this issue figured out. Its part of a wider problem with "stale" data in the sysroot which we really need to figure out but its not been solved yet as its a very hard problem for which we don't have a solution :(. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] State of bitbake world, test-dependencies 2014-12-11
On 11 December 2014 at 12:44, Martin Jansa wrote: > gst-plugins-bad-meta depends on gst-plugins-bad-rtmp when built after > world (rtmp is detected) and doesn't depend on gst-plugins-bad-rtmp when > built in minimal TMPDIR. > > test-dependencies.sh is showing this warning when the dependencies > between "maximal" and "minimal" builds aren't equal. > > I still don't get what's wrong with that warning. > Gotcha, yes, understood. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] State of bitbake world, test-dependencies 2014-12-11
On Thu, Dec 11, 2014 at 12:31:45PM +, Burton, Ross wrote: > On 11 December 2014 at 12:14, Martin Jansa wrote: > > > > > WARN: gst-plugins-bad: gst-plugins-bad-meta rdepends on > > > > gst-plugins-bad-rtmp, but it isn't a build dependency? > > > > ERROR: gst-plugins-bad: gst-plugins-bad-rtmp package isn't created when > > > > building with minimal dependencies? > > > > ERROR: gst-plugins-bad: gst-plugins-bad-rtmp-dev package isn't created > > > > when building with minimal dependencies? > > > > > > > > > > Coincidently last night my world run gave me warnings that > > > gst-plugins-bad-rtmp was depending on rtmpdump without a build depends, > > so > > > I've copied the PACKAGECONFIG[rtmp] from gstreamer1.0-plugins-bad to > > > gst-plugins-bad. Presumably this will fix these errors, although that > > > warning seems odd. > > > > Why odd? It just means that gst-plugins-bad-rtmp* packages aren't > > created at all when rtmp isn't autodetected. > > > But gst-plugins-bad-meta won't depend on -rtmp when rtmp isn't detected as > the splitting is dynamically done. gst-plugins-bad-meta depends on gst-plugins-bad-rtmp when built after world (rtmp is detected) and doesn't depend on gst-plugins-bad-rtmp when built in minimal TMPDIR. test-dependencies.sh is showing this warning when the dependencies between "maximal" and "minimal" builds aren't equal. I still don't get what's wrong with that warning. -- 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] State of bitbake world, test-dependencies 2014-12-11
On 11 December 2014 at 12:14, Martin Jansa wrote: > > > WARN: gst-plugins-bad: gst-plugins-bad-meta rdepends on > > > gst-plugins-bad-rtmp, but it isn't a build dependency? > > > ERROR: gst-plugins-bad: gst-plugins-bad-rtmp package isn't created when > > > building with minimal dependencies? > > > ERROR: gst-plugins-bad: gst-plugins-bad-rtmp-dev package isn't created > > > when building with minimal dependencies? > > > > > > > Coincidently last night my world run gave me warnings that > > gst-plugins-bad-rtmp was depending on rtmpdump without a build depends, > so > > I've copied the PACKAGECONFIG[rtmp] from gstreamer1.0-plugins-bad to > > gst-plugins-bad. Presumably this will fix these errors, although that > > warning seems odd. > > Why odd? It just means that gst-plugins-bad-rtmp* packages aren't > created at all when rtmp isn't autodetected. But gst-plugins-bad-meta won't depend on -rtmp when rtmp isn't detected as the splitting is dynamically done. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] State of bitbake world, test-dependencies 2014-12-11
On Thu, Dec 11, 2014 at 11:13:51AM +, Burton, Ross wrote: > On 11 December 2014 at 09:23, Martin Jansa wrote: > > > WARN: gst-plugins-bad: gst-plugins-bad-meta rdepends on > > gst-plugins-bad-rtmp, but it isn't a build dependency? > > ERROR: gst-plugins-bad: gst-plugins-bad-rtmp package isn't created when > > building with minimal dependencies? > > ERROR: gst-plugins-bad: gst-plugins-bad-rtmp-dev package isn't created > > when building with minimal dependencies? > > > > Coincidently last night my world run gave me warnings that > gst-plugins-bad-rtmp was depending on rtmpdump without a build depends, so > I've copied the PACKAGECONFIG[rtmp] from gstreamer1.0-plugins-bad to > gst-plugins-bad. Presumably this will fix these errors, although that > warning seems odd. Why odd? It just means that gst-plugins-bad-rtmp* packages aren't created at all when rtmp isn't autodetected. -- 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] [daisy][PATCH] python: Building without SSLv3 support , The POODLE Bites Again
On Tuesday 09 December 2014 14:38:53 Sona Sarmadi wrote: > > I think we should apply the patch now anyway; we'll want to know that it > > works for backports to the stable branch(es), and in any case the upgrade > > to 2.7.9 is not going to be a straightforward task based upon my earlier > > attempt to upgrade to 2.7.6 (the current state of which is still in > > paule/python276-wip in poky-contrib). > > I have applied this patch in master and have run some tests to verify that > Sslv3 is really disabled. It seems that SSLv3 still is enabled. I am > running more tests to find out why SSLv3 is not disabled and what more > needs to be done. > SSLv2 is disabled already, if we manage to disable SSLV3 then I guess we > need to disable SSLv23 as well ??! I'm not sure of that. It seems that SSLv23 is the default even in 2.7.9. I'm unclear on whether that is an issue or not based on what I can find. > I think we should consider (start looking at upgrading to python 2.7.9 in > master), to address this issue. I feel uncomfortable with this Debian > patch. It seems that we need to do more manual changes in order to make > this work. I will soon update the bug 7015 with my test results. We definitely do need to do this upgrade, yes; but we'd also like to have a fix for older versions too. FWIW I've just entered an enhancement bug to cover this for master; at the moment I'm not sure who will end up doing it but I thought we should have something to track it since it's not a trivial piece of work: https://bugzilla.yoctoproject.org/show_bug.cgi?id=7059 (Richard is nominally the maintainer of the recipe, but I suspect he has his hands pretty much full with everything else that's going on.) > While testing this issue a new vulnerability was released yesterday : > Incorrect TLS padding may be accepted when terminating TLS 1.x CBC cipher > connections. (CVE-2014-8730) > > https://support.f5.com/kb/en-us/solutions/public/15000/800/sol15882.html > https://community.qualys.com/blogs/securitylabs/2014/12/08/poodle-bites-tls Yes, they never stop coming :( >From my digging though I can't seem to find anything specifying any versions >of open source software that need fixing for this new vulnerability, only proprietary software. Did you find anything? 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
[OE-core] [PATCH 2/2] gst-plugins-bad: add PACKAGECONFIG for the RTMP plugin
The RTMP plugin was non-deterministic, based on whether rtmpdump from meta-multimedia had been built. Add a PACKAGECONFIG to resolve this. Signed-off-by: Ross Burton --- meta/recipes-multimedia/gstreamer/gst-plugins-bad_0.10.23.bb |1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-multimedia/gstreamer/gst-plugins-bad_0.10.23.bb b/meta/recipes-multimedia/gstreamer/gst-plugins-bad_0.10.23.bb index 2ecdcf2..0f64871 100644 --- a/meta/recipes-multimedia/gstreamer/gst-plugins-bad_0.10.23.bb +++ b/meta/recipes-multimedia/gstreamer/gst-plugins-bad_0.10.23.bb @@ -37,6 +37,7 @@ PACKAGECONFIG[openal] = "--enable-openal,--disable-openal,openal-soft" PACKAGECONFIG[schro] = "--enable-schro,--disable-schro,schroedinger" PACKAGECONFIG[dc1394] = "--enable-dc1394,--disable-dc1394,libdc1394" PACKAGECONFIG[faac] = "--enable-faac,--disable-faac,faac" +PACKAGECONFIG[rtmp] = "--enable-rtmp,--disable-rtmp,rtmpdump" ARM_INSTRUCTION_SET = "arm" -- 1.7.10.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] gst-plugins: remove spurious whitespace
Signed-off-by: Ross Burton
---
meta/recipes-multimedia/gstreamer/gst-plugins.inc |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-multimedia/gstreamer/gst-plugins.inc
b/meta/recipes-multimedia/gstreamer/gst-plugins.inc
index 2697609..c852c53 100644
--- a/meta/recipes-multimedia/gstreamer/gst-plugins.inc
+++ b/meta/recipes-multimedia/gstreamer/gst-plugins.inc
@@ -19,10 +19,10 @@ require gst-plugins-package.inc
PACKAGES_DYNAMIC += "^${PN}-.*"
# apply gstreamer hack after Makefile.in.in in source is replaced by our
version from
-# ${STAGING_DATADIR_NATIVE}/gettext/po/Makefile.in.in, but before configure is
executed
+# ${STAGING_DATADIR_NATIVE}/gettext/po/Makefile.in.in, but before configure is
executed
#
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-November/032233.html
-oe_runconf_prepend() {
+oe_runconf_prepend() {
if [ -e ${S}/po/Makefile.in.in ]; then
sed -i -e "1a\\" -e 'GETTEXT_PACKAGE = @GETTEXT_PACKAGE@'
${S}/po/Makefile.in.in
fi
-}
+}
--
1.7.10.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] State of bitbake world, test-dependencies 2014-12-11
On 11 December 2014 at 09:23, Martin Jansa wrote: > WARN: gst-plugins-bad: gst-plugins-bad-meta rdepends on > gst-plugins-bad-rtmp, but it isn't a build dependency? > ERROR: gst-plugins-bad: gst-plugins-bad-rtmp package isn't created when > building with minimal dependencies? > ERROR: gst-plugins-bad: gst-plugins-bad-rtmp-dev package isn't created > when building with minimal dependencies? > Coincidently last night my world run gave me warnings that gst-plugins-bad-rtmp was depending on rtmpdump without a build depends, so I've copied the PACKAGECONFIG[rtmp] from gstreamer1.0-plugins-bad to gst-plugins-bad. Presumably this will fix these errors, although that warning seems odd. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3 2/2] u-boot.inc : add compile multiple u-boot feature
On Thu, Dec 11, 2014 at 1:34 AM, b40...@freescale.com
wrote:
> Hello Otavio,
> Sorry for my late reply.
> Thanks for your review .
> I have submitted v4 of the patchest.
>
...
Comments below...
>> if [ "x${UBOOT_ENV}" != "x" ]
>> then
>> @@ -93,21 +100,36 @@ do_install () {
>> FILES_${PN} = "/boot ${sysconfdir}"
>>
>> do_deploy () {
>> -install -d ${DEPLOYDIR}
>> -install ${S}/${UBOOT_BINARY} ${DEPLOYDIR}/${UBOOT_IMAGE}
>> -
>> -cd ${DEPLOYDIR}
>> -rm -f ${UBOOT_BINARY} ${UBOOT_SYMLINK}
>> -ln -sf ${UBOOT_IMAGE} ${UBOOT_SYMLINK}
>> -ln -sf ${UBOOT_IMAGE} ${UBOOT_BINARY}
>> -
>> -if [ "x${SPL_BINARY}" != "x" ]
>> -then
>> -install ${S}/${SPL_BINARY} ${DEPLOYDIR}/${SPL_IMAGE}
>> -rm -f ${DEPLOYDIR}/${SPL_BINARY} ${DEPLOYDIR}/${SPL_SYMLINK}
>> -ln -sf ${SPL_IMAGE} ${DEPLOYDIR}/${SPL_BINARY}
>> -ln -sf ${SPL_IMAGE} ${DEPLOYDIR}/${SPL_SYMLINK}
>> -fi
>> +for type in ${UBOOT_MACHINE}; do
>> +for imagetype in in ${UBOOT_CONFIG}; do
>> +if [ "${imagetype}"x = "in"x ]
>> +then
>> +continue
>> +fi
>> +if [ -d "${DEPLOYDIR}/u-boot-${imagetype}.${UBOOT_SUFFIX}"]
>> +then
>> +break
>> +else
>> +install -d ${DEPLOYDIR}
>> +install ${S}/${type}/u-boot-${type}.${UBOOT_SUFFIX}
>> ${DEPLOYDIR}/u-boot-${imagetype}.${UBOOT_SUFFIX}
>> +if [ "${imagetype}"x = "sd"x ] || [ "${imagetype}"x =
>> "mfgtool"x ]
>> +then
>> +cp ${DEPLOYDIR}/u-boot-${imagetype}.${UBOOT_SUFFIX}
>> ${DEPLOYDIR}/u-boot-${MACHINE}.${UBOOT_SUFFIX}
>> +fi
>> +fi
>
> Way nicer (and should have some similar code on the install and compile
> tasks) however I didn't get why you're adding the 'sd' or 'mfgtool' specific
> case here. This is a FSL specific thing and shouldn't be part of OE-Core.
>
> [ I use default link of last type uboot of "UBOOT_CONFIG" to fix the
> following error:
>
> * difficulty to figure the binary when generating the rootfs: in
> meta-fsl-arm, for example, we generate the .sdcard rootfs and using the patch
> we now have...
>
> ERROR: Error: The image creation script
> '.../tmp/work/imx6qsabresd-oel-linux-gnueabi/core-image-minimal/1.0-r0/temp/create_image.sdcard'
>
> ]
Right I am wondering if we ought to do this or not. This is a FSL
specific code and I will try to think in a way to improve it at
meta-fsl-arm side ...
--
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
[OE-core] [PATCH 2/4] perl_5.20.0: fix QA package-missing warnings
While building perl with QA package-missing checking enabled, there was warning:
...
WARNING: QA Issue: package perl-module-cpanplus not generated, but listed in
PACKAGES
WARNING: QA Issue: package perl-module-config not generated, but listed in
PACKAGES
WARNING: QA Issue: package perl-module-config-heavy not generated, but listed
in PACKAGES
WARNING: QA Issue: package perl-module-strict not generated, but listed in
PACKAGES
WARNING: QA Issue: package perl-module-vars not generated, but listed in
PACKAGES
WARNING: QA Issue: package perl-module-warnings not generated, but listed in
PACKAGES
WARNING: QA Issue: package perl-module-warnings-register not generated, but
listed in PACKAGES
...
Drop perl-module-cpanplus, from git://perl5.git.perl.org/perl.git:
...
commit fb598ba5e55920eb59105c932df653f4fea6966c
Author: Chris 'BinGOs' Williams
Date: Sat May 18 01:01:42 2013 +0100
Remove cpan/CPANPLUS and associated utilities
...
Drop perl-module-config from PACKAGES_DYNAMIC:
Config.pm was listed in "FILES_${PN}", we should filter it out from
do_split_packages.
Drop perl-module-config-heavy from PACKAGES_DYNAMIC:
Config_heavy.pl was listed in "FILES_${PN}-lib", we should filter it out from
do_split_packages.
Drop perl-module-strict from PACKAGES_DYNAMIC:
strict.pm was listed in "FILES_${PN}", we should filter it out from
do_split_packages.
Drop perl-module-vars from PACKAGES_DYNAMIC:
vars.pm was listed in "FILES_${PN}", we should filter it out from
do_split_packages.
Drop perl-module-warnings from PACKAGES_DYNAMIC:
warnings.pm was listed in "FILES_${PN}", we should filter it out from
do_split_packages.
Drop perl-module-warnings-register from PACKAGES_DYNAMIC:
Dir warnings was listed in "FILES_${PN}", we should filter it out from
do_split_packages.
Signed-off-by: Hongxu Jia
---
meta/recipes-devtools/perl/perl_5.20.0.bb | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/meta/recipes-devtools/perl/perl_5.20.0.bb
b/meta/recipes-devtools/perl/perl_5.20.0.bb
index 3ca0f53..c7f21a9 100644
--- a/meta/recipes-devtools/perl/perl_5.20.0.bb
+++ b/meta/recipes-devtools/perl/perl_5.20.0.bb
@@ -272,7 +272,7 @@ perl_package_preprocess () {
}
PACKAGES = "perl-dbg perl perl-misc perl-dev perl-pod perl-doc perl-lib \
-perl-module-cpan perl-module-cpanplus perl-module-unicore"
+perl-module-cpan perl-module-unicore"
FILES_${PN} = "${bindir}/perl ${bindir}/perl${PV} \
${libdir}/perl/${PV}/Config.pm \
${libdir}/perl/${PV}/strict.pm \
@@ -311,7 +311,6 @@ FILES_${PN}-doc = "${libdir}/perl/${PV}/*/*.txt \
${libdir}/perl/${PV}/CGI/eg \
${libdir}/perl/${PV}/CPAN/PAUSE2003.pub \
${libdir}/perl/${PV}/CPAN/SIGNATURE \
-
${libdir}/perl/${PV}/CPANPLUS/Shell/Default/Plugins/HOWTO.pod \
${libdir}/perl/${PV}/Encode/encode.h \
${libdir}/perl/${PV}/ExtUtils/MANIFEST.SKIP \
${libdir}/perl/${PV}/ExtUtils/NOTES \
@@ -326,8 +325,6 @@ FILES_${PN}-doc = "${libdir}/perl/${PV}/*/*.txt \
FILES_perl-module-cpan += "${libdir}/perl/${PV}/CPAN \
${libdir}/perl/${PV}/CPAN.pm"
-FILES_perl-module-cpanplus += "${libdir}/perl/${PV}/CPANPLUS \
- ${libdir}/perl/${PV}/CPANPLUS.pm"
FILES_perl-module-unicore += "${libdir}/perl/${PV}/unicore"
# Create a perl-modules package recommending all the other perl
@@ -340,7 +337,11 @@ python populate_packages_prepend () {
do_split_packages(d, libdir, 'auto/([^.]*)/[^/]*\.(so|ld|ix|al)',
'perl-module-%s', 'perl module %s', recursive=True, match_path=True,
prepend=False)
do_split_packages(d, libdir, 'Module/([^\/]*)\.pm', 'perl-module-%s',
'perl module %s', recursive=True, allow_dirs=False, match_path=True,
prepend=False)
do_split_packages(d, libdir, 'Module/([^\/]*)/.*', 'perl-module-%s', 'perl
module %s', recursive=True, allow_dirs=False, match_path=True, prepend=False)
-do_split_packages(d, libdir,
'(^(?!(CPAN\/|CPANPLUS\/|Module\/|unicore\/|auto\/)[^\/]).*)\.(pm|pl|e2x)',
'perl-module-%s', 'perl module %s', recursive=True, allow_dirs=False,
match_path=True, prepend=False)
+
+unmatch_dirs = '(CPAN\/|Module\/|unicore\/|auto\/|warnings\/)[^\/]'
+unmatch_files =
'vars.pm$|Config.pm$|strict.pm$|Config_heavy.pl$|warnings.pm$'
+file_regex = '(^(?!(%s|%s)).*)\.(pm|pl|e2x)' % (unmatch_dirs,
unmatch_files)
+do_split_packages(d, libdir, file_regex, 'perl-module-%s', 'perl module
%s', recursive=True, allow_dirs=False, match_path=True, prepend=False)
# perl-modules should recommend every perl module, and only the
# modules. Don't attempt to use the result of do_split_packages() as some
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded
[OE-core] [PATCH 1/4] insane.bbclass: add QA check: package-missing
During packaging, check if there are any dependencies (RDEPENDS)
on packages that have ended up empty and not produced; and if so
produce an warn/error as soon as possible, instead of allowing
the build to proceed up to do_rootfs and then the package manager
reporting the package as missing.
At the moment, we use bb.persist_data as a global database to
collect all available packages rdepends and rprovides. So in the
do_package_qa task, while package not produced, we could compute
rdepends chain, and report warn/error immediately.
[YOCTO #5531]
[YOCTO #6420]
Signed-off-by: Hongxu Jia
---
meta/classes/insane.bbclass | 93 -
1 file changed, 92 insertions(+), 1 deletion(-)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 0b45374..a0eff37 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -29,7 +29,7 @@ QA_SANE = "True"
WARN_QA ?= "ldflags useless-rpaths rpaths staticdev libdir xorg-driver-abi \
textrel already-stripped incompatible-license files-invalid \
installed-vs-shipped compile-host-path install-host-path \
-pn-overrides infodir build-deps file-rdeps \
+pn-overrides infodir build-deps file-rdeps package-missing \
"
ERROR_QA ?= "dev-so debug-deps dev-deps debug-files arch pkgconfig la \
perms dep-cmp pkgvarcheck perm-config perm-line perm-link \
@@ -868,6 +868,15 @@ def package_qa_check_rdepends(pkg, pkgdest, skip,
taskdeps, packages, d):
(pkg, ', '.join(str(e) for e in filerdepends))
sane = package_qa_handle_error("file-rdeps", error_msg, d)
+if "package-missing" not in skip and \
+ not pkg.endswith("-dev") and not pkg.endswith("-staticdev") and
\
+ not pkg.endswith("-locale") and not pkg.endswith("-dbg") and \
+ not pkg.endswith("-doc"):
+if not oe.packagedata.packaged(pkg, d):
+error_msg = "package %s not generated, but listed in
PACKAGES\n" % pkg
+error_msg += compute_rdepends_chain(pkg, d)
+sane = package_qa_handle_error("package-missing", error_msg, d)
+
return sane
def package_qa_check_deps(pkg, pkgdest, skip, d):
@@ -1152,3 +1161,85 @@ python () {
for i in issues:
package_qa_handle_error("pkgvarcheck", "%s: Variable %s is set as not
being package specific, please fix this." % (d.getVar("FILE", True), i), d)
}
+
+# Add a handler to collect all available packages rdepends and rprovides
+# to a global database (bb.persist_data). So the recipe could find out
+# which others rdepends on it. We filter out "-dev, -staticdev, -locale,
+# -dbg, -doc" packages.
+# Such as:
+# RDEPENDS_pkg1 = "pkg2 pkg3"
+# RDEPENDS_pkg4 = "pkg3 pkg5"
+# equals:
+# rdeps_dict = {'pkg2': 'pkg1', 'pkg3': 'pkg1 pkg4', 'pkg5':'pkg4'}
+#
+# RPROVIDES_pkg6 = "pkg2 pkg7"
+# RPROVIDES_pkg7 = "pkg5"
+# equals:
+# rprovides_dict = {'pkg6': 'pkg2 pkg7', 'pkg7': 'pkg5'}
+python collect_package_rdepends_handler () {
+d = e.data
+pkgs = []
+for pkg in (d.getVar('PACKAGES', True) or '').split():
+if pkg.endswith("-dev") or pkg.endswith("-staticdev") or \
+ pkg.endswith("-locale") or pkg.endswith("-dbg") or \
+ pkg.endswith("-doc"):
+continue
+pkgs.append(pkg)
+
+if not pkgs:
+return
+
+rdeps_dict = bb.persist_data.persist('BB_RDEPENDED_CHAIN', d)
+for pkg in pkgs:
+rdeps = (d.getVar('RDEPENDS_%s' % pkg, True) or "").split()
+for rdep in rdeps:
+# Filter out pkg which rdepends itself
+if pkg == rdep:
+continue
+
+if rdep in rdeps_dict and pkg not in rdeps_dict[rdep].split():
+rdeps_dict[rdep] += ' %s' % pkg
+elif rdep not in rdeps_dict:
+rdeps_dict[rdep] = '%s' % pkg
+
+rprovides_dict = bb.persist_data.persist('BB_RPROVIDES_CHAIN', d)
+for pkg in pkgs:
+rprovides = (d.getVar('RPROVIDES_%s' % pkg, True) or "").split()
+if rprovides:
+rprovides_dict[pkg] = ' '.join(set(rprovides))
+}
+addhandler collect_package_rdepends_handler
+collect_package_rdepends_handler[eventmask] = "bb.event.RecipeParsed"
+
+def compute_rdepends_chain(pkg, d):
+rdeps_dict = bb.persist_data.persist('BB_RDEPENDED_CHAIN', d)
+rprovides_dict = bb.persist_data.persist('BB_RPROVIDES_CHAIN', d)
+
+def get_parents(pkg):
+parents = []
+message = ""
+
+if pkg not in rdeps_dict and pkg in rprovides_dict:
+for rprovide in rprovides_dict[pkg].split():
+# Use rprovide to instead of pkg
+if rprovide in rdeps_dict:
+message = '("%s" rprovides "%s")\n' % (pkg, rprovide)
+pkg = rprovide
+break
+
+if pkg in rdeps_dict:
+parents = rdeps_dict[pkg
[OE-core] [PATCH 3/4] linux-libc-headers.inc: fix QA package-missing warnings
While building linux-libc-headers with QA package-missing checking enabled,
there was warning:
...
QA Issue: package linux-libc-headers not generated, but listed in PACKAGES
...
Only linux-libc-headers-dev was generated, the others are empty, we should
set PACKAGE manually.
We also set linux-libc-headers-dev as linux-libc-headers's provider, so
package management could install linux-libc-headers.
Signed-off-by: Hongxu Jia
---
meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
index b18d09f..a69bbe6 100644
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
@@ -71,3 +71,5 @@ RRECOMMENDS_${PN}-dbg = "${PN}-dev (= ${EXTENDPKGV})"
INHIBIT_DEFAULT_DEPS = "1"
DEPENDS += "unifdef-native"
+PACKAGES="${PN}-dev"
+RPROVIDES_${PN}-dev = "${PN}"
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/4] busybox.inc: fix QA package-missing warnings
While building busybox with QA package-missing checking enabled,
there was warning:
...
WARNING: QA Issue: package busybox-mdev not generated, but listed in PACKAGES
WARNING: QA Issue: package busybox-httpd not generated, but listed in PACKAGES
...
The config in ${B}/.config decides to generate busybox-mdev,
busybox-httpd or not. Files are copied if the packages generated.
So set PACKAGES in do_package according to the existance of files.
Signed-off-by: Hongxu Jia
---
meta/recipes-core/busybox/busybox.inc | 10 ++
1 file changed, 10 insertions(+)
diff --git a/meta/recipes-core/busybox/busybox.inc
b/meta/recipes-core/busybox/busybox.inc
index bd66e4f..23115ae 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -314,6 +314,16 @@ python () {
}
python do_package_prepend () {
+if not os.path.exists(d.expand("${D}${sysconfdir}/init.d/busybox-httpd")):
+packages = (d.getVar('PACKAGES', True) or '').split()
+packages.remove(d.expand('${PN}-httpd'))
+d.setVar('PACKAGES', ' '.join(packages))
+
+if not os.path.exists(d.expand("${D}${sysconfdir}/init.d/mdev")):
+packages = (d.getVar('PACKAGES', True) or '').split()
+packages.remove(d.expand('${PN}-mdev'))
+d.setVar('PACKAGES', ' '.join(packages))
+
# We need to load the full set of busybox provides from the
/etc/busybox.links
# Use this to see the update-alternatives with the right information
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/4] insane.bbclass: add QA check: package-missing
We also tried to fix perl, linux-libc-headers and busybox according to
the result of QA checking.
Here is a test to explain what the QA check showing, we could figure out
package missing issue at package generation time rather than do_rootfs
time.
Test Steps:
1. Edit xz and gzip recipe, to simulate a package missing situation (the
manually added
rdepends is not real but):
..
diff --git a/meta/recipes-extended/gzip/gzip.inc
b/meta/recipes-extended/gzip/gzip.inc
index 671b1eb..7e643e5 100644
--- a/meta/recipes-extended/gzip/gzip.inc
+++ b/meta/recipes-extended/gzip/gzip.inc
@@ -32,3 +32,8 @@ ALTERNATIVE_LINK_NAME[gzip] = "${base_bindir}/gzip"
ALTERNATIVE_LINK_NAME[zcat] = "${base_bindir}/zcat"
export CONFIG_SHELL="/bin/sh"
+
+PACKAGES =+ "${PN}-missing1 ${PN}-missing2"
+FILES_${PN}-missing1 = ""
+FILES_${PN}-missing2 = ""
+RPROVIDES_${PN}-missing1 = "${PN}-missing"
diff --git a/meta/recipes-extended/xz/xz_5.1.3alpha.bb
b/meta/recipes-extended/xz/xz_5.1.3alpha.bb
index 168e383..c5d8b57 100644
--- a/meta/recipes-extended/xz/xz_5.1.3alpha.bb
+++ b/meta/recipes-extended/xz/xz_5.1.3alpha.bb
@@ -37,6 +37,9 @@ FILES_liblzma-dev = "${includedir}/lzma*
${libdir}/liblzma*${SOLIBSDEV} ${libdir
FILES_liblzma-staticdev = "${libdir}/liblzma.a"
FILES_liblzma-dbg = "${libdir}/.debug/liblzma*"
+
+RDEPENDS_${PN}_class-target += "gzip-missing gzip-missing2"
+
BBCLASSEXTEND = "native nativesdk"
export CONFIG_SHELL="/bin/sh"
..
2. Vim local.conf
...
IMAGE_INSTALL_append = " xz"
WARN_QA_append = " package-missing"
...
3. bitbake core-image-minimal
..
|WARNING: QA Issue: package gzip-missing1 not generated, but listed in PACKAGES
|Compute rdepends chains, '-->' means 'runtime depends'
|("gzip-missing1" rprovides "gzip-missing")
|"xz" -> "gzip-missing"
| [package-missing]
|WARNING: QA Issue: package gzip-missing2 not generated, but listed in PACKAGES
|Compute rdepends chains, '-->' means 'runtime depends'
|"xz" -> "gzip-missing2"
| [package-missing]
|ERROR: Unable to install packages. Command '/home/jiahongxu/yocto/build-2014120
2-mips/tmp/sysroots/x86_64-linux/usr/bin/smart --quiet --data-dir=/home/jiahongx
u/yocto/build-20141202-mips/tmp/work/qemumips-poky-linux/core-image-minimal/1.0
-r0/rootfs/var/lib/smart install -y xz@mips32r2 run-postinsts@all packagegroup-
core-boot@qemumips' returned 1:
error: Can't install xz-5.1.3alpha-r0@mips32r2: no package provides gzip-missing
|ERROR: Function failed: do_rootfs
|ERROR: Logfile of failure stored in: /home/jiahongxu/yocto/build-20141202-mips/
tmp/work/qemumips-poky-linux/core-image-minimal/1.0-r0/temp/log.do_rootfs.24338
|ERROR: Task 7 (/home/jiahongxu/yocto/poky/meta/recipes-core/images/core-image-
minimal.bb, do_rootfs) failed with exit code '1'
..
//Hongxu
The following changes since commit ec6377bcf52d105cd23ac6bbbeddd38fee9337e4:
bitbake: bitbake-user-manual-metadata.xml: Updated do_package_write example
(2014-12-09 22:25:36 +)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib hongxu/package-missing
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/package-missing
Hongxu Jia (4):
insane.bbclass: add QA check: package-missing
perl_5.20.0: fix QA package-missing warnings
linux-libc-headers.inc: fix QA package-missing warnings
busybox.inc: fix QA package-missing warnings
meta/classes/insane.bbclass| 93 +-
meta/recipes-core/busybox/busybox.inc | 10 +++
meta/recipes-devtools/perl/perl_5.20.0.bb | 11 +--
.../linux-libc-headers/linux-libc-headers.inc | 2 +
4 files changed, 110 insertions(+), 6 deletions(-)
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] State of bitbake world, test-dependencies 2014-12-11
On Sat, Aug 09, 2014 at 11:01:10AM +0200, Martin Jansa wrote: > Complete logs: > http://logs.nslu2-linux.org/buildlogs/oe/world/log.dependencies.20140808_063907.log/ > > ERROR: 483 issues were found in these recipes: directfb engrave epiphany > expedite gd gmtk gnome-disk-utility gst-ffmpeg guile leptonica libarchive > libmicrohttpd libmikmod libungif libwebp libwmf mariadb midori mpd mpeg2dec > mpg123 openal-soft opendataplane oscam piglit protobuf snort sox stunnel > synergy tesseract tracker Complete logs; http://logs.nslu2-linux.org/buildlogs/oe/world/log.dependencies.20141210_162427.log/ This was only partial build, so the results don't look so bad. ERROR: 27 issues were found in these recipes: android-audiosystem collectd fbida gnome-bluetooth gst-plugins-bad mongodb opencv polkit-gnome qtbase tcpdump udisks xbmc xfce4-vala Found differences: WARN: collectd: collectd rdepends on libcrypto, but it isn't a build dependency? WARN: collectd: collectd rdepends on libesmtp, but it isn't a build dependency? WARN: collectd: collectd rdepends on libssl, but it isn't a build dependency? WARN: fbida: fbida rdepends on libwebp, but it isn't a build dependency? WARN: gst-plugins-bad: gst-plugins-bad-meta rdepends on gst-plugins-bad-rtmp, but it isn't a build dependency? WARN: opencv: libopencv-highgui rdepends on jasper, but it isn't a build dependency? WARN: opencv: libopencv-highgui rdepends on libdc1394, but it isn't a build dependency? WARN: qtbase: qtbase-plugins rdepends on cups-lib, but it isn't a build dependency? WARN: tcpdump: tcpdump rdepends on libsmi, but it isn't a build dependency? WARN: udisks: udisks rdepends on lvm2, but it isn't a build dependency? Found errors: ERROR: gst-plugins-bad: gst-plugins-bad-rtmp package isn't created when building with minimal dependencies? ERROR: gst-plugins-bad: gst-plugins-bad-rtmp-dev package isn't created when building with minimal dependencies? -- 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] [v2 PATCH 0/9] kernel: version updates
On Wed, Dec 10, 2014 at 10:02 AM, Burton, Ross wrote: > > On 10 December 2014 at 14:16, Bruce Ashfield > wrote: >> >> The following changes since commit >> 88dfcbf149dda89277e58ae4ec3a87500624cfff: >> >> kernel-yocto: make sure git tags get dereferenced properly in do_patch() >> (2014-12-10 08:12:56 -0500) >> >> are available in the git repository at: >> >> git://git.pokylinux.org/poky-contrib HEAD > > > I wonder what happened here! @#!$#@$ the script is insane. > >> >> for you to fetch changes up to 4be985be419f06f18c735d72ac4a4d00fea71dd8: >> >> linux-yocto/3.14: update to 3.14.26, integrate ltsi and -rt updates >> (2014-12-10 08:38:49 -0500) > > > That's zedd/kernel-updates, right? > Yah. Sorry about the confusion, Bruce > Ross > > -- > ___ > 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
