[OE-core] oe-init-build-env slowdown: chmod -R

[Patrick Ohly]

Hello!

The following commit introduced a "chmod -R -st" on the build dir:

commit f0d3587706fffdcc1c708013f6d6ce296dfc5f24
Author: Alex Franco 
Date:   Fri Aug 28 17:34:04 2015 -0500

Fix mode +st on TMPDIR when creating it

A sanity check fails when TMPDIR has setuid, setgid set. It was
proposed to fix this on TMPDIR creation instead of failing with
a sanity test only. This patch handles removal of those special
bits (and additonally, the sticky bit) from BUILDDIR and TMPDIR
when these directories are created.

In my case (*), that chmod takes about 2 minutes to complete. strace
shows that it does a fchmodat on all files, even if nothing needs to be
changed. atop then shows that this keeps the disk 100% busy with writes.
I don't know what gets written (can't be the access time, I tried
mounting with noatime).

Are others seeing the same behavior? I can't rule out that my disk is
just slow due to fragmentation.

The following commands work much better for me. I can submit a patch if
others see the same thing.

find . -perm /+st -print0 | xargs -0 --no-run-if-empty chmod -st


(*) Debian 8, Linux 3.16.0-4-amd64, coreutils 8.23-4, ext4 on a SATA
hard disk.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/1] pseudo_1.7.2.bb: New version of pseudo

[Peter Seebach]

Pseudo 1.7 adds an experimental feature (which I think needs more testing
before it becomes the default) allowing the pseudo client to store modes
and uid/gid values in extended attributes rather than using the sqlite
database. On most Linux-like systems, this works only if the underlying
file is a plain file or a directory.

Also added is a profiling feature to allow some amount of reporting on
the wall-clock time the client spends in wrappers, processing operations,
or in IPC. This feature is not intendeded to be precisely accurate, but
gives a good overview of where time is going.

Based on the results from the profiling feature, the client now suppresses
OP_OPEN and OP_EXEC messages if the server is not logging messages, and
no longer uses constant dynamic allocation and free cycles for canonicalized
paths.

There's a few other likely-looking optimizations being considered, but
this seemed like a good cutoff for now.

1.7.1 fixes two bugs, one affecting mostly XFS systems with 64-bit
inode values, and one affecting code that called realpath(x, NULL), such
as the RPM backend.

1.7.2 fixes an indirect side-effect of the chmod fixes to deal with
umask 0700, which had no effect with opkg 0.2.4 but appears to cause
failures with 0.3.0.

Signed-off-by: Peter Seebach 
---
 meta/recipes-devtools/pseudo/pseudo_1.7.2.bb | 19 +++
 meta/recipes-devtools/pseudo/pseudo_git.bb   |  4 ++--
 2 files changed, 21 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-devtools/pseudo/pseudo_1.7.2.bb

diff --git a/meta/recipes-devtools/pseudo/pseudo_1.7.2.bb 
b/meta/recipes-devtools/pseudo/pseudo_1.7.2.bb
new file mode 100644
index 000..57704a2
--- /dev/null
+++ b/meta/recipes-devtools/pseudo/pseudo_1.7.2.bb
@@ -0,0 +1,19 @@
+require pseudo.inc
+
+SRC_URI = " \
+http://downloads.yoctoproject.org/releases/pseudo/${BPN}-${PV}.tar.bz2 \
+file://fallback-passwd \
+file://fallback-group \
+"
+
+SRC_URI[md5sum] = "a293a0b38fca6efc9313af24a7cfa369"
+SRC_URI[sha256sum] = 
"f0c4fbd7b19622648bfee66bdfcbfc66de6e63d3ec601ca1922b1839143a2f11"
+
+PSEUDO_EXTRA_OPTS ?= "--enable-force-async --without-passwd-fallback"
+
+do_install_append_class-native () {
+   install -d ${D}${sysconfdir}
+   # The fallback files should never be modified
+   install -m 444 ${WORKDIR}/fallback-passwd ${D}${sysconfdir}/passwd
+   install -m 444 ${WORKDIR}/fallback-group ${D}${sysconfdir}/group
+}
diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb 
b/meta/recipes-devtools/pseudo/pseudo_git.bb
index aa315d3..31e1223 100644
--- a/meta/recipes-devtools/pseudo/pseudo_git.bb
+++ b/meta/recipes-devtools/pseudo/pseudo_git.bb
@@ -1,7 +1,7 @@
 require pseudo.inc
 
-SRCREV = "db758fb11167c79d9682a17d359568e2a3c4acd5"
-PV = "1.6.5+git${SRCPV}"
+SRCREV = "e795df44a90a426a76b790f1b2774f3046a8fc31"
+PV = "1.7.2+git${SRCPV}"
 
 DEFAULT_PREFERENCE = "-1"
 
-- 
2.3.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/1] v3: pseudo 1.7.2

[Peter Seebach]

So the opkg uprev from 0.2.4 to 0.3.0 turns out to trip on a
change I thought would be harmless, but which was also unintentional-ish.

Historically, pseudo has just assumed no one will put 0700 in umask.
With xattrdb, this can break if you have 0700 in umask, and try to open
a file, because pseudo needs to be able to write to the file in order
to store extended attributes. And I spotted that, so I added manual
chmods in cases where a file mave have been created by an open.

But I used 0600 instead of the base mode | 0600, and this resulted in
losing execute bits in some cases. This was only in the base filesystem,
and normally real filesystem execute bits on things in the target filesystem
space don't matter. But opkg 0.3.0 is now doing
sh -c /path/to/postinst_script
and that fails if the script lacks 0100.

Whoops.

(The change there is why this didn't get caught in the previous 1.7.x
testing.)

The following changes since commit aba3ef50d65e0dc8659a48bf98d0fb00dd44a6fc:

  debianutils: create package for run-parts (2015-09-02 23:51:16 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib seebs/pseudo172
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=seebs/pseudo172

Peter Seebach (1):
  pseudo_1.7.2.bb: New version of pseudo

 meta/recipes-devtools/pseudo/pseudo_1.7.2.bb | 19 +++
 meta/recipes-devtools/pseudo/pseudo_git.bb   |  4 ++--
 2 files changed, 21 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-devtools/pseudo/pseudo_1.7.2.bb

-- 
2.3.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] pseudo_1.7.1.bb: New version of pseudo

[Peter Seebach]

On Thu, 3 Sep 2015 09:43:50 +0100
Richard Purdie  wrote:

> This is better however opkg is still unhappy. This is build with this
> pseudo patch applied:
> 
> https://autobuilder.yoctoproject.org/main/builders/nightly-ipk/builds/469

I've found the cause of that particular bit. During my attempts to reproduce
this, I ran into segfaults in cross-localedef that I cannot now reproduce.

The cause of this was fixing up filesystem modes for the case where umask
contains 0200, which wasn't originally expected to work, but which was
breaking the xattrdb code. (There are a few things in the system which create
files with umask 0777, it turns out; this is arguably bad, but now there's a
workaround.)

But when I put in the workaround, I used 0600 as the "definitely at least
these bits" mode, instead of the requested mode, and that breaks scripts
which were expecting, say, 0700. So the things which have a specified mode
now use that | 0600 instead of just 0600.

I want to run a couple more things to see whether I can get any of the other
failures to come back again.

I also partially know why I wasn't seeing this on one of my systems, but only
partially. When I do my builds on CentOS 6.5, the .postinst files in question
either don't come into existence, or get run successfully anyway. So far as
I can tell, opkg is doing "sh -c /path/to/script" on those, which requires
0700 to run. I'm not sure what's causing the difference between the hosts.

-s
-- 
Listen, get this.  Nobody with a good compiler needs to be justified.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/2] ifupdown: import recipe

[Slater, Joseph]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org 
> [mailto:openembedded-core-
> boun...@lists.openembedded.org] On Behalf Of Richard Purdie
> Sent: Thursday, September 03, 2015 2:39 PM
> To: Khem Raj
> Cc: Patches and discussions about the oe-core layer; Slater, Joseph; Otavio 
> Salvador
> Subject: Re: [OE-core] [oe-core][PATCH 1/2] ifupdown: import recipe
> 
> On Thu, 2015-09-03 at 14:15 -0700, Khem Raj wrote:
> > > On Sep 3, 2015, at 1:27 PM, Richard Purdie 
> > >  wrote:
> > >
> > > On Thu, 2015-09-03 at 13:22 -0700, Khem Raj wrote:
> > >> On Thu, Sep 3, 2015 at 5:20 AM, Bruce Ashfield 
> > >>  wrote:
> >  To put this another way, I think it is probably reasonable that we
> >  should be able to build an image from OE-Core with basic functionality
> >  like networking without busybox?
> > >>>
> > >>> That's what I'd support. If everything you need for the functionality 
> > >>> with busy
> > >>> box is in oe-core, to me, it doesn't make sense to go outside core to 
> > >>> get that
> > >>> same functionality without busybox.
> > >>
> > >> irrespective of this change. I see yet another configuration with this
> > >> into OE-core, overall OE-Core should get smaller
> > >> and case does not sound convincing to me. You dont want to use busybox
> > >> in a fairly large image which has other GPLv2 software in
> > >> it. Thats fine but doesnt look like a common usecase to me
> > >
> > > Nobody mentioned GPLv2, that isn't relevant here.
> >
> > I assumed thats one reason to not include it. I am trying to understand 
> > reasoning to
> > not include busybox. Or is is just because its a poster child for 
> > litigations.
> 
> The litigation issues surrounding it certainly don't do it any favours,
> but the main issue is that if busybox is there, we're not seen as a
> "proper/full" linux.
> 
> > > I have heard OE being dismissed since it can't produce an image without
> > > busybox in it. The implication is we can't build "big" Linux, only small
> > > embedded things. The pieces we need busybox for are tiny and should be
> > > easy to replace (like this does).
> >
> > as we include other alternative providers, they get preference over busybox 
> > applets
> > even if busybox is part of it.
> 
> The problem is some people don't want any busybox.
> 
> > > So I can see a fairly compelling argument for OE-Core to be able to
> > > generate a busybox free image with standard functionality just from a PR
> > > perspective. From what I gather we have people willing to test and
> > > maintain it too…
> >
> > PR I see. I was searching for technical reasons.
> 
> Well, its technical but related to the image of the project too. Can
> OE-Core today produce a "standard linux desktop" type "full" featured
> filesystem? I cannot honestly say it can due to this reason, busybox has
> to be there. There are some people who do discount OE because of this.
> This isn't new, I remember Marcin amongst others working on this. We're
> close, but close doesn't mean we can answer "yes" to the question and I
> think it would be nice to be able to do so clearly.

I think if we are trying to allow removing busybox, the functionality needed
should be in oe-core.  Thus, we pull run-parts out of debianutils (this is now
in oe-core, master), pull start-stop-daemon from dpkg (I sent a patch, but I 
have not seen
any action), and we add ifupdown.  shadow is there, as is util-linux-blkid.

Me?  I kind of like busybox, but I also think we should provide images without 
it.

Joe

> 
> Cheers,
> 
> Richard
> 
> --
> ___
> 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] scripts: Create interactive menu for mkefidisk script

[Saul Wold]

On 09/01/2015 12:22 PM, Bruno Bottazzini wrote:

If it is passed only the image parameter, it will show some interactive
options to help to conclude the script.

With this patch it will detect devices available in the machine, asking
to choose what it is wanted to be flashed.

it will suggest the target device. If it is a SD card the suggestion
is /dev/mmcblk0. If it is a pendrive it will suggest to use /dev/sda.



I am little concerned by this patch since it allows the root disk to be 
selected, even if someone can type it on the command line, but offering 
it in list would make someone believe that it was OK.




Signed-off-by: Bruno Bottazzini 
---
  scripts/contrib/mkefidisk.sh | 60 
  1 file changed, 55 insertions(+), 5 deletions(-)

diff --git a/scripts/contrib/mkefidisk.sh b/scripts/contrib/mkefidisk.sh
index 55f72b0..7628de7 100755
--- a/scripts/contrib/mkefidisk.sh
+++ b/scripts/contrib/mkefidisk.sh
@@ -152,8 +152,52 @@ unmount() {
  # Parse and validate arguments
  #
  if [ $# -lt 3 ] || [ $# -gt 4 ]; then
-   usage
-   exit 1
+if [ $# -eq 1 ]; then
+AVAILABLE_DISK=`fdisk -l | grep "Disk /" | cut -f 1 -d ':' | cut -f 2 
-d ' '`
+if [ -z "$AVAILABLE_DISK" ]; then
+die "Starting mkefidisk.sh as root is required"
+fi
+echo "Available disks are"
+X=0
+for line in `echo $AVAILABLE_DISK`; do
+info "$X - $line"
+X=`expr $X + 1`
+done
+read -p "Choose flashable device number: " DISK_NUMBER
+X=0
+for line in `echo $AVAILABLE_DISK`; do
+if [ $DISK_NUMBER -eq $X ]; then
+DISK_TO_BE_FLASHED=$line
+break
+else
+X=`expr $X + 1`
+fi
+done
+if [ -z "$DISK_TO_BE_FLASHED" ]; then
+die "Option \"$DISK_NUMBER\" is invalid. Choose a valid option"
+else
+if [ -z `echo $DISK_TO_BE_FLASHED | grep "mmc"` ]; then
+TARGET_TO_BE_BOOT="/dev/sda"
+else
+TARGET_TO_BE_BOOT="/dev/mmcblk0"
+fi
+fi
+echo ""
+echo "Choose a name of the device that will be boot from"
+echo -n "Recommended name is: "
+info "$TARGET_TO_BE_BOOT\n"

The \n usage is probably wrong here.


+read -p "Is target device okay? [y/N]: " RESPONSE
+if [ "$RESPONSE" != "y" ]; then
+read -p "Choose target device name: " TARGET_TO_BE_BOOT
+fi
+echo ""
+if [ -z "$TARGET_TO_BE_BOOT" ]; then
+die "Error: choose a valid target name"
+fi
+else
+usage
+   exit 1
+fi
  fi

  if [ "$1" = "-v" ]; then
@@ -162,9 +206,15 @@ if [ "$1" = "-v" ]; then
shift
  fi

-DEVICE=$1
-HDDIMG=$2
-TARGET_DEVICE=$3
+if [ -z "$AVAILABLE_DISK" ]; then
+DEVICE=$1
+HDDIMG=$2
+TARGET_DEVICE=$3
+else
+DEVICE=$DISK_TO_BE_FLASHED
+HDDIMG=$1
+TARGET_DEVICE=$TARGET_TO_BE_BOOT
+fi

  LINK=$(readlink $DEVICE)
  if [ $? -eq 0 ]; then


--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v3] devtool: add package plugin that lets you create package via devtool

[brendan . le . foll]

From: Brendan Le Foll 

Signed-off-by: Brendan Le Foll 
---
 scripts/lib/devtool/package.py | 61 ++
 1 file changed, 61 insertions(+)
 create mode 100644 scripts/lib/devtool/package.py

diff --git a/scripts/lib/devtool/package.py b/scripts/lib/devtool/package.py
new file mode 100644
index 000..e9d4240
--- /dev/null
+++ b/scripts/lib/devtool/package.py
@@ -0,0 +1,61 @@
+# Development tool - package command plugin
+#
+# Copyright (C) 2014-2015 Intel Corporation
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program; if not, write to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+"""Devtool plugin containing the package subcommands"""
+
+import os
+import subprocess
+import logging
+from bb.process import ExecutionError
+from devtool import exec_build_env_command, setup_tinfoil, DevtoolError
+
+logger = logging.getLogger('devtool')
+
+def plugin_init(pluginlist):
+"""Plugin initialization"""
+pass
+
+def package(args, config, basepath, workspace):
+"""Entry point for the devtool 'package' subcommand"""
+if not args.recipename in workspace:
+raise DevtoolError("no recipe named %s in your workspace" %
+   args.recipename)
+
+try:
+image_pkgtype = config.get('image_pkgtype', None)
+except:
+tinfoil = setup_tinfoil()
+try:
+tinfoil.prepare(config_only=True)
+image_pkgtype = tinfoil.config_data.getVar('IMAGE_PKGTYPE', True)
+finally:
+tinfoil.shutdown()
+
+package_task = config.get('Package', 'package_task', 'package_write_%s' % 
image_pkgtype)
+try:
+exec_build_env_command(config.init_path, basepath, 'bitbake -c %s %s' 
% (package_task, args.recipename), watch=True)
+except bb.process.ExecutionError as e:
+# We've already seen the output since watch=True, so just ensure we 
return something to the user
+return e.exitcode
+logger.info('Your packages are in %s/tmp/deploy/%s' % (basepath, 
image_pkgtype))
+
+return 0
+
+def register_commands(subparsers, context):
+"""Register devtool subcommands from the package plugin"""
+parser_package = subparsers.add_parser('package', help='Create packages 
for a recipe', description='Creates packages for a recipe\'s output files')
+parser_package.add_argument('recipename', help='Recipe to package')
+parser_package.set_defaults(func=package)
-- 
2.5.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/2] ifupdown: import recipe

[Phil Blundell]

On Thu, 2015-09-03 at 13:22 -0700, Khem Raj wrote:
> irrespective of this change. I see yet another configuration with this
> into OE-core, overall OE-Core should get smaller
> and case does not sound convincing to me. You dont want to use busybox
> in a fairly large image which has other GPLv2 software in
> it. Thats fine but doesnt look like a common usecase to me

In general, I don't think it is a good idea for oe-core to be entirely
beholden to busybox or any other package, and I would be all in favour
of including an alternative implementation for everything that we depend
on busybox for.

In the specific case of ifupdown, the whole thing seems a little bit
1990s and it's hard to avoid the sense that there are better ways to
solve that particular problem nowadays.  But oe-core does already
include net-tools, which is if anything even more retro (and is in a
similar position vis-a-vis busybox) so there is precedent for including
this kind of thing.

It's also not as if ifupdown is a large piece of software with a complex
web of ABI dependencies that will introduce some huge maintenance burden
in the future.  So I can't see any real downside to adding it to
oe-core.

p.


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] distutils.bbclass: Handle python-backport modules

[Alejandro Hernandez]

When installing backport modules they stumble upon each other, complaining with
the following error:

ERROR: The recipe python-backports-ssl is trying to install files into a shared
area when those files already exist.

This is the correct behavior since thats just the way they were designed, all 
backport
modules provide an __init__.py file (the same among all packages), and without 
it they
simply wouldnt work.

distutils handles FILES_${PN}* variables for python packages, but it uses 
wildcards
to include the required files, hence removing the __init__.py files from each 
backport
package during build time is impossible since it doenst actually contain that 
value,
this patch simply removes the __init__.py* files from the staging area if they 
already
exist on sysroot, this way, these are not included in FILES_${PN} anymore, 
fixing the
issue mentioned above.

[YOCTO #8207]

Signed-off-by: Alejandro Hernandez 
---
 meta/classes/distutils.bbclass | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/meta/classes/distutils.bbclass b/meta/classes/distutils.bbclass
index 2498685..82f93d8 100644
--- a/meta/classes/distutils.bbclass
+++ b/meta/classes/distutils.bbclass
@@ -44,7 +44,6 @@ distutils_do_install() {
 # support filenames with *spaces*
 # only modify file if it contains path  and recompile it
 find ${D} -name "*.py" -exec grep -q ${D} {} \; -exec sed -i -e 
s:${D}::g {} \; -exec ${STAGING_BINDIR_NATIVE}/python-native/python 
-mcompileall {} \;
-
 if test -e ${D}${bindir} ; then
 for i in ${D}${bindir}/* ; do \
 if [ ${PN} != "${BPN}-native" ]; then
@@ -73,6 +72,13 @@ distutils_do_install() {
 mv -f ${D}${datadir}/share/* ${D}${datadir}/
 rmdir ${D}${datadir}/share
 fi
+   
+   
+   if [ -e 
${STAGING_LIBDIR}/${PYTHON_DIR}/site-packages/backports/__init__.py ]; then
+   rm ${D}${PYTHON_SITEPACKAGES_DIR}/backports/__init__.py;
+   rm ${D}${PYTHON_SITEPACKAGES_DIR}/backports/__init__.pyc;
+   #FILES_${PN}_remove = 
"${PYTHON_SITEPACKAGES_DIR}/backports/__init__.pyc";
+   fi
 }
 
 EXPORT_FUNCTIONS do_compile do_install
-- 
1.8.4.5

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCHv4] Fix recursive mode -st on BUILDDIR setup

[Alex Franco]

Removing recursive option from chmod -st on BUILDDIR as it would
take very long on existing build directories

[YOCTO #7669]

Signed-off-by: Alex Franco 
---
 meta/classes/sanity.bbclass | 9 ++---
 scripts/oe-setup-builddir   | 5 -
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index 2864318..29bb619 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -841,9 +841,12 @@ def check_sanity_everybuild(status, d):
 else:
 bb.utils.mkdirhier(tmpdir)
 # Remove setuid, setgid and sticky bits from TMPDIR
-os.chmod(tmpdir, os.stat(tmpdir).st_mode & ~ stat.S_ISUID)
-os.chmod(tmpdir, os.stat(tmpdir).st_mode & ~ stat.S_ISGID)
-os.chmod(tmpdir, os.stat(tmpdir).st_mode & ~ stat.S_ISVTX)
+try:
+os.chmod(tmpdir, os.stat(tmpdir).st_mode & ~ stat.S_ISUID)
+os.chmod(tmpdir, os.stat(tmpdir).st_mode & ~ stat.S_ISGID)
+os.chmod(tmpdir, os.stat(tmpdir).st_mode & ~ stat.S_ISVTX)
+except OSError:
+bb.warn("Unable to chmod TMPDIR: %s" % tmpdir)
 with open(checkfile, "w") as f:
 f.write(tmpdir)
 
diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir
index f5b7e4e..91bd86b 100755
--- a/scripts/oe-setup-builddir
+++ b/scripts/oe-setup-builddir
@@ -24,7 +24,10 @@ if [ -z "$BUILDDIR" ]; then
 fi
 
 mkdir -p "$BUILDDIR/conf"
-chmod -R -st "$BUILDDIR" 
+
+# Attempting removal of sticky,setuid bits from BUILDDIR, BUILDDIR/conf
+chmod -st "$BUILDDIR" 2>/dev/null || echo "WARNING: unable to chmod $BUILDDIR"
+chmod -st "$BUILDDIR/conf" 2>/dev/null || echo "WARNING: unable to chmod 
$BUILDDIR/conf"
 
 if [ ! -d "$BUILDDIR" ]; then
 echo >&2 "Error: The builddir ($BUILDDIR) does not exist!"
-- 
2.5.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] Fix recursive mode -st on BUILDDIR setup

[Alex Franco]

Yes, I agree and in fact the patch is just now shipping

Alex Franco

On 09/03/2015 04:43 PM, Martin Jansa wrote:

On Thu, Sep 03, 2015 at 03:01:20PM -0500, Alex Franco wrote:

Hello Martin, so the error you are seeing is related to the chmodding
being done in sanity.bbclass, not the chmodding taking place in
oe-setup-builddir. I am adding a catch and a warning for that, as I
reproduce your setup so I can also reproduce the OSError.

Thanks.

My point was that even when such setup isn't safe from reasons other
people mentioned, the sanity.bbclass shouldn't fail with OSError
exception.

And as the issue isn't fatal for the build (I was using setup like this
for very long time and haven't noticed host-permissions-contamination
from this yet), then I would prefer just bbwarn instead of bbfatal - in
both cases is should show clear message what's wrong and what user
should do about it instead of OSError and user having to read
sanity.bbclass to see what and why failed.

Regards,


Alex

On 09/02/2015 07:57 PM, Martin Jansa wrote:

Warning informing that chmod failed is better than fatal error
preventing me to build anything in that setup with tmpfs.

On Wed, Sep 2, 2015 at 11:27 PM, Alex Franco
mailto:alejandro.fra...@linux.intel.com>> wrote:

 Checking may be the better approach, as warning here would do
 little more than what the current failure does (informing that
 chmod failed)

 Alex Franco


 On 09/02/2015 01:25 PM, Martin Jansa wrote:

 On Wed, Sep 02, 2015 at 06:51:23PM +0100, Richard Purdie wrote:

 On Wed, 2015-09-02 at 11:36 -0500, Alex Franco wrote:

 Removing recursive option from chmod -st on BUILDDIR
 as it would
 take very long on existing build directories

 [YOCTO 7669]

 Signed-off-by: Alex Franco
 mailto:alejandro.fra...@linux.intel.com>>
 ---
   scripts/oe-setup-builddir | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/scripts/oe-setup-builddir
 b/scripts/oe-setup-builddir
 index f5b7e4e..44c7dcc 100755
 --- a/scripts/oe-setup-builddir
 +++ b/scripts/oe-setup-builddir
 @@ -24,7 +24,7 @@ if [ -z "$BUILDDIR" ]; then
   fi
 mkdir -p "$BUILDDIR/conf"
 -chmod -R -st "$BUILDDIR"
 +chmod -st "$BUILDDIR"

 I think you did this so that conf/ gets the right
 permissions too.
 Perhaps the best approach is:

 +chmod -st "$BUILDDIR" $BUILDDIR/conf"

 Can we add "|| bbwarn foo"

 for cases when it doesn't work for whatever reason or check the
 permissions of these 2 dirs before calling chmod?

 ?

 Cheers,

 Richard

 --
 ___
 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] [oe-core][PATCH 1/2] ifupdown: import recipe

[Khem Raj]

> On Sep 3, 2015, at 2:28 PM, Phil Blundell  wrote:
> 
> On Thu, 2015-09-03 at 13:22 -0700, Khem Raj wrote:
>> irrespective of this change. I see yet another configuration with this
>> into OE-core, overall OE-Core should get smaller
>> and case does not sound convincing to me. You dont want to use busybox
>> in a fairly large image which has other GPLv2 software in
>> it. Thats fine but doesnt look like a common usecase to me
> 
> In general, I don't think it is a good idea for oe-core to be entirely
> beholden to busybox or any other package, and I would be all in favour
> of including an alternative implementation for everything that we depend
> on busybox for.

thats a fine idea,

> 
> In the specific case of ifupdown, the whole thing seems a little bit
> 1990s and it's hard to avoid the sense that there are better ways to
> solve that particular problem nowadays.  But oe-core does already
> include net-tools, which is if anything even more retro (and is in a
> similar position vis-a-vis busybox) so there is precedent for including
> this kind of thing.

Yes although replacing net-tools with iproute2 would have been a better one.

> 
> It's also not as if ifupdown is a large piece of software with a complex
> web of ABI dependencies that will introduce some huge maintenance burden
> in the future.  So I can't see any real downside to adding it to
> oe-core.

It needs maintenance, and if maintainers are fine carrying it
is fine too. Added price is future contributions to other areas/packages
which have to keep working with this, and there will be patches rejected because
they don’t work with this so there is some burden dispersed on development 
community

> 
> p.
> 
> 



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] Fix recursive mode -st on BUILDDIR setup

[Martin Jansa]

On Thu, Sep 03, 2015 at 03:01:20PM -0500, Alex Franco wrote:
> Hello Martin, so the error you are seeing is related to the chmodding 
> being done in sanity.bbclass, not the chmodding taking place in 
> oe-setup-builddir. I am adding a catch and a warning for that, as I 
> reproduce your setup so I can also reproduce the OSError.

Thanks.

My point was that even when such setup isn't safe from reasons other
people mentioned, the sanity.bbclass shouldn't fail with OSError
exception.

And as the issue isn't fatal for the build (I was using setup like this
for very long time and haven't noticed host-permissions-contamination
from this yet), then I would prefer just bbwarn instead of bbfatal - in
both cases is should show clear message what's wrong and what user
should do about it instead of OSError and user having to read
sanity.bbclass to see what and why failed.

Regards,

> Alex
> 
> On 09/02/2015 07:57 PM, Martin Jansa wrote:
> > Warning informing that chmod failed is better than fatal error 
> > preventing me to build anything in that setup with tmpfs.
> >
> > On Wed, Sep 2, 2015 at 11:27 PM, Alex Franco 
> >  > > wrote:
> >
> > Checking may be the better approach, as warning here would do
> > little more than what the current failure does (informing that
> > chmod failed)
> >
> > Alex Franco
> >
> >
> > On 09/02/2015 01:25 PM, Martin Jansa wrote:
> >
> > On Wed, Sep 02, 2015 at 06:51:23PM +0100, Richard Purdie wrote:
> >
> > On Wed, 2015-09-02 at 11:36 -0500, Alex Franco wrote:
> >
> > Removing recursive option from chmod -st on BUILDDIR
> > as it would
> > take very long on existing build directories
> >
> > [YOCTO 7669]
> >
> > Signed-off-by: Alex Franco
> >  > >
> > ---
> >   scripts/oe-setup-builddir | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/scripts/oe-setup-builddir
> > b/scripts/oe-setup-builddir
> > index f5b7e4e..44c7dcc 100755
> > --- a/scripts/oe-setup-builddir
> > +++ b/scripts/oe-setup-builddir
> > @@ -24,7 +24,7 @@ if [ -z "$BUILDDIR" ]; then
> >   fi
> > mkdir -p "$BUILDDIR/conf"
> > -chmod -R -st "$BUILDDIR"
> > +chmod -st "$BUILDDIR"
> >
> > I think you did this so that conf/ gets the right
> > permissions too.
> > Perhaps the best approach is:
> >
> > +chmod -st "$BUILDDIR" $BUILDDIR/conf"
> >
> > Can we add "|| bbwarn foo"
> >
> > for cases when it doesn't work for whatever reason or check the
> > permissions of these 2 dirs before calling chmod?
> >
> > ?
> >
> > Cheers,
> >
> > Richard
> >
> > -- 
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > 
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >
> >
> >
> 

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/2] ifupdown: import recipe

[Richard Purdie]

On Thu, 2015-09-03 at 14:15 -0700, Khem Raj wrote:
> > On Sep 3, 2015, at 1:27 PM, Richard Purdie 
> >  wrote:
> > 
> > On Thu, 2015-09-03 at 13:22 -0700, Khem Raj wrote:
> >> On Thu, Sep 3, 2015 at 5:20 AM, Bruce Ashfield  
> >> wrote:
>  To put this another way, I think it is probably reasonable that we
>  should be able to build an image from OE-Core with basic functionality
>  like networking without busybox?
> >>> 
> >>> That's what I'd support. If everything you need for the functionality 
> >>> with busy
> >>> box is in oe-core, to me, it doesn't make sense to go outside core to get 
> >>> that
> >>> same functionality without busybox.
> >> 
> >> irrespective of this change. I see yet another configuration with this
> >> into OE-core, overall OE-Core should get smaller
> >> and case does not sound convincing to me. You dont want to use busybox
> >> in a fairly large image which has other GPLv2 software in
> >> it. Thats fine but doesnt look like a common usecase to me
> > 
> > Nobody mentioned GPLv2, that isn't relevant here.
> 
> I assumed thats one reason to not include it. I am trying to understand 
> reasoning to
> not include busybox. Or is is just because its a poster child for litigations.

The litigation issues surrounding it certainly don't do it any favours,
but the main issue is that if busybox is there, we're not seen as a
"proper/full" linux.

> > I have heard OE being dismissed since it can't produce an image without
> > busybox in it. The implication is we can't build "big" Linux, only small
> > embedded things. The pieces we need busybox for are tiny and should be
> > easy to replace (like this does).
> 
> as we include other alternative providers, they get preference over busybox 
> applets
> even if busybox is part of it.

The problem is some people don't want any busybox.

> > So I can see a fairly compelling argument for OE-Core to be able to
> > generate a busybox free image with standard functionality just from a PR
> > perspective. From what I gather we have people willing to test and
> > maintain it too…
> 
> PR I see. I was searching for technical reasons.

Well, its technical but related to the image of the project too. Can
OE-Core today produce a "standard linux desktop" type "full" featured
filesystem? I cannot honestly say it can due to this reason, busybox has
to be there. There are some people who do discount OE because of this.
This isn't new, I remember Marcin amongst others working on this. We're
close, but close doesn't mean we can answer "yes" to the question and I
think it would be nice to be able to do so clearly.

Cheers,

Richard

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/2] ifupdown: import recipe

[Bruce Ashfield]

On Thu, Sep 3, 2015 at 5:24 PM, Khem Raj  wrote:
>
>> On Sep 3, 2015, at 2:02 PM, Bruce Ashfield  wrote:
>>
>> On Thu, Sep 3, 2015 at 4:32 PM, Otavio Salvador
>>  wrote:
>>> On Thu, Sep 3, 2015 at 5:27 PM, Richard Purdie
>>>  wrote:
 On Thu, 2015-09-03 at 13:22 -0700, Khem Raj wrote:
> On Thu, Sep 3, 2015 at 5:20 AM, Bruce Ashfield  
> wrote:
>>> To put this another way, I think it is probably reasonable that we
>>> should be able to build an image from OE-Core with basic functionality
>>> like networking without busybox?
>>
>> That's what I'd support. If everything you need for the functionality 
>> with busy
>> box is in oe-core, to me, it doesn't make sense to go outside core to 
>> get that
>> same functionality without busybox.
>
> irrespective of this change. I see yet another configuration with this
> into OE-core, overall OE-Core should get smaller
> and case does not sound convincing to me. You dont want to use busybox
> in a fairly large image which has other GPLv2 software in
> it. Thats fine but doesnt look like a common usecase to me

 Nobody mentioned GPLv2, that isn't relevant here.

 I have heard OE being dismissed since it can't produce an image without
 busybox in it. The implication is we can't build "big" Linux, only small
 embedded things. The pieces we need busybox for are tiny and should be
 easy to replace (like this does).

 So I can see a fairly compelling argument for OE-Core to be able to
 generate a busybox free image with standard functionality just from a PR
 perspective. From what I gather we have people willing to test and
 maintain it too...
>>>
>>> If people were demanding it, it would have been moved for
>>> meta-networking ages ago, it seems it is not the case.
>>
>> ... or they were just holding it elsewhere, since not everyone has the
>> time to get things merged to core. In particular if they think it will be
>> a battle.
>
> thats how we bloated oe-classic. Oh people might need it because I need it 
> therefore slam it in
> I have written a packagegroup to replace busybox but I never thought it was 
> so core.
>
>>
>>>
>>> So my vote is:
>>>
>>> - move to meta-networking
>>
>> And what if the use cases don't want/need meta-networking ? We have
>> the submission and one use case, and one of the reasons it was sent
>> to core was to keep a finite set of layers and recipes to build such an 
>> image.
>>
>> Joe/Randy ?
>>
>> It is this sort of thing that forces use of combo layers or the whitelist
>> classes :)
>
> You can also help in making those layers meet the quality criteria you need 
> instead of being
> pick what I need throw the rest out approach.

Agreed. No arguments there .. and hopefully we can also finally break the layers
up into smaller parts / separate repos.

I've had the issue that I can't just update meta-networking .. I get everything.
I can help with quality in layers that I use (which I do), but when
versions change
underneath you (and you have a specific requirement), there's little that can
be done ... except copy and pin.

>
>>
>>> - for 2.1 we see if it goes to core or not
>>
>> But without criteria for success .. what does that get us ? What is the
>> case that needs to be made for a move to core in 2.1, that isn't being
>> made now ?
>>
>> Yes, I'm playing devil's advocate on this thread .. since I want to see
>> this sort of thing clearly defined.
>
> if its required by more than 1 distro. Is duplicated in other layers because 
> the layer it resides in
> is not used by a distro. It replaces a core functionality in OE-Core. It has 
> to be a building block and not a leaf package e.g. These Would be some of 
> things that may be thought of.

Agreed.


Bruce




-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/8] initramfs-framework: create /dev/console

[Khem Raj]

> On Sep 3, 2015, at 11:42 AM, Patrick Ohly  wrote:
> 
> install -m 0755 ${WORKDIR}/debug ${D}/init.d/00-debug
> +
> +# Create device nodes expected by some kernels in initramfs
> +# before even executing /init.
> +install -d ${D}/dev
> +mknod -m 622 ${D}/dev/console c 5 1
> }
> 

may be just use USE_DEVFS = “0” instead if we are not letting devtmpfs into 
initrd image


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 04/12] gnome-icon-theme: remove the recipe

[Khem Raj]

> On Sep 3, 2015, at 8:34 AM, Alexander Kanavin 
>  wrote:
> 
> It is not used by anything in oe-core and will be moved to meta-gnome
> 

OK, please send the patch for meta-gnome as well. So we can merge them in more 
or less in sync

> Signed-off-by: Alexander Kanavin 
> ---
> .../gnome/gnome-icon-theme/pkgconfig-native.patch  | 28 --
> .../recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb | 22 -
> 2 files changed, 50 deletions(-)
> delete mode 100644 
> meta/recipes-gnome/gnome/gnome-icon-theme/pkgconfig-native.patch
> delete mode 100644 meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb
> 
> diff --git a/meta/recipes-gnome/gnome/gnome-icon-theme/pkgconfig-native.patch 
> b/meta/recipes-gnome/gnome/gnome-icon-theme/pkgconfig-native.patch
> deleted file mode 100644
> index 6139eab..000
> --- a/meta/recipes-gnome/gnome/gnome-icon-theme/pkgconfig-native.patch
> +++ /dev/null
> @@ -1,28 +0,0 @@
> -icon-naming-utils is a native dependency so we need to use the native 
> pkg-config
> -to find it.  Simply perform the old switcheroonie on $PKG_CONFIG so
> -pkg-config-native is used temporarily.
> -
> -Upstream-Status: Inappropriate (OE-specific)
> -Signed-off-by: Ross Burton 
> -
> -diff --git a/configure.ac b/configure.ac
> -index 6074f2c..3d38e49 100644
>  a/configure.ac
> -+++ b/configure.ac
> -@@ -40,6 +40,8 @@ if test "x$enable_mapping" != "xno"; then
> -UTILS_REQUIRED=0.8.7
> -
> -AC_MSG_CHECKING([icon-naming-utils >= $UTILS_REQUIRED])
> -+   save_PKG_CONFIG=$PKG_CONFIG
> -+   PKG_CONFIG=pkg-config-native
> -PKG_CHECK_EXISTS(icon-naming-utils >= $UTILS_REQUIRED,
> - have_utils=yes, have_utils=no)
> -if test "x$have_utils" = "xyes"; then
> -@@ -51,6 +53,7 @@ if test "x$enable_mapping" != "xno"; then
> -   AC_MSG_ERROR([icon-naming-utils >= $UTILS_REQUIRED is required to 
> build
> - and install gnome-icon-theme])
> -fi
> -+   PKG_CONFIG=save_PKG_CONFIG
> - else
> -ICONMAP="false"
> - fi
> diff --git a/meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb 
> b/meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb
> deleted file mode 100644
> index a6a3afa..000
> --- a/meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb
> +++ /dev/null
> @@ -1,22 +0,0 @@
> -SUMMARY = "GNOME 2 default icon themes"
> -HOMEPAGE = "http://www.gnome.org/";
> -BUGTRACKER = "https://bugzilla.gnome.org/";
> -SECTION = "x11/gnome"
> -
> -LICENSE = "LGPLv3+ | CC-BY-SA-3.0"
> -LIC_FILES_CHKSUM = "file://COPYING;md5=e7e289d90fc8bdceed5e3f142f98229e"
> -
> -PR = "r5"
> -
> -DEPENDS = "icon-naming-utils-native intltool-native 
> libxml-simple-perl-native"
> -
> -inherit allarch autotools perlnative gtk-icon-cache pkgconfig gettext
> -
> -SRC_URI = "${GNOME_MIRROR}/${BPN}/2.31/${BPN}-${PV}.tar.bz2 \
> -   file://pkgconfig-native.patch"
> -
> -SRC_URI[md5sum] = "8e727703343d4c18c73c79dd2009f8ed"
> -SRC_URI[sha256sum] = 
> "ea7e05b77ead159379392b3b275ca0c9cbacd7d936014e447cc7c5e27a767982"
> -
> -FILES_${PN} += "${datadir}/*"
> -RRECOMMENDS_${PN} += "librsvg-gtk"
> --
> 2.1.4
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/2] ifupdown: import recipe

[Khem Raj]

> On Sep 3, 2015, at 2:02 PM, Bruce Ashfield  wrote:
> 
> On Thu, Sep 3, 2015 at 4:32 PM, Otavio Salvador
>  wrote:
>> On Thu, Sep 3, 2015 at 5:27 PM, Richard Purdie
>>  wrote:
>>> On Thu, 2015-09-03 at 13:22 -0700, Khem Raj wrote:
 On Thu, Sep 3, 2015 at 5:20 AM, Bruce Ashfield  
 wrote:
>> To put this another way, I think it is probably reasonable that we
>> should be able to build an image from OE-Core with basic functionality
>> like networking without busybox?
> 
> That's what I'd support. If everything you need for the functionality 
> with busy
> box is in oe-core, to me, it doesn't make sense to go outside core to get 
> that
> same functionality without busybox.
 
 irrespective of this change. I see yet another configuration with this
 into OE-core, overall OE-Core should get smaller
 and case does not sound convincing to me. You dont want to use busybox
 in a fairly large image which has other GPLv2 software in
 it. Thats fine but doesnt look like a common usecase to me
>>> 
>>> Nobody mentioned GPLv2, that isn't relevant here.
>>> 
>>> I have heard OE being dismissed since it can't produce an image without
>>> busybox in it. The implication is we can't build "big" Linux, only small
>>> embedded things. The pieces we need busybox for are tiny and should be
>>> easy to replace (like this does).
>>> 
>>> So I can see a fairly compelling argument for OE-Core to be able to
>>> generate a busybox free image with standard functionality just from a PR
>>> perspective. From what I gather we have people willing to test and
>>> maintain it too...
>> 
>> If people were demanding it, it would have been moved for
>> meta-networking ages ago, it seems it is not the case.
> 
> ... or they were just holding it elsewhere, since not everyone has the
> time to get things merged to core. In particular if they think it will be
> a battle.

thats how we bloated oe-classic. Oh people might need it because I need it 
therefore slam it in
I have written a packagegroup to replace busybox but I never thought it was so 
core.

> 
>> 
>> So my vote is:
>> 
>> - move to meta-networking
> 
> And what if the use cases don't want/need meta-networking ? We have
> the submission and one use case, and one of the reasons it was sent
> to core was to keep a finite set of layers and recipes to build such an image.
> 
> Joe/Randy ?
> 
> It is this sort of thing that forces use of combo layers or the whitelist
> classes :)

You can also help in making those layers meet the quality criteria you need 
instead of being
pick what I need throw the rest out approach.

> 
>> - for 2.1 we see if it goes to core or not
> 
> But without criteria for success .. what does that get us ? What is the
> case that needs to be made for a move to core in 2.1, that isn't being
> made now ?
> 
> Yes, I'm playing devil's advocate on this thread .. since I want to see
> this sort of thing clearly defined.

if its required by more than 1 distro. Is duplicated in other layers because 
the layer it resides in
is not used by a distro. It replaces a core functionality in OE-Core. It has to 
be a building block and not a leaf package e.g. These Would be some of things 
that may be thought of.


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] [oe-core][PATCH 1/2] ifupdown: import recipe

[Khem Raj]

> On Sep 3, 2015, at 1:27 PM, Richard Purdie 
>  wrote:
> 
> On Thu, 2015-09-03 at 13:22 -0700, Khem Raj wrote:
>> On Thu, Sep 3, 2015 at 5:20 AM, Bruce Ashfield  
>> wrote:
 To put this another way, I think it is probably reasonable that we
 should be able to build an image from OE-Core with basic functionality
 like networking without busybox?
>>> 
>>> That's what I'd support. If everything you need for the functionality with 
>>> busy
>>> box is in oe-core, to me, it doesn't make sense to go outside core to get 
>>> that
>>> same functionality without busybox.
>> 
>> irrespective of this change. I see yet another configuration with this
>> into OE-core, overall OE-Core should get smaller
>> and case does not sound convincing to me. You dont want to use busybox
>> in a fairly large image which has other GPLv2 software in
>> it. Thats fine but doesnt look like a common usecase to me
> 
> Nobody mentioned GPLv2, that isn't relevant here.

I assumed thats one reason to not include it. I am trying to understand 
reasoning to
not include busybox. Or is is just because its a poster child for litigations.

> 
> I have heard OE being dismissed since it can't produce an image without
> busybox in it. The implication is we can't build "big" Linux, only small
> embedded things. The pieces we need busybox for are tiny and should be
> easy to replace (like this does).

as we include other alternative providers, they get preference over busybox 
applets
even if busybox is part of it.

> 
> So I can see a fairly compelling argument for OE-Core to be able to
> generate a busybox free image with standard functionality just from a PR
> perspective. From what I gather we have people willing to test and
> maintain it too…

PR I see. I was searching for technical reasons.


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

[OE-core] [oe-core][PATCH 1/1] libinput: avoid --enable-event-gui=auto

[Joe Slater]

Specify a value via PACKAGECONFIG[gui].  The default is
--diable-event-gui.
---
 meta/recipes-graphics/wayland/libinput_0.21.0.bb |1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-graphics/wayland/libinput_0.21.0.bb 
b/meta/recipes-graphics/wayland/libinput_0.21.0.bb
index d51fb37..ac5a249 100644
--- a/meta/recipes-graphics/wayland/libinput_0.21.0.bb
+++ b/meta/recipes-graphics/wayland/libinput_0.21.0.bb
@@ -18,6 +18,7 @@ inherit autotools pkgconfig
 
 PACKAGECONFIG ??= ""
 PACKAGECONFIG[libunwind] = "--with-libunwind,--without-libunwind,libunwind"
+PACKAGECONFIG[gui] = "--enable-event-gui,--disable-event-gui,cairo gtk+3"
 
 FILES_${PN} += "${libdir}/udev/"
 FILES_${PN}-dbg += "${libdir}/udev/.debug"
-- 
1.7.9.5

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/2] ifupdown: import recipe

[Bruce Ashfield]

On Thu, Sep 3, 2015 at 4:32 PM, Otavio Salvador
 wrote:
> On Thu, Sep 3, 2015 at 5:27 PM, Richard Purdie
>  wrote:
>> On Thu, 2015-09-03 at 13:22 -0700, Khem Raj wrote:
>>> On Thu, Sep 3, 2015 at 5:20 AM, Bruce Ashfield  
>>> wrote:
>>> >> To put this another way, I think it is probably reasonable that we
>>> >> should be able to build an image from OE-Core with basic functionality
>>> >> like networking without busybox?
>>> >
>>> > That's what I'd support. If everything you need for the functionality 
>>> > with busy
>>> > box is in oe-core, to me, it doesn't make sense to go outside core to get 
>>> > that
>>> > same functionality without busybox.
>>>
>>> irrespective of this change. I see yet another configuration with this
>>> into OE-core, overall OE-Core should get smaller
>>> and case does not sound convincing to me. You dont want to use busybox
>>> in a fairly large image which has other GPLv2 software in
>>> it. Thats fine but doesnt look like a common usecase to me
>>
>> Nobody mentioned GPLv2, that isn't relevant here.
>>
>> I have heard OE being dismissed since it can't produce an image without
>> busybox in it. The implication is we can't build "big" Linux, only small
>> embedded things. The pieces we need busybox for are tiny and should be
>> easy to replace (like this does).
>>
>> So I can see a fairly compelling argument for OE-Core to be able to
>> generate a busybox free image with standard functionality just from a PR
>> perspective. From what I gather we have people willing to test and
>> maintain it too...
>
> If people were demanding it, it would have been moved for
> meta-networking ages ago, it seems it is not the case.

... or they were just holding it elsewhere, since not everyone has the
time to get things merged to core. In particular if they think it will be
a battle.

>
> So my vote is:
>
>  - move to meta-networking

And what if the use cases don't want/need meta-networking ? We have
the submission and one use case, and one of the reasons it was sent
to core was to keep a finite set of layers and recipes to build such an image.

Joe/Randy ?

It is this sort of thing that forces use of combo layers or the whitelist
classes :)

>  - for 2.1 we see if it goes to core or not

But without criteria for success .. what does that get us ? What is the
case that needs to be made for a move to core in 2.1, that isn't being
made now ?

Yes, I'm playing devil's advocate on this thread .. since I want to see
this sort of thing clearly defined.

Cheers,

Bruce

>
> --
> 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



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/2] ifupdown: import recipe

[Otavio Salvador]

On Thu, Sep 3, 2015 at 5:27 PM, Richard Purdie
 wrote:
> On Thu, 2015-09-03 at 13:22 -0700, Khem Raj wrote:
>> On Thu, Sep 3, 2015 at 5:20 AM, Bruce Ashfield  
>> wrote:
>> >> To put this another way, I think it is probably reasonable that we
>> >> should be able to build an image from OE-Core with basic functionality
>> >> like networking without busybox?
>> >
>> > That's what I'd support. If everything you need for the functionality with 
>> > busy
>> > box is in oe-core, to me, it doesn't make sense to go outside core to get 
>> > that
>> > same functionality without busybox.
>>
>> irrespective of this change. I see yet another configuration with this
>> into OE-core, overall OE-Core should get smaller
>> and case does not sound convincing to me. You dont want to use busybox
>> in a fairly large image which has other GPLv2 software in
>> it. Thats fine but doesnt look like a common usecase to me
>
> Nobody mentioned GPLv2, that isn't relevant here.
>
> I have heard OE being dismissed since it can't produce an image without
> busybox in it. The implication is we can't build "big" Linux, only small
> embedded things. The pieces we need busybox for are tiny and should be
> easy to replace (like this does).
>
> So I can see a fairly compelling argument for OE-Core to be able to
> generate a busybox free image with standard functionality just from a PR
> perspective. From what I gather we have people willing to test and
> maintain it too...

If people were demanding it, it would have been moved for
meta-networking ages ago, it seems it is not the case.

So my vote is:

 - move to meta-networking
 - for 2.1 we see if it goes to core or not

-- 
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] [oe-core][PATCH 1/2] ifupdown: import recipe

[Richard Purdie]

On Thu, 2015-09-03 at 13:22 -0700, Khem Raj wrote:
> On Thu, Sep 3, 2015 at 5:20 AM, Bruce Ashfield  
> wrote:
> >> To put this another way, I think it is probably reasonable that we
> >> should be able to build an image from OE-Core with basic functionality
> >> like networking without busybox?
> >
> > That's what I'd support. If everything you need for the functionality with 
> > busy
> > box is in oe-core, to me, it doesn't make sense to go outside core to get 
> > that
> > same functionality without busybox.
> 
> irrespective of this change. I see yet another configuration with this
> into OE-core, overall OE-Core should get smaller
> and case does not sound convincing to me. You dont want to use busybox
> in a fairly large image which has other GPLv2 software in
> it. Thats fine but doesnt look like a common usecase to me

Nobody mentioned GPLv2, that isn't relevant here.

I have heard OE being dismissed since it can't produce an image without
busybox in it. The implication is we can't build "big" Linux, only small
embedded things. The pieces we need busybox for are tiny and should be
easy to replace (like this does).

So I can see a fairly compelling argument for OE-Core to be able to
generate a busybox free image with standard functionality just from a PR
perspective. From what I gather we have people willing to test and
maintain it too...

Cheers,

Richard


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/2] ifupdown: import recipe

[Khem Raj]

On Thu, Sep 3, 2015 at 5:20 AM, Bruce Ashfield  wrote:
>> To put this another way, I think it is probably reasonable that we
>> should be able to build an image from OE-Core with basic functionality
>> like networking without busybox?
>
> That's what I'd support. If everything you need for the functionality with 
> busy
> box is in oe-core, to me, it doesn't make sense to go outside core to get that
> same functionality without busybox.

irrespective of this change. I see yet another configuration with this
into OE-core, overall OE-Core should get smaller
and case does not sound convincing to me. You dont want to use busybox
in a fairly large image which has other GPLv2 software in
it. Thats fine but doesnt look like a common usecase to me
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH][master/fido/dizzy] oprofileui: Use inherit gettext

[Saul Wold]

oprofileui uses gettext during the configuration task so should be inherit
gettext. This issue appears when an older version of gettext is used do to
pinning to the older non-gplv3 version.

[YOCTO #7795]

Signed-off-by: Saul Wold 
---
 meta/recipes-kernel/oprofile/oprofileui.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/oprofile/oprofileui.inc 
b/meta/recipes-kernel/oprofile/oprofileui.inc
index 1dfd0c6..8fcf014 100644
--- a/meta/recipes-kernel/oprofile/oprofileui.inc
+++ b/meta/recipes-kernel/oprofile/oprofileui.inc
@@ -10,7 +10,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
 
 DEPENDS = "glib-2.0 avahi intltool-native"
 
-inherit autotools pkgconfig
+inherit autotools pkgconfig gettext
 
 EXTRA_OECONF = "--with-avahi"
 
-- 
2.1.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 10/12] uclibc: update PV to 0.9.33.2 to match latest upstream release

[Khem Raj]

On Thu, Sep 3, 2015 at 8:34 AM, Alexander Kanavin
 wrote:
> -PV = "0.9.33+git${SRCPV}"
> +PV = "0.9.33.2+git${SRCPV}"

technically its not right since we are not on 0.9.33 branch at all.
We could use 0.9.33+0.9.34+git${SRCPV}
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] qemu: Fix qemu_cpu_kick_thread on init

[Aníbal Limón]

When QEMU starts the RCU thread executes qemu_mutex_lock_thread
causing error "qemu:qemu_cpu_kick_thread: No such process" and exits.

For detail explanation see upstream patch.

[YOCTO #8143]

Signed-off-by: Aníbal Limón 
---
 meta/recipes-devtools/qemu/qemu.inc|  1 +
 ..._mutex_lock_iothread-fix-race-condition-a.patch | 45 ++
 2 files changed, 46 insertions(+)
 create mode 100644 
meta/recipes-devtools/qemu/qemu/cpus.c-qemu_mutex_lock_iothread-fix-race-condition-a.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index dc7b628..738bf2b 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -21,6 +21,7 @@ SRC_URI = "\
 file://wacom.patch \
 file://add-ptest-in-makefile.patch \
 file://run-ptest \
+file://cpus.c-qemu_mutex_lock_iothread-fix-race-condition-a.patch \
 "
 
 SRC_URI_append_class-native = "\
diff --git 
a/meta/recipes-devtools/qemu/qemu/cpus.c-qemu_mutex_lock_iothread-fix-race-condition-a.patch
 
b/meta/recipes-devtools/qemu/qemu/cpus.c-qemu_mutex_lock_iothread-fix-race-condition-a.patch
new file mode 100644
index 000..45dffab
--- /dev/null
+++ 
b/meta/recipes-devtools/qemu/qemu/cpus.c-qemu_mutex_lock_iothread-fix-race-condition-a.patch
@@ -0,0 +1,45 @@
+Upstream-Status: Submitted
+
+From f354b9333408d411854af058cc44cceda60b4473 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?An=C3=ADbal=20Lim=C3=B3n?= 
+Date: Thu, 3 Sep 2015 14:07:34 -0500
+Subject: [PATCH] cpus.c: qemu_mutex_lock_iothread fix race condition at cpu
+ thread init
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+When QEMU starts the RCU thread executes qemu_mutex_lock_thread
+causing error "qemu:qemu_cpu_kick_thread: No such process" and exits.
+
+This isn't occur frequently but in glibc the thread id can exist and
+this not guarantee that the thread is on active/running state. If is
+inserted a sleep(1) after newthread assignment [1] the issue appears.
+
+So not make assumption that thread exist if first_cpu->thread is set
+then change the validation of cpu to created that is set into cpu
+threads (kvm, tcg, dummy).
+
+[1] 
https://sourceware.org/git/?p=glibc.git;a=blob;f=nptl/pthread_create.c;h=d10f4ea8004e1d8f3a268b95cc0f8d93b8d89867;hb=HEAD#l621
+
+Signed-off-by: Aníbal Limón 
+---
+ cpus.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/cpus.c b/cpus.c
+index 7e4786e..05e5400 100644
+--- a/cpus.c
 b/cpus.c
+@@ -1171,7 +1171,7 @@ void qemu_mutex_lock_iothread(void)
+  * TCG code execution.
+  */
+ if (!tcg_enabled() || qemu_in_vcpu_thread() ||
+-!first_cpu || !first_cpu->thread) {
++!first_cpu || !first_cpu->created) {
+ qemu_mutex_lock(&qemu_global_mutex);
+ atomic_dec(&iothread_requesting_mutex);
+ } else {
+-- 
+1.9.1
+
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] Fix recursive mode -st on BUILDDIR setup

[Alex Franco]

Hello Martin, so the error you are seeing is related to the chmodding 
being done in sanity.bbclass, not the chmodding taking place in 
oe-setup-builddir. I am adding a catch and a warning for that, as I 
reproduce your setup so I can also reproduce the OSError.


Alex

On 09/02/2015 07:57 PM, Martin Jansa wrote:
Warning informing that chmod failed is better than fatal error 
preventing me to build anything in that setup with tmpfs.


On Wed, Sep 2, 2015 at 11:27 PM, Alex Franco 
> wrote:


Checking may be the better approach, as warning here would do
little more than what the current failure does (informing that
chmod failed)

Alex Franco


On 09/02/2015 01:25 PM, Martin Jansa wrote:

On Wed, Sep 02, 2015 at 06:51:23PM +0100, Richard Purdie wrote:

On Wed, 2015-09-02 at 11:36 -0500, Alex Franco wrote:

Removing recursive option from chmod -st on BUILDDIR
as it would
take very long on existing build directories

[YOCTO 7669]

Signed-off-by: Alex Franco
mailto:alejandro.fra...@linux.intel.com>>
---
  scripts/oe-setup-builddir | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/oe-setup-builddir
b/scripts/oe-setup-builddir
index f5b7e4e..44c7dcc 100755
--- a/scripts/oe-setup-builddir
+++ b/scripts/oe-setup-builddir
@@ -24,7 +24,7 @@ if [ -z "$BUILDDIR" ]; then
  fi
mkdir -p "$BUILDDIR/conf"
-chmod -R -st "$BUILDDIR"
+chmod -st "$BUILDDIR"

I think you did this so that conf/ gets the right
permissions too.
Perhaps the best approach is:

+chmod -st "$BUILDDIR" $BUILDDIR/conf"

Can we add "|| bbwarn foo"

for cases when it doesn't work for whatever reason or check the
permissions of these 2 dirs before calling chmod?

?

Cheers,

Richard

-- 
___

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 3/9] systemd: remove hard-coded paths in FILES entries

[Joshua Lock]

On Thu, 2015-09-03 at 16:22 +0100, Burton, Ross wrote:
> 
> On 3 September 2015 at 16:12, Richard Purdie <
> richard.pur...@linuxfoundation.org> wrote:
> > From what I remember, this is intentional and this change likely
> > breaks
> > multilib. You don't want two sets of rules on a multilib system.
> > 
> Indeed - you need nonarch_base_libdir or whatever it's called here I
> think, as that doesn't get renamed by multilib.

Got it, thanks - I'm testing a v2 series with a multilib build thrown
in to the mix.

Thanks both for the feedback,

Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 8/9] nfs-utils: don't force use of /sbin as sbindir

[Joshua Lock]

On Thu, 2015-09-03 at 12:14 -0500, Mark Hatle wrote:
> On 9/3/15 9:58 AM, Joshua Lock wrote:
> > In a system with a merged /usr /sbin isn't packaged.
> 
> This sounds like an error to me if /sbin doesn't exist at all. It
> should exist
> either as a link to /usr/sbin (or the reverse).. but it should be
> there as lots
> of things expect the directory (or link) to exist.

Sure, it exists in my images but not during packaging. In my testing I
have base_bindir, base_libdir and base_sbindir set to children of /usr
in my distro.conf and a base-files_%.bbappend that creates the
symlinks. Therefore at packaging time the /sbin directory (and symlink)
 doesn't exist.

I admit this commit message is pretty poor and I'll try and remember to
fix it in a v2.

Regards,

Joshua

> (It's also required by the FHS, even though that probably isn't
> enough of a
> concern.)
> 
> > Signed-off-by: Joshua Lock 
> > ---
> >  meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb | 8
> > 
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
> > b/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
> > index 6da8509..42101de 100644
> > --- a/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
> > +++ b/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
> > @@ -90,6 +90,14 @@ RDEPENDS_${PN}-stats = "python"
> >  
> >  FILES_${PN} += "${systemd_unitdir}"
> >  
> > +do_configure_prepend() {
> > +sed -i -e 's,sbindir = /sbin,sbindir = ${base_sbindir},g'
> > \
> > +${S}/utils/mount/Makefile.am
> > +
> > +sed -i -e 's,sbindir = /sbin,sbindir = ${base_sbindir},g'
> > \
> > +${S}/utils/osd_login/Makefile.am
> > +}
> > +
> >  # Make clean needed because the package comes with
> >  # precompiled 64-bit objects that break the build
> >  do_compile_prepend() {
> > 
> 
> So my concern is simply with the commit msg -- not the actual
> implementation.
> What you have above looks correct to me.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/9] Fixes for a distro with a merged /usr

[Joshua Lock]

On Thu, 2015-09-03 at 12:11 -0500, Mark Hatle wrote:
> On 9/3/15 9:58 AM, Joshua Lock wrote:
> > I've been playing around with building a distro with a merged
> > /usr[1] and
> > the following series fixes several issues I ran across in OE core
> > metadata.
> 
> everything in '/' linked to '/usr/' or everything in '/usr/' linked
> down to '/'?
> 
> (I've seen both implementations... just curious which one you are
> trying.)

The latter, as per [1]. That is /bin, /lib and /sbin are symlinked into
/usr.

Cheers,

Joshua

1. https://wiki.freedesktop.org/www/Software/systemd/TheCaseForTheUsrMe
rge/
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH][V2] sstate: implement basic signing/validation

[Ross Burton]

To provide some element of integrity to sstate archives, allow sstate archives
to be GPG signed with a specified key (detached signature to a sidecar .sig
file), and verify the signatures when sstate archives are unpacked.

Signed-off-by: Ross Burton 
---
 meta/classes/sstate.bbclass | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 4e6afef..77313bc 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -54,6 +54,13 @@ EXTRA_STAGING_FIXMES ?= ""
 
 SIGGEN_LOCKEDSIGS_CHECK_LEVEL ?= 'error'
 
+# The GnuPG key ID and passphrase to use to sign sstate archives (or unset to
+# not sign)
+SSTATE_SIG_KEY ?= ""
+SSTATE_SIG_PASSPHRASE ?= ""
+# Whether to verify the GnUPG signatures when extracting sstate archives
+SSTATE_VERIFY_SIG ?= "0"
+
 # Specify dirs in which the shell function is executed and don't use ${B}
 # as default dirs to avoid possible race about ${B} with other task.
 sstate_create_package[dirs] = "${SSTATE_BUILDDIR}"
@@ -298,6 +305,10 @@ def sstate_installpkg(ss, d):
 d.setVar('SSTATE_INSTDIR', sstateinst)
 d.setVar('SSTATE_PKG', sstatepkg)
 
+if bb.utils.to_boolean(d.getVar("SSTATE_VERIFY_SIG", True), False):
+if subprocess.call(["gpg", "--verify", sstatepkg + ".sig", sstatepkg]) 
!= 0:
+bb.warn("Cannot verify signature on sstate package %s" % sstatepkg)
+
 for f in (d.getVar('SSTATEPREINSTFUNCS', True) or '').split() + 
['sstate_unpack_package'] + (d.getVar('SSTATEPOSTUNPACKFUNCS', True) or 
'').split():
 bb.build.exec_func(f, d)
 
@@ -605,7 +616,8 @@ def pstaging_fetch(sstatefetch, sstatepkg, d):
 # Try a fetch from the sstate mirror, if it fails just return and
 # we will build the package
 for srcuri in ['file://{0}'.format(sstatefetch),
-   'file://{0}.siginfo'.format(sstatefetch)]:
+   'file://{0}.siginfo'.format(sstatefetch),
+   'file://{0}.sig'.format(sstatefetch)]:
 localdata.setVar('SRC_URI', srcuri)
 try:
 fetcher = bb.fetch2.Fetch([srcuri], localdata, cache=False)
@@ -665,6 +677,11 @@ sstate_create_package () {
chmod 0664 $TFILE 
mv -f $TFILE ${SSTATE_PKG}
 
+   if [ -n "${SSTATE_SIG_KEY}" ]; then
+   rm -f ${SSTATE_PKG}.sig
+   echo ${SSTATE_SIG_PASSPHRASE} | gpg --batch --passphrase-fd 0 
--detach-sign --local-user ${SSTATE_SIG_KEY} --output ${SSTATE_PKG}.sig 
${SSTATE_PKG}
+   fi
+
cd ${WORKDIR}
rm -rf ${SSTATE_BUILDDIR}
 }
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/8] enhancing images, booting and runqemu, simplified version

[Patrick Ohly]

These are the same patches as in the previous patch series, minus the
ones related to initramfs-framework which will need further
discussion. I split up the /dev/console change into two commits as
suggested by Otavio.

The usage of FS UUID is still turned on by default, see the last
patch. If that's too aggressive, feel free to drop that one. It's a
change that can also be done easily in a local.conf or distro conf.

The following changes since commit aba3ef50d65e0dc8659a48bf98d0fb00dd44a6fc:

  debianutils: create package for run-parts (2015-09-02 23:51:16 +0100)

are available in the git repository at:

  git://github.com/pohly/openembedded-core booting-simplified
  https://github.com/pohly/openembedded-core/tree/booting-simplified

Patrick Ohly (8):
  runqemu: support full-disk images
  initramfs-framework: create /dev/console
  initramfs-live-boot: create /dev/console
  initramfs-framework: handle kernel parameters with . inside
  image-vm.bbclass: avoid duplicating syslinux default values
  image-vm.bbclass: support specifying an initramfs
  boot loader: support root=UUID
  boot-directdisk.bbclass: use rootfs UUID by default

 meta/classes/boot-directdisk.bbclass   |  2 +-
 meta/classes/fs-uuid.bbclass   | 24 ++
 meta/classes/grub-efi.bbclass  |  4 
 meta/classes/gummiboot.bbclass |  4 
 meta/classes/image-vm.bbclass  |  7 +--
 meta/classes/syslinux.bbclass  |  5 -
 .../initrdscripts/initramfs-framework/init |  3 ++-
 .../initrdscripts/initramfs-framework_1.0.bb   |  7 ++-
 .../initrdscripts/initramfs-live-boot_1.0.bb   |  4 +++-
 scripts/runqemu| 24 +-
 scripts/runqemu-internal   | 10 -
 11 files changed, 72 insertions(+), 22 deletions(-)
 create mode 100644 meta/classes/fs-uuid.bbclass

-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 8/8] boot-directdisk.bbclass: use rootfs UUID by default

[Patrick Ohly]

This changes the default SYSLINUX_ROOTFS such that the rootfs is no
longer expected under a fixed device path. Instead, the UUID is used
to find it. This makes the resulting .hdddirect (and thus also the
vdi/vdmk/qcow2 images derived from that) more flexible.

Signed-off-by: Patrick Ohly 
---
 meta/classes/boot-directdisk.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/boot-directdisk.bbclass 
b/meta/classes/boot-directdisk.bbclass
index 600e21a..7cb0ab0 100644
--- a/meta/classes/boot-directdisk.bbclass
+++ b/meta/classes/boot-directdisk.bbclass
@@ -60,7 +60,7 @@ inherit ${EFI_CLASS}
 
 AUTO_SYSLINUXCFG = "1"
 DISK_SIGNATURE ?= "${DISK_SIGNATURE_GENERATED}"
-SYSLINUX_ROOT ?= "root=/dev/sda2"
+SYSLINUX_ROOT ?= "root=UUID=<>"
 SYSLINUX_TIMEOUT ?= "10"
 
 IS_VM = '${@bb.utils.contains_any("IMAGE_FSTYPES", ["vmdk", "vdi", "qcow2"], 
"true", "false", d)}'
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/8] initramfs-framework: create /dev/console

[Patrick Ohly]

Some kernels, for example linux-yocto 3.19 for qemux86, fail to
execute /init in an initramfs unless there is already a /dev/console
char device in the initramfs. Booting then fails with:
Kernel panic - not syncing: /dev/console is missing or not a character 
device!
Please ensure your rootfs is properly configured

The panic itself comes from a linux-yocto specific patch to
kernel_init_freeable in init/main.c, but even without it, that
function will print an error when /dev/console is missing. The
kernel's Documentation/initrd.txt also mentions creating that device.

It remained unclear why this is not a problem on other machines. On
intel-corei7-64 from meta-intel, something (the kernel?) creates
/dev/console and /dev/[012] before transfering control to the init
script. In that case, creating /dev/console in advance is not
necessary, but does not cause any problem either.

Signed-off-by: Patrick Ohly 
---
 meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb 
b/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb
index 89b900d..6c37b9a 100644
--- a/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb
+++ b/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb
@@ -34,6 +34,11 @@ do_install() {
 
 # debug
 install -m 0755 ${WORKDIR}/debug ${D}/init.d/00-debug
+
+# Create device nodes expected by some kernels in initramfs
+# before even executing /init.
+install -d ${D}/dev
+mknod -m 622 ${D}/dev/console c 5 1
 }
 
 PACKAGES = "${PN}-base \
@@ -42,7 +47,7 @@ PACKAGES = "${PN}-base \
 initramfs-module-e2fs \
 initramfs-module-debug"
 
-FILES_${PN}-base = "/init /init.d/99-finish"
+FILES_${PN}-base = "/init /init.d/99-finish /dev"
 
 SUMMARY_initramfs-module-mdev = "initramfs support for mdev"
 RDEPENDS_initramfs-module-mdev = "${PN}-base"
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 7/8] boot loader: support root=UUID

[Patrick Ohly]

As mentioned when introducing the VM images
(https://bugzilla.yoctoproject.org/show_bug.cgi?id=7374), the
resulting images only work when the image is mounted as a disk that
results in the hard-coded path (/dev/sda in the current
default). Using the file system UUID to find the rootfs is more
flexible.

To enable this for boot-direct.bbclass and thus image-vm.bbclass (aka
FSTYPEs vdi/vmdk/qcow2), set SYSLINUX_ROOT =
"root=UUID=<>". The rootfs image must use an ext file
system.

The special string will get replaced in the APPEND line with the
actual UUID when the boot loader (grub-efi, syslinux or gummiboot)
writes the boot loader configuration files. At that time, the rootfs
image has already been created and its UUID can be extracted using
"tune2fs -l", which also should be available because the
e2fsprogs-native tools were needed to create the image in the first
place.

Signed-off-by: Patrick Ohly 
---
 meta/classes/fs-uuid.bbclass   | 24 
 meta/classes/grub-efi.bbclass  |  4 
 meta/classes/gummiboot.bbclass |  4 
 meta/classes/syslinux.bbclass  |  5 -
 4 files changed, 36 insertions(+), 1 deletion(-)
 create mode 100644 meta/classes/fs-uuid.bbclass

diff --git a/meta/classes/fs-uuid.bbclass b/meta/classes/fs-uuid.bbclass
new file mode 100644
index 000..bd2613c
--- /dev/null
+++ b/meta/classes/fs-uuid.bbclass
@@ -0,0 +1,24 @@
+# Extract UUID from ${ROOTFS}, which must have been built
+# by the time that this function gets called. Only works
+# on ext file systems and depends on tune2fs.
+def get_rootfs_uuid(d):
+import subprocess
+rootfs = d.getVar('ROOTFS', True)
+output = subprocess.check_output(['tune2fs', '-l', rootfs])
+for line in output.split('\n'):
+if line.startswith('Filesystem UUID:'):
+uuid = line.split()[-1]
+bb.note('UUID of %s: %s' % (rootfs, uuid))
+return uuid
+bb.fatal('Could not determine filesystem UUID of %s' % rootfs)
+
+# Replace the special <> inside a string (like the
+# root= APPEND string in a syslinux.cfg or gummiboot entry) with the
+# actual UUID of the rootfs. Does nothing if the special string
+# is not used.
+def replace_rootfs_uuid(d, string):
+UUID_PLACEHOLDER = '<>'
+if UUID_PLACEHOLDER in string:
+uuid = get_rootfs_uuid(d)
+string = string.replace(UUID_PLACEHOLDER, uuid)
+return string
diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
index 6d58d48..4ddc2bb 100644
--- a/meta/classes/grub-efi.bbclass
+++ b/meta/classes/grub-efi.bbclass
@@ -26,6 +26,9 @@ GRUB_OPTS ?= "serial --unit=0 --speed=115200 --word=8 
--parity=no --stop=1"
 
 EFIDIR = "/EFI/BOOT"
 
+# Need UUID utility code.
+inherit fs-uuid
+
 efi_populate() {
# DEST must be the root of the image so that EFIDIR is not
# nested under a top level directory.
@@ -129,6 +132,7 @@ python build_efi_cfg() {
 initrd = localdata.getVar('INITRD', True)
 
 if append:
+append = replace_rootfs_uuid(d, append)
 cfgfile.write('%s' % (append))
 cfgfile.write(' %s' % btype[1])
 cfgfile.write('\n')
diff --git a/meta/classes/gummiboot.bbclass b/meta/classes/gummiboot.bbclass
index dae1977..3d9c08b 100644
--- a/meta/classes/gummiboot.bbclass
+++ b/meta/classes/gummiboot.bbclass
@@ -15,6 +15,9 @@ GUMMIBOOT_CFG ?= "${S}/loader.conf"
 GUMMIBOOT_ENTRIES ?= ""
 GUMMIBOOT_TIMEOUT ?= "10"
 
+# Need UUID utility code.
+inherit fs-uuid
+
 efi_populate() {
 DEST=$1
 
@@ -108,6 +111,7 @@ python build_efi_cfg() {
 lb = "install-efi"
 entrycfg.write('options LABEL=%s ' % lb)
 if append:
+append = replace_rootfs_uuid(d, append)
 entrycfg.write('%s' % append)
 entrycfg.write('\n')
 entrycfg.close()
diff --git a/meta/classes/syslinux.bbclass b/meta/classes/syslinux.bbclass
index d6498d9..44ef9a9 100644
--- a/meta/classes/syslinux.bbclass
+++ b/meta/classes/syslinux.bbclass
@@ -34,6 +34,9 @@ ISO_BOOTCAT = "isolinux/boot.cat"
 MKISOFS_OPTIONS = "-no-emul-boot -boot-load-size 4 -boot-info-table"
 APPEND_prepend = " ${SYSLINUX_ROOT} "
 
+# Need UUID utility code.
+inherit fs-uuid
+
 syslinux_populate() {
DEST=$1
BOOTDIR=$2
@@ -177,7 +180,7 @@ python build_syslinux_cfg () {
 cfgfile.write('initrd=/initrd ')
 
 cfgfile.write('LABEL=%s '% (label))
-
+append = replace_rootfs_uuid(d, append)
 cfgfile.write('%s %s\n' % (append, btype[1]))
 else:
 cfgfile.write('APPEND %s\n' % btype[1])
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 4/8] initramfs-framework: handle kernel parameters with . inside

[Patrick Ohly]

Kernel parameters like "uvesafb.mode_option=640x480-32" were turned
into shell variables named "bootparam_uvesafb.mode_option", which
triggered errors from the shell because the name is not valid. Now
points get replaced with underscores, leading to
bootparam_uvesafb_mode_option in this example.

Signed-off-by: Patrick Ohly 
---
 meta/recipes-core/initrdscripts/initramfs-framework/init | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/initrdscripts/initramfs-framework/init 
b/meta/recipes-core/initrdscripts/initramfs-framework/init
index 95fa9fb..e8f4713 100755
--- a/meta/recipes-core/initrdscripts/initramfs-framework/init
+++ b/meta/recipes-core/initrdscripts/initramfs-framework/init
@@ -13,6 +13,7 @@
 #
 # 'foo=value' as 'bootparam_foo=value'
 # 'foo' as 'bootparam_foo=true'
+# 'foo.bar[=value] as 'foo_bar=[value|true]'
 
 # Register a function to be called before running a module
 # The hook is called as:
@@ -79,7 +80,7 @@ mount -t sysfs sysfs /sys
 # populate bootparam environment
 for p in `cat /proc/cmdline`; do
opt=`echo $p | cut -d'=' -f1`
-   opt=`echo $opt | sed -e 's/-/_/'`
+   opt=`echo $opt | tr '.-' '__'`
if [ "`echo $p | cut -d'=' -f1`" = "$p" ]; then
eval "bootparam_${opt}=true"
else
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 6/8] image-vm.bbclass: support specifying an initramfs

[Patrick Ohly]

Set INITRD_IMAGE to automatically add a custom initramfs to the boot
partition.

Signed-off-by: Patrick Ohly 
---
 meta/classes/image-vm.bbclass | 5 +
 1 file changed, 5 insertions(+)

diff --git a/meta/classes/image-vm.bbclass b/meta/classes/image-vm.bbclass
index 3df2c36..0632667 100644
--- a/meta/classes/image-vm.bbclass
+++ b/meta/classes/image-vm.bbclass
@@ -3,6 +3,11 @@ SYSLINUX_PROMPT ?= "0"
 SYSLINUX_LABELS = "boot"
 LABELS_append = " ${SYSLINUX_LABELS} "
 
+# Using an initramfs is optional. Enable it by setting INITRD_IMAGE.
+INITRD_IMAGE ?= ""
+INITRD ?= "${@'${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE}-${MACHINE}.cpio.gz' if 
'${INITRD_IMAGE}' else ''}"
+do_bootdirectdisk[depends] += "${@'${INITRD_IMAGE}:do_rootfs' if 
'${INITRD_IMAGE}' else ''}"
+
 # need to define the dependency and the ROOTFS for directdisk
 do_bootdirectdisk[depends] += "${PN}:do_rootfs"
 ROOTFS ?= "${DEPLOY_DIR_IMAGE}/${IMAGE_BASENAME}-${MACHINE}.ext4"
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 5/8] image-vm.bbclass: avoid duplicating syslinux default values

[Patrick Ohly]

Some of the SYSLINUX defaults are the same as in the underlying
syslinux.bbclass. Let's not duplicate them, because that makes
changing the default harder.

Signed-off-by: Patrick Ohly 
---
 meta/classes/image-vm.bbclass | 2 --
 1 file changed, 2 deletions(-)

diff --git a/meta/classes/image-vm.bbclass b/meta/classes/image-vm.bbclass
index bc0503b..3df2c36 100644
--- a/meta/classes/image-vm.bbclass
+++ b/meta/classes/image-vm.bbclass
@@ -1,7 +1,5 @@
 
-SYSLINUX_ROOT ?= "root=/dev/sda2"
 SYSLINUX_PROMPT ?= "0"
-SYSLINUX_TIMEOUT ?= "10"
 SYSLINUX_LABELS = "boot"
 LABELS_append = " ${SYSLINUX_LABELS} "
 
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 3/8] initramfs-live-boot: create /dev/console

[Patrick Ohly]

Some kernels, for example linux-yocto 3.19 for qemux86, fail to
execute /init in an initramfs unless there is already a /dev/console
char device in the initramfs. Booting then fails with:
Kernel panic - not syncing: /dev/console is missing or not a character 
device!
Please ensure your rootfs is properly configured

The panic itself comes from a linux-yocto specific patch to
kernel_init_freeable in init/main.c, but even without it, that
function will print an error when /dev/console is missing. The
kernel's Documentation/initrd.txt also mentions creating that device.

It remained unclear why this is not a problem on other machines. On
intel-corei7-64 from meta-intel, something (the kernel?) creates
/dev/console and /dev/[012] before transfering control to the init
script. In that case, creating /dev/console in advance is not
necessary, but does not cause any problem either.

Signed-off-by: Patrick Ohly 
---
 meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb 
b/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb
index b54cb61..57b3025 100644
--- a/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb
+++ b/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb
@@ -11,9 +11,11 @@ S = "${WORKDIR}"
 
 do_install() {
 install -m 0755 ${WORKDIR}/init-live.sh ${D}/init
+install -d ${D}/dev
+mknod -m 622 ${D}/dev/console c 5 1
 }
 
-FILES_${PN} += " /init "
+FILES_${PN} += " /init /dev "
 
 # Due to kernel dependency
 PACKAGE_ARCH = "${MACHINE_ARCH}"
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/8] runqemu: support full-disk images

[Patrick Ohly]

This makes it possible to boot images with multiple partitions (the
ones ending in .hddimg or .hdddirect) in several ways:
   runqemu qemux86 core-image-minimal hddimg
   runqemu tmp/deploy/images/qemux86/core-image-minimal-qemux86.hddimg
   VM=tmp-glibc/deploy/images/qemux86/iot-os-image-qemux86.hddimg FSTYPE=hddimg 
runqemu

Same for hdddirect.

This is useful for testing initramfs scripts, secure boot (when
switching to UEFI), or boot loaders like syslinux. For testing the
content of the rootfs, the ext4 image is better because that approach
is faster (no need to create another large image during build, rootfs
can be read directly instead of reading boot.img through loop device).

When booting a live image, the kernel, initramfs (if any) and kernel
parameters are taken from the image by the virtual machine's BIOS, so any
additional kernel parameters given to runqemu are ignored. This can be
avoided (already without this change) in a slightly hacky runqemu setup:
   ROOTFS=tmp/deploy/images/qemux86/core-image-minimal-qemux86.hddimg \
   FSTYPE=ext4 \
   KERNEL=tmp/deploy/images/qemux86/bzImage-initramfs-qemux86.bin \
   MACHINE=qemux86 \
   runqemu serial kvm nographic 'bootparams=root=/dev/ram0'

The additional bzImage-initramfs-qemux86.bin kernel here was created
by adding this to local.conf:
   INITRAMFS_IMAGE = "core-image-minimal-initramfs"
   INITRAMFS_IMAGE_BUNDLE = "1"

In the code, the new FSTYPE=hddimg resp. hdddirect behaves almost
exactly like the older vmdk FSTYPE. New types were chosen because it
seemed cleaner than using FSTYPE=vmdk when the actual image pointed to
by VM is not in that format. The downside is that several checks for
FSTYPE=vmdk had to be duplicated for FSTYPE=hddimg.

The VM variable now gets interpreted as "virtual machine disk image"
instead of "vmdk image".
---
 scripts/runqemu  | 24 ++--
 scripts/runqemu-internal | 10 +-
 2 files changed, 19 insertions(+), 15 deletions(-)

diff --git a/scripts/runqemu b/scripts/runqemu
index 8271160..a4d9a23 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -28,7 +28,7 @@ usage() {
 echo "  MACHINE - the machine name (optional, autodetected from KERNEL 
filename if unspecified)"
 echo "  RAMFS - boot a ramfs-based image"
 echo "  ISO - boot an ISO image"
-echo "  VM - boot a vmdk image"
+echo "  VM - boot a virtual machine image (= a file representing a full 
disk with boot loader)"
 echo "  Simplified QEMU command-line options can be passed with:"
 echo "nographic - disables video console"
 echo "serial - enables a serial console on /dev/ttyS0"
@@ -94,7 +94,7 @@ process_filename() {
error "conflicting FSTYPE types [$FSTYPE] and [$EXT]"
fi
;;
-   /vmdk/)
+   /hddimg/|/hdddirect/|/vmdk/)
FSTYPE=$EXT
VM=$filename
;;
@@ -114,7 +114,7 @@ while true; do
 [ -z "$MACHINE" ] && MACHINE=$arg || \
 error "conflicting MACHINE types [$MACHINE] and [$arg]"
 ;;
-"ext2" | "ext3" | "ext4" | "jffs2" | "nfs" | "btrfs")
+"ext2" | "ext3" | "ext4" | "jffs2" | "nfs" | "btrfs" | "hddimg" | 
"hdddirect" )
 [ -z "$FSTYPE" -o "$FSTYPE" = "$arg" ] && FSTYPE=$arg || \
 error "conflicting FSTYPE types [$FSTYPE] and [$arg]"
 ;;
@@ -235,12 +235,12 @@ if [ "$FSTYPE" = "nfs" -a -z "$ROOTFS" ]; then
 fi
 
 if [ -z "$MACHINE" ]; then
-if [ "x$FSTYPE" = "xvmdk" ]; then
+if [ "x$FSTYPE" = "xvmdk" ] || [ "x$FSTYPE" = "xhddimg" ] || [ "x$FSTYPE" 
= "xhdddirect" ]; then
 MACHINE=`basename $VM | sed -n 
's/.*\(qemux86-64\|qemux86\|qemuarm64\|qemuarm\|qemumips64\|qemumips\|qemuppc\|qemush4\).*/\1/p'`
 if [ -z "$MACHINE" ]; then
-error "Unable to set MACHINE from vmdk filename [$VM]"
+error "Unable to set MACHINE from image filename [$VM]"
 fi
-echo "Set MACHINE to [$MACHINE] based on vmdk [$VM]"
+echo "Set MACHINE to [$MACHINE] based on image [$VM]"
 else
 MACHINE=`basename $KERNEL | sed -n 
's/.*\(qemux86-64\|qemux86\|qemuarm64\|qemuarm\|qemumips64\|qemumips\|qemuppc\|qemush4\).*/\1/p'`
 if [ -z "$MACHINE" ]; then
@@ -436,7 +436,7 @@ if [ -e "$ROOTFS" -a -z "$FSTYPE" ]; then
 fi
 fi
 
-if [ -z "$KERNEL" -a "x$FSTYPE" != "xvmdk" ]; then
+if [ -z "$KERNEL" -a "x$FSTYPE" != "xvmdk" -a "x$FSTYPE" != "xhddimg" -a 
"x$FSTYPE" != "xhdddirect" ]; then
 setup_path_vars 1
 eval kernel_file=\$${machine2}_DEFAULT_KERNEL
 KERNEL=$DEPLOY_DIR_IMAGE/$kernel_file
@@ -462,10 +462,14 @@ fi
 if [ "$LAZY_ROOTFS" = "true" ]; then
 setup_path_vars 1
 echo "Assuming $ROOTFS really means 
$DEPLOY_DIR_IMAGE/$ROOTFS-$MACHINE.$FSTYPE"
-ROOTFS=$DEPLOY_DIR_IMAGE/$ROOTFS-$MACHINE.$FSTYPE
+if [ "$FSTYPE" = "hddimg" -o "x$FSTYPE" = "xhdddirect" ]; then
+VM=$DEPLOY_DIR_IMAGE/$ROOTFS-$MACHINE.$FSTYPE
+

[OE-core] [PATCH] cross-canadian.bbclass: typo fix in comments (s/repsonsible/responsible/)

[Mario Domenech Goulart]

Signed-off-by: Mario Domenech Goulart 
---
 meta/classes/cross-canadian.bbclass |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/cross-canadian.bbclass 
b/meta/classes/cross-canadian.bbclass
index 65ba457..d30a168 100644
--- a/meta/classes/cross-canadian.bbclass
+++ b/meta/classes/cross-canadian.bbclass
@@ -1,5 +1,5 @@
 #
-# NOTE - When using this class the user is repsonsible for ensuring that
+# NOTE - When using this class the user is responsible for ensuring that
 # TRANSLATED_TARGET_ARCH is added into PN. This ensures that if the TARGET_ARCH
 # is changed, another nativesdk xxx-canadian-cross can be installed
 #
-- 
1.7.10.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 8/9] nfs-utils: don't force use of /sbin as sbindir

[Mark Hatle]

On 9/3/15 9:58 AM, Joshua Lock wrote:
> In a system with a merged /usr /sbin isn't packaged.

This sounds like an error to me if /sbin doesn't exist at all. It should exist
either as a link to /usr/sbin (or the reverse).. but it should be there as lots
of things expect the directory (or link) to exist.

(It's also required by the FHS, even though that probably isn't enough of a
concern.)

> Signed-off-by: Joshua Lock 
> ---
>  meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb 
> b/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
> index 6da8509..42101de 100644
> --- a/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
> +++ b/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
> @@ -90,6 +90,14 @@ RDEPENDS_${PN}-stats = "python"
>  
>  FILES_${PN} += "${systemd_unitdir}"
>  
> +do_configure_prepend() {
> +sed -i -e 's,sbindir = /sbin,sbindir = ${base_sbindir},g' \
> +${S}/utils/mount/Makefile.am
> +
> +sed -i -e 's,sbindir = /sbin,sbindir = ${base_sbindir},g' \
> +${S}/utils/osd_login/Makefile.am
> +}
> +
>  # Make clean needed because the package comes with
>  # precompiled 64-bit objects that break the build
>  do_compile_prepend() {
> 

So my concern is simply with the commit msg -- not the actual implementation.
What you have above looks correct to me.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/9] Fixes for a distro with a merged /usr

[Mark Hatle]

On 9/3/15 9:58 AM, Joshua Lock wrote:
> I've been playing around with building a distro with a merged /usr[1] and
> the following series fixes several issues I ran across in OE core metadata.

everything in '/' linked to '/usr/' or everything in '/usr/' linked down to '/'?

(I've seen both implementations... just curious which one you are trying.)

--Mark

> These have been build tested by building a core-image-sato image with
> ipk packaging for qemux86 with both a standard/default configuration and
> for my merged /usr test distro.
> 
> I used buildhistory to compare core-image-sato before and after this series
> and the only change is:
> 
> Changes to images/qemux86/glibc/core-image-sato (files-in-image.txt):
>   /bin/lsmod.kmod changed symlink target from ../bin/kmod to kmod
> 
> Regards,
> 
> Joshua
> 
> 1. https://wiki.freedesktop.org/www/Software/systemd/TheCaseForTheUsrMerge/
> 
> The following changes since commit bdeb32b4cdbe316f17c2fd854d59e05e8f2e8ffc:
> 
>   rt-tests: drop unnecessary added-missing-dependencies.patch (2015-09-01 
> 11:43:38 +0100)
> 
> are available in the git repository at:
> 
>   git://git.openembedded.org/openembedded-core-contrib joshuagl/merged-usr
>   
> http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=joshuagl/merged-usr
> 
> Joshua Lock (9):
>   kmod: fix link creation when base_bindir != /bin
>   busybox: fixes for when base_bindir != /bin
>   systemd: remove hard-coded paths in FILES entries
>   alsa-utils: handle udev dir being 2 levels below /
>   pulseaudio: handle udev dir being 2 levels below /
>   bluez: handle udev dir being 2 levels below /
>   pcmciautils: handle udev dir being 2 levels below /
>   nfs-utils: don't force use of /sbin as sbindir
>   procps: fix for base_sbindir == sbindir
> 
>  meta/recipes-bsp/pcmciautils/pcmciautils_018.bb|  4 +-
>  meta/recipes-connectivity/bluez5/bluez5.inc|  1 +
>  .../nfs-utils/nfs-utils_1.3.1.bb   |  8 
>  meta/recipes-core/busybox/busybox.inc  | 49 
> --
>  meta/recipes-core/systemd/systemd_219.bb   | 10 ++---
>  meta/recipes-extended/procps/procps_3.3.10.bb  |  5 ++-
>  meta/recipes-kernel/kmod/kmod_git.bb   |  4 +-
>  meta/recipes-multimedia/alsa/alsa-utils_1.0.29.bb  |  2 +-
>  meta/recipes-multimedia/pulseaudio/pulseaudio.inc  |  2 +-
>  9 files changed, 49 insertions(+), 36 deletions(-)
> 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/9] systemd: remove hard-coded paths in FILES entries

[Mark Hatle]

On 9/3/15 10:12 AM, Richard Purdie wrote:
> On Thu, 2015-09-03 at 15:58 +0100, Joshua Lock wrote:
>> Signed-off-by: Joshua Lock 
>> ---
>>  meta/recipes-core/systemd/systemd_219.bb | 10 +-
>>  1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/meta/recipes-core/systemd/systemd_219.bb 
>> b/meta/recipes-core/systemd/systemd_219.bb
>> index 4d32fd5..fbd86e8 100644
>> --- a/meta/recipes-core/systemd/systemd_219.bb
>> +++ b/meta/recipes-core/systemd/systemd_219.bb
>> @@ -306,10 +306,10 @@ FILES_${PN} = " ${base_bindir}/* \
>>  ${exec_prefix}/lib/sysctl.d \
>>  ${exec_prefix}/lib/sysusers.d \
>>  ${localstatedir} \
>> -/lib/udev/rules.d/70-uaccess.rules \
>> -/lib/udev/rules.d/71-seat.rules \
>> -/lib/udev/rules.d/73-seat-late.rules \
>> -/lib/udev/rules.d/99-systemd.rules \
>> +${base_libdir}/udev/rules.d/70-uaccess.rules \
>> +${base_libdir}/udev/rules.d/71-seat.rules \
>> +${base_libdir}/udev/rules.d/73-seat-late.rules \
>> +${base_libdir}/udev/rules.d/99-systemd.rules \
>> "
>>  
>>  FILES_${PN}-dbg += "${rootlibdir}/.debug ${systemd_unitdir}/.debug 
>> ${systemd_unitdir}/*/.debug ${base_libdir}/security/.debug/"
>> @@ -327,7 +327,7 @@ RRECOMMENDS_${PN} += "systemd-serialgetty 
>> systemd-vconsole-setup \
>>  
>>  PACKAGES =+ "udev-dbg udev udev-hwdb"
>>  
>> -FILES_udev-dbg += "/lib/udev/.debug"
>> +FILES_udev-dbg += "${base_libdir}/udev/.debug"
> 
> From what I remember, this is intentional and this change likely breaks
> multilib. You don't want two sets of rules on a multilib system.

Correct.. it has to go into /lib or if everything is move to /usr, then 
/usr/lib.

--Mark

> Cheers,
> 
> Richard
> 
> 
> 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/1] busybox: Use UTMPX instead of legacy UTMP

[Khem Raj]

This makes busybox honor UTMPX feature if available in a libc

[YOCTO #8243]

Signed-off-by: Khem Raj 
---
 .../busybox/0001-Switch-to-POSIX-utmpx-API.patch   | 388 +
 meta/recipes-core/busybox/busybox_1.23.2.bb|   1 +
 2 files changed, 389 insertions(+)
 create mode 100644 
meta/recipes-core/busybox/busybox/0001-Switch-to-POSIX-utmpx-API.patch

diff --git 
a/meta/recipes-core/busybox/busybox/0001-Switch-to-POSIX-utmpx-API.patch 
b/meta/recipes-core/busybox/busybox/0001-Switch-to-POSIX-utmpx-API.patch
new file mode 100644
index 000..1d299ee
--- /dev/null
+++ b/meta/recipes-core/busybox/busybox/0001-Switch-to-POSIX-utmpx-API.patch
@@ -0,0 +1,388 @@
+From 86a7f18f211af1abda5c855d2674b0fcb53de524 Mon Sep 17 00:00:00 2001
+From: Bernhard Reutner-Fischer 
+Date: Thu, 2 Apr 2015 23:03:46 +0200
+Subject: [PATCH] *: Switch to POSIX utmpx API
+
+UTMP is SVID legacy, UTMPX is mandated by POSIX.
+
+Glibc and uClibc have identical layout of UTMP and UTMPX, both of these
+libc treat _PATH_UTMPX as _PATH_UTMP so from a user-perspective nothing
+changes except the names of the API entrypoints.
+
+Signed-off-by: Bernhard Reutner-Fischer 
+---
+Upstream-Status: Backport
+
+ coreutils/who.c|  8 
+ include/libbb.h|  2 +-
+ init/halt.c|  4 ++--
+ libbb/utmp.c   | 44 ++--
+ miscutils/last.c   |  8 
+ miscutils/last_fancy.c | 16 ++--
+ miscutils/runlevel.c   | 12 ++--
+ miscutils/wall.c   |  8 
+ procps/uptime.c|  6 +++---
+ 9 files changed, 56 insertions(+), 52 deletions(-)
+
+diff --git a/coreutils/who.c b/coreutils/who.c
+index f955ce6..8337212 100644
+--- a/coreutils/who.c
 b/coreutils/who.c
+@@ -73,7 +73,7 @@ static void idle_string(char *str6, time_t t)
+ int who_main(int argc, char **argv) MAIN_EXTERNALLY_VISIBLE;
+ int who_main(int argc UNUSED_PARAM, char **argv)
+ {
+-  struct utmp *ut;
++  struct utmpx *ut;
+   unsigned opt;
+   int do_users = (ENABLE_USERS && (!ENABLE_WHO || applet_name[0] == 'u'));
+   const char *fmt = "%s";
+@@ -83,8 +83,8 @@ int who_main(int argc UNUSED_PARAM, char **argv)
+   if (opt & 2) // -H
+   printf("USER\t\tTTY\t\tIDLE\tTIME\t\t HOST\n");
+ 
+-  setutent();
+-  while ((ut = getutent()) != NULL) {
++  setutxent();
++  while ((ut = getutxent()) != NULL) {
+   if (ut->ut_user[0]
+&& ((opt & 1) || ut->ut_type == USER_PROCESS)
+   ) {
+@@ -126,6 +126,6 @@ int who_main(int argc UNUSED_PARAM, char **argv)
+   if (do_users)
+   bb_putchar('\n');
+   if (ENABLE_FEATURE_CLEAN_UP)
+-  endutent();
++  endutxent();
+   return EXIT_SUCCESS;
+ }
+diff --git a/include/libbb.h b/include/libbb.h
+index 26b6868..0f8363b 100644
+--- a/include/libbb.h
 b/include/libbb.h
+@@ -84,7 +84,7 @@
+ # include 
+ #endif
+ #if ENABLE_FEATURE_UTMP
+-# include 
++# include 
+ #endif
+ #if ENABLE_LOCALE_SUPPORT
+ # include 
+diff --git a/init/halt.c b/init/halt.c
+index 7974adb..ad12d91 100644
+--- a/init/halt.c
 b/init/halt.c
+@@ -74,7 +74,7 @@
+ 
+ static void write_wtmp(void)
+ {
+-  struct utmp utmp;
++  struct utmpx utmp;
+   struct utsname uts;
+   /* "man utmp" says wtmp file should *not* be created automagically */
+   /*if (access(bb_path_wtmp_file, R_OK|W_OK) == -1) {
+@@ -88,7 +88,7 @@ static void write_wtmp(void)
+   utmp.ut_line[0] = '~'; utmp.ut_line[1] = '~'; /* = strcpy(utmp.ut_line, 
"~~"); */
+   uname(&uts);
+   safe_strncpy(utmp.ut_host, uts.release, sizeof(utmp.ut_host));
+-  updwtmp(bb_path_wtmp_file, &utmp);
++  updwtmpx(bb_path_wtmp_file, &utmp);
+ }
+ #else
+ #define write_wtmp() ((void)0)
+diff --git a/libbb/utmp.c b/libbb/utmp.c
+index 8ad9ba2..bd07670 100644
+--- a/libbb/utmp.c
 b/libbb/utmp.c
+@@ -16,7 +16,7 @@ static void touch(const char *filename)
+ 
+ void FAST_FUNC write_new_utmp(pid_t pid, int new_type, const char *tty_name, 
const char *username, const char *hostname)
+ {
+-  struct utmp utent;
++  struct utmpx utent;
+   char *id;
+   unsigned width;
+ 
+@@ -45,17 +45,17 @@ void FAST_FUNC write_new_utmp(pid_t pid, int new_type, 
const char *tty_name, con
+   tty_name += 3;
+   strncpy(id, tty_name, width);
+ 
+-  touch(_PATH_UTMP);
+-  //utmpname(_PATH_UTMP);
+-  setutent();
++  touch(_PATH_UTMPX);
++  //utmpxname(_PATH_UTMPX);
++  setutxent();
+   /* Append new one (hopefully, unless we collide on ut_id) */
+-  pututline(&utent);
+-  endutent();
++  pututxline(&utent);
++  endutxent();
+ 
+ #if ENABLE_FEATURE_WTMP
+   /* "man utmp" says wtmp file should *not* be created automagically */
+   /*touch(bb_path_wtmp_file);*/
+-  updwtmp(bb_path_wtmp_file, &utent);
++  updwtmpx(bb_path_wtmp_file, &utent);
+ #endif
+ }
+ 
+@@ -64,17 +64,17 @@ vo

[OE-core] [PATCH 0/1] Busybox fix for utmpx

[Khem Raj]

Patch busybox to use utmpx if libc offers it

The following changes since commit bdeb32b4cdbe316f17c2fd854d59e05e8f2e8ffc:

  rt-tests: drop unnecessary added-missing-dependencies.patch (2015-09-01 
11:43:38 +0100)

are available in the git repository at:

  git://github.com/kraj/openembedded-core kraj/busybox_utmpx
  https://github.com/kraj/openembedded-core/tree/kraj/busybox_utmpx

Khem Raj (1):
  busybox: Use UTMPX instead of legacy UTMP

 .../busybox/0001-Switch-to-POSIX-utmpx-API.patch   | 388 +
 meta/recipes-core/busybox/busybox_1.23.2.bb|   1 +
 2 files changed, 389 insertions(+)
 create mode 100644 
meta/recipes-core/busybox/busybox/0001-Switch-to-POSIX-utmpx-API.patch

-- 
2.5.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] scripts: Create interactive menu for mkefidisk script

[Bottazzini, Bruno]

Bump

On Tue, 2015-09-01 at 16:22 -0300, Bruno Bottazzini wrote:
> If it is passed only the image parameter, it will show some interactive
> options to help to conclude the script.
> 
> With this patch it will detect devices available in the machine, asking
> to choose what it is wanted to be flashed.
> 
> it will suggest the target device. If it is a SD card the suggestion
> is /dev/mmcblk0. If it is a pendrive it will suggest to use /dev/sda.
> 
> Signed-off-by: Bruno Bottazzini 
> ---
>  scripts/contrib/mkefidisk.sh | 60 
> 
>  1 file changed, 55 insertions(+), 5 deletions(-)
> 
> diff --git a/scripts/contrib/mkefidisk.sh b/scripts/contrib/mkefidisk.sh
> index 55f72b0..7628de7 100755
> --- a/scripts/contrib/mkefidisk.sh
> +++ b/scripts/contrib/mkefidisk.sh
> @@ -152,8 +152,52 @@ unmount() {
>  # Parse and validate arguments
>  #
>  if [ $# -lt 3 ] || [ $# -gt 4 ]; then
> - usage
> - exit 1
> +if [ $# -eq 1 ]; then
> +AVAILABLE_DISK=`fdisk -l | grep "Disk /" | cut -f 1 -d ':' | cut -f 
> 2 -d ' '`
> +if [ -z "$AVAILABLE_DISK" ]; then
> +die "Starting mkefidisk.sh as root is required"
> +fi
> +echo "Available disks are"
> +X=0
> +for line in `echo $AVAILABLE_DISK`; do
> +info "$X - $line"
> +X=`expr $X + 1`
> +done
> +read -p "Choose flashable device number: " DISK_NUMBER
> +X=0
> +for line in `echo $AVAILABLE_DISK`; do
> +if [ $DISK_NUMBER -eq $X ]; then
> +DISK_TO_BE_FLASHED=$line
> +break
> +else
> +X=`expr $X + 1`
> +fi
> +done
> +if [ -z "$DISK_TO_BE_FLASHED" ]; then
> +die "Option \"$DISK_NUMBER\" is invalid. Choose a valid option"
> +else
> +if [ -z `echo $DISK_TO_BE_FLASHED | grep "mmc"` ]; then
> +TARGET_TO_BE_BOOT="/dev/sda"
> +else
> +TARGET_TO_BE_BOOT="/dev/mmcblk0"
> +fi
> +fi
> +echo ""
> +echo "Choose a name of the device that will be boot from"
> +echo -n "Recommended name is: "
> +info "$TARGET_TO_BE_BOOT\n"
> +read -p "Is target device okay? [y/N]: " RESPONSE
> +if [ "$RESPONSE" != "y" ]; then
> +read -p "Choose target device name: " TARGET_TO_BE_BOOT
> +fi
> +echo ""
> +if [ -z "$TARGET_TO_BE_BOOT" ]; then
> +die "Error: choose a valid target name"
> +fi
> +else
> +usage
> + exit 1
> +fi
>  fi
>  
>  if [ "$1" = "-v" ]; then
> @@ -162,9 +206,15 @@ if [ "$1" = "-v" ]; then
>   shift
>  fi
>  
> -DEVICE=$1
> -HDDIMG=$2
> -TARGET_DEVICE=$3
> +if [ -z "$AVAILABLE_DISK" ]; then
> +DEVICE=$1
> +HDDIMG=$2
> +TARGET_DEVICE=$3
> +else
> +DEVICE=$DISK_TO_BE_FLASHED
> +HDDIMG=$1
> +TARGET_DEVICE=$TARGET_TO_BE_BOOT
> +fi
>  
>  LINK=$(readlink $DEVICE)
>  if [ $? -eq 0 ]; then


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 04/12] gnome-icon-theme: remove the recipe

[Burton, Ross]

On 3 September 2015 at 16:34, Alexander Kanavin <
alexander.kana...@linux.intel.com> wrote:

> It is not used by anything in oe-core and will be moved to meta-gnome
>

I've a feeling that there are some apps in core-image-sato that actually
like to have gnome-icon-theme installed (specifically I'm thinking
pcmanfm).  We should probably check that they work correctly without this
installed (or more likely, show more icons when it is installed) before
removing it.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 06/12] mkelfimage: add RECIPE_NO_UPDATE_REASON

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-devtools/mkelfimage/mkelfimage_git.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-devtools/mkelfimage/mkelfimage_git.bb 
b/meta/recipes-devtools/mkelfimage/mkelfimage_git.bb
index 28aff91..2845b8c 100644
--- a/meta/recipes-devtools/mkelfimage/mkelfimage_git.bb
+++ b/meta/recipes-devtools/mkelfimage/mkelfimage_git.bb
@@ -6,6 +6,9 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=ea5bed2f60d357618ca161ad539f7c0a"
 
 SRCREV = "686a48a339b3200184c27e7f98d4c03180b2be6c"
 PV = "4.0+git${SRCPV}"
+RECIPE_NO_UPDATE_REASON = "mkelfimage has been removed in coreboot 4.1 
release: \
+http://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=34fc4ab80b507739e2580d490dff67fcfdde11ea";
+
 
 DEPENDS += "zlib"
 
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 05/12] libunique: remove the recipe

[Alexander Kanavin]

It is not used by anything in oe-core and will be moved to meta-oe

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-gnome/libunique/libunique/build.patch | 421 -
 .../libunique/fix_for_compile_with_gcc-4.6.0.patch |  36 --
 .../libunique/libunique/noconst.patch  | 130 ---
 meta/recipes-gnome/libunique/libunique_1.1.6.bb|  25 --
 4 files changed, 612 deletions(-)
 delete mode 100644 meta/recipes-gnome/libunique/libunique/build.patch
 delete mode 100644 
meta/recipes-gnome/libunique/libunique/fix_for_compile_with_gcc-4.6.0.patch
 delete mode 100644 meta/recipes-gnome/libunique/libunique/noconst.patch
 delete mode 100644 meta/recipes-gnome/libunique/libunique_1.1.6.bb

diff --git a/meta/recipes-gnome/libunique/libunique/build.patch 
b/meta/recipes-gnome/libunique/libunique/build.patch
deleted file mode 100644
index 46a5c62..000
--- a/meta/recipes-gnome/libunique/libunique/build.patch
+++ /dev/null
@@ -1,421 +0,0 @@
-Upstream-Status: Backport 
[http://git.gnome.org/browse/unique/commit/?h=unique-1.1&id=f75ca2d7aad7d27686acca6090c1c569a79d7e63]
-Signed-off-By: Ross Burton 
-
-From f75ca2d7aad7d27686acca6090c1c569a79d7e63 Mon Sep 17 00:00:00 2001
-From: Emmanuele Bassi 
-Date: Sat, 08 May 2010 11:17:21 +
-Subject: build: Update the build environment
-
-Require autoconf 2.63, automake 1.11 and libtool 2.2.6 to remove Shave.
-
-Also bump up the requirement for gobject-introspection to 0.6.7.

-diff --git a/build/autotools/Makefile.am b/build/autotools/Makefile.am
-index 5f35b85..b78428f 100644
 a/build/autotools/Makefile.am
-+++ b/build/autotools/Makefile.am
-@@ -1,7 +1,4 @@
- EXTRA_DIST = \
--  shave-libtool.in\
--  shave.in\
--  shave.m4\
-   as-compiler-flag.m4 \
-   introspection.m4\
-   Makefile.am.enums   \
-diff --git a/build/autotools/Makefile.am.silent 
b/build/autotools/Makefile.am.silent
-index 249f6af..8576846 100644
 a/build/autotools/Makefile.am.silent
-+++ b/build/autotools/Makefile.am.silent
-@@ -1,10 +1,5 @@
- # custom rules for quiet builds
- 
--if USE_SHAVE
--QUIET_GEN = $(Q:@=@echo '  GEN   '$@;)
--QUIET_LN  = $(Q:@=@echo '  LN'$@;)
--QUIET_RM  = $(Q:@=@echo '  RM'$@;)
--else
- QUIET_GEN = $(AM_V_GEN)
- 
- QUIET_LN   = $(QUIET_LN_$(V))
-@@ -14,4 +9,3 @@ QUIET_LN_0 = @echo '  LN '$@;
- QUIET_RM   = $(QUIET_RM_$(V))
- QUIET_RM_  = $(QUIET_RM_$(AM_DEFAULT_VERBOSITY))
- QUIET_RM_0 = @echo '  RM '$@;
--endif # USE_SHAVE
-diff --git a/build/autotools/introspection.m4 
b/build/autotools/introspection.m4
-index f9ce49c..589721c 100644
 a/build/autotools/introspection.m4
-+++ b/build/autotools/introspection.m4
-@@ -59,12 +59,18 @@ m4_define([_GOBJECT_INTROSPECTION_CHECK_INTERNAL],
-INTROSPECTION_GENERATE=`$PKG_CONFIG --variable=g_ir_generate 
gobject-introspection-1.0`
-INTROSPECTION_GIRDIR=`$PKG_CONFIG --variable=girdir 
gobject-introspection-1.0`
-INTROSPECTION_TYPELIBDIR="$($PKG_CONFIG --variable=typelibdir 
gobject-introspection-1.0)"
-+   INTROSPECTION_CFLAGS=`$PKG_CONFIG --cflags gobject-introspection-1.0`
-+   INTROSPECTION_LIBS=`$PKG_CONFIG --libs gobject-introspection-1.0`
-+   INTROSPECTION_MAKEFILE=`$PKG_CONFIG --variable=datadir 
gobject-introspection-1.0`/gobject-introspection-1.0/Makefile.introspection
- fi
- AC_SUBST(INTROSPECTION_SCANNER)
- AC_SUBST(INTROSPECTION_COMPILER)
- AC_SUBST(INTROSPECTION_GENERATE)
- AC_SUBST(INTROSPECTION_GIRDIR)
- AC_SUBST(INTROSPECTION_TYPELIBDIR)
-+AC_SUBST(INTROSPECTION_CFLAGS)
-+AC_SUBST(INTROSPECTION_LIBS)
-+AC_SUBST(INTROSPECTION_MAKEFILE)
- 
- AM_CONDITIONAL(HAVE_INTROSPECTION, test "x$found_introspection" = "xyes")
- ])
-diff --git a/build/autotools/shave-libtool.in 
b/build/autotools/shave-libtool.in
-deleted file mode 100644
-index 1f3a720..000
 a/build/autotools/shave-libtool.in
-+++ b/dev/null
-@@ -1,69 +0,0 @@
--#!/bin/sh
--
--# we need sed
--SED=@SED@
--if test -z "$SED" ; then
--SED=sed
--fi
--
--lt_unmangle ()
--{
--   last_result=`echo $1 | $SED -e 's#.libs/##' -e 's#[0-9a-zA-Z_\-\.]*_la-##'`
--}
--
--# the real libtool to use
--LIBTOOL="$1"
--shift
--
--# if 1, don't print anything, the underlaying wrapper will do it
--pass_though=0
--
--# scan the arguments, keep the right ones for libtool, and discover the mode
--preserved_args=
--while test "$#" -gt 0; do
--opt="$1"
--shift
--
--case $opt in
----mode=*)
--mode=`echo $opt | $SED -e 's/[-_a-zA-Z0-9]*=//'`
--preserved_args="$preserved_args $opt"
--;;
---o)
--lt_output="$1"
--preserved_args="$preserved_args $opt"
--  ;;
--*)
--preserved_args="$preserved_args $opt"
--;;
--  esac
--done
--
--case "$mode" in
--compile)
--# shave will be called and print the actual CC/CXX/LINK line
--preserved_args="$preserved_args --shave-mode=$mode"
--pass_though=1
--   

[OE-core] [PATCH 01/12] ccache: update to 3.2.3

[Alexander Kanavin]

The LICENSE checksum has changed because of updated copyright years.

SRC_URI has been changed to git, because upstream tarball is broken
(includes configure.ac but not .m4 files it depends on).

Add a backported patch that fixes builds with older versions of make
and external zlib.

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-devtools/ccache/ccache.inc|  4 +-
 meta/recipes-devtools/ccache/ccache_3.1.11.bb  |  7 ---
 meta/recipes-devtools/ccache/ccache_3.2.3.bb   |  8 +++
 ...ion-in-recent-change-related-to-zlib-in-n.patch | 73 ++
 4 files changed, 84 insertions(+), 8 deletions(-)
 delete mode 100644 meta/recipes-devtools/ccache/ccache_3.1.11.bb
 create mode 100644 meta/recipes-devtools/ccache/ccache_3.2.3.bb
 create mode 100644 
meta/recipes-devtools/ccache/files/0001-Fix-regression-in-recent-change-related-to-zlib-in-n.patch

diff --git a/meta/recipes-devtools/ccache/ccache.inc 
b/meta/recipes-devtools/ccache/ccache.inc
index 087cb7d..4790021 100644
--- a/meta/recipes-devtools/ccache/ccache.inc
+++ b/meta/recipes-devtools/ccache/ccache.inc
@@ -9,7 +9,9 @@ LICENSE = "GPLv3+"
 
 DEPENDS = "zlib"
 
-SRC_URI = "http://samba.org/ftp/ccache/ccache-${PV}.tar.xz";
+SRC_URI = "git://git.samba.org/ccache.git"
+
+S = "${WORKDIR}/git"
 
 inherit autotools
 
diff --git a/meta/recipes-devtools/ccache/ccache_3.1.11.bb 
b/meta/recipes-devtools/ccache/ccache_3.1.11.bb
deleted file mode 100644
index 7696003..000
--- a/meta/recipes-devtools/ccache/ccache_3.1.11.bb
+++ /dev/null
@@ -1,7 +0,0 @@
-require ccache.inc
-
-LICENSE = "GPLv3+"
-LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=80e92ec45d4fca91f127864fb9e5d932"
-
-SRC_URI[md5sum] = "0f6df80c8941d9020a1fd5df5ad57dd7"
-SRC_URI[sha256sum] = 
"60e9f3f1e60f528cfce910f3224bcc698029320f6ab77ec09a7b46bda2bc678e"
diff --git a/meta/recipes-devtools/ccache/ccache_3.2.3.bb 
b/meta/recipes-devtools/ccache/ccache_3.2.3.bb
new file mode 100644
index 000..357df75
--- /dev/null
+++ b/meta/recipes-devtools/ccache/ccache_3.2.3.bb
@@ -0,0 +1,8 @@
+require ccache.inc
+
+LICENSE = "GPLv3+"
+LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=b3c337e7664559a789d9f7a93e5283c1"
+
+SRCREV = "4cad46e8ee0053144bb00919f0dadd20c1f87013"
+
+SRC_URI += 
"file://0001-Fix-regression-in-recent-change-related-to-zlib-in-n.patch"
diff --git 
a/meta/recipes-devtools/ccache/files/0001-Fix-regression-in-recent-change-related-to-zlib-in-n.patch
 
b/meta/recipes-devtools/ccache/files/0001-Fix-regression-in-recent-change-related-to-zlib-in-n.patch
new file mode 100644
index 000..a8400d5
--- /dev/null
+++ 
b/meta/recipes-devtools/ccache/files/0001-Fix-regression-in-recent-change-related-to-zlib-in-n.patch
@@ -0,0 +1,73 @@
+From f74c76107933046309861680b741adc67ac2a34e Mon Sep 17 00:00:00 2001
+From: Joel Rosdahl 
+Date: Mon, 17 Aug 2015 19:05:14 +0200
+Subject: [PATCH] Fix regression in recent change related to zlib in
+ nonstandard location
+
+To allow for specifying a -L flag in LDFLAGS and have it take effect for
+-lz, 0220de9c8ebfb18caae2ac1aa163d060e98ceade put -lz in extra_libs
+instead of extra_ldflags. However, extra_libs is supposed to contain
+paths to libraries which are prerequisites of the ccache link rule, and
+some older versions of make got confused by seeing -lz as a
+prerequisite.
+
+This fix is to revert 0220de9c8ebfb18caae2ac1aa163d060e98ceade and
+instead make sure that LDFLAGS comes before extra_ldflags.
+
+Upstream-status: Backport
+---
+ Makefile.in  |  2 +-
+ NEWS.txt | 10 ++
+ configure.ac |  2 +-
+ 3 files changed, 12 insertions(+), 2 deletions(-)
+
+diff --git a/Makefile.in b/Makefile.in
+index e7515b1..d3621cd 100644
+--- a/Makefile.in
 b/Makefile.in
+@@ -20,7 +20,7 @@ RANLIB = @RANLIB@
+ 
+ all_cflags = $(CFLAGS)
+ all_cppflags = @DEFS@ @extra_cppflags@ -DSYSCONFDIR=$(sysconfdir) -I. 
-I$(srcdir) $(CPPFLAGS)
+-all_ldflags = @extra_ldflags@ $(LDFLAGS)
++all_ldflags = $(LDFLAGS) @extra_ldflags@
+ extra_libs = @extra_libs@
+ 
+ base_sources = \
+diff --git a/NEWS.txt b/NEWS.txt
+index f13feeb..eaeadf6 100644
+--- a/NEWS.txt
 b/NEWS.txt
+@@ -2,6 +2,16 @@ ccache news
+ ===
+ 
+ 
++Unreleased 3.2.4
++
++
++Bug fixes
++~
++
++- Fixed build error related to zlib on systems with older make versions
++  (regression in ccache 3.2.3).
++
++
+ ccache 3.2.3
+ 
+ Release date: 2015-08-16
+diff --git a/configure.ac b/configure.ac
+index 8d8ce92..9e65588 100644
+--- a/configure.ac
 b/configure.ac
+@@ -120,7 +120,7 @@ if test x${use_bundled_zlib} = xyes; then
+ extra_libs="zlib/libz.a"
+ mkdir -p zlib
+ else
+-extra_libs="-lz"
++extra_ldflags="-lz"
+ fi
+ 
+ dnl Linking on Windows needs ws2_32
+-- 
+2.1.4
+
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 03/12] net-tools: update to 1.60-25

[Alexander Kanavin]

This means fetching a newer Debian patchset which adds a few
bug/security fixes.

Signed-off-by: Alexander Kanavin 
---
 .../net-tools/{net-tools_1.60-25.bb => net-tools_1.60-26.bb}| 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
 rename meta/recipes-extended/net-tools/{net-tools_1.60-25.bb => 
net-tools_1.60-26.bb} (91%)

diff --git a/meta/recipes-extended/net-tools/net-tools_1.60-25.bb 
b/meta/recipes-extended/net-tools/net-tools_1.60-26.bb
similarity index 91%
rename from meta/recipes-extended/net-tools/net-tools_1.60-25.bb
rename to meta/recipes-extended/net-tools/net-tools_1.60-26.bb
index c47d69a..aefc1e6 100644
--- a/meta/recipes-extended/net-tools/net-tools_1.60-25.bb
+++ b/meta/recipes-extended/net-tools/net-tools_1.60-26.bb
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=8ca43cbc842c2336e835926c2166c28b \
 
file://ifconfig.c;beginline=11;endline=15;md5=d1ca372080ad5401e23ca0afc35cf9ba"
 
 SRC_URI = 
"http://snapshot.debian.org/archive/debian/20050312T00Z/pool/main/n/${BPN}/${BPN}_1.60.orig.tar.gz;name=tarball
 \
-   
http://snapshot.debian.org/archive/debian/20130511T214653Z/pool/main/n/${BPN}/${BPN}_${PV}.diff.gz;apply=no;name=patch
 \
+   
http://snapshot.debian.org/archive/debian//20150831T093342Z/pool/main/n/${BPN}/${BPN}_${PV}.diff.gz;apply=no;name=patch
 \
file://net-tools-config.h \
file://net-tools-config.make \
file://ifconfig-interface-0-del-IP-will-remove-the-aliased-.patch \
@@ -18,8 +18,8 @@ S = "${WORKDIR}/net-tools-1.60"
 SRC_URI[tarball.md5sum] = "ecaf37acb5b5daff4bdda77785fd916d"
 SRC_URI[tarball.sha256sum] = 
"ec67967cf7b1a3a3828a84762fbc013ac50ee5dc9aa3095d5c591f302c2de0f5"
 
-SRC_URI[patch.md5sum] = "5ab1e2184d0fa6518031291138f2fc51"
-SRC_URI[patch.sha256sum] = 
"1bddcd96ac60e794978cb20fb7ea4c2e77258c56c042c9ac8b6ec2b2033bc56f"
+SRC_URI[patch.md5sum] = "ea3592f49ac8380962bc4d9b66c7e7e9"
+SRC_URI[patch.sha256sum] = 
"aeeeafaff68866a446f01bb639d4e0146a60af34dcd20e31a3e46585022fc76c"
 
 inherit gettext
 
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 12/12] package_regex.inc: various updates to improve RRS accuracy

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin 
---
 meta/conf/distro/include/package_regex.inc | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/meta/conf/distro/include/package_regex.inc 
b/meta/conf/distro/include/package_regex.inc
index df384e2..8fc112c 100644
--- a/meta/conf/distro/include/package_regex.inc
+++ b/meta/conf/distro/include/package_regex.inc
@@ -44,6 +44,8 @@ REGEX_pn-nettle = "nettle-(?P\d+(\.\d+)+)\.tar"
 
 REGEX_pn-cairo = "cairo-(?P\d+(\.\d+)+)\.tar"
 REGEX_pn-cmake = "cmake-(?P\d+(\.\d+)+)\.tar"
+REGEX_pn-libsdl = "SDL-(?P\d+(\.\d+)+)\.tar"
+REGEX_pn-libxslt = "libxslt-(?P\d+(\.\d+)+)\.tar"
 
 # Exclude NC versions which lack AES encryption
 REGEX_pn-db = "db-(?P\d+\.\d+(\.\d+)?).tar"
@@ -171,9 +173,8 @@ REGEX_URI_pn-libpng12 = 
"http://sourceforge.net/projects/libpng/files/libpng12/";
 REGEX_pn-libpng12 = "/libpng12/${COMMON_REGEX}/"
 REGEX_URI_pn-docbook-dsssl-stylesheets = 
"http://sourceforge.net/projects/docbook/files/docbook-dsssl/";
 REGEX_pn-docbook-dsssl-stylesheets = "/docbook-dsssl/${COMMON_REGEX}/"
-REGEX_URI_pn-openjade = 
"http://sourceforge.net/projects/openjade/files/openjade/";
-REGEX_pn-openjade = "/openjade/${COMMON_REGEX}/"
 
+REGEX_URI_pn-openjade = "http://openjade.sourceforge.net/download.html";
 REGEX_URI_pn-libpfm4 = 
"http://sourceforge.net/projects/perfmon2/files/libpfm4/";
 REGEX_URI_pn-liba52 = "http://liba52.sourceforge.net/downloads.html";
 REGEX_URI_pn-mpeg2dec = "http://libmpeg2.sourceforge.net/downloads.html";
@@ -202,6 +203,10 @@ GITTAGREGEX_pn-mx-1.0 = "(?P^\d+(\.(?!99)\d+)+)"
 
 # Blacklist a bogus tag
 GITTAGREGEX_pn-file = "FILE(?P(?!6_23).+)"
+GITTAGREGEX_pn-xinetd = "xinetd-(?P(?!20030122).+)"
+
+# Blacklist debian-specific tags
+GITTAGREGEX_pn-xf86-video-omapfb = "(?P\d+(\.\d+)+)(?!-)"
 
 # GNOME related.
 #
@@ -231,6 +236,7 @@ REGEX_pn-clutter-gtk-1.0 = "${GNOME_STABLE}"
 REGEX_pn-clutter-gst-3.0 = "${GNOME_STABLE}"
 REGEX_pn-cogl-1.0 = "${GNOME_STABLE}"
 REGEX_pn-adwaita-icon-theme = "${GNOME_STABLE}"
+REGEX_pn-vte = "${GNOME_STABLE}"
 
 # not GNOME related but uses same even-minor-release-is-stable logic
 REGEX_pn-dbus = "${GNOME_STABLE}"
@@ -249,7 +255,7 @@ REGEX_pn-gstreamer1.0-rtsp-server = "${GNOME_STABLE}"
 REGEX_pn-perl = "${GNOME_STABLE}"
 
 # Keep old gcc versions at their major versions
-REGEX_pn-gcc-source-4.9.2 = "gcc-(?P4\.9\.\d+).tar"
+REGEX_pn-gcc-source-4.9.3 = "gcc-(?P4\.9\.\d+).tar"
 REGEX_pn-gcc-source-4.8.4 = "gcc-(?P4\.8\.\d+).tar"
 
 # these packages are taken from snapshots.debian.org; that source is static 
and goes stale
@@ -267,6 +273,4 @@ DEBIAN_PATCH_REGEX = 
"(?P((\d+\.*)+)-((\d+\.*)+))\.(diff|debian\.tar)\.(gz
 REGEX_pn-net-tools = "${DEBIAN_PATCH_REGEX}"
 REGEX_pn-apmd = "${DEBIAN_PATCH_REGEX}"
 REGEX_pn-blktool = "${DEBIAN_PATCH_REGEX}"
-# mailx is fetched from launchpad
-REGEX_URI_pn-mailx = "${DEBIAN_MIRROR}/main/h/heirloom-mailx/"
 REGEX_pn-mailx = "${DEBIAN_PATCH_REGEX}"
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 10/12] uclibc: update PV to 0.9.33.2 to match latest upstream release

[Alexander Kanavin]

This fixes upstream version check. The git revision that is fetched
is unchanged.

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-core/uclibc/uclibc-git.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/uclibc/uclibc-git.inc 
b/meta/recipes-core/uclibc/uclibc-git.inc
index 14a577f..f4af36a 100644
--- a/meta/recipes-core/uclibc/uclibc-git.inc
+++ b/meta/recipes-core/uclibc/uclibc-git.inc
@@ -1,6 +1,6 @@
 SRCREV = "ca1c74d67dd115d059a875150e10b8560a9c35a8"
 
-PV = "0.9.33+git${SRCPV}"
+PV = "0.9.33.2+git${SRCPV}"
 
 FILESEXTRAPATHS =. "${FILE_DIRNAME}/uclibc-git:"
 
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 09/12] remake: update to 4.1+dbg-1.1

[Alexander Kanavin]

remake-remove-errors-about-colophon-and-cygnus-comma.patch has been merged 
upstream

inherit pkgconfig has been added because m4 macros defined by pkgconfig are now 
used
in configure.ac

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-devtools/remake/remake.inc|  4 +--
 ...ve-errors-about-colophon-and-cygnus-comma.patch | 39 --
 .../{remake_git.bb => remake_4.1+dbg-1.1.bb}   |  8 ++---
 3 files changed, 4 insertions(+), 47 deletions(-)
 delete mode 100644 
meta/recipes-devtools/remake/remake/remake-remove-errors-about-colophon-and-cygnus-comma.patch
 rename meta/recipes-devtools/remake/{remake_git.bb => remake_4.1+dbg-1.1.bb} 
(80%)

diff --git a/meta/recipes-devtools/remake/remake.inc 
b/meta/recipes-devtools/remake/remake.inc
index 6ac833e..df889fc 100644
--- a/meta/recipes-devtools/remake/remake.inc
+++ b/meta/recipes-devtools/remake/remake.inc
@@ -1,4 +1,4 @@
-SUMMARY = "Makefile debugger which is gnumake 3.81 compatible"
+SUMMARY = "Makefile debugger which is gnumake compatible"
 DESCRIPTION = "remake is a patched and modernized version of GNU make \
 utility that adds improved error reporting, the ability to trace \
 execution in a comprehensible way, and a debugger."
@@ -8,7 +8,7 @@ SECTION = "devel"
 
 SRC_URI = "git://github.com/rocky/remake.git"
 
-inherit autotools gettext update-alternatives
+inherit autotools gettext update-alternatives pkgconfig
 
 ALTERNATIVE_${PN} = "make"
 ALTERNATIVE_LINK_NAME[make] = "${bindir}/make"
diff --git 
a/meta/recipes-devtools/remake/remake/remake-remove-errors-about-colophon-and-cygnus-comma.patch
 
b/meta/recipes-devtools/remake/remake/remake-remove-errors-about-colophon-and-cygnus-comma.patch
deleted file mode 100644
index 98b6460..000
--- 
a/meta/recipes-devtools/remake/remake/remake-remove-errors-about-colophon-and-cygnus-comma.patch
+++ /dev/null
@@ -1,39 +0,0 @@
-From 1316f10a97a4a2f5d11a30ec367aa61101318742 Mon Sep 17 00:00:00 2001
-From: "Maxin B. John" 
-Date: Wed, 6 Aug 2014 15:05:56 +0200
-Subject: [PATCH] remake: remove errors about @colophon and @cygnus commands
- not defined
-
-texinfo5 needs replacing @ with @@ when it is part of the text
-
-Upstream-Status: Backport
-Signed-off-by: Maxin B. John 

- doc/remake.texi | 4 ++--
- 1 file changed, 2 insertions(+), 2 deletions(-)
-
-diff --git a/doc/remake.texi b/doc/remake.texi
-index cd73437..fa5ba16 100644
 a/doc/remake.texi
-+++ b/doc/remake.texi
-@@ -2752,7 +2752,7 @@ this list, we would like to add your names!
- @printindex cp
- 
- @tex
--% I think something like @colophon should be in texinfo.  In the
-+% I think something like @@colophon should be in texinfo.  In the
- % meantime:
- \long\def\colophon{\hbox to0pt{}\vfill
- \centerline{The body of this manual is set in}
-@@ -2764,7 +2764,7 @@ this list, we would like to add your names!
- \centerline{{\sl\fontname\tensl\/}}
- \centerline{are used for emphasis.}\vfill}
- \page\colophon
--% Blame: d...@cygnus.com, 1991.
-+% Blame: doc@@cygnus.com, 1991.
- @end tex
- 
- @bye
--- 
-1.9.1
-
diff --git a/meta/recipes-devtools/remake/remake_git.bb 
b/meta/recipes-devtools/remake/remake_4.1+dbg-1.1.bb
similarity index 80%
rename from meta/recipes-devtools/remake/remake_git.bb
rename to meta/recipes-devtools/remake/remake_4.1+dbg-1.1.bb
index 2ba2b80..c61913d 100644
--- a/meta/recipes-devtools/remake/remake_git.bb
+++ b/meta/recipes-devtools/remake/remake_4.1+dbg-1.1.bb
@@ -1,4 +1,3 @@
-PR = "r1"
 LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
 file://tests/COPYING;md5=d32239bcb673463ab874e80d47fae504 \
@@ -6,14 +5,11 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
 require remake.inc
 
 SRC_URI += "file://version-remake.texi.patch \
-file://remake-remove-errors-about-colophon-and-cygnus-comma.patch \
"
-SRCREV = "f05508e521987c8494c92d9c2871aec46307d51d"
+SRCREV = "cf54641d50a0165bb17622b3e9770f426ccbc561"
 S = "${WORKDIR}/git"
 
-PV = "3.82+dbg-0.9+git${SRCPV}"
-
-DEPENDS += "readline"
+DEPENDS += "readline guile"
 # Need to add "gettext-native" dependency to remake-native.
 # By default only "gettext-minimal-native" is added
 # when inherit gettext.
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 11/12] vte: add RECIPE_NO_UPDATE_REASON

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-support/vte/vte_0.28.2.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-support/vte/vte_0.28.2.bb 
b/meta/recipes-support/vte/vte_0.28.2.bb
index 68bc16d..b1025cb 100644
--- a/meta/recipes-support/vte/vte_0.28.2.bb
+++ b/meta/recipes-support/vte/vte_0.28.2.bb
@@ -10,3 +10,5 @@ CFLAGS += "-D_GNU_SOURCE"
 
 SRC_URI[archive.md5sum] = "497f26e457308649e6ece32b3bb142ff"
 SRC_URI[archive.sha256sum] = 
"86cf0b81aa023fa93ed415653d51c96767f20b2d7334c893caba71e42654b0ae"
+
+RECIPE_NO_UPDATE_REASON = "matchbox-terminal needs to be ported over to new 
vte first"
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 07/12] python-async: update to 0.6.2

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin 
---
 .../python/{python-async_0.6.1.bb => python-async_0.6.2.bb}   | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-devtools/python/{python-async_0.6.1.bb => 
python-async_0.6.2.bb} (77%)

diff --git a/meta/recipes-devtools/python/python-async_0.6.1.bb 
b/meta/recipes-devtools/python/python-async_0.6.2.bb
similarity index 77%
rename from meta/recipes-devtools/python/python-async_0.6.1.bb
rename to meta/recipes-devtools/python/python-async_0.6.2.bb
index 1794820..8ed0b03 100644
--- a/meta/recipes-devtools/python/python-async_0.6.1.bb
+++ b/meta/recipes-devtools/python/python-async_0.6.2.bb
@@ -5,8 +5,8 @@ LICENSE = "BSD"
 LIC_FILES_CHKSUM = 
"file://PKG-INFO;beginline=8;endline=8;md5=88df8e78b9edfd744953862179f2d14e"
 
 SRC_URI = "http://pypi.python.org/packages/source/a/async/async-${PV}.tar.gz";
-SRC_URI[md5sum] = "6f0e2ced1fe85f8410b9bde11be08587"
-SRC_URI[sha256sum] = 
"41d14cc0456e03f34d13af284f65821d07d05c20e621bcaebd38f9ab5095d5d1"
+SRC_URI[md5sum] = "9b06b5997de2154f3bc0273f80bcef6b"
+SRC_URI[sha256sum] = 
"ac6894d876e45878faae493b0cf61d0e28ec417334448ac0a6ea2229d8343051"
 
 S = "${WORKDIR}/async-${PV}"
 
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 04/12] gnome-icon-theme: remove the recipe

[Alexander Kanavin]

It is not used by anything in oe-core and will be moved to meta-gnome

Signed-off-by: Alexander Kanavin 
---
 .../gnome/gnome-icon-theme/pkgconfig-native.patch  | 28 --
 .../recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb | 22 -
 2 files changed, 50 deletions(-)
 delete mode 100644 
meta/recipes-gnome/gnome/gnome-icon-theme/pkgconfig-native.patch
 delete mode 100644 meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb

diff --git a/meta/recipes-gnome/gnome/gnome-icon-theme/pkgconfig-native.patch 
b/meta/recipes-gnome/gnome/gnome-icon-theme/pkgconfig-native.patch
deleted file mode 100644
index 6139eab..000
--- a/meta/recipes-gnome/gnome/gnome-icon-theme/pkgconfig-native.patch
+++ /dev/null
@@ -1,28 +0,0 @@
-icon-naming-utils is a native dependency so we need to use the native 
pkg-config
-to find it.  Simply perform the old switcheroonie on $PKG_CONFIG so
-pkg-config-native is used temporarily.
-
-Upstream-Status: Inappropriate (OE-specific)
-Signed-off-by: Ross Burton 
-
-diff --git a/configure.ac b/configure.ac
-index 6074f2c..3d38e49 100644
 a/configure.ac
-+++ b/configure.ac
-@@ -40,6 +40,8 @@ if test "x$enable_mapping" != "xno"; then
-UTILS_REQUIRED=0.8.7
- 
-AC_MSG_CHECKING([icon-naming-utils >= $UTILS_REQUIRED])
-+   save_PKG_CONFIG=$PKG_CONFIG
-+   PKG_CONFIG=pkg-config-native
-PKG_CHECK_EXISTS(icon-naming-utils >= $UTILS_REQUIRED,
- have_utils=yes, have_utils=no)
-if test "x$have_utils" = "xyes"; then
-@@ -51,6 +53,7 @@ if test "x$enable_mapping" != "xno"; then
-   AC_MSG_ERROR([icon-naming-utils >= $UTILS_REQUIRED is required to build
- and install gnome-icon-theme])
-fi
-+   PKG_CONFIG=save_PKG_CONFIG
- else
-ICONMAP="false"
- fi
diff --git a/meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb 
b/meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb
deleted file mode 100644
index a6a3afa..000
--- a/meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb
+++ /dev/null
@@ -1,22 +0,0 @@
-SUMMARY = "GNOME 2 default icon themes"
-HOMEPAGE = "http://www.gnome.org/";
-BUGTRACKER = "https://bugzilla.gnome.org/";
-SECTION = "x11/gnome"
-
-LICENSE = "LGPLv3+ | CC-BY-SA-3.0"
-LIC_FILES_CHKSUM = "file://COPYING;md5=e7e289d90fc8bdceed5e3f142f98229e"
-
-PR = "r5"
-
-DEPENDS = "icon-naming-utils-native intltool-native libxml-simple-perl-native"
-
-inherit allarch autotools perlnative gtk-icon-cache pkgconfig gettext
-
-SRC_URI = "${GNOME_MIRROR}/${BPN}/2.31/${BPN}-${PV}.tar.bz2 \
-   file://pkgconfig-native.patch"
-
-SRC_URI[md5sum] = "8e727703343d4c18c73c79dd2009f8ed"
-SRC_URI[sha256sum] = 
"ea7e05b77ead159379392b3b275ca0c9cbacd7d936014e447cc7c5e27a767982"
-
-FILES_${PN} += "${datadir}/*"
-RRECOMMENDS_${PN} += "librsvg-gtk"
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 02/12] mailx: update to 12.5-5

[Alexander Kanavin]

This means adding new patches from Debian[1] and tweaking build options
that were previously set by patching Makefile.

[1] ftp://ftp.debian.org/debian/pool/main/h/heirloom-mailx/

Signed-off-by: Alexander Kanavin 
---
 ...e-weak-symbol-optopt-to-fix-FTBFS-on-mips.patch |  59 +++
 ...-SSL2-support-since-it-is-no-longer-suppo.patch |  41 
 ...ntian-warning-warning-macro-N-not-defined.patch |  25 +
 .../0011-outof-Introduce-expandaddr-flag.patch |  70 +
 ...ble-option-processing-for-email-addresses.patch |  79 ++
 ...c-Unconditionally-require-wordexp-support.patch | 113 +
 ...4-globname-Invoke-wordexp-with-WRDE_NOCMD.patch |  30 ++
 .../mailx/files/0015-usr-sbin-sendmail.patch   |  38 +++
 .../explicitly.disable.krb5.support.patch  |   0
 .../mailx/{mailx_12.5.bb => mailx_12.5-5.bb}   |  21 ++--
 10 files changed, 469 insertions(+), 7 deletions(-)
 create mode 100644 
meta/recipes-extended/mailx/files/0001-Don-t-reuse-weak-symbol-optopt-to-fix-FTBFS-on-mips.patch
 create mode 100644 
meta/recipes-extended/mailx/files/0002-Patched-out-SSL2-support-since-it-is-no-longer-suppo.patch
 create mode 100644 
meta/recipes-extended/mailx/files/0003-Fixed-Lintian-warning-warning-macro-N-not-defined.patch
 create mode 100644 
meta/recipes-extended/mailx/files/0011-outof-Introduce-expandaddr-flag.patch
 create mode 100644 
meta/recipes-extended/mailx/files/0012-unpack-Disable-option-processing-for-email-addresses.patch
 create mode 100644 
meta/recipes-extended/mailx/files/0013-fio.c-Unconditionally-require-wordexp-support.patch
 create mode 100644 
meta/recipes-extended/mailx/files/0014-globname-Invoke-wordexp-with-WRDE_NOCMD.patch
 create mode 100644 
meta/recipes-extended/mailx/files/0015-usr-sbin-sendmail.patch
 rename meta/recipes-extended/mailx/{mailx-12.5 => 
files}/explicitly.disable.krb5.support.patch (100%)
 rename meta/recipes-extended/mailx/{mailx_12.5.bb => mailx_12.5-5.bb} (48%)

diff --git 
a/meta/recipes-extended/mailx/files/0001-Don-t-reuse-weak-symbol-optopt-to-fix-FTBFS-on-mips.patch
 
b/meta/recipes-extended/mailx/files/0001-Don-t-reuse-weak-symbol-optopt-to-fix-FTBFS-on-mips.patch
new file mode 100644
index 000..126f505
--- /dev/null
+++ 
b/meta/recipes-extended/mailx/files/0001-Don-t-reuse-weak-symbol-optopt-to-fix-FTBFS-on-mips.patch
@@ -0,0 +1,59 @@
+From: Luk Claes 
+Date: Sat, 4 Jul 2009 10:54:53 +0200
+Subject: Don't reuse weak symbol optopt to fix FTBFS on mips*
+
+This patch is taken from 
+ftp://ftp.debian.org/debian/pool/main/h/heirloom-mailx/heirloom-mailx_12.5-5.debian.tar.xz
+
+Upstream-status: Inappropriate [upstream is dead]
+---
+ getopt.c |   10 +-
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/getopt.c b/getopt.c
+index 83ce628..82e983c 100644
+--- a/getopt.c
 b/getopt.c
+@@ -43,7 +43,7 @@ typedef  int ssize_t;
+ char  *optarg;
+ int   optind = 1;
+ int   opterr = 1;
+-int   optopt;
++int   optoptc;
+ 
+ static void
+ error(const char *s, int c)
+@@ -69,7 +69,7 @@ error(const char *s, int c)
+   *bp++ = *s++;
+   while (*msg)
+   *bp++ = *msg++;
+-  *bp++ = optopt;
++  *bp++ = optoptc;
+   *bp++ = '\n';
+   write(2, buf, bp - buf);
+   ac_free(buf);
+@@ -101,13 +101,13 @@ getopt(int argc, char *const argv[], const char 
*optstring)
+   }
+   curp = &argv[optind][1];
+   }
+-  optopt = curp[0] & 0377;
++  optoptc = curp[0] & 0377;
+   while (optstring[0]) {
+   if (optstring[0] == ':') {
+   optstring++;
+   continue;
+   }
+-  if ((optstring[0] & 0377) == optopt) {
++  if ((optstring[0] & 0377) == optoptc) {
+   if (optstring[1] == ':') {
+   if (curp[1] != '\0') {
+   optarg = (char *)&curp[1];
+@@ -127,7 +127,7 @@ getopt(int argc, char *const argv[], const char *optstring)
+   optind++;
+   optarg = 0;
+   }
+-  return optopt;
++  return optoptc;
+   }
+   optstring++;
+   }
diff --git 
a/meta/recipes-extended/mailx/files/0002-Patched-out-SSL2-support-since-it-is-no-longer-suppo.patch
 
b/meta/recipes-extended/mailx/files/0002-Patched-out-SSL2-support-since-it-is-no-longer-suppo.patch
new file mode 100644
index 000..f70f8fc
--- /dev/null
+++ 
b/meta/recipes-extended/mailx/files/0002-Patched-out-SSL2-support-since-it-is-no-longer-suppo.patch
@@ -0,0 +1,41 @@
+From: Hilko Bengen 
+Date: Wed, 27 Apr 2011 00:18:42 +0200
+Subject: Patched out SSL2 support since it is no longer supported by OpenSSL.
+
+This patch is taken from
+ftp://ftp.debian.org/debian/pool/main/h/heirloom-mailx/heirloom-mailx_12.5-5.debian.tar.xz
+
+Upstream-status: Inappropr

[OE-core] [PATCH 08/12] python-smmap: update to 0.9.0

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin 
---
 .../python/{python-smmap_0.8.2.bb => python-smmap_0.9.0.bb}   | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-devtools/python/{python-smmap_0.8.2.bb => 
python-smmap_0.9.0.bb} (82%)

diff --git a/meta/recipes-devtools/python/python-smmap_0.8.2.bb 
b/meta/recipes-devtools/python/python-smmap_0.9.0.bb
similarity index 82%
rename from meta/recipes-devtools/python/python-smmap_0.8.2.bb
rename to meta/recipes-devtools/python/python-smmap_0.9.0.bb
index 64f812d..b658be8 100644
--- a/meta/recipes-devtools/python/python-smmap_0.8.2.bb
+++ b/meta/recipes-devtools/python/python-smmap_0.9.0.bb
@@ -8,8 +8,8 @@ LICENSE = "BSD"
 LIC_FILES_CHKSUM = 
"file://PKG-INFO;beginline=8;endline=8;md5=e910b35b0ef4e1f665b9a75d6afb7709"
 
 SRC_URI = "http://pypi.python.org/packages/source/s/smmap/smmap-${PV}.tar.gz";
-SRC_URI[md5sum] = "f5426b7626ddcf5e447253fae0396b0c"
-SRC_URI[sha256sum] = 
"dea2955cc045ec5527da6b762f7e95a5be7f645c683b54ccce52d56b4d7e2d6f"
+SRC_URI[md5sum] = "d7932d5ace206bf4ae15198cf36fb6ab"
+SRC_URI[sha256sum] = 
"0e2b62b497bd5f0afebc002eda4d90df9d209c30ef257e8673c90a6b5c119d62"
 
 S = "${WORKDIR}/smmap-${PV}"
 
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 00/12] Various package/RRS updates

[Alexander Kanavin]

This week I've reviewed all the packages that have been last touched in 2013 
or earlier (according to RRS) and this is the resulting patchset.

Since the feature freeze is happening soon, and there is still a large backlog 
of 
unmerged patches, I will stop the package version update at this point to avoid 
making
the situation worse :) and will look into other things, perhaps these:

1) fixing gobject introspection

2) completing the work of porting matchbox stuff to gtk3 (or *gasp* looking 
into 
replacing it with the most minimal possible gnome 3 shell/launcher).

3) other suggestions?

The following changes since commit c80b582212336044c55052ad0d39f9da06d71438:

  debianutils: create package for run-parts (2015-09-03 12:43:33 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib akanavin/package-version-updates
  
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akanavin/package-version-updates

Alexander Kanavin (12):
  ccache: update to 3.2.3
  mailx: update to 12.5-5
  net-tools: update to 1.60-25
  gnome-icon-theme: remove the recipe
  libunique: remove the recipe
  mkelfimage: add RECIPE_NO_UPDATE_REASON
  python-async: update to 0.6.2
  python-smmap: update to 0.9.0
  remake: update to 4.1+dbg-1.1
  uclibc: update PV to 0.9.33.2 to match latest upstream release
  vte: add RECIPE_NO_UPDATE_REASON
  package_regex.inc: various updates to improve RRS accuracy

 meta/conf/distro/include/package_regex.inc |  14 +-
 meta/recipes-core/uclibc/uclibc-git.inc|   2 +-
 meta/recipes-devtools/ccache/ccache.inc|   4 +-
 meta/recipes-devtools/ccache/ccache_3.1.11.bb  |   7 -
 meta/recipes-devtools/ccache/ccache_3.2.3.bb   |   8 +
 ...ion-in-recent-change-related-to-zlib-in-n.patch |  73 
 meta/recipes-devtools/mkelfimage/mkelfimage_git.bb |   3 +
 ...python-async_0.6.1.bb => python-async_0.6.2.bb} |   4 +-
 ...python-smmap_0.8.2.bb => python-smmap_0.9.0.bb} |   4 +-
 meta/recipes-devtools/remake/remake.inc|   4 +-
 ...ve-errors-about-colophon-and-cygnus-comma.patch |  39 --
 .../{remake_git.bb => remake_4.1+dbg-1.1.bb}   |   8 +-
 ...e-weak-symbol-optopt-to-fix-FTBFS-on-mips.patch |  59 +++
 ...-SSL2-support-since-it-is-no-longer-suppo.patch |  41 ++
 ...ntian-warning-warning-macro-N-not-defined.patch |  25 ++
 .../0011-outof-Introduce-expandaddr-flag.patch |  70 
 ...ble-option-processing-for-email-addresses.patch |  79 
 ...c-Unconditionally-require-wordexp-support.patch | 113 ++
 ...4-globname-Invoke-wordexp-with-WRDE_NOCMD.patch |  30 ++
 .../mailx/files/0015-usr-sbin-sendmail.patch   |  38 ++
 .../explicitly.disable.krb5.support.patch  |   0
 .../mailx/{mailx_12.5.bb => mailx_12.5-5.bb}   |  21 +-
 .../{net-tools_1.60-25.bb => net-tools_1.60-26.bb} |   6 +-
 .../gnome/gnome-icon-theme/pkgconfig-native.patch  |  28 --
 .../recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb |  22 --
 meta/recipes-gnome/libunique/libunique/build.patch | 421 -
 .../libunique/fix_for_compile_with_gcc-4.6.0.patch |  36 --
 .../libunique/libunique/noconst.patch  | 130 ---
 meta/recipes-gnome/libunique/libunique_1.1.6.bb|  25 --
 meta/recipes-support/vte/vte_0.28.2.bb |   2 +
 30 files changed, 579 insertions(+), 737 deletions(-)
 delete mode 100644 meta/recipes-devtools/ccache/ccache_3.1.11.bb
 create mode 100644 meta/recipes-devtools/ccache/ccache_3.2.3.bb
 create mode 100644 
meta/recipes-devtools/ccache/files/0001-Fix-regression-in-recent-change-related-to-zlib-in-n.patch
 rename meta/recipes-devtools/python/{python-async_0.6.1.bb => 
python-async_0.6.2.bb} (77%)
 rename meta/recipes-devtools/python/{python-smmap_0.8.2.bb => 
python-smmap_0.9.0.bb} (82%)
 delete mode 100644 
meta/recipes-devtools/remake/remake/remake-remove-errors-about-colophon-and-cygnus-comma.patch
 rename meta/recipes-devtools/remake/{remake_git.bb => remake_4.1+dbg-1.1.bb} 
(80%)
 create mode 100644 
meta/recipes-extended/mailx/files/0001-Don-t-reuse-weak-symbol-optopt-to-fix-FTBFS-on-mips.patch
 create mode 100644 
meta/recipes-extended/mailx/files/0002-Patched-out-SSL2-support-since-it-is-no-longer-suppo.patch
 create mode 100644 
meta/recipes-extended/mailx/files/0003-Fixed-Lintian-warning-warning-macro-N-not-defined.patch
 create mode 100644 
meta/recipes-extended/mailx/files/0011-outof-Introduce-expandaddr-flag.patch
 create mode 100644 
meta/recipes-extended/mailx/files/0012-unpack-Disable-option-processing-for-email-addresses.patch
 create mode 100644 
meta/recipes-extended/mailx/files/0013-fio.c-Unconditionally-require-wordexp-support.patch
 create mode 100644 
meta/recipes-extended/mailx/files/0014-globname-Invoke-wordexp-with-WRDE_NOCMD.patch
 create mode 100644 
meta/recipes-extended/mailx/files/0015-usr-sbin-sendmail.patch
 rename meta/recipes-extended/mailx/{mailx-12.5 => 
files}/explicitly.disable.krb5.support.patch (100%)
 rename meta/recipes-extended/mailx/{

Re: [OE-core] [PATCH 3/9] systemd: remove hard-coded paths in FILES entries

[Burton, Ross]

On 3 September 2015 at 16:12, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> From what I remember, this is intentional and this change likely breaks
> multilib. You don't want two sets of rules on a multilib system.
>

Indeed - you need nonarch_base_libdir or whatever it's called here I think,
as that doesn't get renamed by multilib.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/9] systemd: remove hard-coded paths in FILES entries

[Richard Purdie]

On Thu, 2015-09-03 at 15:58 +0100, Joshua Lock wrote:
> Signed-off-by: Joshua Lock 
> ---
>  meta/recipes-core/systemd/systemd_219.bb | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/meta/recipes-core/systemd/systemd_219.bb 
> b/meta/recipes-core/systemd/systemd_219.bb
> index 4d32fd5..fbd86e8 100644
> --- a/meta/recipes-core/systemd/systemd_219.bb
> +++ b/meta/recipes-core/systemd/systemd_219.bb
> @@ -306,10 +306,10 @@ FILES_${PN} = " ${base_bindir}/* \
>  ${exec_prefix}/lib/sysctl.d \
>  ${exec_prefix}/lib/sysusers.d \
>  ${localstatedir} \
> -/lib/udev/rules.d/70-uaccess.rules \
> -/lib/udev/rules.d/71-seat.rules \
> -/lib/udev/rules.d/73-seat-late.rules \
> -/lib/udev/rules.d/99-systemd.rules \
> +${base_libdir}/udev/rules.d/70-uaccess.rules \
> +${base_libdir}/udev/rules.d/71-seat.rules \
> +${base_libdir}/udev/rules.d/73-seat-late.rules \
> +${base_libdir}/udev/rules.d/99-systemd.rules \
> "
>  
>  FILES_${PN}-dbg += "${rootlibdir}/.debug ${systemd_unitdir}/.debug 
> ${systemd_unitdir}/*/.debug ${base_libdir}/security/.debug/"
> @@ -327,7 +327,7 @@ RRECOMMENDS_${PN} += "systemd-serialgetty 
> systemd-vconsole-setup \
>  
>  PACKAGES =+ "udev-dbg udev udev-hwdb"
>  
> -FILES_udev-dbg += "/lib/udev/.debug"
> +FILES_udev-dbg += "${base_libdir}/udev/.debug"

>From what I remember, this is intentional and this change likely breaks
multilib. You don't want two sets of rules on a multilib system.

Cheers,

Richard



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 7/9] pcmciautils: handle udev dir being 2 levels below /

[Joshua Lock]

When building with a merged /usr dir the udev directory
lives at /usr/lib/udev - update the FILES pattern to also
pick up udev files installed two levels below the / to
ensure a merged /usr works.

Signed-off-by: Joshua Lock 
---
 meta/recipes-bsp/pcmciautils/pcmciautils_018.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-bsp/pcmciautils/pcmciautils_018.bb 
b/meta/recipes-bsp/pcmciautils/pcmciautils_018.bb
index 24ceed8..857bd07 100644
--- a/meta/recipes-bsp/pcmciautils/pcmciautils_018.bb
+++ b/meta/recipes-bsp/pcmciautils/pcmciautils_018.bb
@@ -9,5 +9,5 @@ SRC_URI[sha256sum] = 
"79e6ae441278e178c07501d492394ed2c0326fdb66894f6d040ec811b0
 
 PR = "r1"
 
-FILES_${PN}-dbg += "*/udev/.debug"
-FILES_${PN} += "*/udev"
+FILES_${PN}-dbg += "*/udev/.debug */*/udev/.debug"
+FILES_${PN} += "*/udev */*/udev"
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 6/9] bluez: handle udev dir being 2 levels below /

[Joshua Lock]

When building with a merged /usr dir the udev directory
lives at /usr/lib/udev - update the FILES pattern to also
pick up udev files installed two levels below the / to
ensure a merged /usr works.

Signed-off-by: Joshua Lock 
---
 meta/recipes-connectivity/bluez5/bluez5.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc 
b/meta/recipes-connectivity/bluez5/bluez5.inc
index 0fe5be5..039c443 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -95,6 +95,7 @@ FILES_${PN}-dbg += "\
   ${libdir}/bluetooth/plugins/.debug \
   ${libdir}/*/.debug \
   */udev/.debug \
+  */*/udev/.debug \
   "
 
 RDEPENDS_${PN}-testtools += "python python-dbus python-pygobject"
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 5/9] pulseaudio: handle udev dir being 2 levels below /

[Joshua Lock]

When building with a merged /usr dir the udev directory
lives at /usr/lib/udev - update the FILES pattern to also
pick up udev files installed two levels below the / to
ensure a merged /usr works.

Signed-off-by: Joshua Lock 
---
 meta/recipes-multimedia/pulseaudio/pulseaudio.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc 
b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
index 47f5f39..5454787 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
@@ -99,7 +99,7 @@ FILES_${PN}-dbg += "${libexecdir}/pulse/.debug \
 FILES_${PN}-dev += "${libdir}/pulse-${PV}/modules/*.la ${datadir}/vala 
${libdir}/cmake"   
 FILES_${PN}-conf = "${sysconfdir}"
 FILES_${PN}-bin += "${sysconfdir}/default/volatiles/volatiles.04_pulse"
-FILES_${PN}-server = "${bindir}/pulseaudio ${bindir}/start-* ${sysconfdir} 
${bindir}/pactl */udev/rules.d/*.rules ${systemd_user_unitdir}/*"
+FILES_${PN}-server = "${bindir}/pulseaudio ${bindir}/start-* ${sysconfdir} 
${bindir}/pactl */udev/rules.d/*.rules */*/udev/rules.d/*.rules 
${systemd_user_unitdir}/*"
 
 #SYSTEMD_PACKAGES = "${PN}-server"
 SYSTEMD_SERVICE_${PN}-server = "pulseaudio.service"
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 9/9] procps: fix for base_sbindir == sbindir

[Joshua Lock]

An rmdir call in do_install_append was trying to remove the
sbindir, however in a system with a merged usr this directory
is not empty and therefore failing to rm it causes an ERROR.

Instead check that sbindir != base_sbindir before trying to
remove the directory.

Signed-off-by: Joshua Lock 
---
 meta/recipes-extended/procps/procps_3.3.10.bb | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-extended/procps/procps_3.3.10.bb 
b/meta/recipes-extended/procps/procps_3.3.10.bb
index 65d64ec..dcfaba7 100644
--- a/meta/recipes-extended/procps/procps_3.3.10.bb
+++ b/meta/recipes-extended/procps/procps_3.3.10.bb
@@ -31,8 +31,9 @@ do_install_append () {
[ "${bindir}" != "${base_bindir}" ] && for i in ${base_bindir_progs}; 
do mv ${D}${bindir}/$i ${D}${base_bindir}/$i; done
install -d ${D}${base_sbindir}
[ "${sbindir}" != "${base_sbindir}" ] && for i in 
${base_sbindir_progs}; do mv ${D}${sbindir}/$i ${D}${base_sbindir}/$i; done
-# Remove now empty dir
-   rmdir ${D}/${sbindir}
+if [ "${base_sbindir}" != "${sbindir}" ]; then
+rmdir ${D}${sbindir}
+fi
 
 install -d ${D}${sysconfdir}
 install -m 0644 ${WORKDIR}/sysctl.conf ${D}${sysconfdir}/sysctl.conf
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 8/9] nfs-utils: don't force use of /sbin as sbindir

[Joshua Lock]

In a system with a merged /usr /sbin isn't packaged.

Signed-off-by: Joshua Lock 
---
 meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb | 8 
 1 file changed, 8 insertions(+)

diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb 
b/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
index 6da8509..42101de 100644
--- a/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
+++ b/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
@@ -90,6 +90,14 @@ RDEPENDS_${PN}-stats = "python"
 
 FILES_${PN} += "${systemd_unitdir}"
 
+do_configure_prepend() {
+sed -i -e 's,sbindir = /sbin,sbindir = ${base_sbindir},g' \
+${S}/utils/mount/Makefile.am
+
+sed -i -e 's,sbindir = /sbin,sbindir = ${base_sbindir},g' \
+${S}/utils/osd_login/Makefile.am
+}
+
 # Make clean needed because the package comes with
 # precompiled 64-bit objects that break the build
 do_compile_prepend() {
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/9] kmod: fix link creation when base_bindir != /bin

[Joshua Lock]

If base_bindir is not a direct child of / the link creation in
do_install_append creates incorrect relative links.

Instead pass a full path to the link source and use the -r flag
to ln to ensure the link is relative.

Signed-off-by: Joshua Lock 
---
 meta/recipes-kernel/kmod/kmod_git.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-kernel/kmod/kmod_git.bb 
b/meta/recipes-kernel/kmod/kmod_git.bb
index ba4d85e..120fd87 100644
--- a/meta/recipes-kernel/kmod/kmod_git.bb
+++ b/meta/recipes-kernel/kmod/kmod_git.bb
@@ -21,9 +21,9 @@ do_install_append () {
 install -dm755 ${D}${base_bindir}
 install -dm755 ${D}${base_sbindir}
 # add symlinks to kmod
-ln -s ..${base_bindir}/kmod ${D}${base_bindir}/lsmod
+ln -sr ${D}${base_bindir}/kmod ${D}${base_bindir}/lsmod
 for tool in insmod rmmod depmod modinfo modprobe; do
-ln -s ..${base_bindir}/kmod ${D}${base_sbindir}/${tool}
+ln -sr ${D}${base_bindir}/kmod ${D}${base_sbindir}/${tool}
 done
 # configuration directories
 install -dm755 ${D}${base_libdir}/depmod.d
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 4/9] alsa-utils: handle udev dir being 2 levels below /

[Joshua Lock]

When building with a merged /usr dir the udev directory
lives at /usr/lib/udev - update the FILES pattern to also
pick up udev files installed two levels below the / to
ensure a merged /usr works.

Signed-off-by: Joshua Lock 
---
 meta/recipes-multimedia/alsa/alsa-utils_1.0.29.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-multimedia/alsa/alsa-utils_1.0.29.bb 
b/meta/recipes-multimedia/alsa/alsa-utils_1.0.29.bb
index 263f38a..97fe4b2 100644
--- a/meta/recipes-multimedia/alsa/alsa-utils_1.0.29.bb
+++ b/meta/recipes-multimedia/alsa/alsa-utils_1.0.29.bb
@@ -58,7 +58,7 @@ FILES_alsa-utils-midi= "${bindir}/aplaymidi 
${bindir}/arecordmidi ${bind
 FILES_alsa-utils-aconnect= "${bindir}/aconnect"
 FILES_alsa-utils-aseqnet = "${bindir}/aseqnet"
 FILES_alsa-utils-iecset  = "${bindir}/iecset"
-FILES_alsa-utils-alsactl = "${sbindir}/alsactl */udev/rules.d 
${systemd_unitdir} ${localstatedir}/lib/alsa ${datadir}/alsa/init/"
+FILES_alsa-utils-alsactl = "${sbindir}/alsactl */udev/rules.d 
*/*/udev/rules.d ${systemd_unitdir} ${localstatedir}/lib/alsa 
${datadir}/alsa/init/"
 FILES_alsa-utils-aseqdump= "${bindir}/aseqdump"
 FILES_alsa-utils-alsaloop= "${bindir}/alsaloop"
 FILES_alsa-utils-alsaucm = "${bindir}/alsaucm"
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 3/9] systemd: remove hard-coded paths in FILES entries

[Joshua Lock]

Signed-off-by: Joshua Lock 
---
 meta/recipes-core/systemd/systemd_219.bb | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-core/systemd/systemd_219.bb 
b/meta/recipes-core/systemd/systemd_219.bb
index 4d32fd5..fbd86e8 100644
--- a/meta/recipes-core/systemd/systemd_219.bb
+++ b/meta/recipes-core/systemd/systemd_219.bb
@@ -306,10 +306,10 @@ FILES_${PN} = " ${base_bindir}/* \
 ${exec_prefix}/lib/sysctl.d \
 ${exec_prefix}/lib/sysusers.d \
 ${localstatedir} \
-/lib/udev/rules.d/70-uaccess.rules \
-/lib/udev/rules.d/71-seat.rules \
-/lib/udev/rules.d/73-seat-late.rules \
-/lib/udev/rules.d/99-systemd.rules \
+${base_libdir}/udev/rules.d/70-uaccess.rules \
+${base_libdir}/udev/rules.d/71-seat.rules \
+${base_libdir}/udev/rules.d/73-seat-late.rules \
+${base_libdir}/udev/rules.d/99-systemd.rules \
"
 
 FILES_${PN}-dbg += "${rootlibdir}/.debug ${systemd_unitdir}/.debug 
${systemd_unitdir}/*/.debug ${base_libdir}/security/.debug/"
@@ -327,7 +327,7 @@ RRECOMMENDS_${PN} += "systemd-serialgetty 
systemd-vconsole-setup \
 
 PACKAGES =+ "udev-dbg udev udev-hwdb"
 
-FILES_udev-dbg += "/lib/udev/.debug"
+FILES_udev-dbg += "${base_libdir}/udev/.debug"
 
 RPROVIDES_udev = "hotplug"
 
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/9] busybox: fixes for when base_bindir != /bin

[Joshua Lock]

* Replace all hard-coded paths with variables
* Run sed over busybox.links.* to replace /bin with ${base_bindir}

Signed-off-by: Joshua Lock 
---
 meta/recipes-core/busybox/busybox.inc | 49 +++
 1 file changed, 26 insertions(+), 23 deletions(-)

diff --git a/meta/recipes-core/busybox/busybox.inc 
b/meta/recipes-core/busybox/busybox.inc
index 0769d92..92b4a29 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -178,6 +178,9 @@ do_install () {
if [ "${base_sbindir}" != "/sbin" ]; then
sed -i "s:^/sbin/:${base_sbindir}/:" busybox.links*
fi
+   if [ "${base_bindir}" != "/bin" ]; then
+   sed -i "s:^/bin/:${base_bindir}/:" busybox.links*
+   fi
 
install -d ${D}${sysconfdir}/init.d
 
@@ -338,10 +341,10 @@ python do_package_prepend () {
 return
 
 if os.path.exists('%s/etc/busybox.links' % (dvar)):
-set_alternative_vars("/etc/busybox.links", "/bin/busybox")
+set_alternative_vars("${sysconfdir}/busybox.links", 
"${base_bindir}/busybox")
 else:
-set_alternative_vars("/etc/busybox.links.nosuid", 
"/bin/busybox.nosuid")
-set_alternative_vars("/etc/busybox.links.suid", "/bin/busybox.suid")
+set_alternative_vars("${sysconfdir}/busybox.links.nosuid", 
"${base_bindir}/busybox.nosuid")
+set_alternative_vars("${sysconfdir}/busybox.links.suid", 
"${base_bindir}/busybox.suid")
 }
 
 pkg_postinst_${PN} () {
@@ -353,22 +356,22 @@ pkg_postinst_${PN} () {
if test "x$D" = "x"; then
# Remove busybox.nosuid if it's a symlink, because this 
situation indicates
# that we're installing or upgrading to a one-binary busybox.
-   if test -h /bin/busybox.nosuid; then
-   rm -f /bin/busybox.nosuid
+   if test -h ${bindir}/busybox.nosuid; then
+   rm -f ${bindir}/busybox.nosuid
fi
for suffix in "" ".nosuid" ".suid"; do
-   if test -e /etc/busybox.links$suffix; then
+   if test -e ${sysconfdir}/busybox.links$suffix; then
while read link; do
if test ! -e "$link"; then
case "$link" in
/*/*/*)
-   
to="../../bin/busybox$suffix"
+   
to="../..${base_bindir}/busybox$suffix"
;;
/bin/*)

to="busybox$suffix"
;;
/*/*)
-   
to="../bin/busybox$suffix"
+   
to="..${base_bindir}/busybox$suffix"
;;
esac
# we can use busybox here 
because even if we are using splitted busybox
@@ -376,7 +379,7 @@ pkg_postinst_${PN} () {
busybox rm -f $link
busybox ln -s $to $link
fi
-   done < /etc/busybox.links$suffix
+   done < ${sysconfdir}/busybox.links$suffix
fi
done
fi
@@ -387,19 +390,19 @@ pkg_prerm_${PN} () {
# providing its files, this will make update-alternatives work, but the 
update-rc.d part
# for syslog, httpd and/or udhcpd will fail if there is no other 
package providing sh
tmpdir=`mktemp -d /tmp/busyboxrm-XX`
-   ln -s /bin/busybox $tmpdir/[
-   ln -s /bin/busybox $tmpdir/test
-   ln -s /bin/busybox $tmpdir/head
-   ln -s /bin/busybox $tmpdir/sh
-   ln -s /bin/busybox $tmpdir/basename
-   ln -s /bin/busybox $tmpdir/echo
-   ln -s /bin/busybox $tmpdir/mv
-   ln -s /bin/busybox $tmpdir/ln
-   ln -s /bin/busybox $tmpdir/dirname
-   ln -s /bin/busybox $tmpdir/rm
-   ln -s /bin/busybox $tmpdir/sed
-   ln -s /bin/busybox $tmpdir/sort
-   ln -s /bin/busybox $tmpdir/grep
+   ln -s ${base_bindir}/busybox $tmpdir/[
+   ln -s ${base_bindir}/busybox $tmpdir/test
+   ln -s ${base_bindir}/busybox $tmpdir/head
+   ln -s ${base_bindir}/busybox $tmpdir/sh
+   ln -s ${base_bindir}/busybox $tmpdir/basename
+   ln -s ${base_bindir}/busybox $tmpdir/echo
+   ln -s ${base_bindir}/busybox $tmpdir/mv
+   

[OE-core] [PATCH 0/9] Fixes for a distro with a merged /usr

[Joshua Lock]

I've been playing around with building a distro with a merged /usr[1] and
the following series fixes several issues I ran across in OE core metadata.

These have been build tested by building a core-image-sato image with
ipk packaging for qemux86 with both a standard/default configuration and
for my merged /usr test distro.

I used buildhistory to compare core-image-sato before and after this series
and the only change is:

Changes to images/qemux86/glibc/core-image-sato (files-in-image.txt):
  /bin/lsmod.kmod changed symlink target from ../bin/kmod to kmod

Regards,

Joshua

1. https://wiki.freedesktop.org/www/Software/systemd/TheCaseForTheUsrMerge/

The following changes since commit bdeb32b4cdbe316f17c2fd854d59e05e8f2e8ffc:

  rt-tests: drop unnecessary added-missing-dependencies.patch (2015-09-01 
11:43:38 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib joshuagl/merged-usr
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=joshuagl/merged-usr

Joshua Lock (9):
  kmod: fix link creation when base_bindir != /bin
  busybox: fixes for when base_bindir != /bin
  systemd: remove hard-coded paths in FILES entries
  alsa-utils: handle udev dir being 2 levels below /
  pulseaudio: handle udev dir being 2 levels below /
  bluez: handle udev dir being 2 levels below /
  pcmciautils: handle udev dir being 2 levels below /
  nfs-utils: don't force use of /sbin as sbindir
  procps: fix for base_sbindir == sbindir

 meta/recipes-bsp/pcmciautils/pcmciautils_018.bb|  4 +-
 meta/recipes-connectivity/bluez5/bluez5.inc|  1 +
 .../nfs-utils/nfs-utils_1.3.1.bb   |  8 
 meta/recipes-core/busybox/busybox.inc  | 49 --
 meta/recipes-core/systemd/systemd_219.bb   | 10 ++---
 meta/recipes-extended/procps/procps_3.3.10.bb  |  5 ++-
 meta/recipes-kernel/kmod/kmod_git.bb   |  4 +-
 meta/recipes-multimedia/alsa/alsa-utils_1.0.29.bb  |  2 +-
 meta/recipes-multimedia/pulseaudio/pulseaudio.inc  |  2 +-
 9 files changed, 49 insertions(+), 36 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][fido] gnutls: CVE-2015-3308

[Joshua Lock]

On Thu, 2015-09-03 at 13:54 +0200, Sona Sarmadi wrote:
> Fixes use-after-free flaw in CRL distribution points parsing
> 
> Reference:
> https://gitlab.com/gnutls/gnutls/commit/d6972be33264ecc49a86cd0958209
> cd7363af1e9
> https://gitlab.com/gnutls/gnutls/commit/053ae65403216acdb0a4e78b25ad6
> 6ee9f444f02
> 
> http://www.openwall.com/lists/oss-security/2015/04/15/6
> Signed-off-by: Sona Sarmadi 

Thanks Sona! I've pushed this to my joshuagl/fido-next branch[1].

Regards,

Joshua

1. http://cgit.openembedded.org/openembedded-core-contrib/log/?h=joshua
gl/fido-next

> ---
>  .../better-fix-for-double-free-CVE-2015-3308.patch | 65
> ++
>  .../eliminated-double-free-CVE-2015-3308.patch | 33 +++
>  meta/recipes-support/gnutls/gnutls_3.3.12.bb   |  2 +
>  3 files changed, 100 insertions(+)
>  create mode 100644 meta/recipes-support/gnutls/gnutls/better-fix-for
> -double-free-CVE-2015-3308.patch
>  create mode 100644 meta/recipes-support/gnutls/gnutls/eliminated
> -double-free-CVE-2015-3308.patch
> 
> diff --git a/meta/recipes-support/gnutls/gnutls/better-fix-for-double
> -free-CVE-2015-3308.patch b/meta/recipes-support/gnutls/gnutls/better
> -fix-for-double-free-CVE-2015-3308.patch
> new file mode 100644
> index 000..8824729
> --- /dev/null
> +++ b/meta/recipes-support/gnutls/gnutls/better-fix-for-double-free
> -CVE-2015-3308.patch
> @@ -0,0 +1,65 @@
> +From 053ae65403216acdb0a4e78b25ad66ee9f444f02 Mon Sep 17 00:00:00
> 2001
> +From: Nikos Mavrogiannopoulos 
> +Date: Sat, 28 Mar 2015 22:41:03 +0100
> +Subject: [PATCH] Better fix for the double free in dist point
> parsing
> +
> +Fixes CVE-2015-3308
> +Upstream-Status: Backport
> +
> +Signed-off-by: Sona Sarmadi 
> +---
> + lib/x509/x509_ext.c | 10 ++
> + 1 file changed, 6 insertions(+), 4 deletions(-)
> +
> +diff --git a/lib/x509/x509_ext.c b/lib/x509/x509_ext.c
> +index 2e69ed0..f974b02 100644
> +--- a/lib/x509/x509_ext.c
>  b/lib/x509/x509_ext.c
> +@@ -2287,7 +2287,7 @@ int
> gnutls_x509_ext_import_crl_dist_points(const gnutls_datum_t * ext,
> + int len, ret;
> + uint8_t reasons[2];
> + unsigned i, type, rflags, j;
> +-gnutls_datum_t san;
> ++gnutls_datum_t san = {NULL, 0};
> + 
> + result = asn1_create_element
> + (_gnutls_get_pkix(), "PKIX1.CRLDistributionPoints",
> &c2);
> +@@ -2310,9 +2310,6 @@ int
> gnutls_x509_ext_import_crl_dist_points(const gnutls_datum_t * ext,
> + 
> + i = 0;
> + do {
> +-san.data = NULL;
> +-san.size = 0;
> +-
> + snprintf(name, sizeof(name), "?%u.reasons",
> (unsigned)i + 1);
> + 
> + len = sizeof(reasons);
> +@@ -2337,6 +2334,9 @@ int
> gnutls_x509_ext_import_crl_dist_points(const gnutls_datum_t * ext,
> + 
> + j = 0;
> + do {
> ++san.data = NULL;
> ++san.size = 0;
> ++
> + ret =
> + _gnutls_parse_general_name2(c2, name,
> j, &san,
> + &type, 0);
> +@@ -2351,6 +2351,7 @@ int
> gnutls_x509_ext_import_crl_dist_points(const gnutls_datum_t * ext,
> + ret = crl_dist_points_set(cdp, type, &san,
> rflags);
> + if (ret < 0)
> + break;
> ++san.data = NULL; /* it is now in cdp */
> + 
> + j++;
> + } while (ret >= 0);
> +@@ -2360,6 +2361,7 @@ int
> gnutls_x509_ext_import_crl_dist_points(const gnutls_datum_t * ext,
> + 
> + if (ret < 0 && ret !=
> GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE) {
> + gnutls_assert();
> ++gnutls_free(san.data);
> + goto cleanup;
> + }
> + 
> +-- 
> +1.9.1
> +
> diff --git a/meta/recipes-support/gnutls/gnutls/eliminated-double
> -free-CVE-2015-3308.patch b/meta/recipes
> -support/gnutls/gnutls/eliminated-double-free-CVE-2015-3308.patch
> new file mode 100644
> index 000..628103f
> --- /dev/null
> +++ b/meta/recipes-support/gnutls/gnutls/eliminated-double-free-CVE
> -2015-3308.patch
> @@ -0,0 +1,33 @@
> +From d6972be33264ecc49a86cd0958209cd7363af1e9 Mon Sep 17 00:00:00
> 2001
> +From: Nikos Mavrogiannopoulos 
> +Date: Mon, 23 Mar 2015 22:55:29 +0100
> +Subject: [PATCH] eliminated double-free in the parsing of dist
> points
> +MIME-Version: 1.0
> +Content-Type: text/plain; charset=UTF-8
> +Content-Transfer-Encoding: 8bit
> +
> +Reported by Robert Święcki.
> +
> +Fixes CVE-2015-3308
> +Upstream-Status: Backport
> +
> +Signed-off-by: Sona Sarmadi 
> +---
> + lib/x509/x509_ext.c | 1 -
> + 1 file changed, 1 deletion(-)
> +
> +diff --git a/lib/x509/x509_ext.c b/lib/x509/x509_ext.c
> +index c8d5867..6f09438 100644
> +--- a/lib/x509/x509_ext.c
>  b/lib/x509/x509_ext.c
> +@@ -2360,7 +2360,6 @@ int
> gnutls_x509_ext_import_crl_dist_points(const gnutls_datum_t * ext,
> + 
> + if (ret < 0 && ret !=
> GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE) {
> + gnutls_ass

Re: [OE-core] [oe-core][PATCH 1/2] ifupdown: import recipe

[Jack Mitchell]

On 02/09/15 16:55, Otavio Salvador wrote:

On Tue, Sep 1, 2015 at 6:34 PM, Joe Slater  wrote:

Implements ifup and ifdown.

Copied from https://github.com/WindRiver-OpenSourceLabs/meta-overc.git
as of commit aa89eebffe06e4aa04701eae9691cb3049cbaef9.

Signed-off-by: Joe Slater 


I think this belongs to meta-networking. Also, what this one provides
which is not provided by the busybox one?



This provides hotplug support which the busybox version does not. I'm torn on 
where it should land i.e. meta-networking vs core but it is a useful addition 
regardless.


If you're attempting to do a non busybox based build, then I don't see the 
reasoning for not just using connman as your networking manager instead which is 
already supported in core.

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/2] ifupdown: import recipe

[Bruce Ashfield]

On Thu, Sep 3, 2015 at 8:11 AM, Richard Purdie
 wrote:
> On Wed, 2015-09-02 at 16:23 -0300, Otavio Salvador wrote:
>> On Wed, Sep 2, 2015 at 4:09 PM, Randy MacLeod
>>  wrote:
>> > On 2015-09-02 11:55 AM, Otavio Salvador wrote:
>> >>
>> >> On Tue, Sep 1, 2015 at 6:34 PM, Joe Slater  wrote:
>> >>>
>> >>> Implements ifup and ifdown.
>> >>>
>> >>> Copied from https://github.com/WindRiver-OpenSourceLabs/meta-overc.git
>> >>> as of commit aa89eebffe06e4aa04701eae9691cb3049cbaef9.
>> >>>
>> >>> Signed-off-by: Joe Slater 
>> >>
>> >>
>> >> I think this belongs to meta-networking. Also, what this one provides
>> >> which is not provided by the busybox one?
>> >
>> > We're trying to make busybox optional for larger systems
>> > that want to only use the full-featured/bloated packages.
>> > It's not a large tax to carry busybox in a 50+ MB image but
>> > it would be nice to not require it.
>>
>> I see; I still think this belongs to meta-networking as it will allow
>> this to be done however won't add new recipes in core.
>>
>> If many people start to use this, we can move this to core.
>
> To put this another way, I think it is probably reasonable that we
> should be able to build an image from OE-Core with basic functionality
> like networking without busybox?

That's what I'd support. If everything you need for the functionality with busy
box is in oe-core, to me, it doesn't make sense to go outside core to get that
same functionality without busybox.

Cheers,

Bruce

>
> Cheers,
>
> Richard
>
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/2] ifupdown: import recipe

[Otavio Salvador]

On Thu, Sep 3, 2015 at 9:11 AM, Richard Purdie
 wrote:
> On Wed, 2015-09-02 at 16:23 -0300, Otavio Salvador wrote:
>> On Wed, Sep 2, 2015 at 4:09 PM, Randy MacLeod
>>  wrote:
>> > On 2015-09-02 11:55 AM, Otavio Salvador wrote:
>> >>
>> >> On Tue, Sep 1, 2015 at 6:34 PM, Joe Slater  wrote:
>> >>>
>> >>> Implements ifup and ifdown.
>> >>>
>> >>> Copied from https://github.com/WindRiver-OpenSourceLabs/meta-overc.git
>> >>> as of commit aa89eebffe06e4aa04701eae9691cb3049cbaef9.
>> >>>
>> >>> Signed-off-by: Joe Slater 
>> >>
>> >>
>> >> I think this belongs to meta-networking. Also, what this one provides
>> >> which is not provided by the busybox one?
>> >
>> > We're trying to make busybox optional for larger systems
>> > that want to only use the full-featured/bloated packages.
>> > It's not a large tax to carry busybox in a 50+ MB image but
>> > it would be nice to not require it.
>>
>> I see; I still think this belongs to meta-networking as it will allow
>> this to be done however won't add new recipes in core.
>>
>> If many people start to use this, we can move this to core.
>
> To put this another way, I think it is probably reasonable that we
> should be able to build an image from OE-Core with basic functionality
> like networking without busybox?

That is the point; this were not in meta-networking and noone missed
it until now. Moving this to oe-core straight seems overkill.

I think moving this to meta-networking is right and if many people use
it, oe-core is next step.

-- 
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] [oe-core][PATCH 1/2] ifupdown: import recipe

[Richard Purdie]

On Wed, 2015-09-02 at 16:23 -0300, Otavio Salvador wrote:
> On Wed, Sep 2, 2015 at 4:09 PM, Randy MacLeod
>  wrote:
> > On 2015-09-02 11:55 AM, Otavio Salvador wrote:
> >>
> >> On Tue, Sep 1, 2015 at 6:34 PM, Joe Slater  wrote:
> >>>
> >>> Implements ifup and ifdown.
> >>>
> >>> Copied from https://github.com/WindRiver-OpenSourceLabs/meta-overc.git
> >>> as of commit aa89eebffe06e4aa04701eae9691cb3049cbaef9.
> >>>
> >>> Signed-off-by: Joe Slater 
> >>
> >>
> >> I think this belongs to meta-networking. Also, what this one provides
> >> which is not provided by the busybox one?
> >
> > We're trying to make busybox optional for larger systems
> > that want to only use the full-featured/bloated packages.
> > It's not a large tax to carry busybox in a 50+ MB image but
> > it would be nice to not require it.
> 
> I see; I still think this belongs to meta-networking as it will allow
> this to be done however won't add new recipes in core.
> 
> If many people start to use this, we can move this to core.

To put this another way, I think it is probably reasonable that we
should be able to build an image from OE-Core with basic functionality
like networking without busybox?

Cheers,

Richard


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-commits] Alex Franco : Fix mode +st on TMPDIR when creating it

[Richard Purdie]

On Tue, 2015-09-01 at 21:09 +0200, Martin Jansa wrote:
> On Tue, Sep 01, 2015 at 10:45:22AM +, g...@git.openembedded.org wrote:
> > Module: openembedded-core.git
> > Branch: master
> > Commit: 8236d57439640a185c0226312cd4903a3ce2f53b
> > URL:
> > http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=8236d57439640a185c0226312cd4903a3ce2f53b
> > 
> > Author: Alex Franco 
> > Date:   Fri Aug 28 17:34:04 2015 -0500
> > 
> > Fix mode +st on TMPDIR when creating it
> > 
> > A sanity check fails when TMPDIR has setuid, setgid set. It was
> > proposed to fix this on TMPDIR creation instead of failing with
> > a sanity test only. This patch handles removal of those special
> > bits (and additonally, the sticky bit) from BUILDDIR and TMPDIR
> > when these directories are created.
> 
> Can you explain why it's needed to remove them?

At least in theory the sticky bit (t) can end up influencing the target
package file ownership. In the interests of build determinism we really
need TMPDIR to start in a consistent way with a consistent set of
permissions.

Put another way, I don't really want to have to add new sanity tests
that test if builds work the same if TMPDIR is +t compared to a dir that
isn't set that way.

So if you could tweak your autobuilder setup to lose the sticky bit on
that directory, I think that would be preferable to adding more corner
cases to the build environment.

If everyone had setups like this, that would change my view but it
doesn't seem to eb the ase.

Cheers,

Richard

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 05/10] initramfs-framework: support mounting rootfs in modules

[Otavio Salvador]

On Thu, Sep 3, 2015 at 3:29 AM, Patrick Ohly  wrote:
> On Wed, 2015-09-02 at 13:24 -0300, Otavio Salvador wrote:
>> On Wed, Sep 2, 2015 at 1:19 PM, Otavio Salvador  
>> wrote:
>> > If there is any limitation please share the use case so we can
>> > understand the need for it.
>>
>> I found the live module and understood why you want to do this.
>> Instead you could use:
>>
>> - live as 99-live
>> - move finish for 99-rootfs-mount and split as a package
>> - put RCONFLICTS and RPROVIDES initramfs-module-rootfs-mount.
>
> So you are suggesting that either "live" or "finish" do the final step
> of mounting the rootfs and switching to the rootfs? I actually wanted to
> have an initramfs which can be used in the live image *and* on a real
> disk and thus would need both, with the "live" module doing nothing
> unless booting from the live image.
>
> That's because the initramfs would also contain IMA initialization, and
> that is needed in both cases. Maintaining two different initramfs
> versions would be an alternative, but then the user and/or script which
> does the installation must be aware of the difference. It would also
> prevent embedding the initramfs inside the kernel
> (INITRAMFS_IMAGE_BUNDLE).

I see your point and it is a valid one.

However in this case, the finish change needs to be reworked to avoid
too much indenting change for no reason, the finish_enabled function
can be used for this.

-- 
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][fido] gnutls: CVE-2015-3308

[Sona Sarmadi]

Fixes use-after-free flaw in CRL distribution points parsing

Reference:
https://gitlab.com/gnutls/gnutls/commit/d6972be33264ecc49a86cd0958209cd7363af1e9
https://gitlab.com/gnutls/gnutls/commit/053ae65403216acdb0a4e78b25ad66ee9f444f02

http://www.openwall.com/lists/oss-security/2015/04/15/6

Signed-off-by: Sona Sarmadi 
---
 .../better-fix-for-double-free-CVE-2015-3308.patch | 65 ++
 .../eliminated-double-free-CVE-2015-3308.patch | 33 +++
 meta/recipes-support/gnutls/gnutls_3.3.12.bb   |  2 +
 3 files changed, 100 insertions(+)
 create mode 100644 
meta/recipes-support/gnutls/gnutls/better-fix-for-double-free-CVE-2015-3308.patch
 create mode 100644 
meta/recipes-support/gnutls/gnutls/eliminated-double-free-CVE-2015-3308.patch

diff --git 
a/meta/recipes-support/gnutls/gnutls/better-fix-for-double-free-CVE-2015-3308.patch
 
b/meta/recipes-support/gnutls/gnutls/better-fix-for-double-free-CVE-2015-3308.patch
new file mode 100644
index 000..8824729
--- /dev/null
+++ 
b/meta/recipes-support/gnutls/gnutls/better-fix-for-double-free-CVE-2015-3308.patch
@@ -0,0 +1,65 @@
+From 053ae65403216acdb0a4e78b25ad66ee9f444f02 Mon Sep 17 00:00:00 2001
+From: Nikos Mavrogiannopoulos 
+Date: Sat, 28 Mar 2015 22:41:03 +0100
+Subject: [PATCH] Better fix for the double free in dist point parsing
+
+Fixes CVE-2015-3308
+Upstream-Status: Backport
+
+Signed-off-by: Sona Sarmadi 
+---
+ lib/x509/x509_ext.c | 10 ++
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+diff --git a/lib/x509/x509_ext.c b/lib/x509/x509_ext.c
+index 2e69ed0..f974b02 100644
+--- a/lib/x509/x509_ext.c
 b/lib/x509/x509_ext.c
+@@ -2287,7 +2287,7 @@ int gnutls_x509_ext_import_crl_dist_points(const 
gnutls_datum_t * ext,
+   int len, ret;
+   uint8_t reasons[2];
+   unsigned i, type, rflags, j;
+-  gnutls_datum_t san;
++  gnutls_datum_t san = {NULL, 0};
+ 
+   result = asn1_create_element
+   (_gnutls_get_pkix(), "PKIX1.CRLDistributionPoints", &c2);
+@@ -2310,9 +2310,6 @@ int gnutls_x509_ext_import_crl_dist_points(const 
gnutls_datum_t * ext,
+ 
+   i = 0;
+   do {
+-  san.data = NULL;
+-  san.size = 0;
+-
+   snprintf(name, sizeof(name), "?%u.reasons", (unsigned)i + 1);
+ 
+   len = sizeof(reasons);
+@@ -2337,6 +2334,9 @@ int gnutls_x509_ext_import_crl_dist_points(const 
gnutls_datum_t * ext,
+ 
+   j = 0;
+   do {
++  san.data = NULL;
++  san.size = 0;
++
+   ret =
+   _gnutls_parse_general_name2(c2, name, j, &san,
+   &type, 0);
+@@ -2351,6 +2351,7 @@ int gnutls_x509_ext_import_crl_dist_points(const 
gnutls_datum_t * ext,
+   ret = crl_dist_points_set(cdp, type, &san, rflags);
+   if (ret < 0)
+   break;
++  san.data = NULL; /* it is now in cdp */
+ 
+   j++;
+   } while (ret >= 0);
+@@ -2360,6 +2361,7 @@ int gnutls_x509_ext_import_crl_dist_points(const 
gnutls_datum_t * ext,
+ 
+   if (ret < 0 && ret != GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE) {
+   gnutls_assert();
++  gnutls_free(san.data);
+   goto cleanup;
+   }
+ 
+-- 
+1.9.1
+
diff --git 
a/meta/recipes-support/gnutls/gnutls/eliminated-double-free-CVE-2015-3308.patch 
b/meta/recipes-support/gnutls/gnutls/eliminated-double-free-CVE-2015-3308.patch
new file mode 100644
index 000..628103f
--- /dev/null
+++ 
b/meta/recipes-support/gnutls/gnutls/eliminated-double-free-CVE-2015-3308.patch
@@ -0,0 +1,33 @@
+From d6972be33264ecc49a86cd0958209cd7363af1e9 Mon Sep 17 00:00:00 2001
+From: Nikos Mavrogiannopoulos 
+Date: Mon, 23 Mar 2015 22:55:29 +0100
+Subject: [PATCH] eliminated double-free in the parsing of dist points
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Reported by Robert Święcki.
+
+Fixes CVE-2015-3308
+Upstream-Status: Backport
+
+Signed-off-by: Sona Sarmadi 
+---
+ lib/x509/x509_ext.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/lib/x509/x509_ext.c b/lib/x509/x509_ext.c
+index c8d5867..6f09438 100644
+--- a/lib/x509/x509_ext.c
 b/lib/x509/x509_ext.c
+@@ -2360,7 +2360,6 @@ int gnutls_x509_ext_import_crl_dist_points(const 
gnutls_datum_t * ext,
+ 
+   if (ret < 0 && ret != GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE) {
+   gnutls_assert();
+-  gnutls_free(san.data);
+   goto cleanup;
+   }
+ 
+-- 
+1.9.1
+
diff --git a/meta/recipes-support/gnutls/gnutls_3.3.12.bb 
b/meta/recipes-support/gnutls/gnutls_3.3.12.bb
index b310be0..62cd2d0 100644
--- a/meta/recipes-support/gnutls/gnutls_3.3.12.bb
+++ b/meta/recipes-support/gnutls/gnutls_3.3.12.bb
@@ -3,6 +3,8 @@ require gnutls.inc
 SRC_URI += "file://correct_rpl_gettimeofday_signature.patch \

[OE-core] [PATCH][dizzy] gnutls: CVE-2015-3308

[Sona Sarmadi]

Fixes use-after-free flaw in CRL distribution points parsing

Reference:
https://gitlab.com/gnutls/gnutls/commit/d6972be33264ecc49a86cd0958209cd7363af1e9
https://gitlab.com/gnutls/gnutls/commit/053ae65403216acdb0a4e78b25ad66ee9f444f02

http://www.openwall.com/lists/oss-security/2015/04/15/6

Signed-off-by: Sona Sarmadi 
---
 .../better-fix-for-double-free-CVE-2015-3308.patch | 65 ++
 .../eliminated-double-free-CVE-2015-3308.patch | 33 +++
 meta/recipes-support/gnutls/gnutls_3.3.5.bb|  2 +
 3 files changed, 100 insertions(+)
 create mode 100644 
meta/recipes-support/gnutls/gnutls/better-fix-for-double-free-CVE-2015-3308.patch
 create mode 100644 
meta/recipes-support/gnutls/gnutls/eliminated-double-free-CVE-2015-3308.patch

diff --git 
a/meta/recipes-support/gnutls/gnutls/better-fix-for-double-free-CVE-2015-3308.patch
 
b/meta/recipes-support/gnutls/gnutls/better-fix-for-double-free-CVE-2015-3308.patch
new file mode 100644
index 000..8824729
--- /dev/null
+++ 
b/meta/recipes-support/gnutls/gnutls/better-fix-for-double-free-CVE-2015-3308.patch
@@ -0,0 +1,65 @@
+From 053ae65403216acdb0a4e78b25ad66ee9f444f02 Mon Sep 17 00:00:00 2001
+From: Nikos Mavrogiannopoulos 
+Date: Sat, 28 Mar 2015 22:41:03 +0100
+Subject: [PATCH] Better fix for the double free in dist point parsing
+
+Fixes CVE-2015-3308
+Upstream-Status: Backport
+
+Signed-off-by: Sona Sarmadi 
+---
+ lib/x509/x509_ext.c | 10 ++
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+diff --git a/lib/x509/x509_ext.c b/lib/x509/x509_ext.c
+index 2e69ed0..f974b02 100644
+--- a/lib/x509/x509_ext.c
 b/lib/x509/x509_ext.c
+@@ -2287,7 +2287,7 @@ int gnutls_x509_ext_import_crl_dist_points(const 
gnutls_datum_t * ext,
+   int len, ret;
+   uint8_t reasons[2];
+   unsigned i, type, rflags, j;
+-  gnutls_datum_t san;
++  gnutls_datum_t san = {NULL, 0};
+ 
+   result = asn1_create_element
+   (_gnutls_get_pkix(), "PKIX1.CRLDistributionPoints", &c2);
+@@ -2310,9 +2310,6 @@ int gnutls_x509_ext_import_crl_dist_points(const 
gnutls_datum_t * ext,
+ 
+   i = 0;
+   do {
+-  san.data = NULL;
+-  san.size = 0;
+-
+   snprintf(name, sizeof(name), "?%u.reasons", (unsigned)i + 1);
+ 
+   len = sizeof(reasons);
+@@ -2337,6 +2334,9 @@ int gnutls_x509_ext_import_crl_dist_points(const 
gnutls_datum_t * ext,
+ 
+   j = 0;
+   do {
++  san.data = NULL;
++  san.size = 0;
++
+   ret =
+   _gnutls_parse_general_name2(c2, name, j, &san,
+   &type, 0);
+@@ -2351,6 +2351,7 @@ int gnutls_x509_ext_import_crl_dist_points(const 
gnutls_datum_t * ext,
+   ret = crl_dist_points_set(cdp, type, &san, rflags);
+   if (ret < 0)
+   break;
++  san.data = NULL; /* it is now in cdp */
+ 
+   j++;
+   } while (ret >= 0);
+@@ -2360,6 +2361,7 @@ int gnutls_x509_ext_import_crl_dist_points(const 
gnutls_datum_t * ext,
+ 
+   if (ret < 0 && ret != GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE) {
+   gnutls_assert();
++  gnutls_free(san.data);
+   goto cleanup;
+   }
+ 
+-- 
+1.9.1
+
diff --git 
a/meta/recipes-support/gnutls/gnutls/eliminated-double-free-CVE-2015-3308.patch 
b/meta/recipes-support/gnutls/gnutls/eliminated-double-free-CVE-2015-3308.patch
new file mode 100644
index 000..628103f
--- /dev/null
+++ 
b/meta/recipes-support/gnutls/gnutls/eliminated-double-free-CVE-2015-3308.patch
@@ -0,0 +1,33 @@
+From d6972be33264ecc49a86cd0958209cd7363af1e9 Mon Sep 17 00:00:00 2001
+From: Nikos Mavrogiannopoulos 
+Date: Mon, 23 Mar 2015 22:55:29 +0100
+Subject: [PATCH] eliminated double-free in the parsing of dist points
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Reported by Robert ??wi??cki.
+
+Fixes CVE-2015-3308
+Upstream-Status: Backport
+
+Signed-off-by: Sona Sarmadi 
+---
+ lib/x509/x509_ext.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/lib/x509/x509_ext.c b/lib/x509/x509_ext.c
+index c8d5867..6f09438 100644
+--- a/lib/x509/x509_ext.c
 b/lib/x509/x509_ext.c
+@@ -2360,7 +2360,6 @@ int gnutls_x509_ext_import_crl_dist_points(const 
gnutls_datum_t * ext,
+ 
+   if (ret < 0 && ret != GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE) {
+   gnutls_assert();
+-  gnutls_free(san.data);
+   goto cleanup;
+   }
+ 
+-- 
+1.9.1
+
diff --git a/meta/recipes-support/gnutls/gnutls_3.3.5.bb 
b/meta/recipes-support/gnutls/gnutls_3.3.5.bb
index b3daa49..9f26470 100644
--- a/meta/recipes-support/gnutls/gnutls_3.3.5.bb
+++ b/meta/recipes-support/gnutls/gnutls_3.3.5.bb
@@ -1,6 +1,8 @@
 require gnutls.inc
 
 SRC_URI += "file://correct_rpl_gettimeofday_signature.patch \
+  

Re: [OE-core] [PATCH 04/10] initramfs-framework: add separate init_verbose log level parameter

[Otavio Salvador]

On Thu, Sep 3, 2015 at 3:36 AM, Patrick Ohly  wrote:
> On Wed, 2015-09-02 at 13:16 -0300, Otavio Salvador wrote:
>> On Wed, Sep 2, 2015 at 12:48 PM, Patrick Ohly  wrote:
>> > Using the general purpose "debug" and "verbose" kernel parameters to
>> > increase logging in the init script has the disadvantage that it
>> > also increases logging in other components, making the output hard
>> > to read (in particular with "debug").
>> >
>> > The new init_verbose parameter only affects the init script:
>> >   init_verbose, init_verbose=1, init_verbose=true: enable just some info 
>> > messages
>> >   init_verbose=2: debug messages
>> >
>> > Signed-off-by: Patrick Ohly 
>> > ---
>> >  meta/recipes-core/initrdscripts/initramfs-framework/init | 16 
>> > ++--
>> >  1 file changed, 14 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/meta/recipes-core/initrdscripts/initramfs-framework/init 
>> > b/meta/recipes-core/initrdscripts/initramfs-framework/init
>> > index e8f4713..cd55ee2 100755
>> > --- a/meta/recipes-core/initrdscripts/initramfs-framework/init
>> > +++ b/meta/recipes-core/initrdscripts/initramfs-framework/init
>> > @@ -14,6 +14,13 @@
>> >  # 'foo=value' as 'bootparam_foo=value'
>> >  # 'foo' as 'bootparam_foo=true'
>> >  # 'foo.bar[=value] as 'foo_bar=[value|true]'
>> > +#
>> > +# Special boot parameters always recognized by initramfs-framework (see 
>> > modules
>> > +# like "debug" for additional ones):
>> > +# debug: enable debug logging (beware, also enables debug output in other 
>> > system components)
>> > +# verbose: similar do debug, just less output
>> > +# init_verbose[=true|1|2]: same output as for verbose when no value or 
>> > true/1 are given,
>> > +#  same as debug for 2 - only affects logging in 
>> > initramfs-framework
>>
>> I personally don't see much benefit on this. The debug module is the
>> one used to debug the initramfs-framework script. If we ought to add
>> support for something like this, this should be done there.
>
> So you are saying that the msg/info/debug/fatal functions should be in
> the "debug" module? Or should they be present, but changing the logging
> level should be done by the "debug" module? How would logging work
> before the "debug" module is loaded or when it is not installed at all
> (as in a production image)?
>
> I guess one could have empty stubs in the main "init" and only do
> logging after loading the debug module - that should work, at the loss
> of early log output.

I think we can use the init-verbose and init-debug params but I would
like to see them setting the bootparam_verbose and bootparam_debug so
the init module handles it.

I am not sure if we ought to have this outside of debug module though...

-- 
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] Release status (M3 feature freeze)

[Richard Purdie]

The end of last week was supposed to be feature freeze. We're still
trying to get through the backlog of patches and we continue to see new
random/weird build failures, particularly in the runtime testing. I do
have a rough idea of the things I'm planning to take at this point, or
at least strongly consider:

* systemd upgrade (assuming tests are fixed)
* extensible SDK patches (pending review)
* devtool changes
* sstate signing
* rpm signing
* kergoth's sanity test for file ownership
* package feed comparison (build-compare)
* persistent /var/log
* consider the gcc 5.2 default change
* pseudo upgrade if we can fix the opkg issues
* midori/ephipany replacement
* initramfs/qemu improvements from Patrick

There are a number of changes in master-next which are looking ready too
(pending the current build results). If there is a feature you want to
see in 2.0 and its not listed above, let me know ASAP.

Cheers,

Richard




-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] pseudo_1.7.1.bb: New version of pseudo

[Richard Purdie]

On Wed, 2015-09-02 at 13:47 -0500, Peter Seebach wrote:
> Pseudo 1.7 adds an experimental feature (which I think needs more testing
> before it becomes the default) allowing the pseudo client to store modes
> and uid/gid values in extended attributes rather than using the sqlite
> database. On most Linux-like systems, this works only if the underlying
> file is a plain file or a directory.
> 
> Also added is a profiling feature to allow some amount of reporting on
> the wall-clock time the client spends in wrappers, processing operations,
> or in IPC. This feature is not intendeded to be precisely accurate, but
> gives a good overview of where time is going.
> 
> Based on the results from the profiling feature, the client now suppresses
> OP_OPEN and OP_EXEC messages if the server is not logging messages, and
> no longer uses constant dynamic allocation and free cycles for canonicalized
> paths.
> 
> There's a few other likely-looking optimizations being considered, but
> this seemed like a good cutoff for now.
> 
> (1.7.1 fixes two bugs, one affecting mostly XFS systems with 64-bit
> inode values, and one affecting code that called realpath(x, NULL), such
> as the RPM backend.)

This is better however opkg is still unhappy. This is build with this
pseudo patch applied:

https://autobuilder.yoctoproject.org/main/builders/nightly-ipk/builds/469

and this is a build with the same patches expect for the pseudo one:

https://autobuilder.yoctoproject.org/main/builders/nightly-ipk/builds/470

so something is still unhappy :(. The rpm builds were a lot better
though.

Cheers,

Richard

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core