I guess it is enough to scope just the variables in boot-directdisk
for now then.
Regards,
Jonathan
On 03/05/2013, at 8:33 AM, Saul Wold wrote:
> On 05/02/2013 01:56 PM, Jonathan Liu wrote:
>> These variables should not be shared with other image classes.
>> The boot-directdisk class also has a
On 05/02/2013 01:56 PM, Jonathan Liu wrote:
These variables should not be shared with other image classes.
The boot-directdisk class also has an HDDDIR variable that could be
overwritten if executing concurrently in the same image recipe.
Signed-off-by: Jonathan Liu
---
meta/classes/bootimg.b
These variables should not be shared with other image classes.
The boot-directdisk class also has an HDDDIR variable that could be
overwritten if executing concurrently in the same image recipe.
Signed-off-by: Jonathan Liu
---
meta/classes/bootimg.bbclass | 25 +
1 file c
These variables should not be shared with other image classes.
The bootimg class also has an HDDDIR variable that could be overwritten
if executing concurrently in the same image recipe.
Signed-off-by: Jonathan Liu
---
meta/classes/boot-directdisk.bbclass | 25 -
1 file c
Note: This depends on syslinux update to 4.06.
Jonathan Liu (2):
boot-directdisk: Scope HDDDIR and HDDIMG variables to avoid conflicts
bootimg: Scope HDDDIR and ISODIR variables to avoid conflicts
meta/classes/boot-directdisk.bbclass | 25 -
meta/classes/bootimg.bbcla
fix_parallel_build_issue.patch is now part of upstream.
Signed-off-by: Jonathan Liu
---
.../guile/files/fix_parallel_build_issue.patch | 20
meta/recipes-devtools/guile/guile_2.0.7.bb | 103 -
meta/recipes-devtools/guile/guile_2.0.9.bb | 102
On Thu, May 2, 2013 at 1:22 PM, Martin Jansa wrote:
> See:
> http://lists.linuxtogo.org/pipermail/openembedded-devel/2013-April/045090.html
Ah yes... openembedded-devel... that magic list to which I can't seem
to subscribe myself ;-)
___
Openembedded-c
On 04/29/2013 03:52 AM, Jonathan Liu wrote:
fix_parallel_build_issue.patch is now part of upstream.
There was a problem with this patch, maybe due the attachment, can you
please resend without the attachment.
Thanks
Sau!
Signed-off-by: Jonathan Liu
---
.../guile/files/fix_paralle
On 05/02/2013 09:52 AM, Richard Purdie wrote:
On Wed, 2013-05-01 at 12:31 -0700, Saul Wold wrote:
On 04/30/2013 05:30 AM, Andreas Müller wrote:
as discussed in [1-2]
[1]
http://lists.linuxtogo.org/pipermail/openembedded-core/2013-April/039025.html
[2]
http://lists.linuxtogo.org/pipermail/ope
On 5/2/13 12:24 PM, Enrico Scholz wrote:
"Burton, Ross" writes:
rpm allows "executables" (but not libraries) to conflict and will
prefer the 64-bit version,
Sure? At least rpm-4 (Fedora, RHEL) does not allow files to conflict.
Fedora solves the multilib problem by splitting the distribution
On 04/29/2013 11:33 AM, Phil Blundell wrote:
On Mon, 2013-04-29 at 15:54 +0100, Richard Purdie wrote:
On Mon, 2013-04-29 at 15:45 +0100, Paul Eggleton wrote:
Given that this is a departure from previously established behaviour, I do
think we need to give a more of an explanation in the commit m
"Burton, Ross" writes:
> rpm allows "executables" (but not libraries) to conflict and will
> prefer the 64-bit version,
Sure? At least rpm-4 (Fedora, RHEL) does not allow files to conflict.
Fedora solves the multilib problem by splitting the distribution into
main packages (unilib only; contain
On Thu, May 02, 2013 at 12:30:59PM -0400, Trevor Woerner wrote:
> On Thu, May 2, 2013 at 11:57 AM, Paul Barker wrote:
> > The recipe also has dependencies
> > outside meta-oe (fluidsynth in meta-multimedia IIRC) but that's a
> > separate issue.
>
> I've noticed that too. Shouldn't dependencies be
On Thu, May 2, 2013 at 6:40 PM, Andreas Müller
wrote:
> On Thu, May 2, 2013 at 5:53 PM, Mark Hatle wrote:
>>> [andreas@oe-core]$ bitbake -e gdm | grep ^PSEUDO_PASSWD
>>> PSEUDO_PASSWD="/home/andreas/tmp/oe-core-eglibc/sysroots/overo"
>>
>>
>> Check that path contains 'etc/passwd' and 'etc/group'.
On Wed, 2013-05-01 at 12:31 -0700, Saul Wold wrote:
> On 04/30/2013 05:30 AM, Andreas Müller wrote:
> > as discussed in [1-2]
> >
> > [1]
> > http://lists.linuxtogo.org/pipermail/openembedded-core/2013-April/039025.html
> > [2]
> > http://lists.linuxtogo.org/pipermail/openembedded-core/2013-April
On 5/2/13 11:10 AM, Burton, Ross wrote:
Hi all,
There were several issues being discussed here under the topic of
libexecdir, some simple and some less so. I'll ramble for a bit to
try and get a proper conclusion debated.
The situation where you have a 32-bit dropbear but a 64-bit openssh is
r
On Thu, May 02, 2013 at 05:11:28PM +0100, Burton, Ross wrote:
> On 2 May 2013 16:39, Martin Jansa wrote:
> >> -PV = "0.10+git${SRCPV}"
> >> +PV = "0.10+git${SRCREV}"
>
> As the git revision is the 0.10 tag, wouldn't it be clearer to not set
> PV as the git revision is a detail of the fetcher - th
On Thu, May 2, 2013 at 5:53 PM, Mark Hatle wrote:
> On 5/2/13 10:31 AM, Andreas Müller wrote:
>>
>> On Thu, May 2, 2013 at 5:18 PM, Andreas Müller
>> wrote:
>>>
>>> On Thu, May 2, 2013 at 5:09 PM, Mark Hatle
>>> wrote:
On 5/2/13 9:55 AM, Andreas Müller wrote:
>
>
> On Thu,
On Thu, May 2, 2013 at 11:57 AM, Paul Barker wrote:
> The recipe also has dependencies
> outside meta-oe (fluidsynth in meta-multimedia IIRC) but that's a
> separate issue.
I've noticed that too. Shouldn't dependencies be contained within the
same layer? Is it normal from these dependencies to be
On 2 May 2013 16:39, Martin Jansa wrote:
>> -PV = "0.10+git${SRCPV}"
>> +PV = "0.10+git${SRCREV}"
As the git revision is the 0.10 tag, wouldn't it be clearer to not set
PV as the git revision is a detail of the fetcher - this *is* 0.10.
Ross
___
Opene
Hi all,
There were several issues being discussed here under the topic of
libexecdir, some simple and some less so. I'll ramble for a bit to
try and get a proper conclusion debated.
The situation where you have a 32-bit dropbear but a 64-bit openssh is
rather pathological and I'd like to know if
On 2 May 2013 16:18, Martin Jansa wrote:
> meta-openembedded/meta-oe/recipes-multimedia/vlc/vlc_1.1.11.bb, do_package
I did have a potential fix for this, I'll take another look and see
what I can do about sending a patch. The recipe also has dependencies
outside meta-oe (fluidsynth in meta-mul
On 5/2/13 10:31 AM, Andreas Müller wrote:
On Thu, May 2, 2013 at 5:18 PM, Andreas Müller
wrote:
On Thu, May 2, 2013 at 5:09 PM, Mark Hatle wrote:
On 5/2/13 9:55 AM, Andreas Müller wrote:
On Thu, May 2, 2013 at 4:50 PM, Mark Hatle
wrote:
On 5/2/13 9:34 AM, Paul Eggleton wrote:
On Thurs
On 5/2/13 10:18 AM, Andreas Müller wrote:
On Thu, May 2, 2013 at 5:09 PM, Mark Hatle wrote:
On 5/2/13 9:55 AM, Andreas Müller wrote:
On Thu, May 2, 2013 at 4:50 PM, Mark Hatle
wrote:
On 5/2/13 9:34 AM, Paul Eggleton wrote:
On Thursday 02 May 2013 08:35:55 Mark Hatle wrote:
On 5/2/13
On Thu, May 02, 2013 at 05:56:32PM +0300, Jukka Rissanen wrote:
>
> Signed-off-by: Jukka Rissanen
> ---
> meta/recipes-connectivity/neard/neard_0.10.bb | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-connectivity/neard/neard_0.10.bb
> b/meta/recipes-connec
On 2 May 2013 16:28, Otavio Salvador wrote:
> This allow selection of following features:
>
> drm, egl, freetype2, gbm, gles1, gles2, glut, osmesa, vg, wayland, x11
>
> The x11 features is enabled depending on distro features but the
> wayland has not been enabled as it does not work with Wayland
On Thu, May 2, 2013 at 5:18 PM, Andreas Müller
wrote:
> On Thu, May 2, 2013 at 5:09 PM, Mark Hatle wrote:
>> On 5/2/13 9:55 AM, Andreas Müller wrote:
>>>
>>> On Thu, May 2, 2013 at 4:50 PM, Mark Hatle
>>> wrote:
On 5/2/13 9:34 AM, Paul Eggleton wrote:
>
>
> On Thursday 02 M
This allow selection of following features:
drm, egl, freetype2, gbm, gles1, gles2, glut, osmesa, vg, wayland, x11
The x11 features is enabled depending on distro features but the
wayland has not been enabled as it does not work with Wayland
1.0. Rest were enabled for a sane default.
Signed-off
On Thu, May 2, 2013 at 5:18 PM, Martin Jansa wrote:
> On Sat, Apr 27, 2013 at 12:54:00PM +0200, Martin Jansa wrote:
>> Updated status, but only change IIRC is fixed php, tbb,
>> android-audiosystem and partially fixed llvm2.9 (I'm testing patch to
>> fix build on qemuarm again)
>>
>> qemuarm Summa
On Sat, Apr 27, 2013 at 12:54:00PM +0200, Martin Jansa wrote:
> Updated status, but only change IIRC is fixed php, tbb,
> android-audiosystem and partially fixed llvm2.9 (I'm testing patch to
> fix build on qemuarm again)
>
> qemuarm Summary: 19 tasks failed:
> http://logs.nslu2-linux.org/buildlog
On Thu, May 2, 2013 at 5:09 PM, Mark Hatle wrote:
> On 5/2/13 9:55 AM, Andreas Müller wrote:
>>
>> On Thu, May 2, 2013 at 4:50 PM, Mark Hatle
>> wrote:
>>>
>>> On 5/2/13 9:34 AM, Paul Eggleton wrote:
On Thursday 02 May 2013 08:35:55 Mark Hatle wrote:
>
>
> On 5/2/13 2:4
On 23/02/2013 1:50 AM, Jack Mitchell wrote:
On 22/02/13 14:15, Jack Mitchell wrote:
On 22/02/13 09:22, Jack Mitchell wrote:
On 21/02/13 22:27, Khem Raj wrote:
On (14/02/13 15:44), Jack Mitchell wrote:
On 14/02/13 15:31, Burton, Ross wrote:
On 14 February 2013 14:31, Jack Mitchell
wrote:
Did
On 5/2/13 9:55 AM, Andreas Müller wrote:
On Thu, May 2, 2013 at 4:50 PM, Mark Hatle wrote:
On 5/2/13 9:34 AM, Paul Eggleton wrote:
On Thursday 02 May 2013 08:35:55 Mark Hatle wrote:
On 5/2/13 2:49 AM, Andreas Müller wrote:
on one of my build machines useradd.bbclass seem to use the UID/GI
On Thu, 2013-05-02 at 09:50 -0500, Mark Hatle wrote:
> On 5/2/13 9:34 AM, Paul Eggleton wrote:
> > On Thursday 02 May 2013 08:35:55 Mark Hatle wrote:
> >> On 5/2/13 2:49 AM, Andreas Müller wrote:
> >>> on one of my build machines useradd.bbclass seem to use the UID/GID of
> >>> build host. On other
On 15/04/2013 11:45 PM, Jack Mitchell wrote:
On 15/04/13 14:10, Martin Jansa wrote:
On Mon, Apr 15, 2013 at 01:58:52PM +0100, Jack Mitchell wrote:
Ok, I have just come back to trying out the new systemd implementation,
and this bug still exists.
Exactly the same error as before:
[2.390730
This way it is easier to override settings if needed.
Signed-off-by: Jukka Rissanen
---
meta/recipes-connectivity/neard/neard.inc | 59 ++
meta/recipes-connectivity/neard/neard_0.10.bb | 60 +--
2 files changed, 60 insertions(+), 59 deletions(-
Signed-off-by: Jukka Rissanen
---
meta/recipes-connectivity/neard/neard_0.10.bb | 69 +++
meta/recipes-connectivity/neard/neard_0.9.bb | 69 ---
2 files changed, 69 insertions(+), 69 deletions(-)
create mode 100644 meta/recipes-connectivity/neard
Signed-off-by: Jukka Rissanen
---
meta/recipes-connectivity/neard/neard_0.10.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-connectivity/neard/neard_0.10.bb
b/meta/recipes-connectivity/neard/neard_0.10.bb
index dc43f7e..b9198af 100644
--- a/meta/recipes-conn
Hi,
there was too many unrelated changes in my earlier patch so this one splits
it more.
Cheers,
Jukka
Jukka Rissanen (3):
neard: Rename the recipe as we are already in 0.10
neard: Use SRCREV instead of SRCPV
neard: Split recipe to two parts
meta/recipes-connectivity/neard/neard.inc
On Thu, May 2, 2013 at 4:50 PM, Mark Hatle wrote:
> On 5/2/13 9:34 AM, Paul Eggleton wrote:
>>
>> On Thursday 02 May 2013 08:35:55 Mark Hatle wrote:
>>>
>>> On 5/2/13 2:49 AM, Andreas Müller wrote:
on one of my build machines useradd.bbclass seem to use the UID/GID of
build host. On
On Thursday 02 May 2013 15:49:39 Richard Purdie wrote:
> On Thu, 2013-05-02 at 15:34 +0100, Paul Eggleton wrote:
> > Right, do_install will be well before this stuff happens and it is not a
> > fakeroot task anyway. This needs to be moved to a postinstall script
> > (which
> > should be able to run
On 5/2/13 9:34 AM, Paul Eggleton wrote:
On Thursday 02 May 2013 08:35:55 Mark Hatle wrote:
On 5/2/13 2:49 AM, Andreas Müller wrote:
on one of my build machines useradd.bbclass seem to use the UID/GID of
build host. On other machines useradd works correct.
I have the follwing in gdm:
do_insta
On Thu, 2013-05-02 at 15:34 +0100, Paul Eggleton wrote:
> On Thursday 02 May 2013 08:35:55 Mark Hatle wrote:
> > On 5/2/13 2:49 AM, Andreas Müller wrote:
> > > on one of my build machines useradd.bbclass seem to use the UID/GID of
> > > build host. On other machines useradd works correct.
> > >
>
On Thu, May 2, 2013 at 4:34 PM, Paul Eggleton
wrote:
> On Thursday 02 May 2013 08:35:55 Mark Hatle wrote:
>> On 5/2/13 2:49 AM, Andreas Müller wrote:
>> > on one of my build machines useradd.bbclass seem to use the UID/GID of
>> > build host. On other machines useradd works correct.
>> >
>> > I ha
On Thursday 02 May 2013 08:35:55 Mark Hatle wrote:
> On 5/2/13 2:49 AM, Andreas Müller wrote:
> > on one of my build machines useradd.bbclass seem to use the UID/GID of
> > build host. On other machines useradd works correct.
> >
> > I have the follwing in gdm:
> >
> >
> > do_install_append() {
This way it is easier to override settings if needed.
Signed-off-by: Jukka Rissanen
---
meta/recipes-connectivity/neard/neard.inc | 59 +++
meta/recipes-connectivity/neard/neard_0.10.bb | 11 +
meta/recipes-connectivity/neard/neard_0.9.bb | 69 ---
On 5/2/13 8:55 AM, Phil Blundell wrote:
Since 6775feb9fe935ab01fd9cae2b2d3fce5824a9a72 our local "copy" of the
debug sources has in fact been hardlinked to ${S} and potentially other
places too. This means that any modifications we make to these files
might have wider consequences than intended.
Since 6775feb9fe935ab01fd9cae2b2d3fce5824a9a72 our local "copy" of the
debug sources has in fact been hardlinked to ${S} and potentially other
places too. This means that any modifications we make to these files
might have wider consequences than intended.
Avoid this potential pitfall by telling
On 5/2/13 8:20 AM, Phil Blundell wrote:
These were introduced in 6021e309e69d823e1467648aee12a32182945569. The
code currently reads:
os.link(file, fpath)
fstat = cpath.stat(file)
os.chmod(fpath, fstat.st_mode)
os.chown(fpath, f
On 5/2/13 2:49 AM, Andreas Müller wrote:
Hi,
on one of my build machines useradd.bbclass seem to use the UID/GID of
build host. On other machines useradd works correct.
I have the follwing in gdm:
do_install_append() {
...
chown -R gdm:gdm ${D}${localstatedir}/lib/gdm
chmod 075
On 2 May 2013 14:16, Stuart Yoder wrote:
> It's just my observation that there seems to be a discrepancy between
> what is getting built and packaged. Things get built in ./lib and
> packaged from ./lib64.
It looks like yajl is hard-coding "lib" but presumably your machine
configuration wants t
Hi all,
Even a cursory search of github reveals that there are a growing number of
layers being worked on in the community that aren't currently listed in the OE
layer index. I don't think it would be right for us to just add all of these
in bulk as we don't necessarily have all the needed info
These were introduced in 6021e309e69d823e1467648aee12a32182945569. The
code currently reads:
os.link(file, fpath)
fstat = cpath.stat(file)
os.chmod(fpath, fstat.st_mode)
os.chown(fpath, fstat.st_uid, fstat.st_gid)
which can have no
yajl/libyajl is a dependeny I have for another package I'm trying to
build so I'm not touching the yajl recipe at all. In fact the
complete recipe is this:
-
DESCRIPTION = "Yet Another JSON Library - A Portable JSON parsing and serializat
LICENSE = "MIT"
LIC_FILES_
On Thu, 2013-05-02 at 13:54 +0100, Burton, Ross wrote:
> On 2 May 2013 13:19, Phil Blundell wrote:
> > If we didn't build libgomp then we won't have installed anything into
> > ${infodir} or ${libdir}/gcc/${TARGET_SYS}/${BINV}/finclude. Check
> > whether those directories exist before trying to r
On 2 May 2013 13:19, Phil Blundell wrote:
> If we didn't build libgomp then we won't have installed anything into
> ${infodir} or ${libdir}/gcc/${TARGET_SYS}/${BINV}/finclude. Check
> whether those directories exist before trying to remove them, else we
> will lose.
Isn't it neater to use rm -rf
If we didn't build libgomp then we won't have installed anything into
${infodir} or ${libdir}/gcc/${TARGET_SYS}/${BINV}/finclude. Check
whether those directories exist before trying to remove them, else we
will lose.
Signed-off-by: Phil Blundell
---
meta/recipes-devtools/gcc/gcc-configure-runti
On Thu, 2013-05-02 at 11:36 +0100, Paul Eggleton wrote:
> On Thursday 02 May 2013 11:16:30 Phil Blundell wrote:
> > On Wed, 2013-02-06 at 14:25 +0100, Martin Jansa wrote:
> > > * check also RSUGGESTS, RCONFLICTS, RPROVIDES, RREPLACES
> >
> > These are already checked by recipe_sanity.bbclass. The
On Thursday 02 May 2013 11:16:30 Phil Blundell wrote:
> On Wed, 2013-02-06 at 14:25 +0100, Martin Jansa wrote:
> > * check also RSUGGESTS, RCONFLICTS, RPROVIDES, RREPLACES
>
> These are already checked by recipe_sanity.bbclass. There's probably no
> need to check them again here.
recipe_sanity.b
On Wed, 2013-02-06 at 14:25 +0100, Martin Jansa wrote:
> * check also RSUGGESTS, RCONFLICTS, RPROVIDES, RREPLACES
These are already checked by recipe_sanity.bbclass. There's probably no
need to check them again here.
p.
___
Openembedded-core mailing
On Thursday 02 May 2013 10:24:10 Burton, Ross wrote:
> On 1 May 2013 20:11, Stuart Yoder wrote:
> >FILES_yajl="/usr/bin/* /usr/sbin/* /usr/lib64/yajl/* ...
> >
> > Ho do I get the yajl recipe to either a) build the files in lib64 or
> > b) package them from lib.
>
> Don't hard-code paths, in
On 1 May 2013 20:11, Stuart Yoder wrote:
>FILES_yajl="/usr/bin/* /usr/sbin/* /usr/lib64/yajl/* ...
>
> Ho do I get the yajl recipe to either a) build the files in lib64 or
> b) package them from lib.
Don't hard-code paths, instead use the symbols available in bitbake.conf:
FILES_yajl = "${bi
Hi,
on one of my build machines useradd.bbclass seem to use the UID/GID of
build host. On other machines useradd works correct.
I have the follwing in gdm:
do_install_append() {
...
chown -R gdm:gdm ${D}${localstatedir}/lib/gdm
chmod 0750 ${D}${localstatedir}/lib/gdm
}
...
USERADD
63 matches
Mail list logo