date:20141212

[yocto] [meta-cgl][PATCH] ocfs2-tools: add new recipe

2014-12-12 Thread Li xin

Programs to manage the Ocfs2 cluster file system, including
mkfs.ocfs2,tunefs.ocfs2 and fsck.ocfs2

Signed-off-by: Li Xin 
---
 ...ocfs2_controld-Makefile-fix-compile-error.patch |  62 +++
 ...cfs2_fs.h-mount.ocfs2.c-fix-compile-error.patch |  51 +++
 ...-vendor-common-o2cb.ocf-add-new-conf-file.patch | 478 +
 .../ocfs2-tools/ocfs2-tools/cluster.conf.sample|  10 +
 .../ocfs2-tools/ocfs2-tools/o2cb.service   |  12 +
 .../ocfs2-tools/ocfs2-tools/ocfs2.service  |  13 +
 .../recipes-cgl/ocfs2-tools/ocfs2-tools_1.4.3.bb   |  77 
 7 files changed, 703 insertions(+)
 create mode 100644 
meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/0001-ocfs2_controld-Makefile-fix-compile-error.patch
 create mode 100644 
meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/0002-ocfs2_fs.h-mount.ocfs2.c-fix-compile-error.patch
 create mode 100644 
meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/0003-vendor-common-o2cb.ocf-add-new-conf-file.patch
 create mode 100644 
meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/cluster.conf.sample
 create mode 100644 
meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/o2cb.service
 create mode 100644 
meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/ocfs2.service
 create mode 100644 meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.4.3.bb

diff --git 
a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/0001-ocfs2_controld-Makefile-fix-compile-error.patch
 
b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/0001-ocfs2_controld-Makefile-fix-compile-error.patch
new file mode 100644
index 000..c30f38f
--- /dev/null
+++ 
b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/0001-ocfs2_controld-Makefile-fix-compile-error.patch
@@ -0,0 +1,62 @@
+From 865444fb9ecfe5b0050075f986a328701aa3d580 Mon Sep 17 00:00:00 2001
+From: Li xin 
+Date: Fri, 12 Dec 2014 16:11:43 +0900
+Subject: [PATCH 1/3] ocfs2_controld/Makefile: fix compile error
+
+ERROR: This autoconf log indicates errors, it looked at host
+include and/or library paths while determining system capabilities.
+
+Upstream-Status: pending
+
+Signed-off-by: Li Xin 
+---
+ ocfs2_controld/Makefile| 4 ++--
+ ocfs2_controld/pacemaker.c | 3 ++-
+ 2 files changed, 4 insertions(+), 3 deletions(-)
+
+diff --git a/ocfs2_controld/Makefile b/ocfs2_controld/Makefile
+index 52aa493..b530d72 100644
+--- a/ocfs2_controld/Makefile
 b/ocfs2_controld/Makefile
+@@ -17,7 +17,7 @@ SBIN_PROGRAMS += ocfs2_controld.pcmk
+ PCMK_INCLUDES = -I/usr/include/pacemaker -I/usr/include/heartbeat/ 
$(GLIB_CFLAGS)
+ endif
+ 
+-INCLUDES = -I$(TOPDIR)/include -I. $(PCMK_INCLUDES)
++INCLUDES = -I/usr/include/libxml2 -I$(TOPDIR)/include -I. $(PCMK_INCLUDES)
+ LIBO2CB_LIBS = -L$(TOPDIR)/libo2cb -lo2cb
+ LIBO2CB_DEPS = $(TOPDIR)/libo2cb/libo2cb.a
+ LIBOCFS2_LIBS = -L$(TOPDIR)/libocfs2 -locfs2
+@@ -67,7 +67,7 @@ DIST_FILES = \
+ ocfs2_controld.pcmk: $(PCMK_DAEMON_OBJS) $(LIBO2CB_DEPS)
+   $(LINK) $(GLIB_LIBS) $(LIBO2CB_LIBS) $(COM_ERR_LIBS) \
+   $(OPENAIS_LIBS) $(COROSYNC_LIBS) \
+-  $(DLMCONTROL_LIBS) -lcrmcluster -lstonithd
++  $(DLMCONTROL_LIBS) -lcrmcluster -lcrmcommon
+ 
+ ocfs2_controld.cman: $(CMAN_DAEMON_OBJS) $(LIBO2CB_DEPS)
+   $(LINK) $(LIBO2CB_LIBS) $(COM_ERR_LIBS) $(OPENAIS_LIBS) \
+diff --git a/ocfs2_controld/pacemaker.c b/ocfs2_controld/pacemaker.c
+index 8df1052..1361b13 100644
+--- a/ocfs2_controld/pacemaker.c
 b/ocfs2_controld/pacemaker.c
+@@ -22,6 +22,7 @@
+ 
+ #include 
+ 
++#include 
+ #include 
+ /* heartbeat support is irrelevant here */
+ #undef SUPPORT_HEARTBEAT
+@@ -155,7 +156,7 @@ int setup_stack(void)
+   crm_log_init("ocfs2_controld", LOG_INFO, FALSE, TRUE, 0, NULL);
+ 
+   if(init_ais_connection(NULL, NULL, NULL, &local_node_uname, 
&our_nodeid) == FALSE) {
+-  log_error("Connection to our AIS plugin (%d) failed", 
CRM_SERVICE);
++  log_error("Connection to our AIS plugin (%d) failed", 
PCMK_SERVICE);
+   return -1;
+   }
+ 
+-- 
+1.8.4.2
+
diff --git 
a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/0002-ocfs2_fs.h-mount.ocfs2.c-fix-compile-error.patch
 
b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/0002-ocfs2_fs.h-mount.ocfs2.c-fix-compile-error.patch
new file mode 100644
index 000..799eb45
--- /dev/null
+++ 
b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/0002-ocfs2_fs.h-mount.ocfs2.c-fix-compile-error.patch
@@ -0,0 +1,51 @@
+From 507f5cf55e25fd12d138cc28eb061c7e0b8615b8 Mon Sep 17 00:00:00 2001
+From: Li xin 
+Date: Fri, 12 Dec 2014 16:14:10 +0900
+Subject: [PATCH 2/3] ocfs2_fs.h mount.ocfs2.c: fix compile error
+
+Upstream-Status: pending
+
+Signed-off-by: Li Xin 
+---
+ include/ocfs2-kernel/ocfs2_fs.h | 2 +-
+ mount.ocfs2/mount.ocfs2.c   | 4 +++-
+ 2 files changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/include/ocfs2-kernel/ocfs2_fs.h b/include/ocfs2-kernel/ocfs2_fs.h
+index 2140bb3..00add7b 100644
+--- a/include/ocfs2-kern

[yocto] How long are stable branches maintained?

2014-12-12 Thread Vuille, Martin (Martin)

I have read the information at 
https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance

I would like to know how long stable branches are maintained.

If we are using daisy (1.6), how long can we count on point releases with
security patches before we should plan to upgrade to a newer release?

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

[yocto] Package Feature compile/runtime dependency

2014-12-12 Thread Koehler, Yannick (HP Networking)

I played with the system yesterday and find Yocto to be great.  Being a Gentoo 
user, I love the approach taken and see lots of enhancements made.  The biggest 
one is that fact that some packages, like the kernel and glibc got break down 
in a set of feature that can be better controlled than manually setting their 
configuration.  But, this added flexibility create a new level of 
inter-dependencies, which I think Yocto would gain to add support for.  Here is 
an example, if I add system to poky-tiny, it won't compile, and once I fix 
that, it won't boot.  The reason is that systemd package depends not only on 
other user-space package, but also on kernel features as well as glibc feature 
just to compile.  There is also other dependency at runtime for certain 
functionality as well.

Yocto already has a package dependency mechanism with DEPEND and RDEPEND, it 
would be great if we could somehow tie this with feature as well:

DEPENDS="package:feature"
RDEPENDS="package:feature"

This would allow to provide better error indication to the Yocto end-user when 
playing with distro/image and new combination. I could see system dependency 
added like this:


DEPENDS="linux-yocto-tiny:fhandle,autofs4,ipv6?,devtmpfs,libc:ftraverse,posix-clang-wchar,spawn,utmpx"

Etc...  Disregard the syntax as it is simply an idea/example and not intended 
as a specification.

Anyway, I am just sharing because I feel this system is really well done, and 
see this as an opportunity to get it to another level.

--
Yannick Koehler


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

Re: [yocto] Package Feature compile/runtime dependency

2014-12-12 Thread Burton, Ross

On 12 December 2014 at 14:13, Koehler, Yannick (HP Networking) <
yannick.koeh...@hp.com> wrote:
>
>
> DEPENDS="linux-yocto-tiny:fhandle,autofs4,ipv6?,devtmpfs,libc:ftraverse,posix-clang-wchar,spawn,utmpx"
>
> Etc...  Disregard the syntax as it is simply an idea/example and not
> intended as a specification.
>

A lot of those features are DISTRO_FEATURES, so there should be heavier
user of the distro_features_check class.  For example, there are recipes
that require systemd to be used, so they set
REQUIRED_DISTRO_FEATURES=systemd.

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

Re: [yocto] Package Feature compile/runtime dependency

2014-12-12 Thread Koehler, Yannick (HP Networking)

It would definitely make sense to have a distro level feature called 
init-busyboxinit/init-sysvinit/init-systemd/init-upstart or something along 
those line.  Is this already in place?

It would then have to pull the package and their appropriate package feature 
set to get there.

Yannick Koehler
HP Networking Mobility

De : Burton, Ross [mailto:ross.bur...@intel.com] 
Envoyé : December-12-14 9:56 AM
À : Koehler, Yannick (HP Networking)
Cc : yocto@yoctoproject.org
Objet : Re: [yocto] Package Feature compile/runtime dependency


On 12 December 2014 at 14:13, Koehler, Yannick (HP Networking) 
 wrote:
        
DEPENDS="linux-yocto-tiny:fhandle,autofs4,ipv6?,devtmpfs,libc:ftraverse,posix-clang-wchar,spawn,utmpx"

Etc...  Disregard the syntax as it is simply an idea/example and not intended 
as a specification.

A lot of those features are DISTRO_FEATURES, so there should be heavier user of 
the distro_features_check class.  For example, there are recipes that require 
systemd to be used, so they set REQUIRED_DISTRO_FEATURES=systemd.

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

Re: [yocto] Package Feature compile/runtime dependency

2014-12-12 Thread Anders Darander

* Koehler, Yannick (HP Networking)  [141212 16:11]:

> It would definitely make sense to have a distro level feature called
> init-busyboxinit/init-sysvinit/init-systemd/init-upstart or something
> along those line.  Is this already in place?

We have sysvinit and systemd as distro features today.

Cheers,
Anders

-- 
Anders Darander
ChargeStorm AB / eStorm AB
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Using anonymous python function to define variables

2014-12-12 Thread Ulf Winberg

Thanks! Using python as a function with return value solved it.

When bb.parse.SkipPackage is used, there seems to be no warning when
building. Does the text I wrote end up in a log somewhere?

I was testing the SOMEVAR example you give. Am I right to assume that the
overrides only works for gobal variables, already defined elsewhere? I was
not able to define one myself and use the overrides.

Cheers,
Ulf

On Mon, Dec 8, 2014 at 10:41 AM, Paul Eggleton <
paul.eggle...@linux.intel.com> wrote:
>
> Hi Ulf,
>
> On Sunday 07 December 2014 12:22:06 Ulf Winberg wrote:
> > I'm struggling with trying to dynamically set a file name, to be used
> with
> > "require". See code below:
> >
> > python () {
> >TA = d.getVar('TARGET_ARCH', True)
> >if TA == "arm":
> >javaPkg = "oracle-jse-ejre-arm-vfp-hflt-client-headless"
> >elif TA == "i586":
> >javaPkg = "oracle-jse-jre-i586"
> >elif TA == "x86_64":
> >javaPkg = "oracle-jse-jre-x86-64"
> >else:
> >raise Exception("Target architecture '%s' is not supported
> > by the meta-oracle-java layer" %TA)
> >d.setVar('JAVA_PKG', javaPkg)
> > }
> >
> > require ${JAVA_PKG}.inc
> >
> > The python function executes properly (if I print javaPkg, it shows up
> > correctly) but the "JAVA_PKG" variable does not become available for
> > "require". From what I can read in section 3.4.4 in this link
> > <
> http://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manua
> > l.html>, it seems to me it should work. Could someone please explain to
> me
> > why it doesn't?
>
> I'm pretty sure this is because anonymous functions don't get executed
> until
> finalize() is called, which is towards the end of parsing; the "require"
> statement must be handled immediately. Try this instead:
>
>  snip 
>
> def get_java_package(d):
> TA = d.getVar('TARGET_ARCH', True)
> if TA == "arm":
> javaPkg = "oracle-jse-ejre-arm-vfp-hflt-client-headless"
> elif TA == "i586":
> javaPkg = "oracle-jse-jre-i586"
> elif TA == "x86_64":
> javaPkg = "oracle-jse-jre-x86-64"
> else:
> raise bb.parse.SkipPackage("Target architecture '%s' is not
> supported
> by the meta-oracle-java layer" % TA)
> return javaPkg
>
> JAVA_PKG = "${@get_java_package(d)}"
>
> require ${JAVA_PKG}.inc
>
>  snip 
>
> The question is though, do you really need a separate inc file for each
> architecture? You can use overrides for this sort of thing e.g.:
>
>  snip 
>
> SOMEVAR = "default value"
> SOMEVAR_arm = "value if arm"
> SOMEVAR_x86-64 = "value if x86-64"
>
>  snip 
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] prelink & mklibs problem

2014-12-12 Thread Mark Hatle

On 12/12/14, 12:57 AM, Qiang Yu wrote:

Hi Mark,

I have used the 81bab23a4661fdaaa859325d6d3603__811ecf1849 version prelink to
build my image.
Prelink run smoothly without output like before, the image is also modified, so
the prelink works.
My application also run correctly. But how can I make sure the prelink take
effect when I start an
executable?

Here attaches the do_rootfs log:
NOTE: ## Generate images ###
NOTE: Executing mklibs_optimize_image ...
DEBUG: Executing shell function mklibs_optimize_image
DEBUG: Shell function mklibs_optimize_image finished
NOTE: Executing prelink_image ...
DEBUG: Executing shell function prelink_image
Size before prelinking 49340.
Size after prelinking 49592.
DEBUG: Shell function prelink_image finished

You can verify the binary has been prelinked via a number of steps:

*) Start with the size comparison, you should see it change.  (It did, so thats 
good)

*) Look at a binary in your image, such as /bin/busybox, look for the 
'.gnu.prelink_undo' section:

  objdump -x bin/busybox

 29 .gnu.prelink_undo 0900      000b1b48  
2**3
  CONTENTS, READONLY

*) Switch to comparing a library, i.e. /lib64/libc.so.6:

readelf -S bin/libc.so.6

Compare the original to the rootfs filesystem.  You'll see the Address values 
have changed.  On the target system you can look at "/proc/self/maps" and grep 
'libc'  You'll see the load range, it should match the one from the readelf -S 
output.

*) Actually gather load time statistics from ld.so:

Probably the easiest of the methods..  but requires you to actually run the 
binaries in question to check behavior.  On the target:

LD_DEBUG=statistics 

With prelink working the result will be something like:

root@qemu12:~# LD_DEBUG=statistics /bin/busybox
   126:  number of relocations: 0
   126:   number of relocations from cache: 21
   126: number of relative relocations: 0

(output)

   126:
   126: runtime linker statistics:
   126:final number of relocations: 0
   126: final number of relocations from cache: 21

vs w/o prelink:

root@qemu12:~# LD_DEBUG=statistics /bin/busybox
   174:  number of relocations: 126
   174:   number of relocations from cache: 0
   174: number of relative relocations: 0

(output)

   174:
   174: runtime linker statistics:
   174:final number of relocations: 140
   174: final number of relocations from cache: 0

--Mark

Regards,
Qiang

On Thu, Dec 11, 2014 at 7:09 AM, Mark Hatle mailto:mark.ha...@windriver.com>> wrote:

On 12/9/14, 9:01 PM, Mark Hatle wrote:

On 12/9/14, 8:41 PM, Qiang Yu wrote:

I have submitted a bug here:
https://bugzilla.yoctoproject.__org/show_bug.cgi?id=7056

(Responded in the bug as well...)  I have a test version of the cross
prelink
with the ARM HF patch available, as commit:

2cde4ff118b5244f5577d9bc585c1e__e521740af0

To enable it, use the following in your local.conf:

SRCREV_pn-prelink = "__2cde4ff118b5244f5577d9bc585c1e__e521740af0"

That link breaks regular arm prelink, it also missed a patch for the
prelink-rtld.

Got a new one:

SRCREV_pn-prelink = "__81bab23a4661fdaaa859325d6d3603__811ecf1849"

--Mark

If this works for you, I'll finish the patch and submit the changes.

--Mark

Regards,
Qiang

On Tue, Dec 9, 2014 at 11:51 PM, Mark Hatle
mailto:mark.ha...@windriver.com>
>> wrote:

  On 12/8/14, 3:55 AM, Jegan Chandru wrote:

  I recommend you to file a bug here
https://bugzilla.yoctoproject.org/
  > if not
  done already. You may get a proper answer on armhf support
there. From
  what I
  see, (someone please correct me if I am wrong), there is
no prelink
  dynamic link
  armhf patch. You can also create and submit the patch for
review. AFAIK,
  you are
  gonna need to something like below,

  .dynamic_linker = "/lib/ld-linux-armhf.so.3" in 
arch-arm.c.

  This is not tested though. Please do a test yourselves.

  See: http://marc.info/?l=fedora-arm&m=135417053128837&w=2

Re: [yocto] Package Feature compile/runtime dependency

2014-12-12 Thread Koehler, Yannick (HP Networking)

I just realize that I am using it, and it doesn't work the way I thought it 
would.

I added 

DISTRO_FEATURES_append = " systemd"
VIRTUAL-RUNTIME_init_manager = "systemd"

DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
VIRTUAL-RUNTIME_initscripts = ""

As part of my distro.cfg file and the build was failing, due to missing 
libc/kernel features, it appears that the DISTRO_FEATURE simply added 
additional package, which seems to highlight the need to have feature <-> 
feature dependency.

I add to also add this to my distro.cfg to get things there:

DISTRO_FEATURES_LIBC = "${DISTRO_FEATURES_LIBC_TINY} \
${DISTRO_FEATURES_LIBC_MINIMAL} \
${DISTRO_FEATURES_LIBC_REGEX} \
${DISTRO_FEATURES_LIBC_NET} \
libc-ftraverse \
libc-posix-clang-wchar \
libc-posix-wchar-io \
libc-spawn \
libc-locale-code \
libc-utmpx \
   "

And create a systemd.cfg for the linux-yocto-tiny kernel to include those

CONFIG_AUTOFS4_FS=y
CONFIG_TIMERFD=y
CONFIG_FHANDLE=y
CONFIG_DEVTMPFS=y
CONFIG_INOTIFY_USER=y
CONFIG_FANOTIFY=y
CONFIG_SECCOMP=n
CONFIG_DMIID=y
CONFIG_TMPFS=y
CONFIG_PROC_SYSCTL=y

My hope, was that somehow, adding systemd to DISTRO_FEATURE would not only add 
the packages I need, but also add feature to some package like the kernel/libc 
that are required by such addition.

Yannick Koehler
HP Networking Mobility

-Message d'origine-
De : Anders Darander [mailto:and...@chargestorm.se] 
Envoyé : December-12-14 10:19 AM
À : Koehler, Yannick (HP Networking)
Cc : Burton, Ross; yocto@yoctoproject.org
Objet : Re: [yocto] Package Feature compile/runtime dependency

* Koehler, Yannick (HP Networking)  [141212 16:11]:

> It would definitely make sense to have a distro level feature called 
> init-busyboxinit/init-sysvinit/init-systemd/init-upstart or something 
> along those line.  Is this already in place?

We have sysvinit and systemd as distro features today.

Cheers,
Anders

--
Anders Darander
ChargeStorm AB / eStorm AB
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How long are stable branches maintained?

2014-12-12 Thread Khem Raj


> On Dec 12, 2014, at 5:48 AM, Vuille, Martin (Martin)  
> wrote:
> 
> I have read the information at 
> https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance 
> 
>  
> I would like to know how long stable branches are maintained.
>  

as long as patches are actively sent. for more details see

https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance

> If we are using daisy (1.6), how long can we count on point releases with
> security patches before we should plan to upgrade to a newer release?
>  


> MV
> -- 
> ___
> 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-cgl][PATCH] samhain: add new recipe

2014-12-12 Thread akuster808

Thanks for the updates. I jut got back from vacation and will look into 
the changes soon.


- Armin

On 12/10/2014 11:51 PM, Alexandru Vaduva wrote:

Now I did. :D


On Thursday, December 11, 2014 9:21 AM, Alexandru Vaduva
 wrote:


Thanks Joe,

I added Armin for to this discussion as a head-up regarding those
updates, since it was the one working on samhain recipe on meta-security.


Alex Vaduva


On Thursday, December 11, 2014 2:48 AM, Joe MacDonald
 wrote:


[[yocto] [meta-cgl][PATCH] samhain: add new recipe] On 14.12.10 (Wed
16:33) Li xin wrote:

 > Samhain is an open source file integrity and intrusion detection
 > system for Unix that uses cryptographic checksums of files to
 > detect modifications, and allows you to trace: what changes have
 > occured in your system, when these changes have occured, and who
 > was logged into the system at the respective time.

Samhain is already in meta-security at the same version (though without
the patch you've included here.)

Since meta-cgl depends on meta-security today, I think you probably
should submit whatever updates are appropriate to the samhain recipe
to meta-security, so as to avoid duplicating / diverging recipes.

-J.


 >
 > Signed-off-by: Li Xin mailto:lixin.f...@cn.fujitsu.com>>
 > ---
 >  .../samhain/0001-Makefile.in-error-fix.patch  | 31 
 >  .../samhain/samhain/config-site.samhain-3.1.3  |  2 +
 >  .../recipes-cgl/samhain/samhain_3.1.3.bb  | 58
++
 >  3 files changed, 91 insertions(+)
 >  create mode 100644
meta-cgl-common/recipes-cgl/samhain/samhain/0001-Makefile.in-error-fix.patch
 >  create mode 100644
meta-cgl-common/recipes-cgl/samhain/samhain/config-site.samhain-3.1.3
 >  create mode 100644 meta-cgl-common/recipes-cgl/samhain/samhain_3.1.3.bb
 >
 > diff --git
a/meta-cgl-common/recipes-cgl/samhain/samhain/0001-Makefile.in-error-fix.patch
b/meta-cgl-common/recipes-cgl/samhain/samhain/0001-Makefile.in-error-fix.patch
 > new file mode 100644
 > index 000..cd646f6
 > --- /dev/null
 > +++
b/meta-cgl-common/recipes-cgl/samhain/samhain/0001-Makefile.in-error-fix.patch
 > @@ -0,0 +1,31 @@
 > +From a9ce38c56bf7072f292d685a48b912e6e59260a6 Mon Sep 17 00:00:00 2001
 > +From: Li xin mailto:lixin.f...@cn.fujitsu.com>>
 > +Date: Wed, 10 Dec 2014 14:45:28 +0900
 > +Subject: [PATCH] Makefile.in: error fix
 > +
 > +error:File '/usr/sbin/samhain' from samhain was already stripped,
 > +this will prevent future debugging!
 > +
 > +Upstream-Status: pending
 > +
 > +Signed-off-by: Li Xin mailto:lixin.f...@cn.fujitsu.com>>
 > +---
 > + Makefile.in | 2 +-
 > + 1 file changed, 1 insertion(+), 1 deletion(-)
 > +
 > +diff --git a/Makefile.in b/Makefile.in
 > +index b1904d9..000de49 100644
 > +--- a/Makefile.in
 >  b/Makefile.in
 > +@@ -54,7 +54,7 @@ selectconfig = @selectconfig@
 > + top_builddir = .
 > +
 > + INSTALL = @INSTALL@
 > +-INSTALL_PROGRAM = @INSTALL@ -s -m 700
 > ++INSTALL_PROGRAM = @INSTALL@ -m 700
 > + INSTALL_SHELL = @INSTALL@ -m 700
 > + INSTALL_DATA = @INSTALL@ -m 600
 > + INSTALL_MAN = @INSTALL@ -m 644
 > +--
 > +1.8.4.2
 > +
 > diff --git
a/meta-cgl-common/recipes-cgl/samhain/samhain/config-site.samhain-3.1.3
b/meta-cgl-common/recipes-cgl/samhain/samhain/config-site.samhain-3.1.3
 > new file mode 100644
 > index 000..2ce3769
 > --- /dev/null
 > +++
b/meta-cgl-common/recipes-cgl/samhain/samhain/config-site.samhain-3.1.3
 > @@ -0,0 +1,2 @@
 > +ssp_cv_lib=no
 > +sh_cv_va_copy=yes
 > diff --git a/meta-cgl-common/recipes-cgl/samhain/samhain_3.1.3.bb
b/meta-cgl-common/recipes-cgl/samhain/samhain_3.1.3.bb
 > new file mode 100644
 > index 000..22c8577
 > --- /dev/null
 > +++ b/meta-cgl-common/recipes-cgl/samhain/samhain_3.1.3.bb
 > @@ -0,0 +1,58 @@
 > +SUMMARY = "File Integrity and Intrusion Detection System"
 > +DESCRIPTION = "Samhain is an open source file integrity and
intrusion detection \
 > +system for Unix that uses cryptographic checksums of files to \
 > +detect modifications, and allows you to trace: what changes have \
 > +occured in your system, when these changes have occured, and who \
 > +was logged into the system at the respective time."
 > +
 > +HOMEPAGE = "http://la-samhna.de/samhain/";
 > +SECTION = "Filesystem"
 > +
 > +SRC_URI =
"http://la-samhna.de/samhain/samhain-current.tar.gz;extract=samhain-3.1.3.tar.gz
\
 > +  file://0001-Makefile.in-error-fix.patch"
 > +SRC_URI[md5sum] = "64572a4dbfdc8065d6e9f7ca0eab0a34"
 > +SRC_URI[sha256sum] =
"c234afaf9ba3c6b7d240858b74423f935185de66e996405b3016ec4a288a7e1e"
 > +LICENSE = "GPLv2"
 > +LIC_FILES_CHKSUM = "file://LICENSE;md5=8ca43cbc842c2336e835926c2166c28b"
 > +
 > +DEPENDS = "libpthread-stubs acl zlib attr"
 > +inherit autotools-brokensep pkgconfig
 > +
 > +do_unpack2() {
 > +cd ${WORKDIR}
 > +tar zxvf ${PN}-${PV}.tar.gz
 > +}
 > +
 > +S = "${WORKDIR}/${BP}"
 > +
 > +addtask unpack2 after do_unpack before do_patch
 > +do_configure() {
 >

Re: [yocto] How long are stable branches maintained?

2014-12-12 Thread Mark Hatle


On 12/12/14, 7:48 AM, Vuille, Martin (Martin) wrote:

I have read the information at
https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance

I would like to know how long stable branches are maintained.

If we are using daisy (1.6), how long can we count on point releases with

security patches before we should plan to upgrade to a newer release?


Rough rule of thumb is the Yocto Project will support two releases at the same 
time, and releases occur roughly every 6 months.  So about 1 year from the time 
of release.  For instance:


Release - Version - EOL
Fall 2014   - YP 1.7  -
Spring 2014 - YP 1.6  -
Fall 2013   - YP 1.5  - (Fall 2014)
Spring 2013 - YP 1.4  - Spring 2014
Fall 2012   - YP 1.3  - Fall 2013
Spring 2012 - YP 1.2  - Spring 2013
Fall 2011   - YP 1.1  - Fall 2012
Spring 2011 - YP 1.0  - Spring 2012
Fall 2010   - YP 0.9  - Fall 2011

As I said, this is a rule of thumb.  We recently released some updates to 1.5 to 
help close out the work and deal with some security defects.


But I wouldn't expect any further releases.  The maintainer of the branch may 
choose to include fixes submitted by community members, but is not under any 
obligation to.


If you are looking for support longer then the '2 release cycle', I strongly 
suggest that you look at a commercial OSV, or another commercial resource as 
they will be better at helping you with longer term issues.


--Mark


MV





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

[yocto] [ANNOUNCEMENT] Yocto Project 1.5.4 (dora 10.0.4) now available.

2014-12-12 Thread Flanagan, Elizabeth

All,

I am pleased to announce the next point release for the dora branch,
Yocto Project 1.5.4 (dora 10.0.4). A full pass test report is
available at:

https://wiki.yoctoproject.org/wiki/WW48_-_2014-11-25_
_Full_Pass_Release_Dora_1.5.4

Several fixes for CVE-2014-3566 (the SSL Poodle vulnerability) have
been applied to OpenSSL in this release; however, due to the nature of
the vulnerability you will need to ensure that SSL 3.0 support is
either disabled, or alternatively that TLS_FALLBACK_SCSV is
implemented in both clients and servers that use TLS/SSL.

For more information, check with the upstream provider of TLS/SSL
client / server software that you are using.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566
https://www.us-cert.gov/ncas/alerts/TA14-290A

Downloads are available at:
http://downloads.yoctoproject.org/releases/yocto/yocto-1.5.4/poky-dora-10.0.4.tar.bz2



Release Name: poky-dora-10.0.4
Branch: dora
Tag: dora-10.0.4
Hash: e035c59d7d331ddaeff19b069169567af5e6f8ac
md5sum: e3d2250514c68b038640c65c19d9038c
Download: 
http://downloads.yoctoproject.org/releases/yocto/yocto-1.5.4/poky-dora-10.0.4.tar.bz2

Release Name: eclipse-poky-juno-dora-10.0.4
Branch: dora
Tag: dora-10.0.4
Hash: 79cd3c6ff119526f3f85567253450d2e857afed0
md5sum: 01c3e68daa8e337d3aa70b0512cff79d
Download: 
http://downloads.yoctoproject.org/releases/yocto/yocto-1.5.4/eclipse-poky-juno-dora-10.0.4.tar.bz2

Release Name: eclipse-poky-kepler-dora-10.0.4
Branch: dora
Tag: dora-10.0.4
Hash: e2cc15b1549d197ab15073f52274401d0fd86686
md5sum: 99f144fbee42289c7cfd7283d8be3a9e
Download: 
http://downloads.yoctoproject.org/releases/yocto/yocto-1.5.4/eclipse-poky-kepler-dora-10.0.4.tar.bz2

Release Name: meta-qt3-dora-10.0.4
Branch: dora
Tag: dora-10.0.4
Hash: 4772424ab69908d4e3b9d6d4717ca889468e6acd
md5sum: 7843a578d15202d6e4603d3cea09392d
Download: 
http://downloads.yoctoproject.org/releases/yocto/yocto-1.5.4/meta-qt3-dora-10.0.4.tar.bz2

Security Fixes
-
openssl: Fix for CVE-2014-3568
openssl: Fix for CVE-2014-3567
openssl: Fix for CVE-2014-3513
openssl: Fix for CVE-2014-3566
bash: Fix-for-CVE-2014-6278
bash: Fix for CVE-2014-6277
bash: Fix for CVE-2014-7186 and CVE-2014-7187
bash: add missing patch for CVE-2014-7169 to 4.2 recipe
bash: add missing patch for CVE-2014-6271 to 4.2 recipe
bash: Fix CVE-2014-7169
bash: fix CVE-2014-6271

Bug Fixes
-
documentation: Updated the date in Manual Revision History table
yocto-bsp: Update qemu inclusion lists
build-appliance-image: Update to dora head revision
poky: Update version to 1.5.4
build-appliance-image: Update to dora head revision
systemtap: fix do_compile failed on fedora21
ltp: Added zip-native as a DEPENDS
package.bbclass: Add CONFFILES to list of package specific variables
profile-manual: Updates to the LTTng Documentation section.
build-appliance-image: Update to dora head revision
build-appliance-image: Update to daisy head revision
poky.ent: Updated the YOCTO_RELEASE_NOTES variable.
bash: Fix for exported function namespace change
apmd.service: Fix typo (not mandatory EnvironmentFile prefix)
documentation: Steps to prepare for 1.5.4 YP doc set.
qt4: Fix Qt 4.8.5 source to new location
gcc-4.8: backport fix for ICE when building opus
cairo: explicitly disable LTO support by backporting patch which removes it
binutils: Fix building nativesdk binutils with gcc 4.9
ref-manual: Updated note in the "CentOS Packages" section.
dev-manual: Fixed broken link to MACHINE variable.
dev-manual: Updates to the "Creating Partitioned Images" section.

Notes
-
- The source archiver code is not functional.

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

[yocto] [meta-cgl][PATCH] ocfs2-tools: add new recipe

[yocto] How long are stable branches maintained?

[yocto] Package Feature compile/runtime dependency

Re: [yocto] Package Feature compile/runtime dependency

Re: [yocto] Package Feature compile/runtime dependency

Re: [yocto] Package Feature compile/runtime dependency

Re: [yocto] Using anonymous python function to define variables

Re: [yocto] prelink & mklibs problem

Re: [yocto] Package Feature compile/runtime dependency

Re: [yocto] How long are stable branches maintained?

Re: [yocto] [meta-cgl][PATCH] samhain: add new recipe

Re: [yocto] How long are stable branches maintained?

[yocto] [ANNOUNCEMENT] Yocto Project 1.5.4 (dora 10.0.4) now available.

13 matches

Site Navigation

Mail list logo

Footer information