[OE-core] [PATCH] initscripts: Fix regression for requiring /bin/bash
It is not possible to create a rootfs with only busybox + initscipts. This is a result of a regression from commit a4b53872a8a9a2743299acbff015f7f2750a69d6 (initscripts: add /sbin/sushell for systemd service debug-shell). The /sbin/sushell should just use /bin/sh else you end up with a problem when creating the end image with a failed smart transaction shown below: ERROR: Unable to install packages. Command '/proj/bitbake_build/tmp/sysroots/x86_64-linux/usr/bin/smart --quiet --data-dir=/proj/bitbake_build/tmp/work/qemuarma9-wrs-linux-gnueabi/wrlinux-image-glibc-small/1.0-r1/rootfs/var/lib/smart install -y dropbear@armv7at2_vfp hac@armv7at2_vfp run-postinsts@all kernel-modules@qemuarma9 packagegroup-core-boot@qemuarma9' returned 1: error: Can't install initscripts-1.0-r155.0@armv7at2_vfp: no package provides /bin/bash Signed-off-by: Jason Wessel jason.wes...@windriver.com --- .../initscripts/initscripts-1.0/sushell|4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-core/initscripts/initscripts-1.0/sushell b/meta/recipes-core/initscripts/initscripts-1.0/sushell index 7d96941..c319d95 100644 --- a/meta/recipes-core/initscripts/initscripts-1.0/sushell +++ b/meta/recipes-core/initscripts/initscripts-1.0/sushell @@ -1,5 +1,5 @@ -#!/bin/bash +#!/bin/sh -[ -z $SUSHELL ] SUSHELL=/bin/bash +[ -z $SUSHELL ] SUSHELL=/bin/sh exec $SUSHELL -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/3] fix uclibc build with security_flags.inc
Andre McCurdy (3): uclibc.inc: remove unused UCLIBC_EXTRA_LDFLAGS security_flags.inc: clear SECURITY_CFLAGS for uclibc uclibc.inc: avoid immediate expansion for UCLIBC_EXTRA_CFLAGS meta/conf/distro/include/security_flags.inc | 2 ++ meta/recipes-core/uclibc/uclibc.inc | 5 ++--- 2 files changed, 4 insertions(+), 3 deletions(-) -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] uclibc.inc: remove unused UCLIBC_EXTRA_LDFLAGS
Signed-off-by: Andre McCurdy armccu...@gmail.com
---
meta/recipes-core/uclibc/uclibc.inc | 1 -
1 file changed, 1 deletion(-)
diff --git a/meta/recipes-core/uclibc/uclibc.inc
b/meta/recipes-core/uclibc/uclibc.inc
index 08465c4..c483228 100644
--- a/meta/recipes-core/uclibc/uclibc.inc
+++ b/meta/recipes-core/uclibc/uclibc.inc
@@ -59,7 +59,6 @@ export V=2
#
CFLAGS_arm := ${@oe_filter_out('-fno-omit-frame-pointer', '${CFLAGS}', d)}
UCLIBC_EXTRA_CFLAGS := ${@oe_filter_out('(-I\S+|-i\S+)', '${CFLAGS}', d)}
-UCLIBC_EXTRA_LDFLAGS := ${@oe_filter_out('(-L\S+|-l\S+)', '${LDFLAGS}', d)}
do_compile_prepend () {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] uclibc.inc: avoid immediate expansion for UCLIBC_EXTRA_CFLAGS
If immediate variable expansion is used, then UCLIBC_EXTRA_CFLAGS can
sometimes be derived from a partially expanded value of CFLAGS.
One specific problem case occurs when security_flags.inc is used: CFLAGS
is evaluated before the SECURITY_CFLAGS_pn-uclibc over-ride has been
applied and therefore UCLIBC_EXTRA_CFLAGS ends up being based on the
default SECURITY_CFLAGS instead of the uclibc specific value.
Signed-off-by: Andre McCurdy armccu...@gmail.com
---
meta/recipes-core/uclibc/uclibc.inc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/uclibc/uclibc.inc
b/meta/recipes-core/uclibc/uclibc.inc
index c483228..3ed8b60 100644
--- a/meta/recipes-core/uclibc/uclibc.inc
+++ b/meta/recipes-core/uclibc/uclibc.inc
@@ -57,8 +57,8 @@ export V=2
# -On -fno-omit-frame-pointer ends up with GCC ICE on thumb as reported
# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44860
#
-CFLAGS_arm := ${@oe_filter_out('-fno-omit-frame-pointer', '${CFLAGS}', d)}
-UCLIBC_EXTRA_CFLAGS := ${@oe_filter_out('(-I\S+|-i\S+)', '${CFLAGS}', d)}
+CFLAGS_arm = ${@oe_filter_out('-fno-omit-frame-pointer', '${CFLAGS}', d)}
+UCLIBC_EXTRA_CFLAGS = ${@oe_filter_out('(-I\S+|-i\S+)', '${CFLAGS}', d)}
do_compile_prepend () {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] security_flags.inc: clear SECURITY_CFLAGS for uclibc
uclibc fails to build when security_flags.inc is used.
| i686-rdk-linux-uclibc-gcc -m32 -march=core2 -mtune=core2 -msse3
-mfpmath=sse --sysroot=/build-vbox32/tmp/sysroots/vbox32-tcbootstrap -Wl,-EL
-Wl,--sort-common -Wl,--sort-section=alignment -m32 -shared -Wl,--warn-common
-Wl,--warn-once -Wl,-z,combreloc -Wl,-z,relro -Wl,-z,now -Wl,--hash-style=gnu
-Wl,-z,defs -Wl,-init,__uClibc_init -Wl,-soname=libc.so.0 -nostdlib -o
lib/libuClibc-0.9.34-git.so -Wl,--whole-archive libc/libc_so.a
-Wl,--no-whole-archive ./lib/interp.os ./lib/ld-uClibc.so.0
./lib/uclibc_nonshared.a
/build-vbox32/tmp/sysroots/vbox32-tcbootstrap/usr/lib/i686-rdk-linux-uclibc/4.9.3/libgcc.a
| libc/libc_so.a(sigaction.os): In function `__libc_sigaction':
|
/build-vbox32/tmp/work/core2-32-rdk-linux-uclibc/uclibc/0.9.33+gitAUTOINC+48a0006012-r9/git/libc/sysdeps/linux/i386/sigaction.c:37:
undefined reference to `__stack_chk_guard'
|
/build-vbox32/tmp/work/core2-32-rdk-linux-uclibc/uclibc/0.9.33+gitAUTOINC+48a0006012-r9/git/libc/sysdeps/linux/i386/sigaction.c:49:
undefined reference to `__stack_chk_fail_local'
| collect2: error: ld returned 1 exit status
| make: *** [lib/libc.so] Error 1
Clearing SECURITY_CFLAGS completely may not be the best approach, but
it's the approach taken for glibc, so try it for uclibc too.
Signed-off-by: Andre McCurdy armccu...@gmail.com
---
meta/conf/distro/include/security_flags.inc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/conf/distro/include/security_flags.inc
b/meta/conf/distro/include/security_flags.inc
index 3724972..a107657 100644
--- a/meta/conf/distro/include/security_flags.inc
+++ b/meta/conf/distro/include/security_flags.inc
@@ -84,6 +84,8 @@ SECURITY_CFLAGS_pn-python-smartpm =
${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-python-numpy = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-tcl = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-tiff = ${SECURITY_NO_PIE_CFLAGS}
+SECURITY_CFLAGS_pn-uclibc =
+SECURITY_CFLAGS_pn-uclibc-initial =
SECURITY_CFLAGS_pn-valgrind = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-webkit-gtk = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-zlib = ${SECURITY_NO_PIE_CFLAGS}
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [poky][PATCH v6 0/3] Add patches for Gstreamer 1.4.5 base
Fix issue about gstreamer1.0-plugins-base -ssaparse: Enhance SSA text lines parsing. -subparse: Set need_segment after sink pad receive GST_EVENT_SEGMENT. -encodebin: Need more buffers in output queue for better performance. Yuqing Zhu (3): gstreamer1.0-plugins-base: Add ssaparse related patch gstreamer1.0-plugins-base: Add subparse related patch gstreamer1.0-plugins-base: Add encodebin related patch ...3-ssaparse-enhance-SSA-text-lines-parsing.patch | 225 + ...t-need_segment-after-sink-pad-received-GS.patch | 69 +++ ...eed-more-buffers-in-output-queue-for-bett.patch | 32 +++ .../gstreamer/gstreamer1.0-plugins-base_1.4.5.bb | 3 + 4 files changed, 329 insertions(+) create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0003-ssaparse-enhance-SSA-text-lines-parsing.patch create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0004-subparse-set-need_segment-after-sink-pad-received-GS.patch create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/encodebin-Need-more-buffers-in-output-queue-for-bett.patch -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [poky][PATCH v6 2/3] gstreamer1.0-plugins-base: Add subparse related patch
Set need_segment after sink pad receive GST_EVENT_SEGMENT.
Signed-off-by: Yuqing Zhu b54...@freescale.com
---
...t-need_segment-after-sink-pad-received-GS.patch | 69 ++
.../gstreamer/gstreamer1.0-plugins-base_1.4.5.bb | 1 +
2 files changed, 70 insertions(+)
create mode 100644
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0004-subparse-set-need_segment-after-sink-pad-received-GS.patch
diff --git
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0004-subparse-set-need_segment-after-sink-pad-received-GS.patch
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0004-subparse-set-need_segment-after-sink-pad-received-GS.patch
new file mode 100644
index 000..7813915
--- /dev/null
+++
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0004-subparse-set-need_segment-after-sink-pad-received-GS.patch
@@ -0,0 +1,69 @@
+From ed09c8fd2c9c2b5384b72cc70af3728be6694e64 Mon Sep 17 00:00:00 2001
+From: Mingke Wang mingke.w...@freescale.com
+Date: Thu, 19 Mar 2015 14:20:26 +0800
+Subject: [PATCH 4/4] subparse: set need_segment after sink pad received
+ GST_EVENT_SEGMENT
+
+subparse works in push mode, chain funciton will be called once
+up stream element finished the seeking and flushing.
+if set need_segment flag in src pad event handler, the segment
+event will be pushed earlier, result in the subtitle text will
+be send out to down stream from the beginning.
+
+Upstream-Status: Submitted [https://bugzilla.gnome.org/show_bug.cgi?id=747498]
+
+Signed-off-by: Mingke Wang mingke.w...@freescale.com
+
+diff --git a/gst/subparse/gstsubparse.c b/gst/subparse/gstsubparse.c
+old mode 100644
+new mode 100755
+index b565e93..7741ccc
+--- a/gst/subparse/gstsubparse.c
b/gst/subparse/gstsubparse.c
+@@ -266,22 +266,20 @@ gst_sub_parse_src_event (GstPad * pad, GstObject *
parent, GstEvent * event)
+ goto beach;
+ }
+
++ /* Apply the seek to our segment */
++ gst_segment_do_seek (self-segment, rate, format, flags,
++ start_type, start, stop_type, stop, update);
++
++ GST_DEBUG_OBJECT (self, segment after seek: % GST_SEGMENT_FORMAT,
++ self-segment);
++
+ /* Convert that seek to a seeking in bytes at position 0,
+ FIXME: could use an index */
+ ret = gst_pad_push_event (self-sinkpad,
+ gst_event_new_seek (rate, GST_FORMAT_BYTES, flags,
+ GST_SEEK_TYPE_SET, 0, GST_SEEK_TYPE_NONE, 0));
+
+- if (ret) {
+-/* Apply the seek to our segment */
+-gst_segment_do_seek (self-segment, rate, format, flags,
+-start_type, start, stop_type, stop, update);
+-
+-GST_DEBUG_OBJECT (self, segment after seek: % GST_SEGMENT_FORMAT,
+-self-segment);
+-
+-self-need_segment = TRUE;
+- } else {
++ if (!ret) {
+ GST_WARNING_OBJECT (self, seek to 0 bytes failed);
+ }
+
+@@ -1632,8 +1630,10 @@ gst_sub_parse_sink_event (GstPad * pad, GstObject *
parent, GstEvent * event)
+ gst_event_parse_segment (event, s);
+ if (s-format == GST_FORMAT_TIME)
+ gst_event_copy_segment (event, self-segment);
+- GST_DEBUG_OBJECT (self, newsegment (%s),
+- gst_format_get_name (self-segment.format));
++ GST_DEBUG_OBJECT (self, newsegment (%s) % GST_SEGMENT_FORMAT,
++ gst_format_get_name (self-segment.format), self-segment);
++
++ self-need_segment = TRUE;
+
+ /* if not time format, we'll either start with a 0 timestamp anyway or
+* it's following a seek in which case we'll have saved the requested
+--
+1.7.9.5
+
diff --git
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.4.5.bb
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.4.5.bb
index 85e2ad6..ba76bdd 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.4.5.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.4.5.bb
@@ -20,6 +20,7 @@ SRC_URI +=
file://do-not-change-eos-event-to-gap-event-if.patch \
file://0001-basetextoverlay-make-memory-copy-when-video-buffer-s.patch \
file://0002-gstplaysink-don-t-set-async-of-custom-text-sink-to-f.patch \
file://0003-ssaparse-enhance-SSA-text-lines-parsing.patch \
+
file://0004-subparse-set-need_segment-after-sink-pad-received-GS.patch \
SRC_URI[md5sum] = 357165af625c0ca353ab47c5d843920e
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [poky][PATCH v6 3/3] gstreamer1.0-plugins-base: Add encodebin related patch
Need more buffers in output queue for better performance. Signed-off-by: Yuqing Zhu b54...@freescale.com --- ...eed-more-buffers-in-output-queue-for-bett.patch | 32 ++ .../gstreamer/gstreamer1.0-plugins-base_1.4.5.bb | 1 + 2 files changed, 33 insertions(+) create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/encodebin-Need-more-buffers-in-output-queue-for-bett.patch diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/encodebin-Need-more-buffers-in-output-queue-for-bett.patch b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/encodebin-Need-more-buffers-in-output-queue-for-bett.patch new file mode 100644 index 000..3256717 --- /dev/null +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/encodebin-Need-more-buffers-in-output-queue-for-bett.patch @@ -0,0 +1,32 @@ +From 540e02c92c75e08b90326863dc787fa5cadf9da6 Mon Sep 17 00:00:00 2001 +From: Song Bing b06...@freescale.com +Date: Fri, 13 Mar 2015 18:04:31 +0800 +Subject: [PATCH] encodebin: Need more buffers in output queue for better + performance + +Need more buffers in output queue for better performance + +Upstream-Status: Submitted [https://bugzilla.gnome.org/show_bug.cgi?id=744191] + +Signed-off-by: Song Bing b06...@freescale.com +--- + gst/encoding/gstencodebin.c |3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +diff --git a/gst/encoding/gstencodebin.c b/gst/encoding/gstencodebin.c +index 6728e58..32daae4 100644 +--- a/gst/encoding/gstencodebin.c b/gst/encoding/gstencodebin.c +@@ -1138,8 +1138,7 @@ _create_stream_group (GstEncodeBin * ebin, GstEncodingProfile * sprof, +* We only use a 1buffer long queue here, the actual queueing will be done +* in the input queue */ + last = sgroup-outqueue = gst_element_factory_make (queue, NULL); +- g_object_set (sgroup-outqueue, max-size-buffers, (guint32) 1, +- max-size-bytes, (guint32) 0, max-size-time, (guint64) 0, ++ g_object_set (sgroup-outqueue, max-size-time, (guint64) 0, + silent, TRUE, NULL); + + gst_bin_add (GST_BIN (ebin), sgroup-outqueue); +-- +1.7.9.5 + diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.4.5.bb b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.4.5.bb index ba76bdd..b09c2cb 100644 --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.4.5.bb +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.4.5.bb @@ -21,6 +21,7 @@ SRC_URI += file://do-not-change-eos-event-to-gap-event-if.patch \ file://0002-gstplaysink-don-t-set-async-of-custom-text-sink-to-f.patch \ file://0003-ssaparse-enhance-SSA-text-lines-parsing.patch \ file://0004-subparse-set-need_segment-after-sink-pad-received-GS.patch \ +file://encodebin-Need-more-buffers-in-output-queue-for-bett.patch \ SRC_URI[md5sum] = 357165af625c0ca353ab47c5d843920e -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [poky][PATCH v6 1/3] gstreamer1.0-plugins-base: Add ssaparse related patch
Enhance SSA text lines parsing.
Signed-off-by: Yuqing Zhu b54...@freescale.com
---
...3-ssaparse-enhance-SSA-text-lines-parsing.patch | 225 +
.../gstreamer/gstreamer1.0-plugins-base_1.4.5.bb | 1 +
2 files changed, 226 insertions(+)
create mode 100644
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0003-ssaparse-enhance-SSA-text-lines-parsing.patch
diff --git
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0003-ssaparse-enhance-SSA-text-lines-parsing.patch
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0003-ssaparse-enhance-SSA-text-lines-parsing.patch
new file mode 100644
index 000..9fbebd5
--- /dev/null
+++
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0003-ssaparse-enhance-SSA-text-lines-parsing.patch
@@ -0,0 +1,225 @@
+From be6163cfa3a255493f9d75bad9541cbfe1723fee Mon Sep 17 00:00:00 2001
+From: Mingke Wang mingke.w...@freescale.com
+Date: Thu, 19 Mar 2015 14:17:10 +0800
+Subject: [PATCH 3/4] ssaparse: enhance SSA text lines parsing.
+
+some parser will pass in the original ssa text line which starts with Dialog:
+and there's are maybe multiple Dialog lines in one input buffer.
+
+Upstream-Status: Submitted [https://bugzilla.gnome.org/show_bug.cgi?id=747496]
+
+Signed-off-by: Mingke Wang mingke.w...@freescale.com
+
+diff --git a/gst/subparse/gstssaparse.c b/gst/subparse/gstssaparse.c
+old mode 100644
+new mode 100755
+index 06ecef9..0ab5dce
+--- a/gst/subparse/gstssaparse.c
b/gst/subparse/gstssaparse.c
+@@ -260,6 +260,7 @@ gst_ssa_parse_remove_override_codes (GstSsaParse * parse,
gchar * txt)
+ * gst_ssa_parse_push_line:
+ * @parse: caller element
+ * @txt: text to push
++ * @size: text size need to be parse
+ * @start: timestamp for the buffer
+ * @duration: duration for the buffer
+ *
+@@ -269,27 +270,133 @@ gst_ssa_parse_remove_override_codes (GstSsaParse *
parse, gchar * txt)
+ * Returns: result of the push of the created buffer
+ */
+ static GstFlowReturn
+-gst_ssa_parse_push_line (GstSsaParse * parse, gchar * txt,
++gst_ssa_parse_push_line (GstSsaParse * parse, gchar * txt, gint size,
+ GstClockTime start, GstClockTime duration)
+ {
+ GstFlowReturn ret;
+ GstBuffer *buf;
+- gchar *t, *escaped;
++ gchar *t, *text, *p, *escaped, *p_start, *p_end;
+ gint num, i, len;
++ GstClockTime start_time = G_MAXUINT64, end_time = 0;
+
+- num = atoi (txt);
+- GST_LOG_OBJECT (parse, Parsing line #%d at % GST_TIME_FORMAT,
+- num, GST_TIME_ARGS (start));
+-
+- /* skip all non-text fields before the actual text */
++ p = text = g_malloc(size + 1);
++ *p = '\0';
+ t = txt;
+- for (i = 0; i 8; ++i) {
+-t = strchr (t, ',');
++
++ /* there are may have multiple dialogue lines at a time */
++ while (*t) {
++/* ignore leading white space characters */
++while (isspace(*t))
++ t++;
++
++/* ignore Format: and Style: lines */
++if (strncmp(t, Format:, 7) == 0 || strncmp(t, Style:, 6) == 0) {
++ while (*t != '\0' *t != '\n') {
++t++;
++ }
++}
++
++if (*t == '\0')
++ break;
++
++/* continue with next line */
++if (*t == '\n') {
++ t++;
++ continue;
++}
++
++if(strncmp(t, Dialogue:, 9) != 0) {
++ /* not started with Dialogue:, it must be a line trimmed by demuxer */
++ num = atoi (t);
++ GST_LOG_OBJECT (parse, Parsing line #%d at % GST_TIME_FORMAT,
++ num, GST_TIME_ARGS (start));
++
++ /* skip all non-text fields before the actual text */
++ for (i = 0; i 8; ++i) {
++t = strchr (t, ',');
++if (t == NULL)
++ break;
++++t;
++ }
++} else {
++ /* started with Dialogue:, update timestamp and duration */
++ /* time format are like Dialog:Mark,0:00:01.02,0:00:03.04,xx,xxx,... */
++ guint hour, min, sec, msec, len;
++ GstClockTime tmp;
++ gchar t_str[12] = {0};
++
++ /* find the first ',' */
++ p_start = strchr (t, ',');
++ if (p_start)
++p_end = strchr (++p_start, ',');
++
++ if (p_start p_end) {
++/* copy text between first ',' and second ',' */
++strncpy(t_str, p_start, p_end - p_start);
++if (sscanf (t_str, %u:%u:%u.%u, hour, min, sec, msec) == 4) {
++ tmp = ((hour*3600) + (min*60) + sec) * GST_SECOND +
msec*GST_MSECOND;
++ GST_DEBUG_OBJECT (parse, Get start time:%02d:%02d:%02d:%03d\n,
++ hour, min, sec, msec);
++ if (start_time tmp)
++start_time = tmp;
++} else {
++ GST_WARNING_OBJECT (parse,
++ failed to parse ssa start timestamp string :%s, t_str);
++}
++
++p_start = p_end;
++p_end = strchr (++p_start, ',');
++if (p_end) {
++ /* copy text between second ',' and third ',' */
++ strncpy(t_str, p_start, p_end - p_start);
++ if (sscanf (t_str, %u:%u:%u.%u, hour, min, sec, msec) == 4) {
++tmp = ((hour*3600) +
Re: [OE-core] [PATCH] python3: security: disable -pie -fpie from Python3 compilation CFLAGS when security_flags is inherited.
Several Python3 modules require use shared objects but -pie and -fpie GCC
options are not compatible with -shared. This causes linker error which are not
displayed during bitbake execution (unless verbose options are used) but the
.so files are not generated or included in the image.
-Original Message-
From: Jussi Kukkonen [mailto:jussi.kukko...@intel.com]
Sent: Thursday, August 6, 2015 1:31 PM
To: Kuutela, Topi
Cc: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [PATCH] python3: security: disable -pie -fpie from
Python3 compilation CFLAGS when security_flags is inherited.
On 6 August 2015 at 12:54, Topi Kuutela topi.kuut...@intel.com wrote:
Signed-off-by: Topi Kuutela topi.kuut...@intel.com
Could you add an explanation why this change is done? Also, maybe cut the
the subject line length to something more reasonable if you're re-submitting.
Jussi
---
meta/conf/distro/include/security_flags.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/conf/distro/include/security_flags.inc
b/meta/conf/distro/include/security_flags.inc
index 3724972..ff600fa 100644
--- a/meta/conf/distro/include/security_flags.inc
+++ b/meta/conf/distro/include/security_flags.inc
@@ -82,6 +82,7 @@ SECURITY_CFLAGS_pn-python-imaging =
${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-python-pycurl = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-python-smartpm =
${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-python-numpy = ${SECURITY_NO_PIE_CFLAGS}
+SECURITY_CFLAGS_pn-python3 = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-tcl = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-tiff = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-valgrind = ${SECURITY_NO_PIE_CFLAGS}
--
2.4.3
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki Business Identity Code:
0357606 - 4 Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] python3: security: disable -pie -fpie from Python3 compilation CFLAGS when security_flags is inherited.
Signed-off-by: Topi Kuutela topi.kuut...@intel.com
---
meta/conf/distro/include/security_flags.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/conf/distro/include/security_flags.inc
b/meta/conf/distro/include/security_flags.inc
index 3724972..ff600fa 100644
--- a/meta/conf/distro/include/security_flags.inc
+++ b/meta/conf/distro/include/security_flags.inc
@@ -82,6 +82,7 @@ SECURITY_CFLAGS_pn-python-imaging =
${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-python-pycurl = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-python-smartpm = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-python-numpy = ${SECURITY_NO_PIE_CFLAGS}
+SECURITY_CFLAGS_pn-python3 = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-tcl = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-tiff = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-valgrind = ${SECURITY_NO_PIE_CFLAGS}
--
2.4.3
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] python3: security: disable -pie and -fpie from Python3 compilation.
If security_flags.inc is 'required' to the image, -pie and -fpie options
are added to CFLAGS. These are not compatible with -shared GCC option but
cause linker errors which are not reported by bitbake.
Signed-off-by: Topi Kuutela topi.kuut...@intel.com
---
meta/conf/distro/include/security_flags.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/conf/distro/include/security_flags.inc
b/meta/conf/distro/include/security_flags.inc
index 3724972..ff600fa 100644
--- a/meta/conf/distro/include/security_flags.inc
+++ b/meta/conf/distro/include/security_flags.inc
@@ -82,6 +82,7 @@ SECURITY_CFLAGS_pn-python-imaging =
${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-python-pycurl = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-python-smartpm = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-python-numpy = ${SECURITY_NO_PIE_CFLAGS}
+SECURITY_CFLAGS_pn-python3 = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-tcl = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-tiff = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-valgrind = ${SECURITY_NO_PIE_CFLAGS}
--
2.4.3
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] python3: security: disable -pie -fpie from Python3 compilation CFLAGS when security_flags is inherited.
On 6 August 2015 at 12:54, Topi Kuutela topi.kuut...@intel.com wrote:
Signed-off-by: Topi Kuutela topi.kuut...@intel.com
Could you add an explanation why this change is done? Also, maybe cut
the the subject line length to something more reasonable if you're
re-submitting.
Jussi
---
meta/conf/distro/include/security_flags.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/conf/distro/include/security_flags.inc
b/meta/conf/distro/include/security_flags.inc
index 3724972..ff600fa 100644
--- a/meta/conf/distro/include/security_flags.inc
+++ b/meta/conf/distro/include/security_flags.inc
@@ -82,6 +82,7 @@ SECURITY_CFLAGS_pn-python-imaging =
${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-python-pycurl = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-python-smartpm = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-python-numpy = ${SECURITY_NO_PIE_CFLAGS}
+SECURITY_CFLAGS_pn-python3 = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-tcl = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-tiff = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-valgrind = ${SECURITY_NO_PIE_CFLAGS}
--
2.4.3
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] About multilib packages rpm pkg name
On 8/5/15 9:33 PM, Robert Yang wrote: Hi Mark, Thank you very much, this makes things more clear now, I've tried to change packagegroup-core-standalone-sdk-target's PACKAGE_ARCH to MACHINE_ARCH or TUNE_PKGARCH, it didn't work (the rdepends lib32 are still not installed), I will try to use read_subpkgdata() to get the required pkgs and fix the problem. During package creation we strip off the multilib prefix (since it's not needed). Then during dependency calculations things often favor a 'shortest path' to the dependency which may not give you the 32-bit version you are expecting. What I'd like to see is a patch to smart where you can say Use this ARCH or word size, unless explicitly selected. That would help eliminate -some- of these issues. The other side of the issue then is for things that do have explicit word size requirements (like gcc and some of the build tools) we need to fix the packages to have additions RDEPENDS and RPROVIDES that dictate the word size they need and the word size they provide. libpam already does this, and it resolved the issues there. --Mark // Robert On 08/05/2015 09:10 PM, Mark Hatle wrote: On 8/5/15 1:45 AM, Robert Yang wrote: Hello, For the multilib package like lib32-bash, its rpm package name is bash-4.3.30-r0.lib32_x86.rpm, but for ipk and deb, its name is lib32-bash.ipk and lib32-bash.deb, there is a side effect for the naming of rpm, for example, if packagegroup-xx rdepends on bash, the lib32-packagegroup-xx should rdepend on lib32-bash, but the its rpm pkg knows nothing about lib32-bash, so it still rdepends on bash, this causes 32bit toolchain libs not installed when export multilib sdk, for example: Configured multilib: MACHINE ?= qemux86-64 require conf/multilib.conf MULTILIBS = multilib:lib32 DEFAULTTUNE_virtclass-multilib-lib32 = x86 $ bitbake core-image-minimal -cpopulate_sdk When PACKAGE_CLASSES = package_rpm, the lib32-libgcc, lib32-libgcc-dev or other lib32-xx packages are not installed, so that the 32bit toolchain doesn't work in SDK, this is because lib32-packagegroup-core-standalone-sdk-target can't pull in the lib32-xx correctly. When PACKAGE_CLASSES = package_ipk, it works well. Does anyone why we don't use the name like lib32-bash.rpm, please ? Can we use lib32-bash, please ? Because for something like bash, there is absolutely no reason to choose a 64-bit or 32-bit version over the other. They have equivalent functionality for the end user, and only one version can be installed at a time. This is the RPM behavior that is being copied from Red Hat and other places, and what our customers are expecting. RPM supports multiple packages, with different arch fields, being installed at the same time. ipkg and deb have a limitation that the package name MUST be unique. So this is the first reason why we have different style names. The idea here being that you can build the .i586 packages once, and re-use them on an i586 system and an x86-64 system. (Note, this doesn't work in practice in the Yocto Project due to sstate issues... but that is the underlying design from a package management perspective.) Dependency processing is the second reason, see below for an explanation of the difference and how it affects us. There are different types of dependencies within the system. * Package level dependency This is of the format 'bash' or 'lib32-bash'. The system requires a specific package. All three package formats support this. * Virtual dependency This is similar, in that the format can look like a package, or be something like 'virtual/foo'. Again all three package formats support this. * Library SONAME This is a correlation of the library SONAME into the dependency set, such as 'libz.so(64)'. This is pulled directly from any ELF binaries in the system during processing and added as a direct dependency to other shared libraries. It is significantly more exact then the package or virtual dependencies above. HOWEVER, it only works in the RPM case. This is the second reason why deb and ipkg need a unique 'lib32' style name for things. They don't have a mechanism for a package to say I need the 64-bit version of libz.so to run properly, while that is built into RPM itself. * Filename dependency These are dependencies that start with '/'. This is unique to RPM as well, and allows RPM to express dependencies on '/bin/bash', vs deb/ipkg having dependencies on 'bash'. The difference is that it puts a hard marker in place that if 'bash' doesn't provide '/bin/bash', it's not enough. This doesn't directly affect the naming, but occasionally has some indirect adjustments on things. So when building a system using RPM as the package type, the rootfs construction may be slightly different because the package manager rules are different. RPM (smart) will look at the overall dependency tree and attempt to pick the shortest path so
[OE-core] [PATCH v2] Creates manifest/license files for deployed packages not in rootfs
From: Mariano Lopez mariano.lo...@linux.intel.com The current license manifest creation behavior is to include only packages that were installed. This beahvior excludes packages that were deployed but not installed in the rootfs. An example would be the bootloader. This patch adds support for packages deployed but not installed in the rootfs. Please note this patch DEPENDS on: http://lists.openembedded.org/pipermail/bitbake-devel/2015-August/006130.html Mariano Lopez (1): license.bbclass: Add support for deployed packages not in rootfs meta/classes/license.bbclass | 126 ++- 1 file changed, 113 insertions(+), 13 deletions(-) -- 1.8.4.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] license.bbclass: Add support for deployed packages not in rootfs
From: Mariano Lopez mariano.lo...@linux.intel.com
This adds a new manifest file for the packages that were
deployed but not included into rootfs. The new manifest file
is in the same directory as the rootfs manifest but the name is
image_license.manifest.
It also creates the directory structure for the packages and
add the license file in such directories.
The bootloader is an example of such packages.
[YOCTO #6772]
Signed-off-by: Mariano Lopez mariano.lo...@linux.intel.com
---
meta/classes/license.bbclass | 126 ++-
1 file changed, 113 insertions(+), 13 deletions(-)
diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
index 32e172a..d4ad263 100644
--- a/meta/classes/license.bbclass
+++ b/meta/classes/license.bbclass
@@ -26,18 +26,14 @@ python write_package_manifest() {
}
python license_create_manifest() {
-import re
import oe.packagedata
from oe.rootfs import image_list_installed_packages
-bad_licenses = (d.getVar(INCOMPATIBLE_LICENSE, True) or ).split()
-bad_licenses = map(lambda l: canonical_license(d, l), bad_licenses)
-bad_licenses = expand_wildcard_licenses(d, bad_licenses)
-
build_images_from_feeds = d.getVar('BUILD_IMAGES_FROM_FEEDS', True)
if build_images_from_feeds == 1:
return 0
+# Files that are installed in the rootfs
pkg_dic = {}
for pkg in image_list_installed_packages(d).split(\n):
pkg_info = os.path.join(d.getVar('PKGDATA_DIR', True),
@@ -49,8 +45,109 @@ python license_create_manifest() {
pkg_lic_name = LICENSE_ + pkg_name
pkg_dic[pkg_name][LICENSE] = pkg_dic[pkg_name][pkg_lic_name]
-license_manifest = os.path.join(d.getVar('LICENSE_DIRECTORY', True),
+# Files that are part of the image but no installed in rootfs
+imgpkg_dic = {}
+for pkg in list_deployed_packages(d, pkg_dic.keys()).split(\n):
+pkg_info = os.path.join(d.getVar('PKGDATA_DIR', True),
+'runtime', pkg)
+pkg_name = os.path.basename(pkg_info)
+imgpkg_dic[pkg] = oe.packagedata.read_pkgdatafile(pkg_info)
+if not LICENSE in imgpkg_dic[pkg].keys():
+pkg_lic_name = LICENSE_%s % pkg
+imgpkg_dic[pkg][LICENSE] = imgpkg_dic[pkg][pkg_lic_name]
+
+rootfs_license_manifest = os.path.join(d.getVar('LICENSE_DIRECTORY', True),
d.getVar('IMAGE_NAME', True), 'license.manifest')
+image_license_manifest = os.path.join(d.getVar('LICENSE_DIRECTORY', True),
+d.getVar('IMAGE_NAME', True), 'image_license.manifest')
+write_license_files(d, rootfs_license_manifest, pkg_dic)
+write_license_files(d, image_license_manifest, imgpkg_dic)
+}
+
+
+def list_deployed_packages(d, installed_packages):
+
+Get all the deployed packages (not installed on rootfs) of an image
+
+This function needs the BB_TASKDEPDATA from do_rootfs.
+This won't work outside do_rootfs.
+
+import oe.packagedata
+
+packages = []
+taskdepdata = d.getVar(BB_TASKDEPDATA, True)
+all_depends = imagetypes_getdepends(d)
+all_depends += %s % d.getVar(EXTRA_IMAGEDEPENDS, True)
+for depend in all_depends.split():
+# Get package name without task
+depend = depend.split(:)[0]
+if not depend.endswith(native):
+pkgs_file = os.path.join(
+d.getVar('PKGDATA_DIR', True), depend)
+# Search for the file on the installed packages with the
+# same name as depend if not found fallback to search
+# the provider for that depend.
+if not os.path.isfile(pkgs_file):
+pkgs_file =
+for taskdep in taskdepdata.itervalues():
+# The fifth field of BB_TASKDEPDATA is PROVIDES
+if depend in taskdep[4]:
+pkgs_file = os.path.join(
+d.getVar('PKGDATA_DIR', True),
+taskdep[0])
+if os.path.isfile(pkgs_file):
+break
+else:
+pkgs_file =
+if pkgs_file:
+pkgs_dep = oe.packagedata.read_pkgdatafile(pkgs_file)
+# There is no need to duplicate license info for
+# derivated packages or packages in the other
+# license manifest
+for pkg in pkgs_dep['PACKAGES'].split():
+if (pkg.endswith(-dbg) or
+pkg.endswith(-dev) or
+pkg.endswith(-doc) or
+pkg.endswith(-locale) or
+pkg.endswith(-localedata) or
+pkg.endswith(-staticdev) or
+pkg in installed_packages):
+continue
+pkg_data_file =
Re: [OE-core] [PATCH] oe-selftest: support selftests from other layers
Hi Chris, Thanks for your inputs. I tested my case with poky master which includes the two commitments you mentioned: https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=d2023c34e4c3735d919c35d80daf991aab579500 https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=51d760e2a7e22f1b07608fc925da343e56a9ae74 In my observation it still failed at my case. In my test case I have: poky_root/meta-mylayer/lib/oeqa/selftest/subdirs/mytest.py I type: oe-selftest --list-modules And I expect “subdirs.mytest” being listed. I type: oe-selftest --run-tests subdirs.mytest And I expect “mytest” being run. This case still failed without my patch. Attached the log file for your ref. Regards, Sharron From: kerg...@gmail.com [mailto:kerg...@gmail.com] On Behalf Of Christopher Larson Sent: Wednesday, August 5, 2015 11:07 PM To: Liu, Sharron Cc: Patches and discussions about the oe-core layer Subject: Re: [OE-core] [PATCH] oe-selftest: support selftests from other layers On Wed, Aug 5, 2015 at 12:17 AM, LIU, Sharron sharron@intel.commailto:sharron@intel.com wrote: [YOCTO #7865] https://bugzilla.yoctoproject.org/show_bug.cgi?id=7865 This script is extended to detect and run tests from all BBLAYERS added to BBPATH. Tests can be put in any sub-dir, except for files which is treated as test dependent files. To detect tests, this patch goes through lib/oeqa/selftest/ of every layer added to BBPATH. To support sub-dir, this patch list test module with its sub-dirs prefix. To run tests, this patch adds tests package path into sys.path then reload oeqa.selftest. Signed-off-by: LIU, Sharron sharron@intel.commailto:sharron@intel.com This was implemented as a part of the work to do the same for devtool recipetool, see https://bugzilla.yoctoproject.org/show_bug.cgi?id=7865#c10 and https://bugzilla.yoctoproject.org/show_bug.cgi?id=7625#c3: https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=d2023c34e4c3735d919c35d80daf991aab579500 https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=51d760e2a7e22f1b07608fc925da343e56a9ae74 -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics 7865.log Description: 7865.log -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] About multilib packages rpm pkg name
On 08/07/2015 04:57 AM, Mark Hatle wrote:
On 8/5/15 9:33 PM, Robert Yang wrote:
Hi Mark,
Thank you very much, this makes things more clear now, I've tried
to change packagegroup-core-standalone-sdk-target's PACKAGE_ARCH
to MACHINE_ARCH or TUNE_PKGARCH, it didn't work (the rdepends lib32
are still not installed), I will try to use read_subpkgdata() to get
the required pkgs and fix the problem.
During package creation we strip off the multilib prefix (since it's not
needed). Then during dependency calculations things often favor a 'shortest
path' to the dependency which may not give you the 32-bit version you are
expecting.
What I'd like to see is a patch to smart where you can say Use this ARCH or
word size, unless explicitly selected. That would help eliminate -some- of
these issues.
Thanks, sounds good, I will try smart later, at the moment, I made a
simple patch to make the populate_sdk pull in multilib toolchains works,
there are still other issues, I will fix them and send patches.
diff --git a/meta/classes/populate_sdk_base.bbclass
b/meta/classes/populate_sdk_base.bbclass
index a9e9bd7..c2491ea 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -83,8 +83,40 @@ POPULATE_SDK_POST_HOST_COMMAND_append =
write_host_sdk_manifest;
fakeroot python do_populate_sdk() {
from oe.sdk import populate_sdk
from oe.manifest import create_manifest, Manifest
+import oe.packagedata
pn = d.getVar('PN', True)
+# Help rpm to pull in multilib requires since it may not pull in
+# them correctly, for example,
+# lib32-packagegroup-core-standalone-sdk-target requires
+# lib32-libc6, rpm may pull in libc6 rather than lib32-libc6, but
+# directly use
+# TOOLCHAIN_TARGET_TASK_append = lib32-libc6 works well.
+for pkg in (d.getVar('TOOLCHAIN_TARGET_TASK', True) or ).split():
+sub_data = oe.packagedata.read_subpkgdata(pkg, d)
+sub_rdep = sub_data.get(RDEPENDS_ + pkg)
+if not sub_rdep:
+continue
+done = sub_rdep.split()
+next = done
+# Find all the rdepends on the dependency chain
+while next:
+new = []
+for sub_pkg in next:
+sub_data = oe.packagedata.read_subpkgdata(sub_pkg, d)
+sub_pkg_rdep = sub_data.get(RDEPENDS_ + sub_pkg)
+if not sub_pkg_rdep:
+continue
+for p in sub_pkg_rdep.split():
+if p in done:
+continue
+if not p.startswith('(') and \
+oe.packagedata.has_subpkgdata(p, d):
+# It's a new rdep
+done.append(p)
+new.append(p)
+next = new
+d.appendVar('TOOLCHAIN_TARGET_TASK', ' ' + .join(done))
// Robert
The other side of the issue then is for things that do have explicit word size
requirements (like gcc and some of the build tools) we need to fix the packages
to have additions RDEPENDS and RPROVIDES that dictate the word size they need
and the word size they provide. libpam already does this, and it resolved the
issues there.
--Mark
// Robert
On 08/05/2015 09:10 PM, Mark Hatle wrote:
On 8/5/15 1:45 AM, Robert Yang wrote:
Hello,
For the multilib package like lib32-bash, its rpm package name
is bash-4.3.30-r0.lib32_x86.rpm, but for ipk and deb, its name is
lib32-bash.ipk and lib32-bash.deb, there is a side effect for
the naming of rpm, for example, if packagegroup-xx rdepends on bash,
the lib32-packagegroup-xx should rdepend on lib32-bash, but
the its rpm pkg knows nothing about lib32-bash, so it still rdepends
on bash, this causes 32bit toolchain libs not installed when export
multilib sdk, for example:
Configured multilib:
MACHINE ?= qemux86-64
require conf/multilib.conf
MULTILIBS = multilib:lib32
DEFAULTTUNE_virtclass-multilib-lib32 = x86
$ bitbake core-image-minimal -cpopulate_sdk
When PACKAGE_CLASSES = package_rpm, the lib32-libgcc,
lib32-libgcc-dev or other lib32-xx packages are not installed,
so that the 32bit toolchain doesn't work in SDK, this is because
lib32-packagegroup-core-standalone-sdk-target can't pull in the
lib32-xx correctly.
When PACKAGE_CLASSES = package_ipk, it works well.
Does anyone why we don't use the name like lib32-bash.rpm, please ?
Can we use lib32-bash, please ?
Because for something like bash, there is absolutely no reason to choose a
64-bit or 32-bit version over the other. They have equivalent functionality for
the end user, and only one version can be installed at a time.
This is the RPM behavior that is being copied from Red Hat and other places, and
what our customers are expecting.
RPM supports multiple packages, with different arch fields, being installed at
the same time. ipkg and deb have a limitation that the package name MUST be
unique. So this is the first reason why we have
Re: [OE-core] [meta-oe][PATCH] dosfstools-2.11: Fix memory leak in mkdosfs
On Thu, Aug 6, 2015 at 2:25 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Thursday 06 August 2015 12:12:35 Alexander Kanavin wrote: On 08/06/2015 12:06 PM, Amarnath Valluri wrote: Added new patch that fixes the memory leak that was introduced in mkdosfs-dir.patch. You should update the original patch then, not pile additional patches on top. The least painful way is: 1) unpack the sources (manually from tarball, or using bitbake -c unpack) 2) 'git init; git add *; git commit' to create an git repository from the sources 3) apply the patch that needs fixing, then do the fix 4) make a git commit, then produce a patch using git format-patch, then move the new patch back to the recipe directory and update the recipe 5) build the recipe to make sure it still builds 6) make a git commit with the recipe update, and submit it here :) On the contrary - the much less painful way (as of fido) is to use devtool: 1) Extract source and set the build system up to use it: devtool modify dosfstools -x ~/projects/dosfstools 2) Make whatever changes you want to in the git tree that has been set up in the specified path 3) Build the recipe (as you would normally) to make sure it still builds 4) Write the modified/added commits as patches back to the recipe: devtool update-recipe dosfstools 5) Make a git commit with the recipe update, and submit it here :) I'd really like people to start using devtool for this kind of thing. If it's not working for some reason please do let me know. This assumes either we use OE-Core or poky, I dont get it to work with angstrom out of box what am I missing Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] python3: security: disable -pie and -fpie from Python3 compilation.
On Thu, Aug 6, 2015 at 3:48 AM, Topi Kuutela topi.kuut...@intel.com wrote:
If security_flags.inc is 'required' to the image, -pie and -fpie options
are added to CFLAGS. These are not compatible with -shared GCC option but
cause linker errors which are not reported by bitbake.
what error do you run into ? can you also add that here
Signed-off-by: Topi Kuutela topi.kuut...@intel.com
---
meta/conf/distro/include/security_flags.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/conf/distro/include/security_flags.inc
b/meta/conf/distro/include/security_flags.inc
index 3724972..ff600fa 100644
--- a/meta/conf/distro/include/security_flags.inc
+++ b/meta/conf/distro/include/security_flags.inc
@@ -82,6 +82,7 @@ SECURITY_CFLAGS_pn-python-imaging =
${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-python-pycurl = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-python-smartpm = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-python-numpy = ${SECURITY_NO_PIE_CFLAGS}
+SECURITY_CFLAGS_pn-python3 = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-tcl = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-tiff = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-valgrind = ${SECURITY_NO_PIE_CFLAGS}
--
2.4.3
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/6] vte: Fix LICENSE to LGPL2.0
On Aug 6, 2015, at 1:42 AM, Jussi Kukkonen jussi.kukko...@intel.com wrote: Current releases of vte are LGPL 2.1+ but the one we have is still LGPL 2.0. Signed-off-by: Jussi Kukkonen jussi.kukko...@intel.com --- meta/recipes-support/vte/vte.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-support/vte/vte.inc b/meta/recipes-support/vte/vte.inc index 4081a7f..874062a 100644 --- a/meta/recipes-support/vte/vte.inc +++ b/meta/recipes-support/vte/vte.inc @@ -1,6 +1,6 @@ SUMMARY = Virtual terminal emulator GTK+ widget library BUGTRACKER = https://bugzilla.gnome.org/buglist.cgi?product=vte; -LICENSE = LGPLv2.1+ +LICENSE = “LGPLv2.0 this brings to notice that this recipe needs upgrade latest vte srcs already use LGPL2.1 may be updating to latest version is 0.40 http://ftp.gnome.org/pub/gnome/sources/vte/0.40/ DEPENDS = glib-2.0 gtk+ intltool-native ncurses gobject-introspection-stub RDEPENDS_libvte = vte-termcap -- 2.1.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] oe-selftest: support selftests from other layers
On Thu, Aug 6, 2015 at 8:43 PM, Liu, Sharron sharron@intel.com wrote: Thanks for your inputs. I tested my case with poky master which includes the two commitments you mentioned: https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=d2023c34e4c3735d919c35d80daf991aab579500 https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=51d760e2a7e22f1b07608fc925da343e56a9ae74 In my observation it still failed at my case. In my test case I have: poky_root/meta-mylayer/lib/oeqa/selftest/subdirs/mytest.py I type: oe-selftest --list-modules And I expect “subdirs.mytest” being listed. I type: oe-selftest --run-tests subdirs.mytest And I expect “mytest” being run. This case still failed without my patch. Attached the log file for your ref. Sounds like you didn't properly set up your python packages. It has to be possible to import your tests from python, which is not the case unless __init__.py exists at the root of each python package. oeqa.selftest is a python namespace package. Copy poky/meta/lib/oeqa/selftest/__init__.py to poky_root/meta-mylayer/lib/oeqa/selftest/, and either also copy it to poky_root/meta-mylayer/lib/oeqa/selftest/subdirs/ or touch poky_root/meta-mylayer/lib/oeqa/selftest/subdirs/__init__.py. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 19/21] epiphany: add a recipe from meta-gnome
On 2015-07-30 10:27 AM, Alexander Kanavin wrote:
Epiphany is replacing midori as the browser in oe-core recipe set
and poky distribution.
I just got caught up on oe-core and:
https://www.mail-archive.com/yocto@yoctoproject.org/msg24522.html
Please move the midori recipe and dependencies to
meta-oe when this change is merged to oe-core. That would help
anyone that needs to provide a transition warning. Of course it
adds more cruft to meta-oe but that's a separate problem.
Thanks,
../Randy
Signed-off-by: Alexander Kanavin alexander.kana...@linux.intel.com
---
meta/recipes-gnome/epiphany/epiphany_3.16.3.bb | 24
.../0001-yelp.m4-drop-the-check-for-itstool.patch | 33 ++
2 files changed, 57 insertions(+)
create mode 100644 meta/recipes-gnome/epiphany/epiphany_3.16.3.bb
create mode 100644
meta/recipes-gnome/epiphany/files/0001-yelp.m4-drop-the-check-for-itstool.patch
diff --git a/meta/recipes-gnome/epiphany/epiphany_3.16.3.bb
b/meta/recipes-gnome/epiphany/epiphany_3.16.3.bb
new file mode 100644
index 000..0f5aef1
--- /dev/null
+++ b/meta/recipes-gnome/epiphany/epiphany_3.16.3.bb
@@ -0,0 +1,24 @@
+SUMMARY = WebKit based web browser for GNOME
+LICENSE = GPLv2+
+LIC_FILES_CHKSUM = file://COPYING;md5=751419260aa954499f7abaabaa882bbe
+
+DEPENDS = libsoup-2.4 webkitgtk gtk+3 iso-codes ca-certificates avahi
libnotify gcr libwnck3 \
+ gsettings-desktop-schemas gnome-desktop3
+
+inherit gnomebase gsettings
+SRC_URI += file://0001-yelp.m4-drop-the-check-for-itstool.patch
+SRC_URI[archive.md5sum] = 3296af4532b8019775f4b40d21a341ae
+SRC_URI[archive.sha256sum] =
d527f1770779ec22d955aeb13b148a846a26144e433ff0480c981af80e2390b1
+
+EXTRA_OECONF += --disable-nss --with-distributor-name=${DISTRO}
+
+do_configure_prepend() {
+touch ${S}/gnome-doc-utils.make
+sed -i -e s:help::g ${S}/Makefile.am
+}
+
+FILES_${PN} += ${datadir}/appdata ${datadir}/dbus-1
${datadir}/gnome-shell/search-providers
+FILES_${PN}-dbg +=
${libdir}/${PN}/*/web-extensions/.debug/libephywebextension.so
+RDEPENDS_${PN} = iso-codes
+RRECOMMENDS_${PN} = ca-certificates
+
diff --git
a/meta/recipes-gnome/epiphany/files/0001-yelp.m4-drop-the-check-for-itstool.patch
b/meta/recipes-gnome/epiphany/files/0001-yelp.m4-drop-the-check-for-itstool.patch
new file mode 100644
index 000..2585d7f
--- /dev/null
+++
b/meta/recipes-gnome/epiphany/files/0001-yelp.m4-drop-the-check-for-itstool.patch
@@ -0,0 +1,33 @@
+From 30f03a256efe375a4d5c3a24bf4168ebf380e3ab Mon Sep 17 00:00:00 2001
+From: Alexander Kanavin alex.kana...@gmail.com
+Date: Thu, 30 Jul 2015 15:13:23 +0300
+Subject: [PATCH] yelp.m4: drop the check for itstool
+
+It isn't used for anything during build, so there's no need to provide
+it as a recipe.
+
+Upstream-Status: Inappropriate [tarball-specific issue]
+---
+ m4/yelp.m4 | 6 --
+ 1 file changed, 6 deletions(-)
+
+diff --git a/m4/yelp.m4 b/m4/yelp.m4
+index 5db847f..1b6ede4 100644
+--- a/m4/yelp.m4
b/m4/yelp.m4
+@@ -27,12 +27,6 @@ AC_ARG_WITH([help-dir],
+ HELP_DIR=$with_help_dir
+ AC_SUBST(HELP_DIR)
+
+-AC_ARG_VAR([ITSTOOL], [Path to the `itstool` command])
+-AC_CHECK_PROG([ITSTOOL], [itstool], [itstool])
+-if test x$ITSTOOL = x; then
+- AC_MSG_ERROR([itstool not found])
+-fi
+-
+ AC_ARG_VAR([XMLLINT], [Path to the `xmllint` command])
+ AC_CHECK_PROG([XMLLINT], [xmllint], [xmllint])
+ if test x$XMLLINT = x; then
+--
+2.1.4
+
--
# Randy MacLeod. SMTS, Linux, Wind River
Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON,
Canada, K2K 2W5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [poky][PATCH v6 0/3] Add patches for Gstreamer 1.4.5 base
On Thu, 2015-08-06 at 18:29 +0800, Yuqing Zhu wrote: Fix issue about gstreamer1.0-plugins-base -ssaparse: Enhance SSA text lines parsing. -subparse: Set need_segment after sink pad receive GST_EVENT_SEGMENT. -encodebin: Need more buffers in output queue for better performance. Yuqing Zhu (3): gstreamer1.0-plugins-base: Add ssaparse related patch gstreamer1.0-plugins-base: Add subparse related patch gstreamer1.0-plugins-base: Add encodebin related patch I'm afraid I'm completely confused with this patch series. It started as 6 patches, its now 3 and these patches don't apply against master. Could someone send the complete patch series that you're asking to merge that applies against master please? Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/4] uclibc.inc: remove unused UCLIBC_EXTRA_LDFLAGS
Signed-off-by: Andre McCurdy armccu...@gmail.com
---
meta/recipes-core/uclibc/uclibc.inc | 1 -
1 file changed, 1 deletion(-)
diff --git a/meta/recipes-core/uclibc/uclibc.inc
b/meta/recipes-core/uclibc/uclibc.inc
index 08465c4..c483228 100644
--- a/meta/recipes-core/uclibc/uclibc.inc
+++ b/meta/recipes-core/uclibc/uclibc.inc
@@ -59,7 +59,6 @@ export V=2
#
CFLAGS_arm := ${@oe_filter_out('-fno-omit-frame-pointer', '${CFLAGS}', d)}
UCLIBC_EXTRA_CFLAGS := ${@oe_filter_out('(-I\S+|-i\S+)', '${CFLAGS}', d)}
-UCLIBC_EXTRA_LDFLAGS := ${@oe_filter_out('(-L\S+|-l\S+)', '${LDFLAGS}', d)}
do_compile_prepend () {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/4] uclibc.inc: fixup CFLAGS with _remove instead of oe_filter_out
No functional change, but _remove is slightly cleaner and clearer.
Signed-off-by: Andre McCurdy armccu...@gmail.com
---
meta/recipes-core/uclibc/uclibc.inc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-core/uclibc/uclibc.inc
b/meta/recipes-core/uclibc/uclibc.inc
index c483228..969c35b 100644
--- a/meta/recipes-core/uclibc/uclibc.inc
+++ b/meta/recipes-core/uclibc/uclibc.inc
@@ -57,7 +57,8 @@ export V=2
# -On -fno-omit-frame-pointer ends up with GCC ICE on thumb as reported
# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44860
#
-CFLAGS_arm := ${@oe_filter_out('-fno-omit-frame-pointer', '${CFLAGS}', d)}
+CFLAGS_remove_arm = -fno-omit-frame-pointer
+
UCLIBC_EXTRA_CFLAGS := ${@oe_filter_out('(-I\S+|-i\S+)', '${CFLAGS}', d)}
do_compile_prepend () {
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] uclibc.inc: avoid immediate expansion for UCLIBC_EXTRA_CFLAGS
On Thu, 2015-08-06 at 12:41 -0700, Andre McCurdy wrote:
If immediate variable expansion is used, then UCLIBC_EXTRA_CFLAGS can
sometimes be derived from a partially expanded value of CFLAGS.
One specific problem case occurs when security_flags.inc is used: CFLAGS
is evaluated before the SECURITY_CFLAGS_pn-uclibc over-ride has been
applied and therefore UCLIBC_EXTRA_CFLAGS ends up being based on the
default SECURITY_CFLAGS instead of the uclibc specific value.
Signed-off-by: Andre McCurdy armccu...@gmail.com
---
meta/recipes-core/uclibc/uclibc.inc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/uclibc/uclibc.inc
b/meta/recipes-core/uclibc/uclibc.inc
index c483228..3ed8b60 100644
--- a/meta/recipes-core/uclibc/uclibc.inc
+++ b/meta/recipes-core/uclibc/uclibc.inc
@@ -57,8 +57,8 @@ export V=2
# -On -fno-omit-frame-pointer ends up with GCC ICE on thumb as reported
# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44860
#
-CFLAGS_arm := ${@oe_filter_out('-fno-omit-frame-pointer', '${CFLAGS}', d)}
-UCLIBC_EXTRA_CFLAGS := ${@oe_filter_out('(-I\S+|-i\S+)', '${CFLAGS}', d)}
+CFLAGS_arm = ${@oe_filter_out('-fno-omit-frame-pointer', '${CFLAGS}', d)}
I'm rather surprised we don't get circular references without the :=
operator with this. I suspect we can see build failures if you change
the code like this. That said, I've been meaning to go through and
replace all the uses of oe_filter_out with the remove operator. Can we
do that here please instead?
E.g:
CFLAGS_remove_arm = -fno-omit-frame-pointer
+UCLIBC_EXTRA_CFLAGS = ${@oe_filter_out('(-I\S+|-i\S+)', '${CFLAGS}', d)}
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] security_flags.inc: clear SECURITY_CFLAGS for uclibc
On Thu, Aug 6, 2015 at 12:41 PM, Andre McCurdy armccu...@gmail.com wrote:
uclibc fails to build when security_flags.inc is used.
| i686-rdk-linux-uclibc-gcc -m32 -march=core2 -mtune=core2 -msse3
-mfpmath=sse --sysroot=/build-vbox32/tmp/sysroots/vbox32-tcbootstrap -Wl,-EL
-Wl,--sort-common -Wl,--sort-section=alignment -m32 -shared -Wl,--warn-common
-Wl,--warn-once -Wl,-z,combreloc -Wl,-z,relro -Wl,-z,now -Wl,--hash-style=gnu
-Wl,-z,defs -Wl,-init,__uClibc_init -Wl,-soname=libc.so.0 -nostdlib -o
lib/libuClibc-0.9.34-git.so -Wl,--whole-archive libc/libc_so.a
-Wl,--no-whole-archive ./lib/interp.os ./lib/ld-uClibc.so.0
./lib/uclibc_nonshared.a
/build-vbox32/tmp/sysroots/vbox32-tcbootstrap/usr/lib/i686-rdk-linux-uclibc/4.9.3/libgcc.a
| libc/libc_so.a(sigaction.os): In function `__libc_sigaction':
|
/build-vbox32/tmp/work/core2-32-rdk-linux-uclibc/uclibc/0.9.33+gitAUTOINC+48a0006012-r9/git/libc/sysdeps/linux/i386/sigaction.c:37:
undefined reference to `__stack_chk_guard'
|
/build-vbox32/tmp/work/core2-32-rdk-linux-uclibc/uclibc/0.9.33+gitAUTOINC+48a0006012-r9/git/libc/sysdeps/linux/i386/sigaction.c:49:
undefined reference to `__stack_chk_fail_local'
| collect2: error: ld returned 1 exit status
| make: *** [lib/libc.so] Error 1
This fix is papering over real problem. this means gcc is expecting
ssp implementation from libc but is not detecting it rightly can you
try passing gcc_cv_libc_provides_ssp=yes to help it configure
Clearing SECURITY_CFLAGS completely may not be the best approach, but
it's the approach taken for glibc, so try it for uclibc too.
Signed-off-by: Andre McCurdy armccu...@gmail.com
---
meta/conf/distro/include/security_flags.inc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/conf/distro/include/security_flags.inc
b/meta/conf/distro/include/security_flags.inc
index 3724972..a107657 100644
--- a/meta/conf/distro/include/security_flags.inc
+++ b/meta/conf/distro/include/security_flags.inc
@@ -84,6 +84,8 @@ SECURITY_CFLAGS_pn-python-smartpm =
${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-python-numpy = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-tcl = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-tiff = ${SECURITY_NO_PIE_CFLAGS}
+SECURITY_CFLAGS_pn-uclibc =
+SECURITY_CFLAGS_pn-uclibc-initial =
SECURITY_CFLAGS_pn-valgrind = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-webkit-gtk = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-zlib = ${SECURITY_NO_PIE_CFLAGS}
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/4] security_flags.inc: clear SECURITY_CFLAGS for uclibc
uclibc fails to build when security_flags.inc is used.
| i686-rdk-linux-uclibc-gcc -m32 -march=core2 -mtune=core2 -msse3
-mfpmath=sse --sysroot=/build-vbox32/tmp/sysroots/vbox32-tcbootstrap -Wl,-EL
-Wl,--sort-common -Wl,--sort-section=alignment -m32 -shared -Wl,--warn-common
-Wl,--warn-once -Wl,-z,combreloc -Wl,-z,relro -Wl,-z,now -Wl,--hash-style=gnu
-Wl,-z,defs -Wl,-init,__uClibc_init -Wl,-soname=libc.so.0 -nostdlib -o
lib/libuClibc-0.9.34-git.so -Wl,--whole-archive libc/libc_so.a
-Wl,--no-whole-archive ./lib/interp.os ./lib/ld-uClibc.so.0
./lib/uclibc_nonshared.a
/build-vbox32/tmp/sysroots/vbox32-tcbootstrap/usr/lib/i686-rdk-linux-uclibc/4.9.3/libgcc.a
| libc/libc_so.a(sigaction.os): In function `__libc_sigaction':
|
/build-vbox32/tmp/work/core2-32-rdk-linux-uclibc/uclibc/0.9.33+gitAUTOINC+48a0006012-r9/git/libc/sysdeps/linux/i386/sigaction.c:37:
undefined reference to `__stack_chk_guard'
|
/build-vbox32/tmp/work/core2-32-rdk-linux-uclibc/uclibc/0.9.33+gitAUTOINC+48a0006012-r9/git/libc/sysdeps/linux/i386/sigaction.c:49:
undefined reference to `__stack_chk_fail_local'
| collect2: error: ld returned 1 exit status
| make: *** [lib/libc.so] Error 1
Clearing SECURITY_CFLAGS completely may not be the best approach, but
it's the approach taken for glibc, so try it for uclibc too.
Signed-off-by: Andre McCurdy armccu...@gmail.com
---
meta/conf/distro/include/security_flags.inc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/conf/distro/include/security_flags.inc
b/meta/conf/distro/include/security_flags.inc
index 3724972..a107657 100644
--- a/meta/conf/distro/include/security_flags.inc
+++ b/meta/conf/distro/include/security_flags.inc
@@ -84,6 +84,8 @@ SECURITY_CFLAGS_pn-python-smartpm =
${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-python-numpy = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-tcl = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-tiff = ${SECURITY_NO_PIE_CFLAGS}
+SECURITY_CFLAGS_pn-uclibc =
+SECURITY_CFLAGS_pn-uclibc-initial =
SECURITY_CFLAGS_pn-valgrind = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-webkit-gtk = ${SECURITY_NO_PIE_CFLAGS}
SECURITY_CFLAGS_pn-zlib = ${SECURITY_NO_PIE_CFLAGS}
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 0/4] fix uclibc build with security_flags.inc
v2 adds a new patch to fixup CFLAGS with _remove instead of oe_filter_out, which fixes CFLAGS circular reference build failures introduced in v1 when building for ARM. Andre McCurdy (4): uclibc.inc: remove unused UCLIBC_EXTRA_LDFLAGS uclibc.inc: fixup CFLAGS with _remove instead of oe_filter_out uclibc.inc: avoid immediate expansion for UCLIBC_EXTRA_CFLAGS security_flags.inc: clear SECURITY_CFLAGS for uclibc meta/conf/distro/include/security_flags.inc | 2 ++ meta/recipes-core/uclibc/uclibc.inc | 6 +++--- 2 files changed, 5 insertions(+), 3 deletions(-) -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/4] uclibc.inc: avoid immediate expansion for UCLIBC_EXTRA_CFLAGS
If immediate variable expansion is used, then UCLIBC_EXTRA_CFLAGS can
sometimes be derived from a partially expanded value of CFLAGS.
One specific problem case occurs when security_flags.inc is used: CFLAGS
is evaluated before the SECURITY_CFLAGS_pn-uclibc over-ride has been
applied and therefore UCLIBC_EXTRA_CFLAGS ends up being based on the
default SECURITY_CFLAGS instead of the uclibc specific value.
Signed-off-by: Andre McCurdy armccu...@gmail.com
---
meta/recipes-core/uclibc/uclibc.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/uclibc/uclibc.inc
b/meta/recipes-core/uclibc/uclibc.inc
index 969c35b..e20fa5c 100644
--- a/meta/recipes-core/uclibc/uclibc.inc
+++ b/meta/recipes-core/uclibc/uclibc.inc
@@ -59,7 +59,7 @@ export V=2
#
CFLAGS_remove_arm = -fno-omit-frame-pointer
-UCLIBC_EXTRA_CFLAGS := ${@oe_filter_out('(-I\S+|-i\S+)', '${CFLAGS}', d)}
+UCLIBC_EXTRA_CFLAGS = ${@oe_filter_out('(-I\S+|-i\S+)', '${CFLAGS}', d)}
do_compile_prepend () {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] uclibc.inc: avoid immediate expansion for UCLIBC_EXTRA_CFLAGS
On Thu, Aug 6, 2015 at 4:02 PM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Thu, 2015-08-06 at 12:41 -0700, Andre McCurdy wrote:
If immediate variable expansion is used, then UCLIBC_EXTRA_CFLAGS can
sometimes be derived from a partially expanded value of CFLAGS.
One specific problem case occurs when security_flags.inc is used: CFLAGS
is evaluated before the SECURITY_CFLAGS_pn-uclibc over-ride has been
applied and therefore UCLIBC_EXTRA_CFLAGS ends up being based on the
default SECURITY_CFLAGS instead of the uclibc specific value.
Signed-off-by: Andre McCurdy armccu...@gmail.com
---
meta/recipes-core/uclibc/uclibc.inc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/uclibc/uclibc.inc
b/meta/recipes-core/uclibc/uclibc.inc
index c483228..3ed8b60 100644
--- a/meta/recipes-core/uclibc/uclibc.inc
+++ b/meta/recipes-core/uclibc/uclibc.inc
@@ -57,8 +57,8 @@ export V=2
# -On -fno-omit-frame-pointer ends up with GCC ICE on thumb as reported
# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44860
#
-CFLAGS_arm := ${@oe_filter_out('-fno-omit-frame-pointer', '${CFLAGS}', d)}
-UCLIBC_EXTRA_CFLAGS := ${@oe_filter_out('(-I\S+|-i\S+)', '${CFLAGS}', d)}
+CFLAGS_arm = ${@oe_filter_out('-fno-omit-frame-pointer', '${CFLAGS}', d)}
I'm rather surprised we don't get circular references without the :=
operator with this. I suspect we can see build failures if you change
the code like this. That said, I've been meaning to go through and
replace all the uses of oe_filter_out with the remove operator. Can we
do that here please instead?
E.g:
CFLAGS_remove_arm = -fno-omit-frame-pointer
OK, new patch on the way.
+UCLIBC_EXTRA_CFLAGS = ${@oe_filter_out('(-I\S+|-i\S+)', '${CFLAGS}', d)}
Is it OK to keep using oe_filter_out() here to support the regex?
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/4] uclibc.inc: remove unused UCLIBC_EXTRA_LDFLAGS
On Thu, Aug 6, 2015 at 6:54 PM, Andre McCurdy armccu...@gmail.com wrote:
Signed-off-by: Andre McCurdy armccu...@gmail.com
---
meta/recipes-core/uclibc/uclibc.inc | 1 -
1 file changed, 1 deletion(-)
diff --git a/meta/recipes-core/uclibc/uclibc.inc
b/meta/recipes-core/uclibc/uclibc.inc
index 08465c4..c483228 100644
--- a/meta/recipes-core/uclibc/uclibc.inc
+++ b/meta/recipes-core/uclibc/uclibc.inc
@@ -59,7 +59,6 @@ export V=2
#
CFLAGS_arm := ${@oe_filter_out('-fno-omit-frame-pointer', '${CFLAGS}', d)}
UCLIBC_EXTRA_CFLAGS := ${@oe_filter_out('(-I\S+|-i\S+)', '${CFLAGS}', d)}
-UCLIBC_EXTRA_LDFLAGS := ${@oe_filter_out('(-L\S+|-l\S+)', '${LDFLAGS}', d)}
those variables are part of .config so please make sure that they are
really redundant and dont make into .config
do_compile_prepend () {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 6/6] tcmode-default.inc: update BINUVERSION
On 08/06/2015 11:53 AM, Khem Raj wrote:
On Aug 3, 2015, at 11:40 PM, Robert Yang liezhi.y...@windriver.com wrote:
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
meta/conf/distro/include/tcmode-default.inc |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf/distro/include/tcmode-default.inc
b/meta/conf/distro/include/tcmode-default.inc
index 0abf803..c08fe24 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -24,7 +24,7 @@ PREFERRED_PROVIDER_virtual/gettext ??= gettext
GCCVERSION ?= 4.9%
SDKGCCVERSION ?= ${GCCVERSION}
-BINUVERSION ?= 2.25
+BINUVERSION ?= 2.25%”
squash this into binutils upgrade patch
Thanks, updated in the repo:
git://git.openembedded.org/openembedded-core-contrib rbt/PU
// Robert
GDBVERSION ?= 7.9%
GLIBCVERSION ?= 2.21
UCLIBCVERSION ?= 0.9.33+git%
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-oe][PATCH] dosfstools-2.11: Fix memory leak in mkdosfs
Alex Paul, Thanks both of you, I have resubmitted the patch as per you suggestions. - Amarnath From: Paul Eggleton [paul.eggle...@linux.intel.com] Sent: Thursday, August 06, 2015 12:25 PM To: Alexander Kanavin; Valluri, Amarnath Cc: openembedded-core@lists.openembedded.org Subject: Re: [OE-core] [meta-oe][PATCH] dosfstools-2.11: Fix memory leak in mkdosfs On Thursday 06 August 2015 12:12:35 Alexander Kanavin wrote: On 08/06/2015 12:06 PM, Amarnath Valluri wrote: Added new patch that fixes the memory leak that was introduced in mkdosfs-dir.patch. You should update the original patch then, not pile additional patches on top. The least painful way is: 1) unpack the sources (manually from tarball, or using bitbake -c unpack) 2) 'git init; git add *; git commit' to create an git repository from the sources 3) apply the patch that needs fixing, then do the fix 4) make a git commit, then produce a patch using git format-patch, then move the new patch back to the recipe directory and update the recipe 5) build the recipe to make sure it still builds 6) make a git commit with the recipe update, and submit it here :) On the contrary - the much less painful way (as of fido) is to use devtool: 1) Extract source and set the build system up to use it: devtool modify dosfstools -x ~/projects/dosfstools 2) Make whatever changes you want to in the git tree that has been set up in the specified path 3) Build the recipe (as you would normally) to make sure it still builds 4) Write the modified/added commits as patches back to the recipe: devtool update-recipe dosfstools 5) Make a git commit with the recipe update, and submit it here :) I'd really like people to start using devtool for this kind of thing. If it's not working for some reason please do let me know. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [meta-oe][PATCH v2] dosfstools-2.11: Fix memory leak in mkdosfs
Fix memory leak that was introduced in mkdosfs-dir.patch.
Signed-off-by: Amarnath Valluri amarnath.vall...@intel.com
---
.../dosfstools/dosfstools/mkdosfs-dir.patch| 53 ++
1 file changed, 34 insertions(+), 19 deletions(-)
diff --git a/meta/recipes-devtools/dosfstools/dosfstools/mkdosfs-dir.patch
b/meta/recipes-devtools/dosfstools/dosfstools/mkdosfs-dir.patch
index 3ba4711..58b64e1 100644
--- a/meta/recipes-devtools/dosfstools/dosfstools/mkdosfs-dir.patch
+++ b/meta/recipes-devtools/dosfstools/dosfstools/mkdosfs-dir.patch
@@ -1,14 +1,24 @@
-Add -d directory support to populate the image.
+From e746addea175a802717f5e23e14e9dc3b772a53a Mon Sep 17 00:00:00 2001
+From: Scott Garman scott.a.gar...@intel.com
+Date: Thu, 6 Aug 2015 14:29:15 +0300
+Subject: [PATCH 1/8] Add -d directory support to populate the image.
Upstream-Status: Inappropriate [licensing]
We're tracking an old release of dosfstools due to licensing issues.
+v2:
+ - Fix memory leak.
+
Signed-off-by: Scott Garman scott.a.gar...@intel.com
+Signed-off-by: Amarnath Valluri amarnath.vall...@intel.com
+---
+ mkdosfs/mkdosfs.c | 508 +-
+ 1 file changed, 499 insertions(+), 9 deletions(-)
-Index: dosfstools-2.11/mkdosfs/mkdosfs.c
-===
dosfstools-2.11.orig/mkdosfs/mkdosfs.c 2011-12-06 12:27:55.0
+
-+++ dosfstools-2.11/mkdosfs/mkdosfs.c 2011-12-06 12:37:13.445950703 +
+diff --git a/mkdosfs/mkdosfs.c b/mkdosfs/mkdosfs.c
+index 258ca5b..5f23272 100644
+--- a/mkdosfs/mkdosfs.c
b/mkdosfs/mkdosfs.c
@@ -18,6 +18,10 @@
as a rule), and not the block. For example the boot block does not
occupy a full cluster.
@@ -38,7 +48,7 @@ Index: dosfstools-2.11/mkdosfs/mkdosfs.c
/* Constant definitions */
#define TRUE 1/* Boolean constants */
-@@ -149,7 +157,6 @@
+@@ -149,7 +157,6 @@ cdiv (int a, int b)
#define ATTR_VOLUME 8/* volume label */
#define ATTR_DIR 16 /* directory */
#define ATTR_ARCH32 /* archived */
@@ -46,7 +56,7 @@ Index: dosfstools-2.11/mkdosfs/mkdosfs.c
#define ATTR_NONE0/* no attribute bits */
#define ATTR_UNUSED (ATTR_VOLUME | ATTR_ARCH | ATTR_SYS | ATTR_HIDDEN)
/* attribute bits that are copied as is */
-@@ -245,6 +252,19 @@
+@@ -245,6 +252,19 @@ struct fat32_fsinfo {
__u32 reserved2[4];
};
@@ -66,7 +76,7 @@ Index: dosfstools-2.11/mkdosfs/mkdosfs.c
struct msdos_dir_entry
{
char name[8], ext[3];/* name and extension */
-@@ -293,6 +313,15 @@
+@@ -293,6 +313,15 @@ char dummy_boot_code[BOOTCODE_SIZE] =
#define MESSAGE_OFFSET 29 /* Offset of message in above code */
@@ -82,7 +92,7 @@ Index: dosfstools-2.11/mkdosfs/mkdosfs.c
/* Global variables - the root of all evil :-) - see these and weep! */
static char *template_boot_code; /* Variable to store a full template
boot sector in */
-@@ -326,6 +355,9 @@
+@@ -326,6 +355,9 @@ static struct msdos_dir_entry *root_dir; /* Root
directory */
static int size_root_dir; /* Size of the root directory in bytes */
static int sectors_per_cluster = 0; /* Number of sectors per disk cluster */
static int root_dir_entries = 0; /* Number of root directory entries */
@@ -92,7 +102,7 @@ Index: dosfstools-2.11/mkdosfs/mkdosfs.c
static char *blank_sector;/* Blank sector - all zeros */
static int hidden_sectors = 0;/* Number of hidden sectors */
-@@ -399,7 +431,6 @@
+@@ -399,7 +431,6 @@ mark_FAT_cluster (int cluster, unsigned int value)
}
}
@@ -100,7 +110,7 @@ Index: dosfstools-2.11/mkdosfs/mkdosfs.c
/* Mark a specified sector as having a particular value in it's FAT entry */
static void
-@@ -1266,6 +1297,9 @@
+@@ -1266,6 +1297,9 @@ setup_tables (void)
die (unable to allocate space for root directory in memory);
}
@@ -110,7 +120,7 @@ Index: dosfstools-2.11/mkdosfs/mkdosfs.c
memset(root_dir, 0, size_root_dir);
if ( memcmp(volume_name,, 11) )
{
-@@ -1314,11 +1348,11 @@
+@@ -1314,11 +1348,11 @@ setup_tables (void)
}
if (!(blank_sector = malloc( sector_size )))
@@ -125,7 +135,7 @@ Index: dosfstools-2.11/mkdosfs/mkdosfs.c
/* Write the new filesystem's data tables to wherever they're going to end
up! */
#define error(str)\
-@@ -1340,7 +1374,7 @@
+@@ -1340,7 +1374,7 @@ setup_tables (void)
do {\
int __size = (size); \
if (write (dev, buf, __size) != __size) \
@@ -134,7 +144,7 @@ Index: dosfstools-2.11/mkdosfs/mkdosfs.c
} while(0)
-@@ -1412,6 +1446,452 @@
+@@ -1412,6 +1446,454 @@ write_tables (void)
free (fat); /* Free up the fat table space reserved during setup_tables
[OE-core] [PATCH 2/3] wic: add mkhybridiso kickstart file
Add kickstart file for generating a hybrid bootable iso image using isoimage-isohybrid plugin, the output image is HYBRID_ISO_IMG-cd.iso, the label is HYBRIDISO, and the rootfs.img file is an image with ext3 file system, and uses grub as bootloader for EFI boot and syslinux for legacy boot. Signed-off-by: Mihaly Varga mihaly.va...@ni.com --- scripts/lib/image/canned-wks/mkhybridiso.wks | 7 +++ 1 file changed, 7 insertions(+) create mode 100644 scripts/lib/image/canned-wks/mkhybridiso.wks diff --git a/scripts/lib/image/canned-wks/mkhybridiso.wks b/scripts/lib/image/canned-wks/mkhybridiso.wks new file mode 100644 index 000..b443c15 --- /dev/null +++ b/scripts/lib/image/canned-wks/mkhybridiso.wks @@ -0,0 +1,7 @@ +# short-description: Create a hybrid ISO image +# long-description: Creates an EFI and legacy bootable hybrid ISO image +# which can be used on optical media as well as USB media. + +part /boot --source isoimage-isohybrid --sourceparams=loader=grub-efi,image_name=HYBRID_ISO_IMG --ondisk cd --label HYBRIDISO --fstype=ext3 + +bootloader --timeout=15 --append= -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] wic: Add plugin for hybrid iso image
Hi Ed, Thank you for your comments. There is a slightly modified version of the isoimage-isohybrid plugin, the kickstart file and the wic selftest extended with the iso image creation test case. On 7/28/2015 1:57 PM, Ed Bartosh wrote: Hi Mihaly, The code looks ok to me. Can you please fix the following: 1. Pylint is reporting a lot of long lines, indentation and other issues, so it would be nice if you run it and fix at least some of them? 2. Docstring of plugin class is shown in 'wic help plugins' output. Some lines of your plugins look very long there. Please, reformat them. 3. kickstart.get_timeout has a parameter to specify default timeout value. You can use that instead of assigning default value in the code. 4. Using names prefixed by two underscores is only needed if you're really concerned about the name and want it to be mangled by python. One underscore is more than enough in most cases. 5. Please add test case(s) for your plugin to meta/lib/oeqa/selftest/wic.py. This can help keeping your plugin in working state as yocto autobuilder regularly runs all tests. 6. What's crdtools and how to bake them? This is a typo in the commit message, is about cdrtools program set, which contains the mkisofs program. I corrected the commit message. Best regards Mihaly -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] wic: Test creation of iso image
Added new wic testcase, for testing the creation of the hybrid iso image with isoimage-isohybrid plugin. Signed-off-by: Mihaly Varga mihaly.va...@ni.com --- meta/lib/oeqa/selftest/wic.py | 8 1 file changed, 8 insertions(+) diff --git a/meta/lib/oeqa/selftest/wic.py b/meta/lib/oeqa/selftest/wic.py index 0c503ef..117bd9d 100644 --- a/meta/lib/oeqa/selftest/wic.py +++ b/meta/lib/oeqa/selftest/wic.py @@ -160,3 +160,11 @@ class Wic(oeSelfTest): self.assertEqual(0, status) self.assertEqual(1, len(glob(self.resultdir + \ %(wks)s-*.direct % vars))) + +def test18_iso_image(self): +Test creation of hybrid iso imagewith legacy and EFI boot +self.assertEqual(0, runCmd(wic create mkhybridiso + --image-name core-image-minimal).status) +self.assertEqual(1, len(glob(self.resultdir + HYBRID_ISO_IMG-*.direct))) +self.assertEqual(1, len(glob(self.resultdir + HYBRID_ISO_IMG-*.iso))) + -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 1/1] qemurunner: Improves checking for server and target IPs on qemus parameters
Fixes OS hanging infinitely waiting for qemus process to release bitbake.lock
Signed-off-by: Alejandro Hernandez alejandro.hernan...@linux.intel.com
---
meta/lib/oeqa/utils/qemurunner.py | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/meta/lib/oeqa/utils/qemurunner.py
b/meta/lib/oeqa/utils/qemurunner.py
index 1cf8f76..6c1b8dd 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -120,14 +120,17 @@ class QemuRunner:
cmdline = ''
with open('/proc/%s/cmdline' % self.qemupid) as p:
cmdline = p.read()
-ips = re.findall(((?:[0-9]{1,3}\.){3}[0-9]{1,3}),
cmdline.split(ip=)[1])
-if not ips or len(ips) != 3:
+ try:
+ips = re.findall(((?:[0-9]{1,3}\.){3}[0-9]{1,3}),
cmdline.split(ip=)[1])
+if not ips or len(ips) != 3:
+raise ValueError
+else:
+self.ip = ips[0]
+self.server_ip = ips[1]
+except IndexError, ValueError:
logger.info(Couldn't get ip from qemu process arguments! Here
is the qemu command line used: %s % cmdline)
self.stop()
return False
-else:
-self.ip = ips[0]
-self.server_ip = ips[1]
logger.info(Target IP: %s % self.ip)
logger.info(Server IP: %s % self.server_ip)
logger.info(Waiting at most %d seconds for login banner %
self.boottime)
--
1.8.4.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] wic: Add plugin for hybrid iso image
This plugin creates a hybrid, legacy and EFI bootable ISO image. The generated image can be used on optical media as well as USB media. Legacy boot uses syslinux and EFI boot uses grub or gummiboot (not implemented yet) as bootloader. The plugin creates the directories required by bootloaders and populates them by creating and configuring the bootloader files. The plugin adds an image file to the iso which contains the directory tree of the rootfs folder specified by the --rootfs argument or by the IMAGE_ROOTFS bitbake variable. Using the isohybryd tool, the created .iso image is enhanced by a MBR for booting from disk storage devices, consequently the provided iso image could be copyed directly by dd comand onto USB drive or could be burned to an optical media by using a suitable image burner. The plugin depends on parted, e2fstools, syslinux, grub, cdrtools, dosfstools and mtools program. Some of the functions in this plugin were inspired from bootimg-efi.py and bootimg-pcbios.py plugins implemented by Tom Zanussi. Signed-off-by: Mihaly Varga mihaly.va...@ni.com --- .../lib/wic/plugins/source/isoimage-isohybrid.py | 538 + 1 file changed, 538 insertions(+) create mode 100644 scripts/lib/wic/plugins/source/isoimage-isohybrid.py diff --git a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py new file mode 100644 index 000..1cee906 --- /dev/null +++ b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py @@ -0,0 +1,538 @@ +# ex:ts=4:sw=4:sts=4:et +# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*- + +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License version 2 as +# published by the Free Software Foundation. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License along +# with this program; if not, write to the Free Software Foundation, Inc., +# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. +# +# DESCRIPTION +# This implements the 'isoimage-isohybrid' source plugin class for 'wic' +# +# AUTHORS +# Mihaly Varga mihaly.varga (at] ni.com + +import os +import re +import shutil + +from wic import kickstart, msger +from wic.pluginbase import SourcePlugin +from wic.utils.oe.misc import exec_cmd, exec_native_cmd, get_bitbake_var + +class IsoImagePlugin(SourcePlugin): + +Create a bootable ISO image + +This plugin creates a hybrid, legacy and EFI bootable ISO image. The +generated image can be used on optical media as well as USB media. + +Legacy boot uses syslinux and EFI boot uses grub or gummiboot (not +implemented yet) as bootloader. The plugin creates the directories required +by bootloaders and populates them by creating and configuring the +bootloader files. + +Example kickstart file: +part /boot --source isoimage-isohybrid --sourceparams=loader=grub-efi, \\ +image_name= IsoImage --ondisk cd --label LIVECD --fstype=ext2 +bootloader --timeout=10 --append= + +In --sourceparams loader specifies the bootloader used for booting in EFI +mode, while image_name specifies the name of the generated image. In the +example above, wic creates an ISO image named IsoImage-cd.direct (default +extension added by direct imeger plugin) and a file named IsoImage-cd.iso + + +name = 'isoimage-isohybrid' + +@classmethod +def do_configure_syslinux(cls, cr, cr_workdir): + +Create loader-specific (syslinux) config + +splash = os.path.join(cr_workdir, /ISO/boot/splash.jpg) +if os.path.exists(splash): +splashline = menu background splash.jpg +else: +splashline = + +options = cr.ks.handler.bootloader.appendLine + +timeout = kickstart.get_timeout(cr.ks, 10) + +syslinux_conf = +syslinux_conf += PROMPT 0\n +syslinux_conf += TIMEOUT %s \n % timeout +syslinux_conf += \n +syslinux_conf += ALLOWOPTIONS 1\n +syslinux_conf += SERIAL 0 115200\n +syslinux_conf += \n +if splashline: +syslinux_conf += %s\n % splashline +syslinux_conf += DEFAULT boot\n +syslinux_conf += LABEL boot\n + +kernel = /bzImage +syslinux_conf += KERNEL + kernel + \n +syslinux_conf += APPEND initrd=/initrd LABEL=boot %s\n % options + +msger.debug(Writing syslinux config %s/ISO/isolinux/isolinux.cfg \ +% cr_workdir) +with open(%s/ISO/isolinux/isolinux.cfg % cr_workdir, w) as cfg: +cfg.write(syslinux_conf) + +@classmethod +def do_configure_grubefi(cls, part, cr, cr_workdir): + +
[OE-core] [PATCH v3 1/1] qemurunner: Improves checking for server and target IPs on qemus parameters
Fixes OS hanging infinitely waiting for qemus process to release bitbake.lock
Signed-off-by: Alejandro Hernandez alejandro.hernan...@linux.intel.com
---
meta/lib/oeqa/utils/qemurunner.py | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/meta/lib/oeqa/utils/qemurunner.py
b/meta/lib/oeqa/utils/qemurunner.py
index 1cf8f76..02ac89c 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -120,14 +120,17 @@ class QemuRunner:
cmdline = ''
with open('/proc/%s/cmdline' % self.qemupid) as p:
cmdline = p.read()
-ips = re.findall(((?:[0-9]{1,3}\.){3}[0-9]{1,3}),
cmdline.split(ip=)[1])
-if not ips or len(ips) != 3:
+try:
+ips = re.findall(((?:[0-9]{1,3}\.){3}[0-9]{1,3}),
cmdline.split(ip=)[1])
+if not ips or len(ips) != 3:
+raise ValueError
+else:
+self.ip = ips[0]
+self.server_ip = ips[1]
+except IndexError, ValueError:
logger.info(Couldn't get ip from qemu process arguments! Here
is the qemu command line used: %s % cmdline)
self.stop()
return False
-else:
-self.ip = ips[0]
-self.server_ip = ips[1]
logger.info(Target IP: %s % self.ip)
logger.info(Server IP: %s % self.server_ip)
logger.info(Waiting at most %d seconds for login banner %
self.boottime)
--
1.8.4.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel-yocto: do_configme: Add $TOOLCHAIN_OPTIONS to CFLAGS
On Thu, Aug 6, 2015 at 3:23 AM, Ioan-Adrian Ratiu adrian.ra...@ni.com wrote: On 05.08.2015 16:50, Bruce Ashfield wrote: On Wed, Aug 5, 2015 at 4:39 AM, Adrian Ratiu adrian.ra...@ni.com wrote: Bruce Ashfield bruce.ashfi...@gmail.com wrote on 05.08.2015 05:17:14: On Tue, Aug 4, 2015 at 4:41 AM, Ioan-Adrian Ratiu adrian.ra...@ni.com wrote: The kernel configure step was broken by the sysroot poisoning in [1]. Can you be more precise here ? Configuration certainly works for me .. and has been working since last October. This works because it was fixed in linux-yocto.inc *after* the sysroot poisoning. I've mentioned this in the next line :) But this is not what this fix is for, this fix should have been done at the same time with adding $TOOLCHAIN_OPTIONS to $KERNEL_CC in linux-yocto.inc. This bug was missed because there is NO error reporting in yocto-kernel-tools merge_configs.sh and the build continues despite the error. I've sent a patch to fail loudly in case merge_configs.sh fails in yocto-kernel-tools. You know about it because you responded to that mail :) These issues are related. right. And as you saw there .. I don't need that patch. So we might as well let this one sit as well. It's great if these issues were already fixed somehow different than how I proposed. Are those local changes pushed to a public branch yet? I would really like to test the new code. The solution is similar in the end, I just came to adding extra error checking via a different route (missing .cfg fragments not being reported and stopping the build). They are unfortunately back on my development machine, and I'm on vacation at the moment. But I will be back near that equipment next week! Cheers, Bruce P.S. Sorry for the html crap in my previous mail, I hope it's gone now. -- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] qemurunner: Improves checking for Server and Target IPs on qemus parameters
On Wed, 2015-08-05 at 23:21 +, Alejandro Hernandez wrote:
Fixes server hanging infinitely waiting for qemus process to let go of
bitbake.lock
Signed-off-by: Alejandro Hernandez alejandro.hernan...@linux.intel.com
---
meta/lib/oeqa/utils/qemurunner.py | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/meta/lib/oeqa/utils/qemurunner.py
b/meta/lib/oeqa/utils/qemurunner.py
index 1cf8f76..ff53af3 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -120,14 +120,17 @@ class QemuRunner:
cmdline = ''
with open('/proc/%s/cmdline' % self.qemupid) as p:
cmdline = p.read()
-ips = re.findall(((?:[0-9]{1,3}\.){3}[0-9]{1,3}),
cmdline.split(ip=)[1])
-if not ips or len(ips) != 3:
+ try:
+ips = re.findall(((?:[0-9]{1,3}\.){3}[0-9]{1,3}),
cmdline.split(ip=)[1])
+if not ips or len(ips) != 3:
+ raise Exception
+else:
+self.ip = ips[0]
+self.server_ip = ips[1]
+ except Exception:
logger.info(Couldn't get ip from qemu process arguments!
Here is the qemu command line used: %s % cmdline)
self.stop()
return False
-else:
-self.ip = ips[0]
-self.server_ip = ips[1]
logger.info(Target IP: %s % self.ip)
logger.info(Server IP: %s % self.server_ip)
logger.info(Waiting at most %d seconds for login banner %
self.boottime)
This is ok, however its not as pythonic as perhaps it could/should be.
Usually with python you should always trap specific exceptions, so in
this case you'd do:
try:
y = x[1]
if len(ips) != 3:
raise ValueError
except IndexError, ValueError:
handle error
You do this so that if something unexpected happens, the code doesn't
swallow the error but shows a complete traceback and failure.
The whitespace on this patch also looks a little bit odd although I
didn't try applying the patch.
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [meta-oe][PATCH] dosfstools-2.11: Fix memory leak in mkdosfs
Added new patch that fixes the memory leak that was introduced in
mkdosfs-dir.patch.
Signed-off-by: Amarnath Valluri amarnath.vall...@intel.com
---
.../dosfstools/dosfstools-Fix-memroy-leak.patch| 30 ++
.../recipes-devtools/dosfstools/dosfstools_2.11.bb | 1 +
2 files changed, 31 insertions(+)
create mode 100644
meta/recipes-devtools/dosfstools/dosfstools/dosfstools-Fix-memroy-leak.patch
diff --git
a/meta/recipes-devtools/dosfstools/dosfstools/dosfstools-Fix-memroy-leak.patch
b/meta/recipes-devtools/dosfstools/dosfstools/dosfstools-Fix-memroy-leak.patch
new file mode 100644
index 000..555250f
--- /dev/null
+++
b/meta/recipes-devtools/dosfstools/dosfstools/dosfstools-Fix-memroy-leak.patch
@@ -0,0 +1,30 @@
+From 2c2408d815b7cd76a2edd4261eb051e264993090 Mon Sep 17 00:00:00 2001
+From: Amarnath Valluri amarnath.vall...@intel.com
+Date: Wed, 5 Aug 2015 16:25:51 +0300
+Subject: [PATCH] dosfstools: Fix memroy leak
+
+Upstream-Status:[Inappropriate]
+
+Avoid leaking memory allocated for buffer.
+
+Signed-off-by: Amarnath Valluri amarnath.vall...@intel.com
+---
+ mkdosfs/mkdosfs.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/mkdosfs/mkdosfs.c b/mkdosfs/mkdosfs.c
+index 88b0dc2..2822358 100644
+--- a/mkdosfs/mkdosfs.c
b/mkdosfs/mkdosfs.c
+@@ -1693,6 +1693,8 @@ static int add_file(char *filename, struct dir_entry
*dir, unsigned char attr)
+ writebuf(buffer, size, data);
+ }
+
++ free(buffer);
++
+ exit_add:
+ if (infile) close(infile);
+ return 0;
+--
+2.1.4
+
diff --git a/meta/recipes-devtools/dosfstools/dosfstools_2.11.bb
b/meta/recipes-devtools/dosfstools/dosfstools_2.11.bb
index beec488..824c04d 100644
--- a/meta/recipes-devtools/dosfstools/dosfstools_2.11.bb
+++ b/meta/recipes-devtools/dosfstools/dosfstools_2.11.bb
@@ -19,6 +19,7 @@ SRC_URI =
http://pkgs.fedoraproject.org/repo/pkgs/${BPN}/${BP}.src.tar.gz/407d4
file://nofat32_autoselect.patch \
file://fix_populated_dosfs_creation.patch \
file://0001-Include-fcntl.h-for-getting-loff_t-definition.patch \
+ file://dosfstools-Fix-memroy-leak.patch \
SRC_URI[md5sum] = 407d405ade410f7597d364ab5dc8c9f6
--
2.1.4
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/6] gtk+3: Upgrade 3.16.4 - 3.16.6
Remove a backported patch.
Signed-off-by: Jussi Kukkonen jussi.kukko...@intel.com
---
meta/recipes-gnome/gtk+/gtk+3/wayland-pango.patch | 28 --
.../gtk+/{gtk+3_3.16.4.bb = gtk+3_3.16.6.bb} | 5 ++--
2 files changed, 2 insertions(+), 31 deletions(-)
delete mode 100644 meta/recipes-gnome/gtk+/gtk+3/wayland-pango.patch
rename meta/recipes-gnome/gtk+/{gtk+3_3.16.4.bb = gtk+3_3.16.6.bb} (77%)
diff --git a/meta/recipes-gnome/gtk+/gtk+3/wayland-pango.patch
b/meta/recipes-gnome/gtk+/gtk+3/wayland-pango.patch
deleted file mode 100644
index 1d6f12b..000
--- a/meta/recipes-gnome/gtk+/gtk+3/wayland-pango.patch
+++ /dev/null
@@ -1,28 +0,0 @@
-Upstream-Status: Backport
-Signed-off-by: Ross Burton ross.bur...@intel.com
-
-From 802b006b3768ddc8c8cdf0af27428e7042c36509 Mon Sep 17 00:00:00 2001
-From: nick oavc-fu...@yandex.com
-Date: Mon, 29 Jun 2015 20:37:26 +0100
-Subject: settings: Include pangofc-fontmap.h header on Wayland
-
-In case the X11 backend is not enabled, we still need to include the
-pangofc-fontmap.h header file, as we use the Pango/FontConfig API in
-both the X11 and Wayland case.
-
-https://bugzilla.gnome.org/show_bug.cgi?id=751625
-
-diff --git a/gtk/gtksettings.c b/gtk/gtksettings.c
-index 327faf5..a40cb84 100644
a/gtk/gtksettings.c
-+++ b/gtk/gtksettings.c
-@@ -41,6 +41,7 @@
-
- #ifdef GDK_WINDOWING_WAYLAND
- #include wayland/gdkwayland.h
-+#include pango/pangofc-fontmap.h
- #endif
-
- #ifdef GDK_WINDOWING_BROADWAY
---
-cgit v0.10.2
diff --git a/meta/recipes-gnome/gtk+/gtk+3_3.16.4.bb
b/meta/recipes-gnome/gtk+/gtk+3_3.16.6.bb
similarity index 77%
rename from meta/recipes-gnome/gtk+/gtk+3_3.16.4.bb
rename to meta/recipes-gnome/gtk+/gtk+3_3.16.6.bb
index 4bb6b0c..1d736a4 100644
--- a/meta/recipes-gnome/gtk+/gtk+3_3.16.4.bb
+++ b/meta/recipes-gnome/gtk+/gtk+3_3.16.6.bb
@@ -5,11 +5,10 @@ MAJ_VER = ${@oe.utils.trim_version(${PV}, 2)}
SRC_URI =
http://ftp.gnome.org/pub/gnome/sources/gtk+/${MAJ_VER}/gtk+-${PV}.tar.xz \
file://hardcoded_libtool.patch \
file://Dont-force-csd.patch \
- file://wayland-pango.patch \
-SRC_URI[md5sum] = c7497aaf6730524a127597b768a73bd7
-SRC_URI[sha256sum] =
1ee5dbd7a4cb81a91eaa1b7ae64ba5a3eab6a3c0a764155583ab96524590fc8e
+SRC_URI[md5sum] = fc59e5c8b5a4585b60623dd708df400b
+SRC_URI[sha256sum] =
4d12726d0856a968b41802ae5c5971d7e9bac532717e309d3f81b9989da5ffbe
S = ${WORKDIR}/gtk+-${PV}
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/6] Bunch of version upgrades
libinput goes to 0.21 which should be last release before 1.0. Other
upgrades are minor.
The vte change is just for LICENSE variable: our version is still
LGPL2.0 instead of LGPL2.1+ like recent releases.
The following changes since commit a8b723498c9a7106210db140452886894494b4d6:
bitbake: cooker: Resolve file monitoring race issues when using memres
bitbake (2015-08-03 07:36:25 +0100)
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib jku/upgrades
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=jku/upgrades
Jussi Kukkonen (6):
gtk+3: Upgrade 3.16.4 - 3.16.6
gtk-icon-utils-native: Upgrade 3.16.4 - 3.16.6
fontconfig: Upgrade 2.11.93 - 2.11.94
vte: Fix LICENSE to LGPL2.0
libinput: Upgrade 0.18.0 - 0.21.0
which: Upgrade 2.20 - 2.21
.../which/which-2.20/remove-declaration.patch | 18 --
.../{which-2.20 = which-2.21}/automake.patch | 14 +++--
.../which/{which_2.20.bb = which_2.21.bb} | 6 +-
meta/recipes-gnome/gtk+/gtk+3/wayland-pango.patch | 28 -
.../gtk+/{gtk+3_3.16.4.bb = gtk+3_3.16.6.bb} | 5 +-
...e_3.16.4.bb = gtk-icon-utils-native_3.16.6.bb} | 4 +-
...fontconfig_2.11.93.bb = fontconfig_2.11.94.bb} | 4 +-
...ics-need-to-fake-new-touches-on-TRIPLETAP.patch | 72 ++
.../{libinput_0.18.0.bb = libinput_0.21.0.bb} | 8 ++-
meta/recipes-support/vte/vte.inc | 2 +-
10 files changed, 96 insertions(+), 65 deletions(-)
delete mode 100644
meta/recipes-extended/which/which-2.20/remove-declaration.patch
rename meta/recipes-extended/which/{which-2.20 = which-2.21}/automake.patch
(56%)
rename meta/recipes-extended/which/{which_2.20.bb = which_2.21.bb} (84%)
delete mode 100644 meta/recipes-gnome/gtk+/gtk+3/wayland-pango.patch
rename meta/recipes-gnome/gtk+/{gtk+3_3.16.4.bb = gtk+3_3.16.6.bb} (77%)
rename meta/recipes-gnome/gtk+/{gtk-icon-utils-native_3.16.4.bb =
gtk-icon-utils-native_3.16.6.bb} (94%)
rename meta/recipes-graphics/fontconfig/{fontconfig_2.11.93.bb =
fontconfig_2.11.94.bb} (92%)
create mode 100644
meta/recipes-graphics/wayland/libinput/touchpad-serial-synaptics-need-to-fake-new-touches-on-TRIPLETAP.patch
rename meta/recipes-graphics/wayland/{libinput_0.18.0.bb =
libinput_0.21.0.bb} (63%)
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/6] gtk-icon-utils-native: Upgrade 3.16.4 - 3.16.6
Signed-off-by: Jussi Kukkonen jussi.kukko...@intel.com
---
...tk-icon-utils-native_3.16.4.bb = gtk-icon-utils-native_3.16.6.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-gnome/gtk+/{gtk-icon-utils-native_3.16.4.bb =
gtk-icon-utils-native_3.16.6.bb} (94%)
diff --git a/meta/recipes-gnome/gtk+/gtk-icon-utils-native_3.16.4.bb
b/meta/recipes-gnome/gtk+/gtk-icon-utils-native_3.16.6.bb
similarity index 94%
rename from meta/recipes-gnome/gtk+/gtk-icon-utils-native_3.16.4.bb
rename to meta/recipes-gnome/gtk+/gtk-icon-utils-native_3.16.6.bb
index d433b90..cba3815 100644
--- a/meta/recipes-gnome/gtk+/gtk-icon-utils-native_3.16.4.bb
+++ b/meta/recipes-gnome/gtk+/gtk-icon-utils-native_3.16.6.bb
@@ -10,8 +10,8 @@ MAJ_VER = ${@oe.utils.trim_version(${PV}, 2)}
SRC_URI =
http://ftp.gnome.org/pub/gnome/sources/gtk+/${MAJ_VER}/gtk+-${PV}.tar.xz \
file://Remove-Gdk-dependency-from-gtk-encode-symbolic-svg.patch
-SRC_URI[md5sum] = c7497aaf6730524a127597b768a73bd7
-SRC_URI[sha256sum] =
1ee5dbd7a4cb81a91eaa1b7ae64ba5a3eab6a3c0a764155583ab96524590fc8e
+SRC_URI[md5sum] = fc59e5c8b5a4585b60623dd708df400b
+SRC_URI[sha256sum] =
4d12726d0856a968b41802ae5c5971d7e9bac532717e309d3f81b9989da5ffbe
LIC_FILES_CHKSUM = file://COPYING;md5=5f30f0716dfdd0d91eb439ebec522ec2 \
file://gtk/gtk.h;endline=25;md5=1d8dc0fccdbfa26287a271dce88af737 \
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/6] libinput: Upgrade 0.18.0 - 0.21.0
Include a workaround patch suggested by upstream when using
kernel 4.1.x.
Signed-off-by: Jussi Kukkonen jussi.kukko...@intel.com
---
...ics-need-to-fake-new-touches-on-TRIPLETAP.patch | 72 ++
.../{libinput_0.18.0.bb = libinput_0.21.0.bb} | 8 ++-
2 files changed, 77 insertions(+), 3 deletions(-)
create mode 100644
meta/recipes-graphics/wayland/libinput/touchpad-serial-synaptics-need-to-fake-new-touches-on-TRIPLETAP.patch
rename meta/recipes-graphics/wayland/{libinput_0.18.0.bb =
libinput_0.21.0.bb} (63%)
diff --git
a/meta/recipes-graphics/wayland/libinput/touchpad-serial-synaptics-need-to-fake-new-touches-on-TRIPLETAP.patch
b/meta/recipes-graphics/wayland/libinput/touchpad-serial-synaptics-need-to-fake-new-touches-on-TRIPLETAP.patch
new file mode 100644
index 000..97c63bd
--- /dev/null
+++
b/meta/recipes-graphics/wayland/libinput/touchpad-serial-synaptics-need-to-fake-new-touches-on-TRIPLETAP.patch
@@ -0,0 +1,72 @@
+This is a workaround upstream suggests for use with kernel 4.1.
+
+Upstream-Status: Inappropriate [temporary work-around]
+Signed-Off-By: Jussi Kukkonen jussi.kukko...@intel.com
+
+
+
+From: Peter Hutterer peter.hutte...@who-t.net
+Date: Mon Aug 3 18:23:12 PDT 2015
+Subject: [PATCH v3 libinput] touchpad: serial synaptics need to fake new
touches on TRIPLETAP
+
+On the 4.1 kernels synaptics pretends to have 3 slots (the serial fw only does
+2). This was added to avoid cursor jumps but has since been reverted for 4.2
+(kernel commit dbf3c37086, 4.1.3 is still buggy). In some cases a TRIPLETAP
+may be triggered without slot 2 ever activating.
+
+While there are still those kernels out there, work around this bug by opening
+a new touch point where none exists if the fake finger count exceeds the slot
+count.
+
+Reported-by: Jan Alexander Steffens jan.steffens at gmail.com
+Signed-off-by: Peter Hutterer peter.hutterer at who-t.net
+Tested-by: Jan Alexander Steffens jan.steffens at gmail.com
+Reviewed-by: Hans de Goede hdegoede at redhat.com
+---
+Changes to v2:
+- split out the handling instead of having a tmp state variable, see Hans'
+ comments from v2
+
+Mainly sending this to the list again so I have a link to point people to.
+If you're on 4.1.x add this patch to your distribution package.
+
+ src/evdev-mt-touchpad.c | 22 --
+ 1 file changed, 16 insertions(+), 6 deletions(-)
+
+diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
+index a683d9a..5ef03d5 100644
+--- a/src/evdev-mt-touchpad.c
b/src/evdev-mt-touchpad.c
+@@ -369,13 +369,23 @@ tp_restore_synaptics_touches(struct tp_dispatch *tp,
+ for (i = 0; i tp-num_slots; i++) {
+ struct tp_touch *t = tp_get_touch(tp, i);
+
+- if (t-state != TOUCH_END)
++ switch(t-state) {
++ case TOUCH_HOVERING:
++ case TOUCH_BEGIN:
++ case TOUCH_UPDATE:
+ continue;
+-
+- /* new touch, move it through begin to update immediately */
+- tp_new_touch(tp, t, time);
+- tp_begin_touch(tp, t, time);
+- t-state = TOUCH_UPDATE;
++ case TOUCH_NONE:
++ /* new touch, move it through to begin immediately */
++ tp_new_touch(tp, t, time);
++ tp_begin_touch(tp, t, time);
++ break;
++ case TOUCH_END:
++ /* touch just ended ,we need need to restore it to
update */
++ tp_new_touch(tp, t, time);
++ tp_begin_touch(tp, t, time);
++ t-state = TOUCH_UPDATE;
++ break;
++ }
+ }
+ }
+
+--
+2.4.3
+
diff --git a/meta/recipes-graphics/wayland/libinput_0.18.0.bb
b/meta/recipes-graphics/wayland/libinput_0.21.0.bb
similarity index 63%
rename from meta/recipes-graphics/wayland/libinput_0.18.0.bb
rename to meta/recipes-graphics/wayland/libinput_0.21.0.bb
index 0fe1c6c..179596f 100644
--- a/meta/recipes-graphics/wayland/libinput_0.18.0.bb
+++ b/meta/recipes-graphics/wayland/libinput_0.21.0.bb
@@ -7,9 +7,11 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=2184aef38ff137ed33ce9a63b9d1eb8f
DEPENDS = libevdev udev mtdev
-SRC_URI = http://www.freedesktop.org/software/${BPN}/${BP}.tar.xz;
-SRC_URI[md5sum] = 0ddbb0d53d58dec0a86de6791560011a
-SRC_URI[sha256sum] =
64a70f96bab17a22eaf2fd7af17cf83def3388374096c7623be9448f62808cda
+SRC_URI = http://www.freedesktop.org/software/${BPN}/${BP}.tar.xz \
+
file://touchpad-serial-synaptics-need-to-fake-new-touches-on-TRIPLETAP.patch \
+
+SRC_URI[md5sum] = f91d8f4ced986f1ae16d52ea02bc7837
+SRC_URI[sha256sum] =
7cce7a9e510dfe5c4a19ad00e9350808d4f59f8611fd2b5e87213c507283f550
inherit autotools pkgconfig
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
[OE-core] [PATCH 3/6] fontconfig: Upgrade 2.11.93 - 2.11.94
Signed-off-by: Jussi Kukkonen jussi.kukko...@intel.com
---
.../fontconfig/{fontconfig_2.11.93.bb = fontconfig_2.11.94.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-graphics/fontconfig/{fontconfig_2.11.93.bb =
fontconfig_2.11.94.bb} (92%)
diff --git a/meta/recipes-graphics/fontconfig/fontconfig_2.11.93.bb
b/meta/recipes-graphics/fontconfig/fontconfig_2.11.94.bb
similarity index 92%
rename from meta/recipes-graphics/fontconfig/fontconfig_2.11.93.bb
rename to meta/recipes-graphics/fontconfig/fontconfig_2.11.94.bb
index e024adb..9bbff20 100644
--- a/meta/recipes-graphics/fontconfig/fontconfig_2.11.93.bb
+++ b/meta/recipes-graphics/fontconfig/fontconfig_2.11.94.bb
@@ -23,8 +23,8 @@ DEPENDS = expat freetype zlib
SRC_URI = http://fontconfig.org/release/fontconfig-${PV}.tar.gz \
file://revert-static-pkgconfig.patch \
-SRC_URI[md5sum] = 622f94f0f74e40775ea72d7d5f17a36d
-SRC_URI[sha256sum] =
296b5e83189589e537992d65ff01e0cd74eba9a91eb16a6890ce942e3695c526
+SRC_URI[md5sum] = 479be870c7f83f15f87bac085b61d641
+SRC_URI[sha256sum] =
73f6d323c7bcfbde25d78397675191d55b8f4139132c6a910f3a2d8a9a95
PACKAGES =+ fontconfig-utils
FILES_${PN} =+ ${datadir}/xml/*
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/6] vte: Fix LICENSE to LGPL2.0
Current releases of vte are LGPL 2.1+ but the one we have is still LGPL 2.0. Signed-off-by: Jussi Kukkonen jussi.kukko...@intel.com --- meta/recipes-support/vte/vte.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-support/vte/vte.inc b/meta/recipes-support/vte/vte.inc index 4081a7f..874062a 100644 --- a/meta/recipes-support/vte/vte.inc +++ b/meta/recipes-support/vte/vte.inc @@ -1,6 +1,6 @@ SUMMARY = Virtual terminal emulator GTK+ widget library BUGTRACKER = https://bugzilla.gnome.org/buglist.cgi?product=vte; -LICENSE = LGPLv2.1+ +LICENSE = LGPLv2.0 DEPENDS = glib-2.0 gtk+ intltool-native ncurses gobject-introspection-stub RDEPENDS_libvte = vte-termcap -- 2.1.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 6/6] which: Upgrade 2.20 - 2.21
* Drop one upstreamed patch, update the other one
Signed-off-by: Jussi Kukkonen jussi.kukko...@intel.com
---
.../which/which-2.20/remove-declaration.patch | 18 --
.../which/{which-2.20 = which-2.21}/automake.patch| 14 +-
.../which/{which_2.20.bb = which_2.21.bb} | 6 +++---
3 files changed, 12 insertions(+), 26 deletions(-)
delete mode 100644
meta/recipes-extended/which/which-2.20/remove-declaration.patch
rename meta/recipes-extended/which/{which-2.20 = which-2.21}/automake.patch
(56%)
rename meta/recipes-extended/which/{which_2.20.bb = which_2.21.bb} (84%)
diff --git a/meta/recipes-extended/which/which-2.20/remove-declaration.patch
b/meta/recipes-extended/which/which-2.20/remove-declaration.patch
deleted file mode 100644
index d3340a3..000
--- a/meta/recipes-extended/which/which-2.20/remove-declaration.patch
+++ /dev/null
@@ -1,18 +0,0 @@
-Remove the declaration of group_member since it has already been
-declared in unistd.h
-
-Signed-off-by: Dongxiao Xu dongxiao...@intel.com
-
-Upstream-Status: Inappropriate [embedded specific]
-
-diff -ruN which-2.20-orig/bash.c which-2.20/bash.c
which-2.20-orig/bash.c 2010-08-03 12:59:08.897088878 +0800
-+++ which-2.20/bash.c 2010-08-03 13:17:23.406097212 +0800
-@@ -46,7 +46,6 @@
- * - changed all occurences of 'gid_t' into 'GID_T'.
- * - exported functions needed in which.c
- */
--static int group_member (GID_T gid);
- static char* extract_colon_unit (char const* string, int* p_index);
-
- /*===
diff --git a/meta/recipes-extended/which/which-2.20/automake.patch
b/meta/recipes-extended/which/which-2.21/automake.patch
similarity index 56%
rename from meta/recipes-extended/which/which-2.20/automake.patch
rename to meta/recipes-extended/which/which-2.21/automake.patch
index ef00bc9..4d0f2e4 100644
--- a/meta/recipes-extended/which/which-2.20/automake.patch
+++ b/meta/recipes-extended/which/which-2.21/automake.patch
@@ -7,9 +7,13 @@ diff --git a/configure.ac b/configure.ac
index d974461..a20dfa8 100644
--- a/configure.ac
+++ b/configure.ac
-@@ -2,2 +2,3 @@ dnl Process this file with autoconf to produce a configure
script.
--AC_INIT(which.c)
--AM_INIT_AUTOMAKE(which, 2.20)
-+AC_INIT([which],[2.20])
-+AC_CONFIG_SRCDIR(which.c)
+@@ -1,7 +1,7 @@
+ dnl Process this file with autoconf to produce a configure script.
+ AC_INIT([which], [2.21])
+ AC_CONFIG_SRCDIR(which.c)
+-AM_INIT_AUTOMAKE
+AM_INIT_AUTOMAKE([foreign])
+ AM_CONFIG_HEADER(config.h)
+ AM_MAINTAINER_MODE
+
+
diff --git a/meta/recipes-extended/which/which_2.20.bb
b/meta/recipes-extended/which/which_2.21.bb
similarity index 84%
rename from meta/recipes-extended/which/which_2.20.bb
rename to meta/recipes-extended/which/which_2.21.bb
index 7483554..a7687f6 100644
--- a/meta/recipes-extended/which/which_2.20.bb
+++ b/meta/recipes-extended/which/which_2.21.bb
@@ -19,10 +19,10 @@ EXTRA_OECONF = --disable-iberty
SRC_URI = ${GNU_MIRROR}/which/which-${PV}.tar.gz \
file://automake.patch \
- file://remove-declaration.patch
+
-SRC_URI[md5sum] = 95be0501a466e515422cde4af46b2744
-SRC_URI[sha256sum] =
d417b65c650d88ad26a208293c1c6e3eb60d4b6d847f01ff8f66aca63e2857f8
+SRC_URI[md5sum] = 097ff1a324ae02e0a3b0369f07a7544a
+SRC_URI[sha256sum] =
f4a245b94124b377d8b49646bf421f9155d36aa7614b6ebf83705d3ffc76eaad
do_configure_prepend() {
sed -i -e 's%@ACLOCAL_CWFLAGS@%-I
${STAGING_DIR_NATIVE}/usr/share/cwautomacros/m4%g' ${S}/Makefile.am
${S}/tilde/Makefile.am
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel-yocto: do_configme: Add $TOOLCHAIN_OPTIONS to CFLAGS
On 05.08.2015 16:50, Bruce Ashfield wrote: On Wed, Aug 5, 2015 at 4:39 AM, Adrian Ratiu adrian.ra...@ni.com wrote: Bruce Ashfield bruce.ashfi...@gmail.com wrote on 05.08.2015 05:17:14: On Tue, Aug 4, 2015 at 4:41 AM, Ioan-Adrian Ratiu adrian.ra...@ni.com wrote: The kernel configure step was broken by the sysroot poisoning in [1]. Can you be more precise here ? Configuration certainly works for me .. and has been working since last October. This works because it was fixed in linux-yocto.inc *after* the sysroot poisoning. I've mentioned this in the next line :) But this is not what this fix is for, this fix should have been done at the same time with adding $TOOLCHAIN_OPTIONS to $KERNEL_CC in linux-yocto.inc. This bug was missed because there is NO error reporting in yocto-kernel-tools merge_configs.sh and the build continues despite the error. I've sent a patch to fail loudly in case merge_configs.sh fails in yocto-kernel-tools. You know about it because you responded to that mail :) These issues are related. right. And as you saw there .. I don't need that patch. So we might as well let this one sit as well. It's great if these issues were already fixed somehow different than how I proposed. Are those local changes pushed to a public branch yet? I would really like to test the new code. P.S. Sorry for the html crap in my previous mail, I hope it's gone now. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-oe][PATCH] dosfstools-2.11: Fix memory leak in mkdosfs
On 08/06/2015 12:06 PM, Amarnath Valluri wrote: Added new patch that fixes the memory leak that was introduced in mkdosfs-dir.patch. You should update the original patch then, not pile additional patches on top. The least painful way is: 1) unpack the sources (manually from tarball, or using bitbake -c unpack) 2) 'git init; git add *; git commit' to create an git repository from the sources 3) apply the patch that needs fixing, then do the fix 4) make a git commit, then produce a patch using git format-patch, then move the new patch back to the recipe directory and update the recipe 5) build the recipe to make sure it still builds 6) make a git commit with the recipe update, and submit it here :) Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] create-pull-request: cd to relative directory
On Aug 6, 2015, at 1:38 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Wednesday 05 August 2015 20:33:48 Khem Raj wrote: On Wed, Aug 5, 2015 at 2:01 AM, Ed Bartosh ed.bart...@linux.intel.com wrote: create-pull-request -d path creates empty patches if directory is specified as a path, i.e. ./bitbake or ./bitbake/ or full path. It behaves expected way only if script is run with -d bitbake, i.e. relative dir name doesn't contain '\'. Fixed this unwanted behaviour by changing directory and running git format-patch in it with --relative, without specifying relative path as a parameter. Signed-off-by: Ed Bartosh ed.bart...@linux.intel.com --- scripts/create-pull-request | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/scripts/create-pull-request b/scripts/create-pull-request index 216edfd..7eac618 100755 --- a/scripts/create-pull-request +++ b/scripts/create-pull-request @@ -177,12 +177,15 @@ mkdir $ODIR if [ -n $RELDIR ]; then ODIR=$(realpath $ODIR) - extraopts=--relative=$RELDIR + pushd $RELDIR can we avoid using pushd so it works with non bash shells too ? Should be possible, but it's worth mentioning that this script already starts with #!/bin/bash. Does it have to be ? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] create-pull-request: cd to relative directory
On Thursday 06 August 2015 08:05:40 Khem Raj wrote: On Aug 6, 2015, at 1:38 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Wednesday 05 August 2015 20:33:48 Khem Raj wrote: On Wed, Aug 5, 2015 at 2:01 AM, Ed Bartosh ed.bart...@linux.intel.com wrote: create-pull-request -d path creates empty patches if directory is specified as a path, i.e. ./bitbake or ./bitbake/ or full path. It behaves expected way only if script is run with -d bitbake, i.e. relative dir name doesn't contain '\'. Fixed this unwanted behaviour by changing directory and running git format-patch in it with --relative, without specifying relative path as a parameter. Signed-off-by: Ed Bartosh ed.bart...@linux.intel.com --- scripts/create-pull-request | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/scripts/create-pull-request b/scripts/create-pull-request index 216edfd..7eac618 100755 --- a/scripts/create-pull-request +++ b/scripts/create-pull-request @@ -177,12 +177,15 @@ mkdir $ODIR if [ -n $RELDIR ]; then ODIR=$(realpath $ODIR) - extraopts=--relative=$RELDIR + pushd $RELDIR can we avoid using pushd so it works with non bash shells too ? Should be possible, but it's worth mentioning that this script already starts with #!/bin/bash. Does it have to be ? Are you volunteering to fix any other bashisms in the script? If so no ;) Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel-yocto: do_configme: Add $TOOLCHAIN_OPTIONS to CFLAGS
On 06.08.2015 16:19, Bruce Ashfield wrote: On Thu, Aug 6, 2015 at 3:23 AM, Ioan-Adrian Ratiu adrian.ra...@ni.com wrote: On 05.08.2015 16:50, Bruce Ashfield wrote: On Wed, Aug 5, 2015 at 4:39 AM, Adrian Ratiu adrian.ra...@ni.com wrote: Bruce Ashfield bruce.ashfi...@gmail.com wrote on 05.08.2015 05:17:14: On Tue, Aug 4, 2015 at 4:41 AM, Ioan-Adrian Ratiu adrian.ra...@ni.com wrote: The kernel configure step was broken by the sysroot poisoning in [1]. Can you be more precise here ? Configuration certainly works for me .. and has been working since last October. This works because it was fixed in linux-yocto.inc *after* the sysroot poisoning. I've mentioned this in the next line :) But this is not what this fix is for, this fix should have been done at the same time with adding $TOOLCHAIN_OPTIONS to $KERNEL_CC in linux-yocto.inc. This bug was missed because there is NO error reporting in yocto-kernel-tools merge_configs.sh and the build continues despite the error. I've sent a patch to fail loudly in case merge_configs.sh fails in yocto-kernel-tools. You know about it because you responded to that mail :) These issues are related. right. And as you saw there .. I don't need that patch. So we might as well let this one sit as well. It's great if these issues were already fixed somehow different than how I proposed. Are those local changes pushed to a public branch yet? I would really like to test the new code. The solution is similar in the end, I just came to adding extra error checking via a different route (missing .cfg fragments not being reported and stopping the build). They are unfortunately back on my development machine, and I'm on vacation at the moment. But I will be back near that equipment next week! I still think that we are solving two different issues altogether with these patches, but I think it best we wait until you push your changes and after that (if need be) I will reapply my patches on top of your changes and resend (again, if need be). Have a nice vacation! -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] create-pull-request: cd to relative directory
On Aug 6, 2015, at 8:16 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Thursday 06 August 2015 08:05:40 Khem Raj wrote: On Aug 6, 2015, at 1:38 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Wednesday 05 August 2015 20:33:48 Khem Raj wrote: On Wed, Aug 5, 2015 at 2:01 AM, Ed Bartosh ed.bart...@linux.intel.com wrote: create-pull-request -d path creates empty patches if directory is specified as a path, i.e. ./bitbake or ./bitbake/ or full path. It behaves expected way only if script is run with -d bitbake, i.e. relative dir name doesn't contain '\'. Fixed this unwanted behaviour by changing directory and running git format-patch in it with --relative, without specifying relative path as a parameter. Signed-off-by: Ed Bartosh ed.bart...@linux.intel.com --- scripts/create-pull-request | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/scripts/create-pull-request b/scripts/create-pull-request index 216edfd..7eac618 100755 --- a/scripts/create-pull-request +++ b/scripts/create-pull-request @@ -177,12 +177,15 @@ mkdir $ODIR if [ -n $RELDIR ]; then ODIR=$(realpath $ODIR) - extraopts=--relative=$RELDIR + pushd $RELDIR can we avoid using pushd so it works with non bash shells too ? Should be possible, but it's worth mentioning that this script already starts with #!/bin/bash. Does it have to be ? Are you volunteering to fix any other bashisms in the script? If so no ;) looking at the script there seems to be none and checkbashism confirms it checkbashisms scripts/create-pull-request could not find any possible bashisms in bash script scripts/create-pull-request so in effect this will be the first one. May be in your V2 you should remove /bin/bash from interpreter as well. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] create-pull-request: cd to relative directory
On Wednesday 05 August 2015 20:33:48 Khem Raj wrote: On Wed, Aug 5, 2015 at 2:01 AM, Ed Bartosh ed.bart...@linux.intel.com wrote: create-pull-request -d path creates empty patches if directory is specified as a path, i.e. ./bitbake or ./bitbake/ or full path. It behaves expected way only if script is run with -d bitbake, i.e. relative dir name doesn't contain '\'. Fixed this unwanted behaviour by changing directory and running git format-patch in it with --relative, without specifying relative path as a parameter. Signed-off-by: Ed Bartosh ed.bart...@linux.intel.com --- scripts/create-pull-request | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/scripts/create-pull-request b/scripts/create-pull-request index 216edfd..7eac618 100755 --- a/scripts/create-pull-request +++ b/scripts/create-pull-request @@ -177,12 +177,15 @@ mkdir $ODIR if [ -n $RELDIR ]; then ODIR=$(realpath $ODIR) - extraopts=--relative=$RELDIR + pushd $RELDIR can we avoid using pushd so it works with non bash shells too ? Should be possible, but it's worth mentioning that this script already starts with #!/bin/bash. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] create-pull-request: cd to relative directory
On Thu, Aug 06, 2015 at 09:38:16AM +0100, Paul Eggleton wrote: On Wednesday 05 August 2015 20:33:48 Khem Raj wrote: On Wed, Aug 5, 2015 at 2:01 AM, Ed Bartosh ed.bart...@linux.intel.com wrote: create-pull-request -d path creates empty patches if directory is specified as a path, i.e. ./bitbake or ./bitbake/ or full path. It behaves expected way only if script is run with -d bitbake, i.e. relative dir name doesn't contain '\'. Fixed this unwanted behaviour by changing directory and running git format-patch in it with --relative, without specifying relative path as a parameter. Signed-off-by: Ed Bartosh ed.bart...@linux.intel.com --- scripts/create-pull-request | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/scripts/create-pull-request b/scripts/create-pull-request index 216edfd..7eac618 100755 --- a/scripts/create-pull-request +++ b/scripts/create-pull-request @@ -177,12 +177,15 @@ mkdir $ODIR if [ -n $RELDIR ]; then ODIR=$(realpath $ODIR) - extraopts=--relative=$RELDIR + pushd $RELDIR can we avoid using pushd so it works with non bash shells too ? Should be possible, but it's worth mentioning that this script already starts with #!/bin/bash. That was the reason I used pushd/popd. -- Regards, Ed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-oe][PATCH] dosfstools-2.11: Fix memory leak in mkdosfs
On Thursday 06 August 2015 12:12:35 Alexander Kanavin wrote: On 08/06/2015 12:06 PM, Amarnath Valluri wrote: Added new patch that fixes the memory leak that was introduced in mkdosfs-dir.patch. You should update the original patch then, not pile additional patches on top. The least painful way is: 1) unpack the sources (manually from tarball, or using bitbake -c unpack) 2) 'git init; git add *; git commit' to create an git repository from the sources 3) apply the patch that needs fixing, then do the fix 4) make a git commit, then produce a patch using git format-patch, then move the new patch back to the recipe directory and update the recipe 5) build the recipe to make sure it still builds 6) make a git commit with the recipe update, and submit it here :) On the contrary - the much less painful way (as of fido) is to use devtool: 1) Extract source and set the build system up to use it: devtool modify dosfstools -x ~/projects/dosfstools 2) Make whatever changes you want to in the git tree that has been set up in the specified path 3) Build the recipe (as you would normally) to make sure it still builds 4) Write the modified/added commits as patches back to the recipe: devtool update-recipe dosfstools 5) Make a git commit with the recipe update, and submit it here :) I'd really like people to start using devtool for this kind of thing. If it's not working for some reason please do let me know. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] qemu: upgrade to 2.4.0-rc4
Bugfixes, bring it closer to 2.4.0 final release.
Signed-off-by: Cristian Iorga cristian.io...@intel.com
---
meta/recipes-devtools/qemu/{qemu_2.4.0-rc3.bb = qemu_2.4.0-rc4.bb} | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
rename meta/recipes-devtools/qemu/{qemu_2.4.0-rc3.bb = qemu_2.4.0-rc4.bb}
(82%)
diff --git a/meta/recipes-devtools/qemu/qemu_2.4.0-rc3.bb
b/meta/recipes-devtools/qemu/qemu_2.4.0-rc4.bb
similarity index 82%
rename from meta/recipes-devtools/qemu/qemu_2.4.0-rc3.bb
rename to meta/recipes-devtools/qemu/qemu_2.4.0-rc4.bb
index 9b17bcc..1964a50 100644
--- a/meta/recipes-devtools/qemu/qemu_2.4.0-rc3.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.4.0-rc4.bb
@@ -8,11 +8,11 @@ SRC_URI +=
file://configure-fix-Darwin-target-detection.patch \
file://Qemu-Arm-versatilepb-Add-memory-size-checking.patch \
SRC_URI_prepend =
http://wiki.qemu-project.org/download/${BPN}-${REALPV}.tar.bz2;
-SRC_URI[md5sum] = ba43213c94ef4463afc8bd01ee221860
-SRC_URI[sha256sum] =
aacd5834ce275300f1ba3617c32d4d149db93705ecb7955d7436c0fc9b96aa4c
+SRC_URI[md5sum] = 0e9c00b15d383043ce888f7bf17308c9
+SRC_URI[sha256sum] =
724bc17d29babe2b55107c76af7cd67e162857958a3bfe2f34bb9776f1f5f4b3
S=${WORKDIR}/${BPN}-${REALPV}
-REALPV = 2.4.0-rc3
+REALPV = 2.4.0-rc4
PV = 2.3.99+${REALPV}
COMPATIBLE_HOST_class-target_mips64 = null
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
