Re: [yocto] Reducing nightly/release build artifacts.
Hi Beth, 于 2014年04月01日 02:38, Flanagan, Elizabeth 写道: Otavio So, if I were to not publish the fsl builds, would that be an issue? Please do not remove p1022ds images from fsl-ppc build. I'm using it. Thanks, Yi -b On Fri, Mar 28, 2014 at 6:02 AM, Otavio Salvador wrote: Hello Beth, On Wed, Mar 26, 2014 at 6:22 PM, Otavio Salvador wrote: On Wed, Mar 26, 2014 at 6:14 PM, Flanagan, Elizabeth wrote: I'd like to start looking at reducing the number of artifacts we're releasing both for our nightly builds (which is at 250,000 artifacts and .25 TB!) and releases. I don't use any meta-fsl-arm artifacts as I usually build the images for testing, as does Daiane, however the autobuilder is critical for me as your build does spot and exercise other things which mine does not (plus the MUT) so I highly depend on it. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto 1.6 Project Name "Daisy"
On 31 March 2014 23:03, Flanagan, Elizabeth wrote: > Just so folks know, 1.6 is going to be called "Daisy". > > -b > I think the release name references to one of my favourite (though fiendishly difficult) console games from my childhood is half the reason I've stuck around! Cheers, -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Agenda: Yocto Project Technical Team Meeting - Tuesday, April 1, 2014 8:00 AM US Pacific Time
Agenda: * Opens collection - 5 min (Stephen) * Yocto 1.6 status - 5 min (Stephen/team) https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.6_Status https://wiki.yoctoproject.org/wiki/Yocto_1.6_Features * SWAT team rotation: Cristian -> Cristiana https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team * Opens - 10 min * Team Sharing - 10 min -Original Appointment- We encourage people attending the meeting to logon the Yocto Project 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 Project Technical Team Conference date/start time: Tue Jun 25, 2013 at 11:00 AM Eastern Daylight Time (GMT-0400) Participants: 30 Duration: 30 minutes Participant passcode: 42001078 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.x42001078# 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: 01908 355599 US: 972 995 or 1877 561 6828 Recurring conferences First scheduled conference: Tue Jun 25, 2013 Recurrence frequency: Weekly - Every 1 week(s) on Tuesday Recurrence ends: End after 52 occurrences Thanks, Stephen K. Jolley Yocto Project Program Manager INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 * Work Telephone: (503) 712-0534 *Cell:(208) 244-4460 * Email: stephen.k.jol...@intel.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto 1.6 Project Name "Daisy"
Just so folks know, 1.6 is going to be called "Daisy". -b -- Elizabeth Flanagan Yocto Project Build and Release -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [oe] initial support for musl libc with OE/Yocto Project
On Mon, Mar 31, 2014 at 12:21 PM, Paul Barker wrote: > On 30 March 2014 17:48, Khem Raj wrote: >> On Sun, Mar 30, 2014 at 8:43 AM, Paul Barker wrote: >>> On 30 March 2014 05:17, Khem Raj wrote: On Thu, Mar 27, 2014 at 5:53 AM, Paul Barker wrote: > On 26 March 2014 22:12, Burton, Ross wrote: >> On 26 March 2014 22:04, Khem Raj wrote: >>> There were interest in other threads in having musl as an alternative >>> to eglibc/uclibc that we already have in OE, in that direction I have >>> poured in my on and off work and put it into a contrib tree >> >> Blimey Khem that was quick. :) >> > > Agreed! > > I wonder if it's worth splitting this out into its own layer though I thought about it and since class/conf changes that need to go in into OE-core first I kept it as it is (lazyness too). I think once the core support is available in OE-core we can spin the recipes into a layer of its own. > (with fixes done via bbappends) so that it's easy for multiple people > to contribute to. It would also mean it doesn't need rebasing onto > master all the time. > > I'd definitely like to get involved with this. In particular I can > ensure opkg (both current release and development branch) work with > musl and see if some of my preferred software from meta-oe will build > (vim, htop, etc). start with what we have. Once master opens up I would propose the needed changes to OE-core and spin a layer >>> >>> I did a quick 'bitbake -k core-image-minimal' to see what's currently >>> failing. Full logs and config at >>> http://www.paulbarker.me.uk/musl-build/ >>> >>> Build Configuration: >>> BB_VERSION= "1.21.1" >>> BUILD_SYS = "x86_64-linux" >>> NATIVELSBSTRING = "Ubuntu-12.04" >>> TARGET_SYS= "arm-oe-linux-musleabi" >>> MACHINE = "qemuarm" >>> DISTRO= "nodistro" >>> DISTRO_VERSION= "nodistro.0" >>> TUNE_FEATURES = "armv5 thumb dsp" >>> TARGET_FPU= "soft" >>> meta = "kraj/musl:faafa7022ed057d55c131c456d1bdd5dfa3d2517" >>> >>> Summary: 6 tasks failed: >>> openembedded-core/meta/recipes-support/attr/attr_2.4.47.bb, do_compile >>> openembedded-core/meta/recipes-devtools/python/python_2.7.3.bb, do_compile >>> openembedded-core/meta/recipes-core/util-linux/util-linux_2.24.1.bb, >>> do_compile >>> openembedded-core/meta/recipes-core/sysvinit/sysvinit_2.88dsf.bb, >>> do_compile >>> openembedded-core/meta/recipes-core/busybox/busybox_1.22.1.bb, do_compile >>> openembedded-core/meta/recipes-core/glib-2.0/glib-2.0_2.38.2.bb, >>> do_compile >>> >>> I can see for util-linux that we need to implement qsort_r(). >>> >>> Busybox probably just needs config changes: >>> http://wiki.musl-libc.org/wiki/Building_Busybox >> >> >> I already have local fix for busy box. > > Excellent! I'm currently looking at util-linux. > > I think we should ask for a new repo to be setup on > git.yoctoproject.org for meta-musl. I'm happy to be one of the > maintainers for that, I hope that you are as well and maybe a couple > of the others who were interested could also help. I think having a > few people as maintainers is important as we're all already fairly > busy on other projects. > > Once the layer is setup we can move the recipes off your branch of > oe-core and into the layer as time permits. That would just leave the > changes which need to go into oe-core on your branch. > > Does that sound like a sensible plan? I think it does; this allow for easy sharing of work and do increase its visibility. So I agree with the plan and goal. I will try to help on this as well. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Reducing nightly/release build artifacts.
On Mon, Mar 31, 2014 at 3:38 PM, Flanagan, Elizabeth wrote: > So, if I were to not publish the fsl builds, would that be an issue? For me, it would work. In case I need something I can ask you to add it back in future. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Reducing nightly/release build artifacts.
Otavio So, if I were to not publish the fsl builds, would that be an issue? -b On Fri, Mar 28, 2014 at 6:02 AM, Otavio Salvador wrote: > Hello Beth, > > On Wed, Mar 26, 2014 at 6:22 PM, Otavio Salvador > wrote: >> On Wed, Mar 26, 2014 at 6:14 PM, Flanagan, Elizabeth >> wrote: >>> I'd like to start looking at reducing the number of artifacts we're >>> releasing both for our nightly builds (which is at 250,000 artifacts >>> and .25 TB!) and releases. > > I don't use any meta-fsl-arm artifacts as I usually build the images > for testing, as does Daiane, however the autobuilder is critical for > me as your build does spot and exercise other things which mine does > not (plus the MUT) so I highly depend on it. > > -- > Otavio Salvador O.S. Systems > http://www.ossystems.com.brhttp://code.ossystems.com.br > Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- Elizabeth Flanagan Yocto Project Build and Release -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] USB not automounting, missing /dev/disk directory
All, > -Original Message- > From: yocto-boun...@yoctoproject.org [mailto:yocto- > boun...@yoctoproject.org] On Behalf Of Bryan Evenson > Sent: Monday, March 31, 2014 9:57 AM > To: yocto@yoctoproject.org > Subject: [yocto] USB not automounting, missing /dev/disk directory > > All, > > I am on poky/dylan, and I recently did something to really screw up my local > build and I'm trying to figure out how to recover. I have a custom image > which is core-image-minimal plus a few packages for my needs. For a target > device running my latest built image, the target recognizes USB devices but > does not automount a USB stick. Also, my target device does not have a > /dev/disk directory, which I assume means udev is not doing some things it > should. > > I have a local git repository of all layers which I'm using to tag my local > releases. The most likely candidate for my problem is after my last release, > I > tried building with systemd for init just to see how that works, differences > in > image size, etc. Specifically, I added: > > DISTRO_FEATURES_append = " systemd" > VIRTUAL-RUNTIME_init_manager = "systemd" > DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit" > > to my configuration. After the systemd test build, I deleted these three > lines > from my configuration and rebuilt the image to revert back to sysVinit. > Everything seems to work on my system except USB stick automounting. > The only other core function modification I see since my last release was a > configuration change I'd made to Busbox, which I also have reverted. I did a > bitbake -c cleanall of all the installed packages on my image (at least I > thought > so) and rebuilt the image. Even after the clean rebuild, I still have the > issue > with the USB stick not automounting and no /dev/disk directory on the > filesystem. > > Any ideas on what else needs to be cleaned out or rebuilt? I've been trying > to avoid deleting the entire tmp/ directory, but I will if that looks to be > the > best solution. > I've tracked down what I believe is the problem. systemd builds udev revision 199, but dylan is using udev revision 182. After reverting the configuration for systemd, there was still a package for udev revision 199 in my ipk directory. Since I did not specify which revision of udev to use in my image recipe, udev revision 199 was being installed on my system. I'm doing a full clean of all packages for my image and deleting the ipk/ directory to force a full rebuild of everything. After this incident, I want to make sure there were no more surprises left over. > Thanks, > Bryan Evenson > -- > ___ > 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] [OE-core] [oe] initial support for musl libc with OE/Yocto Project
On 30 March 2014 17:48, Khem Raj wrote: > On Sun, Mar 30, 2014 at 8:43 AM, Paul Barker wrote: >> On 30 March 2014 05:17, Khem Raj wrote: >>> On Thu, Mar 27, 2014 at 5:53 AM, Paul Barker wrote: On 26 March 2014 22:12, Burton, Ross wrote: > On 26 March 2014 22:04, Khem Raj wrote: >> There were interest in other threads in having musl as an alternative >> to eglibc/uclibc that we already have in OE, in that direction I have >> poured in my on and off work and put it into a contrib tree > > Blimey Khem that was quick. :) > Agreed! I wonder if it's worth splitting this out into its own layer though >>> >>> I thought about it and since class/conf changes that need to go in into >>> OE-core >>> first I kept it as it is (lazyness too). I think once the core support >>> is available in OE-core >>> we can spin the recipes into a layer of its own. >>> (with fixes done via bbappends) so that it's easy for multiple people to contribute to. It would also mean it doesn't need rebasing onto master all the time. I'd definitely like to get involved with this. In particular I can ensure opkg (both current release and development branch) work with musl and see if some of my preferred software from meta-oe will build (vim, htop, etc). >>> >>> start with what we have. Once master opens up I would propose the needed >>> changes to OE-core and spin a layer >>> >> >> I did a quick 'bitbake -k core-image-minimal' to see what's currently >> failing. Full logs and config at >> http://www.paulbarker.me.uk/musl-build/ >> >> Build Configuration: >> BB_VERSION= "1.21.1" >> BUILD_SYS = "x86_64-linux" >> NATIVELSBSTRING = "Ubuntu-12.04" >> TARGET_SYS= "arm-oe-linux-musleabi" >> MACHINE = "qemuarm" >> DISTRO= "nodistro" >> DISTRO_VERSION= "nodistro.0" >> TUNE_FEATURES = "armv5 thumb dsp" >> TARGET_FPU= "soft" >> meta = "kraj/musl:faafa7022ed057d55c131c456d1bdd5dfa3d2517" >> >> Summary: 6 tasks failed: >> openembedded-core/meta/recipes-support/attr/attr_2.4.47.bb, do_compile >> openembedded-core/meta/recipes-devtools/python/python_2.7.3.bb, do_compile >> openembedded-core/meta/recipes-core/util-linux/util-linux_2.24.1.bb, >> do_compile >> openembedded-core/meta/recipes-core/sysvinit/sysvinit_2.88dsf.bb, >> do_compile >> openembedded-core/meta/recipes-core/busybox/busybox_1.22.1.bb, do_compile >> openembedded-core/meta/recipes-core/glib-2.0/glib-2.0_2.38.2.bb, do_compile >> >> I can see for util-linux that we need to implement qsort_r(). >> >> Busybox probably just needs config changes: >> http://wiki.musl-libc.org/wiki/Building_Busybox > > > I already have local fix for busy box. Excellent! I'm currently looking at util-linux. I think we should ask for a new repo to be setup on git.yoctoproject.org for meta-musl. I'm happy to be one of the maintainers for that, I hope that you are as well and maybe a couple of the others who were interested could also help. I think having a few people as maintainers is important as we're all already fairly busy on other projects. Once the layer is setup we can move the recipes off your branch of oe-core and into the layer as time permits. That would just leave the changes which need to go into oe-core on your branch. Does that sound like a sensible plan? -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-freescale] Problems concerning qte-in-use-image
Hi everyone, I've build qte-in-use image for imx6qsabrelite and I have some problems running qt embedded applications. Some of the problems are: 1. after the boot completes and login I try to launch the demo application: # qtdemoE -qws my screen goes black and nothing happens. The board hangs, non answer also via serial connection 2. I build and run a simple application, it runs correctly, but when I close the application the board hangs, and I have to reset it. I've read some discussion about qte-in-use-image, but I didn't found a solution... Any help will be appreciated. Thank you, Federico -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] beaglebone: fix typo in the U-Boot config name
From: Denys Dmytriyenko Signed-off-by: Denys Dmytriyenko --- meta-yocto-bsp/conf/machine/beaglebone.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta-yocto-bsp/conf/machine/beaglebone.conf b/meta-yocto-bsp/conf/machine/beaglebone.conf index 1dcf351..8b474a5 100644 --- a/meta-yocto-bsp/conf/machine/beaglebone.conf +++ b/meta-yocto-bsp/conf/machine/beaglebone.conf @@ -30,7 +30,7 @@ KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb" SPL_BINARY = "MLO" UBOOT_SUFFIX = "img" -UBOOT_MACHINE = "am335_evm_config" +UBOOT_MACHINE = "am335x_evm_config" UBOOT_ENTRYPOINT = "0x80008000" UBOOT_LOADADDRESS = "0x80008000" -- 1.9.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] USB not automounting, missing /dev/disk directory
All, I am on poky/dylan, and I recently did something to really screw up my local build and I'm trying to figure out how to recover. I have a custom image which is core-image-minimal plus a few packages for my needs. For a target device running my latest built image, the target recognizes USB devices but does not automount a USB stick. Also, my target device does not have a /dev/disk directory, which I assume means udev is not doing some things it should. I have a local git repository of all layers which I'm using to tag my local releases. The most likely candidate for my problem is after my last release, I tried building with systemd for init just to see how that works, differences in image size, etc. Specifically, I added: DISTRO_FEATURES_append = " systemd" VIRTUAL-RUNTIME_init_manager = "systemd" DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit" to my configuration. After the systemd test build, I deleted these three lines from my configuration and rebuilt the image to revert back to sysVinit. Everything seems to work on my system except USB stick automounting. The only other core function modification I see since my last release was a configuration change I'd made to Busbox, which I also have reverted. I did a bitbake -c cleanall of all the installed packages on my image (at least I thought so) and rebuilt the image. Even after the clean rebuild, I still have the issue with the USB stick not automounting and no /dev/disk directory on the filesystem. Any ideas on what else needs to be cleaned out or rebuilt? I've been trying to avoid deleting the entire tmp/ directory, but I will if that looks to be the best solution. Thanks, Bryan Evenson -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
