Re: [yocto] Added package to RDEPENDS in packagegroup, image that IMAGE_INSTALLs packagegroup not rebuilt
-Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of Vuille, Martin (Martin) Sent: November 04, 2014 5:02 PM It's as though bitbake is not seeing my changes. I deliberately introduced syntax errors into the packagegroup .bb file bitbake image does not report any error bitbake packagegroup does not report any error Indeed it appears that the packagegroup.bb file is not being read. Looking at -DDD output, the packagegroup.bb file is mentioned as the runtime provider for packagegroup, and the full path is correct. Still mystified MV -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Added package to RDEPENDS in packagegroup, image that IMAGE_INSTALLs packagegroup not rebuilt
On Wednesday 05 November 2014 10:53:04 Vuille, Martin wrote: -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of Vuille, Martin (Martin) Sent: November 04, 2014 5:02 PM It's as though bitbake is not seeing my changes. I deliberately introduced syntax errors into the packagegroup .bb file What kind of syntax error? Inside a function or outside? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Added package to RDEPENDS in packagegroup, image that IMAGE_INSTALLs packagegroup not rebuilt
-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
Sent: November 05, 2014 5:56 AM
I deliberately introduced syntax errors into the packagegroup .bb file
What kind of syntax error? Inside a function or outside?
This is my packagegroup .bb file as it stands...
DESCRIPTION = Whatever
inherit packagegroup
LICENSE = CLOSED
PACKAGE_ARCH = ${MACHINE_ARCH}
ALLOW_EMPTY_${PN} = 1
PR = r1
frozzle the flab_flab
# Additional third-party packages
RDEPENDS_${PN} += \
ethtool \
gdbserver \
lsof \
openssl-utils \
page-types \
strace \
vim \
vim-common \
daemonize \
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Warning - INCOMPATIBLE_LICENSE regression affecting 1.7 (dizzy)
Hi folks, Unfortunately we've recently discovered that a regression in INCOMPATIBLE_LICENSE behaviour has crept into the 1.7 release. We have a bug report covering the issue here: https://bugzilla.yoctoproject.org/show_bug.cgi?id=6930 The fix has been merged to the master and dizzy branches as of this morning: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=dizzyid=f3a177cf045b19612b7d2c96889ac24307191c3d http://cgit.openembedded.org/openembedded-core/commit/?h=dizzyid=652008fd9dc909836819e5c6808c63643eff6db6 If you use INCOMPATIBLE_LICENSE with dizzy / 1.7 it is strongly recommended that you either use the current tip of the dizzy branch or apply this patch locally. A 1.7.1 point release is upcoming that will include this fix. Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Added package to RDEPENDS in packagegroup, image that IMAGE_INSTALLs packagegroup not rebuilt
-Original Message- From: Vuille, Martin (Martin) Sent: November 05, 2014 5:53 AM I deliberately introduced syntax errors into the packagegroup .bb file bitbake image does not report any error bitbake packagegroup does not report any error Indeed it appears that the packagegroup.bb file is not being read. But bitbake packagegroup -e does re-parse the file and reports the syntax error Repeating bitbake packagegroup after the above still sees no error MV -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Angstrom Build Failing
2014-10-31 19:41 GMT+01:00 nick xerofo...@gmail.com: Thanks Sven, I will git pull later and see if it's up again just wasn't sure if this was a network error or a misconfiguration on my part. Cheers Nick Sorry my fault, I have renamed the layer in gitorious in order to prevent confusion since there is another layer for the new KDE 5 stuff. For KDE4 there is: git://gitorious.org/openembedded-core-layers/meta-kde4.git KDE 5 / KDE Frameworks 5: https://github.com/e8johan/meta-kf5 -- Regards Samuel -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Angstrom Build Failing
That's fine Samuel, I haven't the time to see if it works not due to being busy with school and kernel programming. Cheers Nick On 14-11-05 07:52 AM, Samuel Stirtzel wrote: 2014-10-31 19:41 GMT+01:00 nick xerofo...@gmail.com: Thanks Sven, I will git pull later and see if it's up again just wasn't sure if this was a network error or a misconfiguration on my part. Cheers Nick Sorry my fault, I have renamed the layer in gitorious in order to prevent confusion since there is another layer for the new KDE 5 stuff. For KDE4 there is: git://gitorious.org/openembedded-core-layers/meta-kde4.git KDE 5 / KDE Frameworks 5: https://github.com/e8johan/meta-kf5 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Raspberry b+ support
I did nothing regarding RPI b+ as i don't own a device like that. If you guys can make it work and patches are needed in order to accomplish this, please send them over mailing list and/or review gerrit. Thanks. On Fri, Oct 31, 2014 at 4:06 PM, Mike Hogg mikeh...@mountdrive.com wrote: Yes you can and I have. Search the pi forum for my posts there, last time I tried a yocto build for the b+ it pulled in the old pi firmware which doesn't work on the b+. Per my notes on the pi forum thats easily fixed by copying firmware from another b+ image. On 31 October 2014 12:13:53 GMT+00:00, Natural Groove natural_gro...@hotmail.fr wrote: Hi, I am interested in using oe to crossbuild stuff for raspberry pi b+, and I wondered if someone already achieved to do this? From what I read there are some specifics to deal with, can someone help me with setting this up for b+? Thanks in advance Natural --- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- *Andrei Gherzan* -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Added package to RDEPENDS in packagegroup, image that IMAGE_INSTALLs packagegroup not rebuilt
-Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of Vuille, Martin (Martin) Sent: November 05, 2014 7:35 AM Indeed it appears that the packagegroup.bb file is not being read. But bitbake packagegroup -e does re-parse the file and reports the syntax error Repeating bitbake packagegroup after the above still sees no error In the -DDD output I see DEBUG: Using cache in '/home/platform/Workspace/somename/poky/build/tmp/cache/default-eglibc/sonic/i686' If I rename /home/platform/Workspace/somename/poky/build/tmp/cache/default-eglibc/sonic/i686 to /home/platform/Workspace/somename/poky/build/tmp/cache/default-eglibc/sonic/i686-saved and then run bitbake packagegroup, the .bb file is reparsed If I rename the directory back, then bitbake packagegroup goes back to doing nothing Something stands out here... My build machine is x86_64 but my SDKMACHINE is i686. And I see that the directory name above includes i686. Might there be something to this? MV -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Added package to RDEPENDS in packagegroup, image that IMAGE_INSTALLs packagegroup not rebuilt
On Wednesday 05 November 2014 15:01:02 Vuille, Martin wrote: -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of Vuille, Martin (Martin) Sent: November 05, 2014 7:35 AM Indeed it appears that the packagegroup.bb file is not being read. But bitbake packagegroup -e does re-parse the file and reports the syntax error Repeating bitbake packagegroup after the above still sees no error In the -DDD output I see DEBUG: Using cache in '/home/platform/Workspace/somename/poky/build/tmp/cache/default-eglibc/soni c/i686' If I rename /home/platform/Workspace/somename/poky/build/tmp/cache/default-eglibc/sonic /i686 to /home/platform/Workspace/somename/poky/build/tmp/cache/default-eglibc/sonic /i686-saved and then run bitbake packagegroup, the .bb file is reparsed If I rename the directory back, then bitbake packagegroup goes back to doing nothing Something stands out here... My build machine is x86_64 but my SDKMACHINE is i686. And I see that the directory name above includes i686. Might there be something to this? So it does appear to be cache related, but I just tried creating a similar packagegroup here and even set SDKMACHINE and could not reproduce the problem, adding the same junk you did at the same point caused an immediate parse error on the next build. The question is if you remove the garbage, rename the cache directory, parse it successfully and then add the garbage is it reparsed with the new cache? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Added package to RDEPENDS in packagegroup, image that IMAGE_INSTALLs packagegroup not rebuilt
-Original Message- From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] Sent: November 05, 2014 10:10 AM So it does appear to be cache related, but I just tried creating a similar packagegroup here and even set SDKMACHINE and could not reproduce the problem, adding the same junk you did at the same point caused an immediate parse error on the next build. The question is if you remove the garbage, rename the cache directory, parse it successfully and then add the garbage is it reparsed with the new cache? - Removed the garbage - Renamed the cache directory bitbake packagegroup I get a warning as follows for every single file mentioned in a SRC_URI in any recipe: WARNING: Unable to get checksum for package SRC_URI entry filename: file could not be found and then ERROR: Nothing PROVIDES 'virtual/fakeroot-native'. MV -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Added package to RDEPENDS in packagegroup, image that IMAGE_INSTALLs packagegroup not rebuilt
On Wednesday 05 November 2014 15:18:42 Vuille, Martin wrote: -Original Message- From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] Sent: November 05, 2014 10:10 AM So it does appear to be cache related, but I just tried creating a similar packagegroup here and even set SDKMACHINE and could not reproduce the problem, adding the same junk you did at the same point caused an immediate parse error on the next build. The question is if you remove the garbage, rename the cache directory, parse it successfully and then add the garbage is it reparsed with the new cache? - Removed the garbage - Renamed the cache directory bitbake packagegroup I get a warning as follows for every single file mentioned in a SRC_URI in any recipe: WARNING: Unable to get checksum for package SRC_URI entry filename: file could not be found and then ERROR: Nothing PROVIDES 'virtual/fakeroot-native'. OK, so perhaps this wasn't the best idea after all - I think what's happened there is that part of the cache is there and the other part now isn't. Instead of moving that subdirectory out of the way, in order to do this test you'd probably need to rename the cache directory under your build directory *and* the one under tmp. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Added package to RDEPENDS in packagegroup, image that IMAGE_INSTALLs packagegroup not rebuilt
-Original Message- From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] Sent: November 05, 2014 10:23 AM OK, so perhaps this wasn't the best idea after all - I think what's happened there is that part of the cache is there and the other part now isn't. Instead of moving that subdirectory out of the way, in order to do this test you'd probably need to rename the cache directory under your build directory *and* the one under tmp. Tried renaming cache to cache-saved Still see SRC_URI errors Tried putting everything back, still see the errors Tried removing both dirs again, still see errors I think I will have to clean everything and rebuild from scratch (five-hour build). MV -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Added package to RDEPENDS in packagegroup, image that IMAGE_INSTALLs packagegroup not rebuilt
On Wednesday 05 November 2014 15:27:10 Vuille, Martin wrote: -Original Message- From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] Sent: November 05, 2014 10:23 AM OK, so perhaps this wasn't the best idea after all - I think what's happened there is that part of the cache is there and the other part now isn't. Instead of moving that subdirectory out of the way, in order to do this test you'd probably need to rename the cache directory under your build directory *and* the one under tmp. Tried renaming cache to cache-saved Still see SRC_URI errors Tried putting everything back, still see the errors Tried removing both dirs again, still see errors I think I will have to clean everything and rebuild from scratch (five-hour build). No, you really don't need to do a complete rebuild. This is a cache problem, if you have properly removed the cache the issue (at least the latest errors) will go away. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Added package to RDEPENDS in packagegroup, image that IMAGE_INSTALLs packagegroup not rebuilt
-Original Message- From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] Sent: November 05, 2014 10:29 AM No, you really don't need to do a complete rebuild. This is a cache problem, if you have properly removed the cache the issue (at least the latest errors) will go away. All signs of build/cache and /home/platform/Workspace/somename/poky/build/tmp/cache/default-eglibc/sonic/i686 have been removed. Still seeing the SRC_URI warnings and the virtual/fakeroot-native error. Anything else I need to remove? MV -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Added package to RDEPENDS in packagegroup, image that IMAGE_INSTALLs packagegroup not rebuilt
On Wednesday 05 November 2014 15:32:35 Vuille, Martin wrote: -Original Message- From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] Sent: November 05, 2014 10:29 AM No, you really don't need to do a complete rebuild. This is a cache problem, if you have properly removed the cache the issue (at least the latest errors) will go away. All signs of build/cache and /home/platform/Workspace/somename/poky/build/tmp/cache/default-eglibc/sonic /i686 have been removed. Still seeing the SRC_URI warnings and the virtual/fakeroot-native error. Anything else I need to remove? Rather than removing or renaming /home/platform/Workspace/somename/poky/build/tmp/cache/default- eglibc/sonic/i686, you should remove/rename the cache directory above it i.e. /home/platform/Workspace/somename/poky/build/tmp/cache/ . Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Added package to RDEPENDS in packagegroup, image that IMAGE_INSTALLs packagegroup not rebuilt
-Original Message- From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] Sent: November 05, 2014 10:36 AM Rather than removing or renaming /home/platform/Workspace/somename/poky/build/tmp/cache/default- eglibc/sonic/i686, you should remove/rename the cache directory above it i.e. /home/platform/Workspace/somename/poky/build/tmp/cache/ . Removed both build/cache and /home/platform/Workspace/somename/poky/build/tmp/cache/ Same result MV -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Added package to RDEPENDS in packagegroup, image that IMAGE_INSTALLs packagegroup not rebuilt
On Wednesday 05 November 2014 15:38:02 Vuille, Martin wrote: -Original Message- From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] Sent: November 05, 2014 10:36 AM Rather than removing or renaming /home/platform/Workspace/somename/poky/build/tmp/cache/default- eglibc/sonic/i686, you should remove/rename the cache directory above it i.e. /home/platform/Workspace/somename/poky/build/tmp/cache/ . Removed both build/cache and /home/platform/Workspace/somename/poky/build/tmp/cache/ Same result If by same result you mean you are still getting these errors, something very strange is going on. I know I kind of asked this before, but bitbake really isn't still remaining resident, right? i.e. while bitbake is apparently not running, do you have any bitbake process in ps aux output? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Added package to RDEPENDS in packagegroup, image that IMAGE_INSTALLs packagegroup not rebuilt
-Original Message- From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] Same result If by same result you mean you are still getting these errors, something very strange is going on. Yes, that's what I mean. Yes, very strange. I know I kind of asked this before, but bitbake really isn't still remaining resident, right? i.e. while bitbake is apparently not running, do you have any bitbake process in ps aux output? I don't recall you asking this before, and I certainly never checked. ps ax | grep bitbake gives me ... 4165 pts/1S 0:00 python /home/platform/Workspace/somename/poky/bitbake/bin/../lib/toaster/manage.py runserver 0.0.0.0:8000 4167 pts/1Sl 5:05 /usr/bin/python /home/platform/Workspace/somename/poky/bitbake/bin/../lib/toaster/manage.py runserver 0.0.0.0:8000 4175 ?Sl 6:58 python /home/platform/Workspace/somename/poky/bitbake/bin/bitbake --postread conf/toaster.conf --server-only -t xmlrpc -B localhost:8200 4176 pts/1Sl24:56 python /home/platform/Workspace/somename/poky/bitbake/bin/bitbake --observe-only -u toasterui perhaps because I am running Toaster locally? MV -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Added package to RDEPENDS in packagegroup, image that IMAGE_INSTALLs packagegroup not rebuilt
On Wednesday 05 November 2014 15:51:03 Vuille, Martin wrote: -Original Message- From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] Same result If by same result you mean you are still getting these errors, something very strange is going on. Yes, that's what I mean. Yes, very strange. I know I kind of asked this before, but bitbake really isn't still remaining resident, right? i.e. while bitbake is apparently not running, do you have any bitbake process in ps aux output? I don't recall you asking this before, and I certainly never checked. Yeah, I should really have asked the above, instead I asked about what script you started the build with so we got led down the wrong path - sorry about that. ps ax | grep bitbake gives me ... 4165 pts/1S 0:00 python /home/platform/Workspace/somename/poky/bitbake/bin/../lib/toaster/manage.py runserver 0.0.0.0:8000 4167 pts/1Sl 5:05 /usr/bin/python /home/platform/Workspace/somename/poky/bitbake/bin/../lib/toaster/manage.py runserver 0.0.0.0:8000 4175 ?Sl 6:58 python /home/platform/Workspace/somename/poky/bitbake/bin/bitbake --postread conf/toaster.conf --server-only -t xmlrpc -B localhost:8200 4176 pts/1 Sl24:56 python /home/platform/Workspace/somename/poky/bitbake/bin/bitbake --observe-only -u toasterui perhaps because I am running Toaster locally? OK, so this kind of explains it. To be perfectly honest the bitbake memory resident functionality (which Toaster uses behind the scenes) does have some holes in picking up changes, but I hadn't realised it would manifest in this particular manner. It seems like at the moment you'd need to stop and restart Toaster to be sure that the change gets picked up. Would you be able to file a bug for this issue mentioning that you are using Toaster? Hopefully we can get some focus on fixing the behaviour. Thanks, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-selinux] all files unlabeled_t when using squashfs
Hi Josh, [[yocto] [meta-selinux] all files unlabeled_t when using squashfs] On 14.11.03 (Mon 18:48) josh_penn...@dell.com wrote: Hello, I’m working on a project using the meta-selinux reference policy on an embedded system. The device uses a squashfs file system that is labeled during build time. During the build, policy file labels are applied using Pseudo and setfiles with an alternate root path specified. Also if I modify the build to use sudo setfiles I can confirm the file tags are correct. What about when the system is booted? I mean, can you try relabling the filesystem on the target itself? Historically it's been a pretty sticky challenge to get labels correct in a target fs in a cross-build environment, even when it's only a half-cross scenario (that is, building on x86-64 for x86-64 but still using the x-build environment). I've worked on a number of projects in the past where we've had to make this work and it does tend to be full of blind alleys. :-) Anyway, it sounds like things are mostly good with your setup, but I'd like to know if you are able to first do something like booting your system, verifying you have the unlabeled_t scenario, then do a 'fixfiles -F restore' or 'fixfiles -F relabel' on your live system, that would help. Also, before you boot your system for the first time, can you check to see if there is a '/.autorelabel' file present and, if so, if there are any warnings or errors reported during your first boot? Usually if there is a problem, that'll point toward it. Currently this is being done with Yocto 1.3 for prototyping on some older hardware but moving forward Yocto 1.7 will be used. Yeah, if it's at all possible to migrate to something newer, that'd be your best option. 1.3 is pretty long in the tooth and there's been a lot of improvements in meta-selinux in the interim. -J. Using a Fedora system it is possible to mount the squashfs file and confirm the file labels are correct. When the target system is flashed the file labels for the squashfs files are incorrect, but ram disk files are correct. Using ls –laZ, all squashfs files are system_u:object_r:unlabeled_t The kernel .config values for squsahfs and selinux here here CONFIG_SQUASHFS=y CONFIG_SQUASHFS_XATTR=y CONFIG_SQUASHFS_ZLIB=y CONFIG_SQUASHFS_LZO=y CONFIG_SQUASHFS_XZ=y # CONFIG_SQUASHFS_4K_DEVBLK_SIZE is not set CONFIG_SQUASHFS_EMBEDDED=y CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=10 CONFIG_SECURITY_SELINUX=y CONFIG_SECURITY_SELINUX_BOOTPARAM=y CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1 CONFIG_SECURITY_SELINUX_DISABLE=y CONFIG_SECURITY_SELINUX_DEVELOP=y CONFIG_SECURITY_SELINUX_AVC_STATS=y CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1 CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX=n # CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set Has anyone else run into this problem? Any suggestions on what may be wrong? Regards, josh -- -Joe MacDonald. :wq signature.asc Description: Digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Added package to RDEPENDS in packagegroup, image that IMAGE_INSTALLs packagegroup not rebuilt
-Original Message- From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] Sent: November 05, 2014 11:04 AM I don't recall you asking this before, and I certainly never checked. Yeah, I should really have asked the above, instead I asked about what script you started the build with so we got led down the wrong path - sorry about that. ps ax | grep bitbake gives me ... 4165 pts/1S 0:00 python /home/platform/Workspace/somename/poky/bitbake/bin/../lib/toaster/m anage.py runserver 0.0.0.0:8000 4167 pts/1Sl 5:05 /usr/bin/python /home/platform/Workspace/somename/poky/bitbake/bin/../lib/toaster/m anage.py runserver 0.0.0.0:8000 4175 ?Sl 6:58 python /home/platform/Workspace/somename/poky/bitbake/bin/bitbake -- postread conf/toaster.conf --server-only -t xmlrpc -B localhost:8200 4176 pts/1 Sl24:56 python /home/platform/Workspace/somename/poky/bitbake/bin/bitbake --observe-only -u toasterui perhaps because I am running Toaster locally? OK, so this kind of explains it. To be perfectly honest the bitbake memory resident functionality (which Toaster uses behind the scenes) does have some holes in picking up changes, but I hadn't realised it would manifest in this particular manner. It seems like at the moment you'd need to stop and restart Toaster to be sure that the change gets picked up. Would you be able to file a bug for this issue mentioning that you are using Toaster? Hopefully we can get some focus on fixing the behaviour. Happy to file a bug, still need to wrap my head around the problem. So, the hypothesis is that the change was not detected because Toaster was running locally at the time. Correct? If so, I can verify that and file a bug accordingly. I would file that against bitbake? MV -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Added package to RDEPENDS in packagegroup, image that IMAGE_INSTALLs packagegroup not rebuilt
On Wednesday 05 November 2014 16:16:21 Vuille, Martin wrote: -Original Message- From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] Sent: November 05, 2014 11:04 AM I don't recall you asking this before, and I certainly never checked. Yeah, I should really have asked the above, instead I asked about what script you started the build with so we got led down the wrong path - sorry about that. ps ax | grep bitbake gives me ... 4165 pts/1S 0:00 python /home/platform/Workspace/somename/poky/bitbake/bin/../lib/toaster/m anage.py runserver 0.0.0.0:8000 4167 pts/1Sl 5:05 /usr/bin/python /home/platform/Workspace/somename/poky/bitbake/bin/../lib/toaster/m anage.py runserver 0.0.0.0:8000 4175 ?Sl 6:58 python /home/platform/Workspace/somename/poky/bitbake/bin/bitbake -- postread conf/toaster.conf --server-only -t xmlrpc -B localhost:8200 4176 pts/1 Sl24:56 python /home/platform/Workspace/somename/poky/bitbake/bin/bitbake --observe-only -u toasterui perhaps because I am running Toaster locally? OK, so this kind of explains it. To be perfectly honest the bitbake memory resident functionality (which Toaster uses behind the scenes) does have some holes in picking up changes, but I hadn't realised it would manifest in this particular manner. It seems like at the moment you'd need to stop and restart Toaster to be sure that the change gets picked up. Would you be able to file a bug for this issue mentioning that you are using Toaster? Hopefully we can get some focus on fixing the behaviour. Happy to file a bug, still need to wrap my head around the problem. So, the hypothesis is that the change was not detected because Toaster was running locally at the time. Correct? Correct. If so, I can verify that and file a bug accordingly. I would file that against bitbake? Yes. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Added package to RDEPENDS in packagegroup, image that IMAGE_INSTALLs packagegroup not rebuilt
-Original Message- From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] Sent: November 05, 2014 11:04 AM OK, so this kind of explains it. To be perfectly honest the bitbake memory resident functionality (which Toaster uses behind the scenes) does have some holes in picking up changes, but I hadn't realised it would manifest in this particular manner. It seems like at the moment you'd need to stop and restart Toaster to be sure that the change gets picked up. - Stopped Toaster - Removed the two cache directories - bitbake packagegroup is working. It is running do_package on each of the packages in the packagegroup. Thanks for your time debugging this. MV -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] Perl: fix PERL5LIB settings
The PERL5LIB settings in the perl wrapper script did not include the
site_perl or vendor_perl directories, which caused some errors.
See https://bugzilla.yoctoproject.org/show_bug.cgi?id=6890
Signed-off-by: Wolfgang Denk w...@denx.de
---
meta/recipes-devtools/perl/perl-native_5.14.3.bb | 4 ++--
meta/recipes-devtools/perl/perl_5.14.3.bb| 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-devtools/perl/perl-native_5.14.3.bb
b/meta/recipes-devtools/perl/perl-native_5.14.3.bb
index c9ec2d2..8ea7ddb 100644
--- a/meta/recipes-devtools/perl/perl-native_5.14.3.bb
+++ b/meta/recipes-devtools/perl/perl-native_5.14.3.bb
@@ -101,8 +101,8 @@ do_install () {
install $i ${D}${libdir}/perl/${PV}/CORE
done
- create_wrapper ${D}${bindir}/perl
PERL5LIB='$PERL5LIB:${STAGING_LIBDIR}/perl/${PV}:${STAGING_LIBDIR}/perl/'
- create_wrapper ${D}${bindir}/perl${PV}
PERL5LIB='$PERL5LIB:${STAGING_LIBDIR}/perl/${PV}:${STAGING_LIBDIR}/perl/'
+ create_wrapper ${D}${bindir}/perl
PERL5LIB='$PERL5LIB:${STAGING_LIBDIR}/perl/${PV}:${STAGING_LIBDIR}/perl:${STAGING_LIBDIR}/perl/site_perl/${PV}:${STAGING_LIBDIR}/perl/vendor_perl/${PV}'
+ create_wrapper ${D}${bindir}/perl${PV}
PERL5LIB='$PERL5LIB:${STAGING_LIBDIR}/perl/${PV}:${STAGING_LIBDIR}/perl${STAGING_LIBDIR}/perl:${STAGING_LIBDIR}/perl/site_perl/${PV}:${STAGING_LIBDIR}/perl/vendor_perl/${PV}'
}
SYSROOT_PREPROCESS_FUNCS += perl_sysroot_create_wrapper
diff --git a/meta/recipes-devtools/perl/perl_5.14.3.bb
b/meta/recipes-devtools/perl/perl_5.14.3.bb
index 1e14e17..7ea2c99 100644
--- a/meta/recipes-devtools/perl/perl_5.14.3.bb
+++ b/meta/recipes-devtools/perl/perl_5.14.3.bb
@@ -215,7 +215,7 @@ do_install() {
do_install_append_class-nativesdk () {
create_wrapper ${D}${bindir}/perl \
-
PERL5LIB='$PERL5LIB:$OECORE_NATIVE_SYSROOT/${libdir_nativesdk}/perl:$OECORE_NATIVE_SYSROOT/${libdir_nativesdk}/perl/${PV}'
+
PERL5LIB='$PERL5LIB:$OECORE_NATIVE_SYSROOT/${libdir_nativesdk}/perl:$OECORE_NATIVE_SYSROOT/${libdir_nativesdk}/perl/${PV}:$OECORE_NATIVE_SYSROOT/${libdir_nativesdk}/perl/site_perl/${PV}:$OECORE_NATIVE_SYSROOT/${libdir_nativesdk}/perl/vendor_perl/${PV}'
}
PACKAGE_PREPROCESS_FUNCS += perl_package_preprocess
--
1.8.3.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-selinux] master branch updated / dizzy branch created
Hi all, As previously discussed, meta-selinux has been updated with both the latest reference policy (and derivatives) and userspace tools. As nothing has come up with testing in master-next those changes have now been merged into master. At the same time we now have a dizzy branch to provide stable updates for Yocto 1.7 as required. Please let us know if you see anything unexpected. -- -Joe MacDonald. :wq signature.asc Description: Digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
