* Re: [PATCH] connman: fix bad file descriptor initialisation
From: Lukasz Nowak @ 2016-11-01 12:53 UTC (permalink / raw)
To: Burton, Ross; +Cc: OE-core
In-Reply-To: <CAJTo0LbR6gQYppuR6EPo30xnADd7-mfG6wg3Nf_r7a2-xgHgrw@mail.gmail.com>
Hi Ross,
It is a re-send. Apologies, but I have not received either of my two e-mails back from the mailing list, so I assumed the first one got stuck somewhere. I can see both of them in the web archive, though. Is that normal?
I've just checked and I have the "Receive your own posts to the list?" option set to Yes.
Lukasz
On 01.11.2016 12:46, Burton, Ross wrote:
> On 1 November 2016 at 08:50, Lukasz Nowak <lnowak.tyco@gmail.com <mailto:lnowak.tyco@gmail.com>> wrote:
>
> From: Lukasz Nowak <lnowak@tycoint.com <mailto:lnowak@tycoint.com>>
>
> Import a patch from upstream, which fixes a connman daemon freeze
> under certain conditions (multiple active interfaces, no r/w storage).
>
> Signed-off-by: Lukasz Nowak <lnowak@tycoint.com <mailto:lnowak@tycoint.com>>
> ---
>
>
> Is this a resent of your earlier patch, or a v2?
>
> Ross
^ permalink raw reply
* Re: [PATCH] boost: fix the SRC_URI to point to an actual release, and not a master snapshot
From: Alexander Kanavin @ 2016-11-01 12:44 UTC (permalink / raw)
To: Andreas Oberritter; +Cc: openembedded-core
In-Reply-To: <2de2e824-4b57-1adf-5053-6f9fcd518b8d@opendreambox.org>
On 10/31/2016 10:44 PM, Andreas Oberritter wrote:
>> -SRC_URI = "${SOURCEFORGE_MIRROR}/boost/${BOOST_P}.tar.bz2"
>> +SRC_URI = "${SOURCEFORGE_MIRROR}/project/boost/boost/${PV}/${BOOST_P}.tar.bz2"
>>
>> -SRC_URI[md5sum] = "7ef085456c48c49a7fe8237f07e5f674"
>> -SRC_URI[sha256sum] = "bce80293052e2d6230f1bec9b7524b33412e4fb26e9723460a0f362ac15b7acb"
>> +SRC_URI[md5sum] = "5fb94629535c19e48703bdb2b2e9490f"
>> +SRC_URI[sha256sum] = "36c96b0f6155c98404091d8ceb48319a28279ca0333fba1ad8611eb90afb2ca0"
>> +
>> +PR = "r1"
>
> doesn't the changed SRC_URI (or even the modified checksums alone)
> render the PR bump unnecessary?
Frankly I'm not sure, but I thought bumping PR ensures that anyone using
package feeds will get an updated package.
Alex
^ permalink raw reply
* [PATCH 1/1] insane.bbclass:buildpaths: open() file with 'rb'
From: Robert Yang @ 2016-11-01 12:44 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1478004257.git.liezhi.yang@windriver.com>
open() is default to 'rt' which may cause decoding errors when open
binary file:
$ bitbake xcursor-transparent-theme
[snip]
Exception: UnicodeDecodeError: 'utf-8' codec can't decode byte 0xfd in position 18: invalid start byte
[snip]
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
meta/classes/insane.bbclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 1d73778..a5c93f3 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -647,8 +647,8 @@ def package_qa_check_buildpaths(path, name, d, elf, messages):
return
tmpdir = d.getVar('TMPDIR', True)
- with open(path) as f:
- file_content = f.read()
+ with open(path, 'rb') as f:
+ file_content = f.read().decode('utf-8', errors='ignore')
if tmpdir in file_content:
package_qa_add_message(messages, "buildpaths", "File %s in package contained reference to tmpdir" % package_qa_clean_path(path,d))
--
2.9.0
^ permalink raw reply related
* [PATCH 0/1] insane.bbclass:buildpaths: open() file with 'rb'
From: Robert Yang @ 2016-11-01 12:44 UTC (permalink / raw)
To: openembedded-core
The following changes since commit 98c6ebf1e05158c689e01b785d32757847cdb10c:
oeqa/selftest/kernel.py: Add new file destined for kernel related tests (2016-11-01 10:05:40 +0000)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib rbt/bp
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/bp
Robert Yang (1):
insane.bbclass:buildpaths: open() file with 'rb'
meta/classes/insane.bbclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
2.9.0
^ permalink raw reply
* Re: [PATCH] boost: Fix SRC_URI checksums
From: Alexander Kanavin @ 2016-11-01 12:40 UTC (permalink / raw)
To: Khem Raj; +Cc: openembedded-core
In-Reply-To: <C35FC1E0-3663-4060-9E1C-A286B7A92512@gmail.com>
On 10/31/2016 06:22 PM, Khem Raj wrote:
>> Sourceforge is doing too-clever redirecting that fails miserably here:
>>
>> Proxy request sent, awaiting response... 301 Moved Permanently
>> Location: http://downloads.sourceforge.net/project/boost/boost/snapshots/master/boost_1_62_0.tar.bz2 [following]
>>
>> So we've been fetching a moving master snapshot all along. Patch is coming shortly.
>
> we should specify boost/boost/1.62.0/boost_1_62_0.tar.bz2 instead of boost/boost/boost_1_62_0.tar.bz2
Incorrect. That will still download a master snapshot tarball. Only if
the 'project/' is prefixed, SF will give you the release tarball.
Alex
^ permalink raw reply
* Re: [PATCH 1/1] oe/copy_buildsystem.py: dereference symlink
From: Burton, Ross @ 2016-11-01 12:15 UTC (permalink / raw)
To: Robert Yang; +Cc: OE-core
In-Reply-To: <fcb641d9-c4ae-bb72-cb96-98ec92e34797@windriver.com>
[-- Attachment #1: Type: text/plain, Size: 512 bytes --]
On 1 November 2016 at 10:18, Robert Yang <liezhi.yang@windriver.com> wrote:
> I should explain why not use oe.path.copytree(), but it was late last
> night, so I forgot that. We can't use oe.path.copytree() since:
> 1) oe.path.copytree() doesn't dereference symlink
> 2) We need --exclude='.git'
>
> I'd like to add two arguments to oe.path.copytree() to do this if it is
> worth.
>
Adding options to dereference and exclude a specified list of files sounds
like a good improvement to me.
Ross
[-- Attachment #2: Type: text/html, Size: 947 bytes --]
^ permalink raw reply
* Re: [PATCH] connman: fix bad file descriptor initialisation
From: Burton, Ross @ 2016-11-01 11:46 UTC (permalink / raw)
To: Lukasz Nowak; +Cc: OE-core
In-Reply-To: <c64cf308-d847-eac0-a2f7-bc8e686c2262@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 390 bytes --]
On 1 November 2016 at 08:50, Lukasz Nowak <lnowak.tyco@gmail.com> wrote:
> From: Lukasz Nowak <lnowak@tycoint.com>
>
> Import a patch from upstream, which fixes a connman daemon freeze
> under certain conditions (multiple active interfaces, no r/w storage).
>
> Signed-off-by: Lukasz Nowak <lnowak@tycoint.com>
> ---
>
Is this a resent of your earlier patch, or a v2?
Ross
[-- Attachment #2: Type: text/html, Size: 896 bytes --]
^ permalink raw reply
* Sanity check fails with 'ccache'
From: Enrico Scholz @ 2016-11-01 11:35 UTC (permalink / raw)
To: openembedded-core
Hi,
with 'morty', sanity check fails with
| Please install the following missing utilities: C Compiler (ccache gcc ),C++ Compiler (ccache g++ )
I think, parts of 89f55bf8e9d633cfb508a0885a462afb561c7cee should be
reverted.
Enrico
^ permalink raw reply
* Re: some pedantic questions about layer.conf "best practices"
From: Robert P. J. Day @ 2016-11-01 11:04 UTC (permalink / raw)
To: Gary Thomas; +Cc: openembedded-core
In-Reply-To: <df783f19-0a54-efd5-fa17-a25da1c4bcef@mlbassoc.com>
On Tue, 1 Nov 2016, Gary Thomas wrote:
> On 2016-11-01 11:04, Robert P. J. Day wrote:
> >
> > updating a tutorial about writing a proper layer.conf file, so some
> > nitpicky questions about recommended style.
> >
> > first, when appending to BBFILES, is it recommended to explicitly
> > use separate wildcard patterns of "*.bb" and "*.bbappend", or just get
> > lazy and use "*.bb*"? i realize that, in the end, it makes no
> > effective difference; i just happen to prefer the more explicit
> > pattern; just wondering if anyone has any preferences on this either
> > way. (i did say "nitpicky.")
>
> "*.bb*" also matches "*.bb~" and "*.bbappend~" (I use emacs which makes
> these backup files) that could be WAY confusing...
ah, of course, good point.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* Re: curious about inherent value of dynamic layers
From: Gary Thomas @ 2016-11-01 10:31 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <alpine.LFD.2.20.1611010604480.25706@ca624034.mitel.com>
On 2016-11-01 11:18, Robert P. J. Day wrote:
>
> more pedantry: i notice that a small number of layers (eg,
> meta-freescale, meta-mentor) include "dynamic" layers, so that some
> sublayers are included only conditionally if others layers are
> included. from meta-freescale's layer.conf:
>
> ///// start
>
> # The dynamic-layers directory hosts the extensions and layer specific
> # modifications related to Freescale products.
> #
> # The .bbappend and .bb files are included if the respective layer
> # collection is available.
> BBFILES += "${@' '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bbappend' % layer \
> for layer in BBFILE_COLLECTIONS.split())}"
> BBFILES += "${@' '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bb' % layer \
> for layer in BBFILE_COLLECTIONS.split())}"
>
> ///// end
>
> where the "dynamic-layers" directory in that layer contains further
> recipe directories with .bbappend files related to other layers:
>
> drwxrwxr-x. 3 rpjday rpjday 4096 Jun 26 06:36 browser-layer
> drwxrwxr-x. 3 rpjday rpjday 4096 Jun 26 06:36 efl-layer
> drwxrwxr-x. 3 rpjday rpjday 4096 Jun 26 06:36 filesystem-layer
> drwxrwxr-x. 4 rpjday rpjday 4096 Jun 26 06:36 networking-layer
> drwxrwxr-x. 6 rpjday rpjday 4096 Jun 26 06:36 openembedded-layer
> drwxrwxr-x. 3 rpjday rpjday 4096 Jun 26 06:36 qt4-layer
> drwxrwxr-x. 3 rpjday rpjday 4096 Jun 26 06:36 qt5-layer
> drwxrwxr-x. 3 rpjday rpjday 4096 Jun 26 06:36 virtualization-layer
>
> seems like an interesting idea ... opinions on whether this is a
> useful approach? or possibly overly confusing? is this approach
> mentioned in any OE/YP doc?
It's very useful if they have .bbappend files in these directories
as that will cause problems building if you don't include the corresponding
layers.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: some pedantic questions about layer.conf "best practices"
From: Gary Thomas @ 2016-11-01 10:20 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <alpine.LFD.2.20.1611010545380.25706@ca624034.mitel.com>
On 2016-11-01 11:04, Robert P. J. Day wrote:
>
> updating a tutorial about writing a proper layer.conf file, so some
> nitpicky questions about recommended style.
>
> first, when appending to BBFILES, is it recommended to explicitly
> use separate wildcard patterns of "*.bb" and "*.bbappend", or just get
> lazy and use "*.bb*"? i realize that, in the end, it makes no
> effective difference; i just happen to prefer the more explicit
> pattern; just wondering if anyone has any preferences on this either
> way. (i did say "nitpicky.")
"*.bb*" also matches "*.bb~" and "*.bbappend~" (I use emacs which makes
these backup files) that could be WAY confusing...
>
> next, what is best practice for naming a layer, since standards seem
> to differ. if i create a layer named "meta-rday", i've seen standards
> where the layer is "named" with one of:
>
> BBFILE_COLLECTIONS += "rday"
> BBFILE_COLLECTIONS += "meta-rday"
> BBFILE_COLLECTIONS += "rday-layer"
>
> amusingly, some freescale layers bounce around:
>
> BBFILE_COLLECTIONS += "freescale-layer"
> BBFILE_COLLECTIONS += "fsl-arm"
> BBFILE_COLLECTIONS += "fsl-ppc"
>
> even the meta-openembedded (sub)layers don't have a consistent style;
> some examples, which show all three styles:
>
> meta-filesystems/conf/layer.conf:BBFILE_COLLECTIONS += "filesystems-layer"
> meta-initramfs/conf/layer.conf:BBFILE_COLLECTIONS += "meta-initramfs"
> meta-webserver/conf/layer.conf:BBFILE_COLLECTIONS += "webserver"
>
> is there an encouraged style?
>
> finally, is it necessary to have LAYERDEPENDS include "core"? isn't
> that automatic? how could you possibly have a viable build system
> without the oe-core layer (unless this gives you the freedom to
> replace it with a custom one, which i don't see the value of).
>
> i think that's it for now ... thoughts?
>
> rday
>
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* curious about inherent value of dynamic layers
From: Robert P. J. Day @ 2016-11-01 10:18 UTC (permalink / raw)
To: OE Core mailing list
more pedantry: i notice that a small number of layers (eg,
meta-freescale, meta-mentor) include "dynamic" layers, so that some
sublayers are included only conditionally if others layers are
included. from meta-freescale's layer.conf:
///// start
# The dynamic-layers directory hosts the extensions and layer specific
# modifications related to Freescale products.
#
# The .bbappend and .bb files are included if the respective layer
# collection is available.
BBFILES += "${@' '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bbappend' % layer \
for layer in BBFILE_COLLECTIONS.split())}"
BBFILES += "${@' '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bb' % layer \
for layer in BBFILE_COLLECTIONS.split())}"
///// end
where the "dynamic-layers" directory in that layer contains further
recipe directories with .bbappend files related to other layers:
drwxrwxr-x. 3 rpjday rpjday 4096 Jun 26 06:36 browser-layer
drwxrwxr-x. 3 rpjday rpjday 4096 Jun 26 06:36 efl-layer
drwxrwxr-x. 3 rpjday rpjday 4096 Jun 26 06:36 filesystem-layer
drwxrwxr-x. 4 rpjday rpjday 4096 Jun 26 06:36 networking-layer
drwxrwxr-x. 6 rpjday rpjday 4096 Jun 26 06:36 openembedded-layer
drwxrwxr-x. 3 rpjday rpjday 4096 Jun 26 06:36 qt4-layer
drwxrwxr-x. 3 rpjday rpjday 4096 Jun 26 06:36 qt5-layer
drwxrwxr-x. 3 rpjday rpjday 4096 Jun 26 06:36 virtualization-layer
seems like an interesting idea ... opinions on whether this is a
useful approach? or possibly overly confusing? is this approach
mentioned in any OE/YP doc?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* Re: [PATCH 1/1] oe/copy_buildsystem.py: dereference symlink
From: Robert Yang @ 2016-11-01 10:18 UTC (permalink / raw)
To: Richard Purdie, openembedded-core
In-Reply-To: <1477994978.23123.46.camel@linuxfoundation.org>
On 11/01/2016 06:09 PM, Richard Purdie wrote:
> On Mon, 2016-10-31 at 08:48 -0700, Robert Yang wrote:
>> When there is a relative symlink in the layer, for example:
>> symA -> ../out/of/layer/file
>>
>> symA will be invalid fater copied, it would be invalid from build
>> time
>> if it points to a relative path, and would be invalid after extracted
>> the sdk if it points to a absolute py. Dereference symlink when copy
>> will fix the problem.
>>
>> Use tar rather than shutil.copytree() to copy is because:
>> 1) shutil.copytree(symlinks=Fasle) has bugs when dereference
>> symlinks:
>> https://bugs.python.org/issue21697
>> And Ubunutu 1404 doesn't upgrade python3 to fix the problem.
>>
>> 2) shutil.copytree(symlinks=False) raises errors when there is a
>> invalid
>> symlink, and tar just prints a warning, tar is preferred here
>> since
>> the real world is unpredicatable
>>
>> 3) tar is faster than shutil.copytree() as said by oe.path.copytree()
>
> Could we just use oe.path.copytree() here?
I should explain why not use oe.path.copytree(), but it was late last
night, so I forgot that. We can't use oe.path.copytree() since:
1) oe.path.copytree() doesn't dereference symlink
2) We need --exclude='.git'
I'd like to add two arguments to oe.path.copytree() to do this if it is worth.
// Robert
>
> Cheers,
>
> Richard
>
^ permalink raw reply
* Re: [PATCH 1/1] oe/copy_buildsystem.py: dereference symlink
From: Richard Purdie @ 2016-11-01 10:09 UTC (permalink / raw)
To: Robert Yang, openembedded-core
In-Reply-To: <bc402b553331b622af35b7fea7d30d82c7f2f686.1477928374.git.liezhi.yang@windriver.com>
On Mon, 2016-10-31 at 08:48 -0700, Robert Yang wrote:
> When there is a relative symlink in the layer, for example:
> symA -> ../out/of/layer/file
>
> symA will be invalid fater copied, it would be invalid from build
> time
> if it points to a relative path, and would be invalid after extracted
> the sdk if it points to a absolute py. Dereference symlink when copy
> will fix the problem.
>
> Use tar rather than shutil.copytree() to copy is because:
> 1) shutil.copytree(symlinks=Fasle) has bugs when dereference
> symlinks:
> https://bugs.python.org/issue21697
> And Ubunutu 1404 doesn't upgrade python3 to fix the problem.
>
> 2) shutil.copytree(symlinks=False) raises errors when there is a
> invalid
> symlink, and tar just prints a warning, tar is preferred here
> since
> the real world is unpredicatable
>
> 3) tar is faster than shutil.copytree() as said by oe.path.copytree()
Could we just use oe.path.copytree() here?
Cheers,
Richard
^ permalink raw reply
* some pedantic questions about layer.conf "best practices"
From: Robert P. J. Day @ 2016-11-01 10:04 UTC (permalink / raw)
To: OE Core mailing list
updating a tutorial about writing a proper layer.conf file, so some
nitpicky questions about recommended style.
first, when appending to BBFILES, is it recommended to explicitly
use separate wildcard patterns of "*.bb" and "*.bbappend", or just get
lazy and use "*.bb*"? i realize that, in the end, it makes no
effective difference; i just happen to prefer the more explicit
pattern; just wondering if anyone has any preferences on this either
way. (i did say "nitpicky.")
next, what is best practice for naming a layer, since standards seem
to differ. if i create a layer named "meta-rday", i've seen standards
where the layer is "named" with one of:
BBFILE_COLLECTIONS += "rday"
BBFILE_COLLECTIONS += "meta-rday"
BBFILE_COLLECTIONS += "rday-layer"
amusingly, some freescale layers bounce around:
BBFILE_COLLECTIONS += "freescale-layer"
BBFILE_COLLECTIONS += "fsl-arm"
BBFILE_COLLECTIONS += "fsl-ppc"
even the meta-openembedded (sub)layers don't have a consistent style;
some examples, which show all three styles:
meta-filesystems/conf/layer.conf:BBFILE_COLLECTIONS += "filesystems-layer"
meta-initramfs/conf/layer.conf:BBFILE_COLLECTIONS += "meta-initramfs"
meta-webserver/conf/layer.conf:BBFILE_COLLECTIONS += "webserver"
is there an encouraged style?
finally, is it necessary to have LAYERDEPENDS include "core"? isn't
that automatic? how could you possibly have a viable build system
without the oe-core layer (unless this gives you the freedom to
replace it with a custom one, which i don't see the value of).
i think that's it for now ... thoughts?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* [PATCH] connman: fix bad file descriptor initialisation
From: Lukasz Nowak @ 2016-11-01 8:50 UTC (permalink / raw)
To: openembedded-core
From: Lukasz Nowak <lnowak@tycoint.com>
Import a patch from upstream, which fixes a connman daemon freeze
under certain conditions (multiple active interfaces, no r/w storage).
Signed-off-by: Lukasz Nowak <lnowak@tycoint.com>
---
...ts-Fix-bad-file-descriptor-initialisation.patch | 102 +++++++++++++++++++++
meta/recipes-connectivity/connman/connman_1.33.bb | 1 +
2 files changed, 103 insertions(+)
create mode 100644 meta/recipes-connectivity/connman/connman/0003-stats-Fix-bad-file-descriptor-initialisation.patch
diff --git a/meta/recipes-connectivity/connman/connman/0003-stats-Fix-bad-file-descriptor-initialisation.patch b/meta/recipes-connectivity/connman/connman/0003-stats-Fix-bad-file-descriptor-initialisation.patch
new file mode 100644
index 0000000..c545811
--- /dev/null
+++ b/meta/recipes-connectivity/connman/connman/0003-stats-Fix-bad-file-descriptor-initialisation.patch
@@ -0,0 +1,102 @@
+From c7f4151fb053b0d0691d8f10d7e3690265d28889 Mon Sep 17 00:00:00 2001
+From: Lukasz Nowak <lnowak@tycoint.com>
+Date: Wed, 26 Oct 2016 18:13:02 +0100
+Subject: [PATCH] stats: Fix bad file descriptor initialisation
+
+Stats file code initialises its file descriptor field to 0. But 0 is
+a valid fd value. -1 should be used instead. This causes problems
+when an error happens before a stats file is open (e.g. mkdir
+fails). The clean-up procedure, stats_free() calls close(fd). When fd
+is 0, this first closes stdin, and then any files/sockets which
+received fd=0, re-used by the OS.
+
+Fixed several instances of bad file descriptor field handling, in case
+of errors.
+
+The bug results with connman freezing if there is no read/write storage
+directory available, and there are multiple active interfaces
+(fd=0 gets re-used for sockets in that case).
+
+The patch was imported from the Connman git repository
+(git://git.kernel.org/pub/scm/network/connman) as of commit id
+c7f4151fb053b0d0691d8f10d7e3690265d28889.
+
+Upstream-Status: Accepted
+Signed-off-by: Lukasz Nowak <lnowak@tycoint.com>
+---
+ src/stats.c | 15 +++++++++++++++
+ src/util.c | 4 ++--
+ 2 files changed, 17 insertions(+), 2 deletions(-)
+
+diff --git a/src/stats.c b/src/stats.c
+index 26343b1..c3ca738 100644
+--- a/src/stats.c
++++ b/src/stats.c
+@@ -378,6 +378,7 @@ static int stats_file_setup(struct stats_file *file)
+ strerror(errno), file->name);
+
+ TFR(close(file->fd));
++ file->fd = -1;
+ g_free(file->name);
+ file->name = NULL;
+
+@@ -393,6 +394,7 @@ static int stats_file_setup(struct stats_file *file)
+ err = stats_file_remap(file, size);
+ if (err < 0) {
+ TFR(close(file->fd));
++ file->fd = -1;
+ g_free(file->name);
+ file->name = NULL;
+
+@@ -649,6 +651,13 @@ static int stats_file_history_update(struct stats_file *data_file)
+ bzero(history_file, sizeof(struct stats_file));
+ bzero(temp_file, sizeof(struct stats_file));
+
++ /*
++ * 0 is a valid file descriptor - fd needs to be initialized
++ * to -1 to handle errors correctly
++ */
++ history_file->fd = -1;
++ temp_file->fd = -1;
++
+ err = stats_open(history_file, data_file->history_name);
+ if (err < 0)
+ return err;
+@@ -682,6 +691,12 @@ int __connman_stats_service_register(struct connman_service *service)
+ if (!file)
+ return -ENOMEM;
+
++ /*
++ * 0 is a valid file descriptor - fd needs to be initialized
++ * to -1 to handle errors correctly
++ */
++ file->fd = -1;
++
+ g_hash_table_insert(stats_hash, service, file);
+ } else {
+ return -EALREADY;
+diff --git a/src/util.c b/src/util.c
+index e6532c8..732d451 100644
+--- a/src/util.c
++++ b/src/util.c
+@@ -63,7 +63,7 @@ int __connman_util_init(void)
+ {
+ int r = 0;
+
+- if (f > 0)
++ if (f >= 0)
+ return 0;
+
+ f = open(URANDOM, O_RDONLY);
+@@ -86,7 +86,7 @@ int __connman_util_init(void)
+
+ void __connman_util_cleanup(void)
+ {
+- if (f > 0)
++ if (f >= 0)
+ close(f);
+
+ f = -1;
+--
+2.7.4
+
diff --git a/meta/recipes-connectivity/connman/connman_1.33.bb b/meta/recipes-connectivity/connman/connman_1.33.bb
index 6ea1a08..56a0a0f 100644
--- a/meta/recipes-connectivity/connman/connman_1.33.bb
+++ b/meta/recipes-connectivity/connman/connman_1.33.bb
@@ -5,6 +5,7 @@ SRC_URI = "${KERNELORG_MIRROR}/linux/network/${BPN}/${BP}.tar.xz \
file://connman \
file://no-version-scripts.patch \
file://includes.patch \
+ file://0003-stats-Fix-bad-file-descriptor-initialisation.patch \
"
SRC_URI_append_libc-musl = " file://0002-resolve-musl-does-not-implement-res_ninit.patch"
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] python3: fix library search path
From: kai.kang @ 2016-11-01 7:39 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1477985510.git.kai.kang@windriver.com>
From: Kai Kang <kai.kang@windriver.com>
When enable multilib, it fails to run python3:
| Could not find platform independent libraries <prefix>
| Could not find platform dependent libraries <exec_prefix>
| Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
| Fatal Python error: Py_Initialize: Unable to get the locale encoding
| ImportError: No module named 'encodings'
|
| Current thread 0x00007f62ea5b2700 (most recent call first):
| Aborted (core dumped)
The root cause is the module search path /usr/lib is wrong for x86-64
when multilib is enabled. So replace fixed path string with right macro.
Clean up python-3.3-multilib.patch for Modules/getpath.c at same time.
Signed-off-by: Kai Kang <kai.kang@windriver.com>
---
...t-python3-lib-pathes-for-multilib-support.patch | 49 ++++++++++++++++++++++
.../python/python3/python-3.3-multilib.patch | 13 +++---
meta/recipes-devtools/python/python3_3.5.2.bb | 1 +
3 files changed, 55 insertions(+), 8 deletions(-)
create mode 100644 meta/recipes-devtools/python/python3/correct-python3-lib-pathes-for-multilib-support.patch
diff --git a/meta/recipes-devtools/python/python3/correct-python3-lib-pathes-for-multilib-support.patch b/meta/recipes-devtools/python/python3/correct-python3-lib-pathes-for-multilib-support.patch
new file mode 100644
index 0000000..8ca5a6a
--- /dev/null
+++ b/meta/recipes-devtools/python/python3/correct-python3-lib-pathes-for-multilib-support.patch
@@ -0,0 +1,49 @@
+When enable multilib, it fails to run python3:
+
+| Could not find platform independent libraries <prefix>
+| Could not find platform dependent libraries <exec_prefix>
+| Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
+| Fatal Python error: Py_Initialize: Unable to get the locale encoding
+| ImportError: No module named 'encodings'
+|
+| Current thread 0x00007f62ea5b2700 (most recent call first):
+| Aborted (core dumped)
+
+The root cause is the module search path /usr/lib is wrong for x86-64 when
+multilib is enabled. So replace fixed path string with right macro.
+
+Upstream-Status: Pending
+
+Signed-off-by: Kai Kang <kai.kang@windriver.com>
+---
+diff --git a/Modules/getpath.c b/Modules/getpath.c
+index 18deb60..d22af53 100644
+--- a/Modules/getpath.c
++++ b/Modules/getpath.c
+@@ -494,7 +494,7 @@ calculate_path(void)
+ _pythonpath = Py_DecodeLocale(PYTHONPATH, NULL);
+ _prefix = Py_DecodeLocale(PREFIX, NULL);
+ _exec_prefix = Py_DecodeLocale(EXEC_PREFIX, NULL);
+- lib_python = Py_DecodeLocale("lib/python" VERSION, NULL);
++ lib_python = Py_DecodeLocale(LIB_PYTHON, NULL);
+
+ if (!_pythonpath || !_prefix || !_exec_prefix || !lib_python) {
+ Py_FatalError(
+@@ -683,7 +683,7 @@ calculate_path(void)
+ }
+ else
+ wcsncpy(zip_path, _prefix, MAXPATHLEN);
+- joinpath(zip_path, L"lib/python00.zip");
++ joinpath(zip_path, LIB L"/python00.zip");
+ bufsz = wcslen(zip_path); /* Replace "00" with version */
+ zip_path[bufsz - 6] = VERSION[0];
+ zip_path[bufsz - 5] = VERSION[2];
+@@ -695,7 +695,7 @@ calculate_path(void)
+ fprintf(stderr,
+ "Could not find platform dependent libraries <exec_prefix>\n");
+ wcsncpy(exec_prefix, _exec_prefix, MAXPATHLEN);
+- joinpath(exec_prefix, L"lib/lib-dynload");
++ joinpath(exec_prefix, LIB L"/lib-dynload");
+ }
+ /* If we found EXEC_PREFIX do *not* reduce it! (Yet.) */
+
diff --git a/meta/recipes-devtools/python/python3/python-3.3-multilib.patch b/meta/recipes-devtools/python/python3/python-3.3-multilib.patch
index 056e8e7..f7e73ee 100644
--- a/meta/recipes-devtools/python/python3/python-3.3-multilib.patch
+++ b/meta/recipes-devtools/python/python3/python-3.3-multilib.patch
@@ -7,6 +7,11 @@ get the sys.lib from python itself and do not use hardcoded value of 'lib'
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com>
+Remove the section to add a global var in Modules/getpath.c that the global var
+has been removed from python3 upstream.
+
+Signed-off-by: Kai Kang <kai.kang@windriver.com>
+
Index: Python-3.5.2/Include/pythonrun.h
===================================================================
--- Python-3.5.2.orig/Include/pythonrun.h
@@ -130,14 +135,6 @@ Index: Python-3.5.2/Modules/getpath.c
#ifndef LANDMARK
#define LANDMARK L"os.py"
#endif
-@@ -113,6 +120,7 @@ static wchar_t prefix[MAXPATHLEN+1];
- static wchar_t exec_prefix[MAXPATHLEN+1];
- static wchar_t progpath[MAXPATHLEN+1];
- static wchar_t *module_search_path = NULL;
-+static wchar_t *lib_python = L"" LIB_PYTHON;
-
- /* Get file status. Encode the path to the locale encoding. */
-
Index: Python-3.5.2/Python/getplatform.c
===================================================================
--- Python-3.5.2.orig/Python/getplatform.c
diff --git a/meta/recipes-devtools/python/python3_3.5.2.bb b/meta/recipes-devtools/python/python3_3.5.2.bb
index e6cbb9c..7e6f019 100644
--- a/meta/recipes-devtools/python/python3_3.5.2.bb
+++ b/meta/recipes-devtools/python/python3_3.5.2.bb
@@ -37,6 +37,7 @@ SRC_URI += "\
file://setup.py-find-libraries-in-staging-dirs.patch \
file://configure.ac-fix-LIBPL.patch \
file://python3-fix-CVE-2016-1000110.patch \
+ file://correct-python3-lib-pathes-for-multilib-support.patch \
"
SRC_URI[md5sum] = "8906efbacfcdc7c3c9198aeefafd159e"
SRC_URI[sha256sum] = "0010f56100b9b74259ebcd5d4b295a32324b58b517403a10d1a2aa7cb22bca40"
--
2.10.1
^ permalink raw reply related
* [PATCH 2/3] dbus: update build options when enable ptest
From: kai.kang @ 2016-11-01 7:39 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1477985510.git.kai.kang@windriver.com>
From: Kai Kang <kai.kang@windriver.com>
It fails to run some dbus-ptest cases that some symbols cannot be found:
| ./test/test-bus: relocation error: ./test/test-bus: symbol
| _dbus_threads_init_debug, version LIBDBUS_PRIVATE_1.10.10 not defined
| in file libdbus-1.so.3 with link time reference
| FAIL: test/test-bus
These missing symbols are controlled by some macros. Update configure
options and compile macro to make the symbols visible to ptest cases.
Signed-off-by: Kai Kang <kai.kang@windriver.com>
---
meta/recipes-core/dbus/dbus_1.10.10.bb | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-core/dbus/dbus_1.10.10.bb b/meta/recipes-core/dbus/dbus_1.10.10.bb
index 4db0b9b..214cc13 100644
--- a/meta/recipes-core/dbus/dbus_1.10.10.bb
+++ b/meta/recipes-core/dbus/dbus_1.10.10.bb
@@ -90,7 +90,7 @@ pkg_postinst_dbus() {
fi
}
-EXTRA_OECONF = "--disable-tests \
+EXTRA_OECONF = "${@bb.utils.contains('DISTRO_FEATURES', 'ptest', '--enable-embedded-tests --enable-asserts --enable-verbose-mode', '--disable-tests', d)} \
--disable-xml-docs \
--disable-doxygen-docs \
--disable-libaudit \
@@ -98,6 +98,8 @@ EXTRA_OECONF = "--disable-tests \
EXTRA_OECONF_append_class-native = " --disable-selinux"
+EXTRA_OEMAKE = "${@bb.utils.contains('DISTRO_FEATURES', 'ptest', 'CFLAG_VISIBILITY=-fvisibility=default', '', d)}"
+
PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd', '', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'largefile', 'largefile', '', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '', d)}"
--
2.10.1
^ permalink raw reply related
* [PATCH 1/3] dbus-test: correct paths in service and conf files
From: kai.kang @ 2016-11-01 7:39 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1477985510.git.kai.kang@windriver.com>
From: Kai Kang <kai.kang@windriver.com>
Build path ${B} exists in some service and conf files of ptest. Replace
with right directory.
Signed-off-by: Kai Kang <kai.kang@windriver.com>
---
meta/recipes-core/dbus/dbus-test_1.10.10.bb | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-core/dbus/dbus-test_1.10.10.bb b/meta/recipes-core/dbus/dbus-test_1.10.10.bb
index 650b7ab..29d7f91 100644
--- a/meta/recipes-core/dbus/dbus-test_1.10.10.bb
+++ b/meta/recipes-core/dbus/dbus-test_1.10.10.bb
@@ -54,5 +54,8 @@ do_install_ptest() {
for i in $l; do install ${B}/bus/.libs/test-$i ${D}${PTEST_PATH}/test; done
install ${B}/dbus/.libs/test-dbus ${D}${PTEST_PATH}/test
cp -r ${B}/test/data ${D}${PTEST_PATH}/test
+
+ # set right path in service and conf files
+ find ${D} -type f -not -executable -exec sed -i 's#${B}#${PTEST_PATH}#' {} \;
}
RDEPENDS_${PN}-ptest += "bash"
--
2.10.1
^ permalink raw reply related
* [PATCH 0/3] Fixes for python3 and dbus-ptest
From: kai.kang @ 2016-11-01 7:39 UTC (permalink / raw)
To: openembedded-core
From: Kai Kang <kai.kang@windriver.com>
1
when multilib is enabled, python3 fails to start:
root@qemux86-64:~# python3
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Fatal Python error: Py_Initialize: Unable to get the locale encoding
ImportError: No module named 'encodings'
Current thread 0x00007f4d9b268700 (most recent call first):
Aborted
It is library path issue, and fix it. Then check sys.path are right:
root@qemux86-64:~# python3
Python 3.5.2 (default, Nov 1 2016, 15:32:42)
[GCC 6.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', '/usr/lib64/python35.zip', '/usr/lib64/python3.5', '/usr/lib64/python3.5/plat-linux', '/usr/lib64/python3.5/lib-dynload']
>>>
2
Only 4 cases PASS of dbus-ptest. With the fixes, all ptests cases PASS on qemux86-64.
And for qemuarm, only one case fails:
./run-ptest: line 10: 283 Aborted ./$i ./test/data DBUS_TEST_HOMEDIR=./test > /dev/null
FAIL: test/test-refs
It is a multi-threads issue, and need more work to fix it.
---
The following changes since commit 003b053498aea91fdb8c5418d0d8bbda7b23dbc0:
boost: fix the SRC_URI to point to an actual release, and not a master snapshot (2016-10-31 14:23:12 +0000)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib kangkai/python3_and_dbus
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kangkai/python3_and_dbus
Kai Kang (3):
dbus-test: correct paths in service and conf files
dbus: update build options when enable ptest
python3: fix library search path
meta/recipes-core/dbus/dbus-test_1.10.10.bb | 3 ++
meta/recipes-core/dbus/dbus_1.10.10.bb | 4 +-
...t-python3-lib-pathes-for-multilib-support.patch | 49 ++++++++++++++++++++++
.../python/python3/python-3.3-multilib.patch | 13 +++---
meta/recipes-devtools/python/python3_3.5.2.bb | 1 +
5 files changed, 61 insertions(+), 9 deletions(-)
create mode 100644 meta/recipes-devtools/python/python3/correct-python3-lib-pathes-for-multilib-support.patch
--
2.10.1
^ permalink raw reply
* Re: [oe-core PATCH] wayland: upgrade from 1.11.0 to 1.11.1
From: Fathi Boudra @ 2016-11-01 7:04 UTC (permalink / raw)
To: Burton, Ross; +Cc: OE-core
In-Reply-To: <CAJTo0LYBANe9f--NJkex3sN52ZGUH6Nrd45ktaYV1qxdY8gNJg@mail.gmail.com>
On 31 October 2016 at 13:32, Burton, Ross <ross.burton@intel.com> wrote:
>
> On 31 October 2016 at 08:25, Johannes Pointner <h4nn35.work@gmail.com>
> wrote:
>>
>> Wouldn't it make more sense to update to 1.12?
>> Since 1.11.1 is backporting fixes from 1.12 as stated in the annouce
>> mail of the release.
>
>
> Absolutely - there's a 1.12 so unless there's a good reason to avoid it in
> master we should be moving to that.
The reason is pretty simple, I submitted this change only to go with
the weston patch backported from master to 1.11 serie since it is what
is available in oe-core. It's the combination I tested on my available
boards and nothing related with newer version.
> Ross
^ permalink raw reply
* [PATCH 2/2] classes/nativesdk: set SDK_OLDEST_KERNEL appropriately
From: Paul Eggleton @ 2016-11-01 3:24 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1477970643.git.paul.eggleton@linux.intel.com>
SDK_OLDEST_KERNEL currently only controls the check on SDK installation,
however as with OLDEST_KERNEL it should be controlling the OLDEST_KERNEL
value for building glibc used in the SDK. Thus, set it in
nativesdk.bbclass. This means we need to move the default to
bitbake.conf so that it can be seen in both places.
Also set a more reasonable default for SDK_OLDEST_KERNEL for x86/x86-64 as
glibc 2.24 still supports back to 2.6.32 there and there are still
people wanting to build SDKs that will install on older distros (e.g.
CentOS 6). However it's not possible to set this with overrides since
there aren't any for the SDK_ARCH, however we can instead set the variable
from conf files in conf/machine-sdk especially as there is now a soft
default for SDKMACHINE.
Fixes [YOCTO #10561].
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
meta/classes/nativesdk.bbclass | 2 ++
meta/classes/populate_sdk_base.bbclass | 5 -----
meta/conf/bitbake.conf | 5 +++++
meta/conf/machine-sdk/i586.conf | 1 +
meta/conf/machine-sdk/i686.conf | 1 +
meta/conf/machine-sdk/x86_64.conf | 1 +
6 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/meta/classes/nativesdk.bbclass b/meta/classes/nativesdk.bbclass
index a78257c..31dde4a 100644
--- a/meta/classes/nativesdk.bbclass
+++ b/meta/classes/nativesdk.bbclass
@@ -97,3 +97,5 @@ do_populate_sysroot[stamp-extra-info] = ""
do_packagedata[stamp-extra-info] = ""
USE_NLS = "${SDKUSE_NLS}"
+
+OLDEST_KERNEL = "${SDK_OLDEST_KERNEL}"
diff --git a/meta/classes/populate_sdk_base.bbclass b/meta/classes/populate_sdk_base.bbclass
index a762655..69aae26 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -89,11 +89,6 @@ POPULATE_SDK_POST_HOST_COMMAND_append = " write_host_sdk_manifest; "
SDK_PACKAGING_COMMAND = "${@'${SDK_PACKAGING_FUNC};' if '${SDK_PACKAGING_FUNC}' else ''}"
SDK_POSTPROCESS_COMMAND = " create_sdk_files; check_sdk_sysroots; tar_sdk; ${SDK_PACKAGING_COMMAND} "
-# Some archs override this, we need the nativesdk version
-# turns out this is hard to get from the datastore due to TRANSLATED_TARGET_ARCH
-# manipulation.
-SDK_OLDEST_KERNEL = "3.2.0"
-
def populate_sdk_common(d):
from oe.sdk import populate_sdk
from oe.manifest import create_manifest, Manifest
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 54a587f..9f445bb 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -408,6 +408,11 @@ OLDEST_KERNEL = "3.2.0"
OLDEST_KERNEL_aarch64 = "3.14"
OLDEST_KERNEL_nios2 = "3.19"
+# SDK_OLDEST_KERNEL can't be set using overrides since there are
+# none for the SDK architecture. Best to set it from a machine-sdk
+# include file if you need an SDK arch-specific value
+SDK_OLDEST_KERNEL = "3.2.0"
+
# Define where the kernel headers are installed on the target as well as where
# they are staged.
KERNEL_SRC_PATH = "/usr/src/kernel"
diff --git a/meta/conf/machine-sdk/i586.conf b/meta/conf/machine-sdk/i586.conf
index 41e5e15..99083fb 100644
--- a/meta/conf/machine-sdk/i586.conf
+++ b/meta/conf/machine-sdk/i586.conf
@@ -1,4 +1,5 @@
SDK_ARCH = "i586"
SDK_CC_ARCH = "-march=i586"
ABIEXTENSION_class-nativesdk = ""
+SDK_OLDEST_KERNEL = "2.6.32"
diff --git a/meta/conf/machine-sdk/i686.conf b/meta/conf/machine-sdk/i686.conf
index fe40697..cf22784 100644
--- a/meta/conf/machine-sdk/i686.conf
+++ b/meta/conf/machine-sdk/i686.conf
@@ -1,3 +1,4 @@
SDK_ARCH = "i686"
SDK_CC_ARCH = "-march=i686"
ABIEXTENSION_class-nativesdk = ""
+SDK_OLDEST_KERNEL = "2.6.32"
diff --git a/meta/conf/machine-sdk/x86_64.conf b/meta/conf/machine-sdk/x86_64.conf
index 61439b4..7d2e717 100644
--- a/meta/conf/machine-sdk/x86_64.conf
+++ b/meta/conf/machine-sdk/x86_64.conf
@@ -1,2 +1,3 @@
SDK_ARCH = "x86_64"
ABIEXTENSION_class-nativesdk = ""
+SDK_OLDEST_KERNEL = "2.6.32"
--
2.5.5
^ permalink raw reply related
* [PATCH 1/2] classes/populate_sdk_base: fix usage of & character in SDK_TITLE
From: Paul Eggleton @ 2016-11-01 3:24 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1477970643.git.paul.eggleton@linux.intel.com>
If you used an & character in SDK_TITLE (possibly indirectly from
DISTRO_NAME) then sed interpreted this as a directive to paste in the
replaced string (@SDK_TITLE@ in this case). Escape any & characters in
SDK_TITLE to avoid that.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
meta/classes/populate_sdk_base.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/populate_sdk_base.bbclass b/meta/classes/populate_sdk_base.bbclass
index 4462b52..a762655 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -223,7 +223,7 @@ EOF
-e 's#@SDKEXTPATH@#${SDKEXTPATH}#g' \
-e 's#@OLDEST_KERNEL@#${SDK_OLDEST_KERNEL}#g' \
-e 's#@REAL_MULTIMACH_TARGET_SYS@#${REAL_MULTIMACH_TARGET_SYS}#g' \
- -e 's#@SDK_TITLE@#${SDK_TITLE}#g' \
+ -e 's#@SDK_TITLE@#${@d.getVar("SDK_TITLE", True).replace('&', '\&')}#g' \
-e 's#@SDK_VERSION@#${SDK_VERSION}#g' \
-e '/@SDK_PRE_INSTALL_COMMAND@/d' \
-e '/@SDK_POST_INSTALL_COMMAND@/d' \
--
2.5.5
^ permalink raw reply related
* [PATCH 0/2] A couple of SDK fixes
From: Paul Eggleton @ 2016-11-01 3:24 UTC (permalink / raw)
To: openembedded-core
The following changes since commit b18fa5f2f2f46afc6fdc58f4d29679dea9c36c43:
Remove LIC_FILES_CHKSUM from recipes without SRC_URI (2016-10-28 11:27:33 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib paule/sdk-fixes
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/sdk-fixes
Paul Eggleton (2):
classes/populate_sdk_base: fix usage of & character in SDK_TITLE
classes/nativesdk: set SDK_OLDEST_KERNEL appropriately
meta/classes/nativesdk.bbclass | 2 ++
meta/classes/populate_sdk_base.bbclass | 7 +------
meta/conf/bitbake.conf | 5 +++++
meta/conf/machine-sdk/i586.conf | 1 +
meta/conf/machine-sdk/i686.conf | 1 +
meta/conf/machine-sdk/x86_64.conf | 1 +
6 files changed, 11 insertions(+), 6 deletions(-)
--
2.5.5
^ permalink raw reply
* [PATCH] pax : strip off the trailing slash of file name
From: jackie.huang @ 2016-11-01 3:01 UTC (permalink / raw)
To: openembedded-core
From: Zhang Xiao <xiao.zhang@windriver.com>
When extracting packaes, the trailing slash of the file name
has no means but may cause some issue on system call lstat.
Remove it.
Signed-off-by: Zhang Xiao <xiao.zhang@windriver.com>
Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
---
.../pax-strip-off-file-name-s-trailing-slash.patch | 48 ++++++++++++++++++++++
meta/recipes-extended/pax/pax_3.4.bb | 4 +-
2 files changed, 51 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-extended/pax/pax/pax-strip-off-file-name-s-trailing-slash.patch
diff --git a/meta/recipes-extended/pax/pax/pax-strip-off-file-name-s-trailing-slash.patch b/meta/recipes-extended/pax/pax/pax-strip-off-file-name-s-trailing-slash.patch
new file mode 100644
index 0000000..9e0a335
--- /dev/null
+++ b/meta/recipes-extended/pax/pax/pax-strip-off-file-name-s-trailing-slash.patch
@@ -0,0 +1,48 @@
+From aa8ba118869b75a2a9cd681b2f0362d9d8f1c7ec Mon Sep 17 00:00:00 2001
+From: Zhang Xiao <xiao.zhang@windriver.com>
+Date: Tue, 12 Jul 2016 11:34:45 +0800
+Subject: [PATCH] pax: strip off the trailing slash of file name
+
+When extracting packaes, the trailing slash of the file name
+has no means but may cause some issue on system call lstat.
+Remove it.
+
+Upstream-Status: Pending
+
+Signed-off-by: Zhang Xiao <xiao.zhang@windriver.com>
+---
+ src/pat_rep.c | 11 ++++++++++-
+ 1 file changed, 10 insertions(+), 1 deletion(-)
+
+diff --git a/src/pat_rep.c b/src/pat_rep.c
+index b9a4636..4cbf6bf 100644
+--- a/src/pat_rep.c
++++ b/src/pat_rep.c
+@@ -605,7 +605,7 @@ int
+ mod_name(ARCHD *arcn)
+ {
+ int res = 0;
+-
++ char *pt;
+ /*
+ * Strip off leading '/' if appropriate.
+ * Currently, this option is only set for the tar format.
+@@ -639,6 +639,15 @@ mod_name(ARCHD *arcn)
+ }
+
+ /*
++ * strip off trailing slash.
++ */
++ pt = &(arcn->name[strlen(arcn->name) - 1]);
++ if (*pt == '/') {
++ *pt = '\0';
++ arcn->nlen = strlen(arcn->name);
++ }
++
++ /*
+ * IMPORTANT: We have a problem. what do we do with symlinks?
+ * Modifying a hard link name makes sense, as we know the file it
+ * points at should have been seen already in the archive (and if it
+--
+1.8.5.2.233.g932f7e4
+
diff --git a/meta/recipes-extended/pax/pax_3.4.bb b/meta/recipes-extended/pax/pax_3.4.bb
index 9d1abfb..7ce43ce 100644
--- a/meta/recipes-extended/pax/pax_3.4.bb
+++ b/meta/recipes-extended/pax/pax_3.4.bb
@@ -16,7 +16,9 @@ DEPENDS_append_libc-musl = " fts "
SRC_URI = "http://pkgs.fedoraproject.org/repo/pkgs/${BPN}/${BP}.tar.bz2/fbd9023b590b45ac3ade95870702a0d6/${BP}.tar.bz2 \
file://fix_for_compile_with_gcc-4.6.0.patch \
- file://pax-3.4_fix_for_x32.patch"
+ file://pax-3.4_fix_for_x32.patch \
+ file://pax-strip-off-file-name-s-trailing-slash.patch \
+"
SRC_URI_append_libc-musl = " file://0001-Fix-build-with-musl.patch \
file://0001-use-strtoll-instead-of-strtoq.patch \
--
2.8.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox