[linux-yocto] [PATCH 2/3] yaffs2: NULL ->read/->write

[Kevin Hao]

As stated in commit 5d5d56897530 ("make new_sync_{read,write}() static"),
we shouldn't use new_sync_{read_write} for ->read/->write. We should
NULL ->read/->write with non-NULL ->{read,write}_iter will do the
right thing.

Signed-off-by: Kevin Hao 
---
 fs/yaffs2/yaffs_vfs.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/fs/yaffs2/yaffs_vfs.c b/fs/yaffs2/yaffs_vfs.c
index fbbf313..0a3e9da 100644
--- a/fs/yaffs2/yaffs_vfs.c
+++ b/fs/yaffs2/yaffs_vfs.c
@@ -794,8 +794,6 @@ static int yaffs_sync_object(struct file *file, struct 
dentry *dentry,
 
 #if (LINUX_VERSION_CODE > KERNEL_VERSION(2, 6, 22))
 static const struct file_operations yaffs_file_operations = {
-   .read = new_sync_read,
-   .write = new_sync_write,
.read_iter = generic_file_read_iter,
.write_iter = generic_file_write_iter,
.mmap = generic_file_mmap,
-- 
1.9.1

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

[linux-yocto] [PATCH 3/3] yaffs2: using new ->follow_link() and ->put_link() calling conventions

[Kevin Hao]

As what we did in commit 680baacbca69 ("new ->follow_link() and
->put_link() calling conventions").

Signed-off-by: Kevin Hao 
---
 fs/yaffs2/yaffs_vfs.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/fs/yaffs2/yaffs_vfs.c b/fs/yaffs2/yaffs_vfs.c
index 0a3e9da..1494c8f 100644
--- a/fs/yaffs2/yaffs_vfs.c
+++ b/fs/yaffs2/yaffs_vfs.c
@@ -1060,7 +1060,7 @@ static int yaffs_readlink(struct dentry *dentry, char 
__user * buffer,
 }
 
 #if (YAFFS_NEW_FOLLOW_LINK == 1)
-static void *yaffs_follow_link(struct dentry *dentry, struct nameidata *nd)
+static const char *yaffs_follow_link(struct dentry *dentry, void **cookie)
 {
void *ret;
 #else
@@ -1082,7 +1082,7 @@ static int yaffs_follow_link(struct dentry *dentry, 
struct nameidata *nd)
goto out;
}
 #if (YAFFS_NEW_FOLLOW_LINK == 1)
-   nd_set_link(nd, alias);
+   *cookie = alias;
ret = alias;
 out:
if (ret_int)
@@ -1114,9 +1114,9 @@ static void yaffs_put_inode(struct inode *inode)
 #endif
 
 #if (YAFFS_NEW_FOLLOW_LINK == 1)
-void yaffs_put_link(struct dentry *dentry, struct nameidata *nd, void *alias)
+void yaffs_put_link(struct inode *inode, void *cookie)
 {
-   kfree(alias);
+   kfree(cookie);
 }
 #endif
 
-- 
1.9.1

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

[linux-yocto] [PATCH 1/3] yaffs2: replace f_dentry to f_path.dentry

[Kevin Hao]

From: Yang Shi 

Upstream commit 78d28e651f97866d608d9b41f8ad291e65d47dd5 ("kill f_dentry macro")
removed f_dentry from struct file, so replace it to f_path.dentry to fix the
build failure.

Signed-off-by: Yang Shi 
Signed-off-by: Bruce Ashfield 
---
This is picked from linux-yocto 4.1.

 fs/yaffs2/yaffs_vfs.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/fs/yaffs2/yaffs_vfs.c b/fs/yaffs2/yaffs_vfs.c
index a84e57e..fbbf313 100644
--- a/fs/yaffs2/yaffs_vfs.c
+++ b/fs/yaffs2/yaffs_vfs.c
@@ -274,7 +274,7 @@ static int yaffs_readpage_nolock(struct file *f, struct 
page *pg)
(long long)pos,
(unsigned)PAGE_CACHE_SIZE);
 
-   obj = yaffs_dentry_to_obj(f->f_dentry);
+   obj = yaffs_dentry_to_obj(f->f_path.dentry);
 
dev = obj->my_dev;
 
@@ -472,7 +472,7 @@ static ssize_t yaffs_hold_space(struct file *f)
 
int n_free_chunks;
 
-   obj = yaffs_dentry_to_obj(f->f_dentry);
+   obj = yaffs_dentry_to_obj(f->f_path.dentry);
 
dev = obj->my_dev;
 
@@ -490,7 +490,7 @@ static void yaffs_release_space(struct file *f)
struct yaffs_obj *obj;
struct yaffs_dev *dev;
 
-   obj = yaffs_dentry_to_obj(f->f_dentry);
+   obj = yaffs_dentry_to_obj(f->f_path.dentry);
 
dev = obj->my_dev;
 
@@ -582,7 +582,7 @@ static ssize_t yaffs_file_write(struct file *f, const char 
*buf, size_t n,
struct inode *inode;
struct yaffs_dev *dev;
 
-   obj = yaffs_dentry_to_obj(f->f_dentry);
+   obj = yaffs_dentry_to_obj(f->f_path.dentry);
 
if (!obj) {
yaffs_trace(YAFFS_TRACE_OS,
@@ -594,7 +594,7 @@ static ssize_t yaffs_file_write(struct file *f, const char 
*buf, size_t n,
 
yaffs_gross_lock(dev);
 
-   inode = f->f_dentry->d_inode;
+   inode = f->f_path.dentry->d_inode;
 
if (!S_ISBLK(inode->i_mode) && f->f_flags & O_APPEND)
ipos = inode->i_size;
@@ -745,7 +745,7 @@ static int yaffs_file_flush(struct file *file, fl_owner_t 
id)
 static int yaffs_file_flush(struct file *file)
 #endif
 {
-   struct yaffs_obj *obj = yaffs_dentry_to_obj(file->f_dentry);
+   struct yaffs_obj *obj = yaffs_dentry_to_obj(file->f_path.dentry);
 
struct yaffs_dev *dev = obj->my_dev;
 
@@ -1712,14 +1712,14 @@ static int yaffs_readdir(struct file *file, struct 
dir_context *ctx)
struct yaffs_obj *obj;
struct yaffs_dev *dev;
struct yaffs_search_context *sc;
-   struct inode *inode = file->f_dentry->d_inode;
+   struct inode *inode = file->f_path.dentry->d_inode;
unsigned long offset, curoffs;
struct yaffs_obj *l;
int ret_val = 0;
 
char name[YAFFS_MAX_NAME_LENGTH + 1];
 
-   obj = yaffs_dentry_to_obj(file->f_dentry);
+   obj = yaffs_dentry_to_obj(file->f_path.dentry);
dev = obj->my_dev;
 
yaffs_gross_lock(dev);
@@ -1753,7 +1753,7 @@ static int yaffs_readdir(struct file *file, struct 
dir_context *ctx)
if (offset == 1) {
yaffs_trace(YAFFS_TRACE_OS,
"yaffs_readdir: entry .. ino %d",
-   (int)file->f_dentry->d_parent->d_inode->i_ino);
+   (int)file->f_path.dentry->d_parent->d_inode->i_ino);
yaffs_gross_unlock(dev);
if (!dir_emit_dotdot(file, ctx)) {
yaffs_gross_lock(dev);
@@ -1815,14 +1815,14 @@ static int yaffs_readdir(struct file *f, void *dirent, 
filldir_t filldir)
struct yaffs_obj *obj;
struct yaffs_dev *dev;
struct yaffs_search_context *sc;
-   struct inode *inode = f->f_dentry->d_inode;
+   struct inode *inode = f->f_path.dentry->d_inode;
unsigned long offset, curoffs;
struct yaffs_obj *l;
int ret_val = 0;
 
char name[YAFFS_MAX_NAME_LENGTH + 1];
 
-   obj = yaffs_dentry_to_obj(f->f_dentry);
+   obj = yaffs_dentry_to_obj(f->f_path.dentry);
dev = obj->my_dev;
 
yaffs_gross_lock(dev);
@@ -1856,10 +1856,10 @@ static int yaffs_readdir(struct file *f, void *dirent, 
filldir_t filldir)
if (offset == 1) {
yaffs_trace(YAFFS_TRACE_OS,
"yaffs_readdir: entry .. ino %d",
-   (int)f->f_dentry->d_parent->d_inode->i_ino);
+   (int)f->f_path.dentry->d_parent->d_inode->i_ino);
yaffs_gross_unlock(dev);
if (filldir(dirent, "..", 2, offset,
-   f->f_dentry->d_parent->d_inode->i_ino,
+   f->f_path.dentry->d_parent->d_inode->i_ino,
DT_DIR) < 0) {
yaffs_gross_lock(dev);
goto out;
-- 
1.9.1

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org

[linux-yocto] [PATCH 0/3] linux-yocto 4.4: fix the build errors when yaffs2 is enabled

[Kevin Hao]

Hi,

With these patches applied, we can use a yaffs2 rootfs on mpc8315e-rdb board:
  root@mpc8315e-rdb:~# cat /proc/version 
  Linux version 4.4.1-yocto-standard (khao@pek-lpggp4) (gcc version 5.3.0 (GCC) 
) #2 PREEMPT Wed Feb 24 10:30:40 CST 2016
  root@mpc8315e-rdb:~# cat /proc/cmdline
  root=/dev/mtdblock3 rootfstype=yaffs2 console=ttyS0,115200
  root@mpc8315e-rdb:~# mount
  /dev/root on / type yaffs2 (rw,relatime)

Kevin Hao (2):
  yaffs2: NULL ->read/->write
  yaffs2: using new ->follow_link() and ->put_link() calling conventions

Yang Shi (1):
  yaffs2: replace f_dentry to f_path.dentry

 fs/yaffs2/yaffs_vfs.c | 36 +---
 1 file changed, 17 insertions(+), 19 deletions(-)

-- 
1.9.1

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

Re: [yocto] [meta-raspberrypi][PATCH] linux-raspberrypi: Adjust for libexecdir changes

[Khem Raj]

> On Feb 23, 2016, at 4:37 PM, Andreas Müller  
> wrote:
> 
> On Tue, Feb 23, 2016 at 10:02 PM, Anders Darander  
> wrote:
>> Ping?
>> 
>> We can't build on master branch without this fix...
>> 
>> Cheers,
>> Anders
>> 
>> * Khem Raj  [160130 18:07]:
>> 
>>> libexecdir has changed its location in latest OE core, it used to be
>>> pointing to /usr/lib which was essentially same as libdir and when
>>> hardcoded in do_rpiboot_mkimage it worked.
>> 
>>> Fixes kernel build failures e.g.
>> 
>>> DEBUG: Executing shell function do_rpiboot_mkimage
>>> /a/builder/mnt/build-oe/tmp-musl/work/raspberrypi2-oe-linux-musleabi/linux-raspberrypi/1_4.1.10+gitAUTOINC+b74df9228c-r0/temp/run.do_rpiboot_mkimage.5543:
>>> line 111:
>>> /a/builder/mnt/build-oe/tmp-musl/sysroots/x86_64-linux/usr/lib/rpi-mkimage/mkknlimg:
>>>  No such file or directory
>> 
>>> Signed-off-by: Khem Raj 
>>> ---
>>> recipes-kernel/linux/linux-raspberrypi.inc | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>>> diff --git a/recipes-kernel/linux/linux-raspberrypi.inc 
>>> b/recipes-kernel/linux/linux-raspberrypi.inc
>>> index 70e8bfe..0798788 100644
>>> --- a/recipes-kernel/linux/linux-raspberrypi.inc
>>> +++ b/recipes-kernel/linux/linux-raspberrypi.inc
>>> @@ -60,7 +60,7 @@ do_rpiboot_mkimage() {
>>> if test "x${KERNEL_IMAGETYPE}" != "xuImage" ; then
>>> if test -n "${KERNEL_DEVICETREE}"; then
>>> # Add RPi bootloader trailer to kernel image to enable 
>>> DeviceTree support
>>> -${STAGING_DIR_NATIVE}/usr/lib/rpi-mkimage/mkknlimg --dtok 
>>> ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}
>>> +${STAGING_DIR_NATIVE}${libexecdir}/mkknlimg --dtok 
>>> ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}
>>> fi
>>> fi
>>> }
>> --
>> Anders Darander, Senior System Architect
>> ChargeStorm AB / eStorm AB
>> --
> This patch is mandatory but there was a serial with additional fixes
> send by Maciej Borzecki on Feb 2nd. I think this is worth taken into
> account.

You can try to use github.com/kraj/meta-raspberrypi kraj/master
I plan to test out more and more pending submissions on that branch

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



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[linux-yocto] FW: [PATCH] iwlwifi: mvm: don't allow sched scans without matches to be started

[Zheng, Wu]

Hi,

Can the maintainer of linux-yocto have a look for the patch?

Any comments?
Thanks.

Best Regards
Zheng Wu

>-Original Message-
>From: Zheng, Wu
>Sent: Friday, February 19, 2016 2:36 PM
>To: linux-yocto@yoctoproject.org
>Cc: Zheng, Wu ; Coelho, Luciano
>; Grumbach, Emmanuel
>
>Subject: [PATCH] iwlwifi: mvm: don't allow sched scans without matches to be
>started
>
>The firmware can perform a scheduled scan with not matchsets passed, but it
>can't send notification that results were found.  Since the userspace then
>cannot know when we got new results and the firmware wouldn't trigger a wake
>in case we are sleeping, it's better not to allow scans without matchsets.
>
>This fixes https://bugzilla.kernel.org/show_bug.cgi?id=110831
>
>upstream status: in the process of merging
>
>Signed-off-by: Luca Coelho 
>Signed-off-by: Emmanuel Grumbach 
>Signed-off-by: Wu Zheng 
>---
> drivers/net/wireless/iwlwifi/mvm/mac80211.c | 4 
> 1 file changed, 4 insertions(+)
>
>diff --git a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
>b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
>index 9779c1e..90e8b66 100644
>--- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
>+++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
>@@ -2797,6 +2797,10 @@ static int iwl_mvm_mac_sched_scan_start(struct
>ieee80211_hw *hw,
>   struct iwl_mvm *mvm = IWL_MAC80211_GET_MVM(hw);
>   int ret;
>
>+  /* we don't support "match all" in the firmware */
>+  if (!req->n_match_sets)
>+  return -EOPNOTSUPP;
>+
>   if (!(mvm->fw->ucode_capa.capa[0] &
>IWL_UCODE_TLV_CAPA_UMAC_SCAN)) {
>   ret = iwl_mvm_cancel_scan_wait_notif(mvm, IWL_MVM_SCAN_OS);
>   if (ret)
>--
>2.1.4

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

Re: [yocto] Does CVE-2015-7547 affect eglibc?

[akuster808]

On 02/23/2016 02:52 PM, Darcy Watkins wrote:
> On Tue, 2016-02-23 at 13:51 -0800, Mark Hatle wrote:
>> On 2/23/16 1:53 PM, Khem Raj wrote:
>>> On Tue, Feb 23, 2016 at 2:25 PM, Darcy Watkins
 CVE-2015-7547 glibc vulnerability has been published as affecting glibc
 since ver 2.9 (fixed in 2.23 and patched in 2.22 and 2.21).

 Anyone know if we need the same security fixes in eglibc?
>>>
>>> yes you do. Eglibc was nothing but glibc+few fixes.
>>
>> Yes this affects all eglibc version 2.9 and newer up to glibc 2.23.
>>
>> As far as I'm aware, this affects all Yocto Project versions up to 2.0.
> 
> I will be interested in knowing which Yocto Project versions will
> receive the fixes. 

Master, 2.0 and 1.8 all have the fixes.
How far back do we go in matters like this?

1.7 (dizzy) I plan on doing soon. beyond that I do not know. those are
all community supported.

- armin
> 
> Thanks in advance!
> 
>> (The patch referenced by the security announcement applies to all of the
>> versions of glibc I've needed to apply it to for my customers.  A few 
>> per-line
>> tweaks might be necessary, but it was fairly easy.)
> 
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] [PATCH 0/7] clkdev: Backport some clkdev API from 4.4, for linux-yocto-4.1

[Yong, Jonathan]

Sorry for the spam, looks like Bruce already got these.

-Original Message-
From: Yong, Jonathan 
Sent: Wednesday, February 24, 2016 08:10
To: linux-yocto@yoctoproject.org
Cc: Yong, Jonathan 
Subject: [PATCH 0/7] clkdev: Backport some clkdev API from 4.4, for 
linux-yocto-4.1

Hello Linux-yocto,

We would want to use the same clkdev API for our drivers against bleeding
edge kernel versions. These patches are already upstream and should apply
cleanly against linux-yocto-4.1 standard/base.

Thanks.

[Resent: Seems to be missing from archive]

Russell King (7):
  clkdev: use clk_hw internally
  clkdev: drop __init from clkdev_add_table()
  clkdev: const-ify connection id to clk_add_alias()
  clkdev: add clkdev_create() helper
  clkdev: fix clk_add_alias() with a NULL alias device name
  clk: update clk API documentation to clarify clk_round_rate()
  clkdev: get rid of redundant clk_add_alias() prototype in linux/clk.h

 arch/arm/mach-davinci/da850.c|  1 +
 arch/arm/mach-omap1/board-nokia770.c |  2 +-
 arch/arm/mach-pxa/eseries.c  |  1 +
 arch/arm/mach-pxa/lubbock.c  |  1 +
 arch/arm/mach-pxa/tosa.c |  1 +
 drivers/clk/clkdev.c | 84 ++--
 include/linux/clk.h  | 27 ++--
 include/linux/clkdev.h   |  6 ++-
 8 files changed, 85 insertions(+), 38 deletions(-)

-- 
2.4.10

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

[linux-yocto] [PATCH 6/7] clk: update clk API documentation to clarify clk_round_rate()

[Yong, Jonathan]

From: Russell King 

The idea is that rate = clk_round_rate(clk, r) is equivalent to:

clk_set_rate(clk, r);
rate = clk_get_rate(clk);

except that clk_round_rate() does not change the hardware in any way.

Signed-off-by: Russell King 
(cherry picked from commit d2d14a77886485310ec66e575f00ea5232ac7a14)
Signed-off-by: Yong, Jonathan 
---
 include/linux/clk.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/include/linux/clk.h b/include/linux/clk.h
index 68c16a6..cafb22d 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -306,6 +306,20 @@ void devm_clk_put(struct device *dev, struct clk *clk);
  * @clk: clock source
  * @rate: desired clock rate in Hz
  *
+ * This answers the question "if I were to pass @rate to clk_set_rate(),
+ * what clock rate would I end up with?" without changing the hardware
+ * in any way.  In other words:
+ *
+ *   rate = clk_round_rate(clk, r);
+ *
+ * and:
+ *
+ *   clk_set_rate(clk, r);
+ *   rate = clk_get_rate(clk);
+ *
+ * are equivalent except the former does not modify the clock hardware
+ * in any way.
+ *
  * Returns rounded clock rate in Hz, or negative errno.
  */
 long clk_round_rate(struct clk *clk, unsigned long rate);
-- 
2.4.10

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

[linux-yocto] [PATCH 7/7] clkdev: get rid of redundant clk_add_alias() prototype in linux/clk.h

[Yong, Jonathan]

From: Russell King 

clk_add_alias() is provided by clkdev, and is not part of the clk API.
Howver, it is prototyped in two locations: linux/clkdev.h and
linux/clk.h.  This is a mess.  Get rid of the redundant and unnecessary
version in linux/clk.h.

Acked-by: Tony Lindgren 
Tested-by: Robert Jarzmik 
Acked-by: Sekhar Nori 
Signed-off-by: Russell King 
(cherry picked from commit 2d34e507293102f29ee94d9a9c5b890696d42452)
Signed-off-by: Yong, Jonathan 
---
 arch/arm/mach-davinci/da850.c|  1 +
 arch/arm/mach-omap1/board-nokia770.c |  2 +-
 arch/arm/mach-pxa/eseries.c  |  1 +
 arch/arm/mach-pxa/lubbock.c  |  1 +
 arch/arm/mach-pxa/tosa.c |  1 +
 include/linux/clk.h  | 13 -
 6 files changed, 5 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 45ce065..3b8740c 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -11,6 +11,7 @@
  * is licensed "as is" without any warranty of any kind, whether express
  * or implied.
  */
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-omap1/board-nokia770.c 
b/arch/arm/mach-omap1/board-nokia770.c
index 85089d8..3bc5939 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -7,6 +7,7 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
+#include 
 #include 
 #include 
 #include 
@@ -14,7 +15,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
diff --git a/arch/arm/mach-pxa/eseries.c b/arch/arm/mach-pxa/eseries.c
index cfb8641..4427bf2 100644
--- a/arch/arm/mach-pxa/eseries.c
+++ b/arch/arm/mach-pxa/eseries.c
@@ -10,6 +10,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-pxa/lubbock.c b/arch/arm/mach-pxa/lubbock.c
index 4ac9ab8..7518310 100644
--- a/arch/arm/mach-pxa/lubbock.c
+++ b/arch/arm/mach-pxa/lubbock.c
@@ -11,6 +11,7 @@
  *  it under the terms of the GNU General Public License version 2 as
  *  published by the Free Software Foundation.
  */
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-pxa/tosa.c b/arch/arm/mach-pxa/tosa.c
index 7780d1fa..92e56d8 100644
--- a/arch/arm/mach-pxa/tosa.c
+++ b/arch/arm/mach-pxa/tosa.c
@@ -12,6 +12,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
diff --git a/include/linux/clk.h b/include/linux/clk.h
index cafb22d..0df4a51 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -485,19 +485,6 @@ static inline void clk_disable_unprepare(struct clk *clk)
clk_unprepare(clk);
 }
 
-/**
- * clk_add_alias - add a new clock alias
- * @alias: name for clock alias
- * @alias_dev_name: device name
- * @id: platform specific clock name
- * @dev: device
- *
- * Allows using generic clock names for drivers by adding a new alias.
- * Assumes clkdev, see clkdev.h for more info.
- */
-int clk_add_alias(const char *alias, const char *alias_dev_name, char *id,
-   struct device *dev);
-
 struct device_node;
 struct of_phandle_args;
 
-- 
2.4.10

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

[linux-yocto] [PATCH 1/7] clkdev: use clk_hw internally

[Yong, Jonathan]

From: Russell King 

clk_add_alias() calls clk_get() followed by clk_put() but in between
those two calls it saves away the struct clk pointer to a clk_lookup
structure. This leaves the 'clk' member of the clk_lookup pointing at
freed memory on configurations where CONFIG_COMMON_CLK=y. This is a
problem because clk_get_sys() will eventually try to dereference the
freed pointer by calling __clk_get_hw() on it. Fix this by saving away
the struct clk_hw pointer instead of the struct clk pointer so that when
we try to create a per-user struct clk in clk_get_sys() we don't
dereference a junk pointer.

Signed-off-by: Russell King 
(cherry picked from commit d5622a9c13752be46e6fcde9d31391ce0bb0598b)
Signed-off-by: Yong, Jonathan 
---
 drivers/clk/clkdev.c   | 24 
 include/linux/clkdev.h |  1 +
 2 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 1fcb6ef..1bb120a 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -177,7 +177,7 @@ struct clk *clk_get_sys(const char *dev_id, const char 
*con_id)
if (!cl)
goto out;
 
-   clk = __clk_create_clk(__clk_get_hw(cl->clk), dev_id, con_id);
+   clk = __clk_create_clk(cl->clk_hw, dev_id, con_id);
if (IS_ERR(clk))
goto out;
 
@@ -215,18 +215,26 @@ void clk_put(struct clk *clk)
 }
 EXPORT_SYMBOL(clk_put);
 
-void clkdev_add(struct clk_lookup *cl)
+static void __clkdev_add(struct clk_lookup *cl)
 {
mutex_lock(_mutex);
list_add_tail(>node, );
mutex_unlock(_mutex);
 }
+
+void clkdev_add(struct clk_lookup *cl)
+{
+   if (!cl->clk_hw)
+   cl->clk_hw = __clk_get_hw(cl->clk);
+   __clkdev_add(cl);
+}
 EXPORT_SYMBOL(clkdev_add);
 
 void __init clkdev_add_table(struct clk_lookup *cl, size_t num)
 {
mutex_lock(_mutex);
while (num--) {
+   cl->clk_hw = __clk_get_hw(cl->clk);
list_add_tail(>node, );
cl++;
}
@@ -243,7 +251,7 @@ struct clk_lookup_alloc {
 };
 
 static struct clk_lookup * __init_refok
-vclkdev_alloc(struct clk *clk, const char *con_id, const char *dev_fmt,
+vclkdev_alloc(struct clk_hw *hw, const char *con_id, const char *dev_fmt,
va_list ap)
 {
struct clk_lookup_alloc *cla;
@@ -252,7 +260,7 @@ vclkdev_alloc(struct clk *clk, const char *con_id, const 
char *dev_fmt,
if (!cla)
return NULL;
 
-   cla->cl.clk = clk;
+   cla->cl.clk_hw = hw;
if (con_id) {
strlcpy(cla->con_id, con_id, sizeof(cla->con_id));
cla->cl.con_id = cla->con_id;
@@ -273,7 +281,7 @@ clkdev_alloc(struct clk *clk, const char *con_id, const 
char *dev_fmt, ...)
va_list ap;
 
va_start(ap, dev_fmt);
-   cl = vclkdev_alloc(clk, con_id, dev_fmt, ap);
+   cl = vclkdev_alloc(__clk_get_hw(clk), con_id, dev_fmt, ap);
va_end(ap);
 
return cl;
@@ -334,7 +342,7 @@ int clk_register_clkdev(struct clk *clk, const char *con_id,
return PTR_ERR(clk);
 
va_start(ap, dev_fmt);
-   cl = vclkdev_alloc(clk, con_id, dev_fmt, ap);
+   cl = vclkdev_alloc(__clk_get_hw(clk), con_id, dev_fmt, ap);
va_end(ap);
 
if (!cl)
@@ -365,8 +373,8 @@ int clk_register_clkdevs(struct clk *clk, struct clk_lookup 
*cl, size_t num)
return PTR_ERR(clk);
 
for (i = 0; i < num; i++, cl++) {
-   cl->clk = clk;
-   clkdev_add(cl);
+   cl->clk_hw = __clk_get_hw(clk);
+   __clkdev_add(cl);
}
 
return 0;
diff --git a/include/linux/clkdev.h b/include/linux/clkdev.h
index 94bad77..3003afa 100644
--- a/include/linux/clkdev.h
+++ b/include/linux/clkdev.h
@@ -22,6 +22,7 @@ struct clk_lookup {
const char  *dev_id;
const char  *con_id;
struct clk  *clk;
+   struct clk_hw   *clk_hw;
 };
 
 #define CLKDEV_INIT(d, n, c)   \
-- 
2.4.10

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

[linux-yocto] [PATCH 5/7] clkdev: fix clk_add_alias() with a NULL alias device name

[Yong, Jonathan]

From: Russell King 

clk_add_alias() was not correctly handling the case where alias_dev_name
was NULL: rather than producing an entry with a NULL dev_id pointer,
it would produce a device name of (null).  Fix this.

Cc: 
Fixes: 2568999835d7 ("clkdev: add clkdev_create() helper")
Reported-by: Aaro Koskinen 
Tested-by: Aaro Koskinen 
Signed-off-by: Russell King 
(cherry picked from commit 625faa6a720d26fc0db9e20b48dc0dfe4c8d8ddf)
Signed-off-by: Yong, Jonathan 
---
 drivers/clk/clkdev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index c0eaf09..779b6ff 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -333,7 +333,8 @@ int clk_add_alias(const char *alias, const char 
*alias_dev_name,
if (IS_ERR(r))
return PTR_ERR(r);
 
-   l = clkdev_create(r, alias, "%s", alias_dev_name);
+   l = clkdev_create(r, alias, alias_dev_name ? "%s" : NULL,
+ alias_dev_name);
clk_put(r);
 
return l ? 0 : -ENODEV;
-- 
2.4.10

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

[linux-yocto] [PATCH 2/7] clkdev: drop __init from clkdev_add_table()

[Yong, Jonathan]

From: Russell King 

We want to be able to call clkdev_add_table() from non-init code, so we
need to drop the __init marker from it.

Signed-off-by: Russell King 
(cherry picked from commit fba3acd961ee167a5ffe4c094deccb7d99a0e963)
Signed-off-by: Yong, Jonathan 
---
 drivers/clk/clkdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 1bb120a..04b59ad 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -230,7 +230,7 @@ void clkdev_add(struct clk_lookup *cl)
 }
 EXPORT_SYMBOL(clkdev_add);
 
-void __init clkdev_add_table(struct clk_lookup *cl, size_t num)
+void clkdev_add_table(struct clk_lookup *cl, size_t num)
 {
mutex_lock(_mutex);
while (num--) {
-- 
2.4.10

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

[linux-yocto] [PATCH 0/7] clkdev: Backport some clkdev API from 4.4, for linux-yocto-4.1

[Yong, Jonathan]

Hello Linux-yocto,

We would want to use the same clkdev API for our drivers against bleeding
edge kernel versions. These patches are already upstream and should apply
cleanly against linux-yocto-4.1 standard/base.

Thanks.

[Resent: Seems to be missing from archive]

Russell King (7):
  clkdev: use clk_hw internally
  clkdev: drop __init from clkdev_add_table()
  clkdev: const-ify connection id to clk_add_alias()
  clkdev: add clkdev_create() helper
  clkdev: fix clk_add_alias() with a NULL alias device name
  clk: update clk API documentation to clarify clk_round_rate()
  clkdev: get rid of redundant clk_add_alias() prototype in linux/clk.h

 arch/arm/mach-davinci/da850.c|  1 +
 arch/arm/mach-omap1/board-nokia770.c |  2 +-
 arch/arm/mach-pxa/eseries.c  |  1 +
 arch/arm/mach-pxa/lubbock.c  |  1 +
 arch/arm/mach-pxa/tosa.c |  1 +
 drivers/clk/clkdev.c | 84 ++--
 include/linux/clk.h  | 27 ++--
 include/linux/clkdev.h   |  6 ++-
 8 files changed, 85 insertions(+), 38 deletions(-)

-- 
2.4.10

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

Re: [yocto] How to deal with patch failures due to new source?

[Burton, Ross]

On 23 February 2016 at 20:16, Paul D. DeRocco 
wrote:

> All of a sudden, I'm getting massive patch failures in OE's Samba 4
> package. (Last night it was fine.) Looking at the main log, the
> samba-4.1.12-r0 recipe did a do_fetch, do_unpack and do_patch. This is a
> huge patch, a megabyte in size, applying to 525 files, and it now has 31
> failures, because the patch is from last September and wasn't updated.
>

If OE didn't change the recipe, and none of your other layers changed, then
what *did* change?  The tarball upstream can't have changed as the
checksums wouldn't have matched.

Try doing bitbake samba -cclean to wipe away the local build state and
rebuilding it, this will verify that it's not some local state causing
problems.  What can happen is that bitbake wants to do a rebuild so re-runs
steps and ends up attempting to patch generated files and the patch fails
to apply (in this case the patch is broken).

Probably worth posting to openembedded-devel@ too as samba is part of
meta-oe.

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

Re: [yocto] Does CVE-2015-7547 affect eglibc?

[Darcy Watkins]

On Tue, 2016-02-23 at 13:51 -0800, Mark Hatle wrote:
> On 2/23/16 1:53 PM, Khem Raj wrote:
> > On Tue, Feb 23, 2016 at 2:25 PM, Darcy Watkins
> >> CVE-2015-7547 glibc vulnerability has been published as affecting glibc
> >> since ver 2.9 (fixed in 2.23 and patched in 2.22 and 2.21).
> >>
> >> Anyone know if we need the same security fixes in eglibc?
> > 
> > yes you do. Eglibc was nothing but glibc+few fixes.
> 
> Yes this affects all eglibc version 2.9 and newer up to glibc 2.23.
> 
> As far as I'm aware, this affects all Yocto Project versions up to 2.0.

I will be interested in knowing which Yocto Project versions will
receive the fixes.  How far back do we go in matters like this?

Thanks in advance!

> (The patch referenced by the security announcement applies to all of the
> versions of glibc I've needed to apply it to for my customers.  A few per-line
> tweaks might be necessary, but it was fairly easy.)


-- 

Regards,

Darcy

---

Darcy Watkins
Staff Engineer, Firmware
Sierra Wireless
13811 Wireless Way, Richmond, BC
Canada, V6V 3A4
[P1]

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

Re: [yocto] [meta-chip] How to flash yocto's output into CHIP

[Valentin Le bescond]

I searched a bit more :

The sunxi-spl-with-ecc.bin is built using the spl-image-builder bin in the
CHIP-tools folder (found here :
https://github.com/NextThingCo/CHIP-tools.git)
I found a set of parameters (here : line 52 :
https://github.com/soderstrom-rikard/CHIP-tools/blob/chip/stable/chip-fel-flash.sh)
but I have no idea if it's right or wrong.
That would give us :
spl-image-builder -d -r 3 -u 4096 -o 1664 -p 16384 -c 1024 -s 64
sunxi-spl.bin sunxi-spl-with-ecc.bin

I found that the uboot-env.bin file is not used to flash the chip (using
chip-fel-flash.sh file).
But it should be easy to generate it as it is made with the "mkenvimage"
program that is found (an built by yocto) in the CHIP-uboot repo.

Still not flashing though.

I will look on the UART port of the chip for further tests. I hope to see
u-boot messages while flashing.



Le mar. 23 févr. 2016 à 21:09, Valentin Le bescond <
valentin.lebesc...@gmail.com> a écrit :

> Hi,
>
> I'm wondering if anyone managed to flash the CHIP board with a
> (successful) yocto image build.
>
> I didn't succeed but here are the few things I found :
>
> Comparing the files expected in CHIP-tools/ and the ones available in
> Yocto deploy/image/chip/ I see some are missing in yocto :
> uboot-env.bin
> sunxi-spl-with-ecc.bin
> I tried using the ones downloaded with chip-update-firmware.sh but it
> doesn't work...
>
> While flashing, at some point, the chip (in FEL mode) disconnects the USB
> connection. If it goes well the chip reconnects as a ttyACM0. If it
> doesn't go well (which is my case), chip never shows up !
>
> If anyone managed to get the thing working please let me know. If not I am
> willing to try any idea you may have.
>
> Regards,
>
> Valentin
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] [PATCH v3 00/12] ktype refactoring: move DEBUG_KERNEL, EXPERT and EMBEDDED

[Bruce Ashfield]

On 2016-02-17 7:47 PM, California Sullivan wrote:

Targetted for yocto-4.4 and master


Sorry for the delay, I've been fighting some 4.4 and 4.1 kernel
issues, and bisecting has been taking up my cycles.

This looks reasonable to me, I've pulled it into my queue to see
if there's any fallout

Bruce



Changes since last revision:

*Removed branch command from developer ktype*
Including standard does this already.

*Removed "default policy" comment from -developer common-pc BSPs*
This was copied from the -standard BSPs and is no longer accurate.
I could have changed standard to developer in the comment, but I don't
feel comfortable asserting that this is the default policy for developer
kernels when more is likely to be added.

*Updated commit messages*
Explain that standard is now for production in "add developer common-pc BSPs" 
patch.
Fix typo in subject line of "inlcude developer ktype instead of standard" patch.

*Patches aren't 00/12*
That was embarassing.

This patch series refactors the ktypes so that base and standard ktypes
do not enable EMBEDDED, EXPERT, or DEBUG_KERNEL. The reason this
decision was made is because production platforms likely do not want
DEBUG_KERNEL enabled, and EMBEDDED selects EXPERT which selects
DEBUG_KERNEL.

A new ktype called "developer" was also created. This ktype
enables the options now missing from standard and base, making it easy
to maintain the functionality of a BSP through simply swapping the ktype
from standard to developer. The preempt-rt ktype is now based off of
developer in order to maintain its functionality.

The new standard ktype does not include EMBEDDED, EXPERT, or
DEBUG_KERNEL. Without DEBUG_KERNEL it loses a number of debug features
that are selected by default. Without EXPERT it gains RFKILL_INPUT and
DEBUG_MEMORY_INIT, while losing VMSPLIT_3G. These are only available to
configure with CONFIG_EXPERT=y and default to EXPERT or !EXPERT. Not
selecting EMBEDDED has no apparent impacts.

Some coordination is required for this change, as existing BSPs WILL be
affected, and will either need to accept the changes in the standard
ktype or move to the developer ktype.

California Sullivan (12):
   features/debug: add debug-kernel feature
   ktypes: add developer ktype
   ktypes/base: Disable EMBEDDED and DEBUG_KERNEL
   CONFIG_PROCESSOR_SELECT: do not enable
   intel-common-drivers.scc: move profiling and latencytop to a new file
   romley.scc remove profiling and latencytop features
   bsp/intel-common: add intel-core* developer BSPs
   preempt-rt.scc: include developer ktype instead of standard
   intel-common: add intel-developer-drivers.scc to preempt-rt BSPs
   CONFIG_I2C_I801: set option to yes in intel-core* BSPs
   bsp: add developer common-pc BSPs
   bsp: remove profiling and latencytop from non-developer common-pc BSPs

  bsp/common-pc-64/common-pc-64-developer.scc | 16 
  bsp/common-pc-64/common-pc-64-standard.scc  |  2 --
  bsp/common-pc/common-pc-developer.scc   | 16 
  bsp/common-pc/common-pc-standard.scc|  2 --
  bsp/haswell-wc/haswell-wc.cfg   |  2 +-
  bsp/intel-common/intel-common-drivers.scc   |  2 --
  bsp/intel-common/intel-core2-32-developer.scc   | 14 ++
  bsp/intel-common/intel-core2-32-preempt-rt.scc  |  1 +
  bsp/intel-common/intel-core2-32.cfg |  1 -
  bsp/intel-common/intel-corei7-64-developer.scc  | 13 +
  bsp/intel-common/intel-corei7-64-preempt-rt.scc |  1 +
  bsp/intel-common/intel-developer-drivers.scc|  3 +++
  bsp/mohonpeak/mohonpeak.cfg |  2 +-
  bsp/romley/romley.scc   |  3 ---
  cfg/amd.cfg |  1 -
  cfg/intel.cfg   |  2 --
  features/debug/debug-kernel.cfg |  3 +++
  features/debug/debug-kernel.scc |  5 +
  features/debug/printk.scc   |  1 +
  features/latencytop/latencytop.scc  |  3 +++
  features/profiling/profiling.scc|  2 ++
  features/soc/baytrail/baytrail.cfg  |  2 +-
  ktypes/base/base.cfg|  6 +++---
  ktypes/developer/developer.cfg  | 19 +++
  ktypes/developer/developer.scc  |  9 +
  ktypes/preempt-rt/preempt-rt.scc|  2 +-
  26 files changed, 113 insertions(+), 20 deletions(-)
  create mode 100644 bsp/common-pc-64/common-pc-64-developer.scc
  create mode 100644 bsp/common-pc/common-pc-developer.scc
  create mode 100644 bsp/intel-common/intel-core2-32-developer.scc
  create mode 100644 bsp/intel-common/intel-corei7-64-developer.scc
  create mode 100644 bsp/intel-common/intel-developer-drivers.scc
  create mode 100644 features/debug/debug-kernel.cfg
  create mode 100644 features/debug/debug-kernel.scc
  create mode 100644 ktypes/developer/developer.cfg
  create mode 100644 

Re: [yocto] Does CVE-2015-7547 affect eglibc?

[Mark Hatle]

On 2/23/16 1:53 PM, Khem Raj wrote:
> On Tue, Feb 23, 2016 at 2:25 PM, Darcy Watkins
>  wrote:
>> Hi,
>>
>> CVE-2015-7547 glibc vulnerability has been published as affecting glibc
>> since ver 2.9 (fixed in 2.23 and patched in 2.22 and 2.21).
>>
>> Anyone know if we need the same security fixes in eglibc?
> 
> yes you do. Eglibc was nothing but glibc+few fixes.

Yes this affects all eglibc version 2.9 and newer up to glibc 2.23.

As far as I'm aware, this affects all Yocto Project versions up to 2.0.


(The patch referenced by the security announcement applies to all of the
versions of glibc I've needed to apply it to for my customers.  A few per-line
tweaks might be necessary, but it was fairly easy.)

--Mark

>>
>> --
>>
>> Regards,
>>
>> Darcy
>>
>> ---
>>
>> Darcy Watkins
>> Staff Engineer, Firmware
>> Sierra Wireless
>> 13811 Wireless Way, Richmond, BC
>> Canada, V6V 3A4
>> [P1]
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto

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

[yocto] [yocto-autobuilder][PATCH 4/6] bin/release_scripts/release.py: add ADT publishing feature to release script

[Graydon, Tracy]

This is part of the release automation work, related to Yocto bug #8942. This
patch adds the ADT repo publishing functionality for backward compatability
for point releases, etc. Not used going forward since we have moved to the
eSDK instead, so this defaults to NOT publishing the ADT repo. A flag has
been added to cue publishing, along with an option to provide a custom
target direactory name for oddball cases where release numbering may not
be linear. i.e There was no 1.9 release, so ADT repo for 2.0_M1 would have
actually been 1.8+snapshot. This allows for those corner cases.

Signed-off-by: Graydon, Tracy 
---
 bin/release_scripts/release.py | 58 +++---
 1 file changed, 54 insertions(+), 4 deletions(-)

diff --git a/bin/release_scripts/release.py b/bin/release_scripts/release.py
index c332718..83c198e 100755
--- a/bin/release_scripts/release.py
+++ b/bin/release_scripts/release.py
@@ -317,6 +317,37 @@ def gen_rel_md5(dirname, md5_file):
 f.close()
 return
 
+def publish_adt(rel_id, rel_type, opts):
+if opts:
+ADT_DIR = os.path.join(ADT_BASE, opts)
+else:
+if rel_type == "milestone":
+chunks = split_thing(rel_id, "_")
+id_thing = float(chunks[0])
+id_thing = id_thing - 0.1
+rel_id = str(id_thing) + "+" + "snapshot"
+ADT_DIR = os.path.join(ADT_BASE, rel_id)
+print "ADT_DIR: %s" %ADT_DIR
+if os.path.exists(ADT_DIR):
+print "ADT_DIR %s EXISTS! Refusing to clobber!" %ADT_DIR
+sys.exit()
+else:
+ADT_ROOTFS = os.path.join(ADT_DIR, "rootfs")
+ADT_IPK = os.path.join(ADT_DIR, "adt-ipk")
+QEMU_DIR = os.path.join(MACHINES, "qemu")
+IPK_DIR = os.path.join(RELEASE_DIR, "ipk")
+os.mkdir(ADT_DIR)
+os.mkdir(ADT_ROOTFS)
+dirlist = get_list(QEMU_DIR)
+
+for dirname in dirlist:
+QEMU_SRC = os.path.join(QEMU_DIR, dirname)
+QEMU_TARGET = os.path.join(ADT_ROOTFS, dirname)
+print "QEMU_SRC: %s" %QEMU_SRC
+sync_it(QEMU_SRC, QEMU_TARGET, "")
+
+sync_it(IPK_DIR, ADT_IPK, "")
+return
 
 if __name__ == '__main__':
 
@@ -326,6 +357,7 @@ if __name__ == '__main__':
 VHOSTS = "/srv/www/vhosts"
 AB_BASE = os.path.join(VHOSTS, "autobuilder.yoctoproject.org/pub/releases")
 DL_BASE = os.path.join(VHOSTS, "downloads.yoctoproject.org/releases")
+ADT_BASE = os.path.join(VHOSTS, "adtrepo.yoctoproject.org")
 
 # List of the directories we delete from all releases
 UNLOVED = ['rpm', 'deb', 'ptest', 'adt-installer-QA']
@@ -346,7 +378,12 @@ if __name__ == '__main__':
 parser.add_option("-p", "--poky-ver",
   type="string", dest="poky",
   help="Required for Major and Point releases. i.e. 
14.0.0")
- 
+parser.add_option("-a", action="store_true", dest="pub_adt",
+  help="Publish an ADT repo for the release. Default is 
NOT to publish.")
+parser.add_option("-d", "--adt-dir",
+  type="string", dest="adt_dir",
+  help="Use when you need to publish the ADT repo to a 
custom location. i.e. python adtcopy -b yocto-2.0_M1.rc1 -a 1.8+snaphot")
+
 (options, args) = parser.parse_args()
  
 REL_TYPE = ""
@@ -395,12 +432,12 @@ if __name__ == '__main__':
 print "Build ID is a required argument."
 print "Please use -h or --help for options."
 sys.exit()
-
+   
 if not (RELEASE and RC and REL_ID and REL_TYPE):
 print "Can't determine the release type. Check your args."
 print "You gave me: %s" %options.build
 sys.exit()
-
+
 print "RC_DIR: %s" %RC_DIR
 print "RELEASE: %s" %RELEASE
 print "RC: %s" %RC
@@ -420,7 +457,7 @@ if __name__ == '__main__':
 ECLIPSE_DIR = os.path.join(RELEASE_DIR, "eclipse-plugin")
 BUILD_APP_DIR = os.path.join(RELEASE_DIR, "build-appliance")
 REL_MD5_FILE = RELEASE + ".md5sum"
-   
+
 # For all releases:
 # 1) Rsync the rc candidate to a staging dir where all work happens
 sync_it(RC_SOURCE, RELEASE_DIR, UNLOVED)
@@ -461,3 +498,16 @@ if __name__ == '__main__':
 print "Publishing release to downloads."
 sync_it(RELEASE_DIR, DL_DIR, "")
 
+# 9) Publish the ADT repo. The default is NOT to publish the ADT. The ADT 
+# is deprecated as of 2.1_M1. However, we need to retain backward 
+# compatability for point releases, etc. We do this step after all the 
other
+#  stuff because we want the symlinks to have been converted, extraneous 
+# files deleted, and md5sums generated.
+#
+if options.pub_adt:
+if options.adt_dir:
+print "Publishing the ADT repo using custom dir %s" 
%options.adt_dir
+publish_adt(REL_ID, REL_TYPE, options.adt_dir)
+else:
+print "Publishing ADT repo."
+

[yocto] [yocto-autobuilder][PATCH 3/6] bin/release_scripts/release.py: add a check for valid rc candidate

[Graydon, Tracy]

This is part of the release automation work, related to Yocto bug #8942. This
patch adds a check for a valid release candidate ID passed in from command line
and quits if it is bogus. Adds a few comments/output for the user for the
various release steps to improve clarity.

Signed-off-by: Graydon, Tracy 
---
 bin/release_scripts/release.py | 53 +++---
 1 file changed, 39 insertions(+), 14 deletions(-)

diff --git a/bin/release_scripts/release.py b/bin/release_scripts/release.py
index 3dab369..c332718 100755
--- a/bin/release_scripts/release.py
+++ b/bin/release_scripts/release.py
@@ -360,19 +360,23 @@ if __name__ == '__main__':
 else:
 BRANCH = ""
 
-
 if options.build:
 # Figure out the release name, type of release, and generate some 
vars, do some basic validation
-chunks = split_thing(options.build, ".")
+options.build = options.build.lower()
+RC = split_thing(options.build, ".")[-1]
+chunks = split_thing(options.build, ".") # i.e. split yocto-2.1_m1.rc1
 chunks.pop()
-RELEASE = rejoin_thing(chunks, ".")
-rel_thing = split_thing(options.build, "-")
-RC = split_thing(options.build, ".")[-1].lower()
-RC_DIR = RELEASE + "." + RC
-REL_ID = split_thing(RELEASE, "-")[-1]
-milestone = split_thing(REL_ID, "_")
-if len(milestone) == 1:
-thing = split_thing(milestone[0], ".")
+chunks[1] = chunks[1].upper()
+RELEASE = rejoin_thing(chunks, ".")  # i.e. yocto-2.1_m1
+REL_ID = split_thing(RELEASE, "-")[-1].upper()
+RC_DIR = rejoin_thing([RELEASE, RC], ".")
+RC_SOURCE = os.path.join(AB_BASE, RC_DIR)
+if not os.path.exists(RC_SOURCE):
+print "%s does not appear to be a valid RC dir. Check your args." 
%RC_SOURCE
+sys.exit()
+relstring = split_thing(REL_ID, "_")
+if len(relstring) == 1:
+thing = split_thing(relstring[0], ".")
 if len(thing) == 3:
 REL_TYPE = "point"
 elif len(thing) == 2:
@@ -385,14 +389,27 @@ if __name__ == '__main__':
 print "Please use -h or --help for options."
 sys.exit()
 else:
-MILESTONE = milestone.pop()
+MILESTONE = relstring.pop()
 REL_TYPE = "milestone"
 else:
 print "Build ID is a required argument."
 print "Please use -h or --help for options."
 sys.exit()
-
-RC_SOURCE = os.path.join(AB_BASE, RC_DIR)
+
+if not (RELEASE and RC and REL_ID and REL_TYPE):
+print "Can't determine the release type. Check your args."
+print "You gave me: %s" %options.build
+sys.exit()
+
+print "RC_DIR: %s" %RC_DIR
+print "RELEASE: %s" %RELEASE
+print "RC: %s" %RC
+print "REL_ID: %s" %REL_ID
+print "REL_TYPE: %s" %REL_TYPE
+if MILESTONE:
+print "MILESTONE: %s" %MILESTONE
+print
+
 PLUGIN_DIR = os.path.join(DL_BASE, "eclipse-plugin", REL_ID)
 RELEASE_DIR = os.path.join(AB_BASE, RELEASE)
 DL_DIR = os.path.join(DL_BASE, RELEASE)
@@ -403,36 +420,44 @@ if __name__ == '__main__':
 ECLIPSE_DIR = os.path.join(RELEASE_DIR, "eclipse-plugin")
 BUILD_APP_DIR = os.path.join(RELEASE_DIR, "build-appliance")
 REL_MD5_FILE = RELEASE + ".md5sum"
- 
+   
 # For all releases:
 # 1) Rsync the rc candidate to a staging dir where all work happens
 sync_it(RC_SOURCE, RELEASE_DIR, UNLOVED)
 
 # 2) Convert the symlinks in build-appliance dir.
+print "Converting the build-appliance symlink."
 convert_symlinks(BUILD_APP_DIR)
 
 # 3) In machines dir, convert the symlinks, delete the cruft
+print "Cleaning up the machines dirs, converting symlinks."
 dirlist = get_list(MACHINES)
 for dirname in dirlist:
 dirname = os.path.join(MACHINES, dirname)
 convert_symlinks(dirname)
 nuke_cruft(dirname, CRUFT_LIST)
+print "Generating fresh md5sums."
 gen_md5sum(MACHINES)
 
 # For major and point releases
 if REL_TYPE == "major" or REL_TYPE == "point":
 # 4) Fix up the eclipse and poky tarballs
+print "Cleaning up the eclipse, poky and other tarballs."
 fix_tarballs()
 
 # 5) Publish the eclipse stuff
+print "Publishing the eclipse plugins."
 pub_eclipse(ECLIPSE_DIR, PLUGIN_DIR)
 
 # 6) Make the bsps
+print "Generating the BSP tarballs."
 make_bsps(BSP_LIST, BSP_DIR)
 
 # 7) Generate the master md5sum file for the release (for all releases)
+print "Generating the master md5sum table."
 gen_rel_md5(RELEASE_DIR, REL_MD5_FILE)
 
 # 8) sync to downloads
+print "Publishing release to downloads."
 sync_it(RELEASE_DIR, DL_DIR, "")
 
-- 
2.4.3

-- 
___
yocto mailing list
yocto@yoctoproject.org

[yocto] [yocto-autobuilder][PATCH 5/6] bin/release_scripts/release.py: fix the tarball naming

[Graydon, Tracy]

Fixed tarball repackaging to add missing branch name to the new
tarball name. i.e. -.tar.bz2 was being renamed to
-.14.0.1.tar.bz2, which is wrong. Should be renamed to
--.tar.bz2.

Signed-off-by: Graydon, Tracy 
---
 bin/release_scripts/release.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/bin/release_scripts/release.py b/bin/release_scripts/release.py
index 83c198e..8751a04 100755
--- a/bin/release_scripts/release.py
+++ b/bin/release_scripts/release.py
@@ -94,7 +94,7 @@ def fix_tarballs():
 filename = chunks[0]
 basename = split_thing(filename, "-")
 index = len(basename)-1
-basename[index] = POKY_VER
+basename[index] = "-".join([BRANCH, POKY_VER])
 new_name = rejoin_thing(basename, "-")
 chunks[0] = new_name
 new_blob = rejoin_thing(chunks, ".")
@@ -511,3 +511,4 @@ if __name__ == '__main__':
 else:
 print "Publishing ADT repo."
 publish_adt(REL_ID, REL_TYPE, "")
+
-- 
2.4.3

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

[yocto] [yocto-autobuilder][PATCH 2/6] bin/release_scripts/release.py: remove stuff only used for initial testing

[Graydon, Tracy]

This is part of the release automation work, related to Yocto bug #8942. This
patch removes the print_vars function and some other lines that were only used
for testing and are otherwise useless.

Signed-off-by: Graydon, Tracy 
---
 bin/release_scripts/release.py | 37 -
 1 file changed, 37 deletions(-)

diff --git a/bin/release_scripts/release.py b/bin/release_scripts/release.py
index 27ee409..3dab369 100755
--- a/bin/release_scripts/release.py
+++ b/bin/release_scripts/release.py
@@ -20,33 +20,6 @@ import shutil
 from shutil import rmtree, copyfile
 from subprocess import call
 
-def print_vars():
-print "RELEASE: %s" %RELEASE
-print "REL_TYPE: %s" %REL_TYPE
-print "RC_DIR: %s" %RC_DIR
-print "REL_ID: %s" %REL_ID
-print "RC: %s" %RC
-if MILESTONE != "":
-print "Milestone: %s" %MILESTONE
-if POKY_VER != "":
-print "POKY_VER: %s" %POKY_VER
-else:
-   print "POKY_VER: undefined!"
-if BRANCH:
-print "BRANCH: %s" %BRANCH
-else:
-print "BRANCH: undefined!"
-
-print "DL_BASE: %s" %DL_BASE
-if RC_SOURCE != "":
-print "RC_SOURCE: %s" %RC_SOURCE
-print "RELEASE_DIR: %s" %RELEASE_DIR
-print "ECLIPSE_DIR: %s" %ECLIPSE_DIR
-print "PLUGIN_DIR: %s" %PLUGIN_DIR
-print "DL_DIR: %s" %DL_DIR
-print
-return
-
 def sanity_check(source, target):
 if not os.path.exists(source):
print
@@ -64,7 +37,6 @@ def sanity_check(source, target):
sys.exit()
 return
 
-
 def sync_it(source, target, exclude_list):
 print "Syncing %s to %s" %(source, target)
 sanity_check(source, target)
@@ -112,7 +84,6 @@ def fix_tarballs():
 print "Repackaging poky and eclipse tarballs"
 os.chdir(RELEASE_DIR)
 os.mkdir(TARBALL_DIR)
-#os.mkdir("%s" %TARBALL_DIR)
 os.system("mv %s/*.tar.bz2 %s" %(RELEASE_DIR, TARBALL_DIR))
 os.system("rm *.md5sum")
 os.chdir(TARBALL_DIR)
@@ -352,12 +323,6 @@ if __name__ == '__main__':
 os.system("clear")
 print

-# This is for testing convenience
-#HOME_BASE = "/home/tgraydon/work/release"
-#AB_BASE = HOME_BASE
-#DL_BASE = os.path.join(HOME_BASE, "downloads")
-
-# This is the legit set of vars used for production release
 VHOSTS = "/srv/www/vhosts"
 AB_BASE = os.path.join(VHOSTS, "autobuilder.yoctoproject.org/pub/releases")
 DL_BASE = os.path.join(VHOSTS, "downloads.yoctoproject.org/releases")
@@ -439,8 +404,6 @@ if __name__ == '__main__':
 BUILD_APP_DIR = os.path.join(RELEASE_DIR, "build-appliance")
 REL_MD5_FILE = RELEASE + ".md5sum"
  
-print_vars()
-
 # For all releases:
 # 1) Rsync the rc candidate to a staging dir where all work happens
 sync_it(RC_SOURCE, RELEASE_DIR, UNLOVED)
-- 
2.4.3

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

[yocto] [yocto-autobuilder][PATCH 1/6] bin/release_scripts/relnotes.sh: Add script to generate release notes template.

[Graydon, Tracy]

This is a capture of the command-line ickiness that we have been
using to generate the basic release notes draft. It's frightfully ugly, but
gets the job done for now.

Signed-off-by: Graydon, Tracy 
---
 bin/release_scripts/relnotes.sh | 82 +
 1 file changed, 82 insertions(+)
 create mode 100755 bin/release_scripts/relnotes.sh

diff --git a/bin/release_scripts/relnotes.sh b/bin/release_scripts/relnotes.sh
new file mode 100755
index 000..a88f0b8
--- /dev/null
+++ b/bin/release_scripts/relnotes.sh
@@ -0,0 +1,82 @@
+#!/bin/bash
+
+# NOTE! This script will blissfully clobber any pre-existing poky repos, 
+# previous release notes with same filename, etc. 
+#
+# This is a quick and ugly script to generate the release notes draft.
+#
+# Usage: ./relnotes.sh    
+# i.e. ./relnotes.sh yocto-2.0.1 rc6 jethro 14.0.1
+#
+# Currently the revision in the git log portion is hard coded. You 
+# will want to change accordingly! 
+# i.e. git log --pretty=format:"%s" yocto-2.0..HEAD |grep CVE >> $HOME/CVE;
+# Change the yocto-2.0 bit to whatever it needs to be for the given release.
+
+
+
+clear
+REL_ID=$1
+RC=$2
+BRANCH=$3
+POKY_VER=$4
+RELEASE=$REL_ID
+VHOSTS="/srv/www/vhosts"
+AB_BASE="$VHOSTS/autobuilder.yoctoproject.org/pub/releases"
+DL_BASE="$VHOSTS/downloads.yoctoproject.org/releases"
+RC_SOURCE="$AB_BASE/$RELEASE.$RC"
+RELEASE_DIR="$AB_BASE/$RELEASE"
+MACHINES="$RELEASE_DIR/machines"
+HOME=~/work/release
+echo "REL_ID: $REL_ID"
+echo "RC: $RC"
+echo "BRANCH: $BRANCH"
+echo "POKY_VER: $POKY_VER"
+echo "RELEASE: $RELEASE"
+echo "AB_BASE: $AB_BASE"
+echo "DL_BASE: $DL_BASE"
+echo "RC_SOURCE: $RC_SOURCE"
+echo "RELEASE_DIR: $RELEASE_DIR"
+echo "MACHINES: $MACHINES"
+echo
+
+if [[ -e $HOME/RELEASENOTES.$RELEASE ]]; then
+rm -v $HOME/RELEASENOTES.$RELEASE
+fi
+if [[ -e $HOME/CVE ]]; then
+rm -v $HOME/CVE
+fi
+if [[ -e $HOME/FIXES ]]; then
+rm -v $HOME/FIXES
+fi
+if [[ -d $HOME/poky ]]; then
+rm -rvf $HOME/poky
+fi
+
+for x in `ls $RELEASE_DIR/*.bz2.md5sum | grep -v "\-fsl" | grep -v "\-ppc"`; 
do 
+   layer=`basename $x | sed 
's/\-'"$BRANCH"'\-'"$POKY_VER"'.tar.bz2.md5sum//g'`; 
+   tarball=`basename $x |sed 's/\.md5sum//g'`; 
+   ghash=`ls $RELEASE_DIR/$layer*.bz2 | grep -v $BRANCH | sed 
's/'"$layer"'-//g' | sed 's/.tar.bz2//g'`;
+   ghash=`basename $ghash`
+   echo "Release Name: " $layer-$BRANCH-$POKY_VER; 
+   echo "Branch: $BRANCH"; 
+   echo "Tag: $BRANCH-$POKY_VER"; 
+   echo "Hash: " $ghash; 
+   echo "md5: `cat $RELEASE_DIR/$tarball.md5sum`"; 
+   echo "Download Locations:"; 
+   echo "http://downloads.yoctoproject.org/releases/yocto/$RELEASE/$tarball;; 
+   echo "http://mirrors.kernel.org/yocto/yocto/$RELEASE/$tarball;; echo ""; 
+done >> $HOME/RELEASENOTES.$RELEASE
+
+git clone git://git.yoctoproject.org/poky;
+cd poky; 
+git checkout $BRANCH; 
+echo -e "\n---\nSecurity Fixes\n---" >> $HOME/CVE;
+git log --pretty=format:"%s" yocto-2.0..HEAD |grep CVE >> $HOME/CVE; 
+echo -e "\n---\nFixes\n---" >> $HOME/FIXES; 
+git log --pretty=format:"%s" yocto-2.0..HEAD |grep -v CVE >> $HOME/FIXES; 
+cat $HOME/CVE >> $HOME/RELEASENOTES.$RELEASE; cat $HOME/FIXES >> 
$HOME/RELEASENOTES.$RELEASE
+cd $HOME
+
+
+
-- 
2.4.3

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

Re: [yocto] [meta-raspberrypi][PATCH] linux-raspberrypi: Adjust for libexecdir changes

[Andreas Müller]

On Tue, Feb 23, 2016 at 10:02 PM, Anders Darander  wrote:
> Ping?
>
> We can't build on master branch without this fix...
>
> Cheers,
> Anders
>
> * Khem Raj  [160130 18:07]:
>
>> libexecdir has changed its location in latest OE core, it used to be
>> pointing to /usr/lib which was essentially same as libdir and when
>> hardcoded in do_rpiboot_mkimage it worked.
>
>> Fixes kernel build failures e.g.
>
>> DEBUG: Executing shell function do_rpiboot_mkimage
>> /a/builder/mnt/build-oe/tmp-musl/work/raspberrypi2-oe-linux-musleabi/linux-raspberrypi/1_4.1.10+gitAUTOINC+b74df9228c-r0/temp/run.do_rpiboot_mkimage.5543:
>> line 111:
>> /a/builder/mnt/build-oe/tmp-musl/sysroots/x86_64-linux/usr/lib/rpi-mkimage/mkknlimg:
>>  No such file or directory
>
>> Signed-off-by: Khem Raj 
>> ---
>>  recipes-kernel/linux/linux-raspberrypi.inc | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>
>> diff --git a/recipes-kernel/linux/linux-raspberrypi.inc 
>> b/recipes-kernel/linux/linux-raspberrypi.inc
>> index 70e8bfe..0798788 100644
>> --- a/recipes-kernel/linux/linux-raspberrypi.inc
>> +++ b/recipes-kernel/linux/linux-raspberrypi.inc
>> @@ -60,7 +60,7 @@ do_rpiboot_mkimage() {
>>  if test "x${KERNEL_IMAGETYPE}" != "xuImage" ; then
>>  if test -n "${KERNEL_DEVICETREE}"; then
>>  # Add RPi bootloader trailer to kernel image to enable 
>> DeviceTree support
>> -${STAGING_DIR_NATIVE}/usr/lib/rpi-mkimage/mkknlimg --dtok 
>> ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}
>> +${STAGING_DIR_NATIVE}${libexecdir}/mkknlimg --dtok 
>> ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}
>>  fi
>>  fi
>>  }
> --
> Anders Darander, Senior System Architect
> ChargeStorm AB / eStorm AB
> --
This patch is mandatory but there was a serial with additional fixes
send by Maciej Borzecki on Feb 2nd. I think this is worth taken into
account.

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

[yocto] How to deal with patch failures due to new source?

[Paul D. DeRocco]

All of a sudden, I'm getting massive patch failures in OE's Samba 4
package. (Last night it was fine.) Looking at the main log, the
samba-4.1.12-r0 recipe did a do_fetch, do_unpack and do_patch. This is a
huge patch, a megabyte in size, applying to 525 files, and it now has 31
failures, because the patch is from last September and wasn't updated.

I would think the only way to deal with this, until OE provides a fixed
patch, is to go back to the previous source version. The recipe itself
didn't change, so how do I do this?

Also, is this a normal occurrence in the bitbake world? Is it always
possible, any time one does a bitbake, that some new source will appear
that breaks something? Is there a way of avoiding this by preventing new
source from being fetched, and finding out about its existence perhaps
through warning messages?

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com

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

Re: [yocto] [meta-raspberrypi][PATCH] linux-raspberrypi: Adjust for libexecdir changes

[Anders Darander]

Ping?

We can't build on master branch without this fix...

Cheers,
Anders

* Khem Raj  [160130 18:07]:

> libexecdir has changed its location in latest OE core, it used to be
> pointing to /usr/lib which was essentially same as libdir and when
> hardcoded in do_rpiboot_mkimage it worked.

> Fixes kernel build failures e.g.

> DEBUG: Executing shell function do_rpiboot_mkimage
> /a/builder/mnt/build-oe/tmp-musl/work/raspberrypi2-oe-linux-musleabi/linux-raspberrypi/1_4.1.10+gitAUTOINC+b74df9228c-r0/temp/run.do_rpiboot_mkimage.5543:
> line 111:
> /a/builder/mnt/build-oe/tmp-musl/sysroots/x86_64-linux/usr/lib/rpi-mkimage/mkknlimg:
>  No such file or directory

> Signed-off-by: Khem Raj 
> ---
>  recipes-kernel/linux/linux-raspberrypi.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

> diff --git a/recipes-kernel/linux/linux-raspberrypi.inc 
> b/recipes-kernel/linux/linux-raspberrypi.inc
> index 70e8bfe..0798788 100644
> --- a/recipes-kernel/linux/linux-raspberrypi.inc
> +++ b/recipes-kernel/linux/linux-raspberrypi.inc
> @@ -60,7 +60,7 @@ do_rpiboot_mkimage() {
>  if test "x${KERNEL_IMAGETYPE}" != "xuImage" ; then
>  if test -n "${KERNEL_DEVICETREE}"; then
>  # Add RPi bootloader trailer to kernel image to enable 
> DeviceTree support
> -${STAGING_DIR_NATIVE}/usr/lib/rpi-mkimage/mkknlimg --dtok 
> ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}
> +${STAGING_DIR_NATIVE}${libexecdir}/mkknlimg --dtok 
> ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}
>  fi
>  fi
>  }
-- 
Anders Darander, Senior System Architect
ChargeStorm AB / eStorm AB
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-raspberrypi][PATCH] linux-raspberrypi: make a machine defconfig work

[Anders Darander]

If we have a machine specific defconfig 'defconfig' in our meta-data, the 
install
command fails. OTOH, in that case it's not necessary to copy it into twe WORKDIR
either.

Signed-off-by: Anders Darander 
---
 recipes-kernel/linux/linux-raspberrypi.inc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/recipes-kernel/linux/linux-raspberrypi.inc 
b/recipes-kernel/linux/linux-raspberrypi.inc
index 70e8bfe..0fb3fb3 100644
--- a/recipes-kernel/linux/linux-raspberrypi.inc
+++ b/recipes-kernel/linux/linux-raspberrypi.inc
@@ -43,7 +43,9 @@ python __anonymous () {
 }
 
 do_kernel_configme_prepend() {
-install -m 0644 ${S}/arch/${ARCH}/configs/${KERNEL_DEFCONFIG} 
${WORKDIR}/defconfig || die "No default configuration for ${MACHINE} / 
${KERNEL_DEFCONFIG} available."
+if test -n "${KERNEL_DEFCONFIG}" ; then
+install -m 0644 ${S}/arch/${ARCH}/configs/${KERNEL_DEFCONFIG} 
${WORKDIR}/defconfig || die "No default configuration for ${MACHINE} / 
${KERNEL_DEFCONFIG} available."
+fi
 }
 
 do_install_prepend() {
-- 
2.7.0

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

Re: [yocto] Does CVE-2015-7547 affect eglibc?

[Khem Raj]

On Tue, Feb 23, 2016 at 2:25 PM, Darcy Watkins
 wrote:
> Hi,
>
> CVE-2015-7547 glibc vulnerability has been published as affecting glibc
> since ver 2.9 (fixed in 2.23 and patched in 2.22 and 2.21).
>
> Anyone know if we need the same security fixes in eglibc?

yes you do. Eglibc was nothing but glibc+few fixes.

>
> --
>
> Regards,
>
> Darcy
>
> ---
>
> Darcy Watkins
> Staff Engineer, Firmware
> Sierra Wireless
> 13811 Wireless Way, Richmond, BC
> Canada, V6V 3A4
> [P1]
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Does CVE-2015-7547 affect eglibc?

[Darcy Watkins]

Hi,

CVE-2015-7547 glibc vulnerability has been published as affecting glibc
since ver 2.9 (fixed in 2.23 and patched in 2.22 and 2.21).

Anyone know if we need the same security fixes in eglibc?

-- 

Regards,

Darcy

---

Darcy Watkins
Staff Engineer, Firmware
Sierra Wireless
13811 Wireless Way, Richmond, BC
Canada, V6V 3A4
[P1]

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

Re: [yocto] [RFC] [autobuilder] Autobuilder.py: add verbose buildset parse error

[Flanagan, Elizabeth]

On 23 February 2016 at 15:42, Alex Franco
 wrote:
> From: Alejandro Franco 
>
> Add a more verbose Exception when a buildset parse operation fails
>

Approved and in master.

-b

> Signed-off-by: Alejandro Franco 
> ---
>  lib/python2.7/site-packages/autobuilder/Autobuilder.py | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/lib/python2.7/site-packages/autobuilder/Autobuilder.py 
> b/lib/python2.7/site-packages/autobuilder/Autobuilder.py
> index 3174784..f200974 100644
> --- a/lib/python2.7/site-packages/autobuilder/Autobuilder.py
> +++ b/lib/python2.7/site-packages/autobuilder/Autobuilder.py
> @@ -118,12 +118,15 @@ class Autobuilder:
>  def parseRepos(self, buildset=None):
>  buildset=buildset
>  if self.configdict[buildset].has_key('repos'):
> -for layer in 
> ast.literal_eval(self.configdict[buildset]['repos']):
> -if layer.iterkeys().next() not in self.repos:
> -schedpropstoextend, newcheckoutprops = 
> self.CreateLayerSchedulerParams(layer=layer, trigger=buildset, triggerer=True)
> -self.schedprops.extend(schedpropstoextend)
> -self.checkoutprops.update(newcheckoutprops)
> -self.repos.append(layer.iterkeys().next())
> +try:
> +for layer in 
> ast.literal_eval(self.configdict[buildset]['repos']):
> +if layer.iterkeys().next() not in self.repos:
> +schedpropstoextend, newcheckoutprops = 
> self.CreateLayerSchedulerParams(layer=layer, trigger=buildset, triggerer=True)
> +self.schedprops.extend(schedpropstoextend)
> +self.checkoutprops.update(newcheckoutprops)
> +self.repos.append(layer.iterkeys().next())
> +except SyntaxError as err:
> +raise ABConfigError("%s found in %s" % (err, buildset))
>  return
>
>  def parseProps(self, buildset):
> --
> 1.9.1
>



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

Re: [yocto] Embedded Linux Conference, YP DevDay, and OEDAM

[Paul Eggleton]

On Tue, 23 Feb 2016 08:53:13 akuster808 wrote:
> On 01/27/2016 01:49 PM, Philip Balister wrote:
> > On 01/27/2016 07:49 PM, akuster wrote:
> >> On 01/27/2016 10:15 AM, Jeff Osier-Mixon wrote:
> >>> If you are planning to attend the Embedded Linux Conference in San
> >>> Diego this April, I wanted to let you know about the Yocto Project
> >>> Developer Day that the team is planning. This will be similar to
> >>> previous DevDays, with hands-on training in both introductory and
> >>> advanced tracks. The day will happen just after ELC, on April 7 at the
> >>> Marriott in downtown San Diego, just across from the ELC venue. We'll
> >>> have more details posted later this week.
> >>> 
> >>> The project is also a sponsor for the event and we will have a booth.
> >>> If you have something cool that you have been working on and would
> >>> like to show it off in the booth during the conference, let me know
> >>> and we'll see what we can do to make some space for your project.
> >> 
> >> I will be bring at least one demo. Not sure if its cool.
> >> 
> >>> For those also in the OpenEmbedded community, there will be an OE
> >>> developer's meeting and working session on Friday, April 8. This is a
> >>> working session for OE members (not an educational session, sorry!)
> >>> and space is limited, so if you plan to attend, please let me know so
> >>> I can plan space accordingly.
> >> 
> >> I will be there. I take it there will be a wiki sigh up like before?
> > 
> > Yep, I'm on the road, but will copy the last OE developer meeting to
> > start to page. If you do not have a wiki account go ahead and make on.
> 
> Is there an OEDAM page yet?
> 
> > Accounts need to be approved by a human now, the spammers were getting
> > bad again :(
> 
> Submitted a login request a month ago and no email or response.
> 
> I am not a bot.

I just checked your account on the OE wiki - it looks like it should have 
rights to edit. Is it still not working?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Embedded Linux Conference, YP DevDay, and OEDAM

[akuster808]

On 01/27/2016 01:49 PM, Philip Balister wrote:
> On 01/27/2016 07:49 PM, akuster wrote:
>>
>>
>> On 01/27/2016 10:15 AM, Jeff Osier-Mixon wrote:
>>> If you are planning to attend the Embedded Linux Conference in San
>>> Diego this April, I wanted to let you know about the Yocto Project
>>> Developer Day that the team is planning. This will be similar to
>>> previous DevDays, with hands-on training in both introductory and
>>> advanced tracks. The day will happen just after ELC, on April 7 at the
>>> Marriott in downtown San Diego, just across from the ELC venue. We'll
>>> have more details posted later this week.
>>>
>>> The project is also a sponsor for the event and we will have a booth.
>>> If you have something cool that you have been working on and would
>>> like to show it off in the booth during the conference, let me know
>>> and we'll see what we can do to make some space for your project.
>>
>> I will be bring at least one demo. Not sure if its cool.
>>
>>>
>>> For those also in the OpenEmbedded community, there will be an OE
>>> developer's meeting and working session on Friday, April 8. This is a
>>> working session for OE members (not an educational session, sorry!)
>>> and space is limited, so if you plan to attend, please let me know so
>>> I can plan space accordingly.
>>
>> I will be there. I take it there will be a wiki sigh up like before?
> 
> Yep, I'm on the road, but will copy the last OE developer meeting to
> start to page. If you do not have a wiki account go ahead and make on.

Is there an OEDAM page yet?

> Accounts need to be approved by a human now, the spammers were getting
> bad again :(

Submitted a login request a month ago and no email or response.

I am not a bot.

- Armin
> 
> Philip
> 
> 
> 
>>
>> - armin
>>>
>>> thanks!
>>>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [RFC] [autobuilder] Autobuilder.py: add verbose buildset parse error

[Alex Franco]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Not sure this how this should be done, but at least it's been helpful in
my case

Alex Franco

On 02/23/2016 09:42 AM, Alex Franco wrote:
> From: Alejandro Franco 
>
> Add a more verbose Exception when a buildset parse operation fails
>
> Signed-off-by: Alejandro Franco 
> ---
>  lib/python2.7/site-packages/autobuilder/Autobuilder.py | 15
+--
>  1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/lib/python2.7/site-packages/autobuilder/Autobuilder.py
b/lib/python2.7/site-packages/autobuilder/Autobuilder.py
> index 3174784..f200974 100644
> --- a/lib/python2.7/site-packages/autobuilder/Autobuilder.py
> +++ b/lib/python2.7/site-packages/autobuilder/Autobuilder.py
> @@ -118,12 +118,15 @@ class Autobuilder:
>  def parseRepos(self, buildset=None):
>  buildset=buildset
>  if self.configdict[buildset].has_key('repos'):
> -for layer in
ast.literal_eval(self.configdict[buildset]['repos']):
> -if layer.iterkeys().next() not in self.repos:
> -schedpropstoextend, newcheckoutprops =
self.CreateLayerSchedulerParams(layer=layer, trigger=buildset,
triggerer=True)
> -self.schedprops.extend(schedpropstoextend)
> -self.checkoutprops.update(newcheckoutprops)
> -self.repos.append(layer.iterkeys().next())
> +try:
> +for layer in
ast.literal_eval(self.configdict[buildset]['repos']):
> +if layer.iterkeys().next() not in self.repos:
> +schedpropstoextend, newcheckoutprops =
self.CreateLayerSchedulerParams(layer=layer, trigger=buildset,
triggerer=True)
> +self.schedprops.extend(schedpropstoextend)
> +self.checkoutprops.update(newcheckoutprops)
> +self.repos.append(layer.iterkeys().next())
> +except SyntaxError as err:
> +raise ABConfigError("%s found in %s" % (err, buildset))
>  return
> 
>  def parseProps(self, buildset):

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBAgAGBQJWzH5AAAoJEPR9uwMY2lTLg1MH/1WoSCFXJ768TR5yGvWM5vd1
2VdHTuMRD2FlvvblbFLIrOwsYd9TU5UccijLKYcu0K1k9CiQVjDRB4D7c/uzCLQv
E/ndOerRo1FkZyat2vEONfVInJTzycM2auY3j41jz1Pr4uyNhnJphgVzC/Kinf/F
PswyAYYnnV6ytTXFLBx4dSX5AIO0qXmoX9pmEP5W+FfmkjBQlqrbAScomyNSamhf
SGpC9520wUo7tke/2qLz5PgVkZ8LGR7ZlW6qEErZY462bW/cLWWpnP77c6ll3wiX
huC4iQtSTwJ0ZKl1NWHz0N9Fs8f9ky41VOxaD3EAjdroqMlKnfd8LkDfo6g2cm4=
=9eQK
-END PGP SIGNATURE-

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

[yocto] [RFC] [autobuilder] Autobuilder.py: add verbose buildset parse error

[Alex Franco]

From: Alejandro Franco 

Add a more verbose Exception when a buildset parse operation fails

Signed-off-by: Alejandro Franco 
---
 lib/python2.7/site-packages/autobuilder/Autobuilder.py | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/lib/python2.7/site-packages/autobuilder/Autobuilder.py 
b/lib/python2.7/site-packages/autobuilder/Autobuilder.py
index 3174784..f200974 100644
--- a/lib/python2.7/site-packages/autobuilder/Autobuilder.py
+++ b/lib/python2.7/site-packages/autobuilder/Autobuilder.py
@@ -118,12 +118,15 @@ class Autobuilder:
 def parseRepos(self, buildset=None):
 buildset=buildset
 if self.configdict[buildset].has_key('repos'):
-for layer in ast.literal_eval(self.configdict[buildset]['repos']):
-if layer.iterkeys().next() not in self.repos:
-schedpropstoextend, newcheckoutprops = 
self.CreateLayerSchedulerParams(layer=layer, trigger=buildset, triggerer=True)
-self.schedprops.extend(schedpropstoextend)
-self.checkoutprops.update(newcheckoutprops)
-self.repos.append(layer.iterkeys().next())
+try:
+for layer in 
ast.literal_eval(self.configdict[buildset]['repos']):
+if layer.iterkeys().next() not in self.repos:
+schedpropstoextend, newcheckoutprops = 
self.CreateLayerSchedulerParams(layer=layer, trigger=buildset, triggerer=True)
+self.schedprops.extend(schedpropstoextend)
+self.checkoutprops.update(newcheckoutprops)
+self.repos.append(layer.iterkeys().next())
+except SyntaxError as err:
+raise ABConfigError("%s found in %s" % (err, buildset))
 return
 
 def parseProps(self, buildset):
-- 
1.9.1

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

Re: [yocto] [meta-chip][PATCH] added md5 for ntc's modified u-boot Licences/README file.

[Oliver]

Not yet @Valentin, This is in my TODO list. I did spend an afternoon checking 
for their scripts inside the SDK at least to retrieve a backup copy of the 
oficial firmware. I guess this is the starting point to work out something 
within yocto:
https://github.com/NextThingCo/CHIP-tools/blob/chip/stable/chip-update-firmware.sh


 

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

Re: [yocto] Post Generation of debug information

[Oliver]

In this special case the tool is Lauterbach's Trace32. 

If I understand properly each piece of output I would eventually need, I would 
need to modify its origin recipes to ensure they deploy the such files in 
DEPLOY_DIR_IMAGE/SOME_WHERE. There I could proceed in a similar way as the 
image_types classes.
Paths are the first motivation, but physical addresses, offsets configurations 
which might could only be fetched from grepping the code could be next. Ideally 
I would not like to modify others recipes.
In a more generic way, is there a way a recipe accesses variables of other 
recipes?


El Lunes 22 de febrero de 2016 19:46, Khem Raj  
escribió:
 

 On Mon, Feb 22, 2016 at 7:41 AM, Oliver  wrote:
> I have the need to generate some scripts for a debugger tool. As a first
> approach, these generated scripts could contain paths on where specific
> binary files are stored on the file system.
>
> Such purpose has been partially fulfilled with a recipe implementing the
> do_compile task to generate those files, assuming not implementing the
> deploying tasks, nothing gets integrated in the final image.
>
> Therefore the debugger tool could go to build/work/temp/…/myrecipe/…
> (WORKDIR of the recipe) as a startpoint for such scripts.
>
> 2 Questions:
>
> -          There would be a better solution for this task?
> -          The task has not been as successfully as expected. Ideally I
> would access variables of other recipes to know where they are their
> output/intermediate files. E.g. location of an elf file for u-boot. Is there
> any way around this?
>

There are ways implemented e.g. you can generate an image tarball in two pieces
1. binaries
2. Associated debug info and symbols

The untar both in same place.

Point your cross gdb to this location via setting appropriate sysroot
in .gdbinit
and that will be it.

However its not clear if thats what you are looking for. If you want to point to
components build directory instead of a full rootfs then you have to enhacne
the .gdbinit a bit more.

I am assuming that gdb is the debugging tool you are trying to use

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

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

Re: [yocto] [meta-chip][PATCH] added md5 for ntc's modified u-boot Licences/README file.

[Valentin Le bescond]

Cool,

By the way @Olivier, did you manage to flash the board at some point ?
I spent a hole weekend trying to...

Le lun. 22 févr. 2016 à 19:00, Khem Raj  a écrit :

> On Sun, Feb 21, 2016 at 4:30 AM, Valentin Le bescond
>  wrote:
> > Hi, sorry it was my first (tiny) try at a contribution ... Should I have
> > explained more in the title ?
> >
> > Next Thing Co changed the Licences/README file in their repo.
> > And in the u-boot.inc file used by u-boot-chip, this file is chekced with
> > LIC_FILES_CHKSUM. And so it doesn't build without a modification of the
> md5.
> > That's it !
> >
>
> hmmm ok.
>
> >
> > Le sam. 20 févr. 2016 à 20:09, Khem Raj  a écrit :
> >>
> >> On Sat, Feb 20, 2016 at 8:25 AM, Valentin LE BESCOND
> >>  wrote:
> >> > From: Nitnelav 
> >> >
> >> > Signed-off-by: Nitnelav 
> >> > ---
> >> >  recipes-bsp/u-boot/u-boot-chip_git.bb | 2 ++
> >> >  1 file changed, 2 insertions(+)
> >> >
> >> > diff --git a/recipes-bsp/u-boot/u-boot-chip_git.bb
> >> > b/recipes-bsp/u-boot/u-boot-chip_git.bb
> >> > index 2342478..0b9032f 100644
> >> > --- a/recipes-bsp/u-boot/u-boot-chip_git.bb
> >> > +++ b/recipes-bsp/u-boot/u-boot-chip_git.bb
> >> > @@ -8,6 +8,8 @@ PROVIDES += "u-boot"
> >> >  UBOOT_VERSION ?= "2015.07"
> >> >  PV = "${UBOOT_VERSION}+git${SRCPV}"
> >> >
> >> > +LIC_FILES_CHKSUM =
> >> > "file://Licenses/README;md5=0507cd7da8e7ad6d6701926ec9b84c95"
> >> > +
> >>
> >> while checksumming more is merrier, it would be good to know why we
> >> should check for this one ?
> >>
> >> >  SRCREV ?= "854d5fcc641d8d8914c03a69d7172815d5b81a99"
> >> >  BRANCH ?= "chip/stable"
> >> >  SRC_URI =
> >> > "git://github.com/NextThingCo/CHIP-u-boot.git;branch=${BRANCH}
> "
> >> > --
> >> > 1.9.1
> >> >
> >> > --
> >> > ___
> >> > yocto mailing list
> >> > yocto@yoctoproject.org
> >> > https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto