[Patch v2 0/2] Extend dependencies of networkmanager for native/nativesdk

[Patch v2 0/2] Extend dependencies of networkmanager for native/nativesdk

[Christian Eggers]

On Friday, 2020-06-19, Richard Pudie wrote:
> A native eudev is a really bad idea, a nativesdk one isn't much better.
> If there are libs we need from here, then the recipe should only be
> generating those but a "native eudev" makes no sense to be needed by a
> build system.
Ack. I already expected that there might be a (hidden?) rule, what type of
software is (NOT) allowed for -native/-nativesdk.

> A native or nativesdk consolekit does not make sense.

> If you need libs from networkmanager, you'll probably have to patch it
> just to generate the libs you need. We don't want builds polluted with
> confusing and potentially quite problematic binaries.
Networkmanager can be built fine without consolekit. Probably this will
not make any difference for libnm.


Changelog v2:
--------------
- eudev: Don't build main package for -native(sdk), only libudev is
  required
- dbus/dbus-glib: Patch removed
- consolekit: Patch removed




________________________________
 [http://assets.arri.com/media/sign/2020-04-03-E-mail-signature-Stellar2_V1.jpg] <https://microsites.arri.com/stellar/>

Get all the latest information from www.arri.com<https://www.arri.com/>, Facebook<https://www.facebook.com/TeamARRI>, Twitter<https://twitter.com/ARRIChannel>, Instagram<https://instagram.com/arri> and YouTube<https://www.youtube.com/user/ARRIChannel>.

Arnold & Richter Cine Technik GmbH & Co. Betriebs KG
Sitz: München - Registergericht: Amtsgericht München - Handelsregisternummer: HRA 57918
Persönlich haftender Gesellschafter: Arnold & Richter Cine Technik GmbH
Sitz: München - Registergericht: Amtsgericht München - Handelsregisternummer: HRB 54477
Geschäftsführer: Dr. Michael Neuhäuser; Stephan Schenk; Walter Trauninger; Markus Zeiler

[PATCH v2 1/2] libnl: Extend for native/nativesdk

[Christian Eggers]

libnl is required by networkmanager.

Signed-off-by: Christian Eggers <ceggers@arri.de>
---
 meta/recipes-support/libnl/libnl_3.5.0.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-support/libnl/libnl_3.5.0.bb b/meta/recipes-support/libnl/libnl_3.5.0.bb
index c0609c4d90..9d0e1441a9 100644
--- a/meta/recipes-support/libnl/libnl_3.5.0.bb
+++ b/meta/recipes-support/libnl/libnl_3.5.0.bb
@@ -40,3 +40,5 @@ FILES_${PN}-route = "${libdir}/libnl-route-3.so.*"
 FILES_${PN}-xfrm  = "${libdir}/libnl-xfrm-3.so.*"
 RREPLACES_${PN}-genl = "libnl-genl2"
 RCONFLICTS_${PN}-genl = "libnl-genl2"
+
+BBCLASSEXTEND = "native nativesdk"
-- 
Christian Eggers
Embedded software developer

Arnold & Richter Cine Technik GmbH & Co. Betriebs KG
Sitz: Muenchen - Registergericht: Amtsgericht Muenchen - Handelsregisternummer: HRA 57918
Persoenlich haftender Gesellschafter: Arnold & Richter Cine Technik GmbH
Sitz: Muenchen - Registergericht: Amtsgericht Muenchen - Handelsregisternummer: HRB 54477
Geschaeftsfuehrer: Dr. Michael Neuhaeuser; Stephan Schenk; Walter Trauninger; Markus Zeiler

[PATCH v2 2/2] eudev: Extend for native/nativesdk

[Christian Eggers]

libudev is required by networkmanager.

Signed-off-by: Christian Eggers <ceggers@arri.de>
---
 meta/recipes-core/udev/eudev_3.2.9.bb | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/meta/recipes-core/udev/eudev_3.2.9.bb b/meta/recipes-core/udev/eudev_3.2.9.bb
index f96f8cbe78..0009896ab9 100644
--- a/meta/recipes-core/udev/eudev_3.2.9.bb
+++ b/meta/recipes-core/udev/eudev_3.2.9.bb
@@ -61,12 +61,22 @@ do_install_prepend_class-target () {
 	sed -i -e 's:${RECIPE_SYSROOT_NATIVE}::g' \
 		${B}/src/udev/keyboard-keys-from-name.h
 }
+do_install_append_class-native() {
+	# for -native, we only want to install libudev
+	rm -r ${D}${sysconfdir} ${D}${nonarch_base_libdir}/udev ${D}${base_sbindir} ${D}${bindir} ${D}${libexecdir}
+}
+do_install_append_class-nativesdk() {
+	# for -nativesdk, we only want to install libudev
+	rm -r ${D}${sysconfdir} ${D}${nonarch_base_libdir}/udev ${D}${base_sbindir} ${D}${bindir} ${D}${libexecdir}
+}
 
 INITSCRIPT_NAME = "udev"
 INITSCRIPT_PARAMS = "start 04 S ."
 
 PACKAGES =+ "libudev"
 PACKAGES =+ "eudev-hwdb"
+# For nativesdk, we only want to package libudev
+PACKAGES_remove_class-nativesdk = "${PN} eudev-hwdb"
 
 
 FILES_${PN} += "${libexecdir} ${nonarch_base_libdir}/udev ${bindir}/udevadm"
@@ -81,6 +91,7 @@ RDEPENDS_eudev-hwdb += "eudev"
 
 RPROVIDES_${PN} = "hotplug udev"
 RPROVIDES_eudev-hwdb += "udev-hwdb"
+RPROVIDES_libudev_class-nativesdk = "${PN}"
 
 PACKAGE_WRITE_DEPS += "qemu-native"
 pkg_postinst_eudev-hwdb () {
@@ -94,3 +105,5 @@ pkg_postinst_eudev-hwdb () {
 pkg_prerm_eudev-hwdb () {
         rm -f $D${sysconfdir}/udev/hwdb.bin
 }
+
+BBCLASSEXTEND = "native nativesdk"
-- 
Christian Eggers
Embedded software developer

Arnold & Richter Cine Technik GmbH & Co. Betriebs KG
Sitz: Muenchen - Registergericht: Amtsgericht Muenchen - Handelsregisternummer: HRA 57918
Persoenlich haftender Gesellschafter: Arnold & Richter Cine Technik GmbH
Sitz: Muenchen - Registergericht: Amtsgericht Muenchen - Handelsregisternummer: HRB 54477
Geschaeftsfuehrer: Dr. Michael Neuhaeuser; Stephan Schenk; Walter Trauninger; Markus Zeiler

Re: [OE-core] [Patch v2 0/2] Extend dependencies of networkmanager for native/nativesdk

[Ross Burton]

I'm curious what you're actually building for native here? (ie what
bit of network manager is meaningful as a native build).

Ross

On Mon, 22 Jun 2020 at 13:54, Christian Eggers <ceggers@arri.de> wrote:
>
> On Friday, 2020-06-19, Richard Pudie wrote:
> > A native eudev is a really bad idea, a nativesdk one isn't much better.
> > If there are libs we need from here, then the recipe should only be
> > generating those but a "native eudev" makes no sense to be needed by a
> > build system.
> Ack. I already expected that there might be a (hidden?) rule, what type of
> software is (NOT) allowed for -native/-nativesdk.
>
> > A native or nativesdk consolekit does not make sense.
>
> > If you need libs from networkmanager, you'll probably have to patch it
> > just to generate the libs you need. We don't want builds polluted with
> > confusing and potentially quite problematic binaries.
> Networkmanager can be built fine without consolekit. Probably this will
> not make any difference for libnm.
>
>
> Changelog v2:
> --------------
> - eudev: Don't build main package for -native(sdk), only libudev is
>   required
> - dbus/dbus-glib: Patch removed
> - consolekit: Patch removed
>
>
>
>
> ________________________________
>  [http://assets.arri.com/media/sign/2020-04-03-E-mail-signature-Stellar2_V1.jpg] <https://microsites.arri.com/stellar/>
>
> Get all the latest information from www.arri.com<https://www.arri.com/>, Facebook<https://www.facebook.com/TeamARRI>, Twitter<https://twitter.com/ARRIChannel>, Instagram<https://instagram.com/arri> and YouTube<https://www.youtube.com/user/ARRIChannel>.
>
> Arnold & Richter Cine Technik GmbH & Co. Betriebs KG
> Sitz: München - Registergericht: Amtsgericht München - Handelsregisternummer: HRA 57918
> Persönlich haftender Gesellschafter: Arnold & Richter Cine Technik GmbH
> Sitz: München - Registergericht: Amtsgericht München - Handelsregisternummer: HRB 54477
> Geschäftsführer: Dr. Michael Neuhäuser; Stephan Schenk; Walter Trauninger; Markus Zeiler
> 

Re: [OE-core] [Patch v2 0/2] Extend dependencies of networkmanager for native/nativesdk

[Christian Eggers]

Am Freitag, 26. Juni 2020, 14:06:02 CEST schrieb Ross Burton:
> I'm curious what you're actually building for native here? (ie what
> bit of network manager is meaningful as a native build).
>
> Ross
>
Our own application (embedded product) links against libnm.
This application can either be built for the embedded system
or for PC platform.

I plan to perform unit tests of this application on the build machine
(native). This tests can also include testing the interfaces to
NetworkManager.

I'm still unsure whether I will built and run my own application
tests within the Yocto build environment (native Yocto package)
or doing this "externally" under the (native part of the) SDK. The
compiler/libraries from the build machine itself are not suitable
as they are usually too old.

From your question it sounds like not every type of software
may be suitable for -native/-nativesdk? Shall these packages be
limited to software required for "building" (compiler, code generators,
documentation, ...)?

Sure, I could create separate SDKs for both machines, but having
the "target" SDK and the "PC" SDK together works very fine for us.

regards
Christian

> On Mon, 22 Jun 2020 at 13:54, Christian Eggers <ceggers@arri.de> wrote:
> > On Friday, 2020-06-19, Richard Pudie wrote:
> > > A native eudev is a really bad idea, a nativesdk one isn't much better.
> > > If there are libs we need from here, then the recipe should only be
> > > generating those but a "native eudev" makes no sense to be needed by a
> > > build system.
> >
> > Ack. I already expected that there might be a (hidden?) rule, what type of
> > software is (NOT) allowed for -native/-nativesdk.
> >
> > > A native or nativesdk consolekit does not make sense.
> > >
> > > If you need libs from networkmanager, you'll probably have to patch it
> > > just to generate the libs you need. We don't want builds polluted with
> > > confusing and potentially quite problematic binaries.
> >
> > Networkmanager can be built fine without consolekit. Probably this will
> > not make any difference for libnm.
> >
> >



________________________________
 [http://assets.arri.com/media/sign/2020-04-03-E-mail-signature-Stellar2_V1.jpg] <https://microsites.arri.com/stellar/>

Get all the latest information from www.arri.com<https://www.arri.com/>, Facebook<https://www.facebook.com/TeamARRI>, Twitter<https://twitter.com/ARRIChannel>, Instagram<https://instagram.com/arri> and YouTube<https://www.youtube.com/user/ARRIChannel>.

Arnold & Richter Cine Technik GmbH & Co. Betriebs KG
Sitz: München - Registergericht: Amtsgericht München - Handelsregisternummer: HRA 57918
Persönlich haftender Gesellschafter: Arnold & Richter Cine Technik GmbH
Sitz: München - Registergericht: Amtsgericht München - Handelsregisternummer: HRB 54477
Geschäftsführer: Dr. Michael Neuhäuser; Stephan Schenk; Walter Trauninger; Markus Zeiler