[OE-core] [PATCH] buildhistory: set commit user name and email for the new git repo
git commit needs a user name and email even if --author is set. In most
cases users have ~/.gitconfig but in some cases the build user account
does not have these set which breaks the build.
Change-Id: Idd35df626332756ba5bd61d9273c76c7e63ed3f9
Signed-off-by: Mikko Rapeli mikko.rap...@bmw.de
---
meta/classes/buildhistory.bbclass | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/meta/classes/buildhistory.bbclass
b/meta/classes/buildhistory.bbclass
index 211dcf1..dbd27b0 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -14,7 +14,9 @@ BUILDHISTORY_DIR_PACKAGE =
${BUILDHISTORY_DIR}/packages/${MULTIMACH_TARGET_SYS}
BUILDHISTORY_DIR_SDK = ${BUILDHISTORY_DIR}/sdk/${SDK_NAME}/${IMAGE_BASENAME}
BUILDHISTORY_IMAGE_FILES ?= /etc/passwd /etc/group
BUILDHISTORY_COMMIT ?= 0
-BUILDHISTORY_COMMIT_AUTHOR ?= buildhistory buildhistory@${DISTRO}
+BUILDHISTORY_COMMIT_USER_NAME ?= buildhistory
+BUILDHISTORY_COMMIT_USER_EMAIL ?= buildhistory@${DISTRO}
+BUILDHISTORY_COMMIT_AUTHOR ?= ${BUILDHISTORY_COMMIT_USER_NAME}
${BUILDHISTORY_COMMIT_USER_EMAIL}
BUILDHISTORY_PUSH_REPO ?=
SSTATEPOSTINSTFUNCS_append = buildhistory_emit_pkghistory
@@ -586,6 +588,11 @@ END
HOSTNAME=`hostname 2/dev/null || echo unknown`
CMDLINE=${@buildhistory_get_cmdline(d)}
if [ $repostatus != ] ; then
+ # git commit needs this setup, done every time before
+ # commit to support name and email changes via
+ # bitbake configuration
+ git config user.name ${BUILDHISTORY_COMMIT_USER_NAME}
+ git config user.email
${BUILDHISTORY_COMMIT_USER_EMAIL}
git add -A .
# porcelain output looks like ?? packages/foo/bar
# Ensure we commit metadata-revs with the first commit
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] opkg-utils: Change alternatives lib path from /usr/lib/opkg to /var/lib/opkg
Please use the same variable with weak assignment like opkg recipes (so
that it can be easily changed from distro config).
This also breaks all upgrade paths, is it acceptable? In oe-classic days
I've created postinst script which were migrating existing
update-alternatives in the rootfs when update-alternatives-cworth was
upgraded with different path.
On Wed, May 20, 2015 at 3:31 AM, Li Zhou li.z...@windriver.com wrote:
When update-alternatives is moved from opkg to opkg-utils, a line in
the file is changed
from ad=$OPKG_OFFLINE_ROOT@opkglibdir@/opkg/alternatives
to ad=$OPKG_OFFLINE_ROOT/usr/lib/opkg/alternatives.
But opkglibdir doesn't equal to /usr/lib here, but equal to /var/lib
in oe-core build by configuring --with-opkglibdir.
opkg-utils can't get the var value in opkg, so here define opkglibdir to
set the path.
Signed-off-by: Li Zhou li.z...@windriver.com
---
meta/recipes-devtools/opkg-utils/opkg-utils_git.bb |3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
index 2800a5d..fc12d91 100644
--- a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
+++ b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
@@ -22,8 +22,11 @@ PYTHONRDEPS_class-native =
PACKAGECONFIG = python
PACKAGECONFIG[python] = ,,,${PYTHONRDEPS}
+opkglibdir = /var/lib
+
do_install() {
oe_runmake PREFIX=${prefix} DESTDIR=${D} install
+ sed -i s:/usr/lib/opkg:${opkglibdir}/opkg:
${D}${bindir}/update-alternatives
}
PACKAGES =+ update-alternatives-opkg
--
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] [PATCH] kernel/rm_work: Improve interaction
Hi Richard,
I've observed a side effect of this patch.
The problem is sstate reuse.
Steps to reproduce:
1) bitbake core-image-minimal
2) Change TMPDIR in local.conf
TMPDIR = ${TOPDIR}/tmp-test
3) bitbake core-image-minimal
In theory, sstate objects are all reused in step 3. But currently the
do_populate_sysroot sstate object of the kernel is not reused. In
addition, other kernel tasks like do_fetch, do_patch, do_compile, etc,
are rerun.
Best Regards,
Chen Qi
On 05/14/2015 05:31 PM, Richard Purdie wrote:
The do_shared_workdir task does leave behind the necessary information in
shared-work after it completes. We don't make this a full sstate task
however since that means tarring up and copying what is usually a large
amount of data which would be better extracted straight from the original
SCM.
The issue with rm_work occurs since it removes the do_shared_workdir stamp
meaning subsequent builds will add it back if they need to touch any kernel
modules for example. This ends up triggering a near enough complete kernerl
rebuild since if configure reruns, populate_sysroot has to rerun.
This change promotes the task to have a setscene variant but it doesn't use
any of the sstate class lifting to generate the sstate file. The sstate function
will therefore never get called since the sstate object will never exist.
We can add the task to the list of tasks rm_work promotes to a setscene variant
and unwanted rebuilds of the kernel should be avoided.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 74092e9..54725ba 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -235,6 +235,11 @@ kernel_do_install() {
do_install[prefuncs] += package_get_auto_pr
addtask shared_workdir after do_compile before do_compile_kernelmodules
+addtask shared_workdir_setscene
+
+do_shared_workdir_setscene () {
+ exit 1
+}
emit_depmod_pkgdata() {
# Stash data for depmod
diff --git a/meta/classes/rm_work.bbclass b/meta/classes/rm_work.bbclass
index e68d02a..5e9efc1 100644
--- a/meta/classes/rm_work.bbclass
+++ b/meta/classes/rm_work.bbclass
@@ -49,7 +49,7 @@ do_rm_work () {
cd `dirname ${STAMP}`
for i in `basename ${STAMP}`*
do
-for j in ${SSTATETASKS}
+for j in ${SSTATETASKS} do_shared_workdir
do
case $i in
*do_setscene*)
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] e2fsprogs: add expansion of mkdir_p to configure.in
add 0001-e2fsprogs-add-expansion-of-mkdir_p-to-configure.in.patch which fix a bug that macro @mkdir_p@ can't be substituted and modify e2fsprogs_1.42.9.bb to add this patch Upstream-Status: Pending Signed-off-by: Chuang Dong chuang.d...@windriver.com --- ...-add-expansion-of-mkdir_p-to-configure.in.patch | 32 ++ .../recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb | 1 + 2 files changed, 33 insertions(+) create mode 100644 meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-e2fsprogs-add-expansion-of-mkdir_p-to-configure.in.patch diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-e2fsprogs-add-expansion-of-mkdir_p-to-configure.in.patch b/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-e2fsprogs-add-expansion-of-mkdir_p-to-configure.in.patch new file mode 100644 index 000..fa62f4d --- /dev/null +++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-e2fsprogs-add-expansion-of-mkdir_p-to-configure.in.patch @@ -0,0 +1,32 @@ +From 94868938a7e4728019640356b3919c7ddd0b91d4 Mon Sep 17 00:00:00 2001 +From: Chuang Dong chuang.d...@windriver.com +Date: Wed, 20 May 2015 14:15:27 +0800 +Subject: [PATCH] e2fsprogs: add expansion of mkdir_p to configure.in + +the macro named @mkdir_p@ that can't be substituted, which in the file +Makefile(/build/e2fsprogs/build/po), @mkdir_p@ equal to @MKDIR_P@ which has +been substituted. So, add a command in original code of e2fsprogs could +substitute @mkdir_p@ + +Upstream-Status: Pending + +Signed-off-by: Chuang Dong chuang.d...@windriver.com +--- + configure.in | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/configure.in b/configure.in +index 6f39cc9..f895531 100644 +--- a/configure.in b/configure.in +@@ -6,6 +6,7 @@ AH_BOTTOM([#include dirpaths.h]) + MCONFIG=./MCONFIG + AC_SUBST_FILE(MCONFIG) + BINARY_TYPE=bin ++AC_SUBST([mkdir_p], ['$(MKDIR_P)']) + dnl + dnl This is to figure out the version number and the date + dnl +-- +1.8.5.2.233.g932f7e4 + diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb index b354088..4ce1ba8 100644 --- a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb +++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb @@ -22,6 +22,7 @@ SRC_URI += file://acinclude.m4 \ file://cache_inode.patch \ file://CVE-2015-0247.patch \ file://0001-libext2fs-fix-potential-buffer-overflow-in-closefs.patch \ + file://0001-e2fsprogs-add-expansion-of-mkdir_p-to-configure.in.patch \ SRC_URI[md5sum] = 3f8e41e63b432ba114b33f58674563f7 -- 1.8.5.2.233.g932f7e4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] trouble related to oe-core update
On Tue, May 19, 2015 at 10:54 AM, Andreas Müller schnitzelt...@googlemail.com wrote: On Tue, May 19, 2015 at 5:54 AM, Khem Raj raj.k...@gmail.com wrote: On May 18, 2015, at 6:12 AM, Otavio Salvador ota...@ossystems.com.br wrote: On Mon, May 18, 2015 at 10:08 AM, Andreas Müller schnitzelt...@googlemail.com wrote: On Mon, May 18, 2015 at 2:50 PM, Otavio Salvador ota...@ossystems.com.br wrote: ... overestimate please. Still what about angstrom + imx6qsabresd? No clue. I personally don't use Angstrom and I don't know what the distro does. You can instrument the class code to see if you find something useful and I can assist in how to address the issue. I just don't have enough time to debug this myself. It has nothing to do with Angstrom, I checked meta-fsl-arm and here it goes conf/machine/imx6qsabresd.conf …. SOC_FAMILY = mx6:mx6q” … Then conf/machine/include/imx-base.inc …. # Float-Point setting # handled by software # DEFAULTTUNE_mx6 ?= cortexa9-neon # handled by hardware DEFAULTTUNE_mx6 ?= cortexa9hf-neon” …. Here you are saying all mx6 machines which don’t choose their DEFAULTTUNE are not thumb capable and hence ‘thumb’ does not get into TUNE_FEATURES IMO changing defaults for mx6 to use cortexa9t2hf-vfp-neon would be most close to h/w capabilities. and when we say my default instruction set is thumb then it errors out. Ofcours one could argue that message could have been better but atleast it did not do the wrong thing Hi, thanks very very much for support. As you might guess TUNES are still a matter I do not yet understand - please no comments :). So to get build working again - also for variscite machine - I commented out DEFAULTTUNE_mx6 in conf/machine/include/imx-base.inc. Maybe somebody could jump in to get the combination of meta-fsl-arm / meta-angstrom working with a proper fix? Thanks again Would like to get a solution for this and see 2 ways to go in imx-base.inc: 1. allow thumb: snip # Float-Point setting # handled by software # DEFAULTTUNE_mx6 ?= cortexa9t-neon # handled by hardware DEFAULTTUNE_mx6 ?= cortexa9thf-neon /snip 2. if thumb2 is not allowed (why?): snip # Float-Point setting # handled by software # DEFAULTTUNE_mx6 ?= cortexa9-neon # handled by hardware DEFAULTTUNE_mx6 ?= cortexa9hf-neon ARM_INSTRUCTION_SET = arm /snip Opinions? Andreas -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] combo-layer: handle unset dest_dir in sanity_check()
The previous clean up dest_dir checking patch (f8cdbe7497) improved handling of empty dest_dir but made handling of unset dest_dir worse: instead showing the Option dest_dir is not defined for component ... error, it fails with a Python exception. Avoid that by providing a sane fallback for the unset case. With that change, dest_dir is no longer strictly required, but the check for it is kept to ensure that a combo-layer.conf also works with older combo-layer versions. [Yocto #7773] Signed-off-by: Patrick Ohly patrick.o...@intel.com --- scripts/combo-layer | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/scripts/combo-layer b/scripts/combo-layer index b0b7c28..698d3e3 100755 --- a/scripts/combo-layer +++ b/scripts/combo-layer @@ -145,8 +145,10 @@ class Configuration(object): 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]) +# (unset, empty string, double slashes) in the rest of the code. +# It not being set will still be flagged as error because it is +# listed as required option above; that could be changed now. +dest_dir = os.path.normpath(self.repos[name].get(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)) -- 2.1.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] combo-layer sanity_check fix
The following changes since commit c0f0b6e6ef1edc0a9f9e1ceffb1cdbbef2e409c6: glibc: CVE-2015-1781: resolv/nss_dns/dns-host.c buffer overflow (2015-05-16 22:37:21 +0100) are available in the git repository at: git://github.com/pohly/openembedded-core master https://github.com/pohly/openembedded-core/tree/master Patrick Ohly (1): combo-layer: handle unset dest_dir in sanity_check() scripts/combo-layer | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) -- 2.1.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/5] alsa-plugins: initial recipe
On Mon, 2015-05-18 at 15:40 +0300, Tanu Kaskinen wrote: When PulseAudio is installed, alsa-plugins is needed to provide compatibility for ALSA applications. The dependencies are set up so that pulseaudio-server depends on alsa-plugins-pulseaudio-conf, and alsa-plugins-pulseaudio-conf depends on the PulseAudio plugins. This should make the ALSA-PulseAudio compatibility configuration work out of the box, while leaving the PulseAudio specific configuration out on systems that don't have pulseaudio-server installed. Signed-off-by: Tanu Kaskinen tanu.kaski...@linux.intel.com --- .../recipes-multimedia/alsa/alsa-plugins_1.0.29.bb | 81 ++ meta/recipes-multimedia/pulseaudio/pulseaudio.inc | 5 ++ 2 files changed, 86 insertions(+) create mode 100644 meta/recipes-multimedia/alsa/alsa-plugins_1.0.29.bb Running this through the autobuilder revealed: https://autobuilder.yoctoproject.org/main/builders/nightly-ipk/builds/303/steps/BuildImages/logs/stdio which I'm guessing comes from this patch but I haven't bisected. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/5] alsa-plugins: initial recipe
On Tue, 2015-05-19 at 18:06 +0300, Tanu Kaskinen wrote: On Tue, 2015-05-19 at 15:42 +0100, Burton, Ross wrote: On 19 May 2015 at 15:31, Burton, Ross ross.bur...@intel.com wrote: On 18 May 2015 at 13:40, Tanu Kaskinen tanu.kaski...@linux.intel.com wrote: +# The resampler plugins create some symlinks, which have to be added to FILES +# manually, since do_split_packages() rejects symlinks. The symlinks also cause +# QA errors, but those errors are false positives, so we disable the QA checks. Not true, there's an allow_symlink (default False) option to do_split_packages, so this can be cleaned up. Assuming that those symlinks are versioning (and so pointless for loadable modules), a neater fix might be to patch in libtool -avoid-version. Investigate *before* sending, Ross. Just pass allow_links=True to do_split_packages() and all of this can be deleted. Thanks, I'll do that. Actually, no, I won't do that. I don't want the symlinks to go to separate packages, they should be shipped in the same package that contains the real plugin file. -- Tanu -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] opkg and gpg signed ipk packages
Do you think this patch would be of interest for someone? Yes but it would be good to make it choosable at distro level. Opkg has support for 'sha256' but opkg-utils only supports md5. We could pass the sha256 option to opkg-utils (like other parameters such as Maintainer), and make it configurable. We just need to figure out how to pass this option to opkg-utils. Since MD5 is not very secure, wouldn't it be better to use sha256 as default? Or is there any specific reason that someone would want MD5 to be kept as the default (due to e.g. performance, backwards compatibility .. ?). It takes longer time to compute a sha256 checksum compared to md5 but sha256 is more secure reliable. Any way it would be good to have this optional (sha256 or md5). I agree.. and RPM(5) has the ability to switch the default checksum from MD5 to others as well. So a global distro setting would make sense. (I don't know how the deb package manager is configured.) Let me know if we come up with a distribution level switch (or if we just want to make the policy be sha256, as it's definitely better then MD5) and I can help make the RPM configuration change as well. I think a configuration at high level would be good to use for all PMS, to choose MD5 or sha256. conf/local.conf: # Package Management configuration PACKAGE_CLASSES ?= package_ipk Or PACKAGE_CLASSES ?= package_rpm PACKAGE_CHECKSUM ?= sha256something like this Or PACKAGE_CHECKSUM ?= md5 //Sona -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] combo-layer: modified to generate better commit messages.
This patch includes support for a global section in combo-layer.conf
called [combo-layer-settings]. Supported in this section is key
commit_msg; its value is the template for the git commit message
that updates the last_revision. The template can include substitution
for the updated component list: ${components}. The substituted value
will either be a comma-separated list of components or all components,
if combo-layer was invoked without component list argument.
If the key is not present, the old default value is used for the commit
message.
Configuration file example:
[combo-layer-settings]
commit_msg = pulled in the latest changes for ${components}.
Signed-off-by: Ismo Puustinen ismo.puusti...@intel.com
---
scripts/combo-layer | 33 ++---
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/scripts/combo-layer b/scripts/combo-layer
index 19d64e6..cbb20a2 100755
--- a/scripts/combo-layer
+++ b/scripts/combo-layer
@@ -26,6 +26,7 @@ import logging
import subprocess
import ConfigParser
import re
+from string import Template
__version__ = 0.2.1
@@ -69,15 +70,27 @@ class Configuration(object):
else:
self.repos[repo][name] = value
+def readglobalsection(parser, section):
+for (name, value) in parser.items(section):
+if name == commit_msg:
+self.commit_msg_template = value
+
logger.debug(Loading config file %s % self.conffile)
self.parser = ConfigParser.ConfigParser()
with open(self.conffile) as f:
self.parser.readfp(f)
+# initialize default values
+self.commit_msg_template = Automatic commit to update last_revision
+
self.repos = {}
for repo in self.parser.sections():
-self.repos[repo] = {}
-readsection(self.parser, repo, repo)
+if repo == combo-layer-settings:
+# special handling for global settings
+readglobalsection(self.parser, repo)
+else:
+self.repos[repo] = {}
+readsection(self.parser, repo, repo)
# Load local configuration, if available
self.localconffile = None
@@ -438,7 +451,21 @@ def action_update(conf, args):
if output:
logger.info(Committing updated configuration file)
if output.lstrip().startswith(M):
-runcmd('git commit -m Automatic commit to update last_revision
%s' % relpath)
+
+# create the components string
+component_str = all components
+if len(components) 0:
+# otherwise tell which components were actually changed
+component_str = , .join(components)
+
+# expand the template with known values
+template = Template(conf.commit_msg_template)
+raw_msg = template.substitute(components = component_str)
+
+# sanitize the string before using it in command line
+msg = raw_msg.replace('', '\\')
+
+runcmd('git commit -m %s %s' % (msg, relpath))
def apply_patchlist(conf, repos):
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/5] alsa-plugins: initial recipe
On Wed, 2015-05-20 at 10:00 +0100, Burton, Ross wrote:
On 18 May 2015 at 13:40, Tanu Kaskinen tanu.kaski...@linux.intel.com
wrote:
When PulseAudio is installed, alsa-plugins is needed to
provide
compatibility for ALSA applications.
The dependencies are set up so that pulseaudio-server depends
on
alsa-plugins-pulseaudio-conf, and alsa-plugins-pulseaudio-conf
depends
on the PulseAudio plugins. This should make the
ALSA-PulseAudio
compatibility configuration work out of the box, while leaving
the
PulseAudio specific configuration out on systems that don't
have
pulseaudio-server installed.
* satisfy_dependencies_for: Cannot satisfy the following dependencies
for alsa-plugins-dev:
* alsa-plugins (= 1.0.29-r0) *
* opkg_install_cmd: Cannot install package alsa-plugins-dev.
Oops! In the future, when adding any new packages, I probably should try
building images with those packages installed.
There's a default RDEPENDS_${PN}-dev = ${PN}, but as alsa-plugins
doesn't exist that isn't very useful. Then again shipping the .la
files for the loadable modules isn't very useful either (Linux doesn't
need them to load modules, and nothing will link against them).
So, instead of:
+FILES_${PN}-dev += ${libdir}/alsa-lib/*.la
we should just delete the .la files in the do_install_append().
Right, the -dev package is obviously pointless in this case. I could
have realized that just by thinking a bit more while writing the
recipe...
--
Tanu
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] busybox: passwd: applet not found
Hi, I am a bit confused why busybox passwd does not work with daisy. It used to work with dylan. When I try to use busybox passwd, I am getting the following output: passwd: applet not found Is something wrong with the busybox maintainer script or somewhere else? For instance, busybox pwd can be located as well as some other applets that I have quickly run. Apparently, this does not seem to be in the migration guide either, so I presume that I am doing something wrong, but what exactly? Fwiw, busybox passwd works just fine on my desktop, too, as expected. As for completeness, passwd does work (without the busybox prefix), but that is not what I am aiming for. I am always trying to be explicit because I always want to use busybox's applet, no matter what. So what can I do to overcome this? Ys, L. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] sstate: Add handling of do_shared_workdir task
Changing TMPDIR and rebuilding an image was resulting in rebuilds of
kernels due to dependencies on the shared_workdir task. If installed
from sstate, nothing needs this task so add it to the whitelisted
task patterns.
After this change, the kernel does not rebuild when a new TMPDIR and
hot sstate cache is used.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index ccf2ea7..9e04388 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -867,6 +867,9 @@ def setscene_depvalid(task, taskdependees, notneeded, d):
# Target populate_sysroot need their dependencies
return False
+if taskdependees[task][1] == 'do_shared_workdir':
+continue
+
# This is due to the [depends] in useradd.bbclass complicating matters
# The logic *is* reversed here due to the way hard setscene
dependencies are injected
if taskdependees[task][1] == 'do_package' and
taskdependees[dep][0].endswith(('shadow-native', 'shadow-sysroot',
'base-passwd', 'pseudo-native')) and taskdependees[dep][1] ==
'do_populate_sysroot':
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel/rm_work: Improve interaction
On Wed, 2015-05-20 at 14:01 +0800, ChenQi wrote:
I've observed a side effect of this patch.
The problem is sstate reuse.
Steps to reproduce:
1) bitbake core-image-minimal
2) Change TMPDIR in local.conf
TMPDIR = ${TOPDIR}/tmp-test
3) bitbake core-image-minimal
In theory, sstate objects are all reused in step 3. But currently the
do_populate_sysroot sstate object of the kernel is not reused. In
addition, other kernel tasks like do_fetch, do_patch, do_compile, etc,
are rerun.
Well spotted, I've sent a patch out for this.
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] cooker: release lockfile on process exit
On Tue, 2015-05-19 at 18:24 -0300, Otavio Salvador wrote: On Tue, May 19, 2015 at 6:07 PM, Richard Purdie richard.pur...@linuxfoundation.org wrote: ... So having thought more about this, my proposal is actually that rather than fix this and cause all kinds of other potential problems, we just make memory resident bitbake the default which is something we'd like to ideally do in the 1.9 timeframe anyway. I understand your background ideas here however the non-deterministic lock release is driving us crazy at the autobuilder management. The sstate cleanup script, workdir cleanup script and in-house scripts all need to be teach to deal with this and this is far from optimal. Would be acceptable for you a command line option to 'wait' it to release the lock before exit? This could be done easily and we avoid side effects. This also provide a solution which is isolated enough to be safely backported for previous releases and provide more deterministic script output. How does it sounds? I don't know how you'd implement this safely. I did give this some further thought last night and concluded that if we want to backport something, the safest approach might be to change the lock acquisition code. Basically, if we can't obtain the lock, sleep for one second and try again. If on the second try we can't obtain the lock, error/exit. If we need a longer delay than one second, we need to figure out what is exiting that slowly and fix that instead. Seems reasonable? Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] xserver-nodm: Support reboot from inside X
ping? On Mon, May 11, 2015 at 5:23 PM, Ricardo Ribalda Delgado ricardo.riba...@gmail.com wrote: If reboot was called from inside the Xserver there could happen a race condition where chvt would never end, and therefore the whole system was stalled. The user could not recover the system by ssh the machine or using the keyboard. Running chvt in background fixes the issue. Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com --- meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm b/meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm index 2e3e09077792..31f545f79199 100755 --- a/meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm +++ b/meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm @@ -48,7 +48,7 @@ case $1 in stop) echo Stopping XServer killproc xinit -chvt 1 +chvt 1 ;; restart) -- 2.1.4 -- Ricardo Ribalda -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/5] alsa-plugins: initial recipe
On 18 May 2015 at 13:40, Tanu Kaskinen tanu.kaski...@linux.intel.com
wrote:
When PulseAudio is installed, alsa-plugins is needed to provide
compatibility for ALSA applications.
The dependencies are set up so that pulseaudio-server depends on
alsa-plugins-pulseaudio-conf, and alsa-plugins-pulseaudio-conf depends
on the PulseAudio plugins. This should make the ALSA-PulseAudio
compatibility configuration work out of the box, while leaving the
PulseAudio specific configuration out on systems that don't have
pulseaudio-server installed.
* satisfy_dependencies_for: Cannot satisfy the following dependencies for
alsa-plugins-dev:
* alsa-plugins (= 1.0.29-r0) *
* opkg_install_cmd: Cannot install package alsa-plugins-dev.
There's a default RDEPENDS_${PN}-dev = ${PN}, but as alsa-plugins doesn't
exist that isn't very useful. Then again shipping the .la files for the
loadable modules isn't very useful either (Linux doesn't need them to load
modules, and nothing will link against them).
So, instead of:
+FILES_${PN}-dev += ${libdir}/alsa-lib/*.la
we should just delete the .la files in the do_install_append().
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] zlib: minor symbolic link issue
Hello,
Just tell me if something is wrong, I can provide a v2 patch.
Regards,
Matthieu
-Message d'origine-
De : openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] De la part de
Matthieu Crapet
Envoyé : mardi 5 mai 2015 10:14
À : openembedded-core@lists.openembedded.org
Objet : [OE-core] [PATCH] zlib: minor symbolic link issue
libz.so symbolic link created in ${libdir} is ../..//lib/libz.so.1.2.8 Make it
cleaner and generic (idea comes from libcgroup recipe).
Signed-off-by: Matthieu Crapet matthieu.cra...@ingenico.com
---
meta/recipes-core/zlib/zlib_1.2.8.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/zlib/zlib_1.2.8.bb
b/meta/recipes-core/zlib/zlib_1.2.8.bb
index ca0ba3f..5e11f23 100644
--- a/meta/recipes-core/zlib/zlib_1.2.8.bb
+++ b/meta/recipes-core/zlib/zlib_1.2.8.bb
@@ -6,7 +6,6 @@ SECTION = libs
LICENSE = Zlib
LIC_FILES_CHKSUM =
file://zlib.h;beginline=4;endline=23;md5=fde612df1e5933c428b73844a0c494fd
-
SRC_URI = http://www.zlib.net/${BPN}-${PV}.tar.xz \
file://remove.ldconfig.call.patch \
file://Makefile-runtests.patch \ @@ -54,7 +53,8 @@
do_install_append_class-target() {
mkdir -p ${D}/${base_libdir}
mv ${D}/${libdir}/libz.so.* ${D}/${base_libdir}
tmp=`readlink ${D}/${libdir}/libz.so`
- ln -sf ../../${base_libdir}/$tmp ${D}/${libdir}/libz.so
+ rel_lib_prefix=`echo ${libdir} | sed 's,\(^/\|\)[^/][^/]*,..,g'`
+ ln -sf ${rel_lib_prefix}${base_libdir}/$tmp
${D}/${libdir}/libz.so
fi
}
--
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] rootfs.py: Improve rpm log_check_regex
Current regex can cause false negatives if paths in bitbake log files contain ERR or Fail. do_rootfs fails with return code 1 in this case. Improved regexp is based on error messages produced by rpm. Those are found by analyzing rpm source code. [YOCTO #7789] Signed-off-by: Ed Bartosh ed.bart...@linux.intel.com --- meta/lib/oe/rootfs.py | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py index 6fb749f..ce23b23 100644 --- a/meta/lib/oe/rootfs.py +++ b/meta/lib/oe/rootfs.py @@ -295,7 +295,9 @@ class Rootfs(object): class RpmRootfs(Rootfs): def __init__(self, d, manifest_dir): super(RpmRootfs, self).__init__(d) -self.log_check_regex = '(unpacking of archive failed|Cannot find package|exit 1|ERR|Fail)' +self.log_check_regex = '(unpacking of archive failed|Cannot find package'\ + '|exit 1|ERROR: |Error: |Error |ERROR '\ + '|Failed |Failed: |Failed$|Failed\(\d+\):)' self.manifest = RpmManifest(d, manifest_dir) self.pm = RpmPM(d, -- 2.1.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] gtk-engines: Allow gtk-engines package to be empty in order to make the -dev package installable.
---
meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
b/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
index 33b6afe..9c52193 100644
--- a/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
+++ b/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
@@ -8,7 +8,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=2d5025d4aa3495befef8f17206a5b0a1
SECTION = x11/base
DEPENDS = intltool-native gtk+
-PR = r3
+PR = r4
PACKAGES += ${PN}-schemas
PACKAGES_DYNAMIC += ^gtk-engine-.* ^gtk-theme-.*
@@ -29,6 +29,8 @@ FILES_${PN}-schemas = ${datadir}/gtk-engines/*.xml
CFLAGS_prepend = -DHAVE_ANIMATION
+ALLOW_EMPTY_${PN} = 1
+
inherit gnomebase
python populate_packages_prepend() {
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gtk-engines: Allow gtk-engines package to be empty in order to make the -dev package installable.
On 20 May 2015 at 12:49, Florian Boor florian.b...@kernelconcepts.de wrote: -PR = r3 +PR = r4 No need to bump PR. Personally I think that the fix here is to stop PN-dev depending on PN, instead of creating an empty PN package to confuse people. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gtk-engines: Allow gtk-engines package to be empty in order to make the -dev package installable.
Hi Ross, On 20.05.2015 15:08, Burton, Ross wrote: No need to bump PR. Personally I think that the fix here is to stop PN-dev depending on PN, instead of creating an empty PN package to confuse people. well, in this way it automatically fixes this issues with the -dev package which is not installable for every build where gtk-engines has been built already, so in my opinion this is a good reason to increment PR. Randomly laying around packages with broken dependencies have quite more potential to confuse people than incremented PR most users do not care about much. Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: +49 271-771091-15 and the reality of tomorrow.Fax: +49 271-771091-19 [Robert Hutchings Goddard, 1904]florian.b...@kernelconcepts.de http://www.kernelconcepts.de/en -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gtk-engines: Allow gtk-engines package to be empty in order to make the -dev package installable.
Hi Otavio, On 20.05.2015 15:20, Otavio Salvador wrote: No. You should rely on PR Service for this. Drop the PR bump as it is pointless here. oh PR Service - if we can rely on it in this case I agree. Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: +49 271-771091-15 and the reality of tomorrow.Fax: +49 271-771091-19 [Robert Hutchings Goddard, 1904]florian.b...@kernelconcepts.de http://www.kernelconcepts.de/en -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gtk-engines: Allow gtk-engines package to be empty in order to make the -dev package installable.
On 20 May 2015 at 14:27, Florian Boor florian.b...@kernelconcepts.de wrote: No. You should rely on PR Service for this. Drop the PR bump as it is pointless here. oh PR Service - if we can rely on it in this case I agree. If you care about upgrade paths then the PR service is far more reliable than explicit PR bumps. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/5] alsa-plugins: initial recipe
On Wed, 2015-05-20 at 13:07 +0100, Richard Purdie wrote: On Mon, 2015-05-18 at 15:40 +0300, Tanu Kaskinen wrote: When PulseAudio is installed, alsa-plugins is needed to provide compatibility for ALSA applications. The dependencies are set up so that pulseaudio-server depends on alsa-plugins-pulseaudio-conf, and alsa-plugins-pulseaudio-conf depends on the PulseAudio plugins. This should make the ALSA-PulseAudio compatibility configuration work out of the box, while leaving the PulseAudio specific configuration out on systems that don't have pulseaudio-server installed. Signed-off-by: Tanu Kaskinen tanu.kaski...@linux.intel.com --- .../recipes-multimedia/alsa/alsa-plugins_1.0.29.bb | 81 ++ meta/recipes-multimedia/pulseaudio/pulseaudio.inc | 5 ++ 2 files changed, 86 insertions(+) create mode 100644 meta/recipes-multimedia/alsa/alsa-plugins_1.0.29.bb Running this through the autobuilder revealed: https://autobuilder.yoctoproject.org/main/builders/nightly-ipk/builds/303/steps/BuildImages/logs/stdio which I'm guessing comes from this patch but I haven't bisected. Yep, Ross already complained about the same thing. A fix is forthcoming. -- Tanu -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gtk-engines: Allow gtk-engines package to be empty in order to make the -dev package installable.
On Wed, May 20, 2015 at 10:17 AM, Florian Boor florian.b...@kernelconcepts.de wrote: On 20.05.2015 15:08, Burton, Ross wrote: No need to bump PR. Personally I think that the fix here is to stop PN-dev depending on PN, instead of creating an empty PN package to confuse people. well, in this way it automatically fixes this issues with the -dev package which is not installable for every build where gtk-engines has been built already, so in my opinion this is a good reason to increment PR. Randomly laying around packages with broken dependencies have quite more potential to confuse people than incremented PR most users do not care about much. No. You should rely on PR Service for this. Drop the PR bump as it is pointless here. -- 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] [PATCH v2] gtk-engines: Make gtk-engines-dev installable by dropping dependency to not generated gtk-engines package.
---
meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
b/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
index 33b6afe..036aa27 100644
--- a/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
+++ b/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
@@ -29,6 +29,8 @@ FILES_${PN}-schemas = ${datadir}/gtk-engines/*.xml
CFLAGS_prepend = -DHAVE_ANIMATION
+RDEPENDS_${PN}-dev =
+
inherit gnomebase
python populate_packages_prepend() {
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] busybox: passwd: applet not found
On 20 May 2015 at 15:48, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On 20 May 2015 at 13:55, Laszlo Papp lp...@kde.org wrote: Hi, I am a bit confused why busybox passwd does not work with daisy. It used to work with dylan. When I try to use busybox passwd, I am getting the following output: passwd: applet not found is the password applet built? Check your busybox .config. Is passwd listed when you invoke plain busybox and have the help-text printing turned on? Sometimes code around bsearch is miscompiled but this should not be the case for your setup, i suppose. ah, the great suid / nosuid split ? try /bin/busybox.suid passwd instead, the default /bin/busybox supposedly points to the .nosuid binary. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] trouble related to oe-core update
On Wed, May 20, 2015 at 10:58 AM, Khem Raj raj.k...@gmail.com wrote: On May 20, 2015, at 6:46 AM, Otavio Salvador ota...@ossystems.com.br wrote: OE-Core does not seem to enable thumb2 by default so I don't think we ought to change the default here. However I do agree in extend the comment and provide an example so it is easier for people to do this when needed. No. That setting is effectively telling this chip does not have thumb capabilities which is wrong for that class of processors, that assumption is wrong and should be fixed. even if you have thumb tunes expressed, it won’t change default ISA which is what you are implying with your first sentence there. Default ISA for a component or globally can be changed via different knobs and distros can choose that policy. Is it possible for you to cook a formal patch with a descriptive commit log for review than? I am not against this change but this needs to be well documented. -- 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] trouble related to oe-core update
On Wed, May 20, 2015 at 5:34 AM, Andreas Müller schnitzelt...@googlemail.com wrote: On Tue, May 19, 2015 at 10:54 AM, Andreas Müller schnitzelt...@googlemail.com wrote: Would like to get a solution for this and see 2 ways to go in imx-base.inc: 1. allow thumb: snip # Float-Point setting # handled by software # DEFAULTTUNE_mx6 ?= cortexa9t-neon # handled by hardware DEFAULTTUNE_mx6 ?= cortexa9thf-neon /snip 2. if thumb2 is not allowed (why?): snip # Float-Point setting # handled by software # DEFAULTTUNE_mx6 ?= cortexa9-neon # handled by hardware DEFAULTTUNE_mx6 ?= cortexa9hf-neon ARM_INSTRUCTION_SET = arm /snip Opinions? OE-Core does not seem to enable thumb2 by default so I don't think we ought to change the default here. However I do agree in extend the comment and provide an example so it is easier for people to do this when needed. -- 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] busybox: passwd: applet not found
On 20 May 2015 at 13:55, Laszlo Papp lp...@kde.org wrote: Hi, I am a bit confused why busybox passwd does not work with daisy. It used to work with dylan. When I try to use busybox passwd, I am getting the following output: passwd: applet not found is the password applet built? Check your busybox .config. Is passwd listed when you invoke plain busybox and have the help-text printing turned on? Sometimes code around bsearch is miscompiled but this should not be the case for your setup, i suppose. thanks, Is something wrong with the busybox maintainer script or somewhere else? For instance, busybox pwd can be located as well as some other applets that I have quickly run. Apparently, this does not seem to be in the migration guide either, so I presume that I am doing something wrong, but what exactly? Fwiw, busybox passwd works just fine on my desktop, too, as expected. As for completeness, passwd does work (without the busybox prefix), but that is not what I am aiming for. I am always trying to be explicit because I always want to use busybox's applet, no matter what. So what can I do to overcome this? Ys, L. -- ___ 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] gtk-engines: Allow gtk-engines package to be empty in order to make the -dev package installable.
Hi, On 20.05.2015 15:32, Burton, Ross wrote: If you care about upgrade paths then the PR service is far more reliable than explicit PR bumps. ok great... then I'll change it to dropping the dependency of the -dev package while I'm working on it anyway. Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: +49 271-771091-15 and the reality of tomorrow.Fax: +49 271-771091-19 [Robert Hutchings Goddard, 1904]florian.b...@kernelconcepts.de http://www.kernelconcepts.de/en -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] trouble related to oe-core update
On May 20, 2015, at 6:46 AM, Otavio Salvador ota...@ossystems.com.br wrote: OE-Core does not seem to enable thumb2 by default so I don't think we ought to change the default here. However I do agree in extend the comment and provide an example so it is easier for people to do this when needed. No. That setting is effectively telling this chip does not have thumb capabilities which is wrong for that class of processors, that assumption is wrong and should be fixed. even if you have thumb tunes expressed, it won’t change default ISA which is what you are implying with your first sentence there. Default ISA for a component or globally can be changed via different knobs and distros can choose that policy. 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] xserver-nodm: Support reboot from inside X
Hi Ricardo, I tested your patch and it's ok another improvement to it will be add a sleep 1 before chvt because killproc xinit don't take a defined time to shutdown and chvt didn't work because X it's running. I'll modify a little your patch and send v2 with your signature. Regards, alimon On 20/05/15 03:34, Ricardo Ribalda Delgado wrote: ping? On Mon, May 11, 2015 at 5:23 PM, Ricardo Ribalda Delgado ricardo.riba...@gmail.com wrote: If reboot was called from inside the Xserver there could happen a race condition where chvt would never end, and therefore the whole system was stalled. The user could not recover the system by ssh the machine or using the keyboard. Running chvt in background fixes the issue. Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com --- meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm b/meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm index 2e3e09077792..31f545f79199 100755 --- a/meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm +++ b/meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm @@ -48,7 +48,7 @@ case $1 in stop) echo Stopping XServer killproc xinit -chvt 1 +chvt 1 ;; restart) -- 2.1.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] midori: fix build with GLib 2.44
On 20 May 2015 at 16:24, Alexander Kanavin alexander.kana...@linux.intel.com wrote: Midori is already at 0.5.10 upstream; if it's compatible with the webkit currently in oe-core, maybe it's better to update to the latest version? When the new webkit patches are ready, I'll definitely pull in the latest midori as well. The precise cause of the problem was a bit of a mystery to me, as the autobuilder was failing in ways that I couldn't replicate or understand. Because of this and the failure being one blocking master-next from being merged I opted to fix the immediate problem instead of doing an upgrade. An upgrade is certainly due though. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] busybox: passwd: applet not found
On May 20, 2015 5:36:55 PM GMT+02:00, Laszlo Papp lp...@kde.org wrote: On Wed, May 20, 2015 at 4:25 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On 20 May 2015 at 17:20, Laszlo Papp lp...@kde.org wrote: On Wed, May 20, 2015 at 4:17 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On 20 May 2015 at 17:09, Laszlo Papp lp...@kde.org wrote: On Wed, May 20, 2015 at 4:07 PM, Burton, Ross ross.bur...@intel.com wrote: On 20 May 2015 at 16:02, Laszlo Papp lp...@kde.org wrote: On a second thought: is even worse now than that, our code has to handle _three_ different scenarios: 1) Desktop. 2) Embedded without Yocto or embedded with old Yocto. 3) Embedded with new Yocto. I do not get excited about this. Do as the documentation says in your distro and you have one scenario. That means compromising security. I am now looking for the ideal case in the future. What is wrong about dropping the privileges in busybox for undedicated processes without creating this separation? That would combine the convenience with security, wouldn't it? We already do that. Since June 2002. version 0.60.4 Then I cannot understand the incompatible change. If the privilege is dropped early and the code is well-understood, then what exactly was being solved in here for the price of incompatibility and more complex environments across projects? But in any case, if BUSYBOX_SPLIT_SUID=0 helps me with being compatible while it still drops the privileges properly as intended by busybox upstream, I guess I can go for that. I am yet to understand the certain users do not follow it part. What exactly? Certain users don't want to risk bugs in the code before privs are dropped. The only way to make them happy is to split the binary into two, a suid one a a nosuid one. OK, well, in that case, the question is: why is it not led by busybox upstream? Currently, busybox downstream projects can call this anything. At least, some standard way would be nice, wouldn't it? The logic where to split is upstream to attempt to have a stable, maintained interface at least. I do not want 2 binaries myself. If there is an attack-vector in the part before dropping privileges then I want to have it fixed. You can ask Denys if he wants to do the 2 binary nonsense upstream, but I will not commit such a thing, fwiw. Cheers, -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH RFC] dosfstools: Bump to version 3.0.28
On 18 May 2015 at 06:48, Soren Brinkmann soren.brinkm...@xilinx.com wrote: I suspected the big version jump probably obsoleted the patches carried in OE. Hence, I just removed them. That's a very big assumption, you should verify that is the fact instead of hoping for the best. I'm not sure whether the license change is the reason for OE only providing the old version. In that case, I guess, just disregard this patch. As Khem said we try to have GPLv2 forms of all GPLv3 recipes, so both are welcome but the patch dropping without verification is a problem right now. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH][Resend] apt: upgrade to 1.0.9.9
Hi Roy,
When try to compile your upgrade using qemux86-64 fails with,
WARNING: QA Issue: apt rdepends on liblzma, but it isn't a build
dependency? [build-deps]
WARNING: QA Issue: /usr/bin/apt-cdrom_apt contained in package apt
requires libapt-private.so.0.0()(64bit), but no providers found in its
RDEPENDS [file-rdeps]
ERROR: Unable to update the package index files. Command
'['/home/alimon/repos/poky/build-x86-64/tmp/sysroots/x86_64-linux/usr/bin/apt-get',
'update']' returned 127:
/home/alimon/repos/poky/build-x86-64/tmp/sysroots/x86_64-linux/usr/bin/apt-get:
symbol lookup error:
/home/alimon/repos/poky/build-x86-64/tmp/sysroots/x86_64-linux/usr/bin/apt-get:
undefined symbol: _Z11InitSignalsv
ERROR: Function failed: do_rootfs
ERROR: Logfile of failure stored in:
/home/alimon/repos/poky/build-x86-64/tmp/work/qemux86_64-poky-linux/core-image-full-cmdline/1.0-r0/temp/log.do_rootfs.15118
ERROR: Task 7
(/home/alimon/repos/poky/meta/recipes-extended/images/core-image-full-cmdline.bb,
do_rootfs) failed with exit code '1
Regards,
alimon
On 12/05/15 21:23, rongqing...@windriver.com wrote:
From: Roy Li rongqing...@windriver.com
Upgrade to fix the several CVEs: CVE-2014-0488, CVE-2014-0490
Remove apt-0.9.9.4-CVE-2014-0478.patch, which was backport.
Romve no-ko-translation.patch, apt-1.0.9.9 has ko translation
Update use-host.patch no-curl.patch db_linking_hack.patch and
noconfigure.patch
Not build the test cases since it requires gtest
Signed-off-by: Roy Li rongqing...@windriver.com
---
.../apt-0.9.9.4/apt-0.9.9.4-CVE-2014-0478.patch| 193 -
.../apt/apt-0.9.9.4/no-ko-translation.patch| 11 --
.../disable-configure-in-makefile.patch| 0
.../apt/apt-1.0.9.9/disable-test.patch | 58 +++
.../fix-gcc-4.6-null-not-defined.patch | 0
.../{apt-0.9.9.4 = apt-1.0.9.9}/makerace.patch| 0
.../{apt-0.9.9.4 = apt-1.0.9.9}/no-nls-dpkg.patch | 0
.../{apt-0.9.9.4 = apt-1.0.9.9}/noconfigure.patch | 17 +-
.../apt/{apt-0.9.9.4 = apt-1.0.9.9}/nodoc.patch | 0
.../truncate-filename.patch| 0
.../{apt-0.9.9.4 = apt-1.0.9.9}/use-host.patch| 6 +-
...apt-native_0.9.9.4.bb = apt-native_1.0.9.9.bb} | 4 +-
meta/recipes-devtools/apt/apt.inc | 5 +-
.../apt/{apt_0.9.9.4.bb = apt_1.0.9.9.bb} | 4 +-
.../apt/files/db_linking_hack.patch| 6 +-
meta/recipes-devtools/apt/files/no-curl.patch | 8 +-
16 files changed, 83 insertions(+), 229 deletions(-)
delete mode 100644
meta/recipes-devtools/apt/apt-0.9.9.4/apt-0.9.9.4-CVE-2014-0478.patch
delete mode 100644
meta/recipes-devtools/apt/apt-0.9.9.4/no-ko-translation.patch
rename meta/recipes-devtools/apt/{apt-0.9.9.4 =
apt-1.0.9.9}/disable-configure-in-makefile.patch (100%)
create mode 100644 meta/recipes-devtools/apt/apt-1.0.9.9/disable-test.patch
rename meta/recipes-devtools/apt/{apt-0.9.9.4 =
apt-1.0.9.9}/fix-gcc-4.6-null-not-defined.patch (100%)
rename meta/recipes-devtools/apt/{apt-0.9.9.4 = apt-1.0.9.9}/makerace.patch
(100%)
rename meta/recipes-devtools/apt/{apt-0.9.9.4 =
apt-1.0.9.9}/no-nls-dpkg.patch (100%)
rename meta/recipes-devtools/apt/{apt-0.9.9.4 =
apt-1.0.9.9}/noconfigure.patch (54%)
rename meta/recipes-devtools/apt/{apt-0.9.9.4 = apt-1.0.9.9}/nodoc.patch
(100%)
rename meta/recipes-devtools/apt/{apt-0.9.9.4 =
apt-1.0.9.9}/truncate-filename.patch (100%)
rename meta/recipes-devtools/apt/{apt-0.9.9.4 = apt-1.0.9.9}/use-host.patch
(84%)
rename meta/recipes-devtools/apt/{apt-native_0.9.9.4.bb =
apt-native_1.0.9.9.bb} (55%)
rename meta/recipes-devtools/apt/{apt_0.9.9.4.bb = apt_1.0.9.9.bb} (74%)
diff --git
a/meta/recipes-devtools/apt/apt-0.9.9.4/apt-0.9.9.4-CVE-2014-0478.patch
b/meta/recipes-devtools/apt/apt-0.9.9.4/apt-0.9.9.4-CVE-2014-0478.patch
deleted file mode 100644
index 79a6897..000
--- a/meta/recipes-devtools/apt/apt-0.9.9.4/apt-0.9.9.4-CVE-2014-0478.patch
+++ /dev/null
@@ -1,193 +0,0 @@
-This patch comes from:
-https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=73;filename=apt_0.9.7.9%2Bdeb7u2.debdiff;att=1;bug=749795
-
-Upstream-Status: Backport
-
-Signed-off-by: Wenlin Kang wenlin.k...@windriver.com
-Signed-off-by: Chong Lu chong...@windriver.com
-
-diff -uarN apt-0.9.9.4-org/cmdline/apt-get.cc apt-0.9.9.4/cmdline/apt-get.cc
apt-0.9.9.4-org/cmdline/apt-get.cc 2014-08-29 15:37:42.587156134 +0800
-+++ apt-0.9.9.4/cmdline/apt-get.cc 2014-08-29 15:51:16.672334086 +0800
-@@ -1046,25 +1046,8 @@
-return true;
- }
- /*}}}*/
--// CheckAuth - check if each download comes form a trusted source /*{{{*/
--// -
--/* */
--static bool CheckAuth(pkgAcquire Fetcher)
-+static bool AuthPrompt(std::string UntrustedList, bool const PromptUser)
- {
-- string UntrustedList;
-- for
Re: [OE-core] busybox: passwd: applet not found
On 20 May 2015 at 17:20, Laszlo Papp lp...@kde.org wrote: On Wed, May 20, 2015 at 4:17 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On 20 May 2015 at 17:09, Laszlo Papp lp...@kde.org wrote: On Wed, May 20, 2015 at 4:07 PM, Burton, Ross ross.bur...@intel.com wrote: On 20 May 2015 at 16:02, Laszlo Papp lp...@kde.org wrote: On a second thought: is even worse now than that, our code has to handle _three_ different scenarios: 1) Desktop. 2) Embedded without Yocto or embedded with old Yocto. 3) Embedded with new Yocto. I do not get excited about this. Do as the documentation says in your distro and you have one scenario. That means compromising security. I am now looking for the ideal case in the future. What is wrong about dropping the privileges in busybox for undedicated processes without creating this separation? That would combine the convenience with security, wouldn't it? We already do that. Since June 2002. version 0.60.4 Then I cannot understand the incompatible change. If the privilege is dropped early and the code is well-understood, then what exactly was being solved in here for the price of incompatibility and more complex environments across projects? But in any case, if BUSYBOX_SPLIT_SUID=0 helps me with being compatible while it still drops the privileges properly as intended by busybox upstream, I guess I can go for that. I am yet to understand the certain users do not follow it part. What exactly? Certain users don't want to risk bugs in the code before privs are dropped. The only way to make them happy is to split the binary into two, a suid one a a nosuid one. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] busybox: passwd: applet not found
On Wed, May 20, 2015 at 4:48 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On May 20, 2015 5:36:55 PM GMT+02:00, Laszlo Papp lp...@kde.org wrote: On Wed, May 20, 2015 at 4:25 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On 20 May 2015 at 17:20, Laszlo Papp lp...@kde.org wrote: On Wed, May 20, 2015 at 4:17 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On 20 May 2015 at 17:09, Laszlo Papp lp...@kde.org wrote: On Wed, May 20, 2015 at 4:07 PM, Burton, Ross ross.bur...@intel.com wrote: On 20 May 2015 at 16:02, Laszlo Papp lp...@kde.org wrote: On a second thought: is even worse now than that, our code has to handle _three_ different scenarios: 1) Desktop. 2) Embedded without Yocto or embedded with old Yocto. 3) Embedded with new Yocto. I do not get excited about this. Do as the documentation says in your distro and you have one scenario. That means compromising security. I am now looking for the ideal case in the future. What is wrong about dropping the privileges in busybox for undedicated processes without creating this separation? That would combine the convenience with security, wouldn't it? We already do that. Since June 2002. version 0.60.4 Then I cannot understand the incompatible change. If the privilege is dropped early and the code is well-understood, then what exactly was being solved in here for the price of incompatibility and more complex environments across projects? But in any case, if BUSYBOX_SPLIT_SUID=0 helps me with being compatible while it still drops the privileges properly as intended by busybox upstream, I guess I can go for that. I am yet to understand the certain users do not follow it part. What exactly? Certain users don't want to risk bugs in the code before privs are dropped. The only way to make them happy is to split the binary into two, a suid one a a nosuid one. OK, well, in that case, the question is: why is it not led by busybox upstream? Currently, busybox downstream projects can call this anything. At least, some standard way would be nice, wouldn't it? The logic where to split is upstream to attempt to have a stable, maintained interface at least. I do not want 2 binaries myself. If there is an attack-vector in the part before dropping privileges then I want to have it fixed. You can ask Denys if he wants to do the 2 binary nonsense upstream, but I will not commit such a thing, fwiw. Well, I understand and appreciate that opinions vary, but if busybox had shipped 3 binaries at the end of the build processes, then their naming would be standard led by busybox upstream. Currently, there is no way to standardize it if Yocto thinks it should be called busybox.suid and e.g. (imaginary example) buildroot thinks it should be called suid.busybox. This would be less than ideal if my software has to work with both. Yes, Denys would need to be convinced for this, but for the time being, I do not have enough time to get it through. Anyway, thank you for your replies. I deem them helpful and prompt. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] busybox: passwd: applet not found
On May 20, 2015 5:58:32 PM GMT+02:00, Laszlo Papp lp...@kde.org wrote: Well, I understand and appreciate that opinions vary, but if busybox had shipped 3 binaries at the end of the build processes, then their naming would be standard led by busybox upstream. Currently, there is no way to standardize it if Yocto thinks it should be called busybox.suid and e.g. (imaginary example) buildroot thinks it should be called suid.busybox. This would be less than ideal if my software has to work with both. If you can then I'd set PREFER_APPLETS and use busybox hush or busybox ash as /bin/sh with one binary and thus avoid the whole filesystem roundtrip penalties. At least that is what one normally does anyway and which works satisfactorily in a lot if setups. Anyway, good to see it's not a busybox or compiler bug so all is well as far as I'm concerned. thanks, -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] busybox: passwd: applet not found
On Wed, May 20, 2015 at 4:25 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On 20 May 2015 at 17:20, Laszlo Papp lp...@kde.org wrote: On Wed, May 20, 2015 at 4:17 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On 20 May 2015 at 17:09, Laszlo Papp lp...@kde.org wrote: On Wed, May 20, 2015 at 4:07 PM, Burton, Ross ross.bur...@intel.com wrote: On 20 May 2015 at 16:02, Laszlo Papp lp...@kde.org wrote: On a second thought: is even worse now than that, our code has to handle _three_ different scenarios: 1) Desktop. 2) Embedded without Yocto or embedded with old Yocto. 3) Embedded with new Yocto. I do not get excited about this. Do as the documentation says in your distro and you have one scenario. That means compromising security. I am now looking for the ideal case in the future. What is wrong about dropping the privileges in busybox for undedicated processes without creating this separation? That would combine the convenience with security, wouldn't it? We already do that. Since June 2002. version 0.60.4 Then I cannot understand the incompatible change. If the privilege is dropped early and the code is well-understood, then what exactly was being solved in here for the price of incompatibility and more complex environments across projects? But in any case, if BUSYBOX_SPLIT_SUID=0 helps me with being compatible while it still drops the privileges properly as intended by busybox upstream, I guess I can go for that. I am yet to understand the certain users do not follow it part. What exactly? Certain users don't want to risk bugs in the code before privs are dropped. The only way to make them happy is to split the binary into two, a suid one a a nosuid one. OK, well, in that case, the question is: why is it not led by busybox upstream? Currently, busybox downstream projects can call this anything. At least, some standard way would be nice, wouldn't it? -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/4] xdpyinfo: upgrade to 1.3.2
Signed-off-by: Ross Burton ross.bur...@intel.com
---
.../xorg-app/{xdpyinfo_1.3.1.bb = xdpyinfo_1.3.2.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-graphics/xorg-app/{xdpyinfo_1.3.1.bb = xdpyinfo_1.3.2.bb}
(82%)
diff --git a/meta/recipes-graphics/xorg-app/xdpyinfo_1.3.1.bb
b/meta/recipes-graphics/xorg-app/xdpyinfo_1.3.2.bb
similarity index 82%
rename from meta/recipes-graphics/xorg-app/xdpyinfo_1.3.1.bb
rename to meta/recipes-graphics/xorg-app/xdpyinfo_1.3.2.bb
index 3688e1b..af04bb6 100644
--- a/meta/recipes-graphics/xorg-app/xdpyinfo_1.3.1.bb
+++ b/meta/recipes-graphics/xorg-app/xdpyinfo_1.3.2.bb
@@ -14,7 +14,7 @@ PE = 1
SRC_URI += file://disable-xkb.patch
-SRC_URI[md5sum] = cacc0733f16e4f2a97a5c430fcc4420e
-SRC_URI[sha256sum] =
aef9285069a517ed870e5d8a02d13f7d8a953d7f7220146da563e04c7f128b94
+SRC_URI[md5sum] = 8809037bd48599af55dad81c508b6b39
+SRC_URI[sha256sum] =
30238ed915619e06ceb41721e5f747d67320555cc38d459e954839c189ccaf51
EXTRA_OECONF = --disable-xkb
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/4] xvinfo: upgrade to 1.1.3
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-graphics/xorg-app/{xvinfo_1.1.2.bb = xvinfo_1.1.3.bb} | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
rename meta/recipes-graphics/xorg-app/{xvinfo_1.1.2.bb = xvinfo_1.1.3.bb}
(68%)
diff --git a/meta/recipes-graphics/xorg-app/xvinfo_1.1.2.bb
b/meta/recipes-graphics/xorg-app/xvinfo_1.1.3.bb
similarity index 68%
rename from meta/recipes-graphics/xorg-app/xvinfo_1.1.2.bb
rename to meta/recipes-graphics/xorg-app/xvinfo_1.1.3.bb
index 8ea1ca0..2965ef7 100644
--- a/meta/recipes-graphics/xorg-app/xvinfo_1.1.2.bb
+++ b/meta/recipes-graphics/xorg-app/xvinfo_1.1.3.bb
@@ -9,7 +9,6 @@ extension.
LIC_FILES_CHKSUM = file://COPYING;md5=b664101ad7a1dc758a4c4109bf978e68
DEPENDS += libxv
PE = 1
-PR = ${INC_PR}.0
-SRC_URI[md5sum] = 1fbd65e81323a8c0a4b5e24db0058405
-SRC_URI[sha256sum] =
eed3d90ffd788ef728c4a5e7aa4bd86dc6bbcebac929caf7a0479cf8b53b50e3
+SRC_URI[md5sum] = 558360176b718dee3c39bc0648c0d10c
+SRC_URI[sha256sum] =
9fba8b68daf53863e66d5004fa9c703fcecf69db4d151ea2d3d885d621e6e5eb
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/4] xkeyboard-config: upgrade to 2.14
Signed-off-by: Ross Burton ross.bur...@intel.com
---
.../xorg-lib/{xkeyboard-config_2.13.bb = xkeyboard-config_2.14.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-graphics/xorg-lib/{xkeyboard-config_2.13.bb =
xkeyboard-config_2.14.bb} (88%)
diff --git a/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.13.bb
b/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.14.bb
similarity index 88%
rename from meta/recipes-graphics/xorg-lib/xkeyboard-config_2.13.bb
rename to meta/recipes-graphics/xorg-lib/xkeyboard-config_2.14.bb
index 668a37a..a960744 100644
--- a/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.13.bb
+++ b/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.14.bb
@@ -15,8 +15,8 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=0e7f21ca7db975c63467d2e7624a12f9
SRC_URI =
${XORG_MIRROR}/individual/data/xkeyboard-config/${BPN}-${PV}.tar.bz2 \
file://0001-Remove-GPLv3-content.patch \
-SRC_URI[md5sum] = a415775ca8ecf4dfafc9488b8cbd7114
-SRC_URI[sha256sum] =
7b5be9f2b9a30102512b15308aec55f7f54289df24ac21de82ebb4bf145f9fce
+SRC_URI[md5sum] = 2869c03d85b606f929aab054ef6e1b60
+SRC_URI[sha256sum] =
dc91458a214c56a35727f9e523fc647615de64137057ca6ee4d4d4474a4bb2ae
SECTION = x11/libs
DEPENDS = intltool-native virtual/gettext util-macros libxslt-native
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/4] puzzles: upgrade to latest srcrev
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-sato/puzzles/{puzzles_r10116.bb = puzzles_r10286.bb} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename meta/recipes-sato/puzzles/{puzzles_r10116.bb = puzzles_r10286.bb}
(100%)
diff --git a/meta/recipes-sato/puzzles/puzzles_r10116.bb
b/meta/recipes-sato/puzzles/puzzles_r10286.bb
similarity index 100%
rename from meta/recipes-sato/puzzles/puzzles_r10116.bb
rename to meta/recipes-sato/puzzles/puzzles_r10286.bb
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCHv2] xserver-nodm: Support reboot from inside X
From: Ricardo Ribalda Delgado ricardo.riba...@gmail.com If reboot was called from inside the Xserver there could happen a race condition where chvt would never end, and therefore the whole system was stalled. The user could not recover the system by ssh the machine or using the keyboard. Running chvt in background fixes the issue. Also move sleep 1s inside stop to give time for killproc xinit for fix issue when chvt 1 don't work because X server is still running. Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com Signed-off-by: Aníbal Limón anibal.li...@linux.intel.com --- meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm b/meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm index 2e3e090..bfa0a8d 100755 --- a/meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm +++ b/meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm @@ -48,12 +48,12 @@ case $1 in stop) echo Stopping XServer killproc xinit -chvt 1 +sleep 1 +chvt 1 ;; restart) $0 stop -sleep 1 $0 start ;; -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] xserver-xorg: Upgrade 1.16.3 - 1.17.1 (OELAYOUT_ABI change)
* Increase OELAYOUT_ABI: this is required because the
xf86-video-modesetting package moves from its own recipe to
xserver-xorg and sanity check cannot handle that currently.
The upgrade will delete old xf86-video-modesetting files from
sysroots.
* Remove upstreamed xserver-xorg patches
* Remove xf86-video-modesetting recipe: the driver is now included in
xserver-xorg recipe, which now produces the xf86-video-modesetting
package. The package version changes from 0.9 to 1.17.1
* Update xserver-xorg license checksum: modesetting license
info (another MIT one) has been added to the file
Signed-off-by: Jussi Kukkonen jussi.kukko...@intel.com
---
meta-yocto/conf/distro/poky.conf | 2 +-
meta/classes/sanity.bbclass| 6 +
meta/conf/abi_version.conf | 2 +-
.../xorg-driver/xf86-video-modesetting_0.9.0.bb| 8 --
.../recipes-graphics/xorg-xserver/xserver-xorg.inc | 9 +-
...Check-strings-length-against-request-size.patch | 145 -
...wap-XkbSetGeometry-data-in-the-input-buff.patch | 109
.../Fix-subwindow-in-Xi-emulated-events.patch | 41 --
.../xserver-xorg/xshmfence-option.patch| 57
...erver-xorg_1.16.3.bb = xserver-xorg_1.17.1.bb} | 8 +-
10 files changed, 17 insertions(+), 370 deletions(-)
delete mode 100644
meta/recipes-graphics/xorg-driver/xf86-video-modesetting_0.9.0.bb
delete mode 100644
meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-xkb-Check-strings-length-against-request-size.patch
delete mode 100644
meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-xkb-Don-t-swap-XkbSetGeometry-data-in-the-input-buff.patch
delete mode 100644
meta/recipes-graphics/xorg-xserver/xserver-xorg/Fix-subwindow-in-Xi-emulated-events.patch
delete mode 100644
meta/recipes-graphics/xorg-xserver/xserver-xorg/xshmfence-option.patch
rename meta/recipes-graphics/xorg-xserver/{xserver-xorg_1.16.3.bb =
xserver-xorg_1.17.1.bb} (74%)
diff --git a/meta-yocto/conf/distro/poky.conf b/meta-yocto/conf/distro/poky.conf
index 94de6e8..b47325d 100644
--- a/meta-yocto/conf/distro/poky.conf
+++ b/meta-yocto/conf/distro/poky.conf
@@ -91,7 +91,7 @@ BB_SIGNATURE_HANDLER ?= 'OEBasicHash'
# that breaks the format and have been previously discussed on the mailing
list
# with general agreement from the core team.
#
-OELAYOUT_ABI = 10
+OELAYOUT_ABI = 11
# add poky sanity bbclass
INHERIT += poky-sanity
diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index 839f7ce..c46a073 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -536,6 +536,12 @@ def sanity_handle_abichanges(status, d):
sstate_clean_manifest(f, d)
with open(abifile, w) as f:
f.write(current_abi)
+elif abi == 10 and current_abi == 11:
+bb.note(Converting staging layout from version 10 to layout
version 11)
+# Files in xf86-video-modesetting moved to xserver-xorg and
bitbake can't currently handle that:
+subprocess.call(d.expand(rm
${TMPDIR}/sysroots/*/usr/lib/xorg/modules/drivers/modesetting_drv.so
${TMPDIR}/sysroots/*/pkgdata/runtime/xf86-video-modesetting*
${TMPDIR}/sysroots/*/pkgdata/runtime-reverse/xf86-video-modesetting*
${TMPDIR}/sysroots/*/pkgdata/shlibs2/xf86-video-modesetting*), shell=True)
+with open(abifile, w) as f:
+f.write(current_abi)
elif (abi != current_abi):
# Code to convert from one ABI to another could go here if
possible.
status.addresult(Error, TMPDIR has changed its layout version
number (%s to %s) and you need to either rebuild, revert or adjust it at your
own risk.\n % (abi, current_abi))
diff --git a/meta/conf/abi_version.conf b/meta/conf/abi_version.conf
index 2867850..a829687 100644
--- a/meta/conf/abi_version.conf
+++ b/meta/conf/abi_version.conf
@@ -4,4 +4,4 @@
# that breaks the format and have been previously discussed on the mailing
list
# with general agreement from the core team.
#
-OELAYOUT_ABI = 10
+OELAYOUT_ABI = 11
diff --git a/meta/recipes-graphics/xorg-driver/xf86-video-modesetting_0.9.0.bb
b/meta/recipes-graphics/xorg-driver/xf86-video-modesetting_0.9.0.bb
deleted file mode 100644
index b220787..000
--- a/meta/recipes-graphics/xorg-driver/xf86-video-modesetting_0.9.0.bb
+++ /dev/null
@@ -1,8 +0,0 @@
-require xorg-driver-video.inc
-LIC_FILES_CHKSUM = file://COPYING;md5=5e53d3fcadb1c23d122ad63cb099a918
-
-SUMMARY = X.Org X server -- modesetting display driver
-DESCRIPTION = Provides a generic kernel modesetting display driver for the
X.Org X server.
-
-SRC_URI[md5sum] = da588d4f54111c2deae035998058ce10
-SRC_URI[sha256sum] =
90cf085573203dfadd48ea69bd694c4d04ccbe088b6855e9c85c34bb8a95d75c
diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
index cc95da6..04289f8 100644
---
[OE-core] [PATCH 1/2] sanity.bbclass: import subprocess in correct function
check_sanity() no longer needs the subprocess module but
sanity_handle_abichanges() does use subprocess.call().
Signed-off-by: Jussi Kukkonen jussi.kukko...@intel.com
---
meta/classes/sanity.bbclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index fc8c980..839f7ce 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -491,6 +491,8 @@ def sanity_handle_abichanges(status, d):
#
# Check the 'ABI' of TMPDIR
#
+import subprocess
+
current_abi = d.getVar('OELAYOUT_ABI', True)
abifile = d.getVar('SANITY_ABIFILE', True)
if os.path.exists(abifile):
@@ -824,8 +826,6 @@ def check_sanity_everybuild(status, d):
status.addresult(Error, IMAGE_FSTYPES vmdk and live can't be built
together\n)
def check_sanity(sanity_data):
-import subprocess
-
class SanityStatus(object):
def __init__(self):
self.messages =
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/2] xserver-xorg upgrade
The last commit does three things:
* removes xf86-video-modesetting recipe
* upgrades xserver-xorg (which now includes modesetting driver)
* updates OELAYOUT_ABI (to avoid sanity check freaking out from the
previous two)
The combination seems logically atomic to me but let me know if I should
divide it into separate commits instead.
Also, I'm not totally familiar with the tmp/sysroots/ layout so would
appreciate advice on the sanity.bbclass changes.
First commit fixes a sanity.bbclass bug that would be triggered by the
actual patch.
I've tested the ABI upgrade to the best of my ability (including wiping
tmp/, building an image from master, then building this branch).
The following changes since commit 16caaabfcc678b03a0cd88aaeac15f9b8d1c3dad:
bitbake: bitbake-user-manual-customization.xsl: Pointing to mirrors for XSL
files. (2015-05-19 22:09:36 +0100)
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib jku/xorg
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=jku/xorg
Jussi Kukkonen (2):
sanity.bbclass: import subprocess in correct function
xserver-xorg: Upgrade 1.16.3 - 1.17.1 (OELAYOUT_ABI change)
meta-yocto/conf/distro/poky.conf | 2 +-
meta/classes/sanity.bbclass| 10 +-
meta/conf/abi_version.conf | 2 +-
.../xorg-driver/xf86-video-modesetting_0.9.0.bb| 8 --
.../recipes-graphics/xorg-xserver/xserver-xorg.inc | 9 +-
...Check-strings-length-against-request-size.patch | 145 -
...wap-XkbSetGeometry-data-in-the-input-buff.patch | 109
.../Fix-subwindow-in-Xi-emulated-events.patch | 41 --
.../xserver-xorg/xshmfence-option.patch| 57
...erver-xorg_1.16.3.bb = xserver-xorg_1.17.1.bb} | 8 +-
10 files changed, 19 insertions(+), 372 deletions(-)
delete mode 100644
meta/recipes-graphics/xorg-driver/xf86-video-modesetting_0.9.0.bb
delete mode 100644
meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-xkb-Check-strings-length-against-request-size.patch
delete mode 100644
meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-xkb-Don-t-swap-XkbSetGeometry-data-in-the-input-buff.patch
delete mode 100644
meta/recipes-graphics/xorg-xserver/xserver-xorg/Fix-subwindow-in-Xi-emulated-events.patch
delete mode 100644
meta/recipes-graphics/xorg-xserver/xserver-xorg/xshmfence-option.patch
rename meta/recipes-graphics/xorg-xserver/{xserver-xorg_1.16.3.bb =
xserver-xorg_1.17.1.bb} (74%)
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] xserver-xorg: Upgrade 1.16.3 - 1.17.1 (OELAYOUT_ABI change)
On 20 May 2015 at 20:11, Jussi Kukkonen jussi.kukko...@intel.com wrote: -LIC_FILES_CHKSUM = file://COPYING;md5=15b5bf9327341c81089137aec4830bfd +LIC_FILES_CHKSUM = file://COPYING;md5=5df87950af51ac2c5822094553ea1880 When this happens please explain what the change was, to demonstrate that you've verified that xserver wasn't relicensed to GPLv3. :) I'll look at the rest in a minute... Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] zlib: clean up base_libdir symlink
libz.so symbolic link created in ${libdir} is
../../${base_libdir}/libz.so.1.2.8. This doesn't work if base_libdir or libdir
is changed, so use oe.path.relative to construct the correct path at build time.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-core/zlib/zlib_1.2.8.bb | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/meta/recipes-core/zlib/zlib_1.2.8.bb
b/meta/recipes-core/zlib/zlib_1.2.8.bb
index ca0ba3f..9470adb 100644
--- a/meta/recipes-core/zlib/zlib_1.2.8.bb
+++ b/meta/recipes-core/zlib/zlib_1.2.8.bb
@@ -6,7 +6,6 @@ SECTION = libs
LICENSE = Zlib
LIC_FILES_CHKSUM =
file://zlib.h;beginline=4;endline=23;md5=fde612df1e5933c428b73844a0c494fd
-
SRC_URI = http://www.zlib.net/${BPN}-${PV}.tar.xz \
file://remove.ldconfig.call.patch \
file://Makefile-runtests.patch \
@@ -45,16 +44,15 @@ do_install_ptest() {
install ${B}/minigzipsh ${D}${PTEST_PATH}
}
-# We move zlib shared libraries for target builds to avoid
-# qa warnings.
-#
+# Move zlib shared libraries for target builds to $base_libdir so the library
+# can be used in early boot before $prefix is mounted.
do_install_append_class-target() {
if [ ${base_libdir} != ${libdir} ]
then
mkdir -p ${D}/${base_libdir}
mv ${D}/${libdir}/libz.so.* ${D}/${base_libdir}
- tmp=`readlink ${D}/${libdir}/libz.so`
- ln -sf ../../${base_libdir}/$tmp ${D}/${libdir}/libz.so
+ libname=`readlink ${D}/${libdir}/libz.so`
+ ln -sf ${@oe.path.relative(${libdir},
${base_libdir})}/$libname ${D}${libdir}/libz.so
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 0/6] Remove unsupported GStreamer 0.10
On 18 May 2015 at 14:58, Alexander Kanavin alexander.kana...@linux.intel.com wrote: These patches remove the unsupported GStreamer 0.10 framework from oe-core. GStreamer 0.10 will still be available from meta-oe, but is no longer recommended to use. Can you send a follow-up patch to poky@ to remove the deleted recipes from the tracking files in meta-yocto/conf/distro/*.inc? Thanks, Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH][V3] mmc-utils: fix the building failure when DEBUG_BUILD is 1
ping
-Roy
On 2015年05月13日 08:14, rongqing...@windriver.com wrote:
From: Roy Li rongqing...@windriver.com
AM_CFLAGS in Makefile includes -D_FORTIFY_SOURCE=2 which will lead
to building failure when DEBUG_BUILD is 1.
So Redefine AM_CFLAGS, input it from the environment to overrides
variable in makefile
Signed-off-by: Roy Li rongqing...@windriver.com
---
meta/recipes-devtools/mmc/mmc-utils_git.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-devtools/mmc/mmc-utils_git.bb
b/meta/recipes-devtools/mmc/mmc-utils_git.bb
index bdb4fed..d6d77d9 100644
--- a/meta/recipes-devtools/mmc/mmc-utils_git.bb
+++ b/meta/recipes-devtools/mmc/mmc-utils_git.bb
@@ -11,6 +11,8 @@ PV = 0.1
SRC_URI =
git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc-utils.git;branch=${BRANCH}
\
file://0001-mmc.h-don-t-include-asm-generic-int-ll64.h.patch
+EXTRA_OEMAKE = 'AM_CFLAGS=-D_FILE_OFFSET_BITS=64'
+
S = ${WORKDIR}/git
do_install() {
--
Best Reagrds,
Roy | RongQing Li
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] meta-gir issues and maintenance
I forked meta-gir to https://github.com/locust2001/meta-gir and start working from next week. -Original Message- From: Andreas Müller [mailto:schnitzelt...@googlemail.com] Sent: Monday, May 18, 2015 8:46 PM To: Burton, Ross Cc: Changhyeok Bae; OE-core Subject: Re: [OE-core] meta-gir issues and maintenance On Mon, May 18, 2015 at 1:00 PM, Burton, Ross ross.bur...@intel.com wrote: On 18 May 2015 at 09:00, Andreas Müller schnitzelt...@googlemail.com wrote: I would appreciate to have the gintrospection more central - this would give us a chance to get the gtk stuff out of stone age.. Well, oe-core already has GTK+ 3, so we're just missing the bindings to Python and JavaScript. Sorry - I meant gnome not gtk. Changhyeok, you're welcome to fork meta-gir to your own repository and work on it independently. If you can update it so that it works with oe-core master then you're the new maintainer. :) Andreas This email has been protected by YAC (Yet Another Cleaner) http://www.yac.mx -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] toolchain-scripts.bbclass: fix quoting for CCACHE_PATH
Single quotes prevent expansion of $sdkpathnative$bindir.
Signed-off-by: Andre McCurdy armccu...@gmail.com
---
fido needs the fix too.
meta/classes/toolchain-scripts.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/toolchain-scripts.bbclass
b/meta/classes/toolchain-scripts.bbclass
index 670e93b..9918e2e 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -22,7 +22,7 @@ toolchain_create_sdk_env_script () {
EXTRAPATH=$EXTRAPATH:$sdkpathnative$bindir/${TARGET_ARCH}${TARGET_VENDOR}-$i
done
echo export
PATH=$sdkpathnative$bindir:$sdkpathnative$bindir/${TARGET_SYS}$EXTRAPATH':$PATH'
$script
- echo 'export
CCACHE_PATH=$sdkpathnative$bindir:$sdkpathnative$bindir/${TARGET_SYS}'$EXTRAPATH':$CCACHE_PATH'
$script
+ echo export
CCACHE_PATH=$sdkpathnative$bindir:$sdkpathnative$bindir/${TARGET_SYS}$EXTRAPATH':$CCACHE_PATH'
$script
echo 'export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT' $script
echo 'export PKG_CONFIG_PATH=$SDKTARGETSYSROOT'$libdir'/pkgconfig'
$script
echo 'export
CONFIG_SITE=${SDKPATH}/site-config-'${multimach_target_sys} $script
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] busybox: passwd: applet not found
On 20 May 2015 at 16:02, Laszlo Papp lp...@kde.org wrote: On a second thought: is even worse now than that, our code has to handle _three_ different scenarios: 1) Desktop. 2) Embedded without Yocto or embedded with old Yocto. 3) Embedded with new Yocto. I do not get excited about this. Do as the documentation says in your distro and you have one scenario. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] busybox: passwd: applet not found
On Wed, May 20, 2015 at 4:07 PM, Burton, Ross ross.bur...@intel.com wrote: On 20 May 2015 at 16:02, Laszlo Papp lp...@kde.org wrote: On a second thought: is even worse now than that, our code has to handle _three_ different scenarios: 1) Desktop. 2) Embedded without Yocto or embedded with old Yocto. 3) Embedded with new Yocto. I do not get excited about this. Do as the documentation says in your distro and you have one scenario. That means compromising security. I am now looking for the ideal case in the future. What is wrong about dropping the privileges in busybox for undedicated processes without creating this separation? That would combine the convenience with security, wouldn't it? -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] busybox: passwd: applet not found
[Cc'ing Chen who invented it for the most part] On 20 May 2015 at 17:02, Laszlo Papp lp...@kde.org wrote: On Wed, May 20, 2015 at 3:58 PM, Laszlo Papp lp...@kde.org wrote: On Wed, May 20, 2015 at 3:54 PM, Burton, Ross ross.bur...@intel.com wrote: On 20 May 2015 at 15:50, Laszlo Papp lp...@kde.org wrote: Currently, I do not see any simple way without #ifdef jungle in the code around to it. It is not nice. Looking at the busybox recipe reveals this: # Whether to split the suid apps into a seperate binary BUSYBOX_SPLIT_SUID ?= 1 Just remember that the suid apps were being split out for good security reasons. There's no need for sed to have suid rights! The suid rights are dropped before sed_main is entered, so the potential window is very, very small and the affected code is pretty well understood. But we had that argument numerous times and certain users don't follow it. I will not argue about security measure improvements as I agree about them with you. However, I will debate the way this security measure is implemented. It is distraction from the desktop world where you can also use busybox and many use. Now, all of a sudden, we have to handle them differently in code and scripts. I think a less intrusive approach to implement this could have been (and probably still not late) is to fix the rights underneath and not Can you elaborate what you imagine above? by such wrappers. Such wrappers will introduce this disruption which is not strictly needed. Well, you could say that if desktop distributions also implement it like this, then there is no disruption, but I think that is never going to happen if busybox itself does not enforce it. I think this is not a good implementation for security to remain consistent with the rest of the world. Could it be please reconsidered towards another solutions? It is also good if one call tell me how to solve this differentiation between desktop and Yocto without further code. On a second thought: is even worse now than that, our code has to handle _three_ different scenarios: 1) Desktop. 2) Embedded without Yocto or embedded with old Yocto. 3) Embedded with new Yocto. I do not get excited about this. Just don't set the SPLIT thing and all is well again. Or set CONFIG_FEATURE_INDIVIDUAL so you get a shared libbusybox with a gazillion small binaries linked to that. Not a fancy thing to do, granted. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] e2fsprogs: add expansion of mkdir_p to configure.in
On 20 May 2015 at 08:37, Chuang Dong chuang.d...@windriver.com wrote: ++AC_SUBST([mkdir_p], ['$(MKDIR_P)']) If the recipe is using mkdir_p then the configure.ac should be calling AM_PROG_MKDIR_P, surely. It's not, and I've verified that adding it causes the variables to be defined correctly. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] busybox: passwd: applet not found
On 20 May 2015 at 17:09, Laszlo Papp lp...@kde.org wrote: On Wed, May 20, 2015 at 4:07 PM, Burton, Ross ross.bur...@intel.com wrote: On 20 May 2015 at 16:02, Laszlo Papp lp...@kde.org wrote: On a second thought: is even worse now than that, our code has to handle _three_ different scenarios: 1) Desktop. 2) Embedded without Yocto or embedded with old Yocto. 3) Embedded with new Yocto. I do not get excited about this. Do as the documentation says in your distro and you have one scenario. That means compromising security. I am now looking for the ideal case in the future. What is wrong about dropping the privileges in busybox for undedicated processes without creating this separation? That would combine the convenience with security, wouldn't it? We already do that. Since June 2002. version 0.60.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] busybox: passwd: applet not found
On Wed, May 20, 2015 at 4:17 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On 20 May 2015 at 17:09, Laszlo Papp lp...@kde.org wrote: On Wed, May 20, 2015 at 4:07 PM, Burton, Ross ross.bur...@intel.com wrote: On 20 May 2015 at 16:02, Laszlo Papp lp...@kde.org wrote: On a second thought: is even worse now than that, our code has to handle _three_ different scenarios: 1) Desktop. 2) Embedded without Yocto or embedded with old Yocto. 3) Embedded with new Yocto. I do not get excited about this. Do as the documentation says in your distro and you have one scenario. That means compromising security. I am now looking for the ideal case in the future. What is wrong about dropping the privileges in busybox for undedicated processes without creating this separation? That would combine the convenience with security, wouldn't it? We already do that. Since June 2002. version 0.60.4 Then I cannot understand the incompatible change. If the privilege is dropped early and the code is well-understood, then what exactly was being solved in here for the price of incompatibility and more complex environments across projects? But in any case, if BUSYBOX_SPLIT_SUID=0 helps me with being compatible while it still drops the privileges properly as intended by busybox upstream, I guess I can go for that. I am yet to understand the certain users do not follow it part. What exactly? -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] midori: fix build with GLib 2.44
On 05/19/2015 10:40 PM, Ross Burton wrote: GLib 2.44 introduced a GListStore type which is ambiguous with GtkListStore when using wildcard using statements. Use the full type name to fix builds. Midori is already at 0.5.10 upstream; if it's compatible with the webkit currently in oe-core, maybe it's better to update to the latest version? When the new webkit patches are ready, I'll definitely pull in the latest midori as well. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] zlib: minor symbolic link issue
On 20 May 2015 at 10:47, Matthieu CRAPET matthieu.cra...@ingenico.com
wrote:
Just tell me if something is wrong, I can provide a v2 patch.
No, it just slipped through the cracks.
That regex looked a bit obscure, and there's a Python function we provide
that uses the Python standard library to do the same thing, so I ended up
with this locally:
# Move zlib shared libraries for target builds to $base_libdir so the
library
# can be used in early boot before $prefix is mounted.
do_install_append_class-target() {
if [ ${base_libdir} != ${libdir} ]
then
mkdir -p ${D}/${base_libdir}
mv ${D}/${libdir}/libz.so.* ${D}/${base_libdir}
libname=`readlink ${D}/${libdir}/libz.so`
ln -sf ${@oe.path.relative(${libdir}, ${base_libdir})}/$libname
${D}${libdir}/libz.so
fi
}
Do you have any objections to this form instead? I'm also thinking we
should rationalise the duplicated logic into a single implementation in
meta/classes/utils.bbclass...
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] busybox: passwd: applet not found
On 20 May 2015 at 15:42, Laszlo Papp lp...@kde.org wrote: Now that just breaks all the code that our software is using. Why did this binary incompatible change sneak in, and especially: why without any note in the migration guide? Furthermore, is there a way to reverse this? I really would like to avoid rewriting my code just because some other people think it is a cool change. Or is this change absolutely necessary? The point was to not give normal applets such as cat suid rights. Why can't your scripts just call passwd directly instead of proxying through busybox? Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] busybox: passwd: applet not found
On Wed, May 20, 2015 at 3:45 PM, Burton, Ross ross.bur...@intel.com wrote: On 20 May 2015 at 15:42, Laszlo Papp lp...@kde.org wrote: Now that just breaks all the code that our software is using. Why did this binary incompatible change sneak in, and especially: why without any note in the migration guide? Furthermore, is there a way to reverse this? I really would like to avoid rewriting my code just because some other people think it is a cool change. Or is this change absolutely necessary? The point was to not give normal applets such as cat suid rights. Why can't your scripts just call passwd directly instead of proxying through busybox? If busybox is available on desktop, I would like to call the busybox applet through 'busybox appletname'. If I just call passwd, I will call the desktop version. That is not what I want and this is not how it has so far worked. I think this feature should have been at least optional and if it has to break, it is definitely something to document in the migration guide, isn't it? Currently, I do not see any simple way without #ifdef jungle in the code around to it. It is not nice. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] busybox: passwd: applet not found
On Wed, May 20, 2015 at 3:58 PM, Laszlo Papp lp...@kde.org wrote: On Wed, May 20, 2015 at 3:54 PM, Burton, Ross ross.bur...@intel.com wrote: On 20 May 2015 at 15:50, Laszlo Papp lp...@kde.org wrote: Currently, I do not see any simple way without #ifdef jungle in the code around to it. It is not nice. Looking at the busybox recipe reveals this: # Whether to split the suid apps into a seperate binary BUSYBOX_SPLIT_SUID ?= 1 Just remember that the suid apps were being split out for good security reasons. There's no need for sed to have suid rights! I will not argue about security measure improvements as I agree about them with you. However, I will debate the way this security measure is implemented. It is distraction from the desktop world where you can also use busybox and many use. Now, all of a sudden, we have to handle them differently in code and scripts. I think a less intrusive approach to implement this could have been (and probably still not late) is to fix the rights underneath and not by such wrappers. Such wrappers will introduce this disruption which is not strictly needed. Well, you could say that if desktop distributions also implement it like this, then there is no disruption, but I think that is never going to happen if busybox itself does not enforce it. I think this is not a good implementation for security to remain consistent with the rest of the world. Could it be please reconsidered towards another solutions? It is also good if one call tell me how to solve this differentiation between desktop and Yocto without further code. On a second thought: is even worse now than that, our code has to handle _three_ different scenarios: 1) Desktop. 2) Embedded without Yocto or embedded with old Yocto. 3) Embedded with new Yocto. I do not get excited about this. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] busybox: passwd: applet not found
On Wed, May 20, 2015 at 3:05 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On 20 May 2015 at 15:48, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On 20 May 2015 at 13:55, Laszlo Papp lp...@kde.org wrote: Hi, I am a bit confused why busybox passwd does not work with daisy. It used to work with dylan. When I try to use busybox passwd, I am getting the following output: passwd: applet not found is the password applet built? Check your busybox .config. Is passwd listed when you invoke plain busybox and have the help-text printing turned on? Sometimes code around bsearch is miscompiled but this should not be the case for your setup, i suppose. ah, the great suid / nosuid split ? try /bin/busybox.suid passwd instead, the default /bin/busybox supposedly points to the .nosuid binary. Now that just breaks all the code that our software is using. Why did this binary incompatible change sneak in, and especially: why without any note in the migration guide? Furthermore, is there a way to reverse this? I really would like to avoid rewriting my code just because some other people think it is a cool change. Or is this change absolutely necessary? -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] package_rpm.bbclass : escape % in files and directories name
From: Sébastien Mennetrier smennetr...@voxtok.com
The rpm process replace all the %name in the spec file by the name of
the package. So, if the package is composed of some files or directories
named %name..., the rpm package process failed.
Replace all % present in files or directories names by to
correctly escape %.
Signed-off-by: Sébastien Mennetrier smennetr...@voxtok.com
Signed-off-by: Michaël Burtin mbur...@voxtok.com
---
meta/classes/package_rpm.bbclass | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index e305e8b..3e8ae3d 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -196,6 +196,7 @@ python write_specfile () {
path = rootpath.replace(walkpath, )
if path.endswith(DEBIAN) or path.endswith(CONTROL):
continue
+path = path.replace(%, )
# Treat all symlinks to directories as normal files.
# os.walk() lists them as directories.
@@ -214,6 +215,7 @@ python write_specfile () {
for dir in dirs:
if dir == CONTROL or dir == DEBIAN:
continue
+dir = dir.replace(%, )
# All packages own the directories their files are in...
target.append('%dir ' + path + '/' + dir + '')
else:
@@ -227,6 +229,7 @@ python write_specfile () {
for file in files:
if file == CONTROL or file == DEBIAN:
continue
+file = file.replace(%, )
if conffiles.count(path + '/' + file):
target.append('%config ' + path + '/' + file + '')
else:
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] busybox: passwd: applet not found
On 20 May 2015 at 15:50, Laszlo Papp lp...@kde.org wrote: Currently, I do not see any simple way without #ifdef jungle in the code around to it. It is not nice. Looking at the busybox recipe reveals this: # Whether to split the suid apps into a seperate binary BUSYBOX_SPLIT_SUID ?= 1 Just remember that the suid apps were being split out for good security reasons. There's no need for sed to have suid rights! Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] busybox: passwd: applet not found
On Wed, May 20, 2015 at 3:54 PM, Burton, Ross ross.bur...@intel.com wrote: On 20 May 2015 at 15:50, Laszlo Papp lp...@kde.org wrote: Currently, I do not see any simple way without #ifdef jungle in the code around to it. It is not nice. Looking at the busybox recipe reveals this: # Whether to split the suid apps into a seperate binary BUSYBOX_SPLIT_SUID ?= 1 Just remember that the suid apps were being split out for good security reasons. There's no need for sed to have suid rights! I will not argue about security measure improvements as I agree about them with you. However, I will debate the way this security measure is implemented. It is distraction from the desktop world where you can also use busybox and many use. Now, all of a sudden, we have to handle them differently in code and scripts. I think a less intrusive approach to implement this could have been (and probably still not late) is to fix the rights underneath and not by such wrappers. Such wrappers will introduce this disruption which is not strictly needed. Well, you could say that if desktop distributions also implement it like this, then there is no disruption, but I think that is never going to happen if busybox itself does not enforce it. I think this is not a good implementation for security to remain consistent with the rest of the world. Could it be please reconsidered towards another solutions? It is also good if one call tell me how to solve this differentiation between desktop and Yocto without further code. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
