* [meta-networking][PATCH] strongswan: upgrade to 5.7.1
@ 2018-10-17 5:21 Chen Qi
2018-10-18 10:29 ` [OE-core] [PATCH 1/2] systemd: upgrade to 239 nick83ola
0 siblings, 1 reply; 6+ messages in thread
From: Chen Qi @ 2018-10-17 5:21 UTC (permalink / raw)
To: openembedded-devel
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
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [OE-core] [PATCH 1/2] systemd: upgrade to 239 2018-10-17 5:21 [meta-networking][PATCH] strongswan: upgrade to 5.7.1 Chen Qi @ 2018-10-18 10:29 ` nick83ola 2018-10-18 10:32 ` nick83ola 0 siblings, 1 reply; 6+ messages in thread From: nick83ola @ 2018-10-18 10:29 UTC (permalink / raw) To: Qi.Chen; +Cc: openembeded-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [OE-core] [PATCH 1/2] systemd: upgrade to 239 2018-10-18 10:29 ` [OE-core] [PATCH 1/2] systemd: upgrade to 239 nick83ola @ 2018-10-18 10:32 ` nick83ola 2018-10-18 10:55 ` Martin Jansa 0 siblings, 1 reply; 6+ messages in thread From: nick83ola @ 2018-10-18 10:32 UTC (permalink / raw) To: Qi.Chen; +Cc: openembeded-devel 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 > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [OE-core] [PATCH 1/2] systemd: upgrade to 239 2018-10-18 10:32 ` nick83ola @ 2018-10-18 10:55 ` Martin Jansa 2018-10-18 14:29 ` André Draszik 2018-10-19 3:28 ` ChenQi 0 siblings, 2 replies; 6+ messages in thread From: Martin Jansa @ 2018-10-18 10:55 UTC (permalink / raw) To: nick83ola; +Cc: openembedded-devel 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 > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [OE-core] [PATCH 1/2] systemd: upgrade to 239 2018-10-18 10:55 ` Martin Jansa @ 2018-10-18 14:29 ` André Draszik 2018-10-19 3:28 ` ChenQi 1 sibling, 0 replies; 6+ messages in thread From: André Draszik @ 2018-10-18 14:29 UTC (permalink / raw) To: openembedded-devel 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' ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [OE-core] [PATCH 1/2] systemd: upgrade to 239 2018-10-18 10:55 ` Martin Jansa 2018-10-18 14:29 ` André Draszik @ 2018-10-19 3:28 ` ChenQi 1 sibling, 0 replies; 6+ messages in thread From: ChenQi @ 2018-10-19 3:28 UTC (permalink / raw) To: Martin Jansa, nick83ola; +Cc: openembedded-devel 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 > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-10-19 3:22 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-10-17 5:21 [meta-networking][PATCH] strongswan: upgrade to 5.7.1 Chen Qi 2018-10-18 10:29 ` [OE-core] [PATCH 1/2] systemd: upgrade to 239 nick83ola 2018-10-18 10:32 ` nick83ola 2018-10-18 10:55 ` Martin Jansa 2018-10-18 14:29 ` André Draszik 2018-10-19 3:28 ` ChenQi
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.