* WARNING: Deprecated components removal in 5 days
From: Richard Purdie @ 2011-10-05 16:56 UTC (permalink / raw)
To: openembedded-core
This is a heads up notification that in 5 days time I'm planning to
remove the following things from OE-Core:
* gcc version 4.5
* eglibc 2.12
* gnomevfs
* qt 4.7.3
There is already a version of gcc 4.5 in meta-oe which should suffice
for anyone who still needs it.
Anyone wanting the other components will need to make arrangements for
those recipes to transition there.
I do plan to remove hal too as soon as the last dependency is removed
(my build without hal isn't booting X correctly atm).
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH v2 10/16] Fix mdadm for powerpc64
From: McClintock Matthew-B29882 @ 2011-10-05 16:53 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: McClintock Matthew-B29882
In-Reply-To: <1317814486.14671.136.camel@ted>
On Wed, Oct 5, 2011 at 6:34 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> I dug into this a bit. To quote asm/types.h:
>
> /*
> * This is here because we used to use l64 for 64bit powerpc
> * and we don't want to impact user mode with our change to ll64
> * in the kernel.
> */
> #if defined(__powerpc64__) && !defined(__KERNEL__)
> # include <asm-generic/int-l64.h>
> #else
> # include <asm-generic/int-ll64.h>
> #endif
>
> So ppc64 kernel space uses ll64 and userspace uses l64.
>
> This means __u64 is a long for ppc64 but a long long for x86_64. The
> format errors occurs rightly because a ull is being printed from a ul
> variable. This will happen to work but its messy.
Sorry, I'm missing if you are suggesting a solution here... do I need
to take an alternate approach? The alternative is to patch the
printfs?
-M
^ permalink raw reply
* Re: [PATCH 5/6] Fix sysprof for powerpc64
From: McClintock Matthew-B29882 @ 2011-10-05 16:48 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1317814555.14671.137.camel@ted>
On Wed, Oct 5, 2011 at 6:35 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>> this is a gcc built-in define I wonder why you need to add it explicitly
>
> Are you sure? Is the built-in define not __powerpc64__ ?
Further investigation:
[mattsm@right build_p5020ds-64b_release (testing $)]$
./tmp/sysroots/x86_64-linux/usr/bin/ppc64e5500-fsl-linux/powerpc64-fsl-linux-gcc
-c -E -dM empty.c | grep __p
#define __powerpc64__ 1
#define __powerpc__ 1
[mattsm@right build_p5020ds-64b_release (testing $)]$
-M
^ permalink raw reply
* Re: [PATCH 5/6] Fix sysprof for powerpc64
From: Khem Raj @ 2011-10-05 16:46 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1317814555.14671.137.camel@ted>
On Wed, Oct 5, 2011 at 4:35 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Tue, 2011-10-04 at 17:05 -0700, Khem Raj wrote:
>> On 10/4/2011 3:03 PM, Matthew McClintock wrote:
>> > sysprof will not build properly without this defined
>> >
>> > Signed-off-by: Matthew McClintock<msm@freescale.com>
>> > ---
>> > No comments on original patch sent
>> >
>> > meta/recipes-kernel/sysprof/sysprof_git.bb | 2 ++
>> > 1 files changed, 2 insertions(+), 0 deletions(-)
>> >
>> > diff --git a/meta/recipes-kernel/sysprof/sysprof_git.bb b/meta/recipes-kernel/sysprof/sysprof_git.bb
>> > index 10bde04..271b5d8 100644
>> > --- a/meta/recipes-kernel/sysprof/sysprof_git.bb
>> > +++ b/meta/recipes-kernel/sysprof/sysprof_git.bb
>> > @@ -16,6 +16,8 @@ SRC_URI_append_arm = " file://rmb-arm.patch"
>> > SRC_URI_append_mips = " file://rmb-mips.patch"
>> > SRC_URI_append_powerpc = " file://ppc-macro-fix.patch"
>> >
>> > +export CFLAGS_append_powerpc64 = " -D__ppc64__"
>> > +
>>
>> this is a gcc built-in define I wonder why you need to add it explicitly
>
> Are you sure? Is the built-in define not __powerpc64__ ?
yes that one too is a builtin define. I don't have the OE/ppc64 build
around to explore more
>
> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
^ permalink raw reply
* Re: Bringing an image from OE to OE-Core
From: Eric Bénard @ 2011-10-05 16:39 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <4E8C662B.4090300@balister.org>
Hi Philip,
Le 05/10/2011 16:14, Philip Balister a écrit :
> Short term, I think I'll copy the tasks/images into my bsp and get some
> stuff together for testing. I'd like a better long term solution though.
>
that's what we also did here to get the wanted result without using "standard"
variables which bring too much things in the image.
Eric
^ permalink raw reply
* Re: Bringing an image from OE to OE-Core
From: Koen Kooi @ 2011-10-05 16:20 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Cc: Patches and discussions about the oe-core layer
In-Reply-To: <4E8C662B.4090300@balister.org>
Op 5 okt. 2011 om 09:14 heeft Philip Balister <philip@balister.org> het volgende geschreven:
> On 10/04/2011 06:43 PM, Mark Hatle wrote:
>> On 10/4/11 3:32 PM, Saul Wold wrote:
>>> On 10/04/2011 01:27 PM, Philip Balister wrote:
>>>> On 10/04/2011 04:08 PM, Saul Wold wrote:
>>>>> On 10/04/2011 12:58 PM, Philip Balister wrote:
>>>>>> I'm about to start bringing some images I use from OE to OE-core. The
>>>>>> first issue I saw is there is no task-proper-tools in oe-core (where
>>>>>> oe-core means the set of layers created by the Angstrom setup scripts).
>>>>>>
>>>>> Philip,
>>>>>
>>>>> Have you looked at task-core-basic, it is supposed to be more of a
>>>>> desktop like set of tools, the idea being it's heavier weight than core,
>>>>> will move to supporting the non-graphical part of LSB.
>>>>>
>>>>> Another caveat for task-core-basic is that it's the largetest non-gplv3
>>>>> task that is used by core-image-basic.
>>>>>
>>>>> Does this task approach what you are looking for?
>>>>
>>>> It looks like a start, but I notice it brings in rpm. I'm not sure if I
>>>> want that. I would have thought that the package manager would be a
>>>> distro decision.
>>>>
>>> That's a bug that I would certainly take a patch for, unless rpm is
>>> required as part of LSB, that will need to be verified.
>>
>> The ability to install RPM packages is required by the LSB. The LSB does not
>> require RPM however. (yes I know, odd requirement, but with things like alien
>> it's doable on debian systems.)
>>
>> But yes, RPM is included to satisfy that requirement.
>
> This is beginning to look like a trickier problem than I would like. Between oe-core and meta-angstrom, there are a number of tasks/images to start from, but they each have something I don't like:
>
> 1) I do not want rpm in the image. This would confuse my customer base.
> 2) I am tired of dropbear, I want openssh only.
fwiw 0.53 fixed most of my problems (e.g x11 forwarding), does it fix your issues as well?
> 3) I need the full versions of tools, not the busybox ones.
> 4) I am not limited to gpv2 software.
>
> Richard, it looks to me like we should add an item for the next Yocto development cycle to review how images are built and try to make the base stuff in oe-core more usable by everyone. We need to define what choices are made by distros. For example opkg, rpm, no package management in image. Images may want dropbear or openssh.
>
> Short term, I think I'll copy the tasks/images into my bsp and get some stuff together for testing. I'd like a better long term solution though.
>
> Philip
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply
* Re: Bringing an image from OE to OE-Core
From: Mark Hatle @ 2011-10-05 15:49 UTC (permalink / raw)
To: Philip Balister; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <4E8C662B.4090300@balister.org>
On 10/5/11 9:14 AM, Philip Balister wrote:
> On 10/04/2011 06:43 PM, Mark Hatle wrote:
>> On 10/4/11 3:32 PM, Saul Wold wrote:
>>> On 10/04/2011 01:27 PM, Philip Balister wrote:
>>>> On 10/04/2011 04:08 PM, Saul Wold wrote:
>>>>> On 10/04/2011 12:58 PM, Philip Balister wrote:
>>>>>> I'm about to start bringing some images I use from OE to OE-core. The
>>>>>> first issue I saw is there is no task-proper-tools in oe-core (where
>>>>>> oe-core means the set of layers created by the Angstrom setup scripts).
>>>>>>
>>>>> Philip,
>>>>>
>>>>> Have you looked at task-core-basic, it is supposed to be more of a
>>>>> desktop like set of tools, the idea being it's heavier weight than core,
>>>>> will move to supporting the non-graphical part of LSB.
>>>>>
>>>>> Another caveat for task-core-basic is that it's the largetest non-gplv3
>>>>> task that is used by core-image-basic.
>>>>>
>>>>> Does this task approach what you are looking for?
>>>>
>>>> It looks like a start, but I notice it brings in rpm. I'm not sure if I
>>>> want that. I would have thought that the package manager would be a
>>>> distro decision.
>>>>
>>> That's a bug that I would certainly take a patch for, unless rpm is
>>> required as part of LSB, that will need to be verified.
>>
>> The ability to install RPM packages is required by the LSB. The LSB does not
>> require RPM however. (yes I know, odd requirement, but with things like alien
>> it's doable on debian systems.)
>>
>> But yes, RPM is included to satisfy that requirement.
>
> This is beginning to look like a trickier problem than I would like.
> Between oe-core and meta-angstrom, there are a number of tasks/images to
> start from, but they each have something I don't like:
>
> 1) I do not want rpm in the image. This would confuse my customer base.
> 2) I am tired of dropbear, I want openssh only.
> 3) I need the full versions of tools, not the busybox ones.
> 4) I am not limited to gpv2 software.
>
> Richard, it looks to me like we should add an item for the next Yocto
> development cycle to review how images are built and try to make the
> base stuff in oe-core more usable by everyone. We need to define what
> choices are made by distros. For example opkg, rpm, no package
> management in image. Images may want dropbear or openssh.
>
> Short term, I think I'll copy the tasks/images into my bsp and get some
> stuff together for testing. I'd like a better long term solution though.
I'd suggest for now you try "hob". It's capable of setting up image classes
that can do exactly what you want.. selecting specific packages that must be on
the target image and generating it.
I think the key thing for oe-core is that we'll never have the "right" set of
predefined images.. but we do need something so we can run the specific suite of
tests to show that things are function, as well as give starting points.
And I absolutely agree that we need to re-evaluate the configurations and come
up with distribution flags (feature flags?) that can do things like
enable/disable busybox, dropbear and other tooling. (GPLv2 packages are only
built if you've excluded GPLv3 from your build.. otherwise the latest/greatest
version is defaulted to on.)
--Mark
> Philip
^ permalink raw reply
* Re: Bringing an image from OE to OE-Core
From: Philip Balister @ 2011-10-05 14:14 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <4E8B8C05.5050508@windriver.com>
On 10/04/2011 06:43 PM, Mark Hatle wrote:
> On 10/4/11 3:32 PM, Saul Wold wrote:
>> On 10/04/2011 01:27 PM, Philip Balister wrote:
>>> On 10/04/2011 04:08 PM, Saul Wold wrote:
>>>> On 10/04/2011 12:58 PM, Philip Balister wrote:
>>>>> I'm about to start bringing some images I use from OE to OE-core. The
>>>>> first issue I saw is there is no task-proper-tools in oe-core (where
>>>>> oe-core means the set of layers created by the Angstrom setup scripts).
>>>>>
>>>> Philip,
>>>>
>>>> Have you looked at task-core-basic, it is supposed to be more of a
>>>> desktop like set of tools, the idea being it's heavier weight than core,
>>>> will move to supporting the non-graphical part of LSB.
>>>>
>>>> Another caveat for task-core-basic is that it's the largetest non-gplv3
>>>> task that is used by core-image-basic.
>>>>
>>>> Does this task approach what you are looking for?
>>>
>>> It looks like a start, but I notice it brings in rpm. I'm not sure if I
>>> want that. I would have thought that the package manager would be a
>>> distro decision.
>>>
>> That's a bug that I would certainly take a patch for, unless rpm is
>> required as part of LSB, that will need to be verified.
>
> The ability to install RPM packages is required by the LSB. The LSB does not
> require RPM however. (yes I know, odd requirement, but with things like alien
> it's doable on debian systems.)
>
> But yes, RPM is included to satisfy that requirement.
This is beginning to look like a trickier problem than I would like.
Between oe-core and meta-angstrom, there are a number of tasks/images to
start from, but they each have something I don't like:
1) I do not want rpm in the image. This would confuse my customer base.
2) I am tired of dropbear, I want openssh only.
3) I need the full versions of tools, not the busybox ones.
4) I am not limited to gpv2 software.
Richard, it looks to me like we should add an item for the next Yocto
development cycle to review how images are built and try to make the
base stuff in oe-core more usable by everyone. We need to define what
choices are made by distros. For example opkg, rpm, no package
management in image. Images may want dropbear or openssh.
Short term, I think I'll copy the tasks/images into my bsp and get some
stuff together for testing. I'd like a better long term solution though.
Philip
^ permalink raw reply
* Re: bitbake webkit-gtk fails with clean temp dir
From: Richard Purdie @ 2011-10-05 13:37 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <201110050205.24428.schnitzeltony@gmx.de>
On Wed, 2011-10-05 at 02:05 +0200, Andreas Müller wrote:
> On Tuesday, October 04, 2011 02:40:49 PM Richard Purdie wrote:
> > On Mon, 2011-10-03 at 20:45 +0200, Andreas Müller wrote:
> > > On Monday, October 03, 2011 05:29:52 PM Gary Thomas wrote:
> > > > >> NOTE: package webkit-gtk-1.5.1+svnr90727-r0: task do_compile: Failed
> > > > >> ERROR: Task 7 (/home/Superandy/data/oe-core/sources/openembedded-core/meta/recipes-sato/webkit/webkit-gtk_svn.bb, do_compile) failed with exit code '1'
> > > > >>
> > > > >> ideas what causes this?
> > > > >
> > > > > no idea, but I get the same error
> > > > >
> > > >
> > > > It builds in Yocto/Poky so you might compare with those recipes.
> > > Dit you pull [1] and rebuild webkit-gtk?
> > > >
> > > >
> > > some investigation later: by diff'ing log files created by working environment with the current environment I fell over log.do_configure:
> > >
> > > --disable-dependency-tracking
> > >
> > > was added in [1]. Tried manual bisecting by
> > >
> > > git reset --hard 288343e30604b944dc18fd82172febd314d9c520
> > >
> > > é voilà: webkit-gtk builds again. Will send a patch with --enable-dependency-tracking after testing...
> > >
> > > Andreas
> >
> >
> > I'm planning to add this commit:
> >
> > http://cgit.openembedded.org/cgit.cgi/openembedded-core/commit/?h=master-next&id=d53a0282be132a4ced507c0277925ae4a0f2f40d
> >
> > which means you should just be able to set:
> >
> > CONFIGUREOPT_DEPTRACK = ""
> >
> > for this recipe rather than having multiple configure options and hoping
> > the right one wins.
> I thought recipe's EXTRA_OECONF is by design ensured being appended and thereby overwriting options of same target.
> >
> > I'd also note this means there is a bug somewhere in the webkit
> > makefiles...
> Agreed - somebody with time & skills willing to take care?
I'm not sure I have the time or the right skillset for that one but at
least we've highighted there is a problem there...
> If there are no objections I'll send a patch with
>
> CONFIGUREOPT_DEPTRACK = ""
>
> for webkit-gtk as soon as d53a0282be132a4ced507c0277925ae4a0f2f40d becomes part of master branch
I've gone ahead and added this since I think we're all agreed on what is
needed here :)
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH 4/6] scripts/oe-buildenv-internal: Add SOCKS5_{USER, PASSWD} to BB_ENV_EXTRAWHITE
From: Richard Purdie @ 2011-10-05 13:25 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1317765787-19127-4-git-send-email-msm@freescale.com>
On Tue, 2011-10-04 at 17:03 -0500, Matthew McClintock wrote:
> From: Kumar Gala <galak@kernel.crashing.org>
>
> If a SOCKS5 gateway is needed for a proxy access like git it might also
> require authentication to the proxy via a password and username. Adding
> SOCKS5_USER & SOCKS5_PASSWD to BB_ENV_EXTRAWHITE allow for automation
> of the authentication request to occur when something like a git fetch
> is going through the proxy.
>
> This patch requires the bitbake patch to add extra exportvars so
> these variables get passed from Env -> bitbake -> fetcher
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> This requires a bitbake patch that was just sent:
>
> http://lists.linuxtogo.org/pipermail/bitbake-devel/2011-October/001453.html
Merged to master, thanks.
Richard
^ permalink raw reply
* Re: [PATCH] Improve handling of 'all' architecture recipes and their interaction with sstate
From: Richard Purdie @ 2011-10-05 13:02 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Koen Kooi
In-Reply-To: <20111005123433.GG19366@jama.jama.net>
On Wed, 2011-10-05 at 14:34 +0200, Martin Jansa wrote:
> On Wed, Oct 05, 2011 at 07:29:10AM -0500, Koen Kooi wrote:
> >
> >
> > Op 5 okt. 2011 om 07:27 heeft Otavio Salvador <otavio@ossystems.com.br> het volgende geschreven:
> >
> > > On Wed, Oct 5, 2011 at 09:22, Koen Kooi <koen@dominion.thruhere.net> wrote:
> > >> Op 5 okt. 2011 om 07:10 heeft Otavio Salvador <otavio@ossystems.com.br> het volgende geschreven:
> > >>> On Tue, Oct 4, 2011 at 19:00, Richard Purdie
> > >>> <richard.purdie@linuxfoundation.org> wrote:
> > >>>> Really? hal doesn't really replace udev though, we can just use udev
> > >>>> directly in place of it for many things now?
> > >>>
> > >>> Yes, many moved from hal to udev.
> > >>>
> > >>>> Specifically which applications are people using with dependencies on
> > >>>> hal? As has been pointed out we can fix the xserver and that appears to
> > >>>> be the only thing remaining in OE-Core?
> > >>>
> > >>> OE-Core can be easily hal-less but I just ask for hal to not be
> > >>> removed from meta data as I and probably others hasn't finish the move
> > >>> to udev yet.
> > >>
> > >> Put it in your own layer if you need it. No point in keeping obsolete stuff in oe-core.
> > >
> > > I wouldn't call it obsolete as it is still a valid option to Xorg and
> > > maybe others. So people might want to use it. I use it.
> >
> > So put it in your own layer, it has no place in oe-core anymore.
>
> Agreed, that it has no place in oe-core anymore, but not sure if we can
> keep
> CONFIG_MANAGER_OPTION +=
> "${@['--disable-config-hal','--enable-config-hal',''][bb.data.getVar('DISTRO_XORG_CONFIG_MANAGER',d)
> in ['hal']]}"
>
> in xserver-xorg or we'll force averybody with hal in his layer to
> .bbappend xserver-xorg too.
I don't mind that staying in the xserver recipe config for now, I do
think hal needs to move somewhere other than oe-core though. A
deprecated layer in meta-oe might be one idea which would keep a common
recipe around for now but make it clear its on its way out.
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH] Improve handling of 'all' architecture recipes and their interaction with sstate
From: Martin Jansa @ 2011-10-05 12:34 UTC (permalink / raw)
To: Koen Kooi; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <7F30A97F-D852-4A45-9023-D979D974866A@dominion.thruhere.net>
[-- Attachment #1: Type: text/plain, Size: 1741 bytes --]
On Wed, Oct 05, 2011 at 07:29:10AM -0500, Koen Kooi wrote:
>
>
> Op 5 okt. 2011 om 07:27 heeft Otavio Salvador <otavio@ossystems.com.br> het volgende geschreven:
>
> > On Wed, Oct 5, 2011 at 09:22, Koen Kooi <koen@dominion.thruhere.net> wrote:
> >> Op 5 okt. 2011 om 07:10 heeft Otavio Salvador <otavio@ossystems.com.br> het volgende geschreven:
> >>> On Tue, Oct 4, 2011 at 19:00, Richard Purdie
> >>> <richard.purdie@linuxfoundation.org> wrote:
> >>>> Really? hal doesn't really replace udev though, we can just use udev
> >>>> directly in place of it for many things now?
> >>>
> >>> Yes, many moved from hal to udev.
> >>>
> >>>> Specifically which applications are people using with dependencies on
> >>>> hal? As has been pointed out we can fix the xserver and that appears to
> >>>> be the only thing remaining in OE-Core?
> >>>
> >>> OE-Core can be easily hal-less but I just ask for hal to not be
> >>> removed from meta data as I and probably others hasn't finish the move
> >>> to udev yet.
> >>
> >> Put it in your own layer if you need it. No point in keeping obsolete stuff in oe-core.
> >
> > I wouldn't call it obsolete as it is still a valid option to Xorg and
> > maybe others. So people might want to use it. I use it.
>
> So put it in your own layer, it has no place in oe-core anymore.
Agreed, that it has no place in oe-core anymore, but not sure if we can
keep
CONFIG_MANAGER_OPTION +=
"${@['--disable-config-hal','--enable-config-hal',''][bb.data.getVar('DISTRO_XORG_CONFIG_MANAGER',d)
in ['hal']]}"
in xserver-xorg or we'll force averybody with hal in his layer to
.bbappend xserver-xorg too.
Regards,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* Re: [PATCH] Improve handling of 'all' architecture recipes and their interaction with sstate
From: Koen Kooi @ 2011-10-05 12:29 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: <CAP9ODKp5+nmtPfm+AabX5K9YoGnY_KVE6E1HxP=DJ2c+H2WdcQ@mail.gmail.com>
Op 5 okt. 2011 om 07:27 heeft Otavio Salvador <otavio@ossystems.com.br> het volgende geschreven:
> On Wed, Oct 5, 2011 at 09:22, Koen Kooi <koen@dominion.thruhere.net> wrote:
>> Op 5 okt. 2011 om 07:10 heeft Otavio Salvador <otavio@ossystems.com.br> het volgende geschreven:
>>> On Tue, Oct 4, 2011 at 19:00, Richard Purdie
>>> <richard.purdie@linuxfoundation.org> wrote:
>>>> Really? hal doesn't really replace udev though, we can just use udev
>>>> directly in place of it for many things now?
>>>
>>> Yes, many moved from hal to udev.
>>>
>>>> Specifically which applications are people using with dependencies on
>>>> hal? As has been pointed out we can fix the xserver and that appears to
>>>> be the only thing remaining in OE-Core?
>>>
>>> OE-Core can be easily hal-less but I just ask for hal to not be
>>> removed from meta data as I and probably others hasn't finish the move
>>> to udev yet.
>>
>> Put it in your own layer if you need it. No point in keeping obsolete stuff in oe-core.
>
> I wouldn't call it obsolete as it is still a valid option to Xorg and
> maybe others. So people might want to use it. I use it.
So put it in your own layer, it has no place in oe-core anymore.
>
> --
> Otavio Salvador O.S. Systems
> E-mail: otavio@ossystems.com.br http://www.ossystems.com.br
> Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply
* Re: [PATCH] Improve handling of 'all' architecture recipes and their interaction with sstate
From: Otavio Salvador @ 2011-10-05 12:27 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Martin Jansa
In-Reply-To: <11F8FF03-4C38-4D33-9250-66B5C180698C@dominion.thruhere.net>
On Wed, Oct 5, 2011 at 09:22, Koen Kooi <koen@dominion.thruhere.net> wrote:
> Op 5 okt. 2011 om 07:10 heeft Otavio Salvador <otavio@ossystems.com.br> het volgende geschreven:
>> On Tue, Oct 4, 2011 at 19:00, Richard Purdie
>> <richard.purdie@linuxfoundation.org> wrote:
>>> Really? hal doesn't really replace udev though, we can just use udev
>>> directly in place of it for many things now?
>>
>> Yes, many moved from hal to udev.
>>
>>> Specifically which applications are people using with dependencies on
>>> hal? As has been pointed out we can fix the xserver and that appears to
>>> be the only thing remaining in OE-Core?
>>
>> OE-Core can be easily hal-less but I just ask for hal to not be
>> removed from meta data as I and probably others hasn't finish the move
>> to udev yet.
>
> Put it in your own layer if you need it. No point in keeping obsolete stuff in oe-core.
I wouldn't call it obsolete as it is still a valid option to Xorg and
maybe others. So people might want to use it. I use it.
--
Otavio Salvador O.S. Systems
E-mail: otavio@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply
* Re: [PATCH] Improve handling of 'all' architecture recipes and their interaction with sstate
From: Koen Kooi @ 2011-10-05 12:22 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: <CAP9ODKrfDeDMomqeJCeyJBWqD_KqdMO=WBvjVY5d_j+btn3DfQ@mail.gmail.com>
Op 5 okt. 2011 om 07:10 heeft Otavio Salvador <otavio@ossystems.com.br> het volgende geschreven:
> On Tue, Oct 4, 2011 at 19:00, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>> Really? hal doesn't really replace udev though, we can just use udev
>> directly in place of it for many things now?
>
> Yes, many moved from hal to udev.
>
>> Specifically which applications are people using with dependencies on
>> hal? As has been pointed out we can fix the xserver and that appears to
>> be the only thing remaining in OE-Core?
>
> OE-Core can be easily hal-less but I just ask for hal to not be
> removed from meta data as I and probably others hasn't finish the move
> to udev yet.
Put it in your own layer if you need it. No point in keeping obsolete stuff in oe-core.
>
> --
> Otavio Salvador O.S. Systems
> E-mail: otavio@ossystems.com.br http://www.ossystems.com.br
> Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply
* Re: [PATCH] Improve handling of 'all' architecture recipes and their interaction with sstate
From: Otavio Salvador @ 2011-10-05 12:10 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Martin Jansa
In-Reply-To: <1317765609.14671.118.camel@ted>
On Tue, Oct 4, 2011 at 19:00, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> Really? hal doesn't really replace udev though, we can just use udev
> directly in place of it for many things now?
Yes, many moved from hal to udev.
> Specifically which applications are people using with dependencies on
> hal? As has been pointed out we can fix the xserver and that appears to
> be the only thing remaining in OE-Core?
OE-Core can be easily hal-less but I just ask for hal to not be
removed from meta data as I and probably others hasn't finish the move
to udev yet.
--
Otavio Salvador O.S. Systems
E-mail: otavio@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply
* Re: [PATCH 2/6] Fix perl for powerpc64 build
From: Richard Purdie @ 2011-10-05 11:46 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1317765787-19127-2-git-send-email-msm@freescale.com>
On Tue, 2011-10-04 at 17:03 -0500, Matthew McClintock wrote:
> Build environment for ARCH was set to powerpc on a powerpc64
> build, this adds an override to set this to powerpc64 when
> doing this type of build
>
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> No comments on original patch:
>
> http://lists.linuxtogo.org/pipermail/openembedded-core/2011-September/010340.html
>
> meta/recipes-devtools/perl/perl_5.12.3.bb | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-devtools/perl/perl_5.12.3.bb b/meta/recipes-devtools/perl/perl_5.12.3.bb
> index e4769a4..d1ac0e8 100644
> --- a/meta/recipes-devtools/perl/perl_5.12.3.bb
> +++ b/meta/recipes-devtools/perl/perl_5.12.3.bb
> @@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = "file://Copying;md5=2b4c6ffbcfcbdee469f02565f253d81a \
> # We need gnugrep (for -I)
> DEPENDS = "virtual/db grep-native"
> DEPENDS += "gdbm zlib"
> -PR = "r5"
> +PR = "r6"
>
> # 5.10.1 has Module::Build built-in
> PROVIDES += "libmodule-build-perl"
> @@ -95,6 +95,8 @@ export LDDLFLAGS = "${LDFLAGS} -shared"
> # We're almost Debian, aren't we?
> CFLAGS += "-DDEBIAN"
>
> +export ARCH_powerpc64 = "powerpc64"
> +
I'm finding it really hard to believe this makes any difference. I just
tried a powerpc64 build here and perl built fine. I can't find any
evidence for any part of the perl build using an ARCH variable
(TARGET_ARCH is used but that isn't ARCH).
Can you give some further information about how/where this is used?
> do_nolargefile() {
> sed -i -e "s,\(uselargefiles=\)'define',\1'undef',g" \
> -e "s,\(d_readdir64_r=\)'define',\1'undef',g" \
> @@ -156,7 +158,7 @@ do_configure() {
> config.sh-${TARGET_ARCH}-${TARGET_OS}
>
> case "${TARGET_ARCH}" in
> - x86_64 | powerpc | s390)
> + x86_64 | powerpc | powerpc64 | s390)
> sed -i -e "s,\(need_va_copy=\)'undef',\1'define',g" \
> config.sh-${TARGET_ARCH}-${TARGET_OS}
> ;;
This bit is fine...
Cheers,
Richard
^ permalink raw reply
* Re: Workaround to compile linux-omap_2.6.39.bb?
From: Richard Purdie @ 2011-10-05 11:38 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <4E8C3603.9000803@gmail.com>
On Wed, 2011-10-05 at 12:48 +0200, Tasslehoff Kjappfot wrote:
> I need to compile linux-omap_2.6.39.bb, but it fails since the
> tmlind-repos are not currently on kernel.org.
>
> I have downloaded
> git_git.kernel.org.pub.scm.linux.kernel.git.tmlind.linux-omap-2.6.git_v2.6.39.tar.gz
> from the angstrom mirrors. Can I extract that into my downloads/ in a
> way that will make bitbake find and accept it?
OE-Core uses fetch2 and that is a tarball from fetch1. You'd need to
convert that tarball into the form that fetch2 expects and rename it,
then you stand some chance of it working.
Also note that your recipes needs to be using a fixed source revision
and that revision needs to be present in that tarball.
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH 5/6] Fix sysprof for powerpc64
From: Richard Purdie @ 2011-10-05 11:35 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <4E8B9F2C.5030706@gmail.com>
On Tue, 2011-10-04 at 17:05 -0700, Khem Raj wrote:
> On 10/4/2011 3:03 PM, Matthew McClintock wrote:
> > sysprof will not build properly without this defined
> >
> > Signed-off-by: Matthew McClintock<msm@freescale.com>
> > ---
> > No comments on original patch sent
> >
> > meta/recipes-kernel/sysprof/sysprof_git.bb | 2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/meta/recipes-kernel/sysprof/sysprof_git.bb b/meta/recipes-kernel/sysprof/sysprof_git.bb
> > index 10bde04..271b5d8 100644
> > --- a/meta/recipes-kernel/sysprof/sysprof_git.bb
> > +++ b/meta/recipes-kernel/sysprof/sysprof_git.bb
> > @@ -16,6 +16,8 @@ SRC_URI_append_arm = " file://rmb-arm.patch"
> > SRC_URI_append_mips = " file://rmb-mips.patch"
> > SRC_URI_append_powerpc = " file://ppc-macro-fix.patch"
> >
> > +export CFLAGS_append_powerpc64 = " -D__ppc64__"
> > +
>
> this is a gcc built-in define I wonder why you need to add it explicitly
Are you sure? Is the built-in define not __powerpc64__ ?
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH v2 10/16] Fix mdadm for powerpc64
From: Richard Purdie @ 2011-10-05 11:34 UTC (permalink / raw)
To: McClintock Matthew-B29882,
Patches and discussions about the oe-core layer
In-Reply-To: <CAEsOVNdahRcHTCfVhaqFZiVaKhAtM2a6L6GTm61RtsGoJxjB6A@mail.gmail.com>
On Tue, 2011-10-04 at 21:52 +0000, McClintock Matthew-B29882 wrote:
> On Mon, Oct 3, 2011 at 4:17 PM, Khem Raj <raj.khem@gmail.com> wrote:
> >> I can't find a log of this anywhere, it's probably the default
> >> compiler warnings for our platform are different?
> >
> > It would be handy to understand them since I dont see gcc differentiating
> > formats between ppc64 and x86_64 which both are 64bit hosts. But obviously
> > there is something missing.
>
> I finally got around to rerunning this without my patch and the errors
> are below.
I dug into this a bit. To quote asm/types.h:
/*
* This is here because we used to use l64 for 64bit powerpc
* and we don't want to impact user mode with our change to ll64
* in the kernel.
*/
#if defined(__powerpc64__) && !defined(__KERNEL__)
# include <asm-generic/int-l64.h>
#else
# include <asm-generic/int-ll64.h>
#endif
So ppc64 kernel space uses ll64 and userspace uses l64.
This means __u64 is a long for ppc64 but a long long for x86_64. The
format errors occurs rightly because a ull is being printed from a ul
variable. This will happen to work but its messy.
Cheers,
Richard
^ permalink raw reply
* Workaround to compile linux-omap_2.6.39.bb?
From: Tasslehoff Kjappfot @ 2011-10-05 10:48 UTC (permalink / raw)
To: openembedded-core
I need to compile linux-omap_2.6.39.bb, but it fails since the
tmlind-repos are not currently on kernel.org.
I have downloaded
git_git.kernel.org.pub.scm.linux.kernel.git.tmlind.linux-omap-2.6.git_v2.6.39.tar.gz
from the angstrom mirrors. Can I extract that into my downloads/ in a
way that will make bitbake find and accept it?
- Tasslehoff
^ permalink raw reply
* Re: conman-gnome sources missing
From: Richard Purdie @ 2011-10-05 10:26 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <201110050819.46880.schnitzeltony@gmx.de>
On Wed, 2011-10-05 at 08:19 +0200, Andreas Müller wrote:
> Although kernel.org seems up again I cannot download sources for conman-gnome
>
> | ERROR: Function 'Fetcher failure for URL: 'git://git.kernel.org/pub/scm/network/connman/connman-gnome.git;protocol=git'. Unable to fetch URL git://git.kernel.org/pub/scm/network/connman/connman-gnome.git;protocol=git from any source.' failed
> |
> NOTE: package connman-gnome-0.5-r7: task do_fetch: Failed
>
> Where can I get the sources?
There is a copy on the Yocto sources mirror:
http://autobuilder.yoctoproject.org/pub/sources/git2_git.kernel.org.pub.scm.network.connman.connman-gnome.git.tar.gz
Cheers,
Richard
^ permalink raw reply
* Re: gdb-cross-canadian fails to build
From: Richard Purdie @ 2011-10-05 10:12 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <9DA5872FEF993D41B7173F58FCF6BE94E098FD75@orsmsx504.amr.corp.intel.com>
On Tue, 2011-10-04 at 13:48 -0700, Kamble, Nitin A wrote:
>
> > -----Original Message-----
> > From: otavio.salvador@gmail.com [mailto:otavio.salvador@gmail.com] On
> > Behalf Of Otavio Salvador
> > Sent: Tuesday, October 04, 2011 1:48 PM
> > To: Patches and discussions about the oe-core layer; Kamble, Nitin A
> > Subject: Re: gdb-cross-canadian fails to build
> >
> > On Tue, Oct 4, 2011 at 17:40, Otavio Salvador <otavio@ossystems.com.br>
> > wrote:
> > ...
> > > Log data follows:
> > > | NOTE: Applying patch 'no-werror.patch'
> > > (openembedded-core/meta/recipes-devtools/gdb/gdb/no-werror.patch)
> > ...
> > > /home/otavio/hacking/ossystems/embedded-linux/openembedded-
> > core/meta/recipes-devtools/gdb/gdb-cross-canadian_7.3.1.bb:
> > ...
> >
> > It seems to have been broken by:
> > 9002f664383d71682767546524e1299137b6fe4f
> >
> > Nitin, can you take a look?
> Sure, I will look into it.
I've pushed a fix for this.
Nitin: This is the second time a gdb upgrade has broken in this way so
please ensure you test cross-canadian in future please!
Cheers,
Richard
^ permalink raw reply
* Re: pkg-config bug crashes 'bitbake glib-2.0-native' in FC15.x86_64
From: Richard Purdie @ 2011-10-05 10:05 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1317808871.14671.126.camel@ted>
On Wed, 2011-10-05 at 11:01 +0100, Richard Purdie wrote:
> On Wed, 2011-10-05 at 03:21 -0600, dashesy wrote:
> > Hi,
> >
> > I am using these in my local.conf with master branch of oe-core:
> > DISTRO="angstrom-2010.x"
> > MACHINE="beagleboard"
> >
> > The build for 'bitbake glib-2.0-native' (or actually 'bitbake
> > meta-toolchain') will finally reach a run.do_configure for 'package
> > glib-2.0-native-1_2.28.8-r5: task do_configure: Started'
> > which runs the "oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/bin/pkg-config"
> > for auto build
> > This leads to the following chain
> > pkg-config(cross)->gnome-config->pkg-config->glib-config->pkg-config->...
> >
> > dashesy 21266 21265 21266 0 1 01:56 pts/0 00:00:00 /bin/sh -e
> > /home/dashesy/buildroot/oe-core/build/tmp-eglibc/work/x86_64-linux/glib-2.0-native-1_2.28.8-r5/temp/run.do_configure.21265
> > root 21870 935 21870 0 1 01:56 ? 00:00:00 sleep 60
> > dashesy 22246 21266 22246 0 1 01:56 pts/0 00:00:00 /bin/sh
> > /home/dashesy/buildroot/oe-core/build/tmp-eglibc/work/x86_64-linux/glib-2.0-native-1_2.28.8-r5/glib-2.28.8/configure
> > --build=x86_64-linux --host=x86_64-linux --target=x86_64-linux
> > --prefix=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr
> > --exec_prefix=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr
> > --bindir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/bin
> > --sbindir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/sbin
> > --libexecdir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/libexec
> > --datadir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/share
> > --sysconfdir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/etc
> > --sharedstatedir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/com
> > --localstatedir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/var
> > --libdir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/lib
> > --includedir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/include
> > --oldincludedir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/include
> > --infodir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/share/info
> > --mandir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/share/man
> > --disable-silent-rules --disable-dependency-tracking --disable-dtrace
> > --disable-systemtap --enable-nls --enable-dtrace=no
> > dashesy 22671 22246 22671 0 1 01:56 pts/0 00:00:00
> > /home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/bin/pkg-config
> > --exists --print-errors zlib
> > dashesy 22672 22671 22672 0 1 01:56 pts/0 00:00:00 sh -c
> > gnome-config --libs zlib > /dev/null 2>&1
>
> Something odd is happening here. We have a patch in OE-Core against
> pkg-config which should disable "leagacy" pkg-config functionality.
>
> I took a look and it somehow looks like the patch got broken. Could you
> try again with
>
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip8&id=de51d6ffae1d6a4f594687d5bdef25e731f44dfa
>
> applied please? I think this should fix this problem.
Sorry, this should be:
http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip8&id=8d04d67271e5698ede8c08d3b6e3d4d7e38ffb0c
Cheers,
Richard
^ permalink raw reply
* Re: pkg-config bug crashes 'bitbake glib-2.0-native' in FC15.x86_64
From: Richard Purdie @ 2011-10-05 10:01 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <CADWjqk4pPWNYzO7Cua7xYXa55g=BWqwAY8taHhLwV=xaesDWPA@mail.gmail.com>
On Wed, 2011-10-05 at 03:21 -0600, dashesy wrote:
> Hi,
>
> I am using these in my local.conf with master branch of oe-core:
> DISTRO="angstrom-2010.x"
> MACHINE="beagleboard"
>
> The build for 'bitbake glib-2.0-native' (or actually 'bitbake
> meta-toolchain') will finally reach a run.do_configure for 'package
> glib-2.0-native-1_2.28.8-r5: task do_configure: Started'
> which runs the "oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/bin/pkg-config"
> for auto build
> This leads to the following chain
> pkg-config(cross)->gnome-config->pkg-config->glib-config->pkg-config->...
>
> dashesy 21266 21265 21266 0 1 01:56 pts/0 00:00:00 /bin/sh -e
> /home/dashesy/buildroot/oe-core/build/tmp-eglibc/work/x86_64-linux/glib-2.0-native-1_2.28.8-r5/temp/run.do_configure.21265
> root 21870 935 21870 0 1 01:56 ? 00:00:00 sleep 60
> dashesy 22246 21266 22246 0 1 01:56 pts/0 00:00:00 /bin/sh
> /home/dashesy/buildroot/oe-core/build/tmp-eglibc/work/x86_64-linux/glib-2.0-native-1_2.28.8-r5/glib-2.28.8/configure
> --build=x86_64-linux --host=x86_64-linux --target=x86_64-linux
> --prefix=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr
> --exec_prefix=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr
> --bindir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/bin
> --sbindir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/sbin
> --libexecdir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/libexec
> --datadir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/share
> --sysconfdir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/etc
> --sharedstatedir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/com
> --localstatedir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/var
> --libdir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/lib
> --includedir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/include
> --oldincludedir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/include
> --infodir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/share/info
> --mandir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/share/man
> --disable-silent-rules --disable-dependency-tracking --disable-dtrace
> --disable-systemtap --enable-nls --enable-dtrace=no
> dashesy 22671 22246 22671 0 1 01:56 pts/0 00:00:00
> /home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/bin/pkg-config
> --exists --print-errors zlib
> dashesy 22672 22671 22672 0 1 01:56 pts/0 00:00:00 sh -c
> gnome-config --libs zlib > /dev/null 2>&1
Something odd is happening here. We have a patch in OE-Core against
pkg-config which should disable "leagacy" pkg-config functionality.
I took a look and it somehow looks like the patch got broken. Could you
try again with
http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip8&id=de51d6ffae1d6a4f594687d5bdef25e731f44dfa
applied please? I think this should fix this problem.
Cheers,
Richard
^ 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