* Re: [oe-core 1/4] qt4-embedded: remove dependency on tslib and use std. linux input
From: Simon Busch @ 2011-10-12 19:24 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <E575A7CF-9F72-418C-8143-9BA2701599BC@dominion.thruhere.net>
On 12.10.2011 21:09, Koen Kooi wrote:
>> What is breaking qt:e in this case? For me it's just a feature reduction
>> and not a break (as qt:e still works fine with the linux input interface).
>
> When your TS is suddenly uncalibrated and jittery, it's a breakage, not a feature reduction.
You're talking here about one case where tslib is needed to get a
working touchscreen. But there are even cases where tslib is not needed
to get a working touchscreen.
qt:e does not strongly depends on tslib, it can work without. So if you
need it you should add it to your machine layer as it is really machine
specific if you need tslib or not.
regards,
Simon
--
Simon Busch - http://mm.gravedo.de/blog/
^ permalink raw reply
* Re: [RFC PATCH 0/1] QA check for defined packages
From: Joshua Lock @ 2011-10-12 19:23 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1318447114.23801.178.camel@ted>
On 10/12/2011 12:18 PM, Richard Purdie wrote:
>>> Obviously, you can skip to b) if you already have a package feed.
>>
>> a), right? Indeed I expect that this will be more in line with certain
>> proposed use cases.
>
> No, you'd skip the package feed generation and just end up using it so
> skip a) and start from b).
My bad, I read that as skip b), not skip to b). Apologies.
>>> So we'd be talking about two UI's that could effectively hand off to
>>> each other and share a "build in progress" feedback to the user system.
>>> The image construction dialog would have a "Missing Packages? Build them
>>> here" type switch. This would mean the build system can continue on at
>>> what it does best yet the UI can let the users do what they want to do,
>>> particularly on a prebuilt package feed.
>>
>> I like it. I think we had to "write one to throw away" to realise quite
>> how much data we're missing up front but I support the proposed design.
>
> I'd not say thrown away. We've moved a lot of the code forward and
> significant pieces would get reused...
Quite right, I meant the spirit of the quote. I've tried where possible
to create re-usable components for hob. The crumbs module of the bb ui
is chock full these days and there were various changes to core BitBake
that will hopefully be useful outside of hob.
Cheers,
Joshua
--
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre
^ permalink raw reply
* Re: [oe-core 1/4] qt4-embedded: remove dependency on tslib and use std. linux input
From: Eric Bénard @ 2011-10-12 19:22 UTC (permalink / raw)
To: Simon Busch
Cc: Koen Kooi, Martin Jansa,
Patches and discussions about the oe-core layer
In-Reply-To: <4E95D811.7090105@gravedo.de>
Hi,
Le 12/10/2011 20:10, Simon Busch a écrit :
> On 12.10.2011 10:02, Eric Bénard wrote:
>> Le 12/10/2011 09:45, Martin Jansa a écrit :
>>> From: Simon Busch<morphis@gravedo.de>
>>>
>>> In most cases we don't need tslib in std. configuration as touchscreen
>>> access in most
>>> devices today is done with linux input interface. If some specific
>>> machine has a need for
>>> tslib support it should add the dependency in it's machine layer again
>>> and modify the
>>> profile script accordingly.
>>>
>> When using a resistive touchscreen, tslib is a common solution to handle
>> calibration and raw value processing : do you think this is a good thing
>> to remove this ?
>
> Thats up to the environment you are using qt4-embedded in. In my case
> the setup is a little bit more complicated. We're using tslib but not
> directly in qt4-embedded (we can get rid of tslib completely but time is
> missing).
>
> I removed the dependency from qt4-embedded as qt4-embedded in oe-core
> should be the general thing used in all environments and therefore
> should be only a minimal setup with minimal dependencies.
>
> If someone needs tslib for qt4-embedded for his machine layer he should
> include tslib support in the machine layer itself.
>
removing tslib plugin in qt4e seems not the good solution as this plugin can
be built but not installed by default.
In my opinion that's only the qte.sh script which could be more generic and
maybe could be in its own configuration package so that several machines can
share the same qt4e packages (picking the plugins they need) and have their
own qte-config (for example) package.
Else, why don't you akso remove plugin-gfx-transformed which is not used be
many machines, or plugin-gfx-vnc or plugin-gfx-directfb which is only used on
machine needing directfb or plugin-gfx-qvfb as real machine don't need a
virtual framebuffer or even qt-mouse-pc as you may think that pc with mouses
don't need qtembedded ... in the end we may also notice that basic platforms
can use qt without a display, so why not removing graphic support at all to
make the think even more generic and reduce the number of dependencies ;-)
Eric
^ permalink raw reply
* Re: [RFC PATCH 0/1] QA check for defined packages
From: Richard Purdie @ 2011-10-12 19:18 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <4E95D1C1.2020000@linux.intel.com>
On Wed, 2011-10-12 at 10:43 -0700, Joshua Lock wrote:
> On 10/12/2011 05:37 AM, Richard Purdie wrote:
> > On Tue, 2011-10-11 at 15:29 -0700, Joshua Lock wrote:
> >> I'm looking for some comments on this WIP patch.
> >>
> >> The reason I've added this is because the hob GUI requires us to offer much
> >> more reliable metadata - we show the user available packages, as defined by
> >> each recipe, to add to their image. Should a recipe define a package and yet
> >> not actually create it and the user has included that in their image we cause
> >> errors at build time.
> >>
> >> However whilst the idea seems sound enough, there are some caveats - running
> >> a world build with this patch I see failures fairly early on at least a few
> >> of which I'd expect we'll need to special-case:
> >> * eglibc-local
> >> * linux-yocto
> >> * linux-libc-headers
> >> * gcc-runtime
> >>
> >> Thoughts?
> >
> > I think we probably do need to cleanup some of that data.
> >
> > I have some thoughts about where we're at with hob and this is probably
> > as good a time as any to share them.
> >
> > Effectively the problem is that there is a large body of data we only
> > compute during the build process. This includes what the exact runtime
> > dependencies of packages are, which packages exactly are generated
> > (PACKAGES_DYNAMIC), what the size of the packages are, how long they
> > take to build and so on. Some things we can fix, some things we can hack
> > around but at the end of the day there are some things we just plain
> > can't change.
> >
> > I'm beginning to think we need to have two phases of control of the
> > system:
> >
> > a) The build phase
> >
> > This is the step that generates the package feeds.
> >
> > b) The image construction phase
> >
> > This is the step that takes the package feed data and turns it into an
> > image.
>
> I actually think this is a neat idea, in fact we have the beginnings of
> a Gtk+ GUI to create images from a package feed which Rob Bradford
> worked on some 3 years or so ago - puccho. It's no doubt bit-rotten but
> may be worth a look.
>
> I think we can reuse pieces from puccho and hob to create a GUI per this
> high-level design and I think we'd be much better off for it.
>
> > Obviously, you can skip to b) if you already have a package feed.
>
> a), right? Indeed I expect that this will be more in line with certain
> proposed use cases.
No, you'd skip the package feed generation and just end up using it so
skip a) and start from b).
> > So we'd be talking about two UI's that could effectively hand off to
> > each other and share a "build in progress" feedback to the user system.
> > The image construction dialog would have a "Missing Packages? Build them
> > here" type switch. This would mean the build system can continue on at
> > what it does best yet the UI can let the users do what they want to do,
> > particularly on a prebuilt package feed.
>
> I like it. I think we had to "write one to throw away" to realise quite
> how much data we're missing up front but I support the proposed design.
I'd not say thrown away. We've moved a lot of the code forward and
significant pieces would get reused...
Cheers,
Richard
^ permalink raw reply
* Re: [oe-core 1/4] qt4-embedded: remove dependency on tslib and use std. linux input
From: Koen Kooi @ 2011-10-12 19:09 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <4E95DDD0.7020302@gravedo.de>
Op 12 okt. 2011, om 20:34 heeft Simon Busch het volgende geschreven:
> On 12.10.2011 20:14, Koen Kooi wrote:
>>
>>
>> Op 12 okt. 2011 om 20:10 heeft Simon Busch <morphis@gravedo.de> het volgende geschreven:
>>
>>> On 12.10.2011 10:02, Eric Bénard wrote:
>>>> Hi,
>>>>
>>>> Le 12/10/2011 09:45, Martin Jansa a écrit :
>>>>> From: Simon Busch<morphis@gravedo.de>
>>>>>
>>>>> In most cases we don't need tslib in std. configuration as touchscreen
>>>>> access in most
>>>>> devices today is done with linux input interface. If some specific
>>>>> machine has a need for
>>>>> tslib support it should add the dependency in it's machine layer again
>>>>> and modify the
>>>>> profile script accordingly.
>>>>>
>>>> When using a resistive touchscreen, tslib is a common solution to handle
>>>> calibration and raw value processing : do you think this is a good thing
>>>> to remove this ?
>>>
>>> Thats up to the environment you are using qt4-embedded in. In my case
>>> the setup is a little bit more complicated. We're using tslib but not
>>> directly in qt4-embedded (we can get rid of tslib completely but time is
>>> missing).
>>>
>>> I removed the dependency from qt4-embedded as qt4-embedded in oe-core
>>> should be the general thing used in all environments and therefore
>>> should be only a minimal setup with minimal dependencies.
>>
>> No, it should work in most cases, breaking qt:e like is not acceptable.
>
> What is breaking qt:e in this case? For me it's just a feature reduction
> and not a break (as qt:e still works fine with the linux input interface).
When your TS is suddenly uncalibrated and jittery, it's a breakage, not a feature reduction.
^ permalink raw reply
* Re: [PATCH] Import python-setuptools from meta-oe (for glib-2.0)
From: Khem Raj @ 2011-10-12 19:06 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1318426596.23801.160.camel@ted>
On 10/12/2011 6:36 AM, Richard Purdie wrote:
> +DEPENDS += "python"
> +DEPENDS_virtclass-native += "python-native"
> +
wouldnt BBCLASSEXTEND convert python into python-native ?
^ permalink raw reply
* Re: [oe-core 1/4] qt4-embedded: remove dependency on tslib and use std. linux input
From: Chris Larson @ 2011-10-12 19:04 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Martin Jansa
In-Reply-To: <E9665FD1-F0CD-4ADB-941C-68FC58674D08@dominion.thruhere.net>
On Wed, Oct 12, 2011 at 2:20 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> Op 12 okt. 2011, om 10:02 heeft Eric Bénard het volgende geschreven:
>
>> Hi,
>>
>> Le 12/10/2011 09:45, Martin Jansa a écrit :
>>> From: Simon Busch<morphis@gravedo.de>
>>>
>>> In most cases we don't need tslib in std. configuration as touchscreen access in most
>>> devices today is done with linux input interface. If some specific machine has a need for
>>> tslib support it should add the dependency in it's machine layer again and modify the
>>> profile script accordingly.
>>>
>> When using a resistive touchscreen, tslib is a common solution to handle calibration and raw value processing : do you think this is a good thing to remove this ?
>
> We ran into this at work and like Eric, I'm curious how calibration (and e.g. dejitter) works in the linux-input world combined with qt/e.
Not directly applicable, but I keep meaning to take a look at
http://atrey.karlin.mff.cuni.cz/~metan/evfilter/ - it seems quite
interesting.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
^ permalink raw reply
* Re: [oe-core 1/4] qt4-embedded: remove dependency on tslib and use std. linux input
From: Simon Busch @ 2011-10-12 18:34 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1E1E70C9-6B15-497F-8571-78D2EF0CD081@dominion.thruhere.net>
On 12.10.2011 20:14, Koen Kooi wrote:
>
>
> Op 12 okt. 2011 om 20:10 heeft Simon Busch <morphis@gravedo.de> het volgende geschreven:
>
>> On 12.10.2011 10:02, Eric Bénard wrote:
>>> Hi,
>>>
>>> Le 12/10/2011 09:45, Martin Jansa a écrit :
>>>> From: Simon Busch<morphis@gravedo.de>
>>>>
>>>> In most cases we don't need tslib in std. configuration as touchscreen
>>>> access in most
>>>> devices today is done with linux input interface. If some specific
>>>> machine has a need for
>>>> tslib support it should add the dependency in it's machine layer again
>>>> and modify the
>>>> profile script accordingly.
>>>>
>>> When using a resistive touchscreen, tslib is a common solution to handle
>>> calibration and raw value processing : do you think this is a good thing
>>> to remove this ?
>>
>> Thats up to the environment you are using qt4-embedded in. In my case
>> the setup is a little bit more complicated. We're using tslib but not
>> directly in qt4-embedded (we can get rid of tslib completely but time is
>> missing).
>>
>> I removed the dependency from qt4-embedded as qt4-embedded in oe-core
>> should be the general thing used in all environments and therefore
>> should be only a minimal setup with minimal dependencies.
>
> No, it should work in most cases, breaking qt:e like is not acceptable.
What is breaking qt:e in this case? For me it's just a feature reduction
and not a break (as qt:e still works fine with the linux input interface).
--
Simon Busch - http://mm.gravedo.de/blog/
^ permalink raw reply
* Re: [oe-core 1/4] qt4-embedded: remove dependency on tslib and use std. linux input
From: Koen Kooi @ 2011-10-12 18:14 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Cc: Martin Jansa, Patches and discussions about the oe-core layer
In-Reply-To: <4E95D811.7090105@gravedo.de>
Op 12 okt. 2011 om 20:10 heeft Simon Busch <morphis@gravedo.de> het volgende geschreven:
> On 12.10.2011 10:02, Eric Bénard wrote:
>> Hi,
>>
>> Le 12/10/2011 09:45, Martin Jansa a écrit :
>>> From: Simon Busch<morphis@gravedo.de>
>>>
>>> In most cases we don't need tslib in std. configuration as touchscreen
>>> access in most
>>> devices today is done with linux input interface. If some specific
>>> machine has a need for
>>> tslib support it should add the dependency in it's machine layer again
>>> and modify the
>>> profile script accordingly.
>>>
>> When using a resistive touchscreen, tslib is a common solution to handle
>> calibration and raw value processing : do you think this is a good thing
>> to remove this ?
>
> Thats up to the environment you are using qt4-embedded in. In my case
> the setup is a little bit more complicated. We're using tslib but not
> directly in qt4-embedded (we can get rid of tslib completely but time is
> missing).
>
> I removed the dependency from qt4-embedded as qt4-embedded in oe-core
> should be the general thing used in all environments and therefore
> should be only a minimal setup with minimal dependencies.
No, it should work in most cases, breaking qt:e like is not acceptable.
>
> If someone needs tslib for qt4-embedded for his machine layer he should
> include tslib support in the machine layer itself.
>
> regards,
> Simon
>
> --
> Simon Busch - http://mm.gravedo.de/blog/
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply
* Re: [oe-core 1/4] qt4-embedded: remove dependency on tslib and use std. linux input
From: Simon Busch @ 2011-10-12 18:10 UTC (permalink / raw)
To: Eric Bénard
Cc: Martin Jansa, Patches and discussions about the oe-core layer
In-Reply-To: <4E954984.7020202@eukrea.com>
On 12.10.2011 10:02, Eric Bénard wrote:
> Hi,
>
> Le 12/10/2011 09:45, Martin Jansa a écrit :
>> From: Simon Busch<morphis@gravedo.de>
>>
>> In most cases we don't need tslib in std. configuration as touchscreen
>> access in most
>> devices today is done with linux input interface. If some specific
>> machine has a need for
>> tslib support it should add the dependency in it's machine layer again
>> and modify the
>> profile script accordingly.
>>
> When using a resistive touchscreen, tslib is a common solution to handle
> calibration and raw value processing : do you think this is a good thing
> to remove this ?
Thats up to the environment you are using qt4-embedded in. In my case
the setup is a little bit more complicated. We're using tslib but not
directly in qt4-embedded (we can get rid of tslib completely but time is
missing).
I removed the dependency from qt4-embedded as qt4-embedded in oe-core
should be the general thing used in all environments and therefore
should be only a minimal setup with minimal dependencies.
If someone needs tslib for qt4-embedded for his machine layer he should
include tslib support in the machine layer itself.
regards,
Simon
--
Simon Busch - http://mm.gravedo.de/blog/
^ permalink raw reply
* Re: [oe-core 2/4] qt4-x11-free: bring back pkg-config fixups
From: Simon Busch @ 2011-10-12 18:05 UTC (permalink / raw)
To: Paul Eggleton
Cc: Martin Jansa, Patches and discussions about the oe-core layer
In-Reply-To: <201110121023.52795.paul.eggleton@linux.intel.com>
On 12.10.2011 11:23, Paul Eggleton wrote:
> On Wednesday 12 October 2011 08:45:03 Martin Jansa wrote:
>> From: Simon Busch <morphis@gravedo.de>
>>
>> With b40b9c024be5e1ec81a31961158b3e6b529acfe0 some pkg-config fixups where
>> removed from qt4.inc which breaks the pkg-config files for qt4-embedded.
>> Without that the pkg-config files for qt4-x11-free are broken. So this
>> patch puts the fixes into the qt4-x11-free.inc file to be used by
>> qt4-x11-free and not qt4-embedded.
>
> So why do we need these only in the X11 version? Surely they should be
> applicable to both embedded and X11, or not at all...?
With b40b9c024be5e1ec81a31961158b3e6b529acfe0 I removed this fixups from
qt4.inc as I had problems with building agains qt4-embedded as cflags
were incorrect in the created pkg-config files.
Now I switched my application to x11 and got other problems with the
pkg-config files from qt4-x11-free which can be resolved with the fixups
I removed before.
So you are right we need them for qt4-x11-free but not for qt4-embedded.
I didn't investigated from where these differences are coming.
regards,
Simon
--
Simon Busch - http://mm.gravedo.de/blog/
^ permalink raw reply
* Re: [RFC PATCH 0/1] QA check for defined packages
From: Joshua Lock @ 2011-10-12 17:44 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1318423185.23801.153.camel@ted>
On 10/12/2011 05:39 AM, Richard Purdie wrote:
> On Tue, 2011-10-11 at 15:29 -0700, Joshua Lock wrote:
>> Folks,
>>
>> I'm looking for some comments on this WIP patch.
>>
>> The reason I've added this is because the hob GUI requires us to offer much
>> more reliable metadata - we show the user available packages, as defined by
>> each recipe, to add to their image. Should a recipe define a package and yet
>> not actually create it and the user has included that in their image we cause
>> errors at build time.
>>
>> However whilst the idea seems sound enough, there are some caveats - running
>> a world build with this patch I see failures fairly early on at least a few
>> of which I'd expect we'll need to special-case:
>> * eglibc-local
>> * linux-yocto
>> * linux-libc-headers
>> * gcc-runtime
>
> You'd probably get much better results from this patch if you account
> for ALLOW_EMPTY_<pkgname> btw...
Indeed, that does look useful.
So, ignoring the Hob discussion I still think this QA check will be
generally useful. Are others open to this if I work on it further?
Regards,
Joshua
--
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre
^ permalink raw reply
* Re: [RFC PATCH 0/1] QA check for defined packages
From: Joshua Lock @ 2011-10-12 17:43 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1318423059.23801.151.camel@ted>
On 10/12/2011 05:37 AM, Richard Purdie wrote:
> On Tue, 2011-10-11 at 15:29 -0700, Joshua Lock wrote:
>> I'm looking for some comments on this WIP patch.
>>
>> The reason I've added this is because the hob GUI requires us to offer much
>> more reliable metadata - we show the user available packages, as defined by
>> each recipe, to add to their image. Should a recipe define a package and yet
>> not actually create it and the user has included that in their image we cause
>> errors at build time.
>>
>> However whilst the idea seems sound enough, there are some caveats - running
>> a world build with this patch I see failures fairly early on at least a few
>> of which I'd expect we'll need to special-case:
>> * eglibc-local
>> * linux-yocto
>> * linux-libc-headers
>> * gcc-runtime
>>
>> Thoughts?
>
> I think we probably do need to cleanup some of that data.
>
> I have some thoughts about where we're at with hob and this is probably
> as good a time as any to share them.
>
> Effectively the problem is that there is a large body of data we only
> compute during the build process. This includes what the exact runtime
> dependencies of packages are, which packages exactly are generated
> (PACKAGES_DYNAMIC), what the size of the packages are, how long they
> take to build and so on. Some things we can fix, some things we can hack
> around but at the end of the day there are some things we just plain
> can't change.
>
> I'm beginning to think we need to have two phases of control of the
> system:
>
> a) The build phase
>
> This is the step that generates the package feeds.
>
> b) The image construction phase
>
> This is the step that takes the package feed data and turns it into an
> image.
I actually think this is a neat idea, in fact we have the beginnings of
a Gtk+ GUI to create images from a package feed which Rob Bradford
worked on some 3 years or so ago - puccho. It's no doubt bit-rotten but
may be worth a look.
I think we can reuse pieces from puccho and hob to create a GUI per this
high-level design and I think we'd be much better off for it.
> Obviously, you can skip to b) if you already have a package feed.
a), right? Indeed I expect that this will be more in line with certain
proposed use cases.
> So we'd be talking about two UI's that could effectively hand off to
> each other and share a "build in progress" feedback to the user system.
> The image construction dialog would have a "Missing Packages? Build them
> here" type switch. This would mean the build system can continue on at
> what it does best yet the UI can let the users do what they want to do,
> particularly on a prebuilt package feed.
I like it. I think we had to "write one to throw away" to realise quite
how much data we're missing up front but I support the proposed design.
Regards,
Joshua
--
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre
^ permalink raw reply
* Re: [oe] git server move
From: Khem Raj @ 2011-10-12 17:13 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Cc: Koen Kooi, openembedded-devel
In-Reply-To: <201110121648.29478.paul.eggleton@linux.intel.com>
On Wed, Oct 12, 2011 at 8:48 AM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> On Wednesday 12 October 2011 16:18:37 Koen Kooi wrote:
>> Op 12 okt. 2011, om 17:16 heeft Khem Raj het volgende geschreven:
>> > On Wed, Oct 12, 2011 at 1:17 AM, Koen Kooi <koen@dominion.thruhere.net>
> wrote:
>> >> -----BEGIN PGP SIGNED MESSAGE-----
>> >> Hash: SHA1
>> >>
>> >> Op 11-10-11 21:11, Cliff Brake schreef:
>> >>> Hi, we are moving git.openembedded.org to a new server.
>> >>>
>> >>> SSH access on the old server has been disabled. git:// still works
>> >>> there.
>> >>>
>> >>> As soon as DNS propagates, SSH access will work with the new server.
>> >>>
>> >>> Let me know if you see any problems.
>> >>
>> >> When will cgit be back up?
>> >
>> > It should be up already. Do Ctrl+f5 in your browser on
>> > git.openembedded.org
>>
>> Let me rephrase: when will it be working again? I still get "No
>> repositories found" when clicking on a repo.
>
> I think you may find it's the "/cgit.cgi" part of the URL that's causing
> problems. It used to work, now it doesn't - if you remove it then you get a
> working interface.
>
> FWIW I'd be in favour of fixing it however; all of the links to cgit on my
> layer index page are now broken for example.
Yes, however the new webserver is running on nginx so coming up with
correct set of
rules to reproduce old urls is a bit of challange. Right now the mails
to openembedded-commit
ml are probably not going and the url mentioned in those emails dont
resolve as well
but eventually they will
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
^ permalink raw reply
* [PATCH] bitbake.conf: Exclude MACHINE from MACHINE_OVERRIDES variable dependency list
From: Koen Kooi @ 2011-10-12 16:18 UTC (permalink / raw)
To: openembedded-core; +Cc: Koen Kooi
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
---
meta/conf/bitbake.conf | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 11d76b8..8cf7a60 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -670,6 +670,7 @@ OVERRIDES = "${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVE
DISTROOVERRIDES ?= "${DISTRO}"
MACHINEOVERRIDES ?= "${MACHINE}"
OVERRIDES[vardepsexclude] = "MACHINE"
+MACHINEOVERRIDES[vardepsexclude] = "MACHINE"
CPU_FEATURES ?= ""
CPU_FEATURES_arm ?= "vfp"
--
1.6.6.1
^ permalink raw reply related
* Re: [oe] git server move
From: Paul Eggleton @ 2011-10-12 15:48 UTC (permalink / raw)
To: openembedded-devel
Cc: Koen Kooi, Patches and discussions about the oe-core layer
In-Reply-To: <6C40DE44-FE7C-4C0A-AB7F-1B78CE95216F@dominion.thruhere.net>
On Wednesday 12 October 2011 16:18:37 Koen Kooi wrote:
> Op 12 okt. 2011, om 17:16 heeft Khem Raj het volgende geschreven:
> > On Wed, Oct 12, 2011 at 1:17 AM, Koen Kooi <koen@dominion.thruhere.net>
wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Op 11-10-11 21:11, Cliff Brake schreef:
> >>> Hi, we are moving git.openembedded.org to a new server.
> >>>
> >>> SSH access on the old server has been disabled. git:// still works
> >>> there.
> >>>
> >>> As soon as DNS propagates, SSH access will work with the new server.
> >>>
> >>> Let me know if you see any problems.
> >>
> >> When will cgit be back up?
> >
> > It should be up already. Do Ctrl+f5 in your browser on
> > git.openembedded.org
>
> Let me rephrase: when will it be working again? I still get "No
> repositories found" when clicking on a repo.
I think you may find it's the "/cgit.cgi" part of the URL that's causing
problems. It used to work, now it doesn't - if you remove it then you get a
working interface.
FWIW I'd be in favour of fixing it however; all of the links to cgit on my
layer index page are now broken for example.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply
* Re: [oe] git server move
From: Chris Larson @ 2011-10-12 15:25 UTC (permalink / raw)
To: openembedded-devel; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <CAMKF1srW_j_H1EKJvs9LMOcFeXauLbK5_9W7jcr2RjTtN5OeQQ@mail.gmail.com>
On Wed, Oct 12, 2011 at 8:22 AM, Khem Raj <raj.khem@gmail.com> wrote:
> On Wed, Oct 12, 2011 at 8:18 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>>
>> Op 12 okt. 2011, om 17:16 heeft Khem Raj het volgende geschreven:
>>
>>> On Wed, Oct 12, 2011 at 1:17 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Op 11-10-11 21:11, Cliff Brake schreef:
>>>>> Hi, we are moving git.openembedded.org to a new server.
>>>>>
>>>>> SSH access on the old server has been disabled. git:// still works
>>>>> there.
>>>>>
>>>>> As soon as DNS propagates, SSH access will work with the new server.
>>>>>
>>>>> Let me know if you see any problems.
>>>>
>>>> When will cgit be back up?
>>>
>>> It should be up already. Do Ctrl+f5 in your browser on git.openembedded.org
>>
>> Let me rephrase: when will it be working again? I still get "No repositories found" when clicking on a repo.
>
> Weird I see all the repos fine.
Works here too.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
^ permalink raw reply
* Re: [oe] git server move
From: Koen Kooi @ 2011-10-12 15:29 UTC (permalink / raw)
To: openembedded-core; +Cc: openembedded-devel
In-Reply-To: <CAMKF1srW_j_H1EKJvs9LMOcFeXauLbK5_9W7jcr2RjTtN5OeQQ@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Op 12-10-11 17:22, Khem Raj schreef:
> On Wed, Oct 12, 2011 at 8:18 AM, Koen Kooi <koen@dominion.thruhere.net>
> wrote:
>>
>> Op 12 okt. 2011, om 17:16 heeft Khem Raj het volgende geschreven:
>>
>>> On Wed, Oct 12, 2011 at 1:17 AM, Koen Kooi
>>> <koen@dominion.thruhere.net> wrote:
> Op 11-10-11 21:11, Cliff Brake schreef:
>>>>>> Hi, we are moving git.openembedded.org to a new server.
>>>>>>
>>>>>> SSH access on the old server has been disabled. git:// still
>>>>>> works there.
>>>>>>
>>>>>> As soon as DNS propagates, SSH access will work with the new
>>>>>> server.
>>>>>>
>>>>>> Let me know if you see any problems.
>
> When will cgit be back up?
>>>>
>>>> It should be up already. Do Ctrl+f5 in your browser on
>>>> git.openembedded.org
>>>
>>> Let me rephrase: when will it be working again? I still get "No
>>> repositories found" when clicking on a repo.
>
>> Weird I see all the repos fine.
Old: http://cgit.openembedded.org/cgit.cgi/openembedded-core/log/?h=master-next
New: http://cgit.openembedded.org/openembedded-core/log/?h=master-next
So the URLs changed :(
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: GPGTools - http://gpgtools.org
iD8DBQFOlbJUMkyGM64RGpERAu24AKClgYvg645M1A7QDsFwqqI2nitZvgCfYUJe
xCOhSnarP1PELO3WyrhOSQg=
=6oZd
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [oe] git server move
From: Eric Bénard @ 2011-10-12 15:28 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <CAMKF1srW_j_H1EKJvs9LMOcFeXauLbK5_9W7jcr2RjTtN5OeQQ@mail.gmail.com>
Le 12/10/2011 17:22, Khem Raj a écrit :
> On Wed, Oct 12, 2011 at 8:18 AM, Koen Kooi<koen@dominion.thruhere.net> wrote:
>> Op 12 okt. 2011, om 17:16 heeft Khem Raj het volgende geschreven:
>>> On Wed, Oct 12, 2011 at 1:17 AM, Koen Kooi<koen@dominion.thruhere.net> wrote:
>>>> When will cgit be back up?
>>>
>>> It should be up already. Do Ctrl+f5 in your browser on git.openembedded.org
>>
>> Let me rephrase: when will it be working again? I still get "No repositories found" when clicking on a repo.
>
> Weird I see all the repos fine.
also works fine here on http://cgit.openembedded.org/
Eric
^ permalink raw reply
* Re: [oe] git server move
From: Khem Raj @ 2011-10-12 15:22 UTC (permalink / raw)
To: openembedded-devel; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <6C40DE44-FE7C-4C0A-AB7F-1B78CE95216F@dominion.thruhere.net>
On Wed, Oct 12, 2011 at 8:18 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>
> Op 12 okt. 2011, om 17:16 heeft Khem Raj het volgende geschreven:
>
>> On Wed, Oct 12, 2011 at 1:17 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Op 11-10-11 21:11, Cliff Brake schreef:
>>>> Hi, we are moving git.openembedded.org to a new server.
>>>>
>>>> SSH access on the old server has been disabled. git:// still works
>>>> there.
>>>>
>>>> As soon as DNS propagates, SSH access will work with the new server.
>>>>
>>>> Let me know if you see any problems.
>>>
>>> When will cgit be back up?
>>
>> It should be up already. Do Ctrl+f5 in your browser on git.openembedded.org
>
> Let me rephrase: when will it be working again? I still get "No repositories found" when clicking on a repo.
Weird I see all the repos fine.
>
>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.5 (Darwin)
>>> Comment: GPGTools - http://gpgtools.org
>>>
>>> iD8DBQFOlU0rMkyGM64RGpERArroAJ9EuHaOEcv64o9q9kJLZk50/OLoSQCgmKjd
>>> Yxh2H5CGKREmOq32gr36aes=
>>> =Xubc
>>> -----END PGP SIGNATURE-----
>>>
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
^ permalink raw reply
* Re: git server move
From: Koen Kooi @ 2011-10-12 15:18 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: openembedded-devel
In-Reply-To: <CAMKF1srHT5uh5a=z=mt0kOpF2YO9YyKkEdkRK9ZT8=LaGY6JSA@mail.gmail.com>
Op 12 okt. 2011, om 17:16 heeft Khem Raj het volgende geschreven:
> On Wed, Oct 12, 2011 at 1:17 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Op 11-10-11 21:11, Cliff Brake schreef:
>>> Hi, we are moving git.openembedded.org to a new server.
>>>
>>> SSH access on the old server has been disabled. git:// still works
>>> there.
>>>
>>> As soon as DNS propagates, SSH access will work with the new server.
>>>
>>> Let me know if you see any problems.
>>
>> When will cgit be back up?
>
> It should be up already. Do Ctrl+f5 in your browser on git.openembedded.org
Let me rephrase: when will it be working again? I still get "No repositories found" when clicking on a repo.
>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.5 (Darwin)
>> Comment: GPGTools - http://gpgtools.org
>>
>> iD8DBQFOlU0rMkyGM64RGpERArroAJ9EuHaOEcv64o9q9kJLZk50/OLoSQCgmKjd
>> Yxh2H5CGKREmOq32gr36aes=
>> =Xubc
>> -----END PGP SIGNATURE-----
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply
* Re: git server move
From: Khem Raj @ 2011-10-12 15:16 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: openembedded-devel
In-Reply-To: <j73ifb$3kl$1@dough.gmane.org>
On Wed, Oct 12, 2011 at 1:17 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Op 11-10-11 21:11, Cliff Brake schreef:
>> Hi, we are moving git.openembedded.org to a new server.
>>
>> SSH access on the old server has been disabled. git:// still works
>> there.
>>
>> As soon as DNS propagates, SSH access will work with the new server.
>>
>> Let me know if you see any problems.
>
> When will cgit be back up?
It should be up already. Do Ctrl+f5 in your browser on git.openembedded.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
> Comment: GPGTools - http://gpgtools.org
>
> iD8DBQFOlU0rMkyGM64RGpERArroAJ9EuHaOEcv64o9q9kJLZk50/OLoSQCgmKjd
> Yxh2H5CGKREmOq32gr36aes=
> =Xubc
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
^ permalink raw reply
* Re: Some further build dependency timings
From: Richard Purdie @ 2011-10-12 14:49 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <4E95A6E5.6090402@windriver.com>
On Wed, 2011-10-12 at 09:40 -0500, Mark Hatle wrote:
> > --- a/bitbake/lib/bb/runqueue.py
> > +++ b/bitbake/lib/bb/runqueue.py
> > @@ -1096,6 +1096,10 @@ class RunQueueExecute:
> >
> > logger.debug(2, 'Running %s:%s under fakeroot, fakedirs: %s' %
> > (fn, taskname, ', '.join(fakedirs)))
> > + else:
> > + envbackup["PSEUDO_RELOADED"] = os.environ.get("PSEUDO_RELOADED")
> > + os.environ["PSEUDO_RELOADED"] = "yes"
> > + fakeenv["PSEUDO_RELOADED"] = "yes"
>
> PSEUDO_RELOADED was intended to only be used internally by pseudo. Specifically
> to signify to fork/exec that we're about to run the pseudo server process and to
> remove PSEUDO from the LD_PRELOAD on the next fork/exec.
Right, I realised I was abusing it here, its good for a performance
measurement though ;-)
> The system simply checks the environment on the fork-exec and doesn't check the
> value on pseudo-load. This is why it works.
>
> That side effect means that any subsequent calls can NOT re-enable pseudo as
> it's no longer in memory at all.
>
> So what you are seeing at best is the time difference from avoiding the
> LD_PRELOAD and the jump table setup. (Even when pseudo is disabled, we need to
> enable the jump table, we just pass the call to the original function.)
>
> But more then likely because pseudo is no longer memory resident for the called
> processes and it's sub-processes.. there is likely some place in the system that
> uses pseudo functionality that is no longer functioning properly.
I'm not sure that there is in our use cases. If we need pseudo
functionality the tasks are marked as "fakeroot" with a flag. If that
flag is not set (which is when the above code triggers), its perfectly
fine to have pseudo unload at the next exec.
> It would be interesting to determine first off, if there is anywhere pseudo
> should be running that it currently isn't. And second if this is simply due to
> LD_PRELOAD time, or if enabling the jump table is the culprit.
>
> One potential optimization, when PSEUDO_DISABLE=1 is to only setup the jump
> table entries for fork/exec items.
Agreed, I don't know where the time is being spent exactly at this
point. I do know we execute an absolute ton of exec/fork calls so
removing any overhead from them will improve our speed though. This
change means do_configure won't run with pseudo enabled for example
which is a very exec heavy task.
> Also if it is desired to unload pseudo, I'd suggest we add a new environment
> variable to pseudo that is specific about unloading pseudo, instead of using the
> existing PSEUDO_RELOADED. Not only is the name confusing, but since it's an
> internal item it's behavior may change or go away in the future.
>
> (Below is from the pseudo man page:
>
> PSEUDO_RELOADED
> This purely internal variable is used to track state while try-
> ing to re-execute to get rid of the LD_PRELOAD value when
> spawning a server. (The pseudo server itself cannot function
> running in the pseudo environment.)
> )
I suspect we may need a dedicated option for this...
Cheers,
Richard
^ permalink raw reply
* Re: [oe] git server move
From: Cliff Brake @ 2011-10-12 14:44 UTC (permalink / raw)
To: openembedded-devel; +Cc: openembedded-core
In-Reply-To: <1318361177.3726.1.camel@mattotaupa>
On Tue, Oct 11, 2011 at 3:26 PM, Paul Menzel
<paulepanter@users.sourceforge.net> wrote:
> is there more information about the reasons? Is it just a new machine?
> Where is it hosted now?
Certainly. It is still hosted at OSUOSL. We had some problems with
the original VM (Melo), so git has been running on a temporary VM
(Garnet, our build instance). Now that we have a replacement for Melo
(Opal), we are moving to this machine.
> So what are the fingerprints of the new keys? ;-)
1024 ad:8e:65:4e:dc:4c:d9:63:8f:67:b3:87:03:c9:a1:73 ssh_host_dsa_key.pub (DSA)
2048 ed:99:0d:c1:6e:6c:02:75:df:36:25:4d:62:39:b7:e5 ssh_host_rsa_key.pub (RSA)
Let me know if you have any more questions.
Thanks,
Cliff
--
=================
http://bec-systems.com
^ permalink raw reply
* Re: Some further build dependency timings
From: Mark Hatle @ 2011-10-12 14:40 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1318332940.23801.90.camel@ted>
On 10/11/11 6:35 AM, Richard Purdie wrote:
> On Mon, 2011-10-10 at 21:45 +0100, Richard Purdie wrote:
>> Just for reference, with a base configuration, sato image:
>>
>> real 50m8.223s
>> user 298m41.450s
>> sys 52m42.200s
>>
>> adding:
>>
>> ASSUME_PROVIDED =+ "bison-native flex-native sqlite3-native git-native"
>>
>> (and hacking the pseudo recipe to use a sqlite3-native):
>>
>> real 42m6.740s
>> user 296m21.940s
>> sys 52m25.220s
>>
>> We continue to have real dependency issues around gettext in both the
>> native and target builds...
>
> So to continue the story, adding:
>
> DEBUG_FLAGS = ""
> INHERIT_INSANE = ""
> PACKAGE_CLASSES = "package_ipk"
> USER_CLASSES = ""
>
> Results in:
>
> real 38m23.053s
> user 237m7.430s
> sys 39m3.720s
>
> Then adding PSEUDO_RELOADED=yes to the environment of tasks not needing
> pseudo (hack patch below):
>
> real 36m20.683s
> user 236m19.580s
> sys 37m54.450s
>
> Finally, adding:
>
> DISABLESTATIC = "--disable-static"
> DISABLESTATIC_pn-qemu = ""
> DISABLESTATIC_pn-qemu-native = ""
> DISABLESTATIC_pn-openssl = ""
> DISABLESTATIC_pn-openssl-native = ""
> EXTRA_OECONF += "${DISABLESTATIC}"
>
> real 34m53.877s
> user 233m34.780s
> sys 38m50.190s
>
> Cheers,
>
> Richard
>
>
> --- a/bitbake/lib/bb/runqueue.py
> +++ b/bitbake/lib/bb/runqueue.py
> @@ -1096,6 +1096,10 @@ class RunQueueExecute:
>
> logger.debug(2, 'Running %s:%s under fakeroot, fakedirs: %s' %
> (fn, taskname, ', '.join(fakedirs)))
> + else:
> + envbackup["PSEUDO_RELOADED"] = os.environ.get("PSEUDO_RELOADED")
> + os.environ["PSEUDO_RELOADED"] = "yes"
> + fakeenv["PSEUDO_RELOADED"] = "yes"
PSEUDO_RELOADED was intended to only be used internally by pseudo. Specifically
to signify to fork/exec that we're about to run the pseudo server process and to
remove PSEUDO from the LD_PRELOAD on the next fork/exec.
The system simply checks the environment on the fork-exec and doesn't check the
value on pseudo-load. This is why it works.
That side effect means that any subsequent calls can NOT re-enable pseudo as
it's no longer in memory at all.
So what you are seeing at best is the time difference from avoiding the
LD_PRELOAD and the jump table setup. (Even when pseudo is disabled, we need to
enable the jump table, we just pass the call to the original function.)
But more then likely because pseudo is no longer memory resident for the called
processes and it's sub-processes.. there is likely some place in the system that
uses pseudo functionality that is no longer functioning properly.
It would be interesting to determine first off, if there is anywhere pseudo
should be running that it currently isn't. And second if this is simply due to
LD_PRELOAD time, or if enabling the jump table is the culprit.
One potential optimization, when PSEUDO_DISABLE=1 is to only setup the jump
table entries for fork/exec items.
Also if it is desired to unload pseudo, I'd suggest we add a new environment
variable to pseudo that is specific about unloading pseudo, instead of using the
existing PSEUDO_RELOADED. Not only is the name confusing, but since it's an
internal item it's behavior may change or go away in the future.
(Below is from the pseudo man page:
PSEUDO_RELOADED
This purely internal variable is used to track state while try-
ing to re-execute to get rid of the LD_PRELOAD value when
spawning a server. (The pseudo server itself cannot function
running in the pseudo environment.)
)
>
> sys.stdout.flush()
> sys.stderr.flush()
>
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox