[meta-networking][PATCH] strongswan: upgrade to 5.7.1

[meta-networking][PATCH] strongswan: upgrade to 5.7.1

[Chen Qi]

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
---
 .../strongswan/{strongswan_5.6.3.bb => strongswan_5.7.1.bb}           | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta-networking/recipes-support/strongswan/{strongswan_5.6.3.bb => strongswan_5.7.1.bb} (97%)

diff --git a/meta-networking/recipes-support/strongswan/strongswan_5.6.3.bb b/meta-networking/recipes-support/strongswan/strongswan_5.7.1.bb
similarity index 97%
rename from meta-networking/recipes-support/strongswan/strongswan_5.6.3.bb
rename to meta-networking/recipes-support/strongswan/strongswan_5.7.1.bb
index 297f0e7..c8bb17c 100644
--- a/meta-networking/recipes-support/strongswan/strongswan_5.6.3.bb
+++ b/meta-networking/recipes-support/strongswan/strongswan_5.7.1.bb
@@ -12,8 +12,8 @@ SRC_URI = "http://download.strongswan.org/strongswan-${PV}.tar.bz2 \
            file://0001-memory.h-Include-stdint.h-for-uintptr_t.patch \
            "
 
-SRC_URI[md5sum] = "a6a28eeb22aa58080a7581771a5b63f9"
-SRC_URI[sha256sum] = "c3c7dc8201f40625bba92ffd32eb602a8909210d8b3fac4d214c737ce079bf24"
+SRC_URI[md5sum] = "86b7e9321cde075cf382268fd282e0b0"
+SRC_URI[sha256sum] = "006f9c9126e2a2f4e7a874b5e1bd2abec1bbbb193c8b3b3a4c6ccd8c2d454bec"
 
 UPSTREAM_CHECK_REGEX = "strongswan-(?P<pver>\d+(\.\d+)+)\.tar"
 
-- 
2.7.4

Re: [OE-core] [PATCH 1/2] systemd: upgrade to 239

[nick83ola]

Hi Chen,

regarding this issue:

>On 07/26/2018 07:05 AM, Ricardo Salveti wrote:
>> On Mon, Jul 16, 2018 at 11:05 PM, Chen Qi <Qi.Chen at windriver.com> wrote:
>>> Upgrade systemd to 239.
>>>
>>> 3. update-alternatives changes
>>>    The utilities like shutdown, poweroff, etc. are now created as symlinks
>>>    at do_install. So there's no need to use update-alternatives mechanism
>>>    anymore to create the symlinks now. In addtion, I don't think we now
>>>    support multiple init systems at one running system, so there's really
>>>    no need to use update-alternatives mechanism here.
>> I noticed that reboot stopped working locally as I had busybox
>> installed together with systemd, and the busybox version ended up
>> being used as it was provided via update-alternatives.
>>
>> Looking for possible similar broken links, I found that
>> update-alternatives ended up pointing reboot, halt and poweroff to the
>> busybox binary instead of systemctl. Should we revert the changes and
>> bring back update-alternatives for them?
>>
>> Thanks,
>
>I think the correct direction to fix this problem is to make busybox
>only provide init utilities (reboot, halt, etc) when init manager is set
>to busybox.
>
>We current have in busybox recipe's SRC_URI:
>            ${@["",
>"file://init.cfg"][(d.getVar('VIRTUAL-RUNTIME_init_manager') ==
>'busybox')]} \
>
>I think the init utilities should be moved to init.cfg.
>
>Please check my logic to see if you can agree with it.
>We have two facts here.
>1. Init utilities (reboot, halt, etc.) are tightly bond to the specific
>implementation of PID 1.
>2. We only allow one PID 1 in our image. (VIRTUAL-RUNTIME_init_manager).
>So we can conclude from the above two facts that it does not make much
>sense to have multiple providers of init utilities while we only allow
>one PID 1 provider on image.
>
>After all, we are using update-*alternatives*, things that this
>mechanism manages are supposed to generally serve as alternatives to
>each other.
>
>Best Regards,
>Chen Qi

Can you elaborate more what we need to patch?

because this update break all the systemd based systems...

Also there's a following patch that add back an alternative for busybox

8421aede4fdd5132eb953a59099670f9ab1f7f01  systemd: add ALTERNATIVE for reboot

What's the more correct way to do fix this?

Best Regards

Nicola Lunghi

Re: [OE-core] [PATCH 1/2] systemd: upgrade to 239

[nick83ola]

Another thing:

previously
ALTERNATIVE_PRIORITY[reboot] = "100"
was
ALTERNATIVE_PRIORITY[reboot] = "300"

diff of the relevant part:

539,566c559
< # TODO:
< # u-a for runlevel and telinit
<
< ALTERNATIVE_${PN} = "init halt reboot shutdown poweroff runlevel
resolv-conf"
<
< ALTERNATIVE_TARGET[init] = "${rootlibexecdir}/systemd/systemd"
< ALTERNATIVE_LINK_NAME[init] = "${base_sbindir}/init"
< ALTERNATIVE_PRIORITY[init] ?= "300"
<
< ALTERNATIVE_TARGET[halt] = "${base_bindir}/systemctl"
< ALTERNATIVE_LINK_NAME[halt] = "${base_sbindir}/halt"
< ALTERNATIVE_PRIORITY[halt] ?= "300"
<
< ALTERNATIVE_TARGET[reboot] = "${base_bindir}/systemctl"
< ALTERNATIVE_LINK_NAME[reboot] = "${base_sbindir}/reboot"
< ALTERNATIVE_PRIORITY[reboot] ?= "300"
<
< ALTERNATIVE_TARGET[shutdown] = "${base_bindir}/systemctl"
< ALTERNATIVE_LINK_NAME[shutdown] = "${base_sbindir}/shutdown"
< ALTERNATIVE_PRIORITY[shutdown] ?= "300"
<
< ALTERNATIVE_TARGET[poweroff] = "${base_bindir}/systemctl"
< ALTERNATIVE_LINK_NAME[poweroff] = "${base_sbindir}/poweroff"
< ALTERNATIVE_PRIORITY[poweroff] ?= "300"
<
< ALTERNATIVE_TARGET[runlevel] = "${base_bindir}/systemctl"
< ALTERNATIVE_LINK_NAME[runlevel] = "${base_sbindir}/runlevel"
< ALTERNATIVE_PRIORITY[runlevel] ?= "300"
---
> ALTERNATIVE_${PN} = "resolv-conf reboot"
570a564,566
>
> ALTERNATIVE_LINK_NAME[reboot] = "${base_sbindir}/reboot"
> ALTERNATIVE_PRIORITY[reboot] = "100"

On Thu, 18 Oct 2018 at 11:29, nick83ola <nick83ola@gmail.com> wrote:

> Hi Chen,
>
> regarding this issue:
>
> >On 07/26/2018 07:05 AM, Ricardo Salveti wrote:
> >> On Mon, Jul 16, 2018 at 11:05 PM, Chen Qi <Qi.Chen at windriver.com> wrote:
> >>> Upgrade systemd to 239.
> >>>
> >>> 3. update-alternatives changes
> >>>    The utilities like shutdown, poweroff, etc. are now created as symlinks
> >>>    at do_install. So there's no need to use update-alternatives mechanism
> >>>    anymore to create the symlinks now. In addtion, I don't think we now
> >>>    support multiple init systems at one running system, so there's really
> >>>    no need to use update-alternatives mechanism here.
> >> I noticed that reboot stopped working locally as I had busybox
> >> installed together with systemd, and the busybox version ended up
> >> being used as it was provided via update-alternatives.
> >>
> >> Looking for possible similar broken links, I found that
> >> update-alternatives ended up pointing reboot, halt and poweroff to the
> >> busybox binary instead of systemctl. Should we revert the changes and
> >> bring back update-alternatives for them?
> >>
> >> Thanks,
> >
> >I think the correct direction to fix this problem is to make busybox
> >only provide init utilities (reboot, halt, etc) when init manager is set
> >to busybox.
> >
> >We current have in busybox recipe's SRC_URI:
> >            ${@["",
> >"file://init.cfg"][(d.getVar('VIRTUAL-RUNTIME_init_manager') ==
> >'busybox')]} \
> >
> >I think the init utilities should be moved to init.cfg.
> >
> >Please check my logic to see if you can agree with it.
> >We have two facts here.
> >1. Init utilities (reboot, halt, etc.) are tightly bond to the specific
> >implementation of PID 1.
> >2. We only allow one PID 1 in our image. (VIRTUAL-RUNTIME_init_manager).
> >So we can conclude from the above two facts that it does not make much
> >sense to have multiple providers of init utilities while we only allow
> >one PID 1 provider on image.
> >
> >After all, we are using update-*alternatives*, things that this
> >mechanism manages are supposed to generally serve as alternatives to
> >each other.
> >
> >Best Regards,
> >Chen Qi
>
> Can you elaborate more what we need to patch?
>
> because this update break all the systemd based systems...
>
> Also there's a following patch that add back an alternative for busybox
>
> 8421aede4fdd5132eb953a59099670f9ab1f7f01  systemd: add ALTERNATIVE for reboot
>
> What's the more correct way to do fix this?
>
> Best Regards
>
> Nicola Lunghi
>
>

Re: [OE-core] [PATCH 1/2] systemd: upgrade to 239

[Martin Jansa]

Using u-a for the systemd symlinks to systemctl seems like best solution to
me, I've already suggested it in:
http://lists.openembedded.org/pipermail/openembedded-core/2018-October/156597.html

On Thu, Oct 18, 2018 at 12:33 PM nick83ola <nick83ola@gmail.com> wrote:

> Another thing:
>
> previously
> ALTERNATIVE_PRIORITY[reboot] = "100"
> was
> ALTERNATIVE_PRIORITY[reboot] = "300"
>
> diff of the relevant part:
>
> 539,566c559
> < # TODO:
> < # u-a for runlevel and telinit
> <
> < ALTERNATIVE_${PN} = "init halt reboot shutdown poweroff runlevel
> resolv-conf"
> <
> < ALTERNATIVE_TARGET[init] = "${rootlibexecdir}/systemd/systemd"
> < ALTERNATIVE_LINK_NAME[init] = "${base_sbindir}/init"
> < ALTERNATIVE_PRIORITY[init] ?= "300"
> <
> < ALTERNATIVE_TARGET[halt] = "${base_bindir}/systemctl"
> < ALTERNATIVE_LINK_NAME[halt] = "${base_sbindir}/halt"
> < ALTERNATIVE_PRIORITY[halt] ?= "300"
> <
> < ALTERNATIVE_TARGET[reboot] = "${base_bindir}/systemctl"
> < ALTERNATIVE_LINK_NAME[reboot] = "${base_sbindir}/reboot"
> < ALTERNATIVE_PRIORITY[reboot] ?= "300"
> <
> < ALTERNATIVE_TARGET[shutdown] = "${base_bindir}/systemctl"
> < ALTERNATIVE_LINK_NAME[shutdown] = "${base_sbindir}/shutdown"
> < ALTERNATIVE_PRIORITY[shutdown] ?= "300"
> <
> < ALTERNATIVE_TARGET[poweroff] = "${base_bindir}/systemctl"
> < ALTERNATIVE_LINK_NAME[poweroff] = "${base_sbindir}/poweroff"
> < ALTERNATIVE_PRIORITY[poweroff] ?= "300"
> <
> < ALTERNATIVE_TARGET[runlevel] = "${base_bindir}/systemctl"
> < ALTERNATIVE_LINK_NAME[runlevel] = "${base_sbindir}/runlevel"
> < ALTERNATIVE_PRIORITY[runlevel] ?= "300"
> ---
> > ALTERNATIVE_${PN} = "resolv-conf reboot"
> 570a564,566
> >
> > ALTERNATIVE_LINK_NAME[reboot] = "${base_sbindir}/reboot"
> > ALTERNATIVE_PRIORITY[reboot] = "100"
>
> On Thu, 18 Oct 2018 at 11:29, nick83ola <nick83ola@gmail.com> wrote:
>
> > Hi Chen,
> >
> > regarding this issue:
> >
> > >On 07/26/2018 07:05 AM, Ricardo Salveti wrote:
> > >> On Mon, Jul 16, 2018 at 11:05 PM, Chen Qi <Qi.Chen at windriver.com>
> wrote:
> > >>> Upgrade systemd to 239.
> > >>>
> > >>> 3. update-alternatives changes
> > >>>    The utilities like shutdown, poweroff, etc. are now created as
> symlinks
> > >>>    at do_install. So there's no need to use update-alternatives
> mechanism
> > >>>    anymore to create the symlinks now. In addtion, I don't think we
> now
> > >>>    support multiple init systems at one running system, so there's
> really
> > >>>    no need to use update-alternatives mechanism here.
> > >> I noticed that reboot stopped working locally as I had busybox
> > >> installed together with systemd, and the busybox version ended up
> > >> being used as it was provided via update-alternatives.
> > >>
> > >> Looking for possible similar broken links, I found that
> > >> update-alternatives ended up pointing reboot, halt and poweroff to the
> > >> busybox binary instead of systemctl. Should we revert the changes and
> > >> bring back update-alternatives for them?
> > >>
> > >> Thanks,
> > >
> > >I think the correct direction to fix this problem is to make busybox
> > >only provide init utilities (reboot, halt, etc) when init manager is set
> > >to busybox.
> > >
> > >We current have in busybox recipe's SRC_URI:
> > >            ${@["",
> > >"file://init.cfg"][(d.getVar('VIRTUAL-RUNTIME_init_manager') ==
> > >'busybox')]} \
> > >
> > >I think the init utilities should be moved to init.cfg.
> > >
> > >Please check my logic to see if you can agree with it.
> > >We have two facts here.
> > >1. Init utilities (reboot, halt, etc.) are tightly bond to the specific
> > >implementation of PID 1.
> > >2. We only allow one PID 1 in our image. (VIRTUAL-RUNTIME_init_manager).
> > >So we can conclude from the above two facts that it does not make much
> > >sense to have multiple providers of init utilities while we only allow
> > >one PID 1 provider on image.
> > >
> > >After all, we are using update-*alternatives*, things that this
> > >mechanism manages are supposed to generally serve as alternatives to
> > >each other.
> > >
> > >Best Regards,
> > >Chen Qi
> >
> > Can you elaborate more what we need to patch?
> >
> > because this update break all the systemd based systems...
> >
> > Also there's a following patch that add back an alternative for busybox
> >
> > 8421aede4fdd5132eb953a59099670f9ab1f7f01  systemd: add ALTERNATIVE for
> reboot
> >
> > What's the more correct way to do fix this?
> >
> > Best Regards
> >
> > Nicola Lunghi
> >
> >
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>

Re: [OE-core] [PATCH 1/2] systemd: upgrade to 239

[André Draszik]

On Thu, 2018-10-18 at 12:55 +0200, Martin Jansa wrote:
> Using u-a for the systemd symlinks to systemctl seems like best solution
> to
> me, I've already suggested it in:
> http://lists.openembedded.org/pipermail/openembedded-core/2018-October/156597.html

Yes, I'd support that.



Cheers,
Andre'

Re: [OE-core] [PATCH 1/2] systemd: upgrade to 239

[ChenQi]

Hi All,

In brief, I also agree with Martin and will send out patch to add back 
these alternatives for systemd.
Just one thing to confirm.
Martin, you have a customized busybox defconfig which enables init 
utilties by default, right?

Below are more details and history.

1) Why removing alternatives of init utilities from systemd?
I removed the alternatives for init utilities from systemd because I 
thought these init utilities are basically bound to init manager. In 
other words, there's no point to use reboot from busybox when init 
manager is systemd. Same logic applies to other utilities. So I removed 
these alternatives of the init utilties from systemd, and also moved 
related busybox configs to init.cfg.

2) Why reboot is moved out of busybox init.cfg and added back as an 
alternative for systemd?
The above logic misses one thing, the live image. In oe-core, the 
initramfs for the live image is implemented as a bunch of shell scripts. 
And they need the 'reboot' command. More particularly, they call 'reboot 
-f'. That means they only want kernel to do reboot directly, discarding 
PID 1.
There's a yocto bug for this. 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12914

3) The current situation and potential problems
For oe-core, currently we have:
root@qemux86-64:~# ls -l /sbin/reboot
lrwxrwxrwx 1 root root 20 Oct 18 10:50 /sbin/reboot -> /sbin/reboot.systemd
root@qemux86-64:~# ls -l /sbin/reboot.systemd
lrwxrwxrwx 1 root root 16 Oct 18 10:11 /sbin/reboot.systemd -> 
../bin/systemctl
So for oe-core's default configs, things work well.

BUT, I'm now somewhat worried about users who have customized busybox 
defconfig which enables init utilities by default. The current oe-core 
release will cause regression for them if they use systemd +  busybox.

4) What I will do.
I'll add back these init utilities for systemd to avoid regression.

Best Regards,
Chen Qi

On 10/18/2018 06:55 PM, Martin Jansa wrote:
> Using u-a for the systemd symlinks to systemctl seems like best 
> solution to me, I've already suggested it in:
> http://lists.openembedded.org/pipermail/openembedded-core/2018-October/156597.html
>
> On Thu, Oct 18, 2018 at 12:33 PM nick83ola <nick83ola@gmail.com 
> <mailto:nick83ola@gmail.com>> wrote:
>
>     Another thing:
>
>     previously
>     ALTERNATIVE_PRIORITY[reboot] = "100"
>     was
>     ALTERNATIVE_PRIORITY[reboot] = "300"
>
>     diff of the relevant part:
>
>     539,566c559
>     < # TODO:
>     < # u-a for runlevel and telinit
>     <
>     < ALTERNATIVE_${PN} = "init halt reboot shutdown poweroff runlevel
>     resolv-conf"
>     <
>     < ALTERNATIVE_TARGET[init] = "${rootlibexecdir}/systemd/systemd"
>     < ALTERNATIVE_LINK_NAME[init] = "${base_sbindir}/init"
>     < ALTERNATIVE_PRIORITY[init] ?= "300"
>     <
>     < ALTERNATIVE_TARGET[halt] = "${base_bindir}/systemctl"
>     < ALTERNATIVE_LINK_NAME[halt] = "${base_sbindir}/halt"
>     < ALTERNATIVE_PRIORITY[halt] ?= "300"
>     <
>     < ALTERNATIVE_TARGET[reboot] = "${base_bindir}/systemctl"
>     < ALTERNATIVE_LINK_NAME[reboot] = "${base_sbindir}/reboot"
>     < ALTERNATIVE_PRIORITY[reboot] ?= "300"
>     <
>     < ALTERNATIVE_TARGET[shutdown] = "${base_bindir}/systemctl"
>     < ALTERNATIVE_LINK_NAME[shutdown] = "${base_sbindir}/shutdown"
>     < ALTERNATIVE_PRIORITY[shutdown] ?= "300"
>     <
>     < ALTERNATIVE_TARGET[poweroff] = "${base_bindir}/systemctl"
>     < ALTERNATIVE_LINK_NAME[poweroff] = "${base_sbindir}/poweroff"
>     < ALTERNATIVE_PRIORITY[poweroff] ?= "300"
>     <
>     < ALTERNATIVE_TARGET[runlevel] = "${base_bindir}/systemctl"
>     < ALTERNATIVE_LINK_NAME[runlevel] = "${base_sbindir}/runlevel"
>     < ALTERNATIVE_PRIORITY[runlevel] ?= "300"
>     ---
>     > ALTERNATIVE_${PN} = "resolv-conf reboot"
>     570a564,566
>     >
>     > ALTERNATIVE_LINK_NAME[reboot] = "${base_sbindir}/reboot"
>     > ALTERNATIVE_PRIORITY[reboot] = "100"
>
>     On Thu, 18 Oct 2018 at 11:29, nick83ola <nick83ola@gmail.com
>     <mailto:nick83ola@gmail.com>> wrote:
>
>     > Hi Chen,
>     >
>     > regarding this issue:
>     >
>     > >On 07/26/2018 07:05 AM, Ricardo Salveti wrote:
>     > >> On Mon, Jul 16, 2018 at 11:05 PM, Chen Qi <Qi.Chen at
>     windriver.com <http://windriver.com>> wrote:
>     > >>> Upgrade systemd to 239.
>     > >>>
>     > >>> 3. update-alternatives changes
>     > >>>    The utilities like shutdown, poweroff, etc. are now
>     created as symlinks
>     > >>>    at do_install. So there's no need to use
>     update-alternatives mechanism
>     > >>>    anymore to create the symlinks now. In addtion, I don't
>     think we now
>     > >>>    support multiple init systems at one running system, so
>     there's really
>     > >>>    no need to use update-alternatives mechanism here.
>     > >> I noticed that reboot stopped working locally as I had busybox
>     > >> installed together with systemd, and the busybox version ended up
>     > >> being used as it was provided via update-alternatives.
>     > >>
>     > >> Looking for possible similar broken links, I found that
>     > >> update-alternatives ended up pointing reboot, halt and
>     poweroff to the
>     > >> busybox binary instead of systemctl. Should we revert the
>     changes and
>     > >> bring back update-alternatives for them?
>     > >>
>     > >> Thanks,
>     > >
>     > >I think the correct direction to fix this problem is to make
>     busybox
>     > >only provide init utilities (reboot, halt, etc) when init
>     manager is set
>     > >to busybox.
>     > >
>     > >We current have in busybox recipe's SRC_URI:
>     > >            ${@["",
>     > >"file://init.cfg"][(d.getVar('VIRTUAL-RUNTIME_init_manager') ==
>     > >'busybox')]} \
>     > >
>     > >I think the init utilities should be moved to init.cfg.
>     > >
>     > >Please check my logic to see if you can agree with it.
>     > >We have two facts here.
>     > >1. Init utilities (reboot, halt, etc.) are tightly bond to the
>     specific
>     > >implementation of PID 1.
>     > >2. We only allow one PID 1 in our image.
>     (VIRTUAL-RUNTIME_init_manager).
>     > >So we can conclude from the above two facts that it does not
>     make much
>     > >sense to have multiple providers of init utilities while we
>     only allow
>     > >one PID 1 provider on image.
>     > >
>     > >After all, we are using update-*alternatives*, things that this
>     > >mechanism manages are supposed to generally serve as
>     alternatives to
>     > >each other.
>     > >
>     > >Best Regards,
>     > >Chen Qi
>     >
>     > Can you elaborate more what we need to patch?
>     >
>     > because this update break all the systemd based systems...
>     >
>     > Also there's a following patch that add back an alternative for
>     busybox
>     >
>     > 8421aede4fdd5132eb953a59099670f9ab1f7f01  systemd: add
>     ALTERNATIVE for reboot
>     >
>     > What's the more correct way to do fix this?
>     >
>     > Best Regards
>     >
>     > Nicola Lunghi
>     >
>     >
>     -- 
>     _______________________________________________
>     Openembedded-devel mailing list
>     Openembedded-devel@lists.openembedded.org
>     <mailto:Openembedded-devel@lists.openembedded.org>
>     http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>