Systemtap now works with arm, so include it in task-core-tools-profile
for qemuarm.
Signed-off-by: Tom Zanussi
---
meta/recipes-core/tasks/task-core-tools.bb |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/tasks/task-core-tools.bb
b/meta/recipes-cor
Also enable for arm, since systemtap now works on arm and remove the
gcc-4.6 compile fix patch since the problems it addresses have been
fixed upstream.
Signed-off-by: Tom Zanussi
---
.../fix_for_compilation_with_gcc-4.6.0.patch | 119
meta/recipes-kernel/systemtap/sy
This patchset upgrades systemtap to 1.6. The 1.6 version of
systemtap also has improved support for arm, so this also
enables it for arm and adds it to qemuarm.
This upgrade was successfully tested on qemux86, qemux86-64,
qemuppc, qemuarm, and sugarbay. The results and the tests
can be found at
Fixes [YOCTO #940]
Since v3.0.4 is likely the last stable update in the the release
timeframe a configuration audit was performed. This updates the
SRCREV to remove obselete, and improperly defined configuration
items. With this, all qemu* BSPs configure with no warnings.
Signed-off-by: Bruce Ash
The v3.0.4 stable kernel is available and it can now be merged
into linux-yocto. Build and boot tested on all qemu* machines.
Signed-off-by: Bruce Ashfield
---
meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb |6 +++---
meta/recipes-kernel/linux/linux-yocto_3.0.bb| 16
Richard/Saul,
This took a bit longer than I wanted (this was intended for Thursday), but
since this was potentially the last minor rev bump for yocto 1.1, I wanted
to build and boot all of the qemu targets, and the -rt targets as well.
While doing this, I noticed that there were still some lurk
After constructing a kernel configuration file it then needs
to be located in the tree so it can be audited against the
final .config. The previous string that was used for the search
pattern contains the kernel version. If the recipe space kernel
version and internal tree version are out of sync,
If the wrapper script needs to build pseudo before we can launch hob we need
to notify the user so they aren't shocked by the action of launching a GUI
and seeing a bunch of text whiz by on the console.
Fixes [YOCTO #1435]
Signed-off-by: Joshua Lock
---
scripts/hob |5 +
1 files changed
hob now uses both a pre and post file, update the wrapper script to generate
and use both of these.
Addresses [YOCTO #1281]
Signed-off-by: Joshua Lock
---
scripts/hob | 20 +++-
1 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/scripts/hob b/scripts/hob
index 199
This series adapts the wrapper script to provide 2 configuration files, as
required by the patch series I just sent to the BitBake list, and warns the
user that the UI may not be shown immediately if pseudo may need building.
Regards,
Joshua
The following changes since commit 6b5706d1f9ce7a3fd4d8
On 9/2/11 1:43 PM, Phil Blundell wrote:
> On Fri, 2011-09-02 at 15:03 +0100, Richard Purdie wrote:
>> Seriously, does opkg have the logic in it to run this stuff? If so
>> perhaps we need to teach opkg about offline postinstalls since it should
>> already know about dependencies?
>
> Yeah, that mi
On Fri, 2011-09-02 at 17:21 +0200, Paul Menzel wrote:
> Am Freitag, den 02.09.2011, 14:19 +0100 schrieb Richard Purdie:
> > I do find the split useful...
>
> Hmm, could you please elaborate?
Not that I'm Richard, but I do find the split useful as well.
Personally I am much less interested in the
On Fri, 2011-09-02 at 15:03 +0100, Richard Purdie wrote:
> Seriously, does opkg have the logic in it to run this stuff? If so
> perhaps we need to teach opkg about offline postinstalls since it should
> already know about dependencies?
Yeah, that might be a sensible plan. I'm not entirely sure th
Hi Koen,
I thought of doing this, I just didn't know if it would be acceptable
and if there was a cleaner way of extending a .bbclass
Thanks,
Joel
On Fri, Sep 2, 2011 at 11:00 AM, Koen Kooi wrote:
> Why not start with
>
> echo "inherit image" >> mynewclass.bbclass
>
> And have the image inherit
On Fri, 2011-09-02 at 14:35 -0300, Otavio Salvador wrote:
> On Fri, Sep 2, 2011 at 13:47, Richard Purdie
> wrote:
> > On Fri, 2011-09-02 at 10:53 -0300, Otavio Salvador wrote:
> >> On Fri, Sep 2, 2011 at 10:33, Koen Kooi wrote:
> >> > That sounds like people should just subscribe to oe-core if th
On Fri, Sep 2, 2011 at 14:00, Richard Purdie wrote:
...
>> Hmm, could you please elaborate?
>
> We all try to find ways to make our workflows more efficient and to do
> the best job we can at the things we attempt. The mailing list
> separation actively helps me notice the most important things I
On Fri, Sep 2, 2011 at 13:47, Richard Purdie
wrote:
> On Fri, 2011-09-02 at 10:53 -0300, Otavio Salvador wrote:
>> On Fri, Sep 2, 2011 at 10:33, Koen Kooi wrote:
>> > That sounds like people should just subscribe to oe-core if they want to
>> > be aware of changes instead of merging the 2 lists.
On Thu, 2011-09-01 at 12:36 +0100, Paul Eggleton wrote:
> This variable should be split with \n sequences and these need to be
> specified literally in the string. A corrected version of the example
> given in the original commit (OE-core rev
> 75e3875341ddc8940e9ee2ccbbb2ec18194a68e6):
>
> SANITY
On Thu, 2011-09-01 at 16:03 +0100, Phil Blundell wrote:
> Otherwise the class doesn't work if ${bindir} is set to a different value;
> likewise for /var vs ${localstatedir}.
>
> Signed-off-by: Phil Blundell
> ---
> meta/classes/useradd.bbclass |4 ++--
> 1 files changed, 2 insertions(+), 2 d
On Fri, 2011-09-02 at 09:08 +0200, Koen Kooi wrote:
> Signed-off-by: Koen Kooi
> ---
> meta/recipes-core/dropbear/dropbear/dropbear |4
> .../dropbear/dropbear-configuration-file.patch | 18 ++
> 2 files changed, 22 insertions(+), 0 deletions(-)
> create mode
On Fri, 2011-09-02 at 17:03 +0800, Dongxiao Xu wrote:
> Hi Richard,
>
> This pull request fixes several multilib bugs.
> Please help to review and pull.
>
> Thanks,
> Dongxiao
>
>
> The following changes since commit 06625096f897235ed85f0d9a1355497f92938454:
>
> scripts: Don't show errors fr
On Thu, 2011-09-01 at 16:31 -0700, Saul Wold wrote:
> Richard,
>
> I bumped the PV to 0.(n+1)+git* instead of creating a PE entry,
> the other grouping it to ensure they get repackged against the
> version names.
>
> TZ* update is general updates.
>
> Thanks
> Sau!
>
> The following chang
On Thu, 2011-09-01 at 15:25 -0700, Joshua Lock wrote:
> We rename readprofile to readprofile.util-linux so we need to use that binary
> name in the FILES entry for the readprofile package.
>
> Signed-off-by: Joshua Lock
> ---
> meta/recipes-core/util-linux/util-linux.inc |2 +-
> meta/
On Fri, 2011-09-02 at 17:21 +0200, Paul Menzel wrote:
> Am Freitag, den 02.09.2011, 14:19 +0100 schrieb Richard Purdie:
> > On Fri, 2011-09-02 at 10:05 -0300, Otavio Salvador wrote:
> > > On Fri, Sep 2, 2011 at 08:25, Paul Menzel wrote:
>
> > > > it would be great if we could join the lists oe-dev
On Fri, 2011-09-02 at 10:53 -0300, Otavio Salvador wrote:
> On Fri, Sep 2, 2011 at 10:33, Koen Kooi wrote:
> > That sounds like people should just subscribe to oe-core if they want to be
> > aware of changes instead of merging the 2 lists.
>
> Many times changes are related to meta-oe and oe-cor
Without that commit ubinize.cfg lack a volume name value,
and the related ubinize.cfg line looks like that:
vol_name=
which result in a broken ubi image,which after beeing flashed produce
the following error:
UBI error: vtbl_check: volume table check failed: record 0, error 11
wich
Without that commit ubinize.cfg lack a volume name value,
and the related ubinize.cfg line looks like that:
vol_name=
which result in a broken ubi image,which after beeing flashed produce
the following error:
UBI error: vtbl_check: volume table check failed: record 0, error 11
wich
Why not start with
echo "inherit image" >> mynewclass.bbclass
And have the image inherit mynewclass?
Op 2 sep. 2011, om 17:44 heeft Joel A Fernandes het volgende geschreven:
>
>
> On Tue, Aug 30, 2011 at 12:47 PM, Koen Kooi
> wrote:
> >
> > Op 30 aug. 2011, om 18:46 heeft Jason Kridner het
On Tue, Aug 30, 2011 at 12:47 PM, Koen Kooi
wrote:
>
> Op 30 aug. 2011, om 18:46 heeft Jason Kridner het volgende geschreven:
>
>> On Mon, Aug 29, 2011 at 7:08 PM, Joel A Fernandes
wrote:
>>> On Mon, Aug 29, 2011 at 4:03 PM, Jason Kridner
wrote:
>>>
>>> This script is BSP specific and sh
On Aug 31, 2011, at 12:06 AM, Kumar Gala wrote:
>
> On Jul 28, 2011, at 8:10 AM, Kumar Gala wrote:
>
>> 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_EX
On Aug 25, 2011, at 9:35 AM, Kumar Gala wrote:
> We have some packages like flac that are aware of vectorization that may or
> may not exist on a given processor. I was wondering if adding something like
> TARGET_VECTOR similar to TARGET_FPU made sense as a way for recipes to decide
> on how
mtd-utils 1.4.6 is the lastest release of mtd-utils
at this time.
Signed-off-by: Denis Carikli
---
.../add-exclusion-to-mkfs-jffs2-git-2.patch|0
.../add-exclusion-to-mkfs-jffs2-git-2.patch|0
.../mtd/{mtd-utils_1.4.1.bb => mtd-utils_1.4.6.bb} |7 ++-
3 files ch
mtd-utils 1.4.6 is the lastest release of mtd-utils
at this time.
Signed-off-by: Denis Carikli
---
.../add-exclusion-to-mkfs-jffs2-git-2.patch|0
.../mtd/{mtd-utils_1.4.1.bb => mtd-utils_1.4.6.bb} |3 ---
2 files changed, 0 insertions(+), 3 deletions(-)
rename meta/recipes-dev
mtd-utils 1.4.6 is the lastest release of mtd-utils
at this time.
Signed-off-by: Denis Carikli
---
.../add-exclusion-to-mkfs-jffs2-git-2.patch| 103
.../add-exclusion-to-mkfs-jffs2-git-2.patch| 103
meta/recipes-devtools/mtd/mtd-utils
On Fri, 2011-09-02 at 10:50 +0100, Phil Blundell wrote:
> On Thu, 2011-09-01 at 22:59 +0100, Richard Purdie wrote:
> > The latter sounds like what we'll need to do. I haven't looked at shadow
> > to see what kind of finessing is required though...
>
> Fixing the immediate problem with shadow turne
On Fri, 2011-09-02 at 15:38 +0200, Denis Carikli wrote:
> mtd-utils 1.4.6 is the lastest release of mtd-utils
> at this time.
>
> Signed-off-by: Denis Carikli
> ---
> .../add-exclusion-to-mkfs-jffs2-git-2.patch|0
> .../mtd/{mtd-utils_1.4.1.bb => mtd-utils_1.4.6.bb} |3 ---
> 2
On Fri, Sep 2, 2011 at 10:33, Koen Kooi wrote:
> That sounds like people should just subscribe to oe-core if they want to be
> aware of changes instead of merging the 2 lists.
Many times changes are related to meta-oe and oe-core and we'd need to
cross-post and seems wrong.
--
Otavio Salvador
Hi Koen,
Thanks for writing things down.
On Fri, 2011-09-02 at 13:01 +0200, Koen Kooi wrote:
> This has come up in the past, but no one has had time to site down and
> write a proposal yet.
>
> Problem description: The OE-core layer has both too much in it and not
> enough.
>
> Currently OE-cor
Op 2 sep. 2011, om 15:23 heeft Otavio Salvador het volgende geschreven:
> On Fri, Sep 2, 2011 at 10:19, Richard Purdie
> wrote:
>>> I fully support this merge.
>>
>> I'm not so sure rushing into this is a great idea. Speaking as someone
>> who has problems trying to figure out where patches are
On Fri, Sep 2, 2011 at 10:19, Richard Purdie
wrote:
>> I fully support this merge.
>
> I'm not so sure rushing into this is a great idea. Speaking as someone
> who has problems trying to figure out where patches are intended for and
> who tracks whether they've been applied, I do find the split us
On Fri, 2011-09-02 at 10:05 -0300, Otavio Salvador wrote:
> On Fri, Sep 2, 2011 at 08:25, Paul Menzel
> wrote:
> > Dear OE folks,
> >
> >
> > it would be great if we could join the lists oe-devel and oe-core again.
> > As far as I know the only reason the list oe-core was created was to
> > discus
Commit 35fa8dc5f7da90fdd40091a3c3600d3fcd232922 changed the gcc recipes to use
baselib for the compiler location. This is fine as long as baselib happens to
match the platform multilib definition which is enabled at the time.
This patch fixes things so that gcc will honour whatever ${base_libdir}
On Fri, Sep 2, 2011 at 08:25, Paul Menzel
wrote:
> Dear OE folks,
>
>
> it would be great if we could join the lists oe-devel and oe-core again.
> As far as I know the only reason the list oe-core was created was to
> discuss the initial setup and the creation of oe-core. Now that it has
> been se
For a given system we only want one kernel to be built. This change makes
the main kernel recipe provide all of the provides of the various enabled
multilibs hence allowing it to fulfil all the appropriate dependencies.
To make this work a global multilib class file needed to be created.
This pat
Hi,
This has come up in the past, but no one has had time to site down and write a
proposal yet.
Problem description: The OE-core layer has both too much in it and not enough.
Currently OE-core is basically a relabeling of the poky fork of OE. Due to that
heritage is has bits in it that aren't
On Thu, 2011-09-01 at 22:59 +0100, Richard Purdie wrote:
> The latter sounds like what we'll need to do. I haven't looked at shadow
> to see what kind of finessing is required though...
Fixing the immediate problem with shadow turned out to be rather
straightforward, see attached. However, with t
Thinking of the senario that, if we already built out a 64bit image
along with the full toolchain bootstrapped, then we need to build some
32bit libraries, which needs lib32 versions of gcc and eglibc. These
toolchain recipes will bootstrap again in the same sysroot, resulting
that lib32-gcc-cross-
Hi Richard,
This pull request fixes several multilib bugs.
Please help to review and pull.
Thanks,
Dongxiao
The following changes since commit 06625096f897235ed85f0d9a1355497f92938454:
scripts: Don't show errors from which ifconfig failing (2011-09-01 20:49:44
+0100)
are available in the g
Kernel in a Linux system shouldn't be multilib, thus setting NO_MULTILIB
flag for kernel.bbclass. Besides if other recipes have dependency on
virtual/kernel or kernel-module-*, we don't extend name for them.
Some part of the commit is derived from Ke's prototype in:
http://bugzilla.pokylinux.org/s
hal has runtime dependency on kernel, but not build time. Remove it from
"DEPENDS" list.
Also fix a wrong PACKAGE_ARCH setting when building multilib lib32-hal,
because ":=" will be extended immediately which is not the right value.
Using TUNE_PKGARCH instead.
Signed-off-by: Dongxiao Xu
---
met
libsdl is required by sato image, so extend it for multilib.
Signed-off-by: Dongxiao Xu
---
meta/conf/multilib.conf |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/meta/conf/multilib.conf b/meta/conf/multilib.conf
index 5329eda..62bdfec 100644
--- a/meta/conf/multilib.co
To get the MULTILIB_PACKAGE_ARCHS, we need to get the corresponding
DEFAULTTUNE value. This fixes the multilib arch directory missing issue
in solvedb-ml_archs.conf.
Signed-off-by: Dongxiao Xu
---
meta/classes/rootfs_rpm.bbclass |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff
On Thu, 2011-09-01 at 22:59 +0100, Richard Purdie wrote:
> The latter sounds like what we'll need to do. I haven't looked at shadow
> to see what kind of finessing is required though...
>
> Does opkg have any notion of bitbake's ASSUME_PROVIDED?
Not explicitly, but the same mechanism that we use
Signed-off-by: Koen Kooi
---
meta/recipes-core/dropbear/dropbear/dropbear |4
.../dropbear/dropbear-configuration-file.patch | 18 ++
2 files changed, 22 insertions(+), 0 deletions(-)
create mode 100644 meta/recipes-core/dropbear/dropbear/dropbear
create mod
54 matches
Mail list logo
