Re: [yocto] [meta-cgl][PATCH 0/2] cosmetic updates

2014-05-29 Thread Alexandru Vaduva
For the moment we are preparing a release for Enea Linux, and we are fully 
booked.
After the release we will try to make all the needed steps for the meta-cgl 
layer:
That means proper information about the layers, maintainers and put in place 
all the needed procedures.
All this information will be made publically available.

Thanks for your interest Joe, I personally agree with your suggestions, hope to 
continue the collaboration.


Alex

-Original Message-
From: Joe MacDonald [mailto:j...@deserted.net] 
Sent: Thursday, May 29, 2014 5:11 AM
To: Valentin Cobelea; Alexandru Vaduva
Cc: yocto@yoctoproject.org
Subject: [meta-cgl][PATCH 0/2] cosmetic updates

I'm just taking a look now at meta-cgl and gearing up to do some submissions to 
it.  I've been working from:

   git://git.enea.com/linux/meta-cgl

which hasn't seen much activity recently, but it seems to still be the 
authoritative source.  I apologize if I'm working from an out-of-date tree.

For starters, if I could make a request, any chance we could get the README 
file updated with instructions on where you'd like to see patches go, so I 
don't unnecessarily spam the list?  :-)

-J.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] [meta-cgl][PATCH 0/2] cosmetic updates

2014-05-29 Thread Joe MacDonald
Hey Alex,

On Thu, May 29, 2014 at 7:02 AM, Alexandru Vaduva
alexandru.vad...@enea.com wrote:
 For the moment we are preparing a release for Enea Linux, and we are fully 
 booked.
 After the release we will try to make all the needed steps for the meta-cgl 
 layer:
 That means proper information about the layers, maintainers and put in place 
 all the needed procedures.
 All this information will be made publically available.

 Thanks for your interest Joe, I personally agree with your suggestions, hope 
 to continue the collaboration.

Okay.  So should I interpret that to mean that you're not currently
interested in patches against the meta-cgl layer at
git://git.enea.com/linux/meta-cgl?  I understand the realities of
scheduling a release of a Linux distro, but if you are still able to
collect and discuss / merge changes, I'll continue to kick the tires a
bit.

-J.



 Alex

 -Original Message-
 From: Joe MacDonald [mailto:j...@deserted.net]
 Sent: Thursday, May 29, 2014 5:11 AM
 To: Valentin Cobelea; Alexandru Vaduva
 Cc: yocto@yoctoproject.org
 Subject: [meta-cgl][PATCH 0/2] cosmetic updates

 I'm just taking a look now at meta-cgl and gearing up to do some submissions 
 to it.  I've been working from:

git://git.enea.com/linux/meta-cgl

 which hasn't seen much activity recently, but it seems to still be the 
 authoritative source.  I apologize if I'm working from an out-of-date tree.

 For starters, if I could make a request, any chance we could get the README 
 file updated with instructions on where you'd like to see patches go, so I 
 don't unnecessarily spam the list?  :-)

 -J.



-- 
Joe MacDonald
:wq
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] [meta-oe][PATCH 1/2] dfu-util 0.7 recipe

2014-05-29 Thread Chris Morgan
dfu-util 0.7 is the latest release of dfu-util
From 0a85d88e93de1707aa9b7ee41065d8c3db0acd66 Mon Sep 17 00:00:00 2001
From: Chris Morgan chmor...@gmail.com
Date: Thu, 29 May 2014 08:35:25 -0400
Subject: [PATCH 1/2] dfu-util 0.7 recipe

dfu-util 0.7 is the latest release of dfu-util

Signed-off-by: Chris Morgan chmor...@gmail.com
---
 meta-oe/recipes-support/dfu-util/dfu-util_0.7.bb | 6 ++
 1 file changed, 6 insertions(+)
 create mode 100644 meta-oe/recipes-support/dfu-util/dfu-util_0.7.bb

diff --git a/meta-oe/recipes-support/dfu-util/dfu-util_0.7.bb b/meta-oe/recipes-support/dfu-util/dfu-util_0.7.bb
new file mode 100644
index 000..c4c030d
--- /dev/null
+++ b/meta-oe/recipes-support/dfu-util/dfu-util_0.7.bb
@@ -0,0 +1,6 @@
+require dfu-util.inc
+
+DEPENDS = libusb1
+
+SRC_URI[md5sum] = 56844020177d4db4c1ea2e926fe9d588
+SRC_URI[sha256sum] = f52a2a5489fbf9f3204a6ada05e0b47ee322e19d81c712e0c58a332d80ec3eab
-- 
1.9.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] [meta-oe][PATCH 2/2] Remove old dfu-util 0.1 recipe

2014-05-29 Thread Chris Morgan

From 573dc43515a41ade2d2cf1a5ebfbf8ec3701ea81 Mon Sep 17 00:00:00 2001
From: Chris Morgan chmor...@gmail.com
Date: Thu, 29 May 2014 08:36:37 -0400
Subject: [PATCH 2/2] Remove old dfu-util 0.1 recipe

Signed-off-by: Chris Morgan chmor...@gmail.com
---
 meta-oe/recipes-support/dfu-util/dfu-util_0.1.bb | 10 --
 1 file changed, 10 deletions(-)
 delete mode 100644 meta-oe/recipes-support/dfu-util/dfu-util_0.1.bb

diff --git a/meta-oe/recipes-support/dfu-util/dfu-util_0.1.bb b/meta-oe/recipes-support/dfu-util/dfu-util_0.1.bb
deleted file mode 100644
index b63d74d..000
--- a/meta-oe/recipes-support/dfu-util/dfu-util_0.1.bb
+++ /dev/null
@@ -1,10 +0,0 @@
-require dfu-util.inc
-
-PR = r1
-
-DEPENDS = virtual/libusb0 usbpath
-
-BBCLASSEXTEND = native
-
-SRC_URI[md5sum] = 454b931249d29e4a6c2a2ade17858490
-SRC_URI[sha256sum] = a27cc667be9b158fecf0ed066698e30eca0c0b3cd7a85aad2058d47ffe16f0e1
-- 
1.9.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] [meta-oe][PATCH 1/2] dfu-util 0.7 recipe

2014-05-29 Thread Gary Thomas

On 2014-05-29 06:46, Chris Morgan wrote:

dfu-util 0.7 is the latest release of dfu-util


These patches should be sent to the OpenEmbedded mailing list
  openembedded-de...@lists.openembedded.org

Also, check the README in your repository for details, in particular
the use of git send-mail for patches is preferred.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] [meta-oe][PATCH 1/2] dfu-util 0.7 recipe

2014-05-29 Thread Martin Jansa
On Thu, May 29, 2014 at 07:10:02AM -0600, Gary Thomas wrote:
 On 2014-05-29 06:46, Chris Morgan wrote:
  dfu-util 0.7 is the latest release of dfu-util
 
 These patches should be sent to the OpenEmbedded mailing list
openembedded-de...@lists.openembedded.org
 
 Also, check the README in your repository for details, in particular
 the use of git send-mail for patches is preferred.

And also please remove 0.1 and add 0.7 in the same commit which will be
easier to review if sent with -M.

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] [meta-oe][PATCH 1/2] dfu-util 0.7 recipe

2014-05-29 Thread Chris Morgan
On Thu, May 29, 2014 at 9:16 AM, Martin Jansa martin.ja...@gmail.com wrote:
 On Thu, May 29, 2014 at 07:10:02AM -0600, Gary Thomas wrote:
 On 2014-05-29 06:46, Chris Morgan wrote:
  dfu-util 0.7 is the latest release of dfu-util

 These patches should be sent to the OpenEmbedded mailing list
openembedded-de...@lists.openembedded.org

 Also, check the README in your repository for details, in particular
 the use of git send-mail for patches is preferred.

 And also please remove 0.1 and add 0.7 in the same commit which will be
 easier to review if sent with -M.

 --
 Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com

 --
 ___
 yocto mailing list
 yocto@yoctoproject.org
 https://lists.yoctoproject.org/listinfo/yocto


Thank you for the feedback. I'll get email setup to send through gmail
I guess so I can use the cli send mail. I guess I can use a pull
request instead though, that would let me avoid having to set git
gmail email up.


Today there are 0.1, 0.4/0.4 native and svn versions. I wanted removal
of 0.1 to be separate from adding 0.7 to avoid doing two things in a
single patch and so the 0.1 removal could be rejected separate from
adding 0.7.

If you really want the two together I can do that though, even though
they seem separate.

Maybe 0.4 should also be removed but I didn't want to have to replace
the native build of 0.4 with a native 0.7 build until other changes
were in and I wasn't sure how to test...

Chris
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] [meta-cgl][PATCH 0/2] cosmetic updates

2014-05-29 Thread Alexandru Vaduva
I am able to discuss patches and I already collected your patches, 
but unfortunately I cannot yet take any decision about them or 
about the next apps to be included and bugs to be fixed because 
those decisions will be taken after the Linux distro release (in a few days).


Alex

-Original Message-
From: Joe MacDonald [mailto:j...@deserted.net] 
Sent: Thursday, May 29, 2014 3:13 PM
To: Alexandru Vaduva
Cc: Valentin Cobelea; yocto@yoctoproject.org; Daniel Bornaz; Adrian Dudau; 
Maxin John
Subject: Re: [meta-cgl][PATCH 0/2] cosmetic updates

Hey Alex,

On Thu, May 29, 2014 at 7:02 AM, Alexandru Vaduva alexandru.vad...@enea.com 
wrote:
 For the moment we are preparing a release for Enea Linux, and we are fully 
 booked.
 After the release we will try to make all the needed steps for the meta-cgl 
 layer:
 That means proper information about the layers, maintainers and put in place 
 all the needed procedures.
 All this information will be made publically available.

 Thanks for your interest Joe, I personally agree with your suggestions, hope 
 to continue the collaboration.

Okay.  So should I interpret that to mean that you're not currently interested 
in patches against the meta-cgl layer at git://git.enea.com/linux/meta-cgl?  I 
understand the realities of scheduling a release of a Linux distro, but if you 
are still able to collect and discuss / merge changes, I'll continue to kick 
the tires a bit.

-J.



 Alex

 -Original Message-
 From: Joe MacDonald [mailto:j...@deserted.net]
 Sent: Thursday, May 29, 2014 5:11 AM
 To: Valentin Cobelea; Alexandru Vaduva
 Cc: yocto@yoctoproject.org
 Subject: [meta-cgl][PATCH 0/2] cosmetic updates

 I'm just taking a look now at meta-cgl and gearing up to do some submissions 
 to it.  I've been working from:

git://git.enea.com/linux/meta-cgl

 which hasn't seen much activity recently, but it seems to still be the 
 authoritative source.  I apologize if I'm working from an out-of-date tree.

 For starters, if I could make a request, any chance we could get the 
 README file updated with instructions on where you'd like to see 
 patches go, so I don't unnecessarily spam the list?  :-)

 -J.



--
Joe MacDonald
:wq
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] Yocto with Initial RamFS

2014-05-29 Thread Brian Smucker

Hi,

Was wondering why this has not been answered.  Maybe it is too dumb of a 
question? If so, let me know or point me to some documentation.


Thanks.

Brian

On 5/23/2014 11:37 AM, Brian Smucker wrote:

Hello,

I have an initial ramfs image that I want to convert to Yocto. That is 
in addition to the main yocto-based custom distro.


The initial ram fs is a tiny image based on uclibc (poky-tiny) and 
having busybox and two other compiled apps.  The main file system is 
eglibc-based.


How is this sort of thing typically done in the Yocto world? Since the 
toolchain is totally different for the initial ramfs, do I need to 
have another distro and totally different directory for creating the 
initialramfs, giving two different distros and yocto directories?  Or 
can I somehow do it under the umbrella of one Yocto distro?


I would like some feedback on how this should be done.

Thanks,

Brian


--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] Yocto with Initial RamFS

2014-05-29 Thread Søren Holm
Torsdag den 29. maj 2014 08:07:11 skrev Brian Smucker:
 Hi,
 
 Was wondering why this has not been answered.  Maybe it is too dumb of a
 question? If so, let me know or point me to some documentation.
 

I'm declaring an initramfs-image like this. As you can see the recipe is 
derived from core-image-minimal-initramfs. The package initramfs-vm provides 
the script /init executed on boot.

The assembling of the actual bootable image with initramfs and rootfs (in my 
case a squashfs) is done in another script.


# initramfs for vm-image. Derived from core-image-minimal-initramfs
DESCRIPTION = Small image capable of booting a a squashfs+aufs filesystem

IMAGE_INSTALL = initramfs-vm-boot busybox udev base-passwd

# Do not pollute the initrd image with rootfs features
IMAGE_FEATURES = 
IMAGE_LINGUAS = 
#DISTRO_FEATURES = 

inherit core-image

IMAGE_FSTYPES = cpio

IMAGE_PREPROCESS_COMMAND = cb16_remote_bloat;

cb16_remote_bloat() {
rm -r ${IMAGE_ROOTFS}/boot
}


-- 
Søren Holm
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] Yocto with Initial RamFS

2014-05-29 Thread Brian Smucker

Thanks Soren,

My followup question is: Can I mix toolchains in this situation?

Can I compile the initramfs binaries with the uclibc toolchain based on 
the poky-tiny distro and the regular file system binaries with the 
glibc-based toolchain (based on a different distro)?


If this is possible, how would I begin to do it?

Thanks,

Brian

On 5/29/2014 8:38 AM, Søren Holm wrote:

Torsdag den 29. maj 2014 08:07:11 skrev Brian Smucker:

Hi,

Was wondering why this has not been answered.  Maybe it is too dumb of a
question? If so, let me know or point me to some documentation.


I'm declaring an initramfs-image like this. As you can see the recipe is
derived from core-image-minimal-initramfs. The package initramfs-vm provides
the script /init executed on boot.

The assembling of the actual bootable image with initramfs and rootfs (in my
case a squashfs) is done in another script.


# initramfs for vm-image. Derived from core-image-minimal-initramfs
DESCRIPTION = Small image capable of booting a a squashfs+aufs filesystem

IMAGE_INSTALL = initramfs-vm-boot busybox udev base-passwd

# Do not pollute the initrd image with rootfs features
IMAGE_FEATURES = 
IMAGE_LINGUAS = 
#DISTRO_FEATURES = 

inherit core-image

IMAGE_FSTYPES = cpio

IMAGE_PREPROCESS_COMMAND = cb16_remote_bloat;

cb16_remote_bloat() {
 rm -r ${IMAGE_ROOTFS}/boot
}




--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] HEADS-UP: Master now has GCC 4.9 as default

2014-05-29 Thread Saul Wold


Folks,

We have been testing with GCC 4.9 in master_under_test for sometime now 
and it's been passing local testing and sanity testing on the 
autobuilder.  Since we have the final fix for a PPC ICE issue in place 
now, we are moving to GCC 4.9 as the default in master for the 1.7 release.


Please be aware if this if you find some package failing unexpectedly.

Thanks to Khem and other for this effort!

--
Sau!

Saul Wold
Yocto Component Wrangler @ Intel
Yocto Project / Poky Build System

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] Yocto with Initial RamFS

2014-05-29 Thread Søren Holm
Torsdag den 29. maj 2014 09:49:55 skrev Brian Smucker:
 Thanks Soren,
 
 My followup question is: Can I mix toolchains in this situation?
 
 Can I compile the initramfs binaries with the uclibc toolchain based on
 the poky-tiny distro and the regular file system binaries with the
 glibc-based toolchain (based on a different distro)?
 
 If this is possible, how would I begin to do it?

I don't know, but I've got a simmilar need. Basically I was a very minimal 
busybox-static for the initramfs, but a full-fledged version for the main 
rootfs. I guess that's somehow the same thing.

Maybe you have an idea on how to do that?

 
-- 
Søren Holm
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] Yocto with Initial RamFS

2014-05-29 Thread Brian Smucker

On 5/29/2014 12:38 PM, Søren Holm wrote:

Torsdag den 29. maj 2014 09:49:55 skrev Brian Smucker:

Thanks Soren,

My followup question is: Can I mix toolchains in this situation?

Can I compile the initramfs binaries with the uclibc toolchain based on
the poky-tiny distro and the regular file system binaries with the
glibc-based toolchain (based on a different distro)?

If this is possible, how would I begin to do it?

I don't know, but I've got a simmilar need. Basically I was a very minimal
busybox-static for the initramfs, but a full-fledged version for the main
rootfs. I guess that's somehow the same thing.

Maybe you have an idea on how to do that?

I don't know. I'm somewhat of a newbie here.

It seems this type of requirement should not be unusual in the embedded 
space.


Am hoping others can weigh in on this.

Thanks,

Brian
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] Yocto with Initial RamFS

2014-05-29 Thread Khem Raj
On Thu, May 29, 2014 at 9:49 AM, Brian Smucker b...@bsmucker.eu.org wrote:
 My followup question is: Can I mix toolchains in this situation?


No, not easily. Although you can see if klibc is an option for you.
meta-initramfs has support for that

 Can I compile the initramfs binaries with the uclibc toolchain based on the
 poky-tiny distro and the regular file system binaries with the glibc-based
 toolchain (based on a different distro)?

 If this is possible, how would I begin to do it?

 T
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] (no subject)

2014-05-29 Thread Kashyap Gada
Hello Community,
This is my first question please excuse if I'm making a silly mistake. I am
just starting learning the yocto project to develop custom linux os. I was
following the few commands to download and setup poky on my build system
from the quick start guide at .

$ git clone http://git.yoctoproject.org/git/poky
 $ cd poky
 $ git checkout -b daisy origin/daisy
 $ source oe-init-build-env

Executing the last line gives me the following issue


kashyap@Kashyap-VAIO:/media/kashyap/3E0800DC08009555/yocto/poky$ ls

 bitbakemeta-selftest   oe-init-build-env scripts

 documentation  meta-skeleton   oe-init-build-env-memres

 LICENSEmeta-yocto  README

 meta   meta-yocto-bsp  README.hardware

 kashyap@Kashyap-VAIO:/media/kashyap/3E0800DC08009555/yocto/poky$ source
 oe-init-build-env

 bash:
 /media/kashyap/3E0800DC08009555/yocto/poky/scripts/oe-setup-builddir:
 Permission denied

 kashyap@Kashyap-VAIO:/media/kashyap/3E0800DC08009555/yocto/poky$



I tried searching over the internet about the possible issues but couldn't
figure out the problem here.
Anyone please help.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] Source Command Permission Denied

2014-05-29 Thread Kashyap Gada
Hello Community,
This is my first question please excuse if I'm making a silly mistake. I am
just starting learning the yocto project to develop custom linux os. I was
following the few commands to download and setup poky on my build system
from the quick start guide at .

$ git clone http://git.yoctoproject.org/git/poky
 $ cd poky
 $ git checkout -b daisy origin/daisy
 $ source oe-init-build-env

Executing the last line gives me the following issue


kashyap@Kashyap-VAIO:/media/kashyap/3E0800DC08009555/yocto/poky$ ls

 bitbakemeta-selftest   oe-init-build-env scripts

 documentation  meta-skeleton   oe-init-build-env-memres

 LICENSEmeta-yocto  README

 meta   meta-yocto-bsp  README.hardware

 kashyap@Kashyap-VAIO:/media/kashyap/3E0800DC08009555/yocto/poky$ source
 oe-init-build-env

 bash:
 /media/kashyap/3E0800DC08009555/yocto/poky/scripts/oe-setup-builddir:
 Permission denied

 kashyap@Kashyap-VAIO:/media/kashyap/3E0800DC08009555/yocto/poky$



I tried searching over the internet about the possible issues but couldn't
figure out the problem here.
Anyone please help.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] [PATCH 1/3] SingleBranchScheduler: check each repo but not only the first one

2014-05-29 Thread Yin Kangkai
On 2014-05-20, 10:15 +0800, Yin Kangkai wrote:
 [up post intentionally]
 
 I was trying to setup yocto-autobuilder in my local env, and customize
 it to my needs (i.e. watch git/gerrit event and only build my
 images). It is a little bit of struggle for me to make it finally work
 (due to the fact I am little knowledge to both buildbot and python.)
 
 Anyway, these several patches are needed in my setup. Please review
 and considering merge.
 
 If this is not the right mailing list, please let me know. Thanks.

Sorry, any response on this patch set?

 On 2014-05-20, 10:16 +0800, Yin Kangkai wrote:
  Without this patch, when you set a SingleBranchScheduler scheduler,
  code will only check against the first repo in repos list. e.g.:
 ...
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] [PATCH 1/3] SingleBranchScheduler: check each repo but not only the first one

2014-05-29 Thread Flanagan, Elizabeth
Sorry Yin, I've been backlogged. I have it in my preproduction test
setup. I should pull tomorrow if all goes well.

-b

On Thu, May 29, 2014 at 9:09 PM, Yin Kangkai kangkai@intel.com wrote:
 On 2014-05-20, 10:15 +0800, Yin Kangkai wrote:
 [up post intentionally]

 I was trying to setup yocto-autobuilder in my local env, and customize
 it to my needs (i.e. watch git/gerrit event and only build my
 images). It is a little bit of struggle for me to make it finally work
 (due to the fact I am little knowledge to both buildbot and python.)

 Anyway, these several patches are needed in my setup. Please review
 and considering merge.

 If this is not the right mailing list, please let me know. Thanks.

 Sorry, any response on this patch set?

 On 2014-05-20, 10:16 +0800, Yin Kangkai wrote:
  Without this patch, when you set a SingleBranchScheduler scheduler,
  code will only check against the first repo in repos list. e.g.:
 ...



-- 
Elizabeth Flanagan
Yocto Project
Build and Release
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto