Re: [yocto] configure optimization feature update
Op 20 jun 2011, om 06:53 heeft Esben Haabendal het volgende geschreven:
> On Sun, 2011-06-19 at 16:49 -0700, Khem Raj wrote:
>> On Sun, Jun 19, 2011 at 1:02 PM, Esben Haabendal
>> wrote:
>>> On Wed, 2011-06-15 at 18:28 -0700, Khem Raj wrote:
On Wed, Jun 15, 2011 at 5:57 PM, Xu, Dongxiao
wrote:
> Hi Richard,
>
> Recently I was doing the "configure optimization" feature and collecting
> data for it.
>
> The main logic of this feature is straight forward:
>
> 1. Use the diff file as autoreconf cache. (I use command: "diff -ruN
> SOURCE-ORIG SOURCE", here "SOURCE-ORIG" is the source directory before
> running autoreconf, while "SOURCE" is the directory after running
> autoreconf).
> 2. Add SRC_URI checksum for all patches of the source code.
> 3. Tag each autoreconf cache file with ${PN} and the SRC_URI checksum of
> source code and all patches.
> 4. If the currently SRC_URI checksum matches the cached checksum, then we
> can patch the cache instead of running "autoreconf" stage.
>
The autoconf'ing is sort of arbitrary at the moment. Depending on what
is staged the results may vary.
>>>
>>> Which can be properly fixed by using per-recipe (per-workdir) staging.
>>>
>>
>> you seem to be stuck in this tight while(1) loop
>> per recipe staging is not panacea
>
> Well, panacea is a very strong work. But per recipe staging does
> improve build reproducability and reliability quite a bit. As for what
> it is not, I think you might want to try it before speaking to strongly
> against it.
>
>> Do you have some prototypes ?
>
> Yes. OE-lite: http://oe-lite.org
>
> And it works so well, that I cannot understand why OE do not have a plan
> for how to achieve the same.
So why not send a patch to make OE-core have per recipe staging?
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] configure optimization feature update
Koen Kooi writes: >> Yes. OE-lite: http://oe-lite.org >> >> And it works so well, that I cannot understand why OE do not have a plan >> for how to achieve the same. > > So why not send a patch to make OE-core have per recipe staging? Several good/bad reasons: 1. Communications so far has been rather clear that OE does not want this kind of change, at least not at this point in time. 2. Implementing per recipe staging in OE-core, without dropping vital features of OE (most prominently package feeds) requires additional work that I do not have the manpower to do, nor any particular motivation given that chances of acceptance seems so low. So for now, all I can do is to raise attention to the benefits of doing per recipe staging sometime in the future, hoping to inspire some people to be willing to help get there. Given the current community/project situation around OE, an undertaking like this does not seem feasible within OE without YP behind it. /Esben ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] the yocto under archlinux
2011/6/20 NiQingliang : > Hello, > > Is there someone using archlinux? > Under archlinux, the "env python" is pointing to python3, which result > in the bitbake's failure. > > What I can do? > > I want use "env python=python2", but it doesn't work. I'm OpenEmbedded user but this case is similar. OE wiki have solution on "OE and your distro" page, but seems OE website is inaccessible now. I'm just using lxc container with Debian 6.0 inside. This is more stable solution :) -- Yury Bushmelev ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PULL][linux-yocto] beagleboard: sync with meta-ti linux-omap_2.6.37
On 06/18/11 12:32, Koen Kooi wrote: Op 18 jun 2011, om 18:09 heeft Bruce Ashfield het volgende geschreven: On 11-06-18 11:13 AM, Koen Kooi wrote: Op 18 jun 2011, om 17:10 heeft Koen Kooi het volgende geschreven: Op 18 jun 2011, om 17:08 heeft Darren Hart het volgende geschreven: On 06/18/2011 01:11 AM, Koen Kooi wrote: Op 18 jun 2011, om 01:18 heeft Darren Hart het volgende geschreven: From: Darren Hart The following commits have been pulled in from the meta-ti linux-omap_2.6.37 recipe, with the exception of: USB: ehci: remove structure packing from ehci_def which hails from mainline and should be applied to yocto/base, while the rest should be applied to yocto/standard/beagleboard. Fixes [YOCTO #764] Fixes [YOCTO #765] Fixes [YOCTO #767] This brings linux-yocto in sync with the meta-ti linux-omap_2.6.37 recipe and significantly improves Beagleboard support in linux-yocto. As there are 115 patches in total, and none of them are new, I have omitted them from the email. You seem to be including the patches that patch the kernel from 37rc7 (or rc8, I forget) to .37 final, which shouldn't apply. So basically leave out the patches in the 'linus' directory. There were about 200 patches in total, I've removed all those that reverse applied and failed do to a conflict that was obviously a merge of a very similar patch. That accounted for most of the 37-rc[78] to 37 patches from the linus directory. The camera interface also doesn't work, so the 'media' directory can be left out as well. The goal was to stay as close to the meta-ti/linux-omap_2.6.37 recipe as possible with the linux-yocto kernel repository. Will you be removing all of the media directory from there as well? I don't want to remove them from here if you'll be *adding* to them there. However, if you'll be sure to just be replacing them there, then I can drop them here. The .37 isn't used, developed or supported for beagleboard anymore, .39 is all the rage now :) Speaking of .39, is there a 'linux-yocto' type of tree for .39 mainline with a skeleton for machine support? If there is, I'd like to fork it to see if it can improve my current workflow which consist of self written scripts that emulate guilt. I've got the linux-yocto-dev recipe in poky-extras, meta-kernel-dev layer. That recipe tracked 2.6.39, and has now jumped to 3.0 (with a minor cheat as I work through the 3.0 naming issues). The kernel repo is hosted on git.yoctoproject.org as the linux-yocto-dev repo. The repo is fast forward for a given version, and then is re-generated when I jump it from version to version. I carry forward all the existing patches and keep the qemu machines working. Although at the moment, qemuppc is losing interrupts and can't get past init :) That's also the repo where I'm testing out some changes to kern-tools (but they are stable), which will show up shortly. Thanks, I'll have a look at that. Is there already some doc out on how to create such a structure from scratch? At the moment, they are carried forward from kernel version to kernel version and then interpreted by the tools. But I do have some notes and other information that describe how to take upstream tree , feed it a kernel-cache (what you see in the meta branch) and create a new kernel tree ready to build. I've got to get a bit of 3.0-rcX behind me, but I'm writing this up and will contribute it, if that's what you are thinking of here. Cheers, Bruce ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PULL][linux-yocto] beagleboard: sync with meta-ti linux-omap_2.6.37
Op 20 jun 2011, om 21:46 heeft Bruce Ashfield het volgende geschreven: > On 06/18/11 12:32, Koen Kooi wrote: >> >> Op 18 jun 2011, om 18:09 heeft Bruce Ashfield het volgende geschreven: >> >>> On 11-06-18 11:13 AM, Koen Kooi wrote: Op 18 jun 2011, om 17:10 heeft Koen Kooi het volgende geschreven: > > Op 18 jun 2011, om 17:08 heeft Darren Hart het volgende geschreven: > >> >> >> On 06/18/2011 01:11 AM, Koen Kooi wrote: >>> >>> Op 18 jun 2011, om 01:18 heeft Darren Hart het volgende geschreven: >>> From: Darren Hart The following commits have been pulled in from the meta-ti linux-omap_2.6.37 recipe, with the exception of: USB: ehci: remove structure packing from ehci_def which hails from mainline and should be applied to yocto/base, while the rest should be applied to yocto/standard/beagleboard. Fixes [YOCTO #764] Fixes [YOCTO #765] Fixes [YOCTO #767] This brings linux-yocto in sync with the meta-ti linux-omap_2.6.37 recipe and significantly improves Beagleboard support in linux-yocto. As there are 115 patches in total, and none of them are new, I have omitted them from the email. >>> >>> >>> You seem to be including the patches that patch the kernel from >>> 37rc7 (or rc8, I forget) to .37 final, which shouldn't apply. So >>> basically leave out the patches in the 'linus' directory. >> >> There were about 200 patches in total, I've removed all those that >> reverse applied and failed do to a conflict that was obviously a merge >> of a very similar patch. That accounted for most of the 37-rc[78] to 37 >> patches from the linus directory. >> >>> The camera >>> interface also doesn't work, so the 'media' directory can be left out >>> as well. >> >> The goal was to stay as close to the meta-ti/linux-omap_2.6.37 recipe as >> possible with the linux-yocto kernel repository. Will you be removing >> all of the media directory from there as well? I don't want to remove >> them from here if you'll be *adding* to them there. However, if you'll >> be sure to just be replacing them there, then I can drop them here. > > The .37 isn't used, developed or supported for beagleboard anymore, .39 > is all the rage now :) Speaking of .39, is there a 'linux-yocto' type of tree for .39 mainline with a skeleton for machine support? If there is, I'd like to fork it to see if it can improve my current workflow which consist of self written scripts that emulate guilt. >>> >>> I've got the linux-yocto-dev recipe in poky-extras, meta-kernel-dev >>> layer. That recipe tracked 2.6.39, and has now jumped to 3.0 (with >>> a minor cheat as I work through the 3.0 naming issues). The kernel >>> repo is hosted on git.yoctoproject.org as the linux-yocto-dev repo. >>> >>> The repo is fast forward for a given version, and then is re-generated >>> when I jump it from version to version. I carry forward all the existing >>> patches and keep the qemu machines working. Although at the moment, >>> qemuppc is losing interrupts and can't get past init :) >>> >>> That's also the repo where I'm testing out some changes to kern-tools >>> (but they are stable), which will show up shortly. >> >> Thanks, I'll have a look at that. Is there already some doc out on how to >> create such a structure from scratch? > > At the moment, they are carried forward from kernel version > to kernel version and then interpreted by the tools. But I > do have some notes and other information that describe how to > take upstream tree , feed it a kernel-cache (what you see > in the meta branch) and create a new kernel tree ready to > build. > > I've got to get a bit of 3.0-rcX behind me, but I'm writing this > up and will contribute it, if that's what you are thinking > of here. That's exactly what I'm thinking of! ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 2/3] beagleboard: xserver-kdrive xorg.conf installation
On 06/18/2011 08:09 AM, Koen Kooi wrote:
>
> Op 18 jun 2011, om 17:02 heeft Darren Hart het volgende geschreven:
>
>>
>>
>> On 06/18/2011 01:05 AM, Koen Kooi wrote:
>>>
>>> Op 18 jun 2011, om 02:35 heeft Darren Hart het volgende
>>> geschreven:
>>>
Append xserver-kdrive to allow for BSP specific xorg.conf
files. This also appears to drag in a runtime dependency on
libhal, so add that to the bbappend's RDEPENDS_${PN} as well.
>>>
>>> Since when does kdrive use xorg.conf?
>>
>> This is my first use of xserver-kdrive. I was experimenting with
>> xorg.conf changes to resolve some USB input issues I was having...
>> it seemed to work. Should it be using something else?
>
> AFAIK kdrive doesn't read xorg.conf, one of its design principles :)
> That's we have all those x*-common scripts that start Xfbdev with a
> gazillion commandline options.
Taking a closer look, I'm wondering if it is the xkeyboard-config
package that is reading xorg.conf. Installing this seems a bit at odds
with what I've been able to dig up about xserver-kdrive. I also noticed
the beagleboard.conf in meta-ti use xserver-xorg, not kdrive.
With that information, I'm building a new image using the XSERVER
preferences from the meta-ti beagleboard conf.
Any objections to moving beagleboard to xserver-xorg instead of kdrive?
I'd like us not to diverge from meta-ti without a very good reason.
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
