date:20151124

В письме от 24 ноября 2015 10:30:17 пользователь Lopez, Mariano написал:
> > That's the right solution, although to do it really right (at least IMO)
> > you need to implement the /usr merge [1] (and that's orthogonal to using
> > or not using systemd), which can also help you make your /usr read-only
> > (because that's just code and static data) with read-write / for user
> > data of various sorts.
> 
> To be honest I'm not familiar with /usr merge, I need to check on that
> to see if it is a good option with the current OE-core infrastructure.

It needs some patches for current OE, I hope I'll find some time to rebase the 
set I have for this (based on fido) and send it for discussion.

-- 
 http://roman.khimov.ru
mailto: ro...@khimov.ru
gpg --keyserver hkp://subkeys.pgp.net --recv-keys 0xE5E055C3
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe] RFC: Reference updater filesystem

2015-11-24 Thread Mark Hatle

On 11/24/15 12:05 PM, Roman Khimov wrote:
> В письме от 24 ноября 2015 07:47:38 пользователь Mark Hatle написал:
>> On 11/24/15 4:39 AM, Roman Khimov wrote:
>>> В письме от 23 ноября 2015 15:41:28 пользователь Mariano Lopez написал:
 1. Use a separate partition for the configuration.

a. The pro of this method is the partition is not touched during the

 update.

b. The con of this method is the configuration is not directly in

 rootfs (example: /etc).
>>>
>>> That's the right solution, although to do it really right (at least IMO)
>>> you need to implement the /usr merge [1] (and that's orthogonal to using
>>> or not using systemd), which can also help you make your /usr read-only
>>> (because that's just code and static data) with read-write / for user
>>> data of various sorts.
>>
>> Why does merging /usr have anything to do with this?  I've read the case for
>> merging /usr and / and still don't understand why it "helps".  The key is
>> that if you have separate partitions for /usr and /, then you need to
>> update both of them in sequence.  Merging these two just seems like a lazy
>> solution to people not wanting to deal with early boot being
>> self-contained.
> 
> It helps in that you can achieve a clear separation of your software and 
> users 
> data (whatever that is, even if that's just some configuration files) and 
> only 
> update your part (which is /usr).

This can easily be archived using different partitions like /opt as well.

>> So going back to image upgrade.  The key here is that you need a way to
>> update arbitrary images with arbitrary contents and a mechanisms that is
>> smart enough to generate the update (vs a full image flash) to conserve
>> bandwidth.
> 
> In my experience, size is almost not an issue these days, at least if we're 
> talking about something less than 100 MB, but updating the whole image is 
> more 
> reliable and easier to manage.
> 

Bandwidth is a big deal in areas that are not serviced by anything but very GPRS
or worse.  So 100 MB is even too big in some cases.  Cost is a factor as is
overall bandwidth.

Again, it depends on the product and what you are building if this matters.

The point is we don't want to make some assumptions that preclude alternative
implementations.

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

Re: [OE-core] [yocto] RFC: Reference updater filesystem




On 11/24/2015 12:06 AM, Anders Darander wrote:

* Mariano Lopez  [151123 22:41]:


There has been interest in an image based software updater in Yocto Project.

Ok. Sure, it might be nice with something that can be shared, instead
off everyone's building our own solutions.


The idea is to integrate one, not build one from the scratch.




The proposed solution for a image based updater is to use Stefano Babic's
software updater (http://sbabic.github.io/swupdate). This software do a
binary copy, so it is needed to have at least two partitions, these
partitions would be the rootfs and the maintenance partition. The rootfs
it's the main partition used to boot during the normal device operation, on
the other hand, the maintenance will be used to update the main partition.

I haven't checked the swupdate tool, though I'd suspect that it also
supports the alternating rootfs use case? (I.e. run system1 update
system2; reboot to system2. Next update is system1). This is a rather
common setup, not least when you need a remote upgrade facility.

Would your proposed inclusion to the Yocto Project support that case
too?


Yeah, it would be possible to have two "rootfs" and do the update and 
the just reboot one time.





To update the system, the user has to connect to device and boot in the
maintenance partition; once in the maintenance partition the software
updater will copy the new image in the rootfs partition. A final reboot into
the rootfs it is necessary to complete the upgrade.

Like said above, not all system can be reached manually (at least not in
cost efficient way). Sure, the mainenance partition scheme can be made
to work anyway...


I plan to release this in phases, in the first one it will be manually 
do the update. The idea is implement tools to automate the process of 
the update (where it can be automated).





As mentioned before the the software will copy an image to the partition, so
everything in that partition will be wiped out, including custom
configurations. To avoid the loss of configuration I explore three different
solutions:
1. Use a separate partition for the configuration.
   a. The pro of this method is the partition is not touched during the
update.
   b. The con of this method is the configuration is not directly in rootfs
(example: /etc).

I'd vote for that as well. Though, I only keep the re-writable
configurations here. The one that are constant between all systems are
shipped in /etc in the read-only-rootfs.


With the above information I'm proposing to use a separate partition for the
configuration; this is because is more reliable and doesn't require big
changes in the current architecture.
So, the idea is to have 4 partitions in the media:
1. boot. This is the usual boot partition
2. data. This will hold the configuration files. Not modified by updates.
3. maintenance. This partition will be used to update rootfs.
4. rootfs. Partition used for normal operation.

How flexible to you intend to make this system? Allow everything that
swupdate supports? Or a specific subset?


If you are referring to the filesystem creation I would say very 
flexible. It will be implemented using wic instead of a class, so just 
needs to change a file to suit your needs. If you refer to the swupdate 
features, I plan to have a generic use case; as an example I won't use 
the MTD capabilities of the software.




Cheers,
Anders



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

Re: [OE-core] [oe] RFC: Reference updater filesystem

В письме от 24 ноября 2015 12:27:30 пользователь Mark Hatle написал:
> On 11/24/15 12:05 PM, Roman Khimov wrote:
> > В письме от 24 ноября 2015 07:47:38 пользователь Mark Hatle написал:
> >> On 11/24/15 4:39 AM, Roman Khimov wrote:
> >>> В письме от 23 ноября 2015 15:41:28 пользователь Mariano Lopez написал:
>  1. Use a separate partition for the configuration.
>  
> a. The pro of this method is the partition is not touched during the
>  
>  update.
>  
> b. The con of this method is the configuration is not directly in
>  
>  rootfs (example: /etc).
> >>> 
> >>> That's the right solution, although to do it really right (at least IMO)
> >>> you need to implement the /usr merge [1] (and that's orthogonal to using
> >>> or not using systemd), which can also help you make your /usr read-only
> >>> (because that's just code and static data) with read-write / for user
> >>> data of various sorts.
> >> 
> >> Why does merging /usr have anything to do with this?  I've read the case
> >> for merging /usr and / and still don't understand why it "helps".  The
> >> key is that if you have separate partitions for /usr and /, then you
> >> need to update both of them in sequence.  Merging these two just seems
> >> like a lazy solution to people not wanting to deal with early boot being
> >> self-contained.
> > 
> > It helps in that you can achieve a clear separation of your software and
> > users data (whatever that is, even if that's just some configuration
> > files) and only update your part (which is /usr).
> 
> This can easily be archived using different partitions like /opt as well.

Usually it leads to more complicated partitioning and more complicated startup 
(as well as update) procedure. Of course it can vary from system to system, 
but in my experience /usr merge was exactly the thing needed to clearly 
separate and simplify things. One way or another you want to have your code 
and users data to be separated, /usr merge makes it quite simple.

> Bandwidth is a big deal in areas that are not serviced by anything but very
> GPRS or worse.  So 100 MB is even too big in some cases.  Cost is a factor
> as is overall bandwidth.
> 
> Again, it depends on the product and what you are building if this matters.
> 
> The point is we don't want to make some assumptions that preclude
> alternative implementations.

Sure.

-- 
 http://roman.khimov.ru
mailto: ro...@khimov.ru
gpg --keyserver hkp://subkeys.pgp.net --recv-keys 0xE5E055C3
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/1] python3: fix building nativesdk-python3

2015-11-24 Thread Alejandro Hernandez

When the class nativesdk.bbclass is inherited, it redefines TARGET_CC_ARCH,
in the case of python3, this enables debug, causing an error while linking,
since we dont enable debug during configure theres no declaration of some
functions, this patch makes sure we keep debug disabled, fixing the linking 
errors.

[YOCTO #8467]

Signed-off-by: Alejandro Hernandez 
---
 meta/recipes-devtools/python/python3_3.5.0.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/python/python3_3.5.0.bb 
b/meta/recipes-devtools/python/python3_3.5.0.bb
index 2b16cd2..42a87af 100644
--- a/meta/recipes-devtools/python/python3_3.5.0.bb
+++ b/meta/recipes-devtools/python/python3_3.5.0.bb
@@ -61,6 +61,7 @@ CACHED_CONFIGUREVARS = "ac_cv_have_chflags=no \
 TARGET_CC_ARCH_append_armv6 = " -D__SOFTFP__"
 TARGET_CC_ARCH_append_armv7a = " -D__SOFTFP__"
 TARGET_CC_ARCH += "-DNDEBUG -fno-inline"
+SDK_CC_ARCH += "-DNDEBUG -fno-inline"
 EXTRA_OEMAKE += "CROSS_COMPILE=yes"
 EXTRA_OECONF += 
"CROSSPYTHONPATH=${STAGING_LIBDIR_NATIVE}/python${PYTHON_MAJMIN}/lib-dynload/ 
--without-ensurepip"
 
-- 
1.8.4.5

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

Re: [OE-core] [yocto] [oe] RFC: Reference updater filesystem

On 11/24/2015 7:47 AM, Mark Hatle wrote:

On 11/24/15 4:39 AM, Roman Khimov wrote:

В письме от 23 ноября 2015 15:41:28 пользователь Mariano Lopez написал:

1. Use a separate partition for the configuration.
a. The pro of this method is the partition is not touched during the
update.
b. The con of this method is the configuration is not directly in
rootfs (example: /etc).

That's the right solution, although to do it really right (at least IMO) you
need to implement the /usr merge [1] (and that's orthogonal to using or not
using systemd), which can also help you make your /usr read-only (because
that's just code and static data) with read-write / for user data of various
sorts.

Why does merging /usr have anything to do with this? I've read the case for
merging /usr and / and still don't understand why it "helps". The key is that
if you have separate partitions for /usr and /, then you need to update both of
them in sequence. Merging these two just seems like a lazy solution to people
not wanting to deal with early boot being self-contained.

Also having a separate / from /usr can help with '/' be your maintenance
partition in some cases.

3. Have an OverlayFS for the rootfs or the partition that have the
configuration.
a. The pro is the configuration is "directly" in rootfs.
b. The con is there is need to provide a custom init to guarantee the
Overlay is mounted before the boot process.

And this is the approach I would recommend not doing. I've used UnionFS for
thing like that (overlaying whole root file system) some 6 years ago, it
sounded nice and it kinda worked, but it wasn't difficult to make it fail
(just a little playing with power), we've even seen failures on production
devices, like when you have whiteout file for directory already written, but
don't have new files in it yet and that can completely ruin the system.

Also, it usually works better when you don't have any changes in the lower
layer, but we're talking about updating it here, you can easily end up in a
situation where you have updated something in the rootfs but that was
overriden by upper layer and thus your user doesn't see any change.

When using overlayfs, I'd strongly recommend not doing it over the entire
rootfs. This is generally a bad idea for the reasons stated above.

However, overlaying a part of the rootfs often makes sense. /etc is a good
example. This way applications that want their configurations in /etc can still
have it that way -- and there is always a (hopefully) reasonable default
configuration, should the configuration 'partition' get corrupted. So worst
case the user can start over on configurations only.

Do you know a way to mount the overlay before all the services start? I
tried to do this, but the only reliable way to do it was using a custom
init, I couldn't accomplish this using systemd or sysvnit.

For applications and user data, these can and should be stored outside of the
main rootfs. The FHS/LSB recomment '/opt', but while it doesn't matter if it's
-actually- /opt, the concept itself is good.

So going back to image upgrade. The key here is that you need a way to update
arbitrary images with arbitrary contents and a mechanisms that is smart enough
to generate the update (vs a full image flash) to conserve bandwidth.

I was concerned about this too, not just bandwidth but resources in the
target. Unfortunately I couldn't find an option that is generic enough
to just provide the update. The idea is to integrate the tool into YP,
not to develop a new one. Some of the tools that I checked needed to use
btrfs partitions, need python in the target, or other constrains that
make the update system impossible for a lot of targets.

I still contend it's up to the device to be able to configure the system on how
to get the update and where to apply the update. The tooling (host and target)
should simply assist with this.

Delta updates need version information in order to know they're doing the right
sequence of updating.

Full updates don't, but should be sent in a format that limits "empty space",
effectively send them as sparse files.

On many devices you will need to flash as part of the download due to space
limitations.

The tool mentioned has this capability.

And you need the ability to flash multiple partitions.

maintenance
/
/usr
data

etc.. whatever it takes to either upgrade or restore the device.

Yes, that would be possible, the only limitation is that is not possible
to flash the partition that is being used.

--Mark

With the above information I'm proposing to use a separate partition for
the configuration; this is because is more reliable and doesn't require
big changes in the current architecture.

So, the idea is to have 4 partitions in the media:
1. boot. This is the usual boot partition
2. data. This will hold the configuration files. Not modified by updates.
3. maintenance. This partition will be used to update rootfs.
4. rootfs.

Re: [OE-core] [OE-Core][PATCH v2] LOCKED_KEEP is undefined, so the following error will be caught.

2015-11-24 Thread Burton, Ross

On 23 November 2015 at 02:38, Bian Naimeng  wrote:

>  /usr/lib/python2.7/site-packages/smart/transaction.py", line 1230, in run
>  locked[pkg] = (LOCKED_KEEP, None)
>
>  NameError: global name 'LOCKED_KEEP' is not defined
>
> Upstream-Status: Submitted [sm...@lists.labix.org]
>

The Upstream-Status tag should be in smart-define-LOCKED-KEEP.patch
alongside the Signed-off-by, not the commit message.  The intention is that
the patch contains who wrote it and whether it's a backport, not suitable
for upstream, and so on.

Also the commit message should be in the traditional git shortlog/longlog
form where the first line contains the recipe name and a brief summary,
something like "python-smartpm: fix runtime errors by defining LOCKED_KEEP".

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

Re: [OE-core] [PATCH 2/2] wic: Allow to use a custom config for bootloaders

2015-11-24 Thread Ed Bartosh

On Mon, Nov 23, 2015 at 04:13:15PM -0600, Mariano Lopez wrote:
> 
> 
> On 11/23/2015 11:37 AM, Ed Bartosh wrote:
> >Hi Mariano,
> >
> >Thank you for the patchset!
> >
> >Would it be better to put content of configuration file into .wks
> >instead of just referring to it?
> 
> If the configuration is simple I agree with you; however if the
> configuration have scripts I think it's better to have separated
> file. The file can growth and would be a real mess inside a wks
> file.
>
What bothers me here is that reference to the external entity (config file in 
this case) which
may or may not exist. This makes wic more fragile than it is now.

Can we put bootloader configs to some predefined place, e.g. to the same
directory where .wks is?

> >
> >It would be also nice to have this code covered by oe-selftest.
>
> Yes, I plan do  create a test and update the documentation once it
> is integrated in master.
>

I'd prefer to have tests in the same patchset with the code. It would
help to understand better how to handle external configs. Can you do
that?

Regards,
Ed

> >
> >On Wed, Nov 18, 2015 at 08:25:54AM +, mariano.lo...@linux.intel.com 
> >wrote:
> >>From: Mariano Lopez 
> >>
> >>This change will allow to use a user defined file as the
> >>configuration for the bootloaders (grub, gummiboot, syslinux).
> >>
> >>The config file is defined in the wks file with the "configfile"
> >>option in the bootloader line.
> >>
> >>[YOCTO #8003]
> >>
> >>Signed-off-by: Mariano Lopez 
> >>---
> >>  scripts/lib/wic/plugins/source/bootimg-efi.py| 66 
> >> 
> >>  scripts/lib/wic/plugins/source/bootimg-pcbios.py | 66 
> >> ++--
> >>  2 files changed, 83 insertions(+), 49 deletions(-)
> >>
> >>diff --git a/scripts/lib/wic/plugins/source/bootimg-efi.py 
> >>b/scripts/lib/wic/plugins/source/bootimg-efi.py
> >>index fa63c6a..8fc879e 100644
> >>--- a/scripts/lib/wic/plugins/source/bootimg-efi.py
> >>+++ b/scripts/lib/wic/plugins/source/bootimg-efi.py
> >>@@ -45,22 +45,33 @@ class BootimgEFIPlugin(SourcePlugin):
> >>  """
> >>  Create loader-specific (grub-efi) config
> >>  """
> >>-options = creator.ks.handler.bootloader.appendLine
> >>-
> >>-grubefi_conf = ""
> >>-grubefi_conf += "serial --unit=0 --speed=115200 --word=8 
> >>--parity=no --stop=1\n"
> >>-grubefi_conf += "default=boot\n"
> >>-timeout = kickstart.get_timeout(creator.ks)
> >>-if not timeout:
> >>-timeout = 0
> >>-grubefi_conf += "timeout=%s\n" % timeout
> >>-grubefi_conf += "menuentry 'boot'{\n"
> >>-
> >>-kernel = "/bzImage"
> >>-
> >>-grubefi_conf += "linux %s root=%s rootwait %s\n" \
> >>-% (kernel, creator.rootdev, options)
> >>-grubefi_conf += "}\n"
> >>+configfile = kickstart.get_bootloader_file(creator.ks)
> >>+
> >>+if configfile and os.path.exists(configfile):
> >>+# Use a custom configuration file for grub
> >>+msger.info("Using custom configuration file "
> >>+"%s for grub.cfg" % configfile)
> >>+user_conf = open(configfile, "r")
> >>+grubefi_conf = user_conf.read()
> >>+user_conf.close()
> >>+else:
> >>+# Create grub configuration using parameters from wks file
> >>+options = creator.ks.handler.bootloader.appendLine
> >>+
> >>+grubefi_conf = ""
> >>+grubefi_conf += "serial --unit=0 --speed=115200 --word=8 
> >>--parity=no --stop=1\n"
> >>+grubefi_conf += "default=boot\n"
> >>+timeout = kickstart.get_timeout(creator.ks)
> >>+if not timeout:
> >>+timeout = 0
> >>+grubefi_conf += "timeout=%s\n" % timeout
> >>+grubefi_conf += "menuentry 'boot'{\n"
> >>+
> >>+kernel = "/bzImage"
> >>+
> >>+grubefi_conf += "linux %s root=%s rootwait %s\n" \
> >>+% (kernel, creator.rootdev, options)
> >>+grubefi_conf += "}\n"
> >>  msger.debug("Writing grubefi config 
> >> %s/hdd/boot/EFI/BOOT/grub.cfg" \
> >>  % cr_workdir)
> >>@@ -95,12 +106,23 @@ class BootimgEFIPlugin(SourcePlugin):
> >>  cfg.write(loader_conf)
> >>  cfg.close()
> >>-kernel = "/bzImage"
> >>-
> >>-boot_conf = ""
> >>-boot_conf += "title boot\n"
> >>-boot_conf += "linux %s\n" % kernel
> >>-boot_conf += "options LABEL=Boot root=%s %s\n" % (creator.rootdev, 
> >>options)
> >>+configfile = kickstart.get_bootloader_file(creator.ks)
> >>+
> >>+if configfile and os.path.exists(configfile):
> >>+# Use a custom configuration file for gummiboot
> >>+msger.info("Using custom configuration file "
> >>+"%s for gummiboot's boot.conf" % configfile)
> >>+

Re: [OE-core] [oe] RFC: Reference updater filesystem

On 11/24/2015 4:30 AM, Roman Khimov wrote:

В письме от 23 ноября 2015 15:41:28 пользователь Mariano Lopez написал:

To be honest I'm not familiar with /usr merge, I need to check on that
to see if it is a good option with the current OE-core infrastructure.

Thanks for sharing your experience, this is another big con for the
Overlay option.

With the above information I'm proposing to use a separate partition for
the configuration; this is because is more reliable and doesn't require
big changes in the current architecture.

You probably don't need to separate 1 and 3, all the code for system update
should easily fit into initramfs and just making /boot a bit larger would
allow you to store some backup rootfs.

I left the /boot partition separate just in case there is need to
replace the kernel or the bootloader. This way it would be easier to
change using the same method as the upgrading the rootfs.

Also, you can swap 4 and 2 which will be useful if you're installing on
different sized storage devices, usually you know good enough the size of your
rootfs, but you probably want to leave more space for user data if there is an
opportunity to do so, that's just easier to do with data partition at the end.

I was thinking in the same thinking just backwards, usually
configuration files are just small text files that don't require too
much space. If you require a new feature in the target that will make
rootfs to grow depending on the feature. I plan to use wic to accomplish
the filesystem structure. A good thing about wic is that it will be very
easy to do the swap, just need to modify two options in the .wks file.

[1] http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/

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

Re: [OE-core] [yocto] [oe] RFC: Reference updater filesystem

2015-11-24 Thread Mark Hatle

On 11/24/15 11:02 AM, Lopez, Mariano wrote:
> 
> 
> On 11/24/2015 7:47 AM, Mark Hatle wrote:
>> On 11/24/15 4:39 AM, Roman Khimov wrote:
>>> В письме от 23 ноября 2015 15:41:28 пользователь Mariano Lopez написал:
 1. Use a separate partition for the configuration.
 a. The pro of this method is the partition is not touched during the
 update.
 b. The con of this method is the configuration is not directly in
 rootfs (example: /etc).
>>> That's the right solution, although to do it really right (at least IMO) you
>>> need to implement the /usr merge [1] (and that's orthogonal to using or not
>>> using systemd), which can also help you make your /usr read-only (because
>>> that's just code and static data) with read-write / for user data of various
>>> sorts.
>> Why does merging /usr have anything to do with this?  I've read the case for
>> merging /usr and / and still don't understand why it "helps".  The key is 
>> that
>> if you have separate partitions for /usr and /, then you need to update both 
>> of
>> them in sequence.  Merging these two just seems like a lazy solution to 
>> people
>> not wanting to deal with early boot being self-contained.
>>
>> Also having a separate / from /usr can help with '/' be your maintenance
>> partition in some cases.
>>
 3. Have an OverlayFS for the rootfs or the partition that have the
 configuration.
 a. The pro is the configuration is  "directly" in rootfs.
 b. The con is there is need to provide a custom init to guarantee the
 Overlay is mounted before the boot process.
>>> And this is the approach I would recommend not doing. I've used UnionFS for
>>> thing like that (overlaying whole root file system) some 6 years ago, it
>>> sounded nice and it kinda worked, but it wasn't difficult to make it fail
>>> (just a little playing with power), we've even seen failures on production
>>> devices, like when you have whiteout file for directory already written, but
>>> don't have new files in it yet and that can completely ruin the system.
>>>
>>> Also, it usually works better when you don't have any changes in the lower
>>> layer, but we're talking about updating it here, you can easily end up in a
>>> situation where you have updated something in the rootfs but that was
>>> overriden by upper layer and thus your user doesn't see any change.
>> When using overlayfs, I'd strongly recommend not doing it over the entire
>> rootfs.  This is generally a bad idea for the reasons stated above.
>>
>> However, overlaying a part of the rootfs often makes sense.  /etc is a good
>> example.  This way applications that want their configurations in /etc can 
>> still
>> have it that way -- and there is always a (hopefully) reasonable default
>> configuration, should the configuration 'partition' get corrupted.  So worst
>> case the user can start over on configurations only.
> 
> Do you know a way to mount the overlay before all the services start? I 
> tried to do this, but the only reliable way to do it was using a custom 
> init, I couldn't accomplish this using systemd or sysvnit.

In the past I've done this with an initrd, with a custom /sbin/init that mounted
and then did a reexec for the real init system or ordered things in such a way
that the overlay happened -very- early.

>>
>> For applications and user data, these can and should be stored outside of the
>> main rootfs.  The FHS/LSB recomment '/opt', but while it doesn't matter if 
>> it's
>> -actually- /opt, the concept itself is good.
>>
>>
>> So going back to image upgrade.  The key here is that you need a way to 
>> update
>> arbitrary images with arbitrary contents and a mechanisms that is smart 
>> enough
>> to generate the update (vs a full image flash) to conserve bandwidth.
> 
> I was concerned about this too, not just bandwidth but resources in the 
> target. Unfortunately I couldn't find an option that is generic enough 
> to just provide the update. The idea is to integrate the tool into YP, 
> not to develop a new one. Some of the tools that I checked needed to use 
> btrfs partitions, need python in the target, or other constrains that 
> make the update system impossible for a lot of targets.

Yup.  I just want to make sure people know one tool isn't going to do
everything..  and the integration of a single tool shouldn't restrict people for
doing other things with custom tooling.

--Mark

>>
>> I still contend it's up to the device to be able to configure the system on 
>> how
>> to get the update and where to apply the update.  The tooling (host and 
>> target)
>> should simply assist with this.
>>
>> Delta updates need version information in order to know they're doing the 
>> right
>> sequence of updating.
>>
>> Full updates don't, but should be sent in a format that limits "empty space",
>> effectively send them as sparse files.
>>
>> On many devices you will need to flash as part of the download due to space
>> limitations.
> 
> The tool mentioned

Re: [OE-core] RFC: Reference updater filesystem


On 11/24/2015 1:32 AM, Randy Witt wrote:



On Mon, Nov 23, 2015 at 1:41 PM, Mariano Lopez 
> 
wrote:


There has been interest in an image based software updater in
Yocto Project. The proposed solution for a image based updater is
to use Stefano Babic's software updater
(http://sbabic.github.io/swupdate). This software do a binary
copy, so it is needed to have at least two partitions, these
partitions would be the rootfs and the maintenance partition. The
rootfs it's the main partition used to boot during the normal
device operation, on the other hand, the maintenance will be used
to update the main partition.

To update the system, the user has to connect to device and boot
in the maintenance partition; once in the maintenance partition
the software updater will copy the new image in the rootfs
partition. A final reboot into the rootfs it is necessary to
complete the upgrade.

As mentioned before the the software will copy an image to the
partition, so everything in that partition will be wiped out,
including custom configurations. To avoid the loss of
configuration I explore three different solutions:
1. Use a separate partition for the configuration.
  a. The pro of this method is the partition is not touched during
the update.
  b. The con of this method is the configuration is not directly
in rootfs (example: /etc).

Configuration files can be anywhere a package decides to install them. 
So having a single partition would be difficult. If you could, you 
would most likely be forced to have an initramfs to make sure /etc was 
mounted before init runs.


/etc was an example, the image should have the required files to make 
the target boot and the get the application configuration from this 
other partition. This is like openwrt does, it has a read-only rootfs 
and small read-write partition where the user can write its 
configuration and restore it at boot time.



2. Do the backup during the update.
  a. The pro is the configuration is directly in rootfs.
  b. The con is If the update fail most likely the configuration
would be lost.

Why would the configuration be lost if the update fails? Couldn't it 
just be stored on the thumbdrive?


If there is a power loss while the configuration is copied, the 
partition could go corrupt and would be difficult to recover. And as you 
mentioned  before the configuration files could be anywhere, so the 
script must be customized to get all those files and once the update is 
complete another script must restore those files, these could be 
cumbersome instead of the application have the config in another partition.



3. Have an OverlayFS for the rootfs or the partition that have the
configuration.
  a. The pro is the configuration is  "directly" in rootfs.
  b. The con is there is need to provide a custom init to
guarantee the Overlay is mounted before the boot process.

With the above information I'm proposing to use a separate
partition for the configuration; this is because is more reliable
and doesn't require big changes in the current architecture.

So, the idea is to have 4 partitions in the media:
1. boot. This is the usual boot partition
2. data. This will hold the configuration files. Not modified by
updates.
3. maintenance. This partition will be used to update rootfs.
4. rootfs. Partition used for normal operation.

Mariano
-- 
___

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] RFC: Reference updater filesystem

В письме от 24 ноября 2015 07:47:38 пользователь Mark Hatle написал:
> On 11/24/15 4:39 AM, Roman Khimov wrote:
> > В письме от 23 ноября 2015 15:41:28 пользователь Mariano Lopez написал:
> >> 1. Use a separate partition for the configuration.
> >> 
> >>a. The pro of this method is the partition is not touched during the
> >> 
> >> update.
> >> 
> >>b. The con of this method is the configuration is not directly in
> >> 
> >> rootfs (example: /etc).
> > 
> > That's the right solution, although to do it really right (at least IMO)
> > you need to implement the /usr merge [1] (and that's orthogonal to using
> > or not using systemd), which can also help you make your /usr read-only
> > (because that's just code and static data) with read-write / for user
> > data of various sorts.
> 
> Why does merging /usr have anything to do with this?  I've read the case for
> merging /usr and / and still don't understand why it "helps".  The key is
> that if you have separate partitions for /usr and /, then you need to
> update both of them in sequence.  Merging these two just seems like a lazy
> solution to people not wanting to deal with early boot being
> self-contained.

It helps in that you can achieve a clear separation of your software and users 
data (whatever that is, even if that's just some configuration files) and only 
update your part (which is /usr).

> So going back to image upgrade.  The key here is that you need a way to
> update arbitrary images with arbitrary contents and a mechanisms that is
> smart enough to generate the update (vs a full image flash) to conserve
> bandwidth.

In my experience, size is almost not an issue these days, at least if we're 
talking about something less than 100 MB, but updating the whole image is more 
reliable and easier to manage.

-- 
 http://roman.khimov.ru
mailto: ro...@khimov.ru
gpg --keyserver hkp://subkeys.pgp.net --recv-keys 0xE5E055C3
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V1] kernel-devsrc: add 'make scripts' postinstall

2015-11-24 Thread Bruce Ashfield


On 15-11-23 04:58 PM, Ming Liu wrote:

From: Ming Liu 

Run 'make scripts' inside qemu in order to create script binaries that
needed by external modules build on the target.

Add RDEPENDS on gcc, make, which are needed by the compilation.


This version looks fine to me .. and by "fine", I mean that it probably
is still less than ideal, but with our current packaging and separation
it makes sense to make it work, with all dependencies being explicit.

As we (re)slim down the devsrc/headers split, we can revisit this as
necessary.

One question below though ..



[YOCTO #6630]

Signed-off-by: Ming Liu 
---
  meta/recipes-kernel/linux/kernel-devsrc.bb | 14 --
  1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb 
b/meta/recipes-kernel/linux/kernel-devsrc.bb
index 196c8c7..87826ad 100644
--- a/meta/recipes-kernel/linux/kernel-devsrc.bb
+++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425
  inherit linux-kernel-base

  # Whilst not a module, this ensures we don't get multilib extended (which 
would make no sense)
-inherit module-base
+inherit module-base qemu


Shouldn't this be qemu-native ? Since it is running on the host ? Or
maybe I'm completely misunderstanding something :)

Bruce



  # We need the kernel to be staged (unpacked, patched and configured) before
  # we can grab the source and make the source package. We also need the bits 
from
@@ -71,6 +71,16 @@ do_install() {
  # Ensure we don't race against "make scripts" during cpio
  do_install[lockfiles] = "${TMPDIR}/kernel-scripts.lock"

+pkg_postinst_${PN} () {
+   if [ -n "$D" ]; then
+   ${@qemu_run_binary(d, '$D', '${bindir}/make')} \
+   -C $D${KERNEL_SRC_PATH} O=$D${KERNEL_SRC_PATH} scripts
+   else
+   make -C ${KERNEL_SRC_PATH} O=${KERNEL_SRC_PATH} scripts
+   fi
+}
+
  PACKAGES = "kernel-devsrc"
  FILES_${PN} = "${KERNEL_SRC_PATH}"
-RDEPENDS_${PN} = "bc"
+DEPENDS = "qemu-native"
+RDEPENDS_${PN} = "bc gcc make"



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

[OE-core] vmdk images with musl libc

2015-11-24 Thread Andre McCurdy

It's currently not possible to build a vmdk image when TCLIBC = "musl"
due to the following dependencies:

  do_bootdirectdisk -> syslinux -> mtools -> glibc-gconv-ibm850

Creating an mtools .bbappend containing:

  RDEPENDS_${PN}_libc-musl = ""
  RRECOMMENDS_${PN}_libc-musl = ""

seems to be a workaround.

Does anyone see a better solution?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [RFC] glibc kernel version

2015-11-24 Thread Jonathan David


The change below only replaces the kernel version checked by the shar
file, so that machines running on the 2.6 kernel can unpack an SDK
archive; however, the SDK will be unusable if the bundled glibc requires 
a later kernel than what is installed. glibc's minimal kernel version is 
determined by OLDEST_KERNEL, which from testing does not appear to be 
influenced by SDK_OLDEST_KERNEL.


For example, setting OLDEST_KERNEL=3.14 and SDK_OLDEST_KERNEL=2.6 still 
results in an unusable SDK on systems running [2.6, 3.14) kernels.


Is this a problem that many can expect to encounter, or is bumping the 
version of glibc beyond 2.6 uncommon?



commit: 522ba4c51fff53566678b2689d0d63c393e417b3
populate_sdk_base: Fix aarch64 OLDEST_KERNEL sdk issues

--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -81,6 +81,11 @@ python write_host_sdk_manifest () {
POPULATE_SDK_POST_TARGET_COMMAND_append = " write_target_sdk_manifest ; "
POPULATE_SDK_POST_HOST_COMMAND_append = " write_host_sdk_manifest; "

+# Some archs override this, we need the nativesdk version
+# turns out this is hard to get from the datastore due to
TRANSLATED_TARGET_ARCH
+# manipulation.
+SDK_OLDEST_KERNEL = "2.6.32"
+
fakeroot python do_populate_sdk() {
from oe.sdk import populate_sdk
from oe.manifest import create_manifest, Manifest
@@ -156,7 +161,7 @@ EOF
sed -i -e 's#@SDK_ARCH@#${SDK_ARCH}#g' \
-e 's#@SDKPATH@#${SDKPATH}#g' \
-e 's#@SDKEXTPATH@#${SDKEXTPATH}#g' \
- -e 's#@OLDEST_KERNEL@#${OLDEST_KERNEL}#g' \
+ -e 's#@OLDEST_KERNEL@#${SDK_OLDEST_KERNEL}#g' \
-e 's#@REAL_MULTIMACH_TARGET_SYS@#${REAL_MULTIMACH_TARGET_SYS}#g' \
-e 's#@SDK_TITLE@#${SDK_TITLE}#g' \
-e 's#@SDK_VERSION@#${SDK_VERSION}#g' \


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

Re: [OE-core] [RFC] glibc kernel version

2015-11-24 Thread Khem Raj


> On Nov 24, 2015, at 9:29 AM, Jonathan David  wrote:
> 
> The change below only replaces the kernel version checked by the shar
> file, so that machines running on the 2.6 kernel can unpack an SDK
> archive; however, the SDK will be unusable if the bundled glibc requires a 
> later kernel than what is installed. glibc's minimal kernel version is 
> determined by OLDEST_KERNEL, which from testing does not appear to be 
> influenced by SDK_OLDEST_KERNEL.
> 
> For example, setting OLDEST_KERNEL=3.14 and SDK_OLDEST_KERNEL=2.6 still 
> results in an unusable SDK on systems running [2.6, 3.14) kernels.
> 
> Is this a problem that many can expect to encounter, or is bumping the 
> version of glibc beyond 2.6 uncommon?

We need to compile nativesdk components as well as nativesdk-glibc using this 
defined to 2.6.32 as well. otherwise it will have wrong assumptions about
system calls available to it during build ( 3.14 ) vs at runtime ( 2.6.32 ) and 
many nativesdk programs could fail to run properly. Please note that 2.22 needs 
2.6.32
can’t go below that.

> 
> 
> commit: 522ba4c51fff53566678b2689d0d63c393e417b3
> populate_sdk_base: Fix aarch64 OLDEST_KERNEL sdk issues
> 
> --- a/meta/classes/populate_sdk_base.bbclass
> +++ b/meta/classes/populate_sdk_base.bbclass
> @@ -81,6 +81,11 @@ python write_host_sdk_manifest () {
> POPULATE_SDK_POST_TARGET_COMMAND_append = " write_target_sdk_manifest ; "
> POPULATE_SDK_POST_HOST_COMMAND_append = " write_host_sdk_manifest; "
> 
> +# Some archs override this, we need the nativesdk version
> +# turns out this is hard to get from the datastore due to
> TRANSLATED_TARGET_ARCH
> +# manipulation.
> +SDK_OLDEST_KERNEL = "2.6.32"
> +
> fakeroot python do_populate_sdk() {
> from oe.sdk import populate_sdk
> from oe.manifest import create_manifest, Manifest
> @@ -156,7 +161,7 @@ EOF
> sed -i -e 's#@SDK_ARCH@#${SDK_ARCH}#g' \
> -e 's#@SDKPATH@#${SDKPATH}#g' \
> -e 's#@SDKEXTPATH@#${SDKEXTPATH}#g' \
> - -e 's#@OLDEST_KERNEL@#${OLDEST_KERNEL}#g' \
> + -e 's#@OLDEST_KERNEL@#${SDK_OLDEST_KERNEL}#g' \
> -e 's#@REAL_MULTIMACH_TARGET_SYS@#${REAL_MULTIMACH_TARGET_SYS}#g' \
> -e 's#@SDK_TITLE@#${SDK_TITLE}#g' \
> -e 's#@SDK_VERSION@#${SDK_VERSION}#g' \
> 
> 
> --
> ___
> 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

[OE-core] [PATCH] psplash: update to latest git version

2015-11-24 Thread Juro Bystricky

Latest git version contains fix for big endian RGB888 rendering.

[YOCTO#7236]

Signed-off-by: Juro Bystricky 
---
 meta/recipes-core/psplash/psplash_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/psplash/psplash_git.bb 
b/meta/recipes-core/psplash/psplash_git.bb
index b3b6479..ccc4970 100644
--- a/meta/recipes-core/psplash/psplash_git.bb
+++ b/meta/recipes-core/psplash/psplash_git.bb
@@ -5,7 +5,7 @@ SECTION = "base"
 LICENSE = "GPLv2+"
 LIC_FILES_CHKSUM = 
"file://psplash.h;beginline=1;endline=16;md5=840fb2356b10a85bed78dd09dc7745c6"
 
-SRCREV = "14c8f7b705de944beb4de3f296506d80871e410f"
+SRCREV = "0c790befd0948a5ebfdad282105656e6b6891483"
 PV = "0.1+git${SRCPV}"
 PR = "r15"
 
-- 
1.9.1

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

[OE-core] [PATCH 0/2]: readline fixes

The following changes since commit 1b25a70991589ed1f123015c16ee4806c46e3199:

  yocto-project-qs, ref-manual, poky.ent: CentOS Package updates (2015-11-18 
16:42:22 +)

are available in the git repository at:

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

Petter Mabäcker (2):
  readline: prepare for readline6.3 upstream patches
  readline: apply missing upstream patches

 .../readline/{files => readline-6.3}/norpath.patch |  0
 .../readline-6.3/readline-cve-2014-2524.patch  | 43 --
 .../readline-6.3/readline-dispatch-multikey.patch  | 32 
 meta/recipes-core/readline/readline.inc|  5 +--
 meta/recipes-core/readline/readline_6.3.bb | 30 ++-
 5 files changed, 29 insertions(+), 81 deletions(-)
 rename meta/recipes-core/readline/{files => readline-6.3}/norpath.patch (100%)
 delete mode 100644 
meta/recipes-core/readline/readline-6.3/readline-cve-2014-2524.patch
 delete mode 100644 
meta/recipes-core/readline/readline-6.3/readline-dispatch-multikey.patch

-- 
1.9.1

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

[OE-core] [PATCH 2/2] readline: apply missing upstream patches

Some readline-6.3 upstream patches was missing. Also ensure that the
upstream patches are applied in the same way as in readline-5.2.

Remove 'readline-dispatch-multikey.patch' and
'readline-cve-2014-2524.patch' since they are already included in
upstream patches 'readline63-002' and 'readline63-003'.

[YOCTO #8451]

Signed-off-by: Petter Mabäcker 
---
 .../readline-6.3/readline-cve-2014-2524.patch  | 43 --
 .../readline-6.3/readline-dispatch-multikey.patch  | 32 
 meta/recipes-core/readline/readline_6.3.bb | 31 ++--
 3 files changed, 27 insertions(+), 79 deletions(-)
 delete mode 100644 
meta/recipes-core/readline/readline-6.3/readline-cve-2014-2524.patch
 delete mode 100644 
meta/recipes-core/readline/readline-6.3/readline-dispatch-multikey.patch

diff --git 
a/meta/recipes-core/readline/readline-6.3/readline-cve-2014-2524.patch 
b/meta/recipes-core/readline/readline-6.3/readline-cve-2014-2524.patch
deleted file mode 100644
index 98a9d81..000
--- a/meta/recipes-core/readline/readline-6.3/readline-cve-2014-2524.patch
+++ /dev/null
@@ -1,43 +0,0 @@
-readline: Security Advisory - readline - CVE-2014-2524
-
-Upstream-Status: Backport
-
-Signed-off-by: Yue Tao 
-
-  READLINE PATCH REPORT
-  =
-
-Readline-Release: 6.3
-Patch-ID: readline63-003
-
-Bug-Reported-by:
-Bug-Reference-ID:
-Bug-Reference-URL:
-
-Bug-Description:
-
-There are debugging functions in the readline release that are theoretically
-exploitable as security problems.  They are not public functions, but have
-global linkage.
-
-Patch (apply with `patch -p0'):
-
-*** ../readline-6.3/util.c 2013-09-02 13:36:12.0 -0400
 util.c 2014-03-20 10:25:53.0 -0400
-***
-*** 477,480 
 479,483 
-  }
-  
-+ #if defined (DEBUG)
-  #if defined (USE_VARARGS)
-  static FILE *_rl_tracefp;
-***
-*** 539,542 
 542,546 
-  }
-  #endif
-+ #endif /* DEBUG */
-  
-  
-
diff --git 
a/meta/recipes-core/readline/readline-6.3/readline-dispatch-multikey.patch 
b/meta/recipes-core/readline/readline-6.3/readline-dispatch-multikey.patch
deleted file mode 100644
index 54d1ac6..000
--- a/meta/recipes-core/readline/readline-6.3/readline-dispatch-multikey.patch
+++ /dev/null
@@ -1,32 +0,0 @@
-From 8ef852a5be72c75e17f2510bea52455f809b56ce Mon Sep 17 00:00:00 2001
-From: Chet Ramey 
-Date: Fri, 28 Mar 2014 14:07:42 -0400
-Subject: [PATCH 04/10] Readline-6.3 patch 2
-
-Fixes multi-key issue identified in this thread:
-http://lists.gnu.org/archive/html/bug-readline/2014-03/msg00010.html
-
-Upstream-Status: Backport
-
-Signed-off-by: Saul Wold 

- readline.c | 3 ++-
- 1 files changed, 2 insertions(+), 1 deletions(-)
-
-diff --git a/readline.c b/readline.c
-index eb4eae3..abb29a0 100644
 a/readline.c
-+++ b/readline.c
-@@ -744,7 +744,8 @@ _rl_dispatch_callback (cxt)
- r = _rl_subseq_result (r, cxt->oldmap, cxt->okey, (cxt->flags & 
KSEQ_SUBSEQ));
- 
-   RL_CHECK_SIGNALS ();
--  if (r == 0) /* success! */
-+  /* We only treat values < 0 specially to simulate recursion. */
-+  if (r >= 0 || (r == -1 && (cxt->flags & KSEQ_SUBSEQ) == 0)) /* success! or 
failure! */
- {
-   _rl_keyseq_chain_dispose ();
-   RL_UNSETSTATE (RL_STATE_MULTIKEY);
--- 
-1.8.3.1
-
diff --git a/meta/recipes-core/readline/readline_6.3.bb 
b/meta/recipes-core/readline/readline_6.3.bb
index dbb9f0a..8ec7c4a 100644
--- a/meta/recipes-core/readline/readline_6.3.bb
+++ b/meta/recipes-core/readline/readline_6.3.bb
@@ -1,11 +1,34 @@
 require readline.inc
 
-SRC_URI += "file://configure-fix.patch \
+SRC_URI += 
"${GNU_MIRROR}/readline/readline-6.3-patches/readline63-001;name=patch1;apply=yes;striplevel=0
 \
+
${GNU_MIRROR}/readline/readline-6.3-patches/readline63-002;name=patch2;apply=yes;striplevel=0
 \
+
${GNU_MIRROR}/readline/readline-6.3-patches/readline63-003;name=patch3;apply=yes;striplevel=0
 \
+
${GNU_MIRROR}/readline/readline-6.3-patches/readline63-004;name=patch4;apply=yes;striplevel=0
 \
+
${GNU_MIRROR}/readline/readline-6.3-patches/readline63-005;name=patch5;apply=yes;striplevel=0
 \
+
${GNU_MIRROR}/readline/readline-6.3-patches/readline63-006;name=patch6;apply=yes;striplevel=0
 \
+
${GNU_MIRROR}/readline/readline-6.3-patches/readline63-007;name=patch7;apply=yes;striplevel=0
 \
+
${GNU_MIRROR}/readline/readline-6.3-patches/readline63-008;name=patch8;apply=yes;striplevel=0
 \
+file://configure-fix.patch \
 file://config-dirent-symbols.patch \
-file://norpath.patch \
-file://readline-cve-2014-2524.patch;striplevel=0 \
-file://readline-dispatch-multikey.patch"
+file://norpath.patch"
 
 SRC_URI[archive.md5sum] =

Re: [OE-core] [PATCH 0/2]: readline fixes

 

Hi all, 

I can see that I missed the [OE-core] tag in this
patch-serie... Please ignore this patchset and I will send up a proper
one shortly. 

BR Petter 

Petter Mabäcker

Technux

www.technux.se

2015-11-24 10:50 skrev Petter
Mabäcker: 

> The following changes since commit
1b25a70991589ed1f123015c16ee4806c46e3199:
> 
> yocto-project-qs,
ref-manual, poky.ent: CentOS Package updates (2015-11-18 16:42:22
+)
> 
> are available in the git repository at:
> 
>
git://git.yoctoproject.org/poky-contrib petmab/bug8451
>
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=petmab/bug8451
[1]
> 
> Petter Mabäcker (2):
> readline: prepare for readline6.3
upstream patches
> readline: apply missing upstream patches
> 
>
.../readline/{files => readline-6.3}/norpath.patch | 0
>
.../readline-6.3/readline-cve-2014-2524.patch | 43
--
>
.../readline-6.3/readline-dispatch-multikey.patch | 32

> meta/recipes-core/readline/readline.inc | 5 +--
>
meta/recipes-core/readline/readline_6.3.bb | 30 ++-
> 5
files changed, 29 insertions(+), 81 deletions(-)
> rename
meta/recipes-core/readline/{files => readline-6.3}/norpath.patch
(100%)
> delete mode 100644
meta/recipes-core/readline/readline-6.3/readline-cve-2014-2524.patch
>
delete mode 100644
meta/recipes-core/readline/readline-6.3/readline-dispatch-multikey.patch



Links:
--
[1]
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=petmab/bug8451
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 5/5] useradd-staticids.bbclass: Read passwd/group files before parsing

2015-11-24 Thread Peter Kjellerstedt

*ping*

//Peter

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Peter Kjellerstedt
> Sent: den 13 november 2015 13:52
> To: Mark Hatle
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 5/5] useradd-staticids.bbclass: Read
> passwd/group files before parsing
> 
> > -Original Message-
> > From: openembedded-core-boun...@lists.openembedded.org
> > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
> Of
> > Mark Hatle
> > Sent: den 10 november 2015 17:07
> > To: Peter Kjellerstedt
> > Cc: openembedded-core@lists.openembedded.org
> > Subject: Re: [OE-core] [PATCH 5/5] useradd-staticids.bbclass: Read
> > passwd/group files before parsing
> >
> > On 11/10/15 9:54 AM, Peter Kjellerstedt wrote:
> > >> -Original Message-
> > >> From: Mark Hatle [mailto:mark.ha...@windriver.com]
> > >> Sent: den 6 november 2015 21:14
> > >> To: Peter Kjellerstedt
> > >> Cc: openembedded-core@lists.openembedded.org
> > >> Subject: Re: [PATCH 5/5] useradd-staticids.bbclass: Read
> > >> passwd/group files before parsing
> > >>
> > >> On 11/6/15 2:09 PM, Peter Kjellerstedt wrote:
> >  -Original Message-
> >  From: Mark Hatle [mailto:mark.ha...@windriver.com]
> >  Sent: den 4 november 2015 01:33
> >  To: Peter Kjellerstedt; openembedded-core@lists.openembedded.org
> >  Subject: Re: [PATCH 5/5] useradd-staticids.bbclass: Read
> >  passwd/group files before parsing
> > 
> >  On 11/3/15 6:06 PM, Peter Kjellerstedt wrote:
> > > Read and merge the passwd/group files before parsing the user
> and
> > > group definitions. This means they will only be read once per
> > > recipe. This solves a problem where if a user was definied in
> > > multiple files, it could generate group definitions for groups
> > > that should not be created. E.g., if the first passwd file read
> > > defines a user as:
> > >
> > > foobar::1234
> > >
> > > and the second passwd file defines it as:
> > >
> > > foobar:::nogroup:The foobar user:/:/bin/sh
> > >
> > > then a foobar group would be created even if the user will use
> > > the nogroup as its primary group.
> > 
> >  One minor thing
> > 
> > > @@ -251,7 +269,7 @@ def update_useradd_static_config(d):
> > >
> > >  newparams.append(newparam)
> > >
> > > -return " ;".join(newparams).strip()
> > > +return ";".join(newparams).strip()
> > >
> > >  # Load and process the users and groups, rewriting the
> adduser/addgroup params
> > >  useradd_packages = d.getVar('USERADD_PACKAGES', True)
> > >
> > 
> >  The space was required because you could generate a user/group
> >  add line that ended with a string.  Without the space, you could
> >  end up merging two sets of arguments causing a failure
> condition.
> > 
> >  So I think that it should be retained unless there is a specific
> >  reason you believe it should be removed.
> > >>>
> > >>> I cannot see how that space can make any difference. Each set of
> > >>> useradd/grouppadd options added to newparams has the user/group
> > >>> name at the end of the string. And if that somehow interferes
> with
> > >>> the semicolon, then the code in useradd.bbclass which simply does
> > >>> "cut -d ';'" to split the useradd/groupadd line would break
> > >>> already.
> > >>
> > >> The contents when originally parsed my be run as arguments to a
> > >> shell script or as parameters to these functions.
> > >>
> > >> In the shell script world not have a space can confuse the
> argument
> > >> parsing into thinking the ; is part of the argument.
> > >
> > > No shell I have heard of (bash, zsh and dash comes to mind) would
> be
> > > affected by the lack of a space before the semicolon. Moreover,
> this
> > > is never actually parsed by a shell (except as part of a variable
> > > value). The semicolon is used by useradd.bbclass to split the
> > > variables, after which it lets the shell evaluate the part before
> > > the semicolon (which will ignore any trailing whitespace).
> >
> > I've seen broken shells in the past where you would do something
> like:
> >
> > /bin/echo foo;/bin/echo bar
> >
> > and get:  "/bin echo foo;/bin/echo bar" since it treated the middle
> > item as a single command.  I'm not saying it wasn't a bug in the
> shell
> > or system -- just that I've been burned by it in the past and because
> > of this, I try not to rely on it.. (when adding a space solves the
> issue.)
> 
> Ok, sounds weird, but I will take your word for it.
> 
> > >> You don't have that in the python world with the split behavior.
> > >>
> > >>> Actually, now that I think about it, I do wonder why
> > >>> useradd-staticids.bbclass use this advanced variant to split the
> > >>> useradd/groupadd lines:
> > >>>
> >

[OE-core] [PATCH 1/2] readline: prepare for readline6.3 upstream patches

Upstream patches are always preferred to be applied first (before
integration patches). In order to apply readline-6.3 specific upstream
patches in a preferred order we need to apply the integration-patches
at the end in the 6.3 specific recipe (this is already the case
for readline-5.2).

Also take the oppertunity to move 'norpath.patch' to readline-6.3 dir
since this patch is not shared between the 5.2 and 6.3 recipe.

[YOCTO #8451]

Signed-off-by: Petter Mabäcker 
---
 meta/recipes-core/readline/{files => readline-6.3}/norpath.patch | 0
 meta/recipes-core/readline/readline.inc  | 5 +
 meta/recipes-core/readline/readline_6.3.bb   | 5 -
 3 files changed, 5 insertions(+), 5 deletions(-)
 rename meta/recipes-core/readline/{files => readline-6.3}/norpath.patch (100%)

diff --git a/meta/recipes-core/readline/files/norpath.patch 
b/meta/recipes-core/readline/readline-6.3/norpath.patch
similarity index 100%
rename from meta/recipes-core/readline/files/norpath.patch
rename to meta/recipes-core/readline/readline-6.3/norpath.patch
diff --git a/meta/recipes-core/readline/readline.inc 
b/meta/recipes-core/readline/readline.inc
index 3f662c3..30892e1 100644
--- a/meta/recipes-core/readline/readline.inc
+++ b/meta/recipes-core/readline/readline.inc
@@ -11,10 +11,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
 
 DEPENDS += "ncurses"
 
-SRC_URI = "${GNU_MIRROR}/readline/${BPN}-${PV}.tar.gz;name=archive \
-   file://configure-fix.patch \
-   file://config-dirent-symbols.patch \
-   file://norpath.patch"
+SRC_URI = "${GNU_MIRROR}/readline/${BPN}-${PV}.tar.gz;name=archive"
 
 inherit autotools texinfo
 
diff --git a/meta/recipes-core/readline/readline_6.3.bb 
b/meta/recipes-core/readline/readline_6.3.bb
index fc362ae..dbb9f0a 100644
--- a/meta/recipes-core/readline/readline_6.3.bb
+++ b/meta/recipes-core/readline/readline_6.3.bb
@@ -1,6 +1,9 @@
 require readline.inc
 
-SRC_URI += "file://readline-cve-2014-2524.patch;striplevel=0 \
+SRC_URI += "file://configure-fix.patch \
+file://config-dirent-symbols.patch \
+file://norpath.patch \
+file://readline-cve-2014-2524.patch;striplevel=0 \
 file://readline-dispatch-multikey.patch"
 
 SRC_URI[archive.md5sum] = "33c8fb279e981274f485fd91da77e94a"
-- 
1.9.1

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

Re: [OE-core] [PATCH 0/2]: readline fixes

 

Hi again 

It seems it was the cc mail send-pull-request sent me
that fooled me (the tag was missing there)... But everyrhing seems to be
in order so plz go ahead and review this serie after all =) 

Sorry for
the confusion.. 

Petter Mabäcker

Technux

www.technux.se

2015-11-24 11:00 skrev Petter
Mabäcker: 

> Hi all, 
> 
> I can see that I missed the [OE-core] tag in
this patch-serie... Please ignore this patchset and I will send up a
proper one shortly. 
> 
> BR Petter 
> 
> Petter Mabäcker
> 
> Technux

> www.technux.se
> 
> 2015-11-24 10:50 skrev Petter
Mabäcker: 
> 
>> The following changes since commit
1b25a70991589ed1f123015c16ee4806c46e3199:
>> 
>> yocto-project-qs,
ref-manual, poky.ent: CentOS Package updates (2015-11-18 16:42:22
+)
>> 
>> are available in the git repository at:
>> 
>>
git://git.yoctoproject.org/poky-contrib petmab/bug8451
>>
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=petmab/bug8451
[1]
>> 
>> Petter Mabäcker (2):
>> readline: prepare for readline6.3
upstream patches
>> readline: apply missing upstream patches
>> 
>>
.../readline/{files => readline-6.3}/norpath.patch | 0
>>
.../readline-6.3/readline-cve-2014-2524.patch | 43
--
>>
.../readline-6.3/readline-dispatch-multikey.patch | 32

>> meta/recipes-core/readline/readline.inc | 5 +--
>>
meta/recipes-core/readline/readline_6.3.bb | 30 ++-
>> 5
files changed, 29 insertions(+), 81 deletions(-)
>> rename
meta/recipes-core/readline/{files => readline-6.3}/norpath.patch
(100%)
>> delete mode 100644
meta/recipes-core/readline/readline-6.3/readline-cve-2014-2524.patch
>>
delete mode 100644
meta/recipes-core/readline/readline-6.3/readline-dispatch-multikey.patch



Links:
--
[1]
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=petmab/bug8451
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe] RFC: Reference updater filesystem

В письме от 23 ноября 2015 15:41:28 пользователь Mariano Lopez написал:
> 1. Use a separate partition for the configuration.
>a. The pro of this method is the partition is not touched during the
> update.
>b. The con of this method is the configuration is not directly in
> rootfs (example: /etc).

That's the right solution, although to do it really right (at least IMO) you 
need to implement the /usr merge [1] (and that's orthogonal to using or not 
using systemd), which can also help you make your /usr read-only (because 
that's just code and static data) with read-write / for user data of various 
sorts.

> 3. Have an OverlayFS for the rootfs or the partition that have the
> configuration.
>a. The pro is the configuration is  "directly" in rootfs.
>b. The con is there is need to provide a custom init to guarantee the
> Overlay is mounted before the boot process.

And this is the approach I would recommend not doing. I've used UnionFS for 
thing like that (overlaying whole root file system) some 6 years ago, it 
sounded nice and it kinda worked, but it wasn't difficult to make it fail 
(just a little playing with power), we've even seen failures on production 
devices, like when you have whiteout file for directory already written, but 
don't have new files in it yet and that can completely ruin the system.

Also, it usually works better when you don't have any changes in the lower 
layer, but we're talking about updating it here, you can easily end up in a 
situation where you have updated something in the rootfs but that was 
overriden by upper layer and thus your user doesn't see any change.

> With the above information I'm proposing to use a separate partition for
> the configuration; this is because is more reliable and doesn't require
> big changes in the current architecture.
> 
> So, the idea is to have 4 partitions in the media:
> 1. boot. This is the usual boot partition
> 2. data. This will hold the configuration files. Not modified by updates.
> 3. maintenance. This partition will be used to update rootfs.
> 4. rootfs. Partition used for normal operation.

You probably don't need to separate 1 and 3, all the code for system update 
should easily fit into initramfs and just making /boot a bit larger would 
allow you to store some backup rootfs.

Also, you can swap 4 and 2 which will be useful if you're installing on 
different sized storage devices, usually you know good enough the size of your 
rootfs, but you probably want to leave more space for user data if there is an 
opportunity to do so, that's just easier to do with data partition at the end.


[1] http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Jethro maintainer

2015-11-24 Thread Robert Yang




On 11/24/2015 10:22 PM, Richard Purdie wrote:

On Fri, 2015-11-06 at 13:27 +, Richard Purdie wrote:

We've going to need a new stable maintainer for the new release. There
have already been a  couple of offers, but to be fair to everyone I
thought I'd explicitly ask if there was anyone else interested?


I've had discussions with a few people, thanks for the various offers.

I'm going to select Robert Yang as the stable maintainer for Jethro, not
least as the stable release he has been looking after is effectively out
of maintenance now.


Thanks, it's my pleasure, work on oe-core makes a lot of fun.

// Robert



Thanks Robert!

Cheers,

Richard



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

Re: [OE-core] [PATCH 2/2] dbus: add user sessions support

2015-11-24 Thread Andrew Shadura

On 24/11/15 15:03, Burton, Ross wrote:
> On 20 November 2015 at 14:38, Andrew Shadura
>  wrote:
> 
>>Enable the user-sessions support with a PACKAGECONFIG flag.
> 
> What is the impact on this if someone is using systemd but doesn't want
> user sessions?  Should we enable it if the DISTRO_FEATURES contains
> systemd by default?

It is okay to use systemd and not use user sessions. Possibly, we want
to enable it by default in the future, but it should be okay to have it
disabled for now unless it's switched on from elsewhere.

-- 
Cheers,
  Andrew



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

Re: [OE-core] Jethro maintainer

2015-11-24 Thread Richard Purdie

On Fri, 2015-11-06 at 13:27 +, Richard Purdie wrote:
> We've going to need a new stable maintainer for the new release. There
> have already been a  couple of offers, but to be fair to everyone I
> thought I'd explicitly ask if there was anyone else interested?

I've had discussions with a few people, thanks for the various offers.

I'm going to select Robert Yang as the stable maintainer for Jethro, not
least as the stable release he has been looking after is effectively out
of maintenance now.

Thanks Robert!

Cheers,

Richard

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

Re: [OE-core] [PATCH v3 2/3] dbus: update the recipes to 1.10.2

2015-11-24 Thread Burton, Ross

On 20 November 2015 at 14:27, Andrew Shadura  wrote:

> --- a/meta/recipes-core/dbus/dbus-test_1.8.20.bb
> +++ b/meta/recipes-core/dbus/dbus-test_1.10.2.bb
> +SRC_URI[md5sum] = "9190f5c0e41e8d220352c058faf5463522378e35"
> +SRC_URI[sha256sum] =
> "aef3f49595df09b0824433ee993cda748ede93693a719a831562ae1616b6bb9e"
>
> --- a/meta/recipes-core/dbus/dbus_1.8.20.bb
> +++ b/meta/recipes-core/dbus/dbus_1.10.2.bb
> +SRC_URI[md5sum] = "2428919cc77b8d0028d65ee4d5dbef31"
> +SRC_URI[sha256sum] =
> "aef3f49595df09b0824433ee993cda748ede93693a719a831562ae1616b6bb9e"
>

One of those checksums was wrong, but I fixed it during testing.

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

[OE-core] [PATCH] qemu-native: link with system libdbus

2015-11-24 Thread Ed Bartosh

Build of qemu-native on recent versions of Ubuntu and Debian fails
on configure step. The reason for this is that system dbus version
is higher than oe dbus version and system pulseaudio libraries require
newer dbus.

It causes configure to break with a lot of errors similar to this:
  libpulsecommon-6.0.so: undefined reference to 
dbus_watch_get_enabled@LIBDBUS_1_3

Fixed by building qemu-native with the system libdbus.

This can help with similar issues on other distros when they start
using newer dbus.

[YOCTO #8553]

Signed-off-by: Ed Bartosh 
---
 meta/recipes-devtools/qemu/qemu.inc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index abbace8..7289fa2 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -40,6 +40,9 @@ do_configure_prepend_class-native() {
BHOST_PKGCONFIG_PATH=$(PATH=/usr/bin:/bin pkg-config --variable pc_path 
pkg-config || echo "")
if [ ! -z "$BHOST_PKGCONFIG_PATH" ]; then
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$BHOST_PKGCONFIG_PATH
+   # link with the system libdbus
+   libs=$(PKG_CONFIG_ALLOW_SYSTEM_LIBS=1 
PKG_CONFIG_PATH=$BHOST_PKGCONFIG_PATH PATH=/usr/bin:/bin pkg-config --libs 
dbus-1 || echo "")
+   [ -n "$libs" ] && export LDFLAGS="$libs $LDFLAGS"
fi
 }
 
-- 
2.1.4

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

[OE-core] [PATCH 0/1] create-pull-request: handle empty ODIR

The following changes since commit 1b25a70991589ed1f123015c16ee4806c46e3199:

  yocto-project-qs, ref-manual, poky.ent: CentOS Package updates (2015-11-18 
16:42:22 +)

are available in the git repository at:

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

Petter Mabäcker (1):
  create-pull-request: handle empty ODIR

 scripts/create-pull-request | 8 
 1 file changed, 8 insertions(+)

-- 
1.9.1

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

[OE-core] [PATCH 0/1] boot-directdisk.bbclass: remove HDDIMG before create

2015-11-24 Thread Robert Yang

The following changes since commit 6f98c39418c60b7c0b25b30983d2e5257158a6a4:

  gcc: Drop 4.8 (2015-11-16 14:59:07 +)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/hddimg
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/hddimg

Robert Yang (1):
  boot-directdisk.bbclass: remove HDDIMG before create

 meta/classes/boot-directdisk.bbclass |2 ++
 1 file changed, 2 insertions(+)

-- 
1.7.9.5

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

[OE-core] [PATCH 1/1] create-pull-request: handle empty ODIR