* Re: [PATCH] meta/conf/layer.conf: Add recommended download layer
From: Philip Balister @ 2016-11-24 14:03 UTC (permalink / raw)
To: Martin Jansa, Mark Hatle; +Cc: openembedded-core
In-Reply-To: <20161123185617.GH3265@jama>
[-- Attachment #1.1: Type: text/plain, Size: 2303 bytes --]
On 11/23/2016 01:56 PM, Martin Jansa wrote:
> On Wed, Nov 23, 2016 at 12:38:42PM -0600, Mark Hatle wrote:
>> On 11/23/16 12:10 PM, Martin Jansa wrote:
>>> On Wed, Nov 23, 2016 at 11:42:09AM -0600, Mark Hatle wrote:
>>>> This is a Wind River specific patch and not generally applicable.
>>>
>>> Then why is it sent to oe-core ML?
>>
>> As noted in the cover letter, I'm required to by Yocto Project compliance
>> requirements.
>>
>> As indicated LAST time I got scolded, I was told to indicate this in the patch
>> summary email -- which I did.
>
> Sorry I've noticed the cover letter only after the response.
>
> So it's only because of this requirement from Yocto Project compliance?
>
> "Have all patches applied to BitBake and OpenEmbedded-Core (if present)
> been submitted to the open source community?"
>
> Shouldn't the wording be change to something like "all applicable
> patches" or "all generally useful patches"?
>
> It seems strange to send project specific patches together with cover
> saying that they aren't generally applicable and shouldn't be merged,
> just because of this requirement.
It is useful for the larger community to see what vendors have to do.
Possibly we could decide vendor specific patches code benefit the larer
community. I'd much rather vendors over publish then under publish.
Philip
>
> Regards,
>
>>>> Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
>>>> ---
>>>> meta/conf/layer.conf | 2 ++
>>>> 1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
>>>> index 24b4df0..a94e524 100644
>>>> --- a/meta/conf/layer.conf
>>>> +++ b/meta/conf/layer.conf
>>>> @@ -11,6 +11,8 @@ BBFILE_PRIORITY_core = "5"
>>>> # cause compatibility issues with other layers
>>>> LAYERVERSION_core = "9"
>>>>
>>>> +LAYERRECOMMENDS_core = "oe-core-dl-2-2"
>>>> +
>>>> BBLAYERS_LAYERINDEX_NAME_core = "openembedded-core"
>>>>
>>>> # Set a variable to get to the top of the metadata location
>>>> --
>>>> 2.9.3
>>>>
>>>> --
>>>> _______________________________________________
>>>> Openembedded-core mailing list
>>>> Openembedded-core@lists.openembedded.org
>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>
>>
>
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 514 bytes --]
^ permalink raw reply
* Re: Kernel: Builds use old version of defconfig
From: Bruce Ashfield @ 2016-11-24 13:55 UTC (permalink / raw)
To: Mike Looijmans; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <9147101c-f99a-92fc-d45c-0b67f477a57e@topic.nl>
[-- Attachment #1: Type: text/plain, Size: 4120 bytes --]
On Thu, Nov 24, 2016 at 5:32 AM, Mike Looijmans <mike.looijmans@topic.nl>
wrote:
> On 24-11-16 11:10, Mike Looijmans wrote:
>
>> I'm currently experiencing a problem with "defconfig" files and the
>> kernel.
>>
>> In short, when I make a change to the "defconfig" file, the kernel is
>> rebuilt
>> (which is correct), but the resulting kernel has been built using the old
>> defconfig from a previous build, instead of the new one.
>>
>> The kernel recipe just contains "file://defconfig" in its SRC_URI. The
>> defconfig file is in the project's overlay.
>>
>> For example, I have a kernel with "CONFIG_DEVMEM" disabled:
>>
>> # gunzip < /proc/config.gz | grep DEVMEM
>> # CONFIG_DEVMEM is not set
>>
>> Now, I change the defconfig to contain CONFIG_DEVMEM=y and build the
>> image.
>> The result:
>>
>> # gunzip < /proc/config.gz | grep DEVMEM
>> # CONFIG_DEVMEM is not set
>>
>> So the change did not make it into the actual kernel, even though the
>> kernel
>> was rebuild as a result of the change.
>>
>> I run "bitbake -c cleansstate virtual/kernel" and build the image again:
>>
>> # gunzip < /proc/config.gz | grep DEVMEM
>> CONFIG_DEVMEM=y
>>
>> After cleaning, the result is correct and the new defconfig is active.
>>
>> I'm trying to figure out how this can happen, any help is welcome...
>>
>
> What seems to be the problem is this code in kernel.bbclass:
>
> # Copy defconfig to .config if .config does not exist. This allows
> # recipes to manage the .config themselves in
> do_configure_prepend().
> if [ -f "${WORKDIR}/defconfig" ] && [ ! -f "${B}/.config" ]; then
> cp "${WORKDIR}/defconfig" "${B}/.config"
> fi
>
> This keeps any existing ".config" file if it happens to still be in the $B
> path, which is the case if you're rebuilding a kernel.
>
> I see two possible ways to fix this.
>
> 1) During "cleanup" also remove the .config file in the build dir.
> However, the build dir is probably kept alive for a reason? I also can't
> figure out how that "cleanup" is being done.
>
>
> 2) Remove the second part of the "if" statement, so it becomes:
>
> # Copy defconfig to .config if "defconfig" exists. This allows
> # recipes to manage the .config themselves in
> do_configure_prepend().
> if [ -f "${WORKDIR}/defconfig" ]; then
> cp "${WORKDIR}/defconfig" "${B}/.config"
> fi
>
> I've tested that, and it solves my problem. However, it will probably
> break other people's config mangling?
>
>
Yep, in particular all the fragment processing which has the capability of
starting
with a defconfig and then apply fragments from any number of other places.
When
that task completes, a full .config is in ${B}. If that statement comes
along and
clobbers the .config ...
I'm actually working in the 2.3 release cycle to make the fragment
processing
be available to all kernels, which will likely solve this problem .. but we
can't
wait for that.
So I'm hoping that there's a way to make the behaviour cover both use cases.
Maybe someone with more bitbake knowledge can point out a way that can
detect if the task is being run due to a change in the task signature.
Since if you've modified the defconfig, the task is being re-run for that
change
and at that point we could safely remove the .config (versus forcing it on
the
clean step).
Bruce
>
>
> Kind regards,
>
> Mike Looijmans
> System Expert
>
> TOPIC Products
> Materiaalweg 4, NL-5681 RJ Best
> Postbus 440, NL-5680 AK Best
> Telefoon: +31 (0) 499 33 69 79
> E-mail: mike.looijmans@topicproducts.com
> Website: www.topicproducts.com
>
> Please consider the environment before printing this e-mail
>
>
>
>
>
> --
> _______________________________________________
> 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"
[-- Attachment #2: Type: text/html, Size: 6290 bytes --]
^ permalink raw reply
* [PATCH 2/2] Revert "classes/populate_sdk_ext: require uninative"
From: Ross Burton @ 2016-11-24 13:43 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1479994991-10811-1-git-send-email-ross.burton@intel.com>
The change to move C++ ABI tweaks to bitbake.conf should make this redundant, so
revert it.
This reverts commit c56cd49a12645e82d0a16bb94be16ac509f8813c.
Signed-off-by: Ross Burton <ross.burton@intel.com>
---
meta/classes/populate_sdk_ext.bbclass | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/meta/classes/populate_sdk_ext.bbclass b/meta/classes/populate_sdk_ext.bbclass
index 0e3656b..3c3a73c 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -114,6 +114,10 @@ def create_filtered_tasklist(d, sdkbasepath, tasklistfile, conf_initpath):
f.write('SSTATE_MIRRORS_forcevariable = ""\n')
# Ensure TMPDIR is the default so that clean_esdk_builddir() can delete it
f.write('TMPDIR_forcevariable = "${TOPDIR}/tmp"\n')
+ # Drop uninative if the build isn't using it (or else NATIVELSBSTRING will
+ # be different and we won't be able to find our native sstate)
+ if not bb.data.inherits_class('uninative', d):
+ f.write('INHERIT_remove = "uninative"\n')
# Unfortunately the default SDKPATH (or even a custom value) may contain characters that bitbake
# will not allow in its COREBASE path, so we need to rename the directory temporarily
@@ -609,9 +613,6 @@ fakeroot python do_populate_sdk_ext() {
if d.getVar('SDK_ARCH', True) != d.getVar('BUILD_ARCH', True):
bb.fatal('The extensible SDK can currently only be built for the same architecture as the machine being built on - SDK_ARCH is set to %s (likely via setting SDKMACHINE) which is different from the architecture of the build machine (%s). Unable to continue.' % (d.getVar('SDK_ARCH', True), d.getVar('BUILD_ARCH', True)))
- if not bb.data.inherits_class('uninative', d):
- bb.fatal('The extensible SDK requires uninative to be enabled. Enabling this is straightforward - just add the following to your configuration:\n\nrequire meta/conf/distro/include/yocto-uninative.inc\nINHERIT += "uninative"\n')
-
d.setVar('SDK_INSTALL_TARGETS', get_sdk_install_targets(d))
buildtools_fn = get_current_buildtools(d)
d.setVar('SDK_REQUIRED_UTILITIES', get_sdk_required_utilities(buildtools_fn, d))
--
2.8.1
^ permalink raw reply related
* [PATCH 1/2] conf: add C++ flags for uninative interoperatility
From: Ross Burton @ 2016-11-24 13:43 UTC (permalink / raw)
To: openembedded-core
Create a common include file for compiler flags which allow native binaries to
be interoperable on a wide range of hosts. In particular the C++ ABI is
problematic so choose the CXX11 version to allow interoperation between gcc4 and
gcc5 based hosts. Moving this to a common include instead of uninative.bbclass
allows uninative to be configured later and used in the eSDK (where its
mandatory) even if the base configuration doesn't enable uninative by default
(e.g. nodistro in OE-Core).
[ YOCTO #10645 ]
Signed-off-by: Ross Burton <ross.burton@intel.com>
---
meta/classes/uninative.bbclass | 11 -----------
meta/conf/distro/defaultsetup.conf | 3 ++-
meta/conf/distro/include/uninative-flags.inc | 9 +++++++++
3 files changed, 11 insertions(+), 12 deletions(-)
create mode 100644 meta/conf/distro/include/uninative-flags.inc
diff --git a/meta/classes/uninative.bbclass b/meta/classes/uninative.bbclass
index 89cec07..9242320 100644
--- a/meta/classes/uninative.bbclass
+++ b/meta/classes/uninative.bbclass
@@ -7,17 +7,6 @@ UNINATIVE_TARBALL ?= "${BUILD_ARCH}-nativesdk-libc.tar.bz2"
#UNINATIVE_CHECKSUM[x86_64] = "dead"
UNINATIVE_DLDIR ?= "${DL_DIR}/uninative/"
-# https://wiki.debian.org/GCC5
-# We may see binaries built with gcc5 run or linked into gcc4 environment
-# so use the older libstdc++ standard for now until we don't support gcc4
-# on the host system.
-BUILD_CXXFLAGS_append = " -D_GLIBCXX_USE_CXX11_ABI=0"
-
-#
-# icu configure defaults to CXX11 if no -std= option is passed in CXXFLAGS
-# therefore pass one
-BUILD_CXXFLAGS_append_pn-icu-native = " -std=c++98"
-
addhandler uninative_event_fetchloader
uninative_event_fetchloader[eventmask] = "bb.event.BuildStarted"
diff --git a/meta/conf/distro/defaultsetup.conf b/meta/conf/distro/defaultsetup.conf
index 71c65b14..aa21345 100644
--- a/meta/conf/distro/defaultsetup.conf
+++ b/meta/conf/distro/defaultsetup.conf
@@ -9,6 +9,8 @@ require conf/distro/include/tcmode-${TCMODE}.inc
TCLIBC ?= "glibc"
require conf/distro/include/tclibc-${TCLIBC}.inc
+require conf/distro/include/uninative-flags.inc
+
# Allow single libc distros to disable this code
TCLIBCAPPEND ?= "-${TCLIBC}"
TMPDIR .= "${TCLIBCAPPEND}"
@@ -20,4 +22,3 @@ PACKAGE_CLASSES ?= "package_ipk"
INHERIT_BLACKLIST = "blacklist"
INHERIT_DISTRO ?= "debian devshell sstate license"
INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO} ${INHERIT_BLACKLIST}"
-
diff --git a/meta/conf/distro/include/uninative-flags.inc b/meta/conf/distro/include/uninative-flags.inc
new file mode 100644
index 0000000..e9f82c3
--- /dev/null
+++ b/meta/conf/distro/include/uninative-flags.inc
@@ -0,0 +1,9 @@
+# https://wiki.debian.org/GCC5
+# We may see binaries built with gcc5 run or linked into gcc4 environment
+# so use the older libstdc++ standard for now until we don't support gcc4
+# on the host system.
+BUILD_CXXFLAGS_append = " -D_GLIBCXX_USE_CXX11_ABI=0"
+
+# icu configure defaults to CXX11 if no -std= option is passed in CXXFLAGS
+# therefore pass one
+BUILD_CXXFLAGS_append_pn-icu-native = " -std=c++98"
--
2.8.1
^ permalink raw reply related
* Re: Contents of non-rootfs partitions
From: Ed Bartosh @ 2016-11-24 13:23 UTC (permalink / raw)
To: Kristian Amlie; +Cc: openembedded-core
In-Reply-To: <fa1edaed-1498-160e-2015-8b7882c04877@mender.io>
On Thu, Nov 24, 2016 at 08:38:46AM +0100, Kristian Amlie wrote:
> On 24/11/16 07:15, Ulrich Ölmann wrote:
> > Hi,
> >
> > On Wed, Nov 23, 2016 at 04:56:56PM +0100, Patrick Ohly wrote:
> >> On Wed, 2016-11-23 at 15:22 +0200, Ed Bartosh wrote:
> >>> On Wed, Nov 23, 2016 at 02:08:28PM +0100, Kristian Amlie wrote:
> >>>> On 23/11/16 13:08, Ed Bartosh wrote:
> >>>>> On Tue, Nov 22, 2016 at 12:54:52PM +0100, Kristian Amlie wrote:
> >>>>> [...]
> >>>>> This can be done by extending existing rootfs plugin. It should be able
> >>>>> to do 2 things:
> >>>>>
> >>>>> - populate content of one rootfs directory to the partition. We can
> >>>>> extend syntax of --rootfs-dir parameter to specify optional directory path to use
> >>>>>
> >>>>> - exclude rootfs directories when populating partitions. I'd propose to
> >>>>> introduce --exclude-dirs wks parser option to handle this.
> >>>>>
> >>>>> Example of wks file with proposed new options:
> >>>>> part / --source rootfs --rootfs-dir=core-image-minimal --ondisk sda --fstype=ext4 --label root --align 1024 --exclude-dirs data --exclude-dirs home
> >>>>> part /data --source rootfs --rootfs-dir=core-image-minimal:/home --ondisk sda --fstype=ext4 --label data --align 1024
> >>>>> part /home --source rootfs --rootfs-dir=core-image-minimal:/data --ondisk sda --fstype=ext4 --label data --align 1024
> >>>>>
> >>>>> Does this make sense?
> >>>>
> >>>> Looks good. The only thing I would question is that, in the interest of
> >>>> reducing redundancy, maybe we should omit --exclude-dirs and have wic
> >>>> figure this out by combining all the entries, since "--exclude-dirs
> >>>> <dir>" and the corresponding "part <dir>" will almost always come in
> >>>> pairs. Possibly we could mark the "/" partition with one single
> >>>> --no-overlapping-dirs to force wic to make this consideration. Or do you
> >>>> think that's too magical?
> >>>>
> >>> Tt's quite implicit from my point of view. However, if people like it we
> >>> can implement it this way.
> >>
> >> I prefer the explicit --exclude-dirs. It's less surprising and perhaps
> >> there are usages for having the same content in different partitions
> >> (redundancy, factory reset, etc.).
> >>
> >> Excluding only the directory content but not the actual directory is
> >> indeed a good point. I'm a bit undecided. When excluding only the
> >> directory content, there's no way of building a rootfs without that
> >> mount point, if that's desired. OTOH, when excluding also the directory,
> >> the data would have to be staged under a different path in the rootfs
> >> and the mount point would have to be a separate, empty directory.
> >>
> >> I'm leaning towards excluding the directory content and keeping the
> >> directory.
> >
> > what about having both possibilities by leaning against the syntax that rsync
> > uses to specify if a whole source directory or only it's contents shall be
> > synced to some destination site (see [1])?
> >
> > In analogy to this to exclude only the contents of the directory named 'data'
> > you would use
> >
> > --exclude-dirs data/
> >
> > but to additionally exclude the dir itself as well it would read
> >
> > --exclude-dirs data
>
> This is creative, but ultimately too unintuitive IMHO. Rsync is the only
> tool which uses this syntax AFAIK, and it's a constant source of
> confusion, especially when mixed with cp or similar commands.
>
Would this way be less intuitive?
--exclude-path data/*
--exclude-path data
We can go even further with it allowing any level of directories:
--exclude-path data/tmp/*
--exclude-path data/db/tmp
...
--
Regards,
Ed
^ permalink raw reply
* Re: [PATCH 2/2] base-passwd: set root's default password to 'root'
From: Mike Looijmans @ 2016-11-24 7:51 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <adc8effe-1856-560a-a7fb-0d92138e1990@windriver.com>
On 24-11-16 03:01, Robert Yang wrote:
>
>
> On 11/23/2016 07:16 PM, Patrick Ohly wrote:
>> On Tue, 2016-11-22 at 23:49 -0800, Robert Yang wrote:
>>> [YOCTO #10710]
>>>
>>> Otherwise, we can't login as root when debug-tweaks is not in
>>> IMAGE_FEATURES, and there is no other users to login by default, so
>>> there is no way to login.
>>
>> Wait a second, are you really suggesting that OE-core should have a
>> default root password in its default configuration?
>>
>> That's very bad practice and I'm against doing it this way. Having a
>> default password is one of the common vulnerabilities in actual devices
>> on the market today. OE-core should make it hard to make that mistake,
>> not actively introduce it.
>>
>> So if you think that having a root password set (instead of empty), then
>> at least make it an opt-in behavior that explicitly has to be selected.
>> Make it an image feature so that images with and without default
>> password can be build in the same build configuration. Changing
>> base-passwd doesn't achieve that.
>>
>> Even then I'm still wondering what the benefit of a well-known password
>> compared to no password is. Both are equally insecure, so someone who
>> wants to allow logins might as well go with "empty password".
>
> The problem is that when debug-tweaks or empty-root-password is not in
> IMAGE_FEATURE, there is no way to login by default, which will surprise
> the user. How about:
We've used the following workaround for that in settop box images. Basically,
what you want is that login as root without password is possible, since that
can only be done from a local network connection or a serial port, which
implies that you have physical access to the device anyway. But you do NOT
want to be able to login using SSH with a blank password, because you'd
typically forward that port from a router. So remove "debug-tweaks" but don't
kill the logon:
# Some features in image.bbclass we do NOT want, so override them
# to be empty. We want to log in as root, but NOT via SSH. So we want
# to live without debug-tweaks...
zap_root_password () {
true
}
> 1) Let user can set root passwd via a variable when building.
> 2) Warn the user at build time when the image is unable to login.
Setting a root password at build time is a very very very bad idea. It's only
okay if there's ever going to be only one instance of your product in the world.
It's much better to have a blank or missing password. At least that makes it
possible to check whether the user has configured it already, like for SSH. By
default, SSH won't let you in until you have a password or a keyfile, which
allows your device to be hooked up to the internet without a "gap" where you
could access it with a trivial password.
Having written that, a bit more thought on the initial access is good. I for
one would be glad to get rid of the aforementioned workaround.
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijmans@topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
^ permalink raw reply
* Re: [PATCH] slang: Disable parallel make install
From: Burton, Ross @ 2016-11-24 11:16 UTC (permalink / raw)
To: David Vincent; +Cc: OE-core
In-Reply-To: <20161124094609.30386-1-freesilicon@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 274 bytes --]
On 24 November 2016 at 09:46, David Vincent <freesilicon@gmail.com> wrote:
> Installation task fails if run in parallel. This case happens if we
> define PARALLEL_MAKEINST to a different value of PARALLEL_MAKE.
>
Do you still have the logs of this failure?
Ross
[-- Attachment #2: Type: text/html, Size: 684 bytes --]
^ permalink raw reply
* Re: [PATCH] meta/conf/layer.conf: Add recommended download layer
From: Patrick Ohly @ 2016-11-24 11:13 UTC (permalink / raw)
To: Mark Hatle; +Cc: openembedded-core
In-Reply-To: <f2e7d5d6-7094-10b6-16bc-9398c8bb828e@windriver.com>
On Wed, 2016-11-23 at 13:42 -0600, Mark Hatle wrote:
> On 11/23/16 12:56 PM, Martin Jansa wrote:
> > "Have all patches applied to BitBake and OpenEmbedded-Core (if present)
> > been submitted to the open source community?"
> >
> > Shouldn't the wording be change to something like "all applicable
> > patches" or "all generally useful patches"?
> >
> > It seems strange to send project specific patches together with cover
> > saying that they aren't generally applicable and shouldn't be merged,
> > just because of this requirement.
>
> It was done this way to prevent people from cheating and claiming something was
> (effectively) not useful/applicable/etc when it some special secret sauce.
Perhaps one could use [FYI] instead of [PATCH] in the mail subject to
make the intention even clearer, and patchwork could get configured to
not track such patches or at least not show them as new? Just a thought.
As it stands now, there's an entry for this patch that someone
(Richard?) will have to close:
https://patchwork.openembedded.org/series/4056/
--
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.
^ permalink raw reply
* file paths in the production code
From: Umut Tezduyar Lindskog @ 2016-11-24 11:07 UTC (permalink / raw)
To: openembedded-core
Hello,
Some open source softwares are one way or another including the file
paths in the binaries which reside in non debug sectors. They won't
get stripped out and shipped in the production code. It is quite a
waste when the storage is scarce.
Do you guys handle this problem?
Umut
^ permalink raw reply
* [PATCH v3] rootfs: Modify RPM installation
From: David Vincent @ 2016-11-24 10:49 UTC (permalink / raw)
To: openembedded-core, ross.burton, leonardo.sandoval.gonzalez,
daniela.plascencia
In-Reply-To: <CAKRNOGzXLf_kfousHniKin-qqs2TURwOQQptDJTMHA9Gqe5now@mail.gmail.com>
When using a custom RPM data directory instead of the default dir
'/var/lib/rpm', the final image did not contain any of the database
files in the expected location. This commit takes into account the
'rpmlibdir' variable set into 'rootfs_rpm.bbclass'.
Signed-off-by: David Vincent <freesilicon@gmail.com>
---
meta/lib/oe/package_manager.py | 26 +++++++++++++++-----------
meta/lib/oe/rootfs.py | 3 ++-
2 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index 7ba2e4d..6344543 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -352,7 +352,8 @@ class RpmPkgsList(PkgsList):
super(RpmPkgsList, self).__init__(d, rootfs_dir)
self.rpm_cmd = bb.utils.which(os.getenv('PATH'), "rpm")
- self.image_rpmlib = os.path.join(self.rootfs_dir, 'var/lib/rpm')
+ self.rpm_libdir = self.d.getVar('rpmlibdir', True)
+ self.image_rpmlib = os.path.join(self.rootfs_dir, self.rpm_libdir[1:])
self.ml_prefix_list, self.ml_os_list = \
RpmIndexer(d, rootfs_dir).get_ml_prefix_and_os_list(arch_var, os_var)
@@ -413,7 +414,7 @@ class RpmPkgsList(PkgsList):
def list_pkgs(self):
cmd = self.rpm_cmd + ' --root ' + self.rootfs_dir
- cmd += ' -D "_dbpath /var/lib/rpm" -qa'
+ cmd += ' -D "_dbpath %s" -qa' % self.rpm_libdir
cmd += " --qf '[%{NAME} %{ARCH} %{VERSION} %{PACKAGEORIGIN}\n]'"
try:
@@ -681,7 +682,8 @@ class RpmPM(PackageManager):
self.solution_manifest = self.d.expand('${T}/saved/%s_solution' %
self.task_name)
self.saved_rpmlib = self.d.expand('${T}/saved/%s' % self.task_name)
- self.image_rpmlib = os.path.join(self.target_rootfs, 'var/lib/rpm')
+ self.rpm_libdir = self.d.getVar('rpmlibdir', True)
+ self.image_rpmlib = os.path.join(self.target_rootfs, self.rpm_libdir[1:])
if not os.path.exists(self.d.expand('${T}/saved')):
bb.utils.mkdirhier(self.d.expand('${T}/saved'))
@@ -950,8 +952,8 @@ class RpmPM(PackageManager):
# Create database so that smart doesn't complain (lazy init)
opt = "-qa"
- cmd = "%s --root %s --dbpath /var/lib/rpm %s > /dev/null" % (
- self.rpm_cmd, self.target_rootfs, opt)
+ cmd = "%s --root %s --dbpath %s %s > /dev/null" % (
+ self.rpm_cmd, self.target_rootfs, self.rpm_libdir, opt)
try:
subprocess.check_output(cmd, stderr=subprocess.STDOUT, shell=True)
except subprocess.CalledProcessError as e:
@@ -960,8 +962,8 @@ class RpmPM(PackageManager):
# Import GPG key to RPM database of the target system
if self.d.getVar('RPM_SIGN_PACKAGES', True) == '1':
pubkey_path = self.d.getVar('RPM_GPG_PUBKEY', True)
- cmd = "%s --root %s --dbpath /var/lib/rpm --import %s > /dev/null" % (
- self.rpm_cmd, self.target_rootfs, pubkey_path)
+ cmd = "%s --root %s --dbpath %s --import %s > /dev/null" % (
+ self.rpm_cmd, self.target_rootfs, self.rpm_libdir, pubkey_path)
subprocess.check_output(cmd, stderr=subprocess.STDOUT, shell=True)
# Configure smart
@@ -969,7 +971,7 @@ class RpmPM(PackageManager):
bb.utils.remove(os.path.join(self.target_rootfs, 'var/lib/smart'),
True)
self._invoke_smart('config --set rpm-root=%s' % self.target_rootfs)
- self._invoke_smart('config --set rpm-dbpath=/var/lib/rpm')
+ self._invoke_smart('config --set rpm-dbpath=%s' % self.rpm_libdir)
self._invoke_smart('config --set rpm-extra-macros._var=%s' %
self.d.getVar('localstatedir', True))
cmd = "config --set rpm-extra-macros._tmppath=/%s/tmp" % (self.install_dir_name)
@@ -1231,7 +1233,7 @@ class RpmPM(PackageManager):
if not with_dependencies:
cmd = "%s -e --nodeps " % self.rpm_cmd
cmd += "--root=%s " % self.target_rootfs
- cmd += "--dbpath=/var/lib/rpm "
+ cmd += "--dbpath=%s " % self.rpm_libdir
cmd += "--define='_cross_scriptlet_wrapper %s' " % \
self.scriptlet_wrapper
cmd += "--define='_tmppath /%s/tmp' %s" % (self.install_dir_name, ' '.join(pkgs))
@@ -1385,7 +1387,8 @@ class RpmPM(PackageManager):
saved_dir = self.target_rootfs + self.d.expand('${sysconfdir}/rpm-postinsts/') + new_pkg
cmd = self.rpm_cmd + ' -q --scripts --root ' + self.target_rootfs
- cmd += ' --dbpath=/var/lib/rpm ' + new_pkg
+ cmd += ' --dbpath=%s ' % self.rpm_libdir
+ cmd += new_pkg
cmd += ' | sed -n -e "/^postinstall scriptlet (using .*):$/,/^.* scriptlet (using .*):$/ {/.*/p}"'
cmd += ' | sed -e "/postinstall scriptlet (using \(.*\)):$/d"'
cmd += ' -e "/^.* scriptlet (using .*):$/d" > %s' % saved_dir
@@ -1417,7 +1420,8 @@ class RpmPM(PackageManager):
'''
def unlock_rpm_db(self):
# Remove rpm db lock files
- rpm_db_locks = glob.glob('%s/var/lib/rpm/__db.*' % self.target_rootfs)
+ rpm_db_locks = glob.glob('%s%s/__db.*' % (self.target_rootfs,
+ self.rpm_libdir))
for f in rpm_db_locks:
bb.utils.remove(f, True)
diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index a348b97..7cf8ce8 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -426,6 +426,7 @@ class RpmRootfs(Rootfs):
def _create(self):
pkgs_to_install = self.manifest.parse_initial_manifest()
+ rpm_libdir = self.d.getVar('rpmlibdir', True)
rpm_pre_process_cmds = self.d.getVar('RPM_PREPROCESS_COMMANDS', True)
rpm_post_process_cmds = self.d.getVar('RPM_POSTPROCESS_COMMANDS', True)
@@ -473,7 +474,7 @@ class RpmRootfs(Rootfs):
if self.progress_reporter:
self.progress_reporter.next_stage()
- self._setup_dbg_rootfs(['/etc/rpm', '/var/lib/rpm', '/var/lib/smart'])
+ self._setup_dbg_rootfs(['/etc/rpm', rpm_libdir, '/var/lib/smart'])
execute_pre_post_process(self.d, rpm_post_process_cmds)
--
2.10.2
^ permalink raw reply related
* Re: Kernel: Builds use old version of defconfig
From: Mike Looijmans @ 2016-11-24 10:32 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <6df42b3b-66b7-25dc-faac-e26e19fefbfd@topic.nl>
On 24-11-16 11:10, Mike Looijmans wrote:
> I'm currently experiencing a problem with "defconfig" files and the kernel.
>
> In short, when I make a change to the "defconfig" file, the kernel is rebuilt
> (which is correct), but the resulting kernel has been built using the old
> defconfig from a previous build, instead of the new one.
>
> The kernel recipe just contains "file://defconfig" in its SRC_URI. The
> defconfig file is in the project's overlay.
>
> For example, I have a kernel with "CONFIG_DEVMEM" disabled:
>
> # gunzip < /proc/config.gz | grep DEVMEM
> # CONFIG_DEVMEM is not set
>
> Now, I change the defconfig to contain CONFIG_DEVMEM=y and build the image.
> The result:
>
> # gunzip < /proc/config.gz | grep DEVMEM
> # CONFIG_DEVMEM is not set
>
> So the change did not make it into the actual kernel, even though the kernel
> was rebuild as a result of the change.
>
> I run "bitbake -c cleansstate virtual/kernel" and build the image again:
>
> # gunzip < /proc/config.gz | grep DEVMEM
> CONFIG_DEVMEM=y
>
> After cleaning, the result is correct and the new defconfig is active.
>
> I'm trying to figure out how this can happen, any help is welcome...
What seems to be the problem is this code in kernel.bbclass:
# Copy defconfig to .config if .config does not exist. This allows
# recipes to manage the .config themselves in do_configure_prepend().
if [ -f "${WORKDIR}/defconfig" ] && [ ! -f "${B}/.config" ]; then
cp "${WORKDIR}/defconfig" "${B}/.config"
fi
This keeps any existing ".config" file if it happens to still be in the $B
path, which is the case if you're rebuilding a kernel.
I see two possible ways to fix this.
1) During "cleanup" also remove the .config file in the build dir. However,
the build dir is probably kept alive for a reason? I also can't figure out how
that "cleanup" is being done.
2) Remove the second part of the "if" statement, so it becomes:
# Copy defconfig to .config if "defconfig" exists. This allows
# recipes to manage the .config themselves in do_configure_prepend().
if [ -f "${WORKDIR}/defconfig" ]; then
cp "${WORKDIR}/defconfig" "${B}/.config"
fi
I've tested that, and it solves my problem. However, it will probably break
other people's config mangling?
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijmans@topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
^ permalink raw reply
* Re: [PATCH 1/1] runqemu: add user mode (SLIRP) support to x86 QEMU targets
From: Robert Yang @ 2016-11-24 10:29 UTC (permalink / raw)
To: Todor Minchev, openembedded-core
In-Reply-To: <20161026170559.9444-1-todor.minchev@linux.intel.com>
Hi Todor,
On 10/27/2016 01:05 AM, Todor Minchev wrote:
> Using 'slirp' as a command line option to runqemu will start QEMU
> with user mode networking instead of creating tun/tap devices.
> SLIRP does not require root access. By default port 2222 on the
> host will be mapped to port 22 in the guest. The default port
> mapping can be overwritten with the QB_SLIRP_OPT variable e.g.
>
> QB_SLIRP_OPT = "-net nic,model=e1000 -net user,hostfwd=tcp::2222-:22"
>
> Signed-off-by: Todor Minchev <todor.minchev@linux.intel.com>
> ---
> meta/conf/machine/include/qemuboot-x86.inc | 1 +
> scripts/runqemu | 3 ++-
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/meta/conf/machine/include/qemuboot-x86.inc b/meta/conf/machine/include/qemuboot-x86.inc
> index 06ac983..0870294 100644
> --- a/meta/conf/machine/include/qemuboot-x86.inc
> +++ b/meta/conf/machine/include/qemuboot-x86.inc
> @@ -13,3 +13,4 @@ QB_AUDIO_OPT = "-soundhw ac97,es1370"
> QB_KERNEL_CMDLINE_APPEND = "vga=0 uvesafb.mode_option=640x480-32 oprofile.timer=1 uvesafb.task_timeout=-1"
> # Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy
> QB_OPT_APPEND = "-vga vmware -show-cursor -usb -usbdevice tablet -device virtio-rng-pci"
> +QB_SLIRP_OPT = "-net nic,model=e1000 -net user,hostfwd=tcp::2222-:22"
It will causes errors when multiple qemus are running:
qemu-system-x86_64: -net user,hostfwd=tcp::2222-:22: could not set up host
forwarding rule 'tcp::2222-:22'
qemu-system-x86_64: -net user,hostfwd=tcp::2222-:22: Device 'user' could not be
initialized
This because the port are used by another qemu. I will move these
code into runqemu, and check whether the port is available, add 1 if not
until find a usable port. Default to forward 22, and user can add other
ports.
// Robert
> diff --git a/scripts/runqemu b/scripts/runqemu
> index dbe17ab..6952f32 100755
> --- a/scripts/runqemu
> +++ b/scripts/runqemu
> @@ -542,7 +542,8 @@ class BaseConfig(object):
> def check_and_set(self):
> """Check configs sanity and set when needed"""
> self.validate_paths()
> - check_tun()
> + if not self.slirp_enabled:
> + check_tun()
> # Check audio
> if self.audio_enabled:
> if not self.get('QB_AUDIO_DRV'):
>
^ permalink raw reply
* Kernel: Builds use old version of defconfig
From: Mike Looijmans @ 2016-11-24 10:10 UTC (permalink / raw)
To: openembedded-core
I'm currently experiencing a problem with "defconfig" files and the kernel.
In short, when I make a change to the "defconfig" file, the kernel is rebuilt
(which is correct), but the resulting kernel has been built using the old
defconfig from a previous build, instead of the new one.
The kernel recipe just contains "file://defconfig" in its SRC_URI. The
defconfig file is in the project's overlay.
For example, I have a kernel with "CONFIG_DEVMEM" disabled:
# gunzip < /proc/config.gz | grep DEVMEM
# CONFIG_DEVMEM is not set
Now, I change the defconfig to contain CONFIG_DEVMEM=y and build the image.
The result:
# gunzip < /proc/config.gz | grep DEVMEM
# CONFIG_DEVMEM is not set
So the change did not make it into the actual kernel, even though the kernel
was rebuild as a result of the change.
I run "bitbake -c cleansstate virtual/kernel" and build the image again:
# gunzip < /proc/config.gz | grep DEVMEM
CONFIG_DEVMEM=y
After cleaning, the result is correct and the new defconfig is active.
I'm trying to figure out how this can happen, any help is welcome...
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijmans@topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
^ permalink raw reply
* [PATCH v2] pseudo: include fix for xattr corruption
From: Patrick Ohly @ 2016-11-24 10:28 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1479981089-2181-1-git-send-email-patrick.ohly@intel.com>
pseudo_1.8.1.bb gets the backported patch and pseudo_git.bb gets
updated to include the commit.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
Notes:
Change since V1:
Updated the commit message. It was still the one written
for the initial, broken upstream patch for the problem.
The attached patch works.
.../pseudo/files/More-correctly-fix-xattrs.patch | 37 ++++++++++++++++++++++
meta/recipes-devtools/pseudo/pseudo_1.8.1.bb | 1 +
meta/recipes-devtools/pseudo/pseudo_git.bb | 2 +-
3 files changed, 39 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-devtools/pseudo/files/More-correctly-fix-xattrs.patch
diff --git a/meta/recipes-devtools/pseudo/files/More-correctly-fix-xattrs.patch b/meta/recipes-devtools/pseudo/files/More-correctly-fix-xattrs.patch
new file mode 100644
index 0000000..3d178f9
--- /dev/null
+++ b/meta/recipes-devtools/pseudo/files/More-correctly-fix-xattrs.patch
@@ -0,0 +1,37 @@
+From 45eca34c754d416a38bee90fb2d3c110a0b6cc5f Mon Sep 17 00:00:00 2001
+From: Seebs <seebs@seebs.net>
+Date: Thu, 3 Nov 2016 11:36:12 -0500
+Subject: [PATCH] More-correctly fix xattrs
+
+Fix provided by Patrick Ohly <patrick.ohly@intel.com>. This resolves
+the actual cause of the path length mismatches, and explains why
+I couldn't quite explain why the previous one had only sometimes
+worked, also why it showed up on directories but not plain files.
+
+Signed-off-by: Seebs <seebs@seebs.net>
+
+Fixes [YOCTO #10623]
+
+Upstream-Status: Backport [commit 45eca34c754d416a38bee90fb2d3c110a0b6cc5f]
+
+Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
+---
+ pseudo_client.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/pseudo_client.c b/pseudo_client.c
+index 6a08df3..b1a00fa 100644
+--- a/pseudo_client.c
++++ b/pseudo_client.c
+@@ -1676,7 +1676,7 @@ pseudo_client_op(pseudo_op_t op, int access, int fd, int dirfd, const char *path
+ * empty path for that.
+ */
+ if (path_extra_1) {
+- size_t full_len = path_extra_1len + 1 + pathlen;
++ size_t full_len = path_extra_1len + 1 + pathlen - strip_slash;
+ size_t partial_len = pathlen - 1 - strip_slash;
+ if (path_extra_2) {
+ full_len += path_extra_2len + 1;
+--
+2.1.4
+
diff --git a/meta/recipes-devtools/pseudo/pseudo_1.8.1.bb b/meta/recipes-devtools/pseudo/pseudo_1.8.1.bb
index fb70034..90b53c0 100644
--- a/meta/recipes-devtools/pseudo/pseudo_1.8.1.bb
+++ b/meta/recipes-devtools/pseudo/pseudo_1.8.1.bb
@@ -10,6 +10,7 @@ SRC_URI = "http://downloads.yoctoproject.org/releases/pseudo/${BPN}-${PV}.tar.bz
file://0001-Quiet-diagnostics-during-startup-for-pseudo-d.patch \
file://0002-Use-correct-file-descriptor.patch \
file://0003-Fix-renameat-parallel-to-previous-fix-to-rename.patch \
+ file://More-correctly-fix-xattrs.patch \
"
SRC_URI[md5sum] = "ee38e4fb62ff88ad067b1a5a3825bac7"
diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb b/meta/recipes-devtools/pseudo/pseudo_git.bb
index 8110b1a..ac923bb 100644
--- a/meta/recipes-devtools/pseudo/pseudo_git.bb
+++ b/meta/recipes-devtools/pseudo/pseudo_git.bb
@@ -1,6 +1,6 @@
require pseudo.inc
-SRCREV = "befc6dbd6469d428c9e0830dbe51bdf7ac39d9ae"
+SRCREV = "45eca34c754d416a38bee90fb2d3c110a0b6cc5f"
PV = "1.8.1+git${SRCPV}"
DEFAULT_PREFERENCE = "-1"
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v3] classes: Fix alternatives and rc.d ordering
From: Markus Lehtonen @ 2016-11-24 10:25 UTC (permalink / raw)
To: David Vincent, openembedded-core, haris.okanovic
In-Reply-To: <20161124092636.9533-1-freesilicon@gmail.com>
On Thu, 2016-11-24 at 10:26 +0100, David Vincent wrote:
> When using an alternative as an initscript, the ordering between
> update-rc.d and update-alternatives tasks during prerm and postinst
> tasks must always be the following in order to work:
> * prerm:
> - stop daemon
> - remove alternative
>
> * postinst:
> - add alternative
> - start daemon
>
> This patchset adds comments to the scripts generated by both classes and
> organize the generated sections based on those comments.
>
> [YOCTO #10433]
I also commented this in the bug, but after playing with these a bit I'm
not convinced that init scripts should be managed by update-alternatives.
First, I don't see much reasoning why two syslog services should be
installed in parallel. Also, no other package or distro use this kind of
construction, AFAIK. So I'd avoid complication of the bbclasses for the
purpose of one package only.
If we really want to make these install in parallel I think we should just
name the files differently.
Thanks,
Markus
^ permalink raw reply
* [PATCH] pseudo: include fix for xattr corruption
From: Patrick Ohly @ 2016-11-24 9:51 UTC (permalink / raw)
To: openembedded-core
pseudo_1.8.1.bb gets the backported patch and pseudo_git.bb gets
updated to include the commit, which currently is the most recent
commit on the pseudo master branch.
There's just one problem - it breaks other cases:
foo: security.SMACK64: No such attribute
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
.../pseudo/files/More-correctly-fix-xattrs.patch | 37 ++++++++++++++++++++++
meta/recipes-devtools/pseudo/pseudo_1.8.1.bb | 1 +
meta/recipes-devtools/pseudo/pseudo_git.bb | 2 +-
3 files changed, 39 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-devtools/pseudo/files/More-correctly-fix-xattrs.patch
diff --git a/meta/recipes-devtools/pseudo/files/More-correctly-fix-xattrs.patch b/meta/recipes-devtools/pseudo/files/More-correctly-fix-xattrs.patch
new file mode 100644
index 0000000..3d178f9
--- /dev/null
+++ b/meta/recipes-devtools/pseudo/files/More-correctly-fix-xattrs.patch
@@ -0,0 +1,37 @@
+From 45eca34c754d416a38bee90fb2d3c110a0b6cc5f Mon Sep 17 00:00:00 2001
+From: Seebs <seebs@seebs.net>
+Date: Thu, 3 Nov 2016 11:36:12 -0500
+Subject: [PATCH] More-correctly fix xattrs
+
+Fix provided by Patrick Ohly <patrick.ohly@intel.com>. This resolves
+the actual cause of the path length mismatches, and explains why
+I couldn't quite explain why the previous one had only sometimes
+worked, also why it showed up on directories but not plain files.
+
+Signed-off-by: Seebs <seebs@seebs.net>
+
+Fixes [YOCTO #10623]
+
+Upstream-Status: Backport [commit 45eca34c754d416a38bee90fb2d3c110a0b6cc5f]
+
+Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
+---
+ pseudo_client.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/pseudo_client.c b/pseudo_client.c
+index 6a08df3..b1a00fa 100644
+--- a/pseudo_client.c
++++ b/pseudo_client.c
+@@ -1676,7 +1676,7 @@ pseudo_client_op(pseudo_op_t op, int access, int fd, int dirfd, const char *path
+ * empty path for that.
+ */
+ if (path_extra_1) {
+- size_t full_len = path_extra_1len + 1 + pathlen;
++ size_t full_len = path_extra_1len + 1 + pathlen - strip_slash;
+ size_t partial_len = pathlen - 1 - strip_slash;
+ if (path_extra_2) {
+ full_len += path_extra_2len + 1;
+--
+2.1.4
+
diff --git a/meta/recipes-devtools/pseudo/pseudo_1.8.1.bb b/meta/recipes-devtools/pseudo/pseudo_1.8.1.bb
index fb70034..90b53c0 100644
--- a/meta/recipes-devtools/pseudo/pseudo_1.8.1.bb
+++ b/meta/recipes-devtools/pseudo/pseudo_1.8.1.bb
@@ -10,6 +10,7 @@ SRC_URI = "http://downloads.yoctoproject.org/releases/pseudo/${BPN}-${PV}.tar.bz
file://0001-Quiet-diagnostics-during-startup-for-pseudo-d.patch \
file://0002-Use-correct-file-descriptor.patch \
file://0003-Fix-renameat-parallel-to-previous-fix-to-rename.patch \
+ file://More-correctly-fix-xattrs.patch \
"
SRC_URI[md5sum] = "ee38e4fb62ff88ad067b1a5a3825bac7"
diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb b/meta/recipes-devtools/pseudo/pseudo_git.bb
index 8110b1a..ac923bb 100644
--- a/meta/recipes-devtools/pseudo/pseudo_git.bb
+++ b/meta/recipes-devtools/pseudo/pseudo_git.bb
@@ -1,6 +1,6 @@
require pseudo.inc
-SRCREV = "befc6dbd6469d428c9e0830dbe51bdf7ac39d9ae"
+SRCREV = "45eca34c754d416a38bee90fb2d3c110a0b6cc5f"
PV = "1.8.1+git${SRCPV}"
DEFAULT_PREFERENCE = "-1"
--
2.1.4
^ permalink raw reply related
* [PATCH] qemuboot.bbclass: do not hook into do_rootfs
From: Patrick Ohly @ 2016-11-24 9:51 UTC (permalink / raw)
To: openembedded-core
Writing qemuboot.conf in write_qemuboot_conf() does not modify the
rootfs and thus conceptually shouldn't be executed as part of rootfs
creation.
Running it as separate task is cleaner and fixes the problem of
missing qemuboot.conf files for meta-swupd virtual images; those
images replace do_rootfs and ROOTFS_POSTPROCESS_COMMANDs don't run at
all.
The task gets added such that it runs roughly at the same time as
before. Probably it doesn't actually need to depend on do_rootfs, but
this way we don't write a useless qemuboot.conf in cases where
do_rootfs fails.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
meta/classes/qemuboot.bbclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/classes/qemuboot.bbclass b/meta/classes/qemuboot.bbclass
index 39df3ad..8b1d4d0 100644
--- a/meta/classes/qemuboot.bbclass
+++ b/meta/classes/qemuboot.bbclass
@@ -42,7 +42,7 @@ QB_DEFAULT_FSTYPE ?= "ext4"
QB_OPT_APPEND ?= "-show-cursor"
# Create qemuboot.conf
-ROOTFS_POSTPROCESS_COMMAND += "write_qemuboot_conf; "
+addtask do_write_qemuboot_conf after do_rootfs before do_image
def qemuboot_vars(d):
build_vars = ['MACHINE', 'TUNE_ARCH', 'DEPLOY_DIR_IMAGE',
@@ -51,8 +51,8 @@ def qemuboot_vars(d):
'STAGING_DIR_HOST']
return build_vars + [k for k in d.keys() if k.startswith('QB_')]
-write_qemuboot_conf[vardeps] += "${@' '.join(qemuboot_vars(d))}"
-python write_qemuboot_conf() {
+do_write_qemuboot_conf[vardeps] += "${@' '.join(qemuboot_vars(d))}"
+python do_write_qemuboot_conf() {
import configparser
qemuboot = "%s/%s.qemuboot.conf" % (d.getVar('DEPLOY_DIR_IMAGE', True), d.getVar('IMAGE_NAME', True))
--
2.1.4
^ permalink raw reply related
* [PATCH] slang: Disable parallel make install
From: David Vincent @ 2016-11-24 9:46 UTC (permalink / raw)
To: openembedded-core
Installation task fails if run in parallel. This case happens if we
define PARALLEL_MAKEINST to a different value of PARALLEL_MAKE.
Signed-off-by: David Vincent <freesilicon@gmail.com>
---
meta/recipes-extended/slang/slang_2.3.0.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-extended/slang/slang_2.3.0.bb b/meta/recipes-extended/slang/slang_2.3.0.bb
index 52b2a63..d5967d2 100644
--- a/meta/recipes-extended/slang/slang_2.3.0.bb
+++ b/meta/recipes-extended/slang/slang_2.3.0.bb
@@ -53,5 +53,6 @@ do_install() {
FILES_${PN} += "${libdir}/${BPN}/v2/modules/ ${datadir}/slsh/"
PARALLEL_MAKE = ""
+PARALLEL_MAKEINST = ""
BBCLASSEXTEND = "native"
--
2.10.2
^ permalink raw reply related
* [PATCH v3] rootfs: Modify RPM installation
From: David Vincent @ 2016-11-24 9:39 UTC (permalink / raw)
To: openembedded-core, ross.burton, leonardo.sandoval.gonzalez,
daniela.plascencia
In-Reply-To: <CAKRNOGzb7Z4OW-VyrZyGZWKmHXCbn7w55Eyeto6Rs61LFt0-hg@mail.gmail.com>
When using a custom RPM data directory instead of the default dir
'/var/lib/rpm', the final image did not contain any of the database
files in the expected location. This commit takes into account the
'rpmlibdir' variable set into 'rootfs_rpm.bbclass'.
Signed-off-by: David Vincent <freesilicon@gmail.com>
---
meta/lib/oe/package_manager.py | 26 +++++++++++++++-----------
meta/lib/oe/rootfs.py | 3 ++-
2 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index 7ba2e4d..6344543 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -352,7 +352,8 @@ class RpmPkgsList(PkgsList):
super(RpmPkgsList, self).__init__(d, rootfs_dir)
self.rpm_cmd = bb.utils.which(os.getenv('PATH'), "rpm")
- self.image_rpmlib = os.path.join(self.rootfs_dir, 'var/lib/rpm')
+ self.rpm_libdir = self.d.getVar('rpmlibdir', True)
+ self.image_rpmlib = os.path.join(self.rootfs_dir, self.rpm_libdir[1:])
self.ml_prefix_list, self.ml_os_list = \
RpmIndexer(d, rootfs_dir).get_ml_prefix_and_os_list(arch_var, os_var)
@@ -413,7 +414,7 @@ class RpmPkgsList(PkgsList):
def list_pkgs(self):
cmd = self.rpm_cmd + ' --root ' + self.rootfs_dir
- cmd += ' -D "_dbpath /var/lib/rpm" -qa'
+ cmd += ' -D "_dbpath %s" -qa' % self.rpm_libdir
cmd += " --qf '[%{NAME} %{ARCH} %{VERSION} %{PACKAGEORIGIN}\n]'"
try:
@@ -681,7 +682,8 @@ class RpmPM(PackageManager):
self.solution_manifest = self.d.expand('${T}/saved/%s_solution' %
self.task_name)
self.saved_rpmlib = self.d.expand('${T}/saved/%s' % self.task_name)
- self.image_rpmlib = os.path.join(self.target_rootfs, 'var/lib/rpm')
+ self.rpm_libdir = self.d.getVar('rpmlibdir', True)
+ self.image_rpmlib = os.path.join(self.target_rootfs, self.rpm_libdir[1:])
if not os.path.exists(self.d.expand('${T}/saved')):
bb.utils.mkdirhier(self.d.expand('${T}/saved'))
@@ -950,8 +952,8 @@ class RpmPM(PackageManager):
# Create database so that smart doesn't complain (lazy init)
opt = "-qa"
- cmd = "%s --root %s --dbpath /var/lib/rpm %s > /dev/null" % (
- self.rpm_cmd, self.target_rootfs, opt)
+ cmd = "%s --root %s --dbpath %s %s > /dev/null" % (
+ self.rpm_cmd, self.target_rootfs, self.rpm_libdir, opt)
try:
subprocess.check_output(cmd, stderr=subprocess.STDOUT, shell=True)
except subprocess.CalledProcessError as e:
@@ -960,8 +962,8 @@ class RpmPM(PackageManager):
# Import GPG key to RPM database of the target system
if self.d.getVar('RPM_SIGN_PACKAGES', True) == '1':
pubkey_path = self.d.getVar('RPM_GPG_PUBKEY', True)
- cmd = "%s --root %s --dbpath /var/lib/rpm --import %s > /dev/null" % (
- self.rpm_cmd, self.target_rootfs, pubkey_path)
+ cmd = "%s --root %s --dbpath %s --import %s > /dev/null" % (
+ self.rpm_cmd, self.target_rootfs, self.rpm_libdir, pubkey_path)
subprocess.check_output(cmd, stderr=subprocess.STDOUT, shell=True)
# Configure smart
@@ -969,7 +971,7 @@ class RpmPM(PackageManager):
bb.utils.remove(os.path.join(self.target_rootfs, 'var/lib/smart'),
True)
self._invoke_smart('config --set rpm-root=%s' % self.target_rootfs)
- self._invoke_smart('config --set rpm-dbpath=/var/lib/rpm')
+ self._invoke_smart('config --set rpm-dbpath=%s' % self.rpm_libdir)
self._invoke_smart('config --set rpm-extra-macros._var=%s' %
self.d.getVar('localstatedir', True))
cmd = "config --set rpm-extra-macros._tmppath=/%s/tmp" % (self.install_dir_name)
@@ -1231,7 +1233,7 @@ class RpmPM(PackageManager):
if not with_dependencies:
cmd = "%s -e --nodeps " % self.rpm_cmd
cmd += "--root=%s " % self.target_rootfs
- cmd += "--dbpath=/var/lib/rpm "
+ cmd += "--dbpath=%s " % self.rpm_libdir
cmd += "--define='_cross_scriptlet_wrapper %s' " % \
self.scriptlet_wrapper
cmd += "--define='_tmppath /%s/tmp' %s" % (self.install_dir_name, ' '.join(pkgs))
@@ -1385,7 +1387,8 @@ class RpmPM(PackageManager):
saved_dir = self.target_rootfs + self.d.expand('${sysconfdir}/rpm-postinsts/') + new_pkg
cmd = self.rpm_cmd + ' -q --scripts --root ' + self.target_rootfs
- cmd += ' --dbpath=/var/lib/rpm ' + new_pkg
+ cmd += ' --dbpath=%s ' % self.rpm_libdir
+ cmd += new_pkg
cmd += ' | sed -n -e "/^postinstall scriptlet (using .*):$/,/^.* scriptlet (using .*):$/ {/.*/p}"'
cmd += ' | sed -e "/postinstall scriptlet (using \(.*\)):$/d"'
cmd += ' -e "/^.* scriptlet (using .*):$/d" > %s' % saved_dir
@@ -1417,7 +1420,8 @@ class RpmPM(PackageManager):
'''
def unlock_rpm_db(self):
# Remove rpm db lock files
- rpm_db_locks = glob.glob('%s/var/lib/rpm/__db.*' % self.target_rootfs)
+ rpm_db_locks = glob.glob('%s%s/__db.*' % (self.target_rootfs,
+ self.rpm_libdir))
for f in rpm_db_locks:
bb.utils.remove(f, True)
diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index a348b97..7cf8ce8 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -426,6 +426,7 @@ class RpmRootfs(Rootfs):
def _create(self):
pkgs_to_install = self.manifest.parse_initial_manifest()
+ rpm_libdir = self.d.getVar('rpmlibdir', True)
rpm_pre_process_cmds = self.d.getVar('RPM_PREPROCESS_COMMANDS', True)
rpm_post_process_cmds = self.d.getVar('RPM_POSTPROCESS_COMMANDS', True)
@@ -473,7 +474,7 @@ class RpmRootfs(Rootfs):
if self.progress_reporter:
self.progress_reporter.next_stage()
- self._setup_dbg_rootfs(['/etc/rpm', '/var/lib/rpm', '/var/lib/smart'])
+ self._setup_dbg_rootfs(['/etc/rpm', rpm_libdir, '/var/lib/smart'])
execute_pre_post_process(self.d, rpm_post_process_cmds)
--
2.10.2
^ permalink raw reply related
* [PATCH v3] classes: Fix alternatives and rc.d ordering
From: David Vincent @ 2016-11-24 9:26 UTC (permalink / raw)
To: openembedded-core, haris.okanovic, markus.lehtonen
In-Reply-To: <CAKRNOGwhpqo55k08azMiPt9opo8mCFE_rRE1dxdkntz2eGsLMA@mail.gmail.com>
When using an alternative as an initscript, the ordering between
update-rc.d and update-alternatives tasks during prerm and postinst
tasks must always be the following in order to work:
* prerm:
- stop daemon
- remove alternative
* postinst:
- add alternative
- start daemon
This patchset adds comments to the scripts generated by both classes and
organize the generated sections based on those comments.
[YOCTO #10433]
Signed-off-by: David Vincent <freesilicon@gmail.com>
---
meta/classes/update-alternatives.bbclass | 27 +++++++++++++++++++++------
meta/classes/update-rc.d.bbclass | 20 ++++++++++++++++++--
2 files changed, 39 insertions(+), 8 deletions(-)
diff --git a/meta/classes/update-alternatives.bbclass b/meta/classes/update-alternatives.bbclass
index 1fdd681..bbd5a47 100644
--- a/meta/classes/update-alternatives.bbclass
+++ b/meta/classes/update-alternatives.bbclass
@@ -195,8 +195,8 @@ python populate_packages_updatealternatives () {
pkgdest = d.getVar('PKGD', True)
for pkg in (d.getVar('PACKAGES', True) or "").split():
# Create post install/removal scripts
- alt_setup_links = ""
- alt_remove_links = ""
+ alt_setup_links = "# Begin section update-alternatives\n"
+ alt_remove_links = "# Begin section update-alternatives\n"
for alt_name in (d.getVar('ALTERNATIVE_%s' % pkg, True) or "").split():
alt_link = d.getVarFlag('ALTERNATIVE_LINK_NAME', alt_name, True)
alt_target = d.getVarFlag('ALTERNATIVE_TARGET_%s' % pkg, alt_name, True) or d.getVarFlag('ALTERNATIVE_TARGET', alt_name, True)
@@ -219,8 +219,11 @@ python populate_packages_updatealternatives () {
# Default to generate shell script.. eventually we may want to change this...
alt_target = os.path.normpath(alt_target)
- alt_setup_links += '\tupdate-alternatives --install %s %s %s %s\n' % (alt_link, alt_name, alt_target, alt_priority)
- alt_remove_links += '\tupdate-alternatives --remove %s %s\n' % (alt_name, alt_target)
+ alt_setup_links += 'update-alternatives --install %s %s %s %s\n' % (alt_link, alt_name, alt_target, alt_priority)
+ alt_remove_links += 'update-alternatives --remove %s %s\n' % (alt_name, alt_target)
+
+ alt_setup_links += "# End section update-alternatives\n"
+ alt_remove_links += "# End section update-alternatives\n"
if alt_setup_links:
# RDEPENDS setup
@@ -232,12 +235,24 @@ python populate_packages_updatealternatives () {
bb.note('adding update-alternatives calls to postinst/prerm for %s' % pkg)
bb.note('%s' % alt_setup_links)
postinst = d.getVar('pkg_postinst_%s' % pkg, True) or '#!/bin/sh\n'
- postinst += alt_setup_links
+ postinst = postinst.splitlines(True)
+ try:
+ index = postinst.index('# Begin section update-rc.d\n')
+ postinst.insert(index, alt_setup_links)
+ except ValueError:
+ postinst.append(alt_setup_links)
+ postinst = ''.join(postinst)
d.setVar('pkg_postinst_%s' % pkg, postinst)
bb.note('%s' % alt_remove_links)
prerm = d.getVar('pkg_prerm_%s' % pkg, True) or '#!/bin/sh\n'
- prerm += alt_remove_links
+ prerm = prerm.splitlines(True)
+ try:
+ index = prerm.index('# End section update-rc.d\n')
+ prerm.insert(index + 1, alt_remove_links)
+ except ValueError:
+ prerm.append(alt_remove_links)
+ prerm = ''.join(prerm)
d.setVar('pkg_prerm_%s' % pkg, prerm)
}
diff --git a/meta/classes/update-rc.d.bbclass b/meta/classes/update-rc.d.bbclass
index 321924b..18df2dc 100644
--- a/meta/classes/update-rc.d.bbclass
+++ b/meta/classes/update-rc.d.bbclass
@@ -26,6 +26,7 @@ fi
}
updatercd_postinst() {
+# Begin section update-rc.d
if type update-rc.d >/dev/null 2>/dev/null; then
if [ -n "$D" ]; then
OPT="-r $D"
@@ -34,12 +35,15 @@ if type update-rc.d >/dev/null 2>/dev/null; then
fi
update-rc.d $OPT ${INITSCRIPT_NAME} ${INITSCRIPT_PARAMS}
fi
+# End section update-rc.d
}
updatercd_prerm() {
+# Begin section update-rc.d
if [ -z "$D" -a -x "${INIT_D_DIR}/${INITSCRIPT_NAME}" ]; then
${INIT_D_DIR}/${INITSCRIPT_NAME} stop || :
fi
+# End section update-rc.d
}
updatercd_postrm() {
@@ -102,13 +106,25 @@ python populate_packages_updatercd () {
postinst = d.getVar('pkg_postinst_%s' % pkg, True)
if not postinst:
postinst = '#!/bin/sh\n'
- postinst += localdata.getVar('updatercd_postinst', True)
+ postinst = postinst.splitlines(True)
+ try:
+ index = postinst.index('# End section update-alternatives\n')
+ postinst.insert(index + 1, localdata.getVar('updatercd_postinst', True))
+ except ValueError:
+ postinst.append(localdata.getVar('updatercd_postinst', True))
+ postinst = ''.join(postinst)
d.setVar('pkg_postinst_%s' % pkg, postinst)
prerm = d.getVar('pkg_prerm_%s' % pkg, True)
if not prerm:
prerm = '#!/bin/sh\n'
- prerm += localdata.getVar('updatercd_prerm', True)
+ prerm = prerm.splitlines(True)
+ try:
+ index = prerm.index('# Begin section update-alternatives\n')
+ prerm.insert(index, localdata.getVar('updatercd_prerm', True))
+ except ValueError:
+ prerm.append(localdata.getVar('updatercd_prerm', True))
+ prerm = ''.join(prerm)
d.setVar('pkg_prerm_%s' % pkg, prerm)
postrm = d.getVar('pkg_postrm_%s' % pkg, True)
--
2.10.2
^ permalink raw reply related
* Re: [PATCH 2/2] base-passwd: set root's default password to 'root'
From: Robert Yang @ 2016-11-24 8:27 UTC (permalink / raw)
To: Patrick Ohly; +Cc: Paul Eggleton, openembedded-core
In-Reply-To: <1479973589.6873.15.camel@intel.com>
On 11/24/2016 03:46 PM, Patrick Ohly wrote:
> On Thu, 2016-11-24 at 11:38 +0800, Robert Yang wrote:
>> Currently, debug-tweaks is in EXTRA_IMAGE_FEATURES by default for poky, and
>> there is no passwd, so that user can login easily without a passwd, I think
>> that current status is more unsafe ?
>
> Both well-known password and no password are unsafe. User "root" with
> password "root" is not even "more" safe already now, because tools that
> brute-force logins try that. Choosing something else would be a bit
> safer for a short while until the tools add it to their dictionary.
I meant add an interface to let user can set their password here.
// Robert
>
> Poky is also targeting a different audience than OE-core. Poky can
> assume to be used in a secure environment, OE-core can't (because it
> might be used for all kinds of devices).
>
^ permalink raw reply
* [PATCH v2] classes: Fix alternatives and rc.d ordering
From: David Vincent @ 2016-11-24 8:24 UTC (permalink / raw)
To: openembedded-core; +Cc: haris.okanovic
When using an alternative as an initscript, the ordering between
update-rc.d and update-alternatives tasks during prerm and postinst
tasks must always be the following in order to work:
* prerm:
- stop daemon
- remove alternative
* postinst:
- add alternative
- start daemon
This patchset adds comments to the scripts generated by both classes and
organize the generated sections based on those comments.
[YOCTO #10433]
Signed-off-by: David Vincent <freesilicon@gmail.com>
---
meta/classes/update-alternatives.bbclass | 27 +++++++++++++++++++++------
meta/classes/update-rc.d.bbclass | 20 ++++++++++++++++++--
2 files changed, 39 insertions(+), 8 deletions(-)
diff --git a/meta/classes/update-alternatives.bbclass
b/meta/classes/update-alternatives.bbclass
index 1fdd681..bbd5a47 100644
--- a/meta/classes/update-alternatives.bbclass
+++ b/meta/classes/update-alternatives.bbclass
@@ -195,8 +195,8 @@ python populate_packages_updatealternatives () {
pkgdest = d.getVar('PKGD', True)
for pkg in (d.getVar('PACKAGES', True) or "").split():
# Create post install/removal scripts
- alt_setup_links = ""
- alt_remove_links = ""
+ alt_setup_links = "# Begin section update-alternatives\n"
+ alt_remove_links = "# Begin section update-alternatives\n"
for alt_name in (d.getVar('ALTERNATIVE_%s' % pkg, True) or "").split():
alt_link = d.getVarFlag('ALTERNATIVE_LINK_NAME',
alt_name, True)
alt_target = d.getVarFlag('ALTERNATIVE_TARGET_%s' %
pkg, alt_name, True) or d.getVarFlag('ALTERNATIVE_TARGET', alt_name,
True)
@@ -219,8 +219,11 @@ python populate_packages_updatealternatives () {
# Default to generate shell script.. eventually we may
want to change this...
alt_target = os.path.normpath(alt_target)
- alt_setup_links += '\tupdate-alternatives --install %s
%s %s %s\n' % (alt_link, alt_name, alt_target, alt_priority)
- alt_remove_links += '\tupdate-alternatives --remove %s
%s\n' % (alt_name, alt_target)
+ alt_setup_links += 'update-alternatives --install %s %s
%s %s\n' % (alt_link, alt_name, alt_target, alt_priority)
+ alt_remove_links += 'update-alternatives --remove %s
%s\n' % (alt_name, alt_target)
+
+ alt_setup_links += "# End section update-alternatives\n"
+ alt_remove_links += "# End section update-alternatives\n"
if alt_setup_links:
# RDEPENDS setup
@@ -232,12 +235,24 @@ python populate_packages_updatealternatives () {
bb.note('adding update-alternatives calls to
postinst/prerm for %s' % pkg)
bb.note('%s' % alt_setup_links)
postinst = d.getVar('pkg_postinst_%s' % pkg, True) or '#!/bin/sh\n'
- postinst += alt_setup_links
+ postinst = postinst.splitlines(True)
+ try:
+ index = postinst.index('# Begin section update-rc.d\n')
+ postinst.insert(index, alt_setup_links)
+ except ValueError:
+ postinst.append(alt_setup_links)
+ postinst = ''.join(postinst)
d.setVar('pkg_postinst_%s' % pkg, postinst)
bb.note('%s' % alt_remove_links)
prerm = d.getVar('pkg_prerm_%s' % pkg, True) or '#!/bin/sh\n'
- prerm += alt_remove_links
+ prerm = prerm.splitlines(True)
+ try:
+ index = prerm.index('# End section update-rc.d\n')
+ prerm.insert(index + 1, alt_remove_links)
+ except ValueError:
+ prerm.append(alt_remove_links)
+ prerm = ''.join(prerm)
d.setVar('pkg_prerm_%s' % pkg, prerm)
}
diff --git a/meta/classes/update-rc.d.bbclass b/meta/classes/update-rc.d.bbclass
index 321924b..18df2dc 100644
--- a/meta/classes/update-rc.d.bbclass
+++ b/meta/classes/update-rc.d.bbclass
@@ -26,6 +26,7 @@ fi
}
updatercd_postinst() {
+# Begin section update-rc.d
if type update-rc.d >/dev/null 2>/dev/null; then
if [ -n "$D" ]; then
OPT="-r $D"
@@ -34,12 +35,15 @@ if type update-rc.d >/dev/null 2>/dev/null; then
fi
update-rc.d $OPT ${INITSCRIPT_NAME} ${INITSCRIPT_PARAMS}
fi
+# End section update-rc.d
}
updatercd_prerm() {
+# Begin section update-rc.d
if [ -z "$D" -a -x "${INIT_D_DIR}/${INITSCRIPT_NAME}" ]; then
${INIT_D_DIR}/${INITSCRIPT_NAME} stop || :
fi
+# End section update-rc.d
}
updatercd_postrm() {
@@ -102,13 +106,25 @@ python populate_packages_updatercd () {
postinst = d.getVar('pkg_postinst_%s' % pkg, True)
if not postinst:
postinst = '#!/bin/sh\n'
- postinst += localdata.getVar('updatercd_postinst', True)
+ postinst = postinst.splitlines(True)
+ try:
+ index = postinst.index('# End section update-alternatives\n')
+ postinst.insert(index + 1,
localdata.getVar('updatercd_postinst', True))
+ except ValueError:
+ postinst.append(localdata.getVar('updatercd_postinst', True))
+ postinst = ''.join(postinst)
d.setVar('pkg_postinst_%s' % pkg, postinst)
prerm = d.getVar('pkg_prerm_%s' % pkg, True)
if not prerm:
prerm = '#!/bin/sh\n'
- prerm += localdata.getVar('updatercd_prerm', True)
+ prerm = prerm.splitlines(True)
+ try:
+ index = prerm.index('# Begin section update-alternatives\n')
+ prerm.insert(index, localdata.getVar('updatercd_prerm', True))
+ except ValueError:
+ prerm.append(localdata.getVar('updatercd_prerm', True))
+ prerm = ''.join(prerm)
d.setVar('pkg_prerm_%s' % pkg, prerm)
postrm = d.getVar('pkg_postrm_%s' % pkg, True)
--
2.10.2
^ permalink raw reply related
* Re: [PATCH 2/2] base-passwd: set root's default password to 'root'
From: Patrick Ohly @ 2016-11-24 7:46 UTC (permalink / raw)
To: Robert Yang; +Cc: Paul Eggleton, openembedded-core
In-Reply-To: <27dbd493-5b76-657f-8a1d-57eabe9eebed@windriver.com>
On Thu, 2016-11-24 at 11:38 +0800, Robert Yang wrote:
> Currently, debug-tweaks is in EXTRA_IMAGE_FEATURES by default for poky, and
> there is no passwd, so that user can login easily without a passwd, I think
> that current status is more unsafe ?
Both well-known password and no password are unsafe. User "root" with
password "root" is not even "more" safe already now, because tools that
brute-force logins try that. Choosing something else would be a bit
safer for a short while until the tools add it to their dictionary.
Poky is also targeting a different audience than OE-core. Poky can
assume to be used in a secure environment, OE-core can't (because it
might be used for all kinds of devices).
--
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.
^ permalink raw reply
* Re: Contents of non-rootfs partitions
From: Kristian Amlie @ 2016-11-24 7:38 UTC (permalink / raw)
To: Ulrich Ölmann, openembedded-core
In-Reply-To: <20161124061543.e2xpgh7zjir3oynk@pengutronix.de>
On 24/11/16 07:15, Ulrich Ölmann wrote:
> Hi,
>
> On Wed, Nov 23, 2016 at 04:56:56PM +0100, Patrick Ohly wrote:
>> On Wed, 2016-11-23 at 15:22 +0200, Ed Bartosh wrote:
>>> On Wed, Nov 23, 2016 at 02:08:28PM +0100, Kristian Amlie wrote:
>>>> On 23/11/16 13:08, Ed Bartosh wrote:
>>>>> On Tue, Nov 22, 2016 at 12:54:52PM +0100, Kristian Amlie wrote:
>>>>> [...]
>>>>> This can be done by extending existing rootfs plugin. It should be able
>>>>> to do 2 things:
>>>>>
>>>>> - populate content of one rootfs directory to the partition. We can
>>>>> extend syntax of --rootfs-dir parameter to specify optional directory path to use
>>>>>
>>>>> - exclude rootfs directories when populating partitions. I'd propose to
>>>>> introduce --exclude-dirs wks parser option to handle this.
>>>>>
>>>>> Example of wks file with proposed new options:
>>>>> part / --source rootfs --rootfs-dir=core-image-minimal --ondisk sda --fstype=ext4 --label root --align 1024 --exclude-dirs data --exclude-dirs home
>>>>> part /data --source rootfs --rootfs-dir=core-image-minimal:/home --ondisk sda --fstype=ext4 --label data --align 1024
>>>>> part /home --source rootfs --rootfs-dir=core-image-minimal:/data --ondisk sda --fstype=ext4 --label data --align 1024
>>>>>
>>>>> Does this make sense?
>>>>
>>>> Looks good. The only thing I would question is that, in the interest of
>>>> reducing redundancy, maybe we should omit --exclude-dirs and have wic
>>>> figure this out by combining all the entries, since "--exclude-dirs
>>>> <dir>" and the corresponding "part <dir>" will almost always come in
>>>> pairs. Possibly we could mark the "/" partition with one single
>>>> --no-overlapping-dirs to force wic to make this consideration. Or do you
>>>> think that's too magical?
>>>>
>>> Tt's quite implicit from my point of view. However, if people like it we
>>> can implement it this way.
>>
>> I prefer the explicit --exclude-dirs. It's less surprising and perhaps
>> there are usages for having the same content in different partitions
>> (redundancy, factory reset, etc.).
>>
>> Excluding only the directory content but not the actual directory is
>> indeed a good point. I'm a bit undecided. When excluding only the
>> directory content, there's no way of building a rootfs without that
>> mount point, if that's desired. OTOH, when excluding also the directory,
>> the data would have to be staged under a different path in the rootfs
>> and the mount point would have to be a separate, empty directory.
>>
>> I'm leaning towards excluding the directory content and keeping the
>> directory.
>
> what about having both possibilities by leaning against the syntax that rsync
> uses to specify if a whole source directory or only it's contents shall be
> synced to some destination site (see [1])?
>
> In analogy to this to exclude only the contents of the directory named 'data'
> you would use
>
> --exclude-dirs data/
>
> but to additionally exclude the dir itself as well it would read
>
> --exclude-dirs data
This is creative, but ultimately too unintuitive IMHO. Rsync is the only
tool which uses this syntax AFAIK, and it's a constant source of
confusion, especially when mixed with cp or similar commands.
There is some discussion in the ticket as well:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10712
--
Kristian
^ permalink raw reply
* Re: Contents of non-rootfs partitions
From: Patrick Ohly @ 2016-11-24 7:38 UTC (permalink / raw)
To: Ulrich Ölmann, Eduard Bartosh; +Cc: openembedded-core
In-Reply-To: <20161124061543.e2xpgh7zjir3oynk@pengutronix.de>
On Thu, 2016-11-24 at 07:15 +0100, Ulrich Ölmann wrote:
> On Wed, Nov 23, 2016 at 04:56:56PM +0100, Patrick Ohly wrote:
> > Excluding only the directory content but not the actual directory is
> > indeed a good point. I'm a bit undecided. When excluding only the
> > directory content, there's no way of building a rootfs without that
> > mount point, if that's desired. OTOH, when excluding also the directory,
> > the data would have to be staged under a different path in the rootfs
> > and the mount point would have to be a separate, empty directory.
> >
> > I'm leaning towards excluding the directory content and keeping the
> > directory.
>
> what about having both possibilities by leaning against the syntax that rsync
> uses to specify if a whole source directory or only it's contents shall be
> synced to some destination site (see [1])?
I like that idea.
--
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.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox