[yocto] Multilib build problem
Hello, With a recent poky tree (updated on 16.07.2012) I'm unable to make a multilib build. I added these lines to my conf/local.conf: require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "x86" With this configuration, I get an error when I try to build lib32-core-image-sato-sdk: /poky/build [] $ bitbake lib32-core-image-sato-sdk Loading cache: 100% |###| ETA: 00:00:00 Loaded 1882 entries from dependency cache. Build Configuration: BB_VERSION= "1.15.2" TARGET_ARCH = "x86_64" TARGET_OS = "linux" MACHINE = "qemux86-64" DISTRO= "poky" DISTRO_VERSION= "1.2+snapshot-20120716" TUNE_FEATURES = "m64" TARGET_FPU= "" meta meta-yocto= "master:eb0cb7e8234f5d2e5623406e9660be91cf52f65e" NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue ERROR: Task do_package_setscene depends upon non-existent task /poky/poky/meta/recipes-core/base-passwd/base-passwd_3.5.24.bb:do_populate_sysroot_setscene Summary: There was 1 ERROR message shown, returning a non-zero exit code. 'bitbake core-image-sato-sdk' works with the same configuration. Does anybody have any hints for fixing this issue? Thanks, Bogdan ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Building a custom dtb kernel
Aloha all, I have successfully managed to build a custom kernel, thanks to the help on IRC. Unfortunately this is only step one of my travels with Yocto. I now need to be able to build the kernel with dtb. Part of my issue is that the .dtsi and .dts files that I require are in a separate git tree to the kernel source, due to the hardware being extremely weird and for internal use only. I also need to cat the resulting .dtb to the Zimage and then rename the resulting zimageA15RTSM.bin to zImage. From my understanding I need to include the following in my kernel recipe: require linux-dtb.inc SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git;branch=ael-12.03.00;protocol=git;destsuffix=source;name=source git://linux-arm.org/arm-dts.git;branch=AEL-2012.03;protocol=git;destsuffix=dts;name=dts \ file://defconfig \ " KERNEL_DEVICETREE_rtsm_ve-cortex_a15x2.dts = "rtsm_ve-cortex_a15x2.dts" KERNEL_DEVICETREE_rtsm_ve-motherboard.dtsi = "rtsm_ve-motherboard.dtsi" The issue I seem to be hitting is that when I have the multiple git repos, as per the SRC_URI above, it appears to me that it runs do_configure in the last tree which only holds the .dts files. I get the following error when running bitbake core-image-minimal: | DEBUG: Python function sysroot_cleansstate finished | DEBUG: Executing shell function do_configure | NOTE: make oldconfig | make: *** No rule to make target `oldconfig'. Stop. | ERROR: oe_runmake failed | ERROR: Function failed: do_configure (see /home/andwaf01/Code/Yocto/build/tmp-eglibc/work/qemuarmv7a-oe-linux-gnueabi/linux-ael-3.3+git1+2a521d1e7167375a8329e94ea110965d36968139_1+4a3978695b04436a62262d1ef376e51f0637402a-r0/temp/log.do_configure.5805 for further information) NOTE: package linux-ael-3.3+git1+2a521d1e7167375a8329e94ea110965d36968139_1+4a3978695b04436a62262d1ef376e51f0637402a-r0: task do_configure: Failed ERROR: Task 611 (/home/andwaf01/Code/meta-vexa15/recipes-kernel/linux/linux-ael_3.3.bb, do_configure) failed with exit code '1' NOTE: Tasks Summary: Attempted 1540 tasks of which 1535 didn't need to be rerun and 1 failed. IS my assumption correct or am I fishing in the wrong pond? How am I supposed to build a dtb kernel correctly? Many thanks, Andy -- Andrew Wafaa IRC: FunkyPenguin GPG: 0x3A36312F ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto and Qt embedded
Thanks Khem, I successfully found g++ compiler path which is: /opt/poky/1.2.1/sysroots/i686-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ now I was able to configure the poky tool chain into Qt creator (using default mkspec which is linux-g++); after that I tried to configure Qt Version (4.7.4) in Qt creator using the following qmake file: /opt/poky/1.2.1/sysroots/i686-pokysdk-linux/usr/bin/qmake Now Qt creator gives me a warning: *"ABI detection failed: Make sure to use a matching tool chain when building"* * * ABI is automatically set to arm-linux-generic-elf and this warning prevents me to select arm tool chain for building my application. Am I using the wrong mkspec? (The other ones seems unsuitable for me..) Thanks Giovanni -- Dott. Ing. Giovanni Foiani Cell:+39-349-3577515 Phone:+39-0532-97-4106 mail:giovanni.foi...@unife.it CenTec - Corso Guercino, 47 - 44042 Cento (FE) On Sat, Jul 14, 2012 at 8:17 PM, Khem Raj wrote: > On Sat, Jul 14, 2012 at 3:15 AM, Giovanni Foiani wrote: > > So I tried to find g++ compiler using "find" command, into: > > > > /opt/poky/1.2.1/sysroots/i686-pokysdk-linux/ > > > > with no success. > > find "*g++" > ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] edison/denzil patches (post-1.1.2 and 1.2.1)
On 12/07/12 10:43, McClintock Matthew-B29882 wrote: Josh, Scott: I've pushed a set of patches for edison/denzil branch - and I may push a few more still to: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/edison http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/denzil These are all cherry-pick's and most applied cleanly and a few had some minor cleanups. Please consider these for after the point releases. I will continue to push to these branches and rebase these branches off the official upstream trees as well. I don't know how much work will be done on Edison after the 1.1.2 release. I personally will no longer be working on it and I don't think the team here as enough resources to maintain it perpetually. I assume that these changes are predominantly to further improve PPC support? In general your branch has several types of changes that have generally been considered inappropriate for a point release (such as recipe upgrades, new functionality, etc). Personally I'm not very keen on the idea of pushing them all and advocating their inclusion. I'd strongly encourage adoption of this release series if it's to continue to be relevant to your work. Cheers, Joshua -- Joshua Lock Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] edison/denzil patches (post-1.1.2 and 1.2.1)
On Mon, Jul 16, 2012 at 9:58 AM, Joshua Lock wrote: > On 12/07/12 10:43, McClintock Matthew-B29882 wrote: >> >> Josh, Scott: >> >> I've pushed a set of patches for edison/denzil branch - and I may push >> a few more still to: >> >> >> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/edison >> >> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/denzil >> >> These are all cherry-pick's and most applied cleanly and a few had >> some minor cleanups. Please consider these for after the point >> releases. I will continue to push to these branches and rebase these >> branches off the official upstream trees as well. > > > I don't know how much work will be done on Edison after the 1.1.2 release. I > personally will no longer be working on it and I don't think the team here > as enough resources to maintain it perpetually. OK. > I assume that these changes are predominantly to further improve PPC > support? Yes. > In general your branch has several types of changes that have generally been > considered inappropriate for a point release (such as recipe upgrades, new > functionality, etc). I see very little of this, the valgrind series and/or the a few other image generation bits. > Personally I'm not very keen on the idea of pushing them all and advocating > their inclusion. I'd strongly encourage adoption of this release series if > it's to continue to be relevant to your work. So is poky edison dead now? How do I support folks that still want to use it? I understand that *you* may not have time but is there a process for someone that cares about this release still to do work? If a fork is required is there a way to point folks at this fork? Such as if you want this to work use this other version? As far as these changes go, we are mostly done with edison as well - but I was trying to get the official poky edison into a useful state for powerpc so if folks wanted to go with a community version it would work reasonably well. -M ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] edison/denzil patches (post-1.1.2 and 1.2.1)
On 16/07/12 08:10, McClintock Matthew-B29882 wrote: On Mon, Jul 16, 2012 at 9:58 AM, Joshua Lock wrote: On 12/07/12 10:43, McClintock Matthew-B29882 wrote: Josh, Scott: I've pushed a set of patches for edison/denzil branch - and I may push a few more still to: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/edison http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/denzil These are all cherry-pick's and most applied cleanly and a few had some minor cleanups. Please consider these for after the point releases. I will continue to push to these branches and rebase these branches off the official upstream trees as well. I don't know how much work will be done on Edison after the 1.1.2 release. I personally will no longer be working on it and I don't think the team here as enough resources to maintain it perpetually. OK. I assume that these changes are predominantly to further improve PPC support? Yes. In general your branch has several types of changes that have generally been considered inappropriate for a point release (such as recipe upgrades, new functionality, etc). I see very little of this, the valgrind series and/or the a few other image generation bits. Indeed, that's likely the sum of it but the changes in isolation don't offer any context as to why they're required for PPC so my gut reaction is to reject them as they violate the suggested guidelines for stable releases. Personally I'm not very keen on the idea of pushing them all and advocating their inclusion. I'd strongly encourage adoption of this release series if it's to continue to be relevant to your work. So is poky edison dead now? How do I support folks that still want to use it? I understand that *you* may not have time but is there a process for someone that cares about this release still to do work? If a fork is required is there a way to point folks at this fork? Such as if you want this to work use this other version? I certainly can't see why one would need to fork. I would like to see Edison live on, which is why I sent an email suggesting it be adopted, *I* just don't have time to work on it any more. I'm sure Saul and/or David can help work out a process, as I don't have a clear understanding of it (I am but one cog in the engine). I can't imagine why it would be hugely different from the way it's been maintained thus far. Much of that work you've already been doing with the branch you have submitted. In addition there are a different set of requirements for just getting changes into the branch vs. having some kind of release which includes those changes. The latter would require QA, build/release engineering, release readiness, etc. Thanks, Joshua -- Joshua Lock Yocto Project Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] edison/denzil patches (post-1.1.2 and 1.2.1)
On Mon, Jul 16, 2012 at 10:32 AM, Joshua Lock wrote: > On 16/07/12 08:10, McClintock Matthew-B29882 wrote: >> >> On Mon, Jul 16, 2012 at 9:58 AM, Joshua Lock wrote: >>> >>> On 12/07/12 10:43, McClintock Matthew-B29882 wrote: Josh, Scott: I've pushed a set of patches for edison/denzil branch - and I may push a few more still to: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/edison http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/denzil These are all cherry-pick's and most applied cleanly and a few had some minor cleanups. Please consider these for after the point releases. I will continue to push to these branches and rebase these branches off the official upstream trees as well. >>> >>> >>> >>> I don't know how much work will be done on Edison after the 1.1.2 >>> release. I >>> personally will no longer be working on it and I don't think the team >>> here >>> as enough resources to maintain it perpetually. >> >> >> OK. >> >>> I assume that these changes are predominantly to further improve PPC >>> support? >> >> >> Yes. >> >>> In general your branch has several types of changes that have generally >>> been >>> considered inappropriate for a point release (such as recipe upgrades, >>> new >>> functionality, etc). >> >> >> I see very little of this, the valgrind series and/or the a few other >> image generation bits. > > > Indeed, that's likely the sum of it but the changes in isolation don't offer > any context as to why they're required for PPC so my gut reaction is to > reject them as they violate the suggested guidelines for stable releases. I'm fine to have some of them rejected, such is how things work ;) >>> Personally I'm not very keen on the idea of pushing them all and >>> advocating >>> their inclusion. I'd strongly encourage adoption of this release series >>> if >>> it's to continue to be relevant to your work. >> >> >> So is poky edison dead now? How do I support folks that still want to >> use it? I understand that *you* may not have time but is there a >> process for someone that cares about this release still to do work? If >> a fork is required is there a way to point folks at this fork? Such as >> if you want this to work use this other version? > > > I certainly can't see why one would need to fork. > > I would like to see Edison live on, which is why I sent an email suggesting > it be adopted, *I* just don't have time to work on it any more. I know what you mean ;) > I'm sure Saul and/or David can help work out a process, as I don't have a > clear understanding of it (I am but one cog in the engine). I can't imagine > why it would be hugely different from the way it's been maintained thus far. > > Much of that work you've already been doing with the branch you have > submitted. Yep, I've made my best effort to only backport commits already upstream. > In addition there are a different set of requirements for just getting > changes into the branch vs. having some kind of release which includes those > changes. > > The latter would require QA, build/release engineering, release readiness, > etc. I understand. I'm fine with adding stuff to the edison branch for now and we can worry about another official release sometime in the future (or never). I'm mostly wanting a place I can tell people to get the (working) code from for our targets. And ideally it's on yoctoproject.org and not github.com or git.fsl.com Just for some more context, we just release our SDK off of edison and I expect plenty of activity around bugfixes and back porting commits. I would like this work to be available to all attempting to build edison as well. -M ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] edison/denzil patches (post-1.1.2 and 1.2.1)
On 07/12/2012 10:43 AM, McClintock Matthew-B29882 wrote: Josh, Scott: I've pushed a set of patches for edison/denzil branch - and I may push a few more still to: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/edison http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/denzil These are all cherry-pick's and most applied cleanly and a few had some minor cleanups. Please consider these for after the point releases. I will continue to push to these branches and rebase these branches off the official upstream trees as well. Cool, this is a fairly convenient way for me to merge in these commits. Like Joshua has pointed out, as long as they are bugfixes and don't introduce significant feature additions or create backward compatibility problems, we are likely to accept them. I'm back from vacation and am catching up on a massive email backlog. Please feel free to ping me in a few days if you don't see these merged into my sgarman/denzil-next-1.2.2 branch. Thanks, Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] edison/denzil patches (post-1.1.2 and 1.2.1)
On Mon, Jul 16, 2012 at 11:22 AM, Scott Garman wrote: > On 07/12/2012 10:43 AM, McClintock Matthew-B29882 wrote: >> >> Josh, Scott: >> >> I've pushed a set of patches for edison/denzil branch - and I may push >> a few more still to: >> >> >> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/edison >> >> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/denzil >> >> These are all cherry-pick's and most applied cleanly and a few had >> some minor cleanups. Please consider these for after the point >> releases. I will continue to push to these branches and rebase these >> branches off the official upstream trees as well. > > > Cool, this is a fairly convenient way for me to merge in these commits. Like > Joshua has pointed out, as long as they are bugfixes and don't introduce > significant feature additions or create backward compatibility problems, we > are likely to accept them. > > I'm back from vacation and am catching up on a massive email backlog. Please > feel free to ping me in a few days if you don't see these merged into my > sgarman/denzil-next-1.2.2 branch. Thanks Scott, I'm closing up on the edison branch changes and testing and I will be adding more to the denzil branch soon. -M > > Thanks, > > Scott > > -- > Scott Garman > Embedded Linux Engineer - Yocto Project > Intel Open Source Technology Center > > > > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] Fix for psplash segmentation fault
On 07/06/2012 01:53 PM, Aws Ismail wrote:
Fix segmentation fault when passing -a without angel value.
When psplash -a is called instead of psplash -a
it will segmentation fault calling out of bound argv[].
git://git.yoctoproject.org/psplash
Signed-of-by: Aws Ismail
-
diff --git a/psplash.c b/psplash.c
index 0158628..09cf0d0 100644
--- a/psplash.c
+++ b/psplash.c
@@ -219,7 +219,7 @@ main (int argc, char** argv)
if (!strcmp(argv[i],"-a") || !strcmp(argv[i],"--angle"))
{
- if (++i > argc) goto fail;
+ if (++i >= argc) goto fail;
angle = atoi(argv[i]);
continue;
}
Merged into psplash upstream, if you would like to send a patch to
Openembedded-Core updating the psplash recipe that would be welcome also.
Thanks
Sau!
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Agenda: Yocto Project Technical Team Meeting - Tuesday, July 17, 2012 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).
Agenda: * Opens collection - 5 min (Song) * 1.2.1 release readiness - 10 min (ScottG) * 1.1.2 release readiness - 10 min (Josh/Beth) * Yocto 1.3 status - 10 min (Song/team) https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status * SWAT team rotation: Paul -> Ross * Opens - 10 min * Team sharing - 20 min -Original Appointment- We encourage people attending the meeting to logon the Yocto IRC chancel during the meeting (optional): Yocto IRC: http://webchat.freenode.net/?channels=#yocto IRC Tutorial: http://www.irchelp.org/irchelp/irctutorial.html Conference details Conference name: Yocto Technical Team Conference date/start time: Tue Jun 26, 2012 at 10:00 AM Central Daylight Time Participants: 30 Duration: 60 minutes Participant passcode: 76994298 Dial-in number: 1.972.995. US Toll Free number: 1.877.561.6828 BlackBerry users, click this link to join your conference as a participant: 1.972.995.x76994298# Depending on where you are dialing from, either your BlackBerry will pause and enter the passcode automatically or you will be prompted to click again to dial the passcode. Local and Global Access Numbers Country Dial-in number Australia: 1800 636 843 Czech Republic: 242 430 350 China (Beijing): >From office dial 8-995 or 8784277 Beijing Out of Office dial 5878 4277 China (Shanghai): >From office dial 8-995 or 3073322 Shanghai Out of Office dial 2307 3322 China (Shenzen): >From office dial 8-995 or 6007877 Shenzen Out of Office dial 2600 7877 China (Other Cities): >From IP phone dial 8-995 Other cities - Non IP phone dial 021-23073322 Denmark: 8060 1400 Finland: 09 41333477 France: 0497 275888 Germany: 08161 803232 Holland: 030 2417490 India: BSNL subscribers use 1800 425 9996 (Toll Free) Airtel subscribers use 0008 009 861 212 (Toll Free) From TI Campus use 8995 Others use 2509 9555 (Landline within Bangalore) or 80 2509 9555 (Outside Bangalore) Israel: 09 790 6715 Italy: 039 69061234 (039 is local city code not country code) Japan: >From TI Campus use 8 995 Outside TI use 03 4331 3777 Malaysia: >From IP phone dial 2643799 >From Kuala Lumpur dial 4264 3799 Outside Kuala Lumpur dial (03)4264 3799 Norway: 2 295 8744 Philippines: >From Baguio City use 4471177 >From Metro Manila area use 8702477 Singapore: >From IP phone dial 3894777 Outside TI use 6389 4777 South Korea: >From IP phone dial 5606998 >From Seoul dial 5606998 Outside Seoul dial (02)5606998 Sweden: 08 58755577 Taiwan: >From IP phone dial 1363 >From Taipei dial 2241 1363 Outside Taipei dial (02)2241 1363 Turkey: Landline Only dial 0811 288 0001 then enter 877 633 1123 UK: 01604 663003 US: 972 995 or 1877 561 6828 Recurring conferences First scheduled conference: Tue Jun 26, 2012 Recurrence frequency: Weekly - Every 1 week(s) on Tuesday Recurrence ends: End on Fri Jun 21, 2013, 10:40 AM CDT ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] xserver-xorg
Hi all, I'm having trouble building the xserver-xorg package. The build fails with: | render2.c: In function '__glXDisp_Map1d': | render2.c:104:5: error: the comparison will always evaluate as 'true' for the address of 'u1' will never be NULL [-Werror=address] | render2.c:105:5: error: the comparison will always evaluate as 'true' for the address of 'u2' will never be NULL [-Werror=address] | render2.c: In function '__glXDisp_Map2d': | render2.c:147:5: error: the comparison will always evaluate as 'true' for the address of 'u1' will never be NULL [-Werror=address] | render2.c:148:5: error: the comparison will always evaluate as 'true' for the address of 'u2' will never be NULL [-Werror=address] | render2.c:149:5: error: the comparison will always evaluate as 'true' for the address of 'v1' will never be NULL [-Werror=address] | render2.c:150:5: error: the comparison will always evaluate as 'true' for the address of 'v2' will never be NULL [-Werror=address] | cc1: some warnings being treated as errors The target machine is a x86_64. Looks like the compiler doesn't like how the __GLX_GET_DOUBLE macro tests the address of stack variables against NULL. I would like to know if there is a patch upstream or if this is a known issue? What surprises me the most is that this machine looks a lot like the meta-sugarbay which builds correctly. Regards, Marc ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-baryon][PATCH] webmin: fix dash incompatibility in do_configure
The use of brackets was causing dash to skip over the removal of
several unwanted files. The presence of these files was causing an
exception during packaging.
Signed-off-by: Kevin Strasser
---
recipes-extended/webmin/webmin_1.570.bb |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/recipes-extended/webmin/webmin_1.570.bb
b/recipes-extended/webmin/webmin_1.570.bb
index 150d920..63a1ed2 100644
--- a/recipes-extended/webmin/webmin_1.570.bb
+++ b/recipes-extended/webmin/webmin_1.570.bb
@@ -33,9 +33,10 @@ inherit allarch perlnative update-rc.d
do_configure() {
# Remove binaries and plugins for other platforms
rm -rf acl/Authen-SolarisRBAC-0.1*
-rm -rf {format,{bsd,hpux,sgi}exports,zones,rbac,smf,ipfw,ipfilter,dfsadmin}
-rm -f mount/{free,net,open}bsd-mounts*
-rm -f mount/macos-mounts*
+rm -rf format bsdexports hpuxexports sgiexports
+rm -rf zones rbac smf ipfw ipfilter dfsadmin
+rm -f mount/freebsd-mounts* mount/netbsd-mounts*
+rm -f mount/openbsd-mounts* mount/macos-mounts*
# Remove some plugins for the moment
rm -rf lilo frox wuftpd telnet pserver cpan shorewall webalizer cfengine
fsdump pap
--
1.7.9.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [Package Report System]Upgrade recipes name list
This mail was sent out by Package Report System. This message list those recipes which need to be upgraded. If maintainers believe some of them needn't to upgrade this time, they can fill in RECIPE_NO_UPDATE_REASON_pn-"xxx" in upstream_tracking files to ignore this recipe remainder until newer upstream version was detected. Example: RECIPE_NO_UPDATE_REASON_pn-"xxx" = "Not upgrade to 2.0 because the new version is unstable" You can check the detail information at http://packages.yoctoproject.org/upgradepkgname PackageName Version UpVersion MaintainerNoUpgradeReason xserver-kdrive1.7.99.2 1.12.99.901 Xiaofeng Yan xserver-xorg-lite 1.11.21.12.99.901 Xiaofeng Yan qmmp 0.5.2 0.6.0 Xiaofeng Yan xdg-utils 1.0.2 1.1.0 Valentin Popa randrproto1.3.2 1.4.0 Valentin Popa glproto 1.4.151.4.16 Valentin Popa dri2proto 2.6 2.8 Valentin Popa liberation-fonts 1.04 1.07.2 Valentin Popa pciutils 3.1.9 3.1.10 Valentin Popa qemu 0.15.11.1.1 Valentin Popa evolution-data-server 2.30+git1+3ca578d968d097 6.0 Valentin Popa matchbox-panel-2 0.0+git1+cdf7a22716b8746 2.0 Valentin Popa lttng-viewer 0.12.38 0.12.38.21032011 Valentin Popa shadow4.1.4.3 4.1.5.1 Scott Garman blktool 4-6 4 Scott Garman apmd 3.2.2-14 3.2.2 Scott Garman dbus-glib 0.98 0.100 Scott Garman libnfsidmap 0.24 0.25 Scott Garman foomatic-filters 4.0.164.0.17 Saul Wold libnl 2.0 3.2.11 Saul Woldlibnl-3.2.2 is incompatible w... createrepo0.4.110.9.9 Saul WoldVersions after 0.9.* use YUM,... apt 0.7.140.9.7.2 Saul Wold dpkg 1.15.8.7 1.16.4.3 Saul Wold pkgconfig 0.25 0.27 Saul Wold0.26 removes glib-conf, adds ... build-appliance-image 1.0 3.2.1 Saul Wold dhcp 4.2.3-P2 4.2.3 Saul Wold ftp://ftp.isc.org/isc/dhcp/4.2.3-P2/dhcp-4.2.3-P2.tar.gz liburcu 0.6.7 0.7.3 Radu Moisan js1.7.0+1.8.0rc11.60 Radu Moisan usbutils 0.91 006 Radu Moisan grub 1.99 2.00 Radu Moisan ftp://ftp.gnu.org/gnu/grub/grub-1.99.tar.gz u-boot-fw-utils 2011.06 2012.07 Radu Moisan babeltrace0.8+git1+efc507756840300 1.0.0 Radu Moisan udev 164 182 Radu Moisan busybox 1.19.41.20.2 Radu Moisan mobile-broadband-provider-info1.0.0+gitr1+d9995ef693cb 20090309 R
[yocto] [Package Report System]Manual check recipes name list
This mail was sent out by Package Report System. It will list all the recipes which can't check upstream version by script, and will show how long it is since their last mannual version check. You can check the detail information at http://packages.yoctoproject.org/manuallychkinfo PackageName Version LastChkVersion LastChkTime Maintainer NoUpgradeReason lsb 1.4 1.4 89 days Yi Zhao ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] edison/denzil patches (post-1.1.2 and 1.2.1)
On Mon, 2012-07-16 at 16:01 +, McClintock Matthew-B29882 wrote: > On Mon, Jul 16, 2012 at 10:32 AM, Joshua Lock wrote: > > On 16/07/12 08:10, McClintock Matthew-B29882 wrote: > >> > >> On Mon, Jul 16, 2012 at 9:58 AM, Joshua Lock wrote: > >>> > >>> On 12/07/12 10:43, McClintock Matthew-B29882 wrote: > > > Josh, Scott: > > I've pushed a set of patches for edison/denzil branch - and I may push > a few more still to: > > > > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/edison > > > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/denzil > > These are all cherry-pick's and most applied cleanly and a few had > some minor cleanups. Please consider these for after the point > releases. I will continue to push to these branches and rebase these > branches off the official upstream trees as well. > >>> > >>> > >>> > >>> I don't know how much work will be done on Edison after the 1.1.2 > >>> release. I > >>> personally will no longer be working on it and I don't think the team > >>> here > >>> as enough resources to maintain it perpetually. > >> > >> > >> OK. > >> > >>> I assume that these changes are predominantly to further improve PPC > >>> support? > >> > >> > >> Yes. > >> > >>> In general your branch has several types of changes that have generally > >>> been > >>> considered inappropriate for a point release (such as recipe upgrades, > >>> new > >>> functionality, etc). > >> > >> > >> I see very little of this, the valgrind series and/or the a few other > >> image generation bits. > > > > > > Indeed, that's likely the sum of it but the changes in isolation don't offer > > any context as to why they're required for PPC so my gut reaction is to > > reject them as they violate the suggested guidelines for stable releases. > > I'm fine to have some of them rejected, such is how things work ;) > > >>> Personally I'm not very keen on the idea of pushing them all and > >>> advocating > >>> their inclusion. I'd strongly encourage adoption of this release series > >>> if > >>> it's to continue to be relevant to your work. > >> > >> > >> So is poky edison dead now? How do I support folks that still want to > >> use it? I understand that *you* may not have time but is there a > >> process for someone that cares about this release still to do work? If > >> a fork is required is there a way to point folks at this fork? Such as > >> if you want this to work use this other version? > > > > > > I certainly can't see why one would need to fork. > > > > I would like to see Edison live on, which is why I sent an email suggesting > > it be adopted, *I* just don't have time to work on it any more. > > I know what you mean ;) > > > I'm sure Saul and/or David can help work out a process, as I don't have a > > clear understanding of it (I am but one cog in the engine). I can't imagine > > why it would be hugely different from the way it's been maintained thus far. > > > > Much of that work you've already been doing with the branch you have > > submitted. > > Yep, I've made my best effort to only backport commits already upstream. > > > In addition there are a different set of requirements for just getting > > changes into the branch vs. having some kind of release which includes those > > changes. > > > > The latter would require QA, build/release engineering, release readiness, > > etc. > > I understand. I'm fine with adding stuff to the edison branch for now > and we can worry about another official release sometime in the future > (or never). I'm mostly wanting a place I can tell people to get the > (working) code from for our targets. And ideally it's on > yoctoproject.org and not github.com or git.fsl.com Great, the best thing would be to submit a pull request against the edison branch with a suitable subject. > > Just for some more context, we just release our SDK off of edison and > I expect plenty of activity around bugfixes and back porting commits. > I would like this work to be available to all attempting to build > edison as well. Congratulations! I appreciate your effort in sharing this work. Joshua ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Is it just me? Can't get 'Atom-PC' to boot.
I've built the 'atom-pc' kernel as follows: 1) git clone git://git.yoctoproject.org/poky.git 2) git checkout denzil 3) source poky/oe-init-build-env work-area 4) Edit local.conf so that threads/parallel make are both 16 and MACHINE is 'atom-pc' 8) bitbake virtual/kernel. However, the kernel that gets produced fails to boot. All I get is a screen full of random characters and nothing comes out of the serial port (configured for kernel messages). I don't get any 'Loading...' or 'Uncompressing...' messages either. Using a kernel image from else where (e.g. Voyage Linux) works as expected. What do I need to do differently to get the above to build a bootable image? I'm assuming that 'atom-pc' works for others? Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Is it just me? Can't get 'Atom-PC' to boot.
On 07/16/2012 04:25 PM, Chris Tapp wrote: I've built the 'atom-pc' kernel as follows: 1) git clone git://git.yoctoproject.org/poky.git 2) git checkout denzil 3) source poky/oe-init-build-env work-area 4) Edit local.conf so that threads/parallel make are both 16 and MACHINE is 'atom-pc' 8) bitbake virtual/kernel. However, the kernel that gets produced fails to boot. All I get is a screen full of random characters and nothing comes out of the serial port (configured for kernel messages). I don't get any 'Loading...' or 'Uncompressing...' messages either. Using a kernel image from else where (e.g. Voyage Linux) works as expected. What do I need to do differently to get the above to build a bootable image? I'm assuming that 'atom-pc' works for others? When I build for Atom PCs, I'm usually targeting a specific BSP like CrownBay, n450, Cedartrail. All of those require the meta-intel layer. So you need to edit the local.conf with a machine like n450, crownbay, cedartrail, etc. and you need to edit bblayer.conf to add the meta-intel layer and the meta-intel/meta/crownbay, etc. I always bitbake core-image minimal or core-image-sato. Jim A Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Is it just me? Can't get 'Atom-PC' to boot.
On Monday, 16 July 2012 at 21:25, Chris Tapp wrote: > I've built the 'atom-pc' kernel as follows: > > 1) git clone git://git.yoctoproject.org/poky.git > (http://git.yoctoproject.org/poky.git) > 2) git checkout denzil > 3) source poky/oe-init-build-env work-area > 4) Edit local.conf so that threads/parallel make are both 16 and MACHINE is > 'atom-pc' > 8) bitbake virtual/kernel. > > However, the kernel that gets produced fails to boot. All I get is a screen > full of random characters and nothing comes out of the serial port > (configured for kernel messages). I don't get any 'Loading...' or > 'Uncompressing...' messages either. Using a kernel image from else where > (e.g. Voyage Linux) works as expected. > > What do I need to do differently to get the above to build a bootable image? > I'm assuming that 'atom-pc' works for others? How are you actually booting the kernel? I frequently boot the generated hddimg when written to a USB stick on my Zotac box, but it's well known that PC hardware is a nightmare to boot reliably... Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Is it just me? Can't get 'Atom-PC' to boot.
On 16 Jul 2012, at 22:02, Ross Burton wrote: > On Monday, 16 July 2012 at 21:25, Chris Tapp wrote: >> I've built the 'atom-pc' kernel as follows: >> >> 1) git clone git://git.yoctoproject.org/poky.git >> (http://git.yoctoproject.org/poky.git) >> 2) git checkout denzil >> 3) source poky/oe-init-build-env work-area >> 4) Edit local.conf so that threads/parallel make are both 16 and MACHINE is >> 'atom-pc' >> 8) bitbake virtual/kernel. >> >> However, the kernel that gets produced fails to boot. All I get is a screen >> full of random characters and nothing comes out of the serial port >> (configured for kernel messages). I don't get any 'Loading...' or >> 'Uncompressing...' messages either. Using a kernel image from else where >> (e.g. Voyage Linux) works as expected. >> >> What do I need to do differently to get the above to build a bootable image? >> I'm assuming that 'atom-pc' works for others? > How are you actually booting the kernel? I frequently boot the generated > hddimg when written to a USB stick on my Zotac box, but it's well known that > PC hardware is a nightmare to boot reliably... I've got a USB stick with Extlinux on it. The profile I use is always the same - I just change the 'KERNEL' stanza to point to a different kernel image. opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Is it just me? Can't get 'Atom-PC' to boot.
On 16 Jul 2012, at 21:40, Jim Abernathy wrote: > On 07/16/2012 04:25 PM, Chris Tapp wrote: >> I've built the 'atom-pc' kernel as follows: >> >> 1) git clone git://git.yoctoproject.org/poky.git >> 2) git checkout denzil >> 3) source poky/oe-init-build-env work-area >> 4) Edit local.conf so that threads/parallel make are both 16 and MACHINE is >> 'atom-pc' >> 8) bitbake virtual/kernel. >> >> However, the kernel that gets produced fails to boot. All I get is a screen >> full of random characters and nothing comes out of the serial port >> (configured for kernel messages). I don't get any 'Loading...' or >> 'Uncompressing...' messages either. Using a kernel image from else where >> (e.g. Voyage Linux) works as expected. >> >> What do I need to do differently to get the above to build a bootable image? >> I'm assuming that 'atom-pc' works for others? > When I build for Atom PCs, I'm usually targeting a specific BSP like > CrownBay, n450, Cedartrail. All of those require the meta-intel layer. So you > need to edit the local.conf with a machine like n450, crownbay, cedartrail, > etc. and you need to edit bblayer.conf to add the meta-intel layer and the > meta-intel/meta/crownbay, etc. I've just tried 'n450' and that gives the same result - I.e. screen full of random stuff. > I always bitbake core-image minimal or core-image-sato. I generally build a full image as well, but I'm just after a kernel that I can boot at the moment so virtual/kernel is enough for now ;-) The 2.6.? kernel for my BSP that I build under Poky-4 runs, but I've not managed to get 3.0 or 3.2 to work from Poky-7 (for my BSP). So I thought I would go for a 'known good' kernel and modify it for my needs. However, I've not managed to get the 'known good' start point yet ;-) Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] 1.1.2 Full Pass consolidated Test Report
Comment on 1.1.2 - I'm seeing the following issue on a CentOS 5.8 box - do you do any QA tests on such a distribution? | DEBUG: Staging files from /home/mattsm/git/poky/build-edison-old/tmp/work/ppc603e-poky-linux/eglibc-locale-2.13-r16/pkgdata to /home/mattsm/git/poky/build-edison-old/tmp/pkgdata/ppc603e-poky-linux | DEBUG: Staging files from /home/mattsm/git/poky/build-edison-old/tmp/work/ppc603e-poky-linux/eglibc-locale-2.13-r16/pkgdata to /home/mattsm/git/poky/build-edison-old/tmp/pkgdata/ppc603e-poky-linux | DEBUG: Staging files from /home/mattsm/git/poky/build-edison-old/tmp/work/ppc603e-poky-linux/eglibc-locale-2.13-r16/shlibs to /home/mattsm/git/poky/build-edison-old/tmp/sysroots/mpc8315e-rdb/shlibs | DEBUG: Preparing tree /home/mattsm/git/poky/build-edison-old/tmp/work/ppc603e-poky-linux/eglibc-locale-2.13-r16/pkgdata for packaging at /home/mattsm/git/poky/build-edison-old/tmp/work/ppc603e-poky-linux/eglibc-locale-2.13-r16/sstate-build-package/pkgdata | DEBUG: Preparing tree /home/mattsm/git/poky/build-edison-old/tmp/work/ppc603e-poky-linux/eglibc-locale-2.13-r16/shlibs for packaging at /home/mattsm/git/poky/build-edison-old/tmp/work/ppc603e-poky-linux/eglibc-locale-2.13-r16/sstate-build-package/shlibs | /home/mattsm/git/poky/build-edison-old/tmp/work/ppc603e-poky-linux/eglibc-locale-2.13-r16/temp/run.sstate_create_package.16637: line 83: 7735 Segmentation fault rm -rf /home/mattsm/git/poky/build-edison-old/tmp/work/ppc603e-poky-linux/eglibc-locale-2.13-r16/sstate-build-package/ | ERROR: Function 'sstate_create_package' failed (see /home/mattsm/git/poky/build-edison-old/tmp/work/ppc603e-poky-linux/eglibc-locale-2.13-r16/temp/log.do_package.16637 for further information) NOTE: package eglibc-locale-2.13-r16: task do_package: Failed ERROR: Task 9 (/home/mattsm/git/poky/meta/recipes-core/eglibc/eglibc-locale_2.13.bb, do_package) failed with exit code '1' ERROR: '/home/mattsm/git/poky/meta/recipes-core/eglibc/eglibc-locale_2.13.bb' failed On Fri, Jul 13, 2012 at 3:52 PM, Serban, Laurentiu wrote: > > Hello, > > Here are the results for the full pass testing on 1.1.2 release. > > > > Issues: > > Crownbay image was copied to the wrong folder which we didn’t find and had no > response from anybody, so all cases on crownbay are blocked. LTP on sugarbay > is still running. > > FRI2 sato image was not created so FRI2 tests were blocked. > > > > Summary: > > There were 5 open bugs, three of them were for core build system , they are > lib64 sato image build failed due to non-existent tasks, core-image-sato ipk > build failed due to dependency of lib32-ofono and mklibs-native failed to > compile fedora17 64bit. one issue for ADT, qemu launch failed due to not > finding GLIBC_2.14, reported as bug 2748 and another is Ioatdma error found > in dmesg log on Jasperforest. All these 5 bugs are also in Yocto 1.2 test > cycle. For build performance, one qemux86 sato build on a Core i7 machine > takes 115 minutes. > > For non-intel platforms there is a new bug found for build image with PAM > support, reported as bug 2743. This issue has been fixed in master branch but > the patches aren't merged into edison. > > > > Commit information > > > > Tree/Branch: poky/edison > > Poky Commit: 8886aee5b9741c05886994967d9ecf420331c600 > > > > > > > > Critical bugs, more than 50% test cases are blocked > > > > Only Normal, Minor or Enhancement bugs, or less than 10% test cases failed > > > > Normal, Major and Critical bugs, and more than 10% test cases failed > > > > > > Test Result Summary > > Component > > Target > > Status > > Comments > > BSP > > Beagleboard > > GOOD > > Everything runs well > > Routerstationpro > > GOOD > > Everything runs well > > Mpc8315e-rdb > > GOOD > > Everything runs well > > eMenlow > > GOOD > > Vnc server issue (2700) > > Blacksand > > GOOD > > syslog is not started by default in background on bsps > > Crownbay-emgd > > BLOCK > > No image > > Sugarbay > > GOOD > > Everything runs well > > FRI2-sato-sdk > > BLOCK > > No image > > HuronRiver-sato-sdk > > GOOD > > Everything runs well > > Jasperforest-lsb > > GOOD > > Bug 2742 – system dmesg log check issue > > QEMU > > qemuarm > > GOOD > > Everything runs well > > qemuppc > > GOOD > > Everything runs well > > qemumips > > GOOD > > Everything runs well > > qemux86 > > BUGGY > > Zypper issue (2694) > > qemux86-64 > > BUGGY > > Zypper issue (2694) > > Core build system > > > > BUGGY > > Build image with PAM support failed. > > Multilib issues (2744, 2747), mklibs compile failure (2746) > > HOB > > > > GOOD > > Everything runs well > > Compliance > > GOOD > > LTP result: https://wiki.pokylinux.org/wiki/LTP_result > POSIX result: https://wiki.pokylinux.org/wiki/Posix_result > > Stress > > GOOD > > Everything runs well > > Distribution Support > > GOOD > > beecrypt-native failed to compile on Fedora17(final) 64bit > > ADT > > > > BUGGY > > 2748 (qemu launch failure) > > > > > > Detaile
Re: [yocto] [meta-baryon][PATCH] webmin: fix dash incompatibility in do_configure
On Monday 16 July 2012 11:08:48 Kevin Strasser wrote:
> The use of brackets was causing dash to skip over the removal of
> several unwanted files. The presence of these files was causing an
> exception during packaging.
>
> Signed-off-by: Kevin Strasser
> ---
> recipes-extended/webmin/webmin_1.570.bb |7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/recipes-extended/webmin/webmin_1.570.bb
> b/recipes-extended/webmin/webmin_1.570.bb index 150d920..63a1ed2 100644
> --- a/recipes-extended/webmin/webmin_1.570.bb
> +++ b/recipes-extended/webmin/webmin_1.570.bb
> @@ -33,9 +33,10 @@ inherit allarch perlnative update-rc.d
> do_configure() {
> # Remove binaries and plugins for other platforms
> rm -rf acl/Authen-SolarisRBAC-0.1*
> -rm -rf
> {format,{bsd,hpux,sgi}exports,zones,rbac,smf,ipfw,ipfilter,dfsadmin} -
> rm -f mount/{free,net,open}bsd-mounts*
> -rm -f mount/macos-mounts*
> +rm -rf format bsdexports hpuxexports sgiexports
> +rm -rf zones rbac smf ipfw ipfilter dfsadmin
> +rm -f mount/freebsd-mounts* mount/netbsd-mounts*
> +rm -f mount/openbsd-mounts* mount/macos-mounts*
>
> # Remove some plugins for the moment
> rm -rf lilo frox wuftpd telnet pserver cpan shorewall webalizer
> cfengine fsdump pap
Merged to meta-baryon master, thanks.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-baryon][PATCH 1/2] ffmpegthumbnailer: enable jpeg support
On Friday 13 July 2012 16:19:01 Kevin Strasser wrote:
> Signed-off-by: Kevin Strasser
> ---
> .../ffmpeg/ffmpegthumbnailer_2.0.7.bb |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/recipes-multimedia/ffmpeg/ffmpegthumbnailer_2.0.7.bb
> b/recipes-multimedia/ffmpeg/ffmpegthumbnailer_2.0.7.bb index
> ec6d625..92e484c 100644
> --- a/recipes-multimedia/ffmpeg/ffmpegthumbnailer_2.0.7.bb
> +++ b/recipes-multimedia/ffmpeg/ffmpegthumbnailer_2.0.7.bb
> @@ -6,11 +6,11 @@ LICENSE = "GPLv2"
> LIC_FILES_CHKSUM = "file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
> SRC_URI =
> "http://ffmpegthumbnailer.googlecode.com/files/${PN}-${PV}.tar.gz";
>
> -DEPENDS = "ffmpeg libpng"
> +DEPENDS = "ffmpeg jpeg libpng"
>
> SRC_URI[md5sum] = "2b5726894792ef484793dce9568a065a"
> SRC_URI[sha256sum] =
> "a71155339d17201a13fc3ebb649b0d00c7ab2d5a8880da071c8157a69c6f612b"
>
> -PR = "r0"
> +PR = "r1"
>
> inherit autotools
Merged these two to meta-baryon master, thanks.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] denzil firewall problems
Hi all, I'm trying to take Denzil out for a spin, and when I do bitbake, from inside Sony (behind our corporate firewall) I get this: (I was doing 'bitbake poky-image-sato') - ... ERROR: OE-core's config sanity checker detected a potential misconfiguration. Either fix the cause of this error or at your own risk disable the checker (see sanity.conf). Following is the list of potential problems / advisories: Failed to fetch test data from the network. Please ensure your network is configured correctly. ERROR: Execution of event handler 'check_sanity_eventhandler' failed - I tried to follow the instructions at: https://wiki.yoctoproject.org/wiki/Working_Behind_a_Network_Proxy but nothing worked. These look like instructions for SOCKS proxies. I only have access to HTTP proxies. Here's what I got from 'bitbake -DDD -v poky-image-sato', after configuring an 'nc'-based git-proxy: - DEBUG: Fetcher accessed the network with the command git ls-remote git://git.yoctoproject.org/yocto-firewall-test HEAD DEBUG: Running export HOME="/a/home/tbird"; export SSH_AGENT_PID="1822"; export SSH_AUTH_SOCK="/tmp/keyring-9qrJm0/ssh"; export no_proxy="localhost,127.0.0.0/8"; export ftp_proxy="http://www-west.sony.com:80";; export http_proxy="http://www-west.sony.com:80";; export GIT_CONFIG="/a/home/tbird/work/yocto/poky-7.0-build/tmp/sysroots/x86_64-linux/etc/gitconfig"; export GIT_PROXY_COMMAND="/usr/local/bin/git-proxy"; export PATH="/a/home/tbird/work/yocto/poky-denzil-7.0/bitbake/bin/:/a/home/tbird/bin:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/a/home/tbird/bin/:/a/home/tbird/work/yocto/poky-denzil-7.0/scripts"; git ls-remote git://git.yoctoproject.org/yocto-firewall-test HEAD ERROR: OE-core's config sanity checker detected a potential misconfiguration. Either fix the cause of this error or at your own risk disable the checker (see sanity.conf). Following is the list of potential problems / advisories: Failed to fetch test data from the network. Please ensure your network is configured correctly. ERROR: Execution of event handler 'check_sanity_eventhandler' failed -- I seem to recall in previous Yocto versions a mechanism to point the package fetcher to a mirror. Is this still available? If so, where would I find instructions for this? Alternatively, I have a builder image for denzil. Is there a way to use the material in that image as a source mirror snapshot? Any help would be appreciated. Thanks, -- Tim P.S. With regards to disabling the checker (as a possible workaround for the problem), I found sanity.conf at poky-denzil-7.0/meta/conf/sanity.conf. I looked at it (and meta/classes/sanity.bbclass) but it's not obvious to me how I would disable it. = Tim Bird Architecture Group Chair, CE Workgroup of the Linux Foundation Senior Staff Engineer, Sony Network Entertainment = ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] denzil firewall problems
On Mon, Jul 16, 2012 at 6:57 PM, Tim Bird wrote: > Hi all, > > I'm trying to take Denzil out for a spin, and when I do bitbake, from inside > Sony (behind our corporate firewall) I get this: > > (I was doing 'bitbake poky-image-sato') > - > ... > ERROR: OE-core's config sanity checker detected a potential misconfiguration. > Either fix the cause of this error or at your own risk disable the > checker (see sanity.conf). > Following is the list of potential problems / advisories: > > Failed to fetch test data from the network. Please ensure your network is > configured correctly. > > ERROR: Execution of event handler 'check_sanity_eventhandler' failed > - > > I tried to follow the instructions at: > https://wiki.yoctoproject.org/wiki/Working_Behind_a_Network_Proxy > but nothing worked. These look like instructions for SOCKS proxies. > I only have access to HTTP proxies. > > Here's what I got from 'bitbake -DDD -v poky-image-sato', after configuring > an 'nc'-based git-proxy: > - > DEBUG: Fetcher accessed the network with the command git ls-remote > git://git.yoctoproject.org/yocto-firewall-test HEAD > DEBUG: Running export HOME="/a/home/tbird"; export SSH_AGENT_PID="1822"; > export SSH_AUTH_SOCK="/tmp/keyring-9qrJm0/ssh"; export > no_proxy="localhost,127.0.0.0/8"; export > ftp_proxy="http://www-west.sony.com:80";; export > http_proxy="http://www-west.sony.com:80";; export > GIT_CONFIG="/a/home/tbird/work/yocto/poky-7.0-build/tmp/sysroots/x86_64-linux/etc/gitconfig"; > export > GIT_PROXY_COMMAND="/usr/local/bin/git-proxy"; export > PATH="/a/home/tbird/work/yocto/poky-denzil-7.0/bitbake/bin/:/a/home/tbird/bin:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/a/home/tbird/bin/:/a/home/tbird/work/yocto/poky-denzil-7.0/scripts"; > git ls-remote git://git.yoctoproject.org/yocto-firewall-test HEAD Tim, Can you run that command outside of the yocto build and it works OK? Did you set GIT_PROXY_COMMAND in your local.conf? I recall that git-proxy script on the wiki page not working all that well. (I've gone through all the same problems with our proxy as well). There is a connect-proxy utility available on most distros, and then I've been using this script: $ cat ../scripts/git-proxy #!/bin/sh if [[ "$@" =~ "$GIT_PROXY_IGNORE" ]] then nc $@ else /usr/bin/connect-proxy -S wwwgate0.freescale.net:1090 $@ fi Not 100% sure how it evolved to this point though. -M > ERROR: OE-core's config sanity checker detected a potential misconfiguration. > Either fix the cause of this error or at your own risk disable the > checker (see sanity.conf). > Following is the list of potential problems / advisories: > > Failed to fetch test data from the network. Please ensure your network is > configured correctly. > > ERROR: Execution of event handler 'check_sanity_eventhandler' failed > -- > > I seem to recall in previous Yocto versions a mechanism to point the > package fetcher to a mirror. Is this still available? If so, where would > I find instructions for this? > > Alternatively, I have a builder image for denzil. Is there a way to use the > material in that image as a source mirror snapshot? > > Any help would be appreciated. > > Thanks, > -- Tim > > P.S. With regards to disabling the checker (as a possible workaround for > the problem), I found sanity.conf at poky-denzil-7.0/meta/conf/sanity.conf. > I looked at it (and meta/classes/sanity.bbclass) but it's not obvious > to me how I would disable it. > > = > Tim Bird > Architecture Group Chair, CE Workgroup of the Linux Foundation > Senior Staff Engineer, Sony Network Entertainment > = > > > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] 1.1.2 Full Pass consolidated Test Report
On Mon, Jul 16, 2012 at 5:10 PM, Matthew McClintock wrote:
> Comment on 1.1.2 - I'm seeing the following issue on a CentOS 5.8 box
> - do you do any QA tests on such a distribution?
>
> | DEBUG: Staging files from
> /home/mattsm/git/poky/build-edison-old/tmp/work/ppc603e-poky-linux/eglibc-locale-2.13-r16/pkgdata
> to /home/mattsm/git/poky/build-edison-old/tmp/pkgdata/ppc603e-poky-linux
> | DEBUG: Staging files from
> /home/mattsm/git/poky/build-edison-old/tmp/work/ppc603e-poky-linux/eglibc-locale-2.13-r16/pkgdata
> to /home/mattsm/git/poky/build-edison-old/tmp/pkgdata/ppc603e-poky-linux
> | DEBUG: Staging files from
> /home/mattsm/git/poky/build-edison-old/tmp/work/ppc603e-poky-linux/eglibc-locale-2.13-r16/shlibs
> to /home/mattsm/git/poky/build-edison-old/tmp/sysroots/mpc8315e-rdb/shlibs
> | DEBUG: Preparing tree
> /home/mattsm/git/poky/build-edison-old/tmp/work/ppc603e-poky-linux/eglibc-locale-2.13-r16/pkgdata
> for packaging at
> /home/mattsm/git/poky/build-edison-old/tmp/work/ppc603e-poky-linux/eglibc-locale-2.13-r16/sstate-build-package/pkgdata
> | DEBUG: Preparing tree
> /home/mattsm/git/poky/build-edison-old/tmp/work/ppc603e-poky-linux/eglibc-locale-2.13-r16/shlibs
> for packaging at
> /home/mattsm/git/poky/build-edison-old/tmp/work/ppc603e-poky-linux/eglibc-locale-2.13-r16/sstate-build-package/shlibs
> |
> /home/mattsm/git/poky/build-edison-old/tmp/work/ppc603e-poky-linux/eglibc-locale-2.13-r16/temp/run.sstate_create_package.16637:
> line 83: 7735 Segmentation fault rm -rf
> /home/mattsm/git/poky/build-edison-old/tmp/work/ppc603e-poky-linux/eglibc-locale-2.13-r16/sstate-build-package/
> | ERROR: Function 'sstate_create_package' failed (see
> /home/mattsm/git/poky/build-edison-old/tmp/work/ppc603e-poky-linux/eglibc-locale-2.13-r16/temp/log.do_package.16637
> for further information)
> NOTE: package eglibc-locale-2.13-r16: task do_package: Failed
> ERROR: Task 9
> (/home/mattsm/git/poky/meta/recipes-core/eglibc/eglibc-locale_2.13.bb,
> do_package) failed with exit code '1'
> ERROR: '/home/mattsm/git/poky/meta/recipes-core/eglibc/eglibc-locale_2.13.bb'
> failed
Some more follow up... the following seems to "hide" my issue. Does
anyone have any ideas?
diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index d2a45c3..9a739d1 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -463,7 +463,7 @@ sstate_create_package () {
mv $TFILE ${SSTATE_PKG}
cd ${WORKDIR}
- rm -rf ${SSTATE_BUILDDIR}
+ strace rm -rf ${SSTATE_BUILDDIR}
}
#
-M
>
> On Fri, Jul 13, 2012 at 3:52 PM, Serban, Laurentiu
> wrote:
>>
>> Hello,
>>
>> Here are the results for the full pass testing on 1.1.2 release.
>>
>>
>>
>> Issues:
>>
>> Crownbay image was copied to the wrong folder which we didn’t find and had
>> no response from anybody, so all cases on crownbay are blocked. LTP on
>> sugarbay is still running.
>>
>> FRI2 sato image was not created so FRI2 tests were blocked.
>>
>>
>>
>> Summary:
>>
>> There were 5 open bugs, three of them were for core build system , they are
>> lib64 sato image build failed due to non-existent tasks, core-image-sato ipk
>> build failed due to dependency of lib32-ofono and mklibs-native failed to
>> compile fedora17 64bit. one issue for ADT, qemu launch failed due to not
>> finding GLIBC_2.14, reported as bug 2748 and another is Ioatdma error found
>> in dmesg log on Jasperforest. All these 5 bugs are also in Yocto 1.2 test
>> cycle. For build performance, one qemux86 sato build on a Core i7 machine
>> takes 115 minutes.
>>
>> For non-intel platforms there is a new bug found for build image with PAM
>> support, reported as bug 2743. This issue has been fixed in master branch
>> but the patches aren't merged into edison.
>>
>>
>>
>> Commit information
>>
>>
>>
>> Tree/Branch: poky/edison
>>
>> Poky Commit: 8886aee5b9741c05886994967d9ecf420331c600
>>
>>
>>
>>
>>
>>
>>
>> Critical bugs, more than 50% test cases are blocked
>>
>>
>>
>> Only Normal, Minor or Enhancement bugs, or less than 10% test cases failed
>>
>>
>>
>> Normal, Major and Critical bugs, and more than 10% test cases failed
>>
>>
>>
>>
>>
>> Test Result Summary
>>
>> Component
>>
>> Target
>>
>> Status
>>
>> Comments
>>
>> BSP
>>
>> Beagleboard
>>
>> GOOD
>>
>> Everything runs well
>>
>> Routerstationpro
>>
>> GOOD
>>
>> Everything runs well
>>
>> Mpc8315e-rdb
>>
>> GOOD
>>
>> Everything runs well
>>
>> eMenlow
>>
>> GOOD
>>
>> Vnc server issue (2700)
>>
>> Blacksand
>>
>> GOOD
>>
>> syslog is not started by default in background on bsps
>>
>> Crownbay-emgd
>>
>> BLOCK
>>
>> No image
>>
>> Sugarbay
>>
>> GOOD
>>
>> Everything runs well
>>
>> FRI2-sato-sdk
>>
>> BLOCK
>>
>> No image
>>
>> HuronRiver-sato-sdk
>>
>> GOOD
>>
>> Everything runs well
>>
>> Jasperforest-lsb
>>
>> GOOD
>>
>> Bug 2742 – system dmesg log check issue
>>
>> QEMU
>>
>> qemuarm
>>
>> GOOD
>>
>> Everything runs well
>>
>> qemup
Re: [yocto] 1.1.2 Full Pass consolidated Test Report
On Mon, Jul 16, 2012 at 10:31 PM, McClintock Matthew-B29882
wrote:
> }
> - rm -rf ${SSTATE_BUILDDIR}
> + strace rm -rf ${SSTATE_BUILDDIR}
strace is probably eating the return value
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
