Refresh patches with devtool

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

Signed-off-by: Ross Burton <ross.burton@intel.com>

Modified ostable and tupletable to support muslx32 build.

Signed-off-by: sweeaun <swee.aun.khor@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

Patches rebased due to don't apply, no major changes,

- 0002-Adapt-to-linux-wrs-kernel-version-which-has-characte.patch
- arch_pm.patch
- noman.patch

Patches related to move ostable/triplettable insida data/ostable and
data/tupletable instead also needs to comply the new format of the
tables for arch detection.

- 0006-add-musleabi-to-known-target-tripets.patch
- add_armeb_triplet_entry.patch

And finally a patch to avoid usage --clamp-mtime in tar needs to be
modified because the dpkg-deb internal API changed.

- 0007-dpkg-deb-build.c-Remove-usage-of-clamp-mtime-in-tar.patch

Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

In case a systemd service disables itself while init is still in its
boot sequence the reloading of the service files can be problematic.
In that case: It seems that systemd looses the state of .device units,
and some services depend on such units (namely serial consoles such as
serial-getty@ttymxc0.service). As a result no getty is spawned on the
affected serial tty.
After a power-cycle the second boot (which does not disable services)
succeeds.

The following sequence shows this problem:

| Jan 09 16:36:28 apalis-t30 systemctl[162]: Removed /etc/systemd/system/sysinit.target.wants/run-postinsts.service.
| Jan 09 16:36:28 apalis-t30 systemd[1]: Reloading.
|    ...
|    And then the failing one:
| Feb 22 15:33:15 apalis-t30 systemd[1]: dev-ttyS0.device: Job dev-ttyS0.device/start timed out.
| Feb 22 15:33:15 apalis-t30 systemd[1]: Timed out waiting for device dev-ttyS0.device.
| Feb 22 15:33:15 apalis-t30 systemd[1]: Dependency failed for Serial Getty on ttyS0.
| Feb 22 15:33:15 apalis-t30 systemd[1]: serial-getty@ttyS0.service: Job serial-getty@ttyS0.service/start failed with result 'dependency'.
| Feb 22 15:33:15 apalis-t30 systemd[1]: dev-ttyS0.device: Job dev-ttyS0.device/start failed with result 'timeout'.
| Feb 22 15:33:15 apalis-t30 systemd[1]: Reached target Login Prompts.

(the time has been updated between this two events, but that does not
influence the issue)

Using --no-reload in the service file avoids the "Reloading." message
above and seems to not cause such issues anymore.

Reported-by: Stefan Agner <stefan.agner@toradex.com>
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
(cherry picked from commit 94fabe4b03e899d8876027ee2ced649737a9e522)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

In order to be able to use dpkg-perl on a system various stock perl
modules must also be installed on the system.  Create the list of
required modules based on a read of the code and testing with additional
utilities and list them in RDEPENDS_${PN}-perl.

Signed-off-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

In order for the dpkg perl modules to be used the must reside in the
versioned perl library directory (as to be in the default include path).
Be explicit about this location in our FILES_${PN}-perl directive, so
that if this breaks in the future, the recipe will fail).  We can now
drop the custom do_configure as it wasn't fixing this problem.

Signed-off-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

liblzma is part of xz and we already build it but configure it out. This makes
no sense. Enabling it means we gain multithreaded compression and it speeds
dpkg-deb up massively. It also removes the fork overhead of separate xz processes.

Turning the existing config into a PACKAGECONFIG and turning it on by default
therefore makes best use of what we have available.

The manual RDEPENDS are no longer needed since it uses liblzma which is picked
up by the shlibs code magically.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

The logic is scattered all over the place, but amounts to
"install, unless the rootfs is read only". Let's express that directly.

Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>