Re: [OE-core] [PATCH] file: remove the original magic.h
On 27 March 2015 at 03:31, Junling Zheng zhengjunl...@huawei.com wrote: So I think the true reason is that if the magic.h exists already, sometimes Makefile will not generate it again. In that case it's likely entirely down to timestamps. How are you modifying magic.h.in? Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2 0/4] systemd and dbus split into packages
On 18 March 2015 at 21:40, Bottazzini, Bruno bruno.bottazz...@intel.com wrote: Sorry, I didn't get why we can't consider this patchset to be included into master now. Because when Khem said that, master was freezing so that we can make the 1.8 release. We've now branched off the release branch so master is open, but the current focus is on the release. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] combo-layer: fix file_exclude for dest_dir = .
filterdiff -x ./some/file does not remove changes for some/file.
We must be more careful about constructing the path name and
only add the prefix when it really means a directory.
While at it, also better normalize the path in copy_selected_files()
early on, to handle double slashes. Useful should the function ever
gets used for something other that dest_dir (which gets normalized in
sanity_check()).
Signed-off-by: Patrick Ohly patrick.o...@intel.com
---
scripts/combo-layer | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/scripts/combo-layer b/scripts/combo-layer
index 4aed072..a1fc6ac 100755
--- a/scripts/combo-layer
+++ b/scripts/combo-layer
@@ -249,13 +249,16 @@ def action_init(conf, args):
# files already moved, we need to prepend the
# subdirectory to all filters, otherwise they would
# not match.
-if subdir:
+if subdir == '.':
+subdir = ''
+elif subdir:
+subdir = os.path.normpath(subdir)
file_filter = ' '.join([subdir + '/' + x for x in
file_filter.split()])
exclude_patterns = [subdir + '/' + x for x in
exclude_patterns]
# To handle both cases, we cd into the target
# directory and optionally tell tar to strip the path
# prefix when the files were already moved.
-subdir_components =
len(os.path.normpath(subdir).split(os.path.sep)) if subdir else 0
+subdir_components = len(subdir.split(os.path.sep)) if subdir
else 0
strip=('--strip-components=%d' % subdir_components) if subdir
else ''
# TODO: file_filter wild cards do not work (and haven't worked
before either), because
# a) GNU tar requires a --wildcards parameter before turning
on wild card matching.
@@ -375,7 +378,7 @@ tail -c +18 $tmpname | head -c -4
if not os.path.exists(extract_dir):
os.makedirs(extract_dir)
copy_selected_files('HEAD', extract_dir, file_filter,
exclude_patterns, '.',
-subdir=dest_dir if dest_dir != '.'
else '')
+subdir=dest_dir)
runcmd('git add --all --force .')
if runcmd('git status --porcelain'):
# Something to commit.
@@ -648,7 +651,7 @@ def action_update(conf, args):
filter = ['filterdiff', '-p1']
for path in exclude.split():
filter.append('-x')
-filter.append('%s/%s' % (dest_dir, path) if dest_dir else path)
+filter.append('%s/%s' % (dest_dir, path) if dest_dir != '.'
else path)
for patch in patchlist[:]:
filtered = patch + '.tmp'
with open(filtered, 'w') as f:
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] combo-layer: clean up dest_dir checking
Empty dest_dir is basically undocumented behavior. The sample conf
only mentions using just a dot for the current directory. In practice,
the empty string does not work because of code like this:
def action_splitpatch(conf, args):
...
if dest_dir != .:
filerange_root = '%s -x %s/*' % (filerange_root, dest_dir)
However, the empty string was not explicitly checked for, leading to
strange errors when trying to apply patches:
[12:50:23] Applying: foobar: xyz
fatal: unable to stat newly created file '/foobar': No such file or directory
This patch turns the empty string into an alias for the dot. This seems
more user-friendly than throwing an error. This alias is intentionally
not document in the sample conf, because the dot is clearer and works also
with older copies of combo-layer.
Instead of checking for both all the time and normalizing the path when
needed (as done in some places), rewrite the value in sanity_check()
and then only check for '.'.
Signed-off-by: Patrick Ohly patrick.o...@intel.com
---
scripts/combo-layer | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/scripts/combo-layer b/scripts/combo-layer
index 83cfc8e..4aed072 100755
--- a/scripts/combo-layer
+++ b/scripts/combo-layer
@@ -144,6 +144,10 @@ class Configuration(object):
if option not in self.repos[name]:
msg = %s\nOption %s is not defined for component %s
%(msg, option, name)
missing_options.append(option)
+# Sanitize dest_dir so that we do not have to deal with edge cases
+# (empty string, double slashes) in the rest of the code.
+dest_dir = os.path.normpath(self.repos[name][dest_dir])
+self.repos[name][dest_dir] = . if not dest_dir else dest_dir
if msg != :
logger.error(configuration file %s has the following error: %s %
(self.conffile,msg))
if self.localconffile and 'last_revision' in missing_options:
@@ -231,7 +235,7 @@ def action_init(conf, args):
pass
initialrev = rev
dest_dir = repo['dest_dir']
-if dest_dir and dest_dir != .:
+if dest_dir != .:
extract_dir = os.path.join(os.getcwd(), dest_dir)
if not os.path.exists(extract_dir):
os.makedirs(extract_dir)
@@ -325,7 +329,7 @@ EOF
runcmd('git replace --edit %s' % rev)
# Optional: rewrite history to change commit messages or to
move files.
-if 'hook' in repo or dest_dir and dest_dir != .:
+if 'hook' in repo or dest_dir != .:
filter_branch = ['git', 'filter-branch', '--force']
with tempfile.NamedTemporaryFile() as hookwrapper:
if 'hook' in repo:
@@ -353,7 +357,7 @@ tail -c +18 $tmpname | head -c -4
''' % (hook, name))
hookwrapper.flush()
filter_branch.extend(['--msg-filter', 'bash %s' %
hookwrapper.name])
-if dest_dir and dest_dir != .:
+if dest_dir != .:
parent = os.path.dirname(dest_dir)
if not parent:
parent = '.'
@@ -371,7 +375,7 @@ tail -c +18 $tmpname | head -c -4
if not os.path.exists(extract_dir):
os.makedirs(extract_dir)
copy_selected_files('HEAD', extract_dir, file_filter,
exclude_patterns, '.',
-subdir=dest_dir if dest_dir and
dest_dir != '.' else '')
+subdir=dest_dir if dest_dir != '.'
else '')
runcmd('git add --all --force .')
if runcmd('git status --porcelain'):
# Something to commit.
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/3] combo-layer + file_exclude
Applying the new feature to additional repos highlighted some issue. Proposing for master, but would also be suitable for Fido. The following changes since commit 2d923d6dfe9431dbc005f8ba39838eb4519c471c: python-pygobject: Disable parallel make install in native case (2015-03-25 12:38:44 +) are available in the git repository at: git://github.com/pohly/openembedded-core combo-layer https://github.com/pohly/openembedded-core/tree/combo-layer Patrick Ohly (3): combo-layer: clean up dest_dir checking combo-layer: fix file_exclude for dest_dir = . combo-layer: fix file_exclude for empty commits scripts/combo-layer | 25 ++--- 1 file changed, 18 insertions(+), 7 deletions(-) -- 2.1.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] combo-layer: fix file_exclude for empty commits
The code detecting empty patches after removing files with
file_exclude failed for commits which were already empty before (like
the initial commit in some repos): such patches are completely empty
files, without a From line.
Detect that case and just let the normal empty patch detection deal
with it.
Signed-off-by: Patrick Ohly patrick.o...@intel.com
---
scripts/combo-layer | 4
1 file changed, 4 insertions(+)
diff --git a/scripts/combo-layer b/scripts/combo-layer
index a1fc6ac..1dce4a6 100755
--- a/scripts/combo-layer
+++ b/scripts/combo-layer
@@ -665,6 +665,10 @@ def action_update(conf, args):
# Empty, ignore it. Must also remove from revlist.
with open(patch, 'r') as f:
fromline = f.readline()
+if not fromline:
+# Patch must have been empty to start with. No need
+# to remove it.
+continue
m = re.match(r'''^From ([0-9a-fA-F]+) .*\n''', fromline)
rev = m.group(1)
logger.debug('skipping empty patch %s = %s' % (patch, rev))
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] systemd: split modules into packages
* Bottazzini, Bruno bruno.bottazz...@intel.com [150326 14:40]:
On Qui, 2015-03-26 at 08:56 -0300, Otavio Salvador wrote:
On Thu, Mar 26, 2015 at 5:29 AM, Anders Darander and...@chargestorm.se
wrote:
* Bruno Bottazzini bruno.bottazz...@intel.com [150325 22:50]:
if one wants to launch a simple deamon, most modules are not
required.
He will be able to save space and exclude unwanted packages
from the final image.
I like this, though I've got a few questions that I just noticed.
-PACKAGECONFIG ??= xz ldconfig \
+PACKAGECONFIG ??= \
+ gcrypt \
+ kmod \
+ ldconfig \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'blkid',
'blkid', '', d)} \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'efi',
'efi', '', d)} \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'lz4',
'lz4', '', d)} \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'xz', 'xz',
'', d)} \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'libidn',
'libidn', '', d)} \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'acl',
'acl', '', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'pam',
'pam', '', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'x11',
'xkbcommon', '', d)}
It might be worth noting that xz has gone from being explicitly enabled,
to depend on a DISTRO_FEATURES.
Agreed and we shouldn't explode the number of possible dsitro
features. I'd also prefer if xz were kept enable by default so we
don't make a behavior change under the hood.
...
PACKAGECONFIG[resolved] = --enable-resolved,--disable-resolved
-PACKAGECONFIG[networkd] = --enable-networkd,--disable-networkd
Why do you remove networkd as a PACKAGECONFIG?
If there is a real reason for this, it must be recorded in commit log as
well.
Guys, if you continue this patch you will see that networkd will always
be enabled. Systemd will always configure/make it however, the package
will not be installed if the user wants to.
With PACKAGECONFIG, we may not get everything for free as some data
files will be installed regardless as well as some components from
systemd cannot be disabled by their build system but we can run without
them, for instance we can run without journald.
The advantage of also keeping the PACKAGECONFIG for e.g. networkd (and
as much other things as possible) is that we're also reducing the build
time and size. Sure, it might not be by much, but all small bits are
valuable.
The problem is understanding that although systemd is a single
repository it contains multiple services and daemons in it that can run
even without the core PID1, udev or the many helpers used to configure
the system such as resolved,
timedated, localed...
Yes, and as systemd have configure options for quite a lot of those
things, we should make use of those options, as long as possible.
All of these components are runtime independent, we can install or
remove them and they should not create problems.
That's right, but still, if we even can avoid to build them, it's
better...
Cheers,
Anders
--
Anders Darander
ChargeStorm AB / eStorm AB
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] systemd: split modules into packages
On Sex, 2015-03-27 at 14:11 -0300, Otavio Salvador wrote:
On Fri, Mar 27, 2015 at 2:09 PM, Bottazzini, Bruno
bruno.bottazz...@intel.com wrote:
On Sex, 2015-03-27 at 15:57 +0100, Anders Darander wrote:
* Bottazzini, Bruno bruno.bottazz...@intel.com [150326 14:40]:
On Qui, 2015-03-26 at 08:56 -0300, Otavio Salvador wrote:
On Thu, Mar 26, 2015 at 5:29 AM, Anders Darander
and...@chargestorm.se wrote:
* Bruno Bottazzini bruno.bottazz...@intel.com [150325 22:50]:
if one wants to launch a simple deamon, most modules are not
required.
He will be able to save space and exclude unwanted packages
from the final image.
I like this, though I've got a few questions that I just noticed.
-PACKAGECONFIG ??= xz ldconfig \
+PACKAGECONFIG ??= \
+ gcrypt \
+ kmod \
+ ldconfig \
+ ${@bb.utils.contains('DISTRO_FEATURES',
'blkid', 'blkid', '', d)} \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'efi',
'efi', '', d)} \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'lz4',
'lz4', '', d)} \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'xz',
'xz', '', d)} \
+ ${@bb.utils.contains('DISTRO_FEATURES',
'libidn', 'libidn', '', d)} \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'acl',
'acl', '', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'pam',
'pam', '', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'x11',
'xkbcommon', '', d)}
It might be worth noting that xz has gone from being explicitly
enabled,
to depend on a DISTRO_FEATURES.
Agreed and we shouldn't explode the number of possible dsitro
features. I'd also prefer if xz were kept enable by default so we
don't make a behavior change under the hood.
...
PACKAGECONFIG[resolved] = --enable-resolved,--disable-resolved
-PACKAGECONFIG[networkd] = --enable-networkd,--disable-networkd
Why do you remove networkd as a PACKAGECONFIG?
If there is a real reason for this, it must be recorded in commit log
as well.
Guys, if you continue this patch you will see that networkd will always
be enabled. Systemd will always configure/make it however, the package
will not be installed if the user wants to.
With PACKAGECONFIG, we may not get everything for free as some data
files will be installed regardless as well as some components from
systemd cannot be disabled by their build system but we can run without
them, for instance we can run without journald.
The advantage of also keeping the PACKAGECONFIG for e.g. networkd (and
as much other things as possible) is that we're also reducing the build
time and size. Sure, it might not be by much, but all small bits are
valuable.
You are right! Maybe we should mix them ?
e.g. if PACKAGECONFIG networkd is disabled then the package
systemd-services-networkd will not be included.
What do you think?
You can add the files conditionally so these empty packages won't be
generated.
Indeed, do you know how to do this condition or have you got any
example?
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v5] u-boot.inc: fix rename image error
On Wed, Mar 25, 2015 at 6:51 AM, Chunrong Guo b40...@freescale.com wrote:
Resolve mismatch between U-Boot configs and uboot image name.
The ${S}/${config}/u-boot-${type}.${UBOOT_SUFFIX} may alway be false
and repeat compile or install so we need to check if ${type} match
${config}
Signed-off-by: Chunrong Guo b40...@freescale.com
Acked-by: Otavio Salvador ota...@ossystems.com.br
Ross and Richard, this patch should go into master and fido. The
current inc has some issues which this address fine.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Ownership issue in package contents
Hi,
I'm observing an issue with directory ownership in package
contents. Not sure if I'm overlooking something really basic or
if I hit a bug.
Here's a minimal recipe to illustrate the problem:
$ cat foo.bb
LICENSE = CLOSED
inherit useradd
USERADD_PACKAGES = ${PN}
USERADD_PARAM_${PN} = foo
do_install() {
install -d -m 755 ${D}${libdir}/foo
touch ${D}${libdir}/foo/bar
chown -R foo:foo ${D}${libdir}/foo
}
Here's the package content:
$ dpkg -c foo_1.0-r0.0_cortexa9hf-vfp-neon.ipk
drwxrwxrwx root/root 0 2015-03-27 13:37 ./
drwxr-xr-x root/root 0 2015-03-27 13:37 ./usr/
drwxr-xr-x root/root 0 2015-03-27 13:37 ./usr/lib/
drwxr-xr-x root/root 0 2015-03-27 13:37 ./usr/lib/foo/
-rw-r--r-- foo/foo 0 2015-03-27 13:37 ./usr/lib/foo/bar
Note that, although I run chown -R foo:foo ${D}${libdir}/foo in
the recipe, ./usr/lib/foo/ in the package is owned by root.
However, its content has the right ownership.
I also generated and checked the rpm package and observed the
same issue.
Best wishes.
Mario
--
http://www.ossystems.com.br
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Ownership issue in package contents
Hello Mario, On Fri, Mar 27, 2015 at 2:31 PM, Mario Domenech Goulart ma...@ossystems.com.br wrote: ... I also generated and checked the rpm package and observed the same issue. ... I tested the foo recipe on master (OE-Core:2d923d6) and I see the same behavior. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] systemd: split modules into packages
On Fri, Mar 27, 2015 at 2:09 PM, Bottazzini, Bruno
bruno.bottazz...@intel.com wrote:
On Sex, 2015-03-27 at 15:57 +0100, Anders Darander wrote:
* Bottazzini, Bruno bruno.bottazz...@intel.com [150326 14:40]:
On Qui, 2015-03-26 at 08:56 -0300, Otavio Salvador wrote:
On Thu, Mar 26, 2015 at 5:29 AM, Anders Darander and...@chargestorm.se
wrote:
* Bruno Bottazzini bruno.bottazz...@intel.com [150325 22:50]:
if one wants to launch a simple deamon, most modules are not
required.
He will be able to save space and exclude unwanted packages
from the final image.
I like this, though I've got a few questions that I just noticed.
-PACKAGECONFIG ??= xz ldconfig \
+PACKAGECONFIG ??= \
+ gcrypt \
+ kmod \
+ ldconfig \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'blkid',
'blkid', '', d)} \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'efi',
'efi', '', d)} \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'lz4',
'lz4', '', d)} \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'xz',
'xz', '', d)} \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'libidn',
'libidn', '', d)} \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'acl',
'acl', '', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'pam',
'pam', '', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'x11',
'xkbcommon', '', d)}
It might be worth noting that xz has gone from being explicitly
enabled,
to depend on a DISTRO_FEATURES.
Agreed and we shouldn't explode the number of possible dsitro
features. I'd also prefer if xz were kept enable by default so we
don't make a behavior change under the hood.
...
PACKAGECONFIG[resolved] = --enable-resolved,--disable-resolved
-PACKAGECONFIG[networkd] = --enable-networkd,--disable-networkd
Why do you remove networkd as a PACKAGECONFIG?
If there is a real reason for this, it must be recorded in commit log as
well.
Guys, if you continue this patch you will see that networkd will always
be enabled. Systemd will always configure/make it however, the package
will not be installed if the user wants to.
With PACKAGECONFIG, we may not get everything for free as some data
files will be installed regardless as well as some components from
systemd cannot be disabled by their build system but we can run without
them, for instance we can run without journald.
The advantage of also keeping the PACKAGECONFIG for e.g. networkd (and
as much other things as possible) is that we're also reducing the build
time and size. Sure, it might not be by much, but all small bits are
valuable.
You are right! Maybe we should mix them ?
e.g. if PACKAGECONFIG networkd is disabled then the package
systemd-services-networkd will not be included.
What do you think?
You can add the files conditionally so these empty packages won't be generated.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2 0/4] systemd and dbus split into packages
On Sex, 2015-03-27 at 12:38 +, Burton, Ross wrote: On 18 March 2015 at 21:40, Bottazzini, Bruno bruno.bottazz...@intel.com wrote: Sorry, I didn't get why we can't consider this patchset to be included into master now. Because when Khem said that, master was freezing so that we can make the 1.8 release. We've now branched off the release branch so master is open, but the current focus is on the release. Alright! Thanks Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] systemd: split modules into packages
On Sex, 2015-03-27 at 15:57 +0100, Anders Darander wrote:
* Bottazzini, Bruno bruno.bottazz...@intel.com [150326 14:40]:
On Qui, 2015-03-26 at 08:56 -0300, Otavio Salvador wrote:
On Thu, Mar 26, 2015 at 5:29 AM, Anders Darander and...@chargestorm.se
wrote:
* Bruno Bottazzini bruno.bottazz...@intel.com [150325 22:50]:
if one wants to launch a simple deamon, most modules are not
required.
He will be able to save space and exclude unwanted packages
from the final image.
I like this, though I've got a few questions that I just noticed.
-PACKAGECONFIG ??= xz ldconfig \
+PACKAGECONFIG ??= \
+ gcrypt \
+ kmod \
+ ldconfig \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'blkid',
'blkid', '', d)} \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'efi',
'efi', '', d)} \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'lz4',
'lz4', '', d)} \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'xz',
'xz', '', d)} \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'libidn',
'libidn', '', d)} \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'acl',
'acl', '', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'pam',
'pam', '', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'x11',
'xkbcommon', '', d)}
It might be worth noting that xz has gone from being explicitly enabled,
to depend on a DISTRO_FEATURES.
Agreed and we shouldn't explode the number of possible dsitro
features. I'd also prefer if xz were kept enable by default so we
don't make a behavior change under the hood.
...
PACKAGECONFIG[resolved] = --enable-resolved,--disable-resolved
-PACKAGECONFIG[networkd] = --enable-networkd,--disable-networkd
Why do you remove networkd as a PACKAGECONFIG?
If there is a real reason for this, it must be recorded in commit log as
well.
Guys, if you continue this patch you will see that networkd will always
be enabled. Systemd will always configure/make it however, the package
will not be installed if the user wants to.
With PACKAGECONFIG, we may not get everything for free as some data
files will be installed regardless as well as some components from
systemd cannot be disabled by their build system but we can run without
them, for instance we can run without journald.
The advantage of also keeping the PACKAGECONFIG for e.g. networkd (and
as much other things as possible) is that we're also reducing the build
time and size. Sure, it might not be by much, but all small bits are
valuable.
You are right! Maybe we should mix them ?
e.g. if PACKAGECONFIG networkd is disabled then the package
systemd-services-networkd will not be included.
What do you think?
The problem is understanding that although systemd is a single
repository it contains multiple services and daemons in it that can run
even without the core PID1, udev or the many helpers used to configure
the system such as resolved,
timedated, localed...
Yes, and as systemd have configure options for quite a lot of those
things, we should make use of those options, as long as possible.
All of these components are runtime independent, we can install or
remove them and they should not create problems.
That's right, but still, if we even can avoid to build them, it's
better...
Cheers,
Anders
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] linux-yocto: add kern-tools-native to kernel_metadata depends
On Fri, Mar 27, 2015 at 11:21 AM, Ross Burton ross.bur...@intel.com wrote:
The autobuilder failed like this:
temp/run.do_kernel_metadata.25242: line 165: createme: command not found
createme is provided by kern-tools-native. do_patch has a dependency on
kern-tools-native, but do_kernel_metadata runs before do_patch. So move the
dependency from do_patch to do_kernel_metadata, moving the statement from the
.inc to the class so it's alongside the task definition.
Agreed. I've meant to do this cleanup myself a few times .. and then
get sidetracked.
If the depends had been beside the task definition in the .inc, I
would have realized
that I needed to tweak it at the same time .. so this is much better.
Acked-by: Bruce Ashfield bruce.ashfi...@windriver.com
[ YOCTO #7531 ]
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/classes/kernel-yocto.bbclass |1 +
meta/recipes-kernel/linux/linux-yocto.inc |2 --
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/meta/classes/kernel-yocto.bbclass
b/meta/classes/kernel-yocto.bbclass
index 14551a2..a1fbb51 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -261,6 +261,7 @@ do_kernel_checkout[dirs] = ${S}
addtask kernel_checkout before do_patch after do_unpack
addtask kernel_metadata after do_validate_branches before do_patch
+do_kernel_metadata[depends] = kern-tools-native:do_populate_sysroot
do_kernel_configme[dirs] += ${S} ${B}
do_kernel_configme() {
diff --git a/meta/recipes-kernel/linux/linux-yocto.inc
b/meta/recipes-kernel/linux/linux-yocto.inc
index c62f8ca..5b69a49 100644
--- a/meta/recipes-kernel/linux/linux-yocto.inc
+++ b/meta/recipes-kernel/linux/linux-yocto.inc
@@ -32,8 +32,6 @@ KCONF_BSP_AUDIT_LEVEL ?= 0
LINUX_VERSION_EXTENSION ?= -yocto-${LINUX_KERNEL_TYPE}
-do_patch[depends] = kern-tools-native:do_populate_sysroot
-
addtask kernel_configme before do_configure after do_patch
# Pick up shared functions
--
1.7.10.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
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 2/2] kernel-yocto: merge duplicate kernel_configme task definitions
On Fri, Mar 27, 2015 at 11:21 AM, Ross Burton ross.bur...@intel.com wrote:
The kernel_configme task was added twice (once in the .bbclass, one in a .inc)
with different ordering constraints.
Change this to be just one definition in the bbclass with the stronger
ordering
constraints.
Agreed. Organically grown .. and not ideal in the existing layout :)
Acked-by: Bruce Ashfield bruce.ashfi...@windriver.com
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/classes/kernel-yocto.bbclass |2 +-
meta/recipes-kernel/linux/linux-yocto.inc |2 --
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/meta/classes/kernel-yocto.bbclass
b/meta/classes/kernel-yocto.bbclass
index a1fbb51..650ae5a 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -289,7 +289,7 @@ do_kernel_configme() {
echo CONFIG_LOCALVERSION=\${LINUX_VERSION_EXTENSION}\
${B}/.config
}
-addtask kernel_configme after do_patch
+addtask kernel_configme before do_configure after do_patch
python do_kernel_configcheck() {
import re, string, sys
diff --git a/meta/recipes-kernel/linux/linux-yocto.inc
b/meta/recipes-kernel/linux/linux-yocto.inc
index 5b69a49..3b41a61 100644
--- a/meta/recipes-kernel/linux/linux-yocto.inc
+++ b/meta/recipes-kernel/linux/linux-yocto.inc
@@ -32,8 +32,6 @@ KCONF_BSP_AUDIT_LEVEL ?= 0
LINUX_VERSION_EXTENSION ?= -yocto-${LINUX_KERNEL_TYPE}
-addtask kernel_configme before do_configure after do_patch
-
# Pick up shared functions
inherit kernel
inherit kernel-yocto
--
1.7.10.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
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
[OE-core] [PATCH 1/2] linux-yocto: add kern-tools-native to kernel_metadata depends
The autobuilder failed like this:
temp/run.do_kernel_metadata.25242: line 165: createme: command not found
createme is provided by kern-tools-native. do_patch has a dependency on
kern-tools-native, but do_kernel_metadata runs before do_patch. So move the
dependency from do_patch to do_kernel_metadata, moving the statement from the
.inc to the class so it's alongside the task definition.
[ YOCTO #7531 ]
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/classes/kernel-yocto.bbclass |1 +
meta/recipes-kernel/linux/linux-yocto.inc |2 --
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/meta/classes/kernel-yocto.bbclass
b/meta/classes/kernel-yocto.bbclass
index 14551a2..a1fbb51 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -261,6 +261,7 @@ do_kernel_checkout[dirs] = ${S}
addtask kernel_checkout before do_patch after do_unpack
addtask kernel_metadata after do_validate_branches before do_patch
+do_kernel_metadata[depends] = kern-tools-native:do_populate_sysroot
do_kernel_configme[dirs] += ${S} ${B}
do_kernel_configme() {
diff --git a/meta/recipes-kernel/linux/linux-yocto.inc
b/meta/recipes-kernel/linux/linux-yocto.inc
index c62f8ca..5b69a49 100644
--- a/meta/recipes-kernel/linux/linux-yocto.inc
+++ b/meta/recipes-kernel/linux/linux-yocto.inc
@@ -32,8 +32,6 @@ KCONF_BSP_AUDIT_LEVEL ?= 0
LINUX_VERSION_EXTENSION ?= -yocto-${LINUX_KERNEL_TYPE}
-do_patch[depends] = kern-tools-native:do_populate_sysroot
-
addtask kernel_configme before do_configure after do_patch
# Pick up shared functions
--
1.7.10.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] kernel-yocto: merge duplicate kernel_configme task definitions
The kernel_configme task was added twice (once in the .bbclass, one in a .inc)
with different ordering constraints.
Change this to be just one definition in the bbclass with the stronger ordering
constraints.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/classes/kernel-yocto.bbclass |2 +-
meta/recipes-kernel/linux/linux-yocto.inc |2 --
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/meta/classes/kernel-yocto.bbclass
b/meta/classes/kernel-yocto.bbclass
index a1fbb51..650ae5a 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -289,7 +289,7 @@ do_kernel_configme() {
echo CONFIG_LOCALVERSION=\${LINUX_VERSION_EXTENSION}\
${B}/.config
}
-addtask kernel_configme after do_patch
+addtask kernel_configme before do_configure after do_patch
python do_kernel_configcheck() {
import re, string, sys
diff --git a/meta/recipes-kernel/linux/linux-yocto.inc
b/meta/recipes-kernel/linux/linux-yocto.inc
index 5b69a49..3b41a61 100644
--- a/meta/recipes-kernel/linux/linux-yocto.inc
+++ b/meta/recipes-kernel/linux/linux-yocto.inc
@@ -32,8 +32,6 @@ KCONF_BSP_AUDIT_LEVEL ?= 0
LINUX_VERSION_EXTENSION ?= -yocto-${LINUX_KERNEL_TYPE}
-addtask kernel_configme before do_configure after do_patch
-
# Pick up shared functions
inherit kernel
inherit kernel-yocto
--
1.7.10.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] oe-git-proxy: Redirect error messages to STDERR
Hi Juro, On 27 March 2015 at 20:37, Darren Hart dvh...@linux.intel.com wrote: oe-git-proxy script needs socat. If socat is not found, an error message is issued on STDOUT. This leads to a misleading git message: fatal: protocol error: bad line length character: ERRO instead of the intended message: ERROR: socat binary not in PATH Redirecting the error message to STDERR fixes this issue. Signed-off-by: Juro Bystricky juro.bystri...@intel.com Thanks Juro, good fix. Reviewed-by: Darren Hart dvh...@linux.intel.com I never saw the original mail, can you re-send it to the list please? Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] oe-git-proxy: Redirect error messages to STDERR
On 3/27/15, 10:17 AM, Juro Bystricky juro.bystri...@intel.com wrote: oe-git-proxy script needs socat. If socat is not found, an error message is issued on STDOUT. This leads to a misleading git message: fatal: protocol error: bad line length character: ERRO instead of the intended message: ERROR: socat binary not in PATH Redirecting the error message to STDERR fixes this issue. Signed-off-by: Juro Bystricky juro.bystri...@intel.com Thanks Juro, good fix. Reviewed-by: Darren Hart dvh...@linux.intel.com -- Darren Hart Intel Open Source Technology Center -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Not selecting old version of package as installing it would break existing dependencies
openembedded-core-boun...@lists.openembedded.org wrote on 03/24/2015 12:16:05 PM: From: Mike Looijmans mike.looijm...@topic.nl To: openembedded-core@lists.openembedded.org, Date: 03/24/2015 12:16 PM Subject: [OE-core] Not selecting old version of package as installing it would break existing dependencies Sent by: openembedded-core-boun...@lists.openembedded.org After upgrading a library to a newer version, for example, something called libdvbsi++ from 0.3.6 to 0.3.7, running opkg upgrade outputs the following cryptic error message: Not selecting libdvbsi++1 0.3.6 as installing it would break existing dependencies. When opkg runs, it creates a list of all the available packages on the configured repos + all the installed packages. During an upgrade, it goes through the process of finding the best upgrade match for each installed package, searching on the master list. The process goes through a series of checks for each candidate, like making sure the archs are compatible, and making sure installing a candidate won't break existing installed packages. In your case, opkg determines there are 2 candidates, libdvbsi++0.3.6 and libdvbsi++0.3.7. While evaluating libdvbsi++0.3.6, the pkg_breaks_reverse_dep check fails, triggering the message shown above (and removing the candidate). Adding -V2 to opkg upgrade expands that with the following message: opkg_prepare_upgrade_pkg: Package libdvbsi++1 (0.3.7-r2.0) installed in root is up to date. So apparently it knows about the later version, so why complain about the old one? The function that returns the best candidate match correctly returns libdvbsi++1 0.3.7. It then compares it against what's already installed. The DEBUG message above shows that the best candidate found is already installed on the system. There is only one package that (r)depends on that lib (enigma2). Nothing else needs it. This often happens with other packages as well. Is this a bug in opkg, or is it trying to tell us we're doing something wrong? It is not a bug, the message is harmless as it is only pointing to the reason why one of the possible upgrade candidates was discarded. Hope this helps! Alejandro del Castillo -- Mike Looijmans -- ___ 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] wpa-supplicant: Make SystemD D-Bus config conditional
The SystemD D-Bus configuration should only to be installed when
SystemD support is enabled.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/recipes-connectivity/wpa-supplicant/wpa-supplicant.inc | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant.inc
b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant.inc
index 6f0de3c..f95e91c 100644
--- a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant.inc
+++ b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant.inc
@@ -86,12 +86,13 @@ do_install () {
cd ${D}${sysconfdir}/network/ \
ln -sf ../if-pre-up.d/wpa-supplicant if-post-down.d/wpa-supplicant
- install -d ${D}/${sysconfdir}/dbus-1/system.d
- install -m 644 ${S}/wpa_supplicant/dbus/dbus-wpa_supplicant.conf
${D}/${sysconfdir}/dbus-1/system.d
install -d ${D}/${datadir}/dbus-1/system-services
install -m 644 ${S}/wpa_supplicant/dbus/*.service
${D}/${datadir}/dbus-1/system-services
if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)};
then
+ install -d ${D}/${sysconfdir}/dbus-1/system.d
+ install -m 644
${S}/wpa_supplicant/dbus/dbus-wpa_supplicant.conf
${D}/${sysconfdir}/dbus-1/system.d
+
install -d ${D}/${systemd_unitdir}/system
install -m 644 ${S}/wpa_supplicant/systemd/*.service
${D}/${systemd_unitdir}/system
fi
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] file: remove the original magic.h
On 2015/3/27 17:56, Burton, Ross wrote: On 27 March 2015 at 03:31, Junling Zheng zhengjunl...@huawei.com mailto:zhengjunl...@huawei.com wrote: So I think the true reason is that if the magic.h exists already, sometimes Makefile will not generate it again. In that case it's likely entirely down to timestamps. How are you modifying magic.h.in http://magic.h.in? Ross Hi, Ross I backport some commits from upstream to fix CVE-2014-9620, and some of them involve the modifying of magic.h.in: 90018fe22ff8b74a22fcd142225b0a00f3f12677 6ce24f35cd4a43c4bdd249e8e0c4952c1f8eac67 0056ec32255de1de973574b0300161a1568767d6 09e41625c999a2e5b51e1092f0ef2432a99b5c33 ce90e05774dd77d86cfc8dfa6da57b32816841c4 And the final difference between magic.h and magic.h.in is: z00238152@Patch-Test:file-5.140$ diff -u src/magic.h src/magic.h magic.h magic.h.in z00238152@Patch-Test:file-5.140$ diff -u src/magic.h src/magic.h.in --- src/magic.h 2015-03-28 02:01:46.0 + +++ src/magic.h.in 2015-03-28 02:01:47.0 + @@ -74,7 +74,7 @@ #defineMAGIC_NO_CHECK_FORTRAN 0x00 /* Don't check ascii/fortran */ #defineMAGIC_NO_CHECK_TROFF0x00 /* Don't check ascii/troff */ -#define MAGIC_VERSION 514 /* This implementation */ +#define MAGIC_VERSION X.YY/* This implementation */ #ifdef __cplusplus @@ -100,7 +100,12 @@ int magic_list(magic_t, const char *); int magic_errno(magic_t); -#define MAGIC_PARAM_MAX_RECURSION 0 +#define MAGIC_PARAM_INDIR_MAX 0 +#define MAGIC_PARAM_NAME_MAX 1 +#define MAGIC_PARAM_ELF_PHNUM_MAX 2 +#define MAGIC_PARAM_ELF_SHNUM_MAX 3 +#define MAGIC_PARAM_ELF_NOTES_MAX 4 + int magic_setparam(magic_t, int, const void *); int magic_getparam(magic_t, int, void *); So, if Makefile doesn't generate a new magic.h, there will be some symbol undeclared errors during compiling. By the way, the upstream code has only magic.h.in, and no magic.h, which only exists in release version tarballs. And I think the original magic.h is redundant. Cheers, Junling -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
