From: Scott Garman <scott.a.garman@intel.com>
To: openembedded-core@lists.openembedded.org
Subject: Re: useradd changes to dbus, base-passwd
Date: Wed, 26 Oct 2011 09:52:27 -0700 [thread overview]
Message-ID: <4EA83ACB.4040001@intel.com> (raw)
In-Reply-To: <4EA825F0.1030504@windriver.com>
On 10/26/2011 08:23 AM, Mark Hatle wrote:
> On 10/25/11 10:37 PM, James Limbouris wrote:
>>> -----Original Message-----
>>> From: openembedded-core-bounces@lists.openembedded.org
>>> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
>>> James Limbouris
>>> Sent: Wednesday, 26 October 2011 9:35 AM
>>> To: openembedded-core@lists.openembedded.org
>>> Subject: [OE-core] useradd changes to dbus, base-passwd
>>>
>>> Hi,
>>>
>>> Recent changes to dbus have broken some sdk building:
>>>
>>> Missing or unbuildable dependency chain was: ['meta-toolchain-qte', 'task-qte-
>>> toolchain-host-nativesdk', 'qt4-tools-nativesdk', 'dbus-nativesdk', 'base-passwd-
>>> nativesdk']
>>>
>>> I think the commit introducing the base-passed dependency is
>>> 46e6c3fa8034b12d178d605f3f5d7efe69671a13 (dbus: use useradd class to
>>> allow use in read-only filesystems).
>>> I'm not too clear on how useradd works, so I can't tell if simply adding
>>> BBCLASSEXTEND = "native nativesdk" to base-passwd is sufficient. I'd expect
>>> that this would cause dbus to add itself to the sdk sysroot's passwd (which
>>> previously didn't exist?). Seems harmless enough... I'm giving it a try now, but
>>> any advice or opinions would be appreciated.
>>
>> It seems that adding BBCLASSEXTEND = "native nativesdk" to base-passwd and shadow-sysroot is not sufficient.
>> dbus itself will not build for nativesdk:
>>
>
> ...
>
>> NOTE: package dbus-nativesdk-1.4.12-r1: task do_install: Failed
>> ERROR: Task 1370 (virtual:nativesdk:/home/james/oe/sources/oe-core/meta/recipes-core/dbus/dbus_1.4.12.bb, do_install) failed with exit code '1'
>>
>> Perhaps we should not inherit useradd when building for nativesdk? After all, the sdk sysroots have not had /etc/passwd in the past.
>
> The useradd class should only be used in a target build. Neither nativesdk or
> native have a reasonable set of actions with useradd.
>
> I am a bit confused as to why we are building dbus in a nativesdk situation. I
> would have thought that we'd be forced to use the host system's version of dbus
> for compatibility sake. Perhaps this is the root of the problem -- or I'm
> mistaken and we do need to build it -- in that case we need to avoid including
> useradd with non-target builds.
Grepping through our classes, it looks like I can detect the nativesdk
within useradd.bbclass by checking for
bb.data.inherits_class('nativesdk', d).
I've filed a bug for this and will develop a patch to ensure useradd is
becomes a no-op for nativesdk builds:
http://bugzilla.pokylinux.org/show_bug.cgi?id=1702
Thanks for reporting this!
Scott
--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
next prev parent reply other threads:[~2011-10-26 17:00 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-26 1:34 useradd changes to dbus, base-passwd James Limbouris
2011-10-26 3:37 ` James Limbouris
2011-10-26 15:23 ` Mark Hatle
2011-10-26 16:52 ` Scott Garman [this message]
2011-11-06 20:31 ` Eric Bénard
2011-11-06 23:16 ` Scott Garman
2011-11-07 8:36 ` Eric Bénard
2011-11-07 18:24 ` Scott Garman
2011-11-07 21:11 ` [PATCH 1/2] useradd.bbclass: handle nativesdk case Eric Bénard
2011-11-07 21:11 ` [PATCH 2/2] dbus: fix install for virtclass-nativesdk Eric Bénard
2011-11-07 21:32 ` Scott Garman
2011-11-07 21:32 ` [PATCH 1/2] useradd.bbclass: handle nativesdk case Scott Garman
2011-11-07 23:47 ` Scott Garman
2011-11-08 8:41 ` Eric Bénard
2011-11-08 8:41 ` [PATCH 2/2] dbus: fix install for virtclass-nativesdk Eric Bénard
2011-11-08 14:19 ` Richard Purdie
2011-11-08 14:11 ` [PATCH 1/2] useradd.bbclass: handle nativesdk case Richard Purdie
2011-11-08 15:46 ` [PATCH] " Eric Bénard
2011-11-08 16:30 ` Richard Purdie
2011-11-08 8:45 ` [PATCH 1/2] " Eric Bénard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EA83ACB.4040001@intel.com \
--to=scott.a.garman@intel.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox