On 11/02/12 14:01, Joe MacDonald wrote:
> [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On
> 12.11.02 (Fri 08:00) Martin Ertsås wrote:
>
>> On 11/01/12 18:32, Joe MacDonald wrote:
>>> [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: C
On 11/01/12 18:32, Joe MacDonald wrote:
> [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On
> 12.11.01 (Thu 17:19) Paul Eggleton wrote:
>
>> On Thursday 01 November 2012 17:09:59 Little, Morgan wrote:
>>> My rational behind splitting like that is if it is just ntpdate an
On 11/01/12 02:08, Paul Eggleton wrote:
On Tuesday 23 October 2012 12:20:20 Morgan Little wrote:
-PACKAGES += "ntpdate ${PN}-bin ${PN}-tickadj ${PN}-utils"
...
+PACKAGES += "${PN}-date ${PN}-bin ${PN}-tickadj ${PN}-utils"
I'm not particularly happy with this change. Apart from the fact that i
On 10/31/12 13:11, Phil Blundell wrote:
> On Wed, 2012-10-31 at 12:43 +0100, Martin Ertsås wrote:
>
>> for now I guess we can just use pool.ntp.org
>
> I'm not sure that this is a very good idea. The pool.ntp.org
> documentation is fairly explicit that they don't wa
For this you should also have a look at the ntpdate.service and
ntp.service files. There was a discussion about this earlier:
http://patches.openembedded.org/patch/38575/
Also, what is not on that discussion, is that pool.ntp.org is not really
the way to do it. What we would like is to register so
On 10/26/12 17:07, Burton, Ross wrote:
On 26 October 2012 15:35, Enrico Scholz wrote:
Martin Ertsaas writes:
Type=oneshot
-ExecStart=/usr/bin/ntpd -q -g -x
+ExecStart=/usr/bin/ntpdate pool.ntp.org
This should be made configurable. E.g.
Environment=NTPHOSTS=pool.ntp.org
EnvironmentF
On 10/26/12 10:01, Martin Jansa wrote:
> On Fri, Oct 26, 2012 at 09:14:43AM +0200, Koen Kooi wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Op 25-10-12 20:58, Martin Ertsaas schreef:
>>> Change version of ntp to match that in meta-networking. Also change
>>> ntpdate to ntp-date to
On 10/26/12 09:14, Koen Kooi wrote:
> Op 25-10-12 20:58, Martin Ertsaas schreef:
> > Change version of ntp to match that in meta-networking. Also change
> > ntpdate to ntp-date to match the names used in meta-networking.
>
> While you are there, can you also disable the autoactivating for the unit?
Assuming you use meta-java, it seems like what you are looking for is:
DEPENDS += "openjdk-6-jdk"
as that at least contains the include, lib and bin directory.
- Martin
On 10/10/12 08:40, Jaap de Jong wrote:
>
> On 10/09/2012 07:51 AM, Martin Ertsås wrote:
>> As you are u
On 10/09/12 19:27, Martin Jansa wrote:
> On Tue, Oct 09, 2012 at 02:04:25PM +0200, Martin Ertsaas wrote:
>> According to http://www.intra2net.com/en/developer/libftdi/, libftdi itself
>> is licensed under LGPLv2,
>> with some parts (eeprom programmer) is licensed under GPLv2. There doesn't
>> see
As you are using icedtea6, I guess DEPENDS += "icedtea6" should do it.
- Martin
On 10/08/12 16:49, Jaap de Jong wrote:
>
> On 10/08/2012 04:05 PM, Khem Raj wrote:
>> On Mon, Oct 8, 2012 at 4:18 AM, Jaap de Jong
>> wrote:
>>> Hi All!
>>> probably a stupid question... my apologies!
>>> If a source
Ok. Nice. Did not see your patches there.
- Martin
On 09/05/12 11:25, Martin Jansa wrote:
> On Wed, Sep 05, 2012 at 11:22:32AM +0200, Martin Ertsaas wrote:
>> ---
>> .../packagegroups/packagegroup-x11-server_1.0.bb | 23 +++
>> .../packagegroups/packagegroup-x11_1.0.bb |
Hi, and welcome.
The way we started was by looking at the angstrom distribution. That is
available as a oe-core layer, and you can easily start by compiling that
one.
After that, we started taking stuff from angstrom, into our own
repository. Starting with configurations, and changing them as we
w
Hi.
I have just made a new layer, for qt5 recipes. This contains work in
progress recipes, but should be working. In the (not so) long run, qt5
recipes will hopefully be added to oe-core, but in the meantime these
are available.
The recipes are based on the qt4 recipes in oe-core from 4-5 months
The issue was quite simple. My thoughts were correct, but should add
pkgconfig-nativesdk-dev to task-sdk-host-nativesdk.
- Martin
On 07/23/12 10:46, Martin Ertsås wrote:
> Hi.
>
> When building meta-toolchain, pkg.m4 is put in the arm sysroot of the
> toolchain, instead of the x86 s
Hi.
When building meta-toolchain, pkg.m4 is put in the arm sysroot of the
toolchain, instead of the x86 sysroot where it belongs. pkg-config is in
the x86 directory, and when it is in the arm directory, we need to hack
the aclocal flags to point to it for stuff to compile.
I have tried a few thin
This fixed it. Thanks.
- Martin
On 06/10/12 00:25, Khem Raj wrote:
> On 6/5/2012 11:20 PM, Martin Ertsås wrote:
> > The configure log is at: http://pastebin.com/93h1rw7G while the
> > compile log, which is what actually failes, is at:
> > http://pastebin.com/2iXYrCDa
>
&g
puzzles me.
Thanks for the help
- Martin
On 06/05/12 22:53, Khem Raj wrote:
> On Tuesday, June 5, 2012, Martin Ertsås wrote:
>> Sure. Will do it first thing in the morning. Think this actually happens
> in compile though, for some reason. Do you want me to paste it and give a
> li
Sure. Will do it first thing in the morning. Think this actually happens
in compile though, for some reason. Do you want me to paste it and give
a link, or is it ok with an attachment?
- Martin
On 06/04/12 18:32, Khem Raj wrote:
On Sun, Jun 3, 2012 at 11:49 PM, Martin Ertsås wrote:
Hi
Hi.
When trying to compile meta-toolchain, it crashes during
gcc-cross-initial with the error:
this target does not support --with-float
Valied --with options are: arch arch_32 arch_64 cpu cpu_32 cpu_64 tune
tune_32 tune_64
The reason for this is a commit that happened 2012-05-01 in openembedded
On 05/15/12 10:39, Thilo Fromm wrote:
> Hello Khem,
>
>>> I've got an issue with
>>> openembedded-core/meta/recipes-kernel/kmod/kmod_git.bb, with the way
>>> {libdir} is set in line 19:
>>>
>>> libdir = "${base_libdir}"
>>>
>>> "git blame" claims this was added by Khem Raj on 2012-05-08. This line
On 05/03/12 09:48, Koen Kooi wrote:
> Op 03-05-12 08:48, Martin Ertsås schreef:
> > On 05/02/12 23:06, Khem Raj wrote:
> >> On 05/02/2012 02:35 AM, Martin Ertsås wrote:
> >>> The patches posted seems to be working fine. I at least didn't have
> >>> an
On 05/02/12 23:06, Khem Raj wrote:
> On 05/02/2012 02:35 AM, Martin Ertsås wrote:
> > The patches posted seems to be working fine. I at least didn't have
> > any problems with them.
>
>
> thanks for trying them out. GCC patch is final but eglibc patch I
> still g
On 05/01/12 14:32, Khem Raj wrote:
> On Mon, Apr 30, 2012 at 11:44 PM, Martin Ertsås wrote:
>> On 05/01/12 00:05, Khem Raj wrote:
>>> On Fri, Apr 27, 2012 at 5:38 AM, Martin Ertsås wrote:
>>>> I'm working on a pandaboard with OMAP4460. Were trying to use
On 05/01/12 14:32, Khem Raj wrote:
On Mon, Apr 30, 2012 at 11:44 PM, Martin Ertsås wrote:
On 05/01/12 00:05, Khem Raj wrote:
On Fri, Apr 27, 2012 at 5:38 AM, Martin Ertsåswrote:
I'm working on a pandaboard with OMAP4460. Were trying to use the newest
PVR drivers, which conforms t
On 05/01/12 00:05, Khem Raj wrote:
On Fri, Apr 27, 2012 at 5:38 AM, Martin Ertsås wrote:
I'm working on a pandaboard with OMAP4460. Were trying to use the newest
PVR drivers, which conforms to the result that arose from
https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr201
On 04/29/12 04:40, Khem Raj wrote:
> On Fri, Apr 27, 2012 at 5:38 AM, Martin Ertsås wrote:
>> Hi.
>>
>> I'm working on a pandaboard with OMAP4460. Were trying to use the newest
>> PVR drivers, which conforms to the result that arose from
>> https:/
On 04/27/12 17:04, Mark Hatle wrote:
On 4/27/12 7:38 AM, Martin Ertsås wrote:
Hi.
I'm working on a pandaboard with OMAP4460. Were trying to use the newest
PVR drivers, which conforms to the result that arose from
https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
We
Hi.
I'm working on a pandaboard with OMAP4460. Were trying to use the newest
PVR drivers, which conforms to the result that arose from
https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
We have applied the patch at the bottom of that page gcc, and also a
patch for making eglibc m
Hi.
I'm using OE to build for OMAP4, when compiling python, OE reports
success, however only the core python seems to be built successfully.
Looking at the log files however, we see a lot of ld errors, when it
tries to link to x86_64 libraries. As an example, the following is
output with ncurses:
30 matches
Mail list logo
