[PATCH 0/2] add ifupdown

[PATCH 0/2] add ifupdown

[Joe Slater]

I'm not sure where this should go, but these patches are for oe-core.
This recipe overrides the versions of ifup and ifdown implemented
by busybox, if present.

This was copied, with one minor change, from meta-overc, as mentioned in
the first patch.

Joe Slater (2):
  ifupdown: import recipe
  ifupdown: create alternative links

 meta/recipes-core/ifupdown/files/99_network        |    1 +
 ...-don-t-rely-on-dpkg-architecture-to-set-a.patch |   56 +++++++++++
 ...-6-.defn-fix-inverted-checks-for-loopback.patch |  103 ++++++++++++++++++++
 meta/recipes-core/ifupdown/ifupdown_0.7.48.1.bb    |   54 ++++++++++
 4 files changed, 214 insertions(+)
 create mode 100644 meta/recipes-core/ifupdown/files/99_network
 create mode 100644 meta/recipes-core/ifupdown/files/defn2-c-man-don-t-rely-on-dpkg-architecture-to-set-a.patch
 create mode 100644 meta/recipes-core/ifupdown/files/inet-6-.defn-fix-inverted-checks-for-loopback.patch
 create mode 100644 meta/recipes-core/ifupdown/ifupdown_0.7.48.1.bb

-- 
1.7.9.5

[PATCH 1/2] ifupdown: import recipe

[Joe Slater]

Implements ifup and ifdown.

Copied from https://github.com/WindRiver-OpenSourceLabs/meta-overc.git
as of commit aa89eebffe06e4aa04701eae9691cb3049cbaef9.

Signed-off-by: Joe Slater <jslater@windriver.com>
---
 meta/recipes-core/ifupdown/files/99_network        |    1 +
 ...-don-t-rely-on-dpkg-architecture-to-set-a.patch |   56 +++++++++++
 ...-6-.defn-fix-inverted-checks-for-loopback.patch |  103 ++++++++++++++++++++
 meta/recipes-core/ifupdown/ifupdown_0.7.48.1.bb    |   54 ++++++++++
 4 files changed, 214 insertions(+)
 create mode 100644 meta/recipes-core/ifupdown/files/99_network
 create mode 100644 meta/recipes-core/ifupdown/files/defn2-c-man-don-t-rely-on-dpkg-architecture-to-set-a.patch
 create mode 100644 meta/recipes-core/ifupdown/files/inet-6-.defn-fix-inverted-checks-for-loopback.patch
 create mode 100644 meta/recipes-core/ifupdown/ifupdown_0.7.48.1.bb

diff --git a/meta/recipes-core/ifupdown/files/99_network b/meta/recipes-core/ifupdown/files/99_network
new file mode 100644
index 0000000..42d5895
--- /dev/null
+++ b/meta/recipes-core/ifupdown/files/99_network
@@ -0,0 +1 @@
+d root root 0755 /run/network none
diff --git a/meta/recipes-core/ifupdown/files/defn2-c-man-don-t-rely-on-dpkg-architecture-to-set-a.patch b/meta/recipes-core/ifupdown/files/defn2-c-man-don-t-rely-on-dpkg-architecture-to-set-a.patch
new file mode 100644
index 0000000..8c4d953
--- /dev/null
+++ b/meta/recipes-core/ifupdown/files/defn2-c-man-don-t-rely-on-dpkg-architecture-to-set-a.patch
@@ -0,0 +1,56 @@
+From 7af9db748974cb3a2c6ef8f9e03d7db1f9f8ee16 Mon Sep 17 00:00:00 2001
+From: Paul Gortmaker <paul.gortmaker@windriver.com>
+Date: Wed, 6 Aug 2014 14:54:12 -0400
+Subject: [PATCH 1/2] defn2[c|man]: don't rely on dpkg-architecture to set arch
+
+In yocto we'll always be cross compiling, and we'll always
+be building on linux for linux (vs. *BSD, hurd, etc.)
+
+Without this the arch is not detected, but it doesn't error
+out, and hence you get useless binaries that don't know any
+arch specific methods, and the end result will be strangeness
+like the loopback device not being configured/enabled.
+
+Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
+---
+ defn2c.pl   | 6 +++---
+ defn2man.pl | 6 +++---
+ 2 files changed, 6 insertions(+), 6 deletions(-)
+
+diff --git a/defn2c.pl b/defn2c.pl
+index c449de2f3d1c..38845e374c76 100755
+--- a/defn2c.pl
++++ b/defn2c.pl
+@@ -2,9 +2,9 @@
+ 
+ use strict;
+ 
+-my $DEB_HOST_ARCH_OS = `dpkg-architecture -qDEB_HOST_ARCH_OS`;
+-
+-$DEB_HOST_ARCH_OS =~ s/\n//;
++#my $DEB_HOST_ARCH_OS = `dpkg-architecture -qDEB_HOST_ARCH_OS`;
++#$DEB_HOST_ARCH_OS =~ s/\n//;
++my $DEB_HOST_ARCH_OS ="linux";
+ 
+ # declarations
+ my $address_family = "";
+diff --git a/defn2man.pl b/defn2man.pl
+index 6ddcfdd4fe68..c9c4dd046597 100755
+--- a/defn2man.pl
++++ b/defn2man.pl
+@@ -2,9 +2,9 @@
+ 
+ use strict;
+ 
+-my $DEB_HOST_ARCH_OS = `dpkg-architecture -qDEB_HOST_ARCH_OS`;
+-
+-$DEB_HOST_ARCH_OS =~ s/\n//;
++#my $DEB_HOST_ARCH_OS = `dpkg-architecture -qDEB_HOST_ARCH_OS`;
++#$DEB_HOST_ARCH_OS =~ s/\n//;
++my $DEB_HOST_ARCH_OS = "linux";
+ 
+ # declarations
+ my $line;
+-- 
+1.9.1
+
diff --git a/meta/recipes-core/ifupdown/files/inet-6-.defn-fix-inverted-checks-for-loopback.patch b/meta/recipes-core/ifupdown/files/inet-6-.defn-fix-inverted-checks-for-loopback.patch
new file mode 100644
index 0000000..bff352e
--- /dev/null
+++ b/meta/recipes-core/ifupdown/files/inet-6-.defn-fix-inverted-checks-for-loopback.patch
@@ -0,0 +1,103 @@
+From 74152ac74a3e1ea0f3be292aa1eeca5ad1fe69c0 Mon Sep 17 00:00:00 2001
+From: Paul Gortmaker <paul.gortmaker@windriver.com>
+Date: Wed, 6 Aug 2014 15:12:11 -0400
+Subject: [PATCH 2/2] inet[6].defn: fix inverted checks for loopback
+
+Compared to the hurd link.defn for loopback, we see these
+are inverted, meaning that you would only be able to configure
+a loopback device that was _not_ named "lo" (unlikely to exist).
+
+The result was that we'd update /run/network/ifstate for "lo"
+but never actually do anything for up/down, as shown below:
+
+root@localhost:~# ifconfig -s
+Iface   MTU Met   RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
+eth0       1500 0   7736329      0   2016 0       5289422      0      0      0 BMRU
+lo        65536 0        18      0      0 0            18      0      0      0 LRU
+root@localhost:~# ifdown lo
+root@localhost:~# echo $?
+0
+root@localhost:~# ifconfig -s
+Iface   MTU Met   RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
+eth0       1500 0   7736406      0   2016 0       5289455      0      0      0 BMRU
+lo        65536 0        18      0      0 0            18      0      0      0 LRU
+root@localhost:~# ifconfig lo down
+root@localhost:~# ifconfig -s
+Iface   MTU Met   RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
+eth0       1500 0   7736474      0   2016 0       5289481      0      0      0 BMRU
+root@localhost:~#
+
+Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
+---
+ inet.defn  | 12 ++++++------
+ inet6.defn |  8 ++++----
+ 2 files changed, 10 insertions(+), 10 deletions(-)
+
+diff --git a/inet.defn b/inet.defn
+index b176ab4ed03e..5fdfb14a0e1c 100644
+--- a/inet.defn
++++ b/inet.defn
+@@ -6,10 +6,10 @@ method loopback
+     This method may be used to define the IPv4 loopback interface.
+ 
+   up
+-    ip link set dev %iface% up if (!iface_is_lo())
++    ip link set dev %iface% up if (iface_is_lo())
+ 
+   down
+-    ip link set dev %iface% down if (!iface_is_lo())
++    ip link set dev %iface% down if (iface_is_lo())
+ 
+ method static
+   description
+@@ -212,11 +212,11 @@ method loopback
+ 
+   up
+     ifconfig %iface% 127.0.0.1 up \
+-	if (!iface_is_lo())
++	if (iface_is_lo())
+ 
+   down
+     ifconfig %iface% down \
+-	if (!iface_is_lo())
++	if (iface_is_lo())
+ 
+ method static
+   description
+@@ -371,11 +371,11 @@ method loopback
+ 
+   up
+     inetutils-ifconfig --interface %iface% --address 127.0.0.1 --up \
+-	if (!iface_is_lo())
++	if (iface_is_lo())
+ 
+   down
+     inetutils-ifconfig --interface %iface% --down \
+-	if (!iface_is_lo())
++	if (iface_is_lo())
+ 
+ method static
+   description
+diff --git a/inet6.defn b/inet6.defn
+index 09325539cd01..4df64aff38cc 100644
+--- a/inet6.defn
++++ b/inet6.defn
+@@ -33,11 +33,11 @@ method loopback
+   description
+     This method may be used to define the IPv6 loopback interface.
+   up
+-    -ip link set dev %iface% up 2>/dev/null if (!iface_is_lo())
+-    -ip addr add dev %iface% ::1 2>/dev/null if (!iface_is_lo())
++    -ip link set dev %iface% up 2>/dev/null if (iface_is_lo())
++    -ip addr add dev %iface% ::1 2>/dev/null if (iface_is_lo())
+   down
+-    -ip addr del dev %iface% ::1 2>/dev/null if (!iface_is_lo())
+-    -ip link set dev %iface% down 2>/dev/null if (!iface_is_lo())
++    -ip addr del dev %iface% ::1 2>/dev/null if (iface_is_lo())
++    -ip link set dev %iface% down 2>/dev/null if (iface_is_lo())
+ 
+ method static
+   description
+-- 
+1.9.1
+
diff --git a/meta/recipes-core/ifupdown/ifupdown_0.7.48.1.bb b/meta/recipes-core/ifupdown/ifupdown_0.7.48.1.bb
new file mode 100644
index 0000000..e29cc49
--- /dev/null
+++ b/meta/recipes-core/ifupdown/ifupdown_0.7.48.1.bb
@@ -0,0 +1,54 @@
+SUMMARY = "ifupdown: basic ifup and ifdown used by initscripts"
+DESCRIPTION = "High level tools to configure network interfaces \
+This package provides the tools ifup and ifdown which may be used to \
+configure (or, respectively, deconfigure) network interfaces, based on \
+the file /etc/network/interfaces."
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
+
+SRC_URI = "http://archive.ubuntu.com/ubuntu/pool/main/i/ifupdown/ifupdown_0.7.48.1ubuntu5.tar.gz \
+	   file://defn2-c-man-don-t-rely-on-dpkg-architecture-to-set-a.patch \
+	   file://inet-6-.defn-fix-inverted-checks-for-loopback.patch \
+	   file://99_network \
+	  "
+
+EXTRA_OEMAKE = ""
+
+# needed so we don't get default S="${WORKDIR}/ifupdown-${PV}"
+S = "${WORKDIR}/ifupdown-${PV}ubuntu5"
+
+
+inherit update-rc.d
+
+do_compile () {
+	chmod a+rx *.pl *.sh
+	oe_runmake 'CC=${CC}' "CFLAGS=${CFLAGS} -Wall -W -D'IFUPDOWN_VERSION=\"${PV}\"'"
+}
+
+do_install () {
+	install -d ${D}${mandir}/man8 \
+		  ${D}${mandir}/man5 \
+		  ${D}${base_sbindir}
+
+	# If volatiles are used, then we'll also need /run/network there too.
+	install -d ${D}/etc/default/volatiles
+	install -m 0644 ${WORKDIR}/99_network ${D}/etc/default/volatiles
+
+	install -m 0755 ifup ${D}${base_sbindir}/
+	ln ${D}${base_sbindir}/ifup ${D}${base_sbindir}/ifdown
+	install -m 0644 ifup.8 ${D}${mandir}/man8
+	install -m 0644 interfaces.5 ${D}${mandir}/man5
+	cd ${D}${mandir}/man8 && ln -s ifup.8 ifdown.8
+}
+
+ALTERNATIVE_PRIORITY = "100"
+ALTERNATIVE_${PN} = "ifup ifdown"
+
+ALTERNATIVE_LINK_NAME[ifup] = "${base_sbindir}/ifup"
+ALTERNATIVE_LINK_NAME[ifdown] = "${base_sbindir}/ifdown"
+
+INITSCRIPT_NAME = "ifup"
+INITSCRIPT_PARAMS = "start 39 S . stop 39 0 6 1 ."
+
+SRC_URI[md5sum] = "85ba375f3c6f26d34efb2a8575e77fc8"
+SRC_URI[sha256sum] = "08dce14692c07b72b583b86c4d3ace0d9dac1928925144cc3ddde15b694ebbdf"
-- 
1.7.9.5

[PATCH 2/2] ifupdown: create alternative links

[Joe Slater]

Inherit update-alternatives so links are created.  ifup
and ifdown are higher priority than the versions provided
by busybox.

Signed-off-by: Joe Slater <jslater@windriver.com>
---
 meta/recipes-core/ifupdown/ifupdown_0.7.48.1.bb |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/ifupdown/ifupdown_0.7.48.1.bb b/meta/recipes-core/ifupdown/ifupdown_0.7.48.1.bb
index e29cc49..24eb87b 100644
--- a/meta/recipes-core/ifupdown/ifupdown_0.7.48.1.bb
+++ b/meta/recipes-core/ifupdown/ifupdown_0.7.48.1.bb
@@ -18,7 +18,7 @@ EXTRA_OEMAKE = ""
 S = "${WORKDIR}/ifupdown-${PV}ubuntu5"
 
 
-inherit update-rc.d
+inherit update-rc.d update-alternatives
 
 do_compile () {
 	chmod a+rx *.pl *.sh
-- 
1.7.9.5

Re: [PATCH 1/2] ifupdown: import recipe

[Otavio Salvador]

On Tue, Sep 1, 2015 at 6:34 PM, Joe Slater <jslater@windriver.com> wrote:
> Implements ifup and ifdown.
>
> Copied from https://github.com/WindRiver-OpenSourceLabs/meta-overc.git
> as of commit aa89eebffe06e4aa04701eae9691cb3049cbaef9.
>
> Signed-off-by: Joe Slater <jslater@windriver.com>

I think this belongs to meta-networking. Also, what this one provides
which is not provided by the busybox one?

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH 1/2] ifupdown: import recipe

[Randy MacLeod]

On 2015-09-02 11:55 AM, Otavio Salvador wrote:
> On Tue, Sep 1, 2015 at 6:34 PM, Joe Slater <jslater@windriver.com> wrote:
>> Implements ifup and ifdown.
>>
>> Copied from https://github.com/WindRiver-OpenSourceLabs/meta-overc.git
>> as of commit aa89eebffe06e4aa04701eae9691cb3049cbaef9.
>>
>> Signed-off-by: Joe Slater <jslater@windriver.com>
>
> I think this belongs to meta-networking. Also, what this one provides
> which is not provided by the busybox one?
>

We're trying to make busybox optional for larger systems
that want to only use the full-featured/bloated packages.
It's not a large tax to carry busybox in a 50+ MB image but
it would be nice to not require it.

-- 
# Randy MacLeod. SMTS, Linux, Wind River
Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, 
Canada, K2K 2W5

Re: [PATCH 1/2] ifupdown: import recipe

[Otavio Salvador]

On Wed, Sep 2, 2015 at 4:09 PM, Randy MacLeod
<randy.macleod@windriver.com> wrote:
> On 2015-09-02 11:55 AM, Otavio Salvador wrote:
>>
>> On Tue, Sep 1, 2015 at 6:34 PM, Joe Slater <jslater@windriver.com> wrote:
>>>
>>> Implements ifup and ifdown.
>>>
>>> Copied from https://github.com/WindRiver-OpenSourceLabs/meta-overc.git
>>> as of commit aa89eebffe06e4aa04701eae9691cb3049cbaef9.
>>>
>>> Signed-off-by: Joe Slater <jslater@windriver.com>
>>
>>
>> I think this belongs to meta-networking. Also, what this one provides
>> which is not provided by the busybox one?
>
> We're trying to make busybox optional for larger systems
> that want to only use the full-featured/bloated packages.
> It's not a large tax to carry busybox in a 50+ MB image but
> it would be nice to not require it.

I see; I still think this belongs to meta-networking as it will allow
this to be done however won't add new recipes in core.

If many people start to use this, we can move this to core.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH 1/2] ifupdown: import recipe

[Richard Purdie]

On Wed, 2015-09-02 at 16:23 -0300, Otavio Salvador wrote:
> On Wed, Sep 2, 2015 at 4:09 PM, Randy MacLeod
> <randy.macleod@windriver.com> wrote:
> > On 2015-09-02 11:55 AM, Otavio Salvador wrote:
> >>
> >> On Tue, Sep 1, 2015 at 6:34 PM, Joe Slater <jslater@windriver.com> wrote:
> >>>
> >>> Implements ifup and ifdown.
> >>>
> >>> Copied from https://github.com/WindRiver-OpenSourceLabs/meta-overc.git
> >>> as of commit aa89eebffe06e4aa04701eae9691cb3049cbaef9.
> >>>
> >>> Signed-off-by: Joe Slater <jslater@windriver.com>
> >>
> >>
> >> I think this belongs to meta-networking. Also, what this one provides
> >> which is not provided by the busybox one?
> >
> > We're trying to make busybox optional for larger systems
> > that want to only use the full-featured/bloated packages.
> > It's not a large tax to carry busybox in a 50+ MB image but
> > it would be nice to not require it.
> 
> I see; I still think this belongs to meta-networking as it will allow
> this to be done however won't add new recipes in core.
> 
> If many people start to use this, we can move this to core.

To put this another way, I think it is probably reasonable that we
should be able to build an image from OE-Core with basic functionality
like networking without busybox?

Cheers,

Richard

Re: [PATCH 1/2] ifupdown: import recipe

[Otavio Salvador]

On Thu, Sep 3, 2015 at 9:11 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Wed, 2015-09-02 at 16:23 -0300, Otavio Salvador wrote:
>> On Wed, Sep 2, 2015 at 4:09 PM, Randy MacLeod
>> <randy.macleod@windriver.com> wrote:
>> > On 2015-09-02 11:55 AM, Otavio Salvador wrote:
>> >>
>> >> On Tue, Sep 1, 2015 at 6:34 PM, Joe Slater <jslater@windriver.com> wrote:
>> >>>
>> >>> Implements ifup and ifdown.
>> >>>
>> >>> Copied from https://github.com/WindRiver-OpenSourceLabs/meta-overc.git
>> >>> as of commit aa89eebffe06e4aa04701eae9691cb3049cbaef9.
>> >>>
>> >>> Signed-off-by: Joe Slater <jslater@windriver.com>
>> >>
>> >>
>> >> I think this belongs to meta-networking. Also, what this one provides
>> >> which is not provided by the busybox one?
>> >
>> > We're trying to make busybox optional for larger systems
>> > that want to only use the full-featured/bloated packages.
>> > It's not a large tax to carry busybox in a 50+ MB image but
>> > it would be nice to not require it.
>>
>> I see; I still think this belongs to meta-networking as it will allow
>> this to be done however won't add new recipes in core.
>>
>> If many people start to use this, we can move this to core.
>
> To put this another way, I think it is probably reasonable that we
> should be able to build an image from OE-Core with basic functionality
> like networking without busybox?

That is the point; this were not in meta-networking and noone missed
it until now. Moving this to oe-core straight seems overkill.

I think moving this to meta-networking is right and if many people use
it, oe-core is next step.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH 1/2] ifupdown: import recipe

[Bruce Ashfield]

On Thu, Sep 3, 2015 at 8:11 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Wed, 2015-09-02 at 16:23 -0300, Otavio Salvador wrote:
>> On Wed, Sep 2, 2015 at 4:09 PM, Randy MacLeod
>> <randy.macleod@windriver.com> wrote:
>> > On 2015-09-02 11:55 AM, Otavio Salvador wrote:
>> >>
>> >> On Tue, Sep 1, 2015 at 6:34 PM, Joe Slater <jslater@windriver.com> wrote:
>> >>>
>> >>> Implements ifup and ifdown.
>> >>>
>> >>> Copied from https://github.com/WindRiver-OpenSourceLabs/meta-overc.git
>> >>> as of commit aa89eebffe06e4aa04701eae9691cb3049cbaef9.
>> >>>
>> >>> Signed-off-by: Joe Slater <jslater@windriver.com>
>> >>
>> >>
>> >> I think this belongs to meta-networking. Also, what this one provides
>> >> which is not provided by the busybox one?
>> >
>> > We're trying to make busybox optional for larger systems
>> > that want to only use the full-featured/bloated packages.
>> > It's not a large tax to carry busybox in a 50+ MB image but
>> > it would be nice to not require it.
>>
>> I see; I still think this belongs to meta-networking as it will allow
>> this to be done however won't add new recipes in core.
>>
>> If many people start to use this, we can move this to core.
>
> To put this another way, I think it is probably reasonable that we
> should be able to build an image from OE-Core with basic functionality
> like networking without busybox?

That's what I'd support. If everything you need for the functionality with busy
box is in oe-core, to me, it doesn't make sense to go outside core to get that
same functionality without busybox.

Cheers,

Bruce

>
> Cheers,
>
> Richard
>
>
> --
> _______________________________________________
> 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"

Re: [PATCH 1/2] ifupdown: import recipe

[Jack Mitchell]

On 02/09/15 16:55, Otavio Salvador wrote:
> On Tue, Sep 1, 2015 at 6:34 PM, Joe Slater <jslater@windriver.com> wrote:
>> Implements ifup and ifdown.
>>
>> Copied from https://github.com/WindRiver-OpenSourceLabs/meta-overc.git
>> as of commit aa89eebffe06e4aa04701eae9691cb3049cbaef9.
>>
>> Signed-off-by: Joe Slater <jslater@windriver.com>
>
> I think this belongs to meta-networking. Also, what this one provides
> which is not provided by the busybox one?
>

This provides hotplug support which the busybox version does not. I'm torn on 
where it should land i.e. meta-networking vs core but it is a useful addition 
regardless.

If you're attempting to do a non busybox based build, then I don't see the 
reasoning for not just using connman as your networking manager instead which is 
already supported in core.

Re: [PATCH 1/2] ifupdown: import recipe

[Khem Raj]

On Thu, Sep 3, 2015 at 5:20 AM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>> To put this another way, I think it is probably reasonable that we
>> should be able to build an image from OE-Core with basic functionality
>> like networking without busybox?
>
> That's what I'd support. If everything you need for the functionality with busy
> box is in oe-core, to me, it doesn't make sense to go outside core to get that
> same functionality without busybox.

irrespective of this change. I see yet another configuration with this
into OE-core, overall OE-Core should get smaller
and case does not sound convincing to me. You dont want to use busybox
in a fairly large image which has other GPLv2 software in
it. Thats fine but doesnt look like a common usecase to me

Re: [PATCH 1/2] ifupdown: import recipe

[Richard Purdie]

On Thu, 2015-09-03 at 13:22 -0700, Khem Raj wrote:
> On Thu, Sep 3, 2015 at 5:20 AM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
> >> To put this another way, I think it is probably reasonable that we
> >> should be able to build an image from OE-Core with basic functionality
> >> like networking without busybox?
> >
> > That's what I'd support. If everything you need for the functionality with busy
> > box is in oe-core, to me, it doesn't make sense to go outside core to get that
> > same functionality without busybox.
> 
> irrespective of this change. I see yet another configuration with this
> into OE-core, overall OE-Core should get smaller
> and case does not sound convincing to me. You dont want to use busybox
> in a fairly large image which has other GPLv2 software in
> it. Thats fine but doesnt look like a common usecase to me

Nobody mentioned GPLv2, that isn't relevant here.

I have heard OE being dismissed since it can't produce an image without
busybox in it. The implication is we can't build "big" Linux, only small
embedded things. The pieces we need busybox for are tiny and should be
easy to replace (like this does).

So I can see a fairly compelling argument for OE-Core to be able to
generate a busybox free image with standard functionality just from a PR
perspective. From what I gather we have people willing to test and
maintain it too...

Cheers,

Richard

Re: [PATCH 1/2] ifupdown: import recipe

[Otavio Salvador]

On Thu, Sep 3, 2015 at 5:27 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Thu, 2015-09-03 at 13:22 -0700, Khem Raj wrote:
>> On Thu, Sep 3, 2015 at 5:20 AM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>> >> To put this another way, I think it is probably reasonable that we
>> >> should be able to build an image from OE-Core with basic functionality
>> >> like networking without busybox?
>> >
>> > That's what I'd support. If everything you need for the functionality with busy
>> > box is in oe-core, to me, it doesn't make sense to go outside core to get that
>> > same functionality without busybox.
>>
>> irrespective of this change. I see yet another configuration with this
>> into OE-core, overall OE-Core should get smaller
>> and case does not sound convincing to me. You dont want to use busybox
>> in a fairly large image which has other GPLv2 software in
>> it. Thats fine but doesnt look like a common usecase to me
>
> Nobody mentioned GPLv2, that isn't relevant here.
>
> I have heard OE being dismissed since it can't produce an image without
> busybox in it. The implication is we can't build "big" Linux, only small
> embedded things. The pieces we need busybox for are tiny and should be
> easy to replace (like this does).
>
> So I can see a fairly compelling argument for OE-Core to be able to
> generate a busybox free image with standard functionality just from a PR
> perspective. From what I gather we have people willing to test and
> maintain it too...

If people were demanding it, it would have been moved for
meta-networking ages ago, it seems it is not the case.

So my vote is:

 - move to meta-networking
 - for 2.1 we see if it goes to core or not

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH 1/2] ifupdown: import recipe

[Bruce Ashfield]

On Thu, Sep 3, 2015 at 4:32 PM, Otavio Salvador
<otavio.salvador@ossystems.com.br> wrote:
> On Thu, Sep 3, 2015 at 5:27 PM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>> On Thu, 2015-09-03 at 13:22 -0700, Khem Raj wrote:
>>> On Thu, Sep 3, 2015 at 5:20 AM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>>> >> To put this another way, I think it is probably reasonable that we
>>> >> should be able to build an image from OE-Core with basic functionality
>>> >> like networking without busybox?
>>> >
>>> > That's what I'd support. If everything you need for the functionality with busy
>>> > box is in oe-core, to me, it doesn't make sense to go outside core to get that
>>> > same functionality without busybox.
>>>
>>> irrespective of this change. I see yet another configuration with this
>>> into OE-core, overall OE-Core should get smaller
>>> and case does not sound convincing to me. You dont want to use busybox
>>> in a fairly large image which has other GPLv2 software in
>>> it. Thats fine but doesnt look like a common usecase to me
>>
>> Nobody mentioned GPLv2, that isn't relevant here.
>>
>> I have heard OE being dismissed since it can't produce an image without
>> busybox in it. The implication is we can't build "big" Linux, only small
>> embedded things. The pieces we need busybox for are tiny and should be
>> easy to replace (like this does).
>>
>> So I can see a fairly compelling argument for OE-Core to be able to
>> generate a busybox free image with standard functionality just from a PR
>> perspective. From what I gather we have people willing to test and
>> maintain it too...
>
> If people were demanding it, it would have been moved for
> meta-networking ages ago, it seems it is not the case.

... or they were just holding it elsewhere, since not everyone has the
time to get things merged to core. In particular if they think it will be
a battle.

>
> So my vote is:
>
>  - move to meta-networking

And what if the use cases don't want/need meta-networking ? We have
the submission and one use case, and one of the reasons it was sent
to core was to keep a finite set of layers and recipes to build such an image.

Joe/Randy ?

It is this sort of thing that forces use of combo layers or the whitelist
classes :)

>  - for 2.1 we see if it goes to core or not

But without criteria for success .. what does that get us ? What is the
case that needs to be made for a move to core in 2.1, that isn't being
made now ?

Yes, I'm playing devil's advocate on this thread .. since I want to see
this sort of thing clearly defined.

Cheers,

Bruce

>
> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
> --
> _______________________________________________
> 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"

Re: [PATCH 1/2] ifupdown: import recipe

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1882 bytes --]


> On Sep 3, 2015, at 1:27 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> 
> On Thu, 2015-09-03 at 13:22 -0700, Khem Raj wrote:
>> On Thu, Sep 3, 2015 at 5:20 AM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>>>> To put this another way, I think it is probably reasonable that we
>>>> should be able to build an image from OE-Core with basic functionality
>>>> like networking without busybox?
>>> 
>>> That's what I'd support. If everything you need for the functionality with busy
>>> box is in oe-core, to me, it doesn't make sense to go outside core to get that
>>> same functionality without busybox.
>> 
>> irrespective of this change. I see yet another configuration with this
>> into OE-core, overall OE-Core should get smaller
>> and case does not sound convincing to me. You dont want to use busybox
>> in a fairly large image which has other GPLv2 software in
>> it. Thats fine but doesnt look like a common usecase to me
> 
> Nobody mentioned GPLv2, that isn't relevant here.

I assumed thats one reason to not include it. I am trying to understand reasoning to
not include busybox. Or is is just because its a poster child for litigations.

> 
> I have heard OE being dismissed since it can't produce an image without
> busybox in it. The implication is we can't build "big" Linux, only small
> embedded things. The pieces we need busybox for are tiny and should be
> easy to replace (like this does).

as we include other alternative providers, they get preference over busybox applets
even if busybox is part of it.

> 
> So I can see a fairly compelling argument for OE-Core to be able to
> generate a busybox free image with standard functionality just from a PR
> perspective. From what I gather we have people willing to test and
> maintain it too…

PR I see. I was searching for technical reasons.

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [PATCH 1/2] ifupdown: import recipe

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 3432 bytes --]


> On Sep 3, 2015, at 2:02 PM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
> 
> On Thu, Sep 3, 2015 at 4:32 PM, Otavio Salvador
> <otavio.salvador@ossystems.com.br> wrote:
>> On Thu, Sep 3, 2015 at 5:27 PM, Richard Purdie
>> <richard.purdie@linuxfoundation.org> wrote:
>>> On Thu, 2015-09-03 at 13:22 -0700, Khem Raj wrote:
>>>> On Thu, Sep 3, 2015 at 5:20 AM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>>>>>> To put this another way, I think it is probably reasonable that we
>>>>>> should be able to build an image from OE-Core with basic functionality
>>>>>> like networking without busybox?
>>>>> 
>>>>> That's what I'd support. If everything you need for the functionality with busy
>>>>> box is in oe-core, to me, it doesn't make sense to go outside core to get that
>>>>> same functionality without busybox.
>>>> 
>>>> irrespective of this change. I see yet another configuration with this
>>>> into OE-core, overall OE-Core should get smaller
>>>> and case does not sound convincing to me. You dont want to use busybox
>>>> in a fairly large image which has other GPLv2 software in
>>>> it. Thats fine but doesnt look like a common usecase to me
>>> 
>>> Nobody mentioned GPLv2, that isn't relevant here.
>>> 
>>> I have heard OE being dismissed since it can't produce an image without
>>> busybox in it. The implication is we can't build "big" Linux, only small
>>> embedded things. The pieces we need busybox for are tiny and should be
>>> easy to replace (like this does).
>>> 
>>> So I can see a fairly compelling argument for OE-Core to be able to
>>> generate a busybox free image with standard functionality just from a PR
>>> perspective. From what I gather we have people willing to test and
>>> maintain it too...
>> 
>> If people were demanding it, it would have been moved for
>> meta-networking ages ago, it seems it is not the case.
> 
> ... or they were just holding it elsewhere, since not everyone has the
> time to get things merged to core. In particular if they think it will be
> a battle.

thats how we bloated oe-classic. Oh people might need it because I need it therefore slam it in
I have written a packagegroup to replace busybox but I never thought it was so core.

> 
>> 
>> So my vote is:
>> 
>> - move to meta-networking
> 
> And what if the use cases don't want/need meta-networking ? We have
> the submission and one use case, and one of the reasons it was sent
> to core was to keep a finite set of layers and recipes to build such an image.
> 
> Joe/Randy ?
> 
> It is this sort of thing that forces use of combo layers or the whitelist
> classes :)

You can also help in making those layers meet the quality criteria you need instead of being
pick what I need throw the rest out approach.

> 
>> - for 2.1 we see if it goes to core or not
> 
> But without criteria for success .. what does that get us ? What is the
> case that needs to be made for a move to core in 2.1, that isn't being
> made now ?
> 
> Yes, I'm playing devil's advocate on this thread .. since I want to see
> this sort of thing clearly defined.

if its required by more than 1 distro. Is duplicated in other layers because the layer it resides in
is not used by a distro. It replaces a core functionality in OE-Core. It has to be a building block and not a leaf package e.g. These Would be some of things that may be thought of.

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [PATCH 1/2] ifupdown: import recipe

[Phil Blundell]

On Thu, 2015-09-03 at 13:22 -0700, Khem Raj wrote:
> irrespective of this change. I see yet another configuration with this
> into OE-core, overall OE-Core should get smaller
> and case does not sound convincing to me. You dont want to use busybox
> in a fairly large image which has other GPLv2 software in
> it. Thats fine but doesnt look like a common usecase to me

In general, I don't think it is a good idea for oe-core to be entirely
beholden to busybox or any other package, and I would be all in favour
of including an alternative implementation for everything that we depend
on busybox for.

In the specific case of ifupdown, the whole thing seems a little bit
1990s and it's hard to avoid the sense that there are better ways to
solve that particular problem nowadays.  But oe-core does already
include net-tools, which is if anything even more retro (and is in a
similar position vis-a-vis busybox) so there is precedent for including
this kind of thing.

It's also not as if ifupdown is a large piece of software with a complex
web of ABI dependencies that will introduce some huge maintenance burden
in the future.  So I can't see any real downside to adding it to
oe-core.

p.

Re: [PATCH 1/2] ifupdown: import recipe

[Bruce Ashfield]

On Thu, Sep 3, 2015 at 5:24 PM, Khem Raj <raj.khem@gmail.com> wrote:
>
>> On Sep 3, 2015, at 2:02 PM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>>
>> On Thu, Sep 3, 2015 at 4:32 PM, Otavio Salvador
>> <otavio.salvador@ossystems.com.br> wrote:
>>> On Thu, Sep 3, 2015 at 5:27 PM, Richard Purdie
>>> <richard.purdie@linuxfoundation.org> wrote:
>>>> On Thu, 2015-09-03 at 13:22 -0700, Khem Raj wrote:
>>>>> On Thu, Sep 3, 2015 at 5:20 AM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>>>>>>> To put this another way, I think it is probably reasonable that we
>>>>>>> should be able to build an image from OE-Core with basic functionality
>>>>>>> like networking without busybox?
>>>>>>
>>>>>> That's what I'd support. If everything you need for the functionality with busy
>>>>>> box is in oe-core, to me, it doesn't make sense to go outside core to get that
>>>>>> same functionality without busybox.
>>>>>
>>>>> irrespective of this change. I see yet another configuration with this
>>>>> into OE-core, overall OE-Core should get smaller
>>>>> and case does not sound convincing to me. You dont want to use busybox
>>>>> in a fairly large image which has other GPLv2 software in
>>>>> it. Thats fine but doesnt look like a common usecase to me
>>>>
>>>> Nobody mentioned GPLv2, that isn't relevant here.
>>>>
>>>> I have heard OE being dismissed since it can't produce an image without
>>>> busybox in it. The implication is we can't build "big" Linux, only small
>>>> embedded things. The pieces we need busybox for are tiny and should be
>>>> easy to replace (like this does).
>>>>
>>>> So I can see a fairly compelling argument for OE-Core to be able to
>>>> generate a busybox free image with standard functionality just from a PR
>>>> perspective. From what I gather we have people willing to test and
>>>> maintain it too...
>>>
>>> If people were demanding it, it would have been moved for
>>> meta-networking ages ago, it seems it is not the case.
>>
>> ... or they were just holding it elsewhere, since not everyone has the
>> time to get things merged to core. In particular if they think it will be
>> a battle.
>
> thats how we bloated oe-classic. Oh people might need it because I need it therefore slam it in
> I have written a packagegroup to replace busybox but I never thought it was so core.
>
>>
>>>
>>> So my vote is:
>>>
>>> - move to meta-networking
>>
>> And what if the use cases don't want/need meta-networking ? We have
>> the submission and one use case, and one of the reasons it was sent
>> to core was to keep a finite set of layers and recipes to build such an image.
>>
>> Joe/Randy ?
>>
>> It is this sort of thing that forces use of combo layers or the whitelist
>> classes :)
>
> You can also help in making those layers meet the quality criteria you need instead of being
> pick what I need throw the rest out approach.

Agreed. No arguments there .. and hopefully we can also finally break the layers
up into smaller parts / separate repos.

I've had the issue that I can't just update meta-networking .. I get everything.
I can help with quality in layers that I use (which I do), but when
versions change
underneath you (and you have a specific requirement), there's little that can
be done ... except copy and pin.

>
>>
>>> - for 2.1 we see if it goes to core or not
>>
>> But without criteria for success .. what does that get us ? What is the
>> case that needs to be made for a move to core in 2.1, that isn't being
>> made now ?
>>
>> Yes, I'm playing devil's advocate on this thread .. since I want to see
>> this sort of thing clearly defined.
>
> if its required by more than 1 distro. Is duplicated in other layers because the layer it resides in
> is not used by a distro. It replaces a core functionality in OE-Core. It has to be a building block and not a leaf package e.g. These Would be some of things that may be thought of.

Agreed.


Bruce




-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH 1/2] ifupdown: import recipe

[Richard Purdie]

On Thu, 2015-09-03 at 14:15 -0700, Khem Raj wrote:
> > On Sep 3, 2015, at 1:27 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> > 
> > On Thu, 2015-09-03 at 13:22 -0700, Khem Raj wrote:
> >> On Thu, Sep 3, 2015 at 5:20 AM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
> >>>> To put this another way, I think it is probably reasonable that we
> >>>> should be able to build an image from OE-Core with basic functionality
> >>>> like networking without busybox?
> >>> 
> >>> That's what I'd support. If everything you need for the functionality with busy
> >>> box is in oe-core, to me, it doesn't make sense to go outside core to get that
> >>> same functionality without busybox.
> >> 
> >> irrespective of this change. I see yet another configuration with this
> >> into OE-core, overall OE-Core should get smaller
> >> and case does not sound convincing to me. You dont want to use busybox
> >> in a fairly large image which has other GPLv2 software in
> >> it. Thats fine but doesnt look like a common usecase to me
> > 
> > Nobody mentioned GPLv2, that isn't relevant here.
> 
> I assumed thats one reason to not include it. I am trying to understand reasoning to
> not include busybox. Or is is just because its a poster child for litigations.

The litigation issues surrounding it certainly don't do it any favours,
but the main issue is that if busybox is there, we're not seen as a
"proper/full" linux.

> > I have heard OE being dismissed since it can't produce an image without
> > busybox in it. The implication is we can't build "big" Linux, only small
> > embedded things. The pieces we need busybox for are tiny and should be
> > easy to replace (like this does).
> 
> as we include other alternative providers, they get preference over busybox applets
> even if busybox is part of it.

The problem is some people don't want any busybox.

> > So I can see a fairly compelling argument for OE-Core to be able to
> > generate a busybox free image with standard functionality just from a PR
> > perspective. From what I gather we have people willing to test and
> > maintain it too…
> 
> PR I see. I was searching for technical reasons.

Well, its technical but related to the image of the project too. Can
OE-Core today produce a "standard linux desktop" type "full" featured
filesystem? I cannot honestly say it can due to this reason, busybox has
to be there. There are some people who do discount OE because of this.
This isn't new, I remember Marcin amongst others working on this. We're
close, but close doesn't mean we can answer "yes" to the question and I
think it would be nice to be able to do so clearly.

Cheers,

Richard

Re: [PATCH 1/2] ifupdown: import recipe

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1761 bytes --]


> On Sep 3, 2015, at 2:28 PM, Phil Blundell <pb@pbcl.net> wrote:
> 
> On Thu, 2015-09-03 at 13:22 -0700, Khem Raj wrote:
>> irrespective of this change. I see yet another configuration with this
>> into OE-core, overall OE-Core should get smaller
>> and case does not sound convincing to me. You dont want to use busybox
>> in a fairly large image which has other GPLv2 software in
>> it. Thats fine but doesnt look like a common usecase to me
> 
> In general, I don't think it is a good idea for oe-core to be entirely
> beholden to busybox or any other package, and I would be all in favour
> of including an alternative implementation for everything that we depend
> on busybox for.

thats a fine idea,

> 
> In the specific case of ifupdown, the whole thing seems a little bit
> 1990s and it's hard to avoid the sense that there are better ways to
> solve that particular problem nowadays.  But oe-core does already
> include net-tools, which is if anything even more retro (and is in a
> similar position vis-a-vis busybox) so there is precedent for including
> this kind of thing.

Yes although replacing net-tools with iproute2 would have been a better one.

> 
> It's also not as if ifupdown is a large piece of software with a complex
> web of ABI dependencies that will introduce some huge maintenance burden
> in the future.  So I can't see any real downside to adding it to
> oe-core.

It needs maintenance, and if maintainers are fine carrying it
is fine too. Added price is future contributions to other areas/packages
which have to keep working with this, and there will be patches rejected because
they don’t work with this so there is some burden dispersed on development community

> 
> p.
> 
> 


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [PATCH 1/2] ifupdown: import recipe

[Slater, Joseph]

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org [mailto:openembedded-core-
> bounces@lists.openembedded.org] On Behalf Of Richard Purdie
> Sent: Thursday, September 03, 2015 2:39 PM
> To: Khem Raj
> Cc: Patches and discussions about the oe-core layer; Slater, Joseph; Otavio Salvador
> Subject: Re: [OE-core] [oe-core][PATCH 1/2] ifupdown: import recipe
> 
> On Thu, 2015-09-03 at 14:15 -0700, Khem Raj wrote:
> > > On Sep 3, 2015, at 1:27 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> > >
> > > On Thu, 2015-09-03 at 13:22 -0700, Khem Raj wrote:
> > >> On Thu, Sep 3, 2015 at 5:20 AM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
> > >>>> To put this another way, I think it is probably reasonable that we
> > >>>> should be able to build an image from OE-Core with basic functionality
> > >>>> like networking without busybox?
> > >>>
> > >>> That's what I'd support. If everything you need for the functionality with busy
> > >>> box is in oe-core, to me, it doesn't make sense to go outside core to get that
> > >>> same functionality without busybox.
> > >>
> > >> irrespective of this change. I see yet another configuration with this
> > >> into OE-core, overall OE-Core should get smaller
> > >> and case does not sound convincing to me. You dont want to use busybox
> > >> in a fairly large image which has other GPLv2 software in
> > >> it. Thats fine but doesnt look like a common usecase to me
> > >
> > > Nobody mentioned GPLv2, that isn't relevant here.
> >
> > I assumed thats one reason to not include it. I am trying to understand reasoning to
> > not include busybox. Or is is just because its a poster child for litigations.
> 
> The litigation issues surrounding it certainly don't do it any favours,
> but the main issue is that if busybox is there, we're not seen as a
> "proper/full" linux.
> 
> > > I have heard OE being dismissed since it can't produce an image without
> > > busybox in it. The implication is we can't build "big" Linux, only small
> > > embedded things. The pieces we need busybox for are tiny and should be
> > > easy to replace (like this does).
> >
> > as we include other alternative providers, they get preference over busybox applets
> > even if busybox is part of it.
> 
> The problem is some people don't want any busybox.
> 
> > > So I can see a fairly compelling argument for OE-Core to be able to
> > > generate a busybox free image with standard functionality just from a PR
> > > perspective. From what I gather we have people willing to test and
> > > maintain it too…
> >
> > PR I see. I was searching for technical reasons.
> 
> Well, its technical but related to the image of the project too. Can
> OE-Core today produce a "standard linux desktop" type "full" featured
> filesystem? I cannot honestly say it can due to this reason, busybox has
> to be there. There are some people who do discount OE because of this.
> This isn't new, I remember Marcin amongst others working on this. We're
> close, but close doesn't mean we can answer "yes" to the question and I
> think it would be nice to be able to do so clearly.

I think if we are trying to allow removing busybox, the functionality needed
should be in oe-core.  Thus, we pull run-parts out of debianutils (this is now
in oe-core, master), pull start-stop-daemon from dpkg (I sent a patch, but I have not seen
any action), and we add ifupdown.  shadow is there, as is util-linux-blkid.

Me?  I kind of like busybox, but I also think we should provide images without it.

Joe

> 
> Cheers,
> 
> Richard
> 
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH 1/2] ifupdown: import recipe

[Andrew Shadura]

[-- Attachment #1: Type: text/plain, Size: 1009 bytes --]

Hi,

I just wanted to comment on this patch pulled with the recipe:

> +From 74152ac74a3e1ea0f3be292aa1eeca5ad1fe69c0 Mon Sep 17 00:00:00 2001
> +From: Paul Gortmaker <paul.gortmaker@windriver.com>
> +Date: Wed, 6 Aug 2014 15:12:11 -0400
> +Subject: [PATCH 2/2] inet[6].defn: fix inverted checks for loopback

I have already commented on this patch when I still was an upstream
developer for ifupdown, see <https://bugs.debian.org/757291>. The issue
led to this patch was caused by Ubuntu maintainer trying to remove one
of the features he deemed as not yet ready for Ubuntu release, but he
didn't do it properly on the first attempt, thus leading to broken
loopback (which didn't really matter for Ubuntu, as the loopback
interface was configured by upstart there back then).

The correct fix for the issue would be rebasing to the Debian version of
the package which, by the way, has a new active developer, Guus Sliepen.
Then the patch could be dropped.

-- 
Cheers,
  Andrew




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]