Hi Laszlo,
Maybe adding more information will make the case for it.
For example, the fact that is used in a lot of OSS.
A very good demo of the possibilities of FLTK is Giada, "A Hardcore Loop
Machine"
http://www.giadamusic.com/
In my opinion, it is one of the best looking apps written using FL
Fixes QA warnings like
WARNING: QA Issue: binutils: Files/directories were installed but not
shipped
/usr/bin/ld.bfd
/usr/bin/dwp
Signed-off-by: Khem Raj
Acked-by: Martin Jansa
---
meta/recipes-devtools/binutils/binutils.inc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --g
Define the SourcePlugin class, which is the class that should be
subclassed to create a 'source' plugin.
'Source' plugins provide a mechanism to customize various aspects of
the image generation process in wic, mainly the contents of
partitions.
The initial version of wic defined a --source param
Implement the BootimgPcbiosPlugin and BootimgEFIPlugin SourcePlugin
classes. The configure/prepare_partition() methods are implemented
using code derived from similar code in the Wic_PartData class.
These classes have the corresponding names 'bootimg-pcbios' and
'bootimg-efi', which are the names
Remove all the Wic_PartData and DirectImageCreator code now
implemented by the BootimgEFIPlugin and BootimgPcbiosPlugin plugins,
as well as all the special-cased boot_type code, significantly
cleaning up the code.
Replace the calling code with general-purpose plugin invocations, in
essence calling
Add a new wic-specific bootloader subclass so we can add a --source
param to hang non-partition plugin off of.
By default, the bootloader gets the /boot partition source plugin, but
this can be overridden by the --source bootloader param if needed.
Signed-off-by: Tom Zanussi
---
scripts/lib/mic
Hook up the existing --debug option to toggle the wic debug loglevel,
which is indispensible when things go wrong, and make it easy to use
from the command-line.
Signed-off-by: Tom Zanussi
---
scripts/lib/image/engine.py | 5 -
scripts/wic | 11 +++
2 files changed,
Add get_bitbake_var() and bitbake_env_lines() functions for use by
plugins, which will need access to them for customization.
Signed-off-by: Tom Zanussi
---
scripts/lib/image/engine.py | 20 +++-
scripts/lib/mic/utils/oe/misc.py | 16
scripts/wic
Move a couple items into a more common location since they're going to
need to be accessible from source plugins.
Signed-off-by: Tom Zanussi
---
scripts/lib/image/engine.py| 11 ---
scripts/lib/mic/kickstart/custom_commands/partition.py | 2 --
scripts/lib/mi
This patchset implements wic 'source plugins', basically a generalization
of the existing --source params to wic .wks commands.
The following changes since commit 358dd840c53e2e69e668a6d5da04eb3da3769ba3:
sstate-cache-management.sh: don't remove all packagedata sstate archives
(2014-02-02 11:3
On Mon, 2014-02-03 at 22:23 +0100, Ulf Samuelsson wrote:
> 1 feb 2014 kl. 10:21 skrev Mike Looijmans :
>
> > On 01/29/2014 01:56 PM, Richard Purdie wrote:
> >> On Wed, 2014-01-29 at 13:09 +0100, Ulf Samuelsson wrote:
> If bitbakes can track the loading of the CPU, then maybe some parts
> in the la
1 feb 2014 kl. 10:21 skrev Mike Looijmans :
> On 01/29/2014 01:56 PM, Richard Purdie wrote:
>> On Wed, 2014-01-29 at 13:09 +0100, Ulf Samuelsson wrote:
>>> We discussed this 2.3 months ago.
>>> Did some studies on my dual hex-core machine (24 H/W treads) while
>>> building a cloud9-gnome-image d
Changelog since 2014-01-26 until 2014-02-02. Projects included in this report:
bitbake: git://git.openembedded.org/bitbake
openembedded-core: git://git.openembedded.org/openembedded-core
meta-openembedded: git://git.openembedded.org/meta-openembedded
meta-angstrom: git://github.com/Angstrom-distr
Hello,
These patches add the ability to export and run tests outside of the build.
As tests used to query values from the data storage this exports parts of d
and makes them avaiable in a json file, so tests don't need to change to
make them exportable. Tests exported are the ones defined in TEST_
This script will run the exported tests outside of the build system.
Simplest way to test this is with a qemu image that you manually start.
For an already build image use this in local.conf:
TEST_EXPORT_ONLY = "1"
TEST_TARGET = "simpleremote"
TEST_TARGET_IP = "192.168.7.2"
TEST_SERVER_IP = "192.1
When running tests outside of the build system we can't use
bb.fetch anymore. It was nice but tests and their modules
need to rely on the data storage only as that gets exported.
This module is used by the oeqa/runtime/build* tests.
Signed-off-by: Stefan Stanacar
---
meta/lib/oeqa/utils/targetbu
Add the ability to export the tests so that they can run independently of
the build system, as is required if you want to be able to hand the test
execution off to a scheduler.
Booting/deployment of the target is still handled by the build system,
as before, only the execution of the tests happens
On Mon, Feb 03, 2014 at 07:50:03PM +0100, Kristof Robot wrote:
> On Sat, Jan 11, 2014 at 4:08 PM, Andrei Gherzan wrote:
> > Avoid a confusion when including thumb in TUNE_FATURES. In the curent
> > behavior,
> > if I include thumb in TUNE_FATURES, ARM_THUMB_M_OPT will be "-marm" which
> > makes
On Mon, Feb 03, 2014 at 06:38:45PM +0100, Martin Jansa wrote:
> On Mon, Feb 03, 2014 at 09:27:44AM -0800, Khem Raj wrote:
> > On Mon, Feb 3, 2014 at 6:31 AM, Martin Jansa wrote:
> > > Hi Khem,
> > >
> > > can you please check following QA warning:
> > >
> > > NOTE: recipe binutils-2.24-r0: task do
On Sat, Jan 11, 2014 at 4:08 PM, Andrei Gherzan wrote:
> Avoid a confusion when including thumb in TUNE_FATURES. In the curent
> behavior,
> if I include thumb in TUNE_FATURES, ARM_THUMB_M_OPT will be "-marm" which
> makes
> no sense for me as a default behavior.
I agree that this is confusing,
Hi,
I'm using dora and have recently adopted Icecream to speed up my build
times. Unfortunately, icecc.bbclass breaks with the pslash recipe in a
way that is not easily worked around.
The problem has already been fixed in master, though:
icecc: Add dummy python version of set_icecc_env
On Sun, Feb 2, 2014 at 10:19 AM, Phil Blundell wrote:
> This helper script is used only during development and is not generally
> useful on the target. Inherit lib_package to move it to a different
> package from the libraries.
>
> Signed-off-by: Phil Blundell
Did you check if it provides an up
On Mon, Feb 03, 2014 at 09:27:44AM -0800, Khem Raj wrote:
> On Mon, Feb 3, 2014 at 6:31 AM, Martin Jansa wrote:
> > Hi Khem,
> >
> > can you please check following QA warning:
> >
> > NOTE: recipe binutils-2.24-r0: task do_package: Started
> > WARNING: QA Issue: binutils: Files/directories were in
On Mon, Feb 3, 2014 at 6:31 AM, Martin Jansa wrote:
> Hi Khem,
>
> can you please check following QA warning:
>
> NOTE: recipe binutils-2.24-r0: task do_package: Started
> WARNING: QA Issue: binutils: Files/directories were installed but not shipped
> /usr/bin/ld.bfd
> /usr/bin/dwp
> NOTE: rec
On Monday 03 February 2014 08:49:36 Khem Raj wrote:
> On Mon, Feb 3, 2014 at 4:03 AM, Paul Eggleton
> wrote:
> > I see this series has been merged at last - great! Could you also send
> > Scott some information about documentation changes that we should have
> > for this?
>
> I will send another p
On Mon, Feb 3, 2014 at 4:03 AM, Paul Eggleton
wrote:
> Hi Khem,
>
> On Wednesday 29 January 2014 20:12:24 Khem Raj wrote:
>> Post V5
>>
>> Upgrade to 3.3.3
>
> I see this series has been merged at last - great! Could you also send Scott
> some information about documentation changes that we should
On Mon, Feb 03, 2014 at 03:32:49PM +0100, David Nyström wrote:
> On 2014-02-03 12:38, Laurentiu Palcu wrote:
> >Hi all,
> >
>
> Have you tested that BUILD_IMAGES_FROM_FEEDS functionality is not
> broken by these commits ?
No, I did not test this. I tried to test it on master though and it
doesn't
On Sat, Feb 1, 2014 at 9:02 AM, Richard Purdie
wrote:
> On Thu, 2014-01-30 at 18:46 +, Laszlo Papp wrote:
>> Ping?
>>
>> I asked this a bit more than five months ago. Shall I take it as "No"?
>
> The lack of responses does indicate that its not something there is
> strong support for so I don'
Hello,
I am adding OE-Core and Yocto mailing list as destination as this has
fixes for both.
While setting a build system, in a very clean host installation I
found some issues which were fixed in master and ought to be
backported to Dora:
meta-yocto:
- 1893d1576c1e7acc9881b3392a838c575019f18d
On 2014-02-03 12:38, Laurentiu Palcu wrote:
Hi all,
Have you tested that BUILD_IMAGES_FROM_FEEDS functionality is not broken
by these commits ?
Br,
David
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.ope
On Sun, Feb 02, 2014 at 10:32:58PM +, g...@git.openembedded.org wrote:
> Module: openembedded-core.git
> Branch: master
> Commit: 015eca84f1b0f25868b47d2480bb60cea698f70e
> URL:
> http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=015eca84f1b0f25868b47d2480bb60cea698f70e
>
> A
On Mon, Feb 03, 2014 at 02:21:26PM +0100, David Nyström wrote:
> On mån 3 feb 2014 14:03:47, Paul Eggleton wrote:
> > Hi David,
> >
> > On Monday 03 February 2014 13:58:49 David Nyström wrote:
> >> An intended fix for below error message with core-image-lsb,
> >> Sending this as an RFC since I don
On mån 3 feb 2014 14:43:53, Phil Blundell wrote:
On Mon, 2014-02-03 at 13:58 +0100, David Nyström wrote:
An intended fix for below error message with core-image-lsb,
Sending this as an RFC since I dont really know what constitutes
a RRECOMMENDS vs. RDEPENDS.
Is this clearly defined somewhere ?
On Mon, 2014-02-03 at 13:58 +0100, David Nyström wrote:
> An intended fix for below error message with core-image-lsb,
> Sending this as an RFC since I dont really know what constitutes
> a RRECOMMENDS vs. RDEPENDS.
> Is this clearly defined somewhere ?
> Below should be an RDEPENDS, no ?
>
> I
On mån 3 feb 2014 14:03:47, Paul Eggleton wrote:
Hi David,
On Monday 03 February 2014 13:58:49 David Nyström wrote:
An intended fix for below error message with core-image-lsb,
Sending this as an RFC since I dont really know what constitutes
a RRECOMMENDS vs. RDEPENDS.
Is this clearly defined
Hi David,
On Monday 03 February 2014 13:58:49 David Nyström wrote:
> An intended fix for below error message with core-image-lsb,
> Sending this as an RFC since I dont really know what constitutes
> a RRECOMMENDS vs. RDEPENDS.
> Is this clearly defined somewhere ?
> Below should be an RDEPENDS, no
An intended fix for below error message with core-image-lsb,
Sending this as an RFC since I dont really know what constitutes
a RRECOMMENDS vs. RDEPENDS.
Is this clearly defined somewhere ?
Below should be an RDEPENDS, no ?
INIT: version 2.88 booting
Starting udev
udevd[59]: starting version 18
Hi Khem,
On Wednesday 29 January 2014 20:12:24 Khem Raj wrote:
> Post V5
>
> Upgrade to 3.3.3
I see this series has been merged at last - great! Could you also send Scott
some information about documentation changes that we should have for this?
Thanks,
Paul
--
Paul Eggleton
Intel Open Sour
This update will add improvements to HOB,
fix issues encountered during build.
Fixes [YOCTO #5759].
Signed-off-by: Cristian Iorga
---
meta/recipes-core/images/build-appliance-image_8.0.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/images/build-applianc
The following changes since commit b37dd451a52622d5b570183a81583cc34c2ff555:
rootfs_ipk: Ensure that BAD_RECOMMENDATIONS are honoured for all
architectures (2014-02-02 22:37:42 +)
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib ciorga/YB5759
http://git.
Hi,
At FOSDEM last weekend I ran into Paul Barker and we chatted about our
wishlists for package management. One of the items on my lists was drop in
postinst scriplets. I've been working on support for the dracut initramfs
generator in Angstrom and I have it working. In contrast to the current
41 matches
Mail list logo
