* [meta-oe][meta-networking][PATCH V2 0/3] ntp updates @ 2012-10-23 16:20 Morgan Little 2012-10-23 16:20 ` [meta-oe][meta-networking][PATCH V2 1/3] ntp: Move from meta-oe to meta-networking Morgan Little ` (2 more replies) 0 siblings, 3 replies; 27+ messages in thread From: Morgan Little @ 2012-10-23 16:20 UTC (permalink / raw) To: openembedded-devel are available in the git repository at: git@github.com:morganlittle/meta-oe.git ntp Morgan Little (3): ntp: Move from meta-oe to meta-networking ntp: Uprev from 4.2.6p3 to 4.2.6p5 ntp: Clean up recipes .../recipes-support/ntp/files/ntp | 0 .../ntp/files/ntp-4.2.4_p6-nano.patch | 0 .../recipes-support/ntp/files/ntp.conf | 0 .../recipes-support/ntp/files/ntpd | 0 .../recipes-support/ntp/files/ntpdate | 0 .../recipes-support/ntp/files/tickadj.c.patch | 0 .../recipes-support/ntp/ntp-ssl_4.2.6p5.bb | 10 +++ meta-networking/recipes-support/ntp/ntp.inc | 74 ++++++++++++++++++++ meta-networking/recipes-support/ntp/ntp_4.2.6p5.bb | 4 + meta-oe/recipes-support/ntp/ntp-ssl_4.2.6p3.bb | 11 --- meta-oe/recipes-support/ntp/ntp.inc | 35 --------- meta-oe/recipes-support/ntp/ntp_4.2.6p3.bb | 47 ------------ 12 files changed, 88 insertions(+), 93 deletions(-) rename {meta-oe => meta-networking}/recipes-support/ntp/files/ntp (100%) rename {meta-oe => meta-networking}/recipes-support/ntp/files/ntp-4.2.4_p6-nano.patch (100%) rename {meta-oe => meta-networking}/recipes-support/ntp/files/ntp.conf (100%) rename {meta-oe => meta-networking}/recipes-support/ntp/files/ntpd (100%) rename {meta-oe => meta-networking}/recipes-support/ntp/files/ntpdate (100%) rename {meta-oe => meta-networking}/recipes-support/ntp/files/tickadj.c.patch (100%) create mode 100644 meta-networking/recipes-support/ntp/ntp-ssl_4.2.6p5.bb create mode 100644 meta-networking/recipes-support/ntp/ntp.inc create mode 100644 meta-networking/recipes-support/ntp/ntp_4.2.6p5.bb delete mode 100644 meta-oe/recipes-support/ntp/ntp-ssl_4.2.6p3.bb delete mode 100644 meta-oe/recipes-support/ntp/ntp.inc delete mode 100644 meta-oe/recipes-support/ntp/ntp_4.2.6p3.bb ^ permalink raw reply [flat|nested] 27+ messages in thread
* [meta-oe][meta-networking][PATCH V2 1/3] ntp: Move from meta-oe to meta-networking 2012-10-23 16:20 [meta-oe][meta-networking][PATCH V2 0/3] ntp updates Morgan Little @ 2012-10-23 16:20 ` Morgan Little 2012-10-23 16:20 ` [meta-oe][meta-networking][PATCH V2 2/3] ntp: Uprev from 4.2.6p3 to 4.2.6p5 Morgan Little 2012-10-23 16:20 ` [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes Morgan Little 2 siblings, 0 replies; 27+ messages in thread From: Morgan Little @ 2012-10-23 16:20 UTC (permalink / raw) To: openembedded-devel Signed-off-by: Morgan Little <morgan.little@windriver.com> --- meta-networking/recipes-support/ntp/files/ntp | 31 ++++++++++ .../ntp/files/ntp-4.2.4_p6-nano.patch | 17 +++++ meta-networking/recipes-support/ntp/files/ntp.conf | 14 +++++ meta-networking/recipes-support/ntp/files/ntpd | 62 ++++++++++++++++++++ meta-networking/recipes-support/ntp/files/ntpdate | 49 +++++++++++++++ .../recipes-support/ntp/files/tickadj.c.patch | 32 ++++++++++ .../recipes-support/ntp/ntp-ssl_4.2.6p3.bb | 11 ++++ meta-networking/recipes-support/ntp/ntp.inc | 35 +++++++++++ meta-networking/recipes-support/ntp/ntp_4.2.6p3.bb | 47 +++++++++++++++ meta-oe/recipes-support/ntp/files/ntp | 31 ---------- .../ntp/files/ntp-4.2.4_p6-nano.patch | 17 ----- meta-oe/recipes-support/ntp/files/ntp.conf | 14 ----- meta-oe/recipes-support/ntp/files/ntpd | 62 -------------------- meta-oe/recipes-support/ntp/files/ntpdate | 49 --------------- meta-oe/recipes-support/ntp/files/tickadj.c.patch | 32 ---------- meta-oe/recipes-support/ntp/ntp-ssl_4.2.6p3.bb | 11 ---- meta-oe/recipes-support/ntp/ntp.inc | 35 ----------- meta-oe/recipes-support/ntp/ntp_4.2.6p3.bb | 47 --------------- 18 files changed, 298 insertions(+), 298 deletions(-) create mode 100755 meta-networking/recipes-support/ntp/files/ntp create mode 100644 meta-networking/recipes-support/ntp/files/ntp-4.2.4_p6-nano.patch create mode 100644 meta-networking/recipes-support/ntp/files/ntp.conf create mode 100755 meta-networking/recipes-support/ntp/files/ntpd create mode 100755 meta-networking/recipes-support/ntp/files/ntpdate create mode 100644 meta-networking/recipes-support/ntp/files/tickadj.c.patch create mode 100644 meta-networking/recipes-support/ntp/ntp-ssl_4.2.6p3.bb create mode 100644 meta-networking/recipes-support/ntp/ntp.inc create mode 100644 meta-networking/recipes-support/ntp/ntp_4.2.6p3.bb delete mode 100755 meta-oe/recipes-support/ntp/files/ntp delete mode 100644 meta-oe/recipes-support/ntp/files/ntp-4.2.4_p6-nano.patch delete mode 100644 meta-oe/recipes-support/ntp/files/ntp.conf delete mode 100755 meta-oe/recipes-support/ntp/files/ntpd delete mode 100755 meta-oe/recipes-support/ntp/files/ntpdate delete mode 100644 meta-oe/recipes-support/ntp/files/tickadj.c.patch delete mode 100644 meta-oe/recipes-support/ntp/ntp-ssl_4.2.6p3.bb delete mode 100644 meta-oe/recipes-support/ntp/ntp.inc delete mode 100644 meta-oe/recipes-support/ntp/ntp_4.2.6p3.bb diff --git a/meta-networking/recipes-support/ntp/files/ntp b/meta-networking/recipes-support/ntp/files/ntp new file mode 100755 index 0000000..e91a528 --- /dev/null +++ b/meta-networking/recipes-support/ntp/files/ntp @@ -0,0 +1,31 @@ +#! /bin/sh + +FLAGS="defaults 23" + +test -f /usr/bin/ntpd || exit 0 + +case "$1" in + start) + echo -n "Starting NTP server: ntpd" + start-stop-daemon --start --quiet --exec /usr/bin/ntpd + echo "." + ;; + stop) + echo -n "Stopping NTP server: ntpd" + start-stop-daemon --stop --quiet --exec /usr/bin/ntpd + echo "." + ;; + restart|force-reload) + echo -n "Restarting NTP server: ntpd... " + start-stop-daemon --stop --quiet --exec /usr/bin/ntpd + sleep 2 + start-stop-daemon --start --quiet --exec /usr/bin/ntpd + echo "done." + ;; + *) + echo "Usage: /etc/init.d/ntp {start|stop|restart|force-reload}" + exit 1 + ;; +esac + +exit 0 diff --git a/meta-networking/recipes-support/ntp/files/ntp-4.2.4_p6-nano.patch b/meta-networking/recipes-support/ntp/files/ntp-4.2.4_p6-nano.patch new file mode 100644 index 0000000..cb1e2f7 --- /dev/null +++ b/meta-networking/recipes-support/ntp/files/ntp-4.2.4_p6-nano.patch @@ -0,0 +1,17 @@ +--- a/include/ntp_syscall.h.orig 2009-05-19 16:44:55.048156467 -0400 ++++ b/include/ntp_syscall.h 2009-05-19 16:46:19.293323686 -0400 +@@ -14,6 +14,14 @@ + # include <sys/timex.h> + #endif + ++#if defined(ADJ_NANO) && !defined(MOD_NANO) ++#define MOD_NANO ADJ_NANO ++#endif ++ ++#if defined(ADJ_TAI) && !defined(MOD_TAI) ++#define MOD_TAI ADJ_TAI ++#endif ++ + #ifndef NTP_SYSCALLS_LIBC + #ifdef NTP_SYSCALLS_STD + # define ntp_adjtime(t) syscall(SYS_ntp_adjtime, (t)) diff --git a/meta-networking/recipes-support/ntp/files/ntp.conf b/meta-networking/recipes-support/ntp/files/ntp.conf new file mode 100644 index 0000000..bf52440 --- /dev/null +++ b/meta-networking/recipes-support/ntp/files/ntp.conf @@ -0,0 +1,14 @@ +# This is the most basic ntp configuration file +# The driftfile must remain in a place specific to this +# machine - it records the machine specific clock error +driftfile /etc/ntp.drift +# This obtains a random server which will be close +# (in IP terms) to the machine. Add other servers +# as required, or change this. +server pool.ntp.org +# Using local hardware clock as fallback +# Disable this when using ntpd -q -g -x as ntpdate or it will sync to itself +server 127.127.1.0 +fudge 127.127.1.0 stratum 14 +# Defining a default security setting +restrict default diff --git a/meta-networking/recipes-support/ntp/files/ntpd b/meta-networking/recipes-support/ntp/files/ntpd new file mode 100755 index 0000000..ae50f13 --- /dev/null +++ b/meta-networking/recipes-support/ntp/files/ntpd @@ -0,0 +1,62 @@ +#! /bin/sh +# +# ntpd init.d script for ntpdc from ntp.isc.org +test -x /usr/bin/ntpd -a -r /etc/ntp.conf || exit 0 +# rcS contains TICKADJ +test -r /etc/default/rcS && . /etc/default/rcS + +# Functions to do individual actions +settick(){ + # If TICKADJ is set we *must* adjust it before we start, because the + # driftfile relies on the correct setting + test -n "$TICKADJ" -a -x /usr/bin/tickadj && { + echo -n "Setting tick to $TICKADJ: " + /usr/bin/tickadj "$TICKADJ" + echo "done" + } +} +startdaemon(){ + # The -g option allows ntpd to step the time to correct it just + # once. The daemon will exit if the clock drifts too much after + # this. If ntpd seems to disappear after a while assume TICKADJ + # above is set to a totally incorrect value. + echo -n "Starting ntpd: " + start-stop-daemon --start -x /usr/bin/ntpd -- -p /var/run/ntp.pid "$@" + echo "done" +} +stopdaemon(){ + echo -n "Stopping ntpd: " + start-stop-daemon --stop -p /var/run/ntp.pid + echo "done" +} + +case "$1" in + start) + settick + startdaemon -g + ;; + stop) + stopdaemon + ;; + force-reload) + stopdaemon + settick + startdaemon -g + ;; + restart) + # Don't reset the tick here + stopdaemon + startdaemon -g + ;; + reload) + # Must do this by hand, but don't do -g + stopdaemon + startdaemon + ;; + *) + echo "Usage: ntpd { start | stop | restart | reload }" >&2 + exit 1 + ;; +esac + +exit 0 diff --git a/meta-networking/recipes-support/ntp/files/ntpdate b/meta-networking/recipes-support/ntp/files/ntpdate new file mode 100755 index 0000000..784b029 --- /dev/null +++ b/meta-networking/recipes-support/ntp/files/ntpdate @@ -0,0 +1,49 @@ +#!/bin/sh + +PATH=/sbin:/bin:/usr/bin + +test -x /usr/bin/ntpdate || exit 0 + +if test -f /etc/default/ntpdate ; then +. /etc/default/ntpdate +else +NTPSERVERS="pool.ntp.org" +fi + +test -n "$NTPSERVERS" || exit 0 + +# This is a heuristic: The idea is that if a static interface is brought +# up, that is a major event, and we can put in some extra effort to fix +# the system time. Feel free to change this, especially if you regularly +# bring up new network interfaces. +if [ "$METHOD" = static ]; then + OPTS="-b" +fi + +if [ "$METHOD" = loopback ]; then + exit 0 +fi + +( + +LOCKFILE=/var/lock/ntpdate + +# Avoid running more than one at a time +if [ -x /usr/bin/lockfile-create ]; then + lockfile-create $LOCKFILE + lockfile-touch $LOCKFILE & + LOCKTOUCHPID="$!" +fi + +if /usr/bin/ntpdate -s $OPTS $NTPSERVERS 2>/dev/null; then + if [ "$UPDATE_HWCLOCK" = "yes" ]; then + hwclock --systohc || : + fi +fi + +if [ -x /usr/bin/lockfile-create ] ; then + kill $LOCKTOUCHPID + lockfile-remove $LOCKFILE +fi + +) & diff --git a/meta-networking/recipes-support/ntp/files/tickadj.c.patch b/meta-networking/recipes-support/ntp/files/tickadj.c.patch new file mode 100644 index 0000000..9ef9de9 --- /dev/null +++ b/meta-networking/recipes-support/ntp/files/tickadj.c.patch @@ -0,0 +1,32 @@ +Index: ntp-4.2.2p3-r0/ntp-4.2.2p3/util/tickadj.c +=================================================================== +--- ntp-4.2.2p3/util/tickadj.c 2004-02-25 06:58:33.000000000 +0100 ++++ ntp-4.2.2p3/util/tickadj.c 2007-07-07 01:00:54.000000000 +0200 +@@ -21,7 +21,8 @@ + # include <unistd.h> + #endif /* HAVE_UNISTD_H */ + +-#ifdef HAVE___ADJTIMEX /* Linux */ ++/* proper handling here has been moved to upstream ntp bugzilla */ ++#ifdef linux + + #include <sys/timex.h> + struct timex txc; +@@ -91,7 +92,7 @@ + } + + if (!errflg) { +- if (__adjtimex(&txc) < 0) ++ if (adjtimex(&txc) < 0) + perror("adjtimex"); + else if (!quiet) + printf("tick = %ld\ntick_adj = %d\n", +@@ -146,7 +147,7 @@ + #endif + } + +- if (__adjtimex(&txc) < 0) ++ if (adjtimex(&txc) < 0) + { + perror("adjtimex"); + } diff --git a/meta-networking/recipes-support/ntp/ntp-ssl_4.2.6p3.bb b/meta-networking/recipes-support/ntp/ntp-ssl_4.2.6p3.bb new file mode 100644 index 0000000..a158990 --- /dev/null +++ b/meta-networking/recipes-support/ntp/ntp-ssl_4.2.6p3.bb @@ -0,0 +1,11 @@ +require ntp_${PV}.bb +DEPENDS = "openssl" + +S = "${WORKDIR}/ntp-${PV}" + +EXTRA_OECONF = "--with-openssl-libdir=${STAGING_LIBDIR} \ + --with-openssl-incdir=${STAGING_INCDIR}/openssl" + + +SRC_URI[md5sum] = "98e16c7aa4ecd4c004b51bff18962e95" +SRC_URI[sha256sum] = "9f4a5271a285d390c9225e3ea28f70049ea377d30fc6de4659007cfff278671a" diff --git a/meta-networking/recipes-support/ntp/ntp.inc b/meta-networking/recipes-support/ntp/ntp.inc new file mode 100644 index 0000000..1d740f0 --- /dev/null +++ b/meta-networking/recipes-support/ntp/ntp.inc @@ -0,0 +1,35 @@ +DESCRIPTION = "The Network Time Protocol (NTP) is used to \ +synchronize the time of a computer client or server to \ +another server or reference time source, such as a radio \ +or satellite receiver or modem." +HOMEPAGE = "http://ntp.isc.org/bin/view/Main/WebHome" +SECTION = "console/network" +LICENSE = "ntp" +LIC_FILES_CHKSUM = "file://COPYRIGHT;md5=fea4b50c33b18c2194b4b1c9ca512670" +RSUGGESTS_${PN} = "iana-etc" + +SRC_URI = "http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/${P}.tar.gz \ + file://ipv6only-workaround.patch \ + file://ntpd \ + file://ntp.conf \ + file://ntpdate \ + file://ntpd.service \ +" + +inherit autotools update-rc.d + +INITSCRIPT_NAME = "ntpd" +# No dependencies, so just go in at the standard level (20) +INITSCRIPT_PARAMS = "defaults" + +# The ac_cv_header_readline_history is to stop ntpdc depending on either +# readline or curses +EXTRA_OECONF = "--without-openssl --without-crypto ac_cv_header_readline_history_h=no" +CFLAGS_append = " -DPTYS_ARE_GETPT -DPTYS_ARE_SEARCHED" + +PACKAGES += "ntpdate ${PN}-bin ${PN}-tickadj ${PN}-utils" +# NOTE: you don't need ntpdate, use "ntpd -q -g -x" +# or the ntpdate systemd service + +# This should use rc.update +FILES_ntpdate = "${bindir}/ntpdate ${sysconfdir}/init.d/ntpdate" diff --git a/meta-networking/recipes-support/ntp/ntp_4.2.6p3.bb b/meta-networking/recipes-support/ntp/ntp_4.2.6p3.bb new file mode 100644 index 0000000..89a272a --- /dev/null +++ b/meta-networking/recipes-support/ntp/ntp_4.2.6p3.bb @@ -0,0 +1,47 @@ +require ntp.inc + +PR = "r6" + +SRC_URI = "http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/ntp-${PV}.tar.gz \ + file://tickadj.c.patch \ + file://ntp-4.2.4_p6-nano.patch \ + file://ntpd \ + file://ntp.conf \ + file://ntpdate \ +" + +SRC_URI[md5sum] = "59876a9009b098ff59767ee45a88ebd2" +SRC_URI[sha256sum] = "6e84d4ddfa14b911c3ed88463af10867e1fa9b287e7b34d8a02e78be85a7c40e" + +EXTRA_OECONF += " --with-net-snmp-config=no --without-ntpsnmpd" + +do_install_append() { + install -d ${D}/${sysconfdir}/init.d + install -m 644 ${WORKDIR}/ntp.conf ${D}/${sysconfdir} + install -m 755 ${WORKDIR}/ntpd ${D}/${sysconfdir}/init.d + install -d ${D}/${sysconfdir}/network/if-up.d + install -m 755 ${WORKDIR}/ntpdate ${D}/${sysconfdir}/network/if-up.d +} + +FILES_${PN}-bin = "${bindir}/ntp-wait ${bindir}/ntpdc ${bindir}/ntpq ${bindir}/ntptime ${bindir}/ntptrace" +FILES_${PN} = "${bindir}/ntpd ${sysconfdir}/ntp.conf ${sysconfdir}/init.d/ntpd" +FILES_${PN}-tickadj = "${bindir}/tickadj" +FILES_ntp-utils = "${bindir}/*" +FILES_ntpdate = "${bindir}/ntpdate ${sysconfdir}/network/if-up.d/ntpdate" + +# ntp originally includes tickadj. It's split off for inclusion in small firmware images on platforms +# with wonky clocks (e.g. OpenSlug) +RDEPENDS_${PN} = "${PN}-tickadj" + +pkg_postinst_ntpdate() { +if test "x$D" != "x"; then + exit 1 +else + if ! grep -q -s ntpdate /var/spool/cron/root; then + echo "adding crontab" + test -d /var/spool/cron || mkdir -p /var/spool/cron + echo "30 * * * * /usr/bin/ntpdate -b -s -u pool.ntp.org" >> /var/spool/cron/root + fi +fi +} + diff --git a/meta-oe/recipes-support/ntp/files/ntp b/meta-oe/recipes-support/ntp/files/ntp deleted file mode 100755 index e91a528..0000000 --- a/meta-oe/recipes-support/ntp/files/ntp +++ /dev/null @@ -1,31 +0,0 @@ -#! /bin/sh - -FLAGS="defaults 23" - -test -f /usr/bin/ntpd || exit 0 - -case "$1" in - start) - echo -n "Starting NTP server: ntpd" - start-stop-daemon --start --quiet --exec /usr/bin/ntpd - echo "." - ;; - stop) - echo -n "Stopping NTP server: ntpd" - start-stop-daemon --stop --quiet --exec /usr/bin/ntpd - echo "." - ;; - restart|force-reload) - echo -n "Restarting NTP server: ntpd... " - start-stop-daemon --stop --quiet --exec /usr/bin/ntpd - sleep 2 - start-stop-daemon --start --quiet --exec /usr/bin/ntpd - echo "done." - ;; - *) - echo "Usage: /etc/init.d/ntp {start|stop|restart|force-reload}" - exit 1 - ;; -esac - -exit 0 diff --git a/meta-oe/recipes-support/ntp/files/ntp-4.2.4_p6-nano.patch b/meta-oe/recipes-support/ntp/files/ntp-4.2.4_p6-nano.patch deleted file mode 100644 index cb1e2f7..0000000 --- a/meta-oe/recipes-support/ntp/files/ntp-4.2.4_p6-nano.patch +++ /dev/null @@ -1,17 +0,0 @@ ---- a/include/ntp_syscall.h.orig 2009-05-19 16:44:55.048156467 -0400 -+++ b/include/ntp_syscall.h 2009-05-19 16:46:19.293323686 -0400 -@@ -14,6 +14,14 @@ - # include <sys/timex.h> - #endif - -+#if defined(ADJ_NANO) && !defined(MOD_NANO) -+#define MOD_NANO ADJ_NANO -+#endif -+ -+#if defined(ADJ_TAI) && !defined(MOD_TAI) -+#define MOD_TAI ADJ_TAI -+#endif -+ - #ifndef NTP_SYSCALLS_LIBC - #ifdef NTP_SYSCALLS_STD - # define ntp_adjtime(t) syscall(SYS_ntp_adjtime, (t)) diff --git a/meta-oe/recipes-support/ntp/files/ntp.conf b/meta-oe/recipes-support/ntp/files/ntp.conf deleted file mode 100644 index bf52440..0000000 --- a/meta-oe/recipes-support/ntp/files/ntp.conf +++ /dev/null @@ -1,14 +0,0 @@ -# This is the most basic ntp configuration file -# The driftfile must remain in a place specific to this -# machine - it records the machine specific clock error -driftfile /etc/ntp.drift -# This obtains a random server which will be close -# (in IP terms) to the machine. Add other servers -# as required, or change this. -server pool.ntp.org -# Using local hardware clock as fallback -# Disable this when using ntpd -q -g -x as ntpdate or it will sync to itself -server 127.127.1.0 -fudge 127.127.1.0 stratum 14 -# Defining a default security setting -restrict default diff --git a/meta-oe/recipes-support/ntp/files/ntpd b/meta-oe/recipes-support/ntp/files/ntpd deleted file mode 100755 index ae50f13..0000000 --- a/meta-oe/recipes-support/ntp/files/ntpd +++ /dev/null @@ -1,62 +0,0 @@ -#! /bin/sh -# -# ntpd init.d script for ntpdc from ntp.isc.org -test -x /usr/bin/ntpd -a -r /etc/ntp.conf || exit 0 -# rcS contains TICKADJ -test -r /etc/default/rcS && . /etc/default/rcS - -# Functions to do individual actions -settick(){ - # If TICKADJ is set we *must* adjust it before we start, because the - # driftfile relies on the correct setting - test -n "$TICKADJ" -a -x /usr/bin/tickadj && { - echo -n "Setting tick to $TICKADJ: " - /usr/bin/tickadj "$TICKADJ" - echo "done" - } -} -startdaemon(){ - # The -g option allows ntpd to step the time to correct it just - # once. The daemon will exit if the clock drifts too much after - # this. If ntpd seems to disappear after a while assume TICKADJ - # above is set to a totally incorrect value. - echo -n "Starting ntpd: " - start-stop-daemon --start -x /usr/bin/ntpd -- -p /var/run/ntp.pid "$@" - echo "done" -} -stopdaemon(){ - echo -n "Stopping ntpd: " - start-stop-daemon --stop -p /var/run/ntp.pid - echo "done" -} - -case "$1" in - start) - settick - startdaemon -g - ;; - stop) - stopdaemon - ;; - force-reload) - stopdaemon - settick - startdaemon -g - ;; - restart) - # Don't reset the tick here - stopdaemon - startdaemon -g - ;; - reload) - # Must do this by hand, but don't do -g - stopdaemon - startdaemon - ;; - *) - echo "Usage: ntpd { start | stop | restart | reload }" >&2 - exit 1 - ;; -esac - -exit 0 diff --git a/meta-oe/recipes-support/ntp/files/ntpdate b/meta-oe/recipes-support/ntp/files/ntpdate deleted file mode 100755 index 784b029..0000000 --- a/meta-oe/recipes-support/ntp/files/ntpdate +++ /dev/null @@ -1,49 +0,0 @@ -#!/bin/sh - -PATH=/sbin:/bin:/usr/bin - -test -x /usr/bin/ntpdate || exit 0 - -if test -f /etc/default/ntpdate ; then -. /etc/default/ntpdate -else -NTPSERVERS="pool.ntp.org" -fi - -test -n "$NTPSERVERS" || exit 0 - -# This is a heuristic: The idea is that if a static interface is brought -# up, that is a major event, and we can put in some extra effort to fix -# the system time. Feel free to change this, especially if you regularly -# bring up new network interfaces. -if [ "$METHOD" = static ]; then - OPTS="-b" -fi - -if [ "$METHOD" = loopback ]; then - exit 0 -fi - -( - -LOCKFILE=/var/lock/ntpdate - -# Avoid running more than one at a time -if [ -x /usr/bin/lockfile-create ]; then - lockfile-create $LOCKFILE - lockfile-touch $LOCKFILE & - LOCKTOUCHPID="$!" -fi - -if /usr/bin/ntpdate -s $OPTS $NTPSERVERS 2>/dev/null; then - if [ "$UPDATE_HWCLOCK" = "yes" ]; then - hwclock --systohc || : - fi -fi - -if [ -x /usr/bin/lockfile-create ] ; then - kill $LOCKTOUCHPID - lockfile-remove $LOCKFILE -fi - -) & diff --git a/meta-oe/recipes-support/ntp/files/tickadj.c.patch b/meta-oe/recipes-support/ntp/files/tickadj.c.patch deleted file mode 100644 index 9ef9de9..0000000 --- a/meta-oe/recipes-support/ntp/files/tickadj.c.patch +++ /dev/null @@ -1,32 +0,0 @@ -Index: ntp-4.2.2p3-r0/ntp-4.2.2p3/util/tickadj.c -=================================================================== ---- ntp-4.2.2p3/util/tickadj.c 2004-02-25 06:58:33.000000000 +0100 -+++ ntp-4.2.2p3/util/tickadj.c 2007-07-07 01:00:54.000000000 +0200 -@@ -21,7 +21,8 @@ - # include <unistd.h> - #endif /* HAVE_UNISTD_H */ - --#ifdef HAVE___ADJTIMEX /* Linux */ -+/* proper handling here has been moved to upstream ntp bugzilla */ -+#ifdef linux - - #include <sys/timex.h> - struct timex txc; -@@ -91,7 +92,7 @@ - } - - if (!errflg) { -- if (__adjtimex(&txc) < 0) -+ if (adjtimex(&txc) < 0) - perror("adjtimex"); - else if (!quiet) - printf("tick = %ld\ntick_adj = %d\n", -@@ -146,7 +147,7 @@ - #endif - } - -- if (__adjtimex(&txc) < 0) -+ if (adjtimex(&txc) < 0) - { - perror("adjtimex"); - } diff --git a/meta-oe/recipes-support/ntp/ntp-ssl_4.2.6p3.bb b/meta-oe/recipes-support/ntp/ntp-ssl_4.2.6p3.bb deleted file mode 100644 index a158990..0000000 --- a/meta-oe/recipes-support/ntp/ntp-ssl_4.2.6p3.bb +++ /dev/null @@ -1,11 +0,0 @@ -require ntp_${PV}.bb -DEPENDS = "openssl" - -S = "${WORKDIR}/ntp-${PV}" - -EXTRA_OECONF = "--with-openssl-libdir=${STAGING_LIBDIR} \ - --with-openssl-incdir=${STAGING_INCDIR}/openssl" - - -SRC_URI[md5sum] = "98e16c7aa4ecd4c004b51bff18962e95" -SRC_URI[sha256sum] = "9f4a5271a285d390c9225e3ea28f70049ea377d30fc6de4659007cfff278671a" diff --git a/meta-oe/recipes-support/ntp/ntp.inc b/meta-oe/recipes-support/ntp/ntp.inc deleted file mode 100644 index 1d740f0..0000000 --- a/meta-oe/recipes-support/ntp/ntp.inc +++ /dev/null @@ -1,35 +0,0 @@ -DESCRIPTION = "The Network Time Protocol (NTP) is used to \ -synchronize the time of a computer client or server to \ -another server or reference time source, such as a radio \ -or satellite receiver or modem." -HOMEPAGE = "http://ntp.isc.org/bin/view/Main/WebHome" -SECTION = "console/network" -LICENSE = "ntp" -LIC_FILES_CHKSUM = "file://COPYRIGHT;md5=fea4b50c33b18c2194b4b1c9ca512670" -RSUGGESTS_${PN} = "iana-etc" - -SRC_URI = "http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/${P}.tar.gz \ - file://ipv6only-workaround.patch \ - file://ntpd \ - file://ntp.conf \ - file://ntpdate \ - file://ntpd.service \ -" - -inherit autotools update-rc.d - -INITSCRIPT_NAME = "ntpd" -# No dependencies, so just go in at the standard level (20) -INITSCRIPT_PARAMS = "defaults" - -# The ac_cv_header_readline_history is to stop ntpdc depending on either -# readline or curses -EXTRA_OECONF = "--without-openssl --without-crypto ac_cv_header_readline_history_h=no" -CFLAGS_append = " -DPTYS_ARE_GETPT -DPTYS_ARE_SEARCHED" - -PACKAGES += "ntpdate ${PN}-bin ${PN}-tickadj ${PN}-utils" -# NOTE: you don't need ntpdate, use "ntpd -q -g -x" -# or the ntpdate systemd service - -# This should use rc.update -FILES_ntpdate = "${bindir}/ntpdate ${sysconfdir}/init.d/ntpdate" diff --git a/meta-oe/recipes-support/ntp/ntp_4.2.6p3.bb b/meta-oe/recipes-support/ntp/ntp_4.2.6p3.bb deleted file mode 100644 index 89a272a..0000000 --- a/meta-oe/recipes-support/ntp/ntp_4.2.6p3.bb +++ /dev/null @@ -1,47 +0,0 @@ -require ntp.inc - -PR = "r6" - -SRC_URI = "http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/ntp-${PV}.tar.gz \ - file://tickadj.c.patch \ - file://ntp-4.2.4_p6-nano.patch \ - file://ntpd \ - file://ntp.conf \ - file://ntpdate \ -" - -SRC_URI[md5sum] = "59876a9009b098ff59767ee45a88ebd2" -SRC_URI[sha256sum] = "6e84d4ddfa14b911c3ed88463af10867e1fa9b287e7b34d8a02e78be85a7c40e" - -EXTRA_OECONF += " --with-net-snmp-config=no --without-ntpsnmpd" - -do_install_append() { - install -d ${D}/${sysconfdir}/init.d - install -m 644 ${WORKDIR}/ntp.conf ${D}/${sysconfdir} - install -m 755 ${WORKDIR}/ntpd ${D}/${sysconfdir}/init.d - install -d ${D}/${sysconfdir}/network/if-up.d - install -m 755 ${WORKDIR}/ntpdate ${D}/${sysconfdir}/network/if-up.d -} - -FILES_${PN}-bin = "${bindir}/ntp-wait ${bindir}/ntpdc ${bindir}/ntpq ${bindir}/ntptime ${bindir}/ntptrace" -FILES_${PN} = "${bindir}/ntpd ${sysconfdir}/ntp.conf ${sysconfdir}/init.d/ntpd" -FILES_${PN}-tickadj = "${bindir}/tickadj" -FILES_ntp-utils = "${bindir}/*" -FILES_ntpdate = "${bindir}/ntpdate ${sysconfdir}/network/if-up.d/ntpdate" - -# ntp originally includes tickadj. It's split off for inclusion in small firmware images on platforms -# with wonky clocks (e.g. OpenSlug) -RDEPENDS_${PN} = "${PN}-tickadj" - -pkg_postinst_ntpdate() { -if test "x$D" != "x"; then - exit 1 -else - if ! grep -q -s ntpdate /var/spool/cron/root; then - echo "adding crontab" - test -d /var/spool/cron || mkdir -p /var/spool/cron - echo "30 * * * * /usr/bin/ntpdate -b -s -u pool.ntp.org" >> /var/spool/cron/root - fi -fi -} - -- 1.7.0.4 ^ permalink raw reply related [flat|nested] 27+ messages in thread
* [meta-oe][meta-networking][PATCH V2 2/3] ntp: Uprev from 4.2.6p3 to 4.2.6p5 2012-10-23 16:20 [meta-oe][meta-networking][PATCH V2 0/3] ntp updates Morgan Little 2012-10-23 16:20 ` [meta-oe][meta-networking][PATCH V2 1/3] ntp: Move from meta-oe to meta-networking Morgan Little @ 2012-10-23 16:20 ` Morgan Little 2012-10-23 16:20 ` [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes Morgan Little 2 siblings, 0 replies; 27+ messages in thread From: Morgan Little @ 2012-10-23 16:20 UTC (permalink / raw) To: openembedded-devel Signed-off-by: Morgan Little <morgan.little@windriver.com> --- .../recipes-support/ntp/ntp-ssl_4.2.6p3.bb | 11 ----- .../recipes-support/ntp/ntp-ssl_4.2.6p5.bb | 11 +++++ meta-networking/recipes-support/ntp/ntp_4.2.6p3.bb | 47 -------------------- meta-networking/recipes-support/ntp/ntp_4.2.6p5.bb | 45 +++++++++++++++++++ 4 files changed, 56 insertions(+), 58 deletions(-) delete mode 100644 meta-networking/recipes-support/ntp/ntp-ssl_4.2.6p3.bb create mode 100644 meta-networking/recipes-support/ntp/ntp-ssl_4.2.6p5.bb delete mode 100644 meta-networking/recipes-support/ntp/ntp_4.2.6p3.bb create mode 100644 meta-networking/recipes-support/ntp/ntp_4.2.6p5.bb diff --git a/meta-networking/recipes-support/ntp/ntp-ssl_4.2.6p3.bb b/meta-networking/recipes-support/ntp/ntp-ssl_4.2.6p3.bb deleted file mode 100644 index a158990..0000000 --- a/meta-networking/recipes-support/ntp/ntp-ssl_4.2.6p3.bb +++ /dev/null @@ -1,11 +0,0 @@ -require ntp_${PV}.bb -DEPENDS = "openssl" - -S = "${WORKDIR}/ntp-${PV}" - -EXTRA_OECONF = "--with-openssl-libdir=${STAGING_LIBDIR} \ - --with-openssl-incdir=${STAGING_INCDIR}/openssl" - - -SRC_URI[md5sum] = "98e16c7aa4ecd4c004b51bff18962e95" -SRC_URI[sha256sum] = "9f4a5271a285d390c9225e3ea28f70049ea377d30fc6de4659007cfff278671a" diff --git a/meta-networking/recipes-support/ntp/ntp-ssl_4.2.6p5.bb b/meta-networking/recipes-support/ntp/ntp-ssl_4.2.6p5.bb new file mode 100644 index 0000000..a158990 --- /dev/null +++ b/meta-networking/recipes-support/ntp/ntp-ssl_4.2.6p5.bb @@ -0,0 +1,11 @@ +require ntp_${PV}.bb +DEPENDS = "openssl" + +S = "${WORKDIR}/ntp-${PV}" + +EXTRA_OECONF = "--with-openssl-libdir=${STAGING_LIBDIR} \ + --with-openssl-incdir=${STAGING_INCDIR}/openssl" + + +SRC_URI[md5sum] = "98e16c7aa4ecd4c004b51bff18962e95" +SRC_URI[sha256sum] = "9f4a5271a285d390c9225e3ea28f70049ea377d30fc6de4659007cfff278671a" diff --git a/meta-networking/recipes-support/ntp/ntp_4.2.6p3.bb b/meta-networking/recipes-support/ntp/ntp_4.2.6p3.bb deleted file mode 100644 index 89a272a..0000000 --- a/meta-networking/recipes-support/ntp/ntp_4.2.6p3.bb +++ /dev/null @@ -1,47 +0,0 @@ -require ntp.inc - -PR = "r6" - -SRC_URI = "http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/ntp-${PV}.tar.gz \ - file://tickadj.c.patch \ - file://ntp-4.2.4_p6-nano.patch \ - file://ntpd \ - file://ntp.conf \ - file://ntpdate \ -" - -SRC_URI[md5sum] = "59876a9009b098ff59767ee45a88ebd2" -SRC_URI[sha256sum] = "6e84d4ddfa14b911c3ed88463af10867e1fa9b287e7b34d8a02e78be85a7c40e" - -EXTRA_OECONF += " --with-net-snmp-config=no --without-ntpsnmpd" - -do_install_append() { - install -d ${D}/${sysconfdir}/init.d - install -m 644 ${WORKDIR}/ntp.conf ${D}/${sysconfdir} - install -m 755 ${WORKDIR}/ntpd ${D}/${sysconfdir}/init.d - install -d ${D}/${sysconfdir}/network/if-up.d - install -m 755 ${WORKDIR}/ntpdate ${D}/${sysconfdir}/network/if-up.d -} - -FILES_${PN}-bin = "${bindir}/ntp-wait ${bindir}/ntpdc ${bindir}/ntpq ${bindir}/ntptime ${bindir}/ntptrace" -FILES_${PN} = "${bindir}/ntpd ${sysconfdir}/ntp.conf ${sysconfdir}/init.d/ntpd" -FILES_${PN}-tickadj = "${bindir}/tickadj" -FILES_ntp-utils = "${bindir}/*" -FILES_ntpdate = "${bindir}/ntpdate ${sysconfdir}/network/if-up.d/ntpdate" - -# ntp originally includes tickadj. It's split off for inclusion in small firmware images on platforms -# with wonky clocks (e.g. OpenSlug) -RDEPENDS_${PN} = "${PN}-tickadj" - -pkg_postinst_ntpdate() { -if test "x$D" != "x"; then - exit 1 -else - if ! grep -q -s ntpdate /var/spool/cron/root; then - echo "adding crontab" - test -d /var/spool/cron || mkdir -p /var/spool/cron - echo "30 * * * * /usr/bin/ntpdate -b -s -u pool.ntp.org" >> /var/spool/cron/root - fi -fi -} - diff --git a/meta-networking/recipes-support/ntp/ntp_4.2.6p5.bb b/meta-networking/recipes-support/ntp/ntp_4.2.6p5.bb new file mode 100644 index 0000000..f7c5b68 --- /dev/null +++ b/meta-networking/recipes-support/ntp/ntp_4.2.6p5.bb @@ -0,0 +1,45 @@ +require ntp.inc + +SRC_URI = "http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/ntp-${PV}.tar.gz \ + file://tickadj.c.patch \ + file://ntp-4.2.4_p6-nano.patch \ + file://ntpd \ + file://ntp.conf \ + file://ntpdate \ +" + +SRC_URI[md5sum] = "59876a9009b098ff59767ee45a88ebd2" +SRC_URI[sha256sum] = "6e84d4ddfa14b911c3ed88463af10867e1fa9b287e7b34d8a02e78be85a7c40e" + +EXTRA_OECONF += " --with-net-snmp-config=no --without-ntpsnmpd" + +do_install_append() { + install -d ${D}/${sysconfdir}/init.d + install -m 644 ${WORKDIR}/ntp.conf ${D}/${sysconfdir} + install -m 755 ${WORKDIR}/ntpd ${D}/${sysconfdir}/init.d + install -d ${D}/${sysconfdir}/network/if-up.d + install -m 755 ${WORKDIR}/ntpdate ${D}/${sysconfdir}/network/if-up.d +} + +FILES_${PN}-bin = "${bindir}/ntp-wait ${bindir}/ntpdc ${bindir}/ntpq ${bindir}/ntptime ${bindir}/ntptrace" +FILES_${PN} = "${bindir}/ntpd ${sysconfdir}/ntp.conf ${sysconfdir}/init.d/ntpd" +FILES_${PN}-tickadj = "${bindir}/tickadj" +FILES_ntp-utils = "${bindir}/*" +FILES_ntpdate = "${bindir}/ntpdate ${sysconfdir}/network/if-up.d/ntpdate" + +# ntp originally includes tickadj. It's split off for inclusion in small firmware images on platforms +# with wonky clocks (e.g. OpenSlug) +RDEPENDS_${PN} = "${PN}-tickadj" + +pkg_postinst_ntpdate() { +if test "x$D" != "x"; then + exit 1 +else + if ! grep -q -s ntpdate /var/spool/cron/root; then + echo "adding crontab" + test -d /var/spool/cron || mkdir -p /var/spool/cron + echo "30 * * * * /usr/bin/ntpdate -b -s -u pool.ntp.org" >> /var/spool/cron/root + fi +fi +} + -- 1.7.0.4 ^ permalink raw reply related [flat|nested] 27+ messages in thread
* [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes 2012-10-23 16:20 [meta-oe][meta-networking][PATCH V2 0/3] ntp updates Morgan Little 2012-10-23 16:20 ` [meta-oe][meta-networking][PATCH V2 1/3] ntp: Move from meta-oe to meta-networking Morgan Little 2012-10-23 16:20 ` [meta-oe][meta-networking][PATCH V2 2/3] ntp: Uprev from 4.2.6p3 to 4.2.6p5 Morgan Little @ 2012-10-23 16:20 ` Morgan Little 2012-11-01 1:08 ` Paul Eggleton 2 siblings, 1 reply; 27+ messages in thread From: Morgan Little @ 2012-10-23 16:20 UTC (permalink / raw) To: openembedded-devel Clean up recipes to make them easier to read and to allow ntp-ssl to build * Move common portions to ntp.inc * Update ntp-ssl to require ntp.inc oppose to ntp_${PV}.bb * Change ntp-ssl EXTRA_OECONF to append so it won't try to configure snmp as it will use local paths can cause a error while configuring Signed-off-by: Morgan Little <morgan.little@windriver.com> --- .../recipes-support/ntp/ntp-ssl_4.2.6p5.bb | 11 ++-- meta-networking/recipes-support/ntp/ntp.inc | 49 ++++++++++++++++++-- meta-networking/recipes-support/ntp/ntp_4.2.6p5.bb | 43 +----------------- 3 files changed, 50 insertions(+), 53 deletions(-) diff --git a/meta-networking/recipes-support/ntp/ntp-ssl_4.2.6p5.bb b/meta-networking/recipes-support/ntp/ntp-ssl_4.2.6p5.bb index a158990..e5851ae 100644 --- a/meta-networking/recipes-support/ntp/ntp-ssl_4.2.6p5.bb +++ b/meta-networking/recipes-support/ntp/ntp-ssl_4.2.6p5.bb @@ -1,11 +1,10 @@ -require ntp_${PV}.bb +require ntp.inc DEPENDS = "openssl" S = "${WORKDIR}/ntp-${PV}" -EXTRA_OECONF = "--with-openssl-libdir=${STAGING_LIBDIR} \ - --with-openssl-incdir=${STAGING_INCDIR}/openssl" +EXTRA_OECONF += "--with-openssl-libdir=${STAGING_LIBDIR} \ + --with-openssl-incdir=${STAGING_INCDIR}/openssl \ + --with-crypto" - -SRC_URI[md5sum] = "98e16c7aa4ecd4c004b51bff18962e95" -SRC_URI[sha256sum] = "9f4a5271a285d390c9225e3ea28f70049ea377d30fc6de4659007cfff278671a" +FILES_${PN} += "${bindir}/sntp ${bindir}/ntp-keygen" diff --git a/meta-networking/recipes-support/ntp/ntp.inc b/meta-networking/recipes-support/ntp/ntp.inc index 1d740f0..e2dbdad 100644 --- a/meta-networking/recipes-support/ntp/ntp.inc +++ b/meta-networking/recipes-support/ntp/ntp.inc @@ -8,14 +8,19 @@ LICENSE = "ntp" LIC_FILES_CHKSUM = "file://COPYRIGHT;md5=fea4b50c33b18c2194b4b1c9ca512670" RSUGGESTS_${PN} = "iana-etc" -SRC_URI = "http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/${P}.tar.gz \ - file://ipv6only-workaround.patch \ +INC_PR = "r1" + +SRC_URI = "http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/ntp-${PV}.tar.gz \ + file://tickadj.c.patch \ + file://ntp-4.2.4_p6-nano.patch \ file://ntpd \ file://ntp.conf \ file://ntpdate \ - file://ntpd.service \ " +SRC_URI[md5sum] = "00df80a84ec9528fcfb09498075525bc" +SRC_URI[sha256sum] = "d6ab8371f9d31e594eb6922823d5ccd03dcc4e9d84b0e23ea25ac1405432f91c" + inherit autotools update-rc.d INITSCRIPT_NAME = "ntpd" @@ -24,12 +29,46 @@ INITSCRIPT_PARAMS = "defaults" # The ac_cv_header_readline_history is to stop ntpdc depending on either # readline or curses -EXTRA_OECONF = "--without-openssl --without-crypto ac_cv_header_readline_history_h=no" +EXTRA_OECONF += " --with-net-snmp-config=no --without-ntpsnmpd ac_cv_header_readline_history_h=no" CFLAGS_append = " -DPTYS_ARE_GETPT -DPTYS_ARE_SEARCHED" -PACKAGES += "ntpdate ${PN}-bin ${PN}-tickadj ${PN}-utils" +do_configure(){ + oe_runconf +} + +do_install_append() { + install -d ${D}/${sysconfdir}/init.d + install -m 644 ${WORKDIR}/ntp.conf ${D}/${sysconfdir} + install -m 755 ${WORKDIR}/ntpd ${D}/${sysconfdir}/init.d + install -d ${D}/${sysconfdir}/network/if-up.d + install -m 755 ${WORKDIR}/ntpdate ${D}/${sysconfdir}/network/if-up.d +} + +FILES_${PN}-bin = "${bindir}/ntp-wait ${bindir}/ntpdc ${bindir}/ntpq ${bindir}/ntptime ${bindir}/ntptrace" +FILES_${PN} = "${bindir}/ntpd ${sysconfdir}/ntp.conf ${sysconfdir}/init.d/ntpd ${sbindir} ${libdir}" +FILES_${PN}-tickadj = "${bindir}/tickadj" +FILES_${PN}-utils = "${bindir}/*" +FILES_${PN}-date += "${bindir}/ntpdate ${sysconfdir}/network/if-up.d/ntpdate" + +# ntp originally includes tickadj. It's split off for inclusion in small firmware images on platforms +# with wonky clocks (e.g. OpenSlug) +RDEPENDS_${PN} = "${PN}-tickadj" + +PACKAGES += "${PN}-date ${PN}-bin ${PN}-tickadj ${PN}-utils" # NOTE: you don't need ntpdate, use "ntpd -q -g -x" # or the ntpdate systemd service # This should use rc.update FILES_ntpdate = "${bindir}/ntpdate ${sysconfdir}/init.d/ntpdate" + +pkg_postinst_ntpdate() { +if test "x$D" != "x"; then + exit 1 +else + if ! grep -q -s ntpdate /var/spool/cron/root; then + echo "adding crontab" + test -d /var/spool/cron || mkdir -p /var/spool/cron + echo "30 * * * * /usr/bin/ntpdate -b -s -u pool.ntp.org" >> /var/spool/cron/root + fi +fi +} diff --git a/meta-networking/recipes-support/ntp/ntp_4.2.6p5.bb b/meta-networking/recipes-support/ntp/ntp_4.2.6p5.bb index f7c5b68..175a1b0 100644 --- a/meta-networking/recipes-support/ntp/ntp_4.2.6p5.bb +++ b/meta-networking/recipes-support/ntp/ntp_4.2.6p5.bb @@ -1,45 +1,4 @@ require ntp.inc -SRC_URI = "http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/ntp-${PV}.tar.gz \ - file://tickadj.c.patch \ - file://ntp-4.2.4_p6-nano.patch \ - file://ntpd \ - file://ntp.conf \ - file://ntpdate \ -" - -SRC_URI[md5sum] = "59876a9009b098ff59767ee45a88ebd2" -SRC_URI[sha256sum] = "6e84d4ddfa14b911c3ed88463af10867e1fa9b287e7b34d8a02e78be85a7c40e" - -EXTRA_OECONF += " --with-net-snmp-config=no --without-ntpsnmpd" - -do_install_append() { - install -d ${D}/${sysconfdir}/init.d - install -m 644 ${WORKDIR}/ntp.conf ${D}/${sysconfdir} - install -m 755 ${WORKDIR}/ntpd ${D}/${sysconfdir}/init.d - install -d ${D}/${sysconfdir}/network/if-up.d - install -m 755 ${WORKDIR}/ntpdate ${D}/${sysconfdir}/network/if-up.d -} - -FILES_${PN}-bin = "${bindir}/ntp-wait ${bindir}/ntpdc ${bindir}/ntpq ${bindir}/ntptime ${bindir}/ntptrace" -FILES_${PN} = "${bindir}/ntpd ${sysconfdir}/ntp.conf ${sysconfdir}/init.d/ntpd" -FILES_${PN}-tickadj = "${bindir}/tickadj" -FILES_ntp-utils = "${bindir}/*" -FILES_ntpdate = "${bindir}/ntpdate ${sysconfdir}/network/if-up.d/ntpdate" - -# ntp originally includes tickadj. It's split off for inclusion in small firmware images on platforms -# with wonky clocks (e.g. OpenSlug) -RDEPENDS_${PN} = "${PN}-tickadj" - -pkg_postinst_ntpdate() { -if test "x$D" != "x"; then - exit 1 -else - if ! grep -q -s ntpdate /var/spool/cron/root; then - echo "adding crontab" - test -d /var/spool/cron || mkdir -p /var/spool/cron - echo "30 * * * * /usr/bin/ntpdate -b -s -u pool.ntp.org" >> /var/spool/cron/root - fi -fi -} +EXTRA_OECONF += "--without-openssl --without-crypto" -- 1.7.0.4 ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes 2012-10-23 16:20 ` [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes Morgan Little @ 2012-11-01 1:08 ` Paul Eggleton 2012-11-01 5:50 ` Martin Ertsås 0 siblings, 1 reply; 27+ messages in thread From: Paul Eggleton @ 2012-11-01 1:08 UTC (permalink / raw) To: Morgan Little; +Cc: openembedded-devel On Tuesday 23 October 2012 12:20:20 Morgan Little wrote: > -PACKAGES += "ntpdate ${PN}-bin ${PN}-tickadj ${PN}-utils" ... > +PACKAGES += "${PN}-date ${PN}-bin ${PN}-tickadj ${PN}-utils" I'm not particularly happy with this change. Apart from the fact that it wasn't mentioned in the commit message, it breaks any recipe that depends upon the previous ntpdate package. Could we go back to the old ntpdate name for the package or at the very least provide an RPROVIDES for the old name? I'm happy to submit a patch to do this once there is agreement either way. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes 2012-11-01 1:08 ` Paul Eggleton @ 2012-11-01 5:50 ` Martin Ertsås 2012-11-01 14:31 ` Joe MacDonald 0 siblings, 1 reply; 27+ messages in thread From: Martin Ertsås @ 2012-11-01 5:50 UTC (permalink / raw) To: openembedded-devel On 11/01/12 02:08, Paul Eggleton wrote: > On Tuesday 23 October 2012 12:20:20 Morgan Little wrote: >> -PACKAGES += "ntpdate ${PN}-bin ${PN}-tickadj ${PN}-utils" > ... >> +PACKAGES += "${PN}-date ${PN}-bin ${PN}-tickadj ${PN}-utils" > I'm not particularly happy with this change. Apart from the fact that it > wasn't mentioned in the commit message, it breaks any recipe that depends upon > the previous ntpdate package. Could we go back to the old ntpdate name for the > package or at the very least provide an RPROVIDES for the old name? I'm happy > to submit a patch to do this once there is agreement either way. > > Cheers, > Paul > I agree with you. Also find it kind of strange to change from ntpdate to ntp-date, as the universally known name of that module is ntpdate. Don't really see the rational of changing that to ntp-date in the recipe. - Martin ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes 2012-11-01 5:50 ` Martin Ertsås @ 2012-11-01 14:31 ` Joe MacDonald 2012-11-01 17:09 ` Little, Morgan 0 siblings, 1 reply; 27+ messages in thread From: Joe MacDonald @ 2012-11-01 14:31 UTC (permalink / raw) To: openembedded-devel [-- Attachment #1: Type: text/plain, Size: 1388 bytes --] [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.01 (Thu 06:50) Martin Ertsås wrote: > On 11/01/12 02:08, Paul Eggleton wrote: > >On Tuesday 23 October 2012 12:20:20 Morgan Little wrote: > >>-PACKAGES += "ntpdate ${PN}-bin ${PN}-tickadj ${PN}-utils" > >... > >>+PACKAGES += "${PN}-date ${PN}-bin ${PN}-tickadj ${PN}-utils" > >I'm not particularly happy with this change. Apart from the fact that it > >wasn't mentioned in the commit message, it breaks any recipe that depends upon > >the previous ntpdate package. Could we go back to the old ntpdate name for the > >package or at the very least provide an RPROVIDES for the old name? I'm happy > >to submit a patch to do this once there is agreement either way. > > > >Cheers, > >Paul > > > I agree with you. Also find it kind of strange to change from > ntpdate to ntp-date, as the universally known name of that module is > ntpdate. Don't really see the rational of changing that to ntp-date > in the recipe. Agreed. Though if there's a good reason to rename in ntp-date, that's fine with me, so long as we go with Paul's suggestion of having an RPROVIDES for ntpdate. It's probably best to leave it as ntpdate, though. -- Joe MacDonald, Sr. Member of Technical Staff, Linux Products Group, Wind River direct 613.270.5750 mobile 613.291.7421 fax 613.592.2283 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 205 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes 2012-11-01 14:31 ` Joe MacDonald @ 2012-11-01 17:09 ` Little, Morgan 2012-11-01 17:19 ` Paul Eggleton 0 siblings, 1 reply; 27+ messages in thread From: Little, Morgan @ 2012-11-01 17:09 UTC (permalink / raw) To: openembedded-devel On 11/01/2012 10:31 AM, Joe MacDonald wrote: > [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.01 (Thu 06:50) Martin Ertsås wrote: > >> On 11/01/12 02:08, Paul Eggleton wrote: >>> On Tuesday 23 October 2012 12:20:20 Morgan Little wrote: >>>> -PACKAGES += "ntpdate ${PN}-bin ${PN}-tickadj ${PN}-utils" >>> ... >>>> +PACKAGES += "${PN}-date ${PN}-bin ${PN}-tickadj ${PN}-utils" >>> I'm not particularly happy with this change. Apart from the fact that it >>> wasn't mentioned in the commit message, it breaks any recipe that depends upon >>> the previous ntpdate package. Could we go back to the old ntpdate name for the >>> package or at the very least provide an RPROVIDES for the old name? I'm happy >>> to submit a patch to do this once there is agreement either way. >>> >>> Cheers, >>> Paul >>> >> I agree with you. Also find it kind of strange to change from >> ntpdate to ntp-date, as the universally known name of that module is >> ntpdate. Don't really see the rational of changing that to ntp-date >> in the recipe. > > Agreed. Though if there's a good reason to rename in ntp-date, that's > fine with me, so long as we go with Paul's suggestion of having an > RPROVIDES for ntpdate. It's probably best to leave it as ntpdate, > though. > My rational behind splitting like that is if it is just ntpdate and you try to add ntp-ssl and ntpdate it will use ntp to provide ntpdate. It could be change add RPROVIDES so ntp will provide ntpdate and ntp-ssl provides a uniquely named version. //Morgan > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes 2012-11-01 17:09 ` Little, Morgan @ 2012-11-01 17:19 ` Paul Eggleton 2012-11-01 17:32 ` Joe MacDonald 0 siblings, 1 reply; 27+ messages in thread From: Paul Eggleton @ 2012-11-01 17:19 UTC (permalink / raw) To: Little, Morgan; +Cc: openembedded-devel On Thursday 01 November 2012 17:09:59 Little, Morgan wrote: > My rational behind splitting like that is if it is just ntpdate and you try > to add ntp-ssl and ntpdate it will use ntp to provide ntpdate. It could be > change add RPROVIDES so ntp will provide ntpdate and ntp-ssl provides a > uniquely named version. The ssl version could be ntpdate-ssl if it needs to be unique. I think originally though these recipes weren't intended to be built side-by-side - rather they were mutually exclusive and the distro would make a choice as to which one was built. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes 2012-11-01 17:19 ` Paul Eggleton @ 2012-11-01 17:32 ` Joe MacDonald 2012-11-02 7:00 ` Martin Ertsås 2012-11-02 9:59 ` Paul Eggleton 0 siblings, 2 replies; 27+ messages in thread From: Joe MacDonald @ 2012-11-01 17:32 UTC (permalink / raw) To: openembedded-devel; +Cc: Little, Morgan [-- Attachment #1: Type: text/plain, Size: 1386 bytes --] [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.01 (Thu 17:19) Paul Eggleton wrote: > On Thursday 01 November 2012 17:09:59 Little, Morgan wrote: > > My rational behind splitting like that is if it is just ntpdate and you try > > to add ntp-ssl and ntpdate it will use ntp to provide ntpdate. It could be > > change add RPROVIDES so ntp will provide ntpdate and ntp-ssl provides a > > uniquely named version. > > The ssl version could be ntpdate-ssl if it needs to be unique. I think > originally though these recipes weren't intended to be built side-by-side - > rather they were mutually exclusive and the distro would make a choice as to > which one was built. Hmm, good point. Does it make sense to have both on a system? That is, if you build ntp-ssl does that imply it will only use SSL for communications? If that's not the case (which I suspect it isn't, but I haven't checked myself) then there's not really a strong reason to install both on the same system. Which then seems fine to provide ntpdate-ssl as the alternative. Now that I think about it a bit more, maybe a RPROVIDES is appropriate since ntp and ntpdate are overlapping in a lot of places. -- Joe MacDonald, Sr. Member of Technical Staff, Linux Products Group, Wind River direct 613.270.5750 mobile 613.291.7421 fax 613.592.2283 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 205 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes 2012-11-01 17:32 ` Joe MacDonald @ 2012-11-02 7:00 ` Martin Ertsås 2012-11-02 13:01 ` Joe MacDonald 2012-11-02 9:59 ` Paul Eggleton 1 sibling, 1 reply; 27+ messages in thread From: Martin Ertsås @ 2012-11-02 7:00 UTC (permalink / raw) To: openembedded-devel On 11/01/12 18:32, Joe MacDonald wrote: > [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.01 (Thu 17:19) Paul Eggleton wrote: > >> On Thursday 01 November 2012 17:09:59 Little, Morgan wrote: >>> My rational behind splitting like that is if it is just ntpdate and you try >>> to add ntp-ssl and ntpdate it will use ntp to provide ntpdate. It could be >>> change add RPROVIDES so ntp will provide ntpdate and ntp-ssl provides a >>> uniquely named version. >> The ssl version could be ntpdate-ssl if it needs to be unique. I think >> originally though these recipes weren't intended to be built side-by-side - >> rather they were mutually exclusive and the distro would make a choice as to >> which one was built. > Hmm, good point. > > Does it make sense to have both on a system? That is, if you build > ntp-ssl does that imply it will only use SSL for communications? If > that's not the case (which I suspect it isn't, but I haven't checked > myself) then there's not really a strong reason to install both on the > same system. Which then seems fine to provide ntpdate-ssl as the > alternative. > > Now that I think about it a bit more, maybe a RPROVIDES is appropriate > since ntp and ntpdate are overlapping in a lot of places. > > > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel Are you thinking of ntp providing ntpdate then? In my mind at least, this makes sense, as ntp seems able to do whatever ntpdate does, so I don't really see the rational of having both on the same system. - Martin ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes 2012-11-02 7:00 ` Martin Ertsås @ 2012-11-02 13:01 ` Joe MacDonald 2012-11-02 13:09 ` Martin Ertsås 0 siblings, 1 reply; 27+ messages in thread From: Joe MacDonald @ 2012-11-02 13:01 UTC (permalink / raw) To: openembedded-devel [-- Attachment #1: Type: text/plain, Size: 3139 bytes --] [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.02 (Fri 08:00) Martin Ertsås wrote: > On 11/01/12 18:32, Joe MacDonald wrote: > > [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.01 (Thu 17:19) Paul Eggleton wrote: > > > >> On Thursday 01 November 2012 17:09:59 Little, Morgan wrote: > >>> My rational behind splitting like that is if it is just ntpdate and you try > >>> to add ntp-ssl and ntpdate it will use ntp to provide ntpdate. It could be > >>> change add RPROVIDES so ntp will provide ntpdate and ntp-ssl provides a > >>> uniquely named version. > >> The ssl version could be ntpdate-ssl if it needs to be unique. I think > >> originally though these recipes weren't intended to be built side-by-side - > >> rather they were mutually exclusive and the distro would make a choice as to > >> which one was built. > > Hmm, good point. > > > > Does it make sense to have both on a system? That is, if you build > > ntp-ssl does that imply it will only use SSL for communications? If > > that's not the case (which I suspect it isn't, but I haven't checked > > myself) then there's not really a strong reason to install both on the > > same system. Which then seems fine to provide ntpdate-ssl as the > > alternative. > > > > Now that I think about it a bit more, maybe a RPROVIDES is appropriate > > since ntp and ntpdate are overlapping in a lot of places. > > > > > > > > _______________________________________________ > > Openembedded-devel mailing list > > Openembedded-devel@lists.openembedded.org > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > Are you thinking of ntp providing ntpdate then? In my mind at least, > this makes sense, as ntp seems able to do whatever ntpdate does, so I > don't really see the rational of having both on the same system. Yeah, exactly. The only time I've ever wanted both ntp and ntpdate on the same system at the same time was when I had a system with a clock that was so badly damaged occasionally ntp couldn't recover it and I needed to just do a reset on the time. But I could have even accomplished that with ntp -q. In fact, a quick check of the ntp manpage on my system says: -q Exit the ntpd just after the first time the clock is set. This behavior mimics that of the ntpdate program, which is to be retired. The -g and -x options can be used with this option. Note: The kernel time discipline is disabled with this option. So I'm thinking that ntpdate can be completely replaced with ntp if you're putting that on your system. The obvious fallout would be in any scripts specifically relying on something called 'ntpdate', but it looks to me like the ntp package is already providing an ntpdate binary. Seeing that, it seems to me that ntp/ntp-ssl and ntpdate actually conflict with each other. -- Joe MacDonald, Sr. Member of Technical Staff, Linux Products Group, Wind River direct 613.270.5750 mobile 613.291.7421 fax 613.592.2283 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 205 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes 2012-11-02 13:01 ` Joe MacDonald @ 2012-11-02 13:09 ` Martin Ertsås 2012-11-02 13:14 ` Joe MacDonald 0 siblings, 1 reply; 27+ messages in thread From: Martin Ertsås @ 2012-11-02 13:09 UTC (permalink / raw) To: openembedded-devel On 11/02/12 14:01, Joe MacDonald wrote: > [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.02 (Fri 08:00) Martin Ertsås wrote: > >> On 11/01/12 18:32, Joe MacDonald wrote: >>> [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.01 (Thu 17:19) Paul Eggleton wrote: >>> >>>> On Thursday 01 November 2012 17:09:59 Little, Morgan wrote: >>>>> My rational behind splitting like that is if it is just ntpdate and you try >>>>> to add ntp-ssl and ntpdate it will use ntp to provide ntpdate. It could be >>>>> change add RPROVIDES so ntp will provide ntpdate and ntp-ssl provides a >>>>> uniquely named version. >>>> The ssl version could be ntpdate-ssl if it needs to be unique. I think >>>> originally though these recipes weren't intended to be built side-by-side - >>>> rather they were mutually exclusive and the distro would make a choice as to >>>> which one was built. >>> Hmm, good point. >>> >>> Does it make sense to have both on a system? That is, if you build >>> ntp-ssl does that imply it will only use SSL for communications? If >>> that's not the case (which I suspect it isn't, but I haven't checked >>> myself) then there's not really a strong reason to install both on the >>> same system. Which then seems fine to provide ntpdate-ssl as the >>> alternative. >>> >>> Now that I think about it a bit more, maybe a RPROVIDES is appropriate >>> since ntp and ntpdate are overlapping in a lot of places. >>> >>> >>> >>> _______________________________________________ >>> Openembedded-devel mailing list >>> Openembedded-devel@lists.openembedded.org >>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel >> Are you thinking of ntp providing ntpdate then? In my mind at least, >> this makes sense, as ntp seems able to do whatever ntpdate does, so I >> don't really see the rational of having both on the same system. > Yeah, exactly. The only time I've ever wanted both ntp and ntpdate on > the same system at the same time was when I had a system with a clock > that was so badly damaged occasionally ntp couldn't recover it and I > needed to just do a reset on the time. But I could have even > accomplished that with ntp -q. In fact, a quick check of the ntp > manpage on my system says: > > -q Exit the ntpd just after the first time the clock is set. > This behavior mimics that of the ntpdate program, which > is to be retired. The -g and -x options can be used with > this option. Note: The kernel time discipline is disabled > with this option. > > So I'm thinking that ntpdate can be completely replaced with ntp if > you're putting that on your system. The obvious fallout would be in any > scripts specifically relying on something called 'ntpdate', but it looks > to me like the ntp package is already providing an ntpdate binary. > Seeing that, it seems to me that ntp/ntp-ssl and ntpdate actually > conflict with each other. > > > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel Then I agree, and think a nice solution to this would be that ntp provides ntpdate, as we don't want both. If you install ntp, you won't need ntpdate, and if you want ntpdate, you don't need all of ntp, and therefor just install ntpdate, and the same goes of course if what you want is ntp-ssl. If ntp is actually providing a ntpdate binary, I agree that it should actually conflict, and not only provide ntpdate. - Martin ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes 2012-11-02 13:09 ` Martin Ertsås @ 2012-11-02 13:14 ` Joe MacDonald 0 siblings, 0 replies; 27+ messages in thread From: Joe MacDonald @ 2012-11-02 13:14 UTC (permalink / raw) To: openembedded-devel [-- Attachment #1: Type: text/plain, Size: 4153 bytes --] [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.02 (Fri 14:09) Martin Ertsås wrote: > On 11/02/12 14:01, Joe MacDonald wrote: > > [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.02 (Fri 08:00) Martin Ertsås wrote: > > > >> On 11/01/12 18:32, Joe MacDonald wrote: > >>> [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.01 (Thu 17:19) Paul Eggleton wrote: > >>> > >>>> On Thursday 01 November 2012 17:09:59 Little, Morgan wrote: > >>>>> My rational behind splitting like that is if it is just ntpdate and you try > >>>>> to add ntp-ssl and ntpdate it will use ntp to provide ntpdate. It could be > >>>>> change add RPROVIDES so ntp will provide ntpdate and ntp-ssl provides a > >>>>> uniquely named version. > >>>> The ssl version could be ntpdate-ssl if it needs to be unique. I think > >>>> originally though these recipes weren't intended to be built side-by-side - > >>>> rather they were mutually exclusive and the distro would make a choice as to > >>>> which one was built. > >>> Hmm, good point. > >>> > >>> Does it make sense to have both on a system? That is, if you build > >>> ntp-ssl does that imply it will only use SSL for communications? If > >>> that's not the case (which I suspect it isn't, but I haven't checked > >>> myself) then there's not really a strong reason to install both on the > >>> same system. Which then seems fine to provide ntpdate-ssl as the > >>> alternative. > >>> > >>> Now that I think about it a bit more, maybe a RPROVIDES is appropriate > >>> since ntp and ntpdate are overlapping in a lot of places. > >>> > >>> > >>> > >>> _______________________________________________ > >>> Openembedded-devel mailing list > >>> Openembedded-devel@lists.openembedded.org > >>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > >> Are you thinking of ntp providing ntpdate then? In my mind at least, > >> this makes sense, as ntp seems able to do whatever ntpdate does, so I > >> don't really see the rational of having both on the same system. > > Yeah, exactly. The only time I've ever wanted both ntp and ntpdate on > > the same system at the same time was when I had a system with a clock > > that was so badly damaged occasionally ntp couldn't recover it and I > > needed to just do a reset on the time. But I could have even > > accomplished that with ntp -q. In fact, a quick check of the ntp > > manpage on my system says: > > > > -q Exit the ntpd just after the first time the clock is set. > > This behavior mimics that of the ntpdate program, which > > is to be retired. The -g and -x options can be used with > > this option. Note: The kernel time discipline is disabled > > with this option. > > > > So I'm thinking that ntpdate can be completely replaced with ntp if > > you're putting that on your system. The obvious fallout would be in any > > scripts specifically relying on something called 'ntpdate', but it looks > > to me like the ntp package is already providing an ntpdate binary. > > Seeing that, it seems to me that ntp/ntp-ssl and ntpdate actually > > conflict with each other. > > > > > > > > _______________________________________________ > > Openembedded-devel mailing list > > Openembedded-devel@lists.openembedded.org > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > > Then I agree, and think a nice solution to this would be that ntp > provides ntpdate, as we don't want both. If you install ntp, you won't > need ntpdate, and if you want ntpdate, you don't need all of ntp, and > therefor just install ntpdate, and the same goes of course if what you > want is ntp-ssl. > > If ntp is actually providing a ntpdate binary, I agree that it should > actually conflict, and not only provide ntpdate. Yep, my thoughts exactly. -- Joe MacDonald, Sr. Member of Technical Staff, Linux Products Group, Wind River direct 613.270.5750 mobile 613.291.7421 fax 613.592.2283 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 205 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes 2012-11-01 17:32 ` Joe MacDonald 2012-11-02 7:00 ` Martin Ertsås @ 2012-11-02 9:59 ` Paul Eggleton 2012-11-02 13:07 ` Joe MacDonald 2012-11-02 15:44 ` Phil Blundell 1 sibling, 2 replies; 27+ messages in thread From: Paul Eggleton @ 2012-11-02 9:59 UTC (permalink / raw) To: openembedded-devel; +Cc: Little, Morgan, Joe MacDonald On Thursday 01 November 2012 13:32:40 Joe MacDonald wrote: > [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.01 (Thu 17:19) Paul Eggleton wrote: > > On Thursday 01 November 2012 17:09:59 Little, Morgan wrote: > > > My rational behind splitting like that is if it is just ntpdate and you > > > try > > > to add ntp-ssl and ntpdate it will use ntp to provide ntpdate. It could > > > be > > > change add RPROVIDES so ntp will provide ntpdate and ntp-ssl provides a > > > uniquely named version. > > > > The ssl version could be ntpdate-ssl if it needs to be unique. I think > > originally though these recipes weren't intended to be built side-by-side > > - > > rather they were mutually exclusive and the distro would make a choice as > > to which one was built. > > Hmm, good point. > > Does it make sense to have both on a system? That is, if you build > ntp-ssl does that imply it will only use SSL for communications? If > that's not the case (which I suspect it isn't, but I haven't checked > myself) then there's not really a strong reason to install both on the > same system. Which then seems fine to provide ntpdate-ssl as the > alternative. I'm not sure that it does. I think the split was made just to avoid bringing in OpenSSL on systems where it was not needed or desired. Phil Blundell (on CC) made the split quite a while ago in OE-Classic - Phil can you comment? > Now that I think about it a bit more, maybe a RPROVIDES is appropriate > since ntp and ntpdate are overlapping in a lot of places. Sorry, I don't quite understand what you mean here... ? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes 2012-11-02 9:59 ` Paul Eggleton @ 2012-11-02 13:07 ` Joe MacDonald 2012-11-02 13:38 ` Paul Eggleton 2012-11-02 15:44 ` Phil Blundell 1 sibling, 1 reply; 27+ messages in thread From: Joe MacDonald @ 2012-11-02 13:07 UTC (permalink / raw) To: Paul Eggleton; +Cc: Little, Morgan, openembedded-devel [-- Attachment #1: Type: text/plain, Size: 3000 bytes --] [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.02 (Fri 09:59) Paul Eggleton wrote: > On Thursday 01 November 2012 13:32:40 Joe MacDonald wrote: > > [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On > 12.11.01 (Thu 17:19) Paul Eggleton wrote: > > > On Thursday 01 November 2012 17:09:59 Little, Morgan wrote: > > > > My rational behind splitting like that is if it is just ntpdate and you > > > > try > > > > to add ntp-ssl and ntpdate it will use ntp to provide ntpdate. It could > > > > be > > > > change add RPROVIDES so ntp will provide ntpdate and ntp-ssl provides a > > > > uniquely named version. > > > > > > The ssl version could be ntpdate-ssl if it needs to be unique. I think > > > originally though these recipes weren't intended to be built side-by-side > > > - > > > rather they were mutually exclusive and the distro would make a choice as > > > to which one was built. > > > > Hmm, good point. > > > > Does it make sense to have both on a system? That is, if you build > > ntp-ssl does that imply it will only use SSL for communications? If > > that's not the case (which I suspect it isn't, but I haven't checked > > myself) then there's not really a strong reason to install both on the > > same system. Which then seems fine to provide ntpdate-ssl as the > > alternative. > > I'm not sure that it does. I think the split was made just to avoid bringing > in OpenSSL on systems where it was not needed or desired. Phil Blundell (on > CC) made the split quite a while ago in OE-Classic - Phil can you comment? > > > Now that I think about it a bit more, maybe a RPROVIDES is appropriate > > since ntp and ntpdate are overlapping in a lot of places. > > Sorry, I don't quite understand what you mean here... ? Sorry about that, I've been interleaving writing and thinking, usually not a good recipe. :-) It's been so long since I had to actually pay attention to what's in ntp that I'm just getting back clued up on it. I was thinking that it should be made explicit in the ntp recipe that it provides ntpdate and therefore you would never need to have ntpdate and ntp/ntp-ssl installed on the same system at the same time. So going back to Morgan's thing, I think now that the case of "add ntp-ssl and ntpdate" is invalid, and the result should be using ntp-ssl to provide ntpdate. As long as that's what is happening with his recipe, I'm okay with it. If it's actually dragging in ntp in addition to ntp-ssl purely to provide ntpdate, I think we have a problem. And nothing should result in ntp[-ssl] and ntpdate (as in the things provided by two or more recipes) being on the same system at the same time, since ntp provides ntpdate anyway. At least it looks like it does on my test build. -- Joe MacDonald, Sr. Member of Technical Staff, Linux Products Group, Wind River direct 613.270.5750 mobile 613.291.7421 fax 613.592.2283 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 205 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes 2012-11-02 13:07 ` Joe MacDonald @ 2012-11-02 13:38 ` Paul Eggleton 2012-11-02 14:02 ` Joe MacDonald 2012-11-02 21:09 ` Phil Blundell 0 siblings, 2 replies; 27+ messages in thread From: Paul Eggleton @ 2012-11-02 13:38 UTC (permalink / raw) To: Joe MacDonald; +Cc: Little, Morgan, openembedded-devel On Friday 02 November 2012 09:07:43 Joe MacDonald wrote: > [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.02 (Fri 09:59) Paul Eggleton wrote: > > On Thursday 01 November 2012 13:32:40 Joe MacDonald wrote: > > > Does it make sense to have both on a system? That is, if you build > > > ntp-ssl does that imply it will only use SSL for communications? If > > > that's not the case (which I suspect it isn't, but I haven't checked > > > myself) then there's not really a strong reason to install both on the > > > same system. Which then seems fine to provide ntpdate-ssl as the > > > alternative. > > > > I'm not sure that it does. I think the split was made just to avoid > > bringing in OpenSSL on systems where it was not needed or desired. Phil > > Blundell (on CC) made the split quite a while ago in OE-Classic - Phil > > can you comment? > > > > Now that I think about it a bit more, maybe a RPROVIDES is appropriate > > > since ntp and ntpdate are overlapping in a lot of places. > > > > Sorry, I don't quite understand what you mean here... ? > > Sorry about that, I've been interleaving writing and thinking, usually > not a good recipe. :-) > > It's been so long since I had to actually pay attention to what's in > ntp that I'm just getting back clued up on it. I was thinking that it > should be made explicit in the ntp recipe that it provides ntpdate and > therefore you would never need to have ntpdate and ntp/ntp-ssl installed > on the same system at the same time. > > So going back to Morgan's thing, I think now that the case of "add > ntp-ssl and ntpdate" is invalid, and the result should be using ntp-ssl > to provide ntpdate. As long as that's what is happening with his > recipe, I'm okay with it. If it's actually dragging in ntp in addition > to ntp-ssl purely to provide ntpdate, I think we have a problem. And > nothing should result in ntp[-ssl] and ntpdate (as in the things > provided by two or more recipes) being on the same system at the same > time, since ntp provides ntpdate anyway. At least it looks like it does > on my test build. I have to say I think that these days this could be better implemented as one ntp recipe with a PACKAGECONFIG that you can use to enable OpenSSL support if desired. (At the time the ntp/ntp-ssl split was done, PACKAGECONFIG did not exist). Then it becomes a distro-level choice as to whether this is enabled as I believe was originally intended. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes 2012-11-02 13:38 ` Paul Eggleton @ 2012-11-02 14:02 ` Joe MacDonald 2012-11-02 14:10 ` Paul Eggleton 2012-11-02 21:09 ` Phil Blundell 1 sibling, 1 reply; 27+ messages in thread From: Joe MacDonald @ 2012-11-02 14:02 UTC (permalink / raw) To: Paul Eggleton; +Cc: Little, Morgan, openembedded-devel [-- Attachment #1: Type: text/plain, Size: 3302 bytes --] [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.02 (Fri 13:38) Paul Eggleton wrote: > On Friday 02 November 2012 09:07:43 Joe MacDonald wrote: > > [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On > 12.11.02 (Fri 09:59) Paul Eggleton wrote: > > > On Thursday 01 November 2012 13:32:40 Joe MacDonald wrote: > > > > Does it make sense to have both on a system? That is, if you build > > > > ntp-ssl does that imply it will only use SSL for communications? If > > > > that's not the case (which I suspect it isn't, but I haven't checked > > > > myself) then there's not really a strong reason to install both on the > > > > same system. Which then seems fine to provide ntpdate-ssl as the > > > > alternative. > > > > > > I'm not sure that it does. I think the split was made just to avoid > > > bringing in OpenSSL on systems where it was not needed or desired. Phil > > > Blundell (on CC) made the split quite a while ago in OE-Classic - Phil > > > can you comment? > > > > > > Now that I think about it a bit more, maybe a RPROVIDES is appropriate > > > > since ntp and ntpdate are overlapping in a lot of places. > > > > > > Sorry, I don't quite understand what you mean here... ? > > > > Sorry about that, I've been interleaving writing and thinking, usually > > not a good recipe. :-) > > > > It's been so long since I had to actually pay attention to what's in > > ntp that I'm just getting back clued up on it. I was thinking that it > > should be made explicit in the ntp recipe that it provides ntpdate and > > therefore you would never need to have ntpdate and ntp/ntp-ssl installed > > on the same system at the same time. > > > > So going back to Morgan's thing, I think now that the case of "add > > ntp-ssl and ntpdate" is invalid, and the result should be using ntp-ssl > > to provide ntpdate. As long as that's what is happening with his > > recipe, I'm okay with it. If it's actually dragging in ntp in addition > > to ntp-ssl purely to provide ntpdate, I think we have a problem. And > > nothing should result in ntp[-ssl] and ntpdate (as in the things > > provided by two or more recipes) being on the same system at the same > > time, since ntp provides ntpdate anyway. At least it looks like it does > > on my test build. > > I have to say I think that these days this could be better implemented > as one ntp recipe with a PACKAGECONFIG that you can use to enable > OpenSSL support if desired. (At the time the ntp/ntp-ssl split was > done, PACKAGECONFIG did not exist). Then it becomes a distro-level > choice as to whether this is enabled as I believe was originally > intended. I'm also perfectly fine with that. Question, though. Do you mean that the presence of OpenSSL in the distro would then mean you get ntp-ssl all the time? That would be fine for me, but I wonder if anyone else might want OpenSSL on their system but a non-ssl-enabled ntp? Probably a silly case to be thinking about anyway. I'm fine with a single recipe and using PACKAGECONFIG to control the sslness of it. -- Joe MacDonald, Sr. Member of Technical Staff, Linux Products Group, Wind River direct 613.270.5750 mobile 613.291.7421 fax 613.592.2283 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 205 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes 2012-11-02 14:02 ` Joe MacDonald @ 2012-11-02 14:10 ` Paul Eggleton 2012-11-02 14:14 ` Joe MacDonald 0 siblings, 1 reply; 27+ messages in thread From: Paul Eggleton @ 2012-11-02 14:10 UTC (permalink / raw) To: Joe MacDonald; +Cc: Little, Morgan, openembedded-devel On Friday 02 November 2012 10:02:23 Joe MacDonald wrote: > On 12.11.02 (Fri 13:38) Paul Eggleton wrote: > > I have to say I think that these days this could be better implemented > > as one ntp recipe with a PACKAGECONFIG that you can use to enable > > OpenSSL support if desired. (At the time the ntp/ntp-ssl split was > > done, PACKAGECONFIG did not exist). Then it becomes a distro-level > > choice as to whether this is enabled as I believe was originally > > intended. > > I'm also perfectly fine with that. Question, though. Do you mean that > the presence of OpenSSL in the distro would then mean you get ntp-ssl > all the time? That would be fine for me, but I wonder if anyone else > might want OpenSSL on their system but a non-ssl-enabled ntp? Probably > a silly case to be thinking about anyway. The idea with PACKAGECONFIG is it allows per-recipe control over this kind of thing. The default would be for OpenSSL support to be disabled, but it could be enabled with a bbappend containing PACKAGECONFIG += "openssl"; alternatively you could do PACKAGECONFIG_append_pn-ntp = " openssl" in the distro .conf file or even local.conf. I'll send a patch. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes 2012-11-02 14:10 ` Paul Eggleton @ 2012-11-02 14:14 ` Joe MacDonald 2012-11-02 17:26 ` Paul Eggleton 0 siblings, 1 reply; 27+ messages in thread From: Joe MacDonald @ 2012-11-02 14:14 UTC (permalink / raw) To: openembedded-devel; +Cc: Little, Morgan [-- Attachment #1: Type: text/plain, Size: 1538 bytes --] [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.02 (Fri 14:10) Paul Eggleton wrote: > On Friday 02 November 2012 10:02:23 Joe MacDonald wrote: > > On 12.11.02 (Fri 13:38) Paul Eggleton wrote: > > > I have to say I think that these days this could be better implemented > > > as one ntp recipe with a PACKAGECONFIG that you can use to enable > > > OpenSSL support if desired. (At the time the ntp/ntp-ssl split was > > > done, PACKAGECONFIG did not exist). Then it becomes a distro-level > > > choice as to whether this is enabled as I believe was originally > > > intended. > > > > I'm also perfectly fine with that. Question, though. Do you mean that > > the presence of OpenSSL in the distro would then mean you get ntp-ssl > > all the time? That would be fine for me, but I wonder if anyone else > > might want OpenSSL on their system but a non-ssl-enabled ntp? Probably > > a silly case to be thinking about anyway. > > The idea with PACKAGECONFIG is it allows per-recipe control over this kind of > thing. The default would be for OpenSSL support to be disabled, but it could > be enabled with a bbappend containing PACKAGECONFIG += "openssl"; > alternatively you could do PACKAGECONFIG_append_pn-ntp = " openssl" in the > distro .conf file or even local.conf. > > I'll send a patch. Great. Thanks, Paul. -- Joe MacDonald, Sr. Member of Technical Staff, Linux Products Group, Wind River direct 613.270.5750 mobile 613.291.7421 fax 613.592.2283 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 205 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes 2012-11-02 14:14 ` Joe MacDonald @ 2012-11-02 17:26 ` Paul Eggleton 2012-11-04 18:43 ` Joe MacDonald 0 siblings, 1 reply; 27+ messages in thread From: Paul Eggleton @ 2012-11-02 17:26 UTC (permalink / raw) To: openembedded-devel; +Cc: Little, Morgan, Joe MacDonald On Friday 02 November 2012 10:14:02 Joe MacDonald wrote: > [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.02 (Fri 14:10) Paul Eggleton wrote: > > On Friday 02 November 2012 10:02:23 Joe MacDonald wrote: > > > On 12.11.02 (Fri 13:38) Paul Eggleton wrote: > > > > I have to say I think that these days this could be better implemented > > > > as one ntp recipe with a PACKAGECONFIG that you can use to enable > > > > OpenSSL support if desired. (At the time the ntp/ntp-ssl split was > > > > done, PACKAGECONFIG did not exist). Then it becomes a distro-level > > > > choice as to whether this is enabled as I believe was originally > > > > intended. > > > > > > I'm also perfectly fine with that. Question, though. Do you mean that > > > the presence of OpenSSL in the distro would then mean you get ntp-ssl > > > all the time? That would be fine for me, but I wonder if anyone else > > > might want OpenSSL on their system but a non-ssl-enabled ntp? Probably > > > a silly case to be thinking about anyway. > > > > The idea with PACKAGECONFIG is it allows per-recipe control over this kind > > of thing. The default would be for OpenSSL support to be disabled, but it > > could be enabled with a bbappend containing PACKAGECONFIG += "openssl"; > > alternatively you could do PACKAGECONFIG_append_pn-ntp = " openssl" in the > > distro .conf file or even local.conf. > > > > I'll send a patch. > > Great. Thanks, Paul. Unfortunately when I tested the OpenSSL part I found that it's not actually linking against the OpenSSL libraries (!) This is due to libssl and libcrypto being split between /usr/lib and /lib respectively instead of being in the same directory as the configure script expects. Also the OpenSSL include directory being specified does not match with what the configure script tests for (it's supposed to be the parent of the openssl directory, not the openssl directory itself). I've also noticed that the ${PN}-utils package ends up empty and the ${PN}-bin directory contains a bunch of binaries I would have assumed belonged in that package. What should be in these packages? Should there just be one? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes 2012-11-02 17:26 ` Paul Eggleton @ 2012-11-04 18:43 ` Joe MacDonald 2012-11-09 14:55 ` Little, Morgan 0 siblings, 1 reply; 27+ messages in thread From: Joe MacDonald @ 2012-11-04 18:43 UTC (permalink / raw) To: Paul Eggleton, Little, Morgan; +Cc: openembedded-devel [-- Attachment #1: Type: text/plain, Size: 3202 bytes --] [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.02 (Fri 17:26) Paul Eggleton wrote: > On Friday 02 November 2012 10:14:02 Joe MacDonald wrote: > > [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On > 12.11.02 (Fri 14:10) Paul Eggleton wrote: > > > On Friday 02 November 2012 10:02:23 Joe MacDonald wrote: > > > > On 12.11.02 (Fri 13:38) Paul Eggleton wrote: > > > > > I have to say I think that these days this could be better implemented > > > > > as one ntp recipe with a PACKAGECONFIG that you can use to enable > > > > > OpenSSL support if desired. (At the time the ntp/ntp-ssl split was > > > > > done, PACKAGECONFIG did not exist). Then it becomes a distro-level > > > > > choice as to whether this is enabled as I believe was originally > > > > > intended. > > > > > > > > I'm also perfectly fine with that. Question, though. Do you mean that > > > > the presence of OpenSSL in the distro would then mean you get ntp-ssl > > > > all the time? That would be fine for me, but I wonder if anyone else > > > > might want OpenSSL on their system but a non-ssl-enabled ntp? Probably > > > > a silly case to be thinking about anyway. > > > > > > The idea with PACKAGECONFIG is it allows per-recipe control over this kind > > > of thing. The default would be for OpenSSL support to be disabled, but it > > > could be enabled with a bbappend containing PACKAGECONFIG += "openssl"; > > > alternatively you could do PACKAGECONFIG_append_pn-ntp = " openssl" in the > > > distro .conf file or even local.conf. > > > > > > I'll send a patch. > > > > Great. Thanks, Paul. > > Unfortunately when I tested the OpenSSL part I found that it's not > actually linking against the OpenSSL libraries (!) This is due to > libssl and libcrypto being split between /usr/lib and /lib > respectively instead of being in the same directory as the configure > script expects. Is that intentional? I mean is that a misconfiguration or something reasonably easily changed, or are there specific reasons for that split, do you know? > Also the OpenSSL include directory being specified does not match with > what the configure script tests for (it's supposed to be the parent of > the openssl directory, not the openssl directory itself). Yeah, that's interesting. Present in the existing recipe as well, from what I can see, so I'm thinking that hasn't worked since at least the update to 4.2.6p5. Morgan, can you confirm that you've got SSL support working in your updated recipe(s)? > I've also noticed that the ${PN}-utils package ends up empty and the ${PN}-bin > directory contains a bunch of binaries I would have assumed belonged in that > package. What should be in these packages? Should there just be one? I think so. Given that ntpd lives in FILES_${PN}, I'm thinking everything listed in -bin looks appropriate for -utils. Or dumping -utils and leaving them in -bin. Looking at the recipe it seems like -utils was intended to be a housecleaning collection. Did you find other non-named binaries living in ${bindir} on some builds, Morgan? -- -Joe MacDonald. :wq [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 205 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes 2012-11-04 18:43 ` Joe MacDonald @ 2012-11-09 14:55 ` Little, Morgan 2012-11-09 15:04 ` Joe MacDonald 0 siblings, 1 reply; 27+ messages in thread From: Little, Morgan @ 2012-11-09 14:55 UTC (permalink / raw) To: MacDonald, Joe, Paul Eggleton; +Cc: openembedded-devel On 11/04/2012 01:43 PM, Joe MacDonald wrote: > [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.02 (Fri 17:26) Paul Eggleton wrote: > >> On Friday 02 November 2012 10:14:02 Joe MacDonald wrote: >>> [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On >> 12.11.02 (Fri 14:10) Paul Eggleton wrote: >>>> On Friday 02 November 2012 10:02:23 Joe MacDonald wrote: >>>>> On 12.11.02 (Fri 13:38) Paul Eggleton wrote: >>>>>> I have to say I think that these days this could be better implemented >>>>>> as one ntp recipe with a PACKAGECONFIG that you can use to enable >>>>>> OpenSSL support if desired. (At the time the ntp/ntp-ssl split was >>>>>> done, PACKAGECONFIG did not exist). Then it becomes a distro-level >>>>>> choice as to whether this is enabled as I believe was originally >>>>>> intended. >>>>> >>>>> I'm also perfectly fine with that. Question, though. Do you mean that >>>>> the presence of OpenSSL in the distro would then mean you get ntp-ssl >>>>> all the time? That would be fine for me, but I wonder if anyone else >>>>> might want OpenSSL on their system but a non-ssl-enabled ntp? Probably >>>>> a silly case to be thinking about anyway. >>>> >>>> The idea with PACKAGECONFIG is it allows per-recipe control over this kind >>>> of thing. The default would be for OpenSSL support to be disabled, but it >>>> could be enabled with a bbappend containing PACKAGECONFIG += "openssl"; >>>> alternatively you could do PACKAGECONFIG_append_pn-ntp = " openssl" in the >>>> distro .conf file or even local.conf. >>>> >>>> I'll send a patch. >>> >>> Great. Thanks, Paul. >> >> Unfortunately when I tested the OpenSSL part I found that it's not >> actually linking against the OpenSSL libraries (!) This is due to >> libssl and libcrypto being split between /usr/lib and /lib >> respectively instead of being in the same directory as the configure >> script expects. > > Is that intentional? I mean is that a misconfiguration or something > reasonably easily changed, or are there specific reasons for that split, > do you know? > >> Also the OpenSSL include directory being specified does not match with >> what the configure script tests for (it's supposed to be the parent of >> the openssl directory, not the openssl directory itself). > > Yeah, that's interesting. Present in the existing recipe as well, from > what I can see, so I'm thinking that hasn't worked since at least the > update to 4.2.6p5. > > Morgan, can you confirm that you've got SSL support working in your > updated recipe(s)? Looking at the configure output, it seems that my builds don't take ssl in either. I'm not sure if 4.2.6p3 worked since without changes the old recipe doesn't build. > >> I've also noticed that the ${PN}-utils package ends up empty and the ${PN}-bin >> directory contains a bunch of binaries I would have assumed belonged in that >> package. What should be in these packages? Should there just be one? > > I think so. Given that ntpd lives in FILES_${PN}, I'm thinking > everything listed in -bin looks appropriate for -utils. Or dumping > -utils and leaving them in -bin. Looking at the recipe it seems like > -utils was intended to be a housecleaning collection. Did you find > other non-named binaries living in ${bindir} on some builds, Morgan? > I didn't find any non-named binaries living in ${bindir}. //Morgan ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes 2012-11-09 14:55 ` Little, Morgan @ 2012-11-09 15:04 ` Joe MacDonald 2012-11-10 13:22 ` Paul Eggleton 0 siblings, 1 reply; 27+ messages in thread From: Joe MacDonald @ 2012-11-09 15:04 UTC (permalink / raw) To: Little, Morgan; +Cc: openembedded-devel [-- Attachment #1: Type: text/plain, Size: 4239 bytes --] [RE: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.09 (Fri 09:55) Little, Morgan wrote: > On 11/04/2012 01:43 PM, Joe MacDonald wrote: > > [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.02 (Fri 17:26) Paul Eggleton wrote: > > > >> On Friday 02 November 2012 10:14:02 Joe MacDonald wrote: > >>> [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On > >> 12.11.02 (Fri 14:10) Paul Eggleton wrote: > >>>> On Friday 02 November 2012 10:02:23 Joe MacDonald wrote: > >>>>> On 12.11.02 (Fri 13:38) Paul Eggleton wrote: > >>>>>> I have to say I think that these days this could be better implemented > >>>>>> as one ntp recipe with a PACKAGECONFIG that you can use to enable > >>>>>> OpenSSL support if desired. (At the time the ntp/ntp-ssl split was > >>>>>> done, PACKAGECONFIG did not exist). Then it becomes a distro-level > >>>>>> choice as to whether this is enabled as I believe was originally > >>>>>> intended. > >>>>> > >>>>> I'm also perfectly fine with that. Question, though. Do you mean that > >>>>> the presence of OpenSSL in the distro would then mean you get ntp-ssl > >>>>> all the time? That would be fine for me, but I wonder if anyone else > >>>>> might want OpenSSL on their system but a non-ssl-enabled ntp? Probably > >>>>> a silly case to be thinking about anyway. > >>>> > >>>> The idea with PACKAGECONFIG is it allows per-recipe control over this kind > >>>> of thing. The default would be for OpenSSL support to be disabled, but it > >>>> could be enabled with a bbappend containing PACKAGECONFIG += "openssl"; > >>>> alternatively you could do PACKAGECONFIG_append_pn-ntp = " openssl" in the > >>>> distro .conf file or even local.conf. > >>>> > >>>> I'll send a patch. > >>> > >>> Great. Thanks, Paul. > >> > >> Unfortunately when I tested the OpenSSL part I found that it's not > >> actually linking against the OpenSSL libraries (!) This is due to > >> libssl and libcrypto being split between /usr/lib and /lib > >> respectively instead of being in the same directory as the configure > >> script expects. > > > > Is that intentional? I mean is that a misconfiguration or something > > reasonably easily changed, or are there specific reasons for that split, > > do you know? > > > >> Also the OpenSSL include directory being specified does not match with > >> what the configure script tests for (it's supposed to be the parent of > >> the openssl directory, not the openssl directory itself). > > > > Yeah, that's interesting. Present in the existing recipe as well, from > > what I can see, so I'm thinking that hasn't worked since at least the > > update to 4.2.6p5. > > > > Morgan, can you confirm that you've got SSL support working in your > > updated recipe(s)? > Looking at the configure output, it seems that my builds don't take ssl in either. > I'm not sure if 4.2.6p3 worked since without changes the old recipe doesn't build. Yeah, that's expected based on Paul's findings. I just meant could you ensure it's working in the next version of the recipe update you send out? At some point in the past it was supposed to work, we should probably try to get back there. :-) > >> I've also noticed that the ${PN}-utils package ends up empty and the ${PN}-bin > >> directory contains a bunch of binaries I would have assumed belonged in that > >> package. What should be in these packages? Should there just be one? > > > > I think so. Given that ntpd lives in FILES_${PN}, I'm thinking > > everything listed in -bin looks appropriate for -utils. Or dumping > > -utils and leaving them in -bin. Looking at the recipe it seems like > > -utils was intended to be a housecleaning collection. Did you find > > other non-named binaries living in ${bindir} on some builds, Morgan? > > > I didn't find any non-named binaries living in ${bindir}. Okay, so dump one of -utils or -bin, I'm leaning toward keeping the former and dumping the latter, but that's really up to you. -- Joe MacDonald, Sr. Member of Technical Staff, Linux Products Group, Wind River direct 613.270.5750 mobile 613.291.7421 fax 613.592.2283 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 205 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes 2012-11-09 15:04 ` Joe MacDonald @ 2012-11-10 13:22 ` Paul Eggleton 0 siblings, 0 replies; 27+ messages in thread From: Paul Eggleton @ 2012-11-10 13:22 UTC (permalink / raw) To: Joe MacDonald; +Cc: Little, Morgan, openembedded-devel On Friday 09 November 2012 10:04:14 Joe MacDonald wrote: > [RE: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.09 (Fri 09:55) Little, Morgan wrote: > > On 11/04/2012 01:43 PM, Joe MacDonald wrote: > > > [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.02 (Fri 17:26) Paul Eggleton wrote: > > >> On Friday 02 November 2012 10:14:02 Joe MacDonald wrote: > > >>> [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up > > >>> recipes] On> >> > > >> 12.11.02 (Fri 14:10) Paul Eggleton wrote: > > >>>> On Friday 02 November 2012 10:02:23 Joe MacDonald wrote: > > >>>>> On 12.11.02 (Fri 13:38) Paul Eggleton wrote: > > >>>>>> I have to say I think that these days this could be better > > >>>>>> implemented > > >>>>>> as one ntp recipe with a PACKAGECONFIG that you can use to enable > > >>>>>> OpenSSL support if desired. (At the time the ntp/ntp-ssl split was > > >>>>>> done, PACKAGECONFIG did not exist). Then it becomes a distro-level > > >>>>>> choice as to whether this is enabled as I believe was originally > > >>>>>> intended. > > >>>>> > > >>>>> I'm also perfectly fine with that. Question, though. Do you mean > > >>>>> that > > >>>>> the presence of OpenSSL in the distro would then mean you get > > >>>>> ntp-ssl > > >>>>> all the time? That would be fine for me, but I wonder if anyone > > >>>>> else > > >>>>> might want OpenSSL on their system but a non-ssl-enabled ntp? > > >>>>> Probably > > >>>>> a silly case to be thinking about anyway. > > >>>> > > >>>> The idea with PACKAGECONFIG is it allows per-recipe control over this > > >>>> kind > > >>>> of thing. The default would be for OpenSSL support to be disabled, > > >>>> but it > > >>>> could be enabled with a bbappend containing PACKAGECONFIG += > > >>>> "openssl"; > > >>>> alternatively you could do PACKAGECONFIG_append_pn-ntp = " openssl" > > >>>> in the > > >>>> distro .conf file or even local.conf. > > >>>> > > >>>> I'll send a patch. > > >>> > > >>> Great. Thanks, Paul. > > >> > > >> Unfortunately when I tested the OpenSSL part I found that it's not > > >> actually linking against the OpenSSL libraries (!) This is due to > > >> libssl and libcrypto being split between /usr/lib and /lib > > >> respectively instead of being in the same directory as the configure > > >> script expects. > > > > > > Is that intentional? I mean is that a misconfiguration or something > > > reasonably easily changed, or are there specific reasons for that split, > > > do you know? > > > > > >> Also the OpenSSL include directory being specified does not match with > > >> what the configure script tests for (it's supposed to be the parent of > > >> the openssl directory, not the openssl directory itself). > > > > > > Yeah, that's interesting. Present in the existing recipe as well, from > > > what I can see, so I'm thinking that hasn't worked since at least the > > > update to 4.2.6p5. > > > > > > Morgan, can you confirm that you've got SSL support working in your > > > updated recipe(s)? > > > > Looking at the configure output, it seems that my builds don't take ssl in > > either. I'm not sure if 4.2.6p3 worked since without changes the old > > recipe doesn't build. > Yeah, that's expected based on Paul's findings. I just meant could you > ensure it's working in the next version of the recipe update you send > out? At some point in the past it was supposed to work, we should > probably try to get back there. :-) > > > >> I've also noticed that the ${PN}-utils package ends up empty and the > > >> ${PN}-bin directory contains a bunch of binaries I would have assumed > > >> belonged in that package. What should be in these packages? Should > > >> there just be one?> > > > > I think so. Given that ntpd lives in FILES_${PN}, I'm thinking > > > everything listed in -bin looks appropriate for -utils. Or dumping > > > -utils and leaving them in -bin. Looking at the recipe it seems like > > > -utils was intended to be a housecleaning collection. Did you find > > > other non-named binaries living in ${bindir} on some builds, Morgan? > > > > I didn't find any non-named binaries living in ${bindir}. > > Okay, so dump one of -utils or -bin, I'm leaning toward keeping the > former and dumping the latter, but that's really up to you. FYI I am still working on a patch for the ntp recipes here but have yet to fix the SSL issue fully. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes 2012-11-02 13:38 ` Paul Eggleton 2012-11-02 14:02 ` Joe MacDonald @ 2012-11-02 21:09 ` Phil Blundell 1 sibling, 0 replies; 27+ messages in thread From: Phil Blundell @ 2012-11-02 21:09 UTC (permalink / raw) To: Paul Eggleton; +Cc: Little, Morgan, openembedded-devel, Joe MacDonald On Fri, 2012-11-02 at 13:38 +0000, Paul Eggleton wrote: > I have to say I think that these days this could be better implemented as one > ntp recipe with a PACKAGECONFIG that you can use to enable OpenSSL support if > desired. (At the time the ntp/ntp-ssl split was done, PACKAGECONFIG did not > exist). Then it becomes a distro-level choice as to whether this is enabled as > I believe was originally intended. Yes, agreed, that would be ideal. p. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes 2012-11-02 9:59 ` Paul Eggleton 2012-11-02 13:07 ` Joe MacDonald @ 2012-11-02 15:44 ` Phil Blundell 1 sibling, 0 replies; 27+ messages in thread From: Phil Blundell @ 2012-11-02 15:44 UTC (permalink / raw) To: Paul Eggleton; +Cc: Little, Morgan, openembedded-devel, Joe MacDonald On Fri, 2012-11-02 at 09:59 +0000, Paul Eggleton wrote: > I'm not sure that it does. I think the split was made just to avoid bringing > in OpenSSL on systems where it was not needed or desired. Phil Blundell (on > CC) made the split quite a while ago in OE-Classic - Phil can you comment? Yes, exactly. If ntpdate is the only thing on the system that's linked with openssl then it ends up dragging in several times its own weight in dependencies. And, for most people, having SSL-secured time is not that much of a priority since the time server is typically on a trusted local network. p. ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2012-11-10 13:36 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-10-23 16:20 [meta-oe][meta-networking][PATCH V2 0/3] ntp updates Morgan Little 2012-10-23 16:20 ` [meta-oe][meta-networking][PATCH V2 1/3] ntp: Move from meta-oe to meta-networking Morgan Little 2012-10-23 16:20 ` [meta-oe][meta-networking][PATCH V2 2/3] ntp: Uprev from 4.2.6p3 to 4.2.6p5 Morgan Little 2012-10-23 16:20 ` [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes Morgan Little 2012-11-01 1:08 ` Paul Eggleton 2012-11-01 5:50 ` Martin Ertsås 2012-11-01 14:31 ` Joe MacDonald 2012-11-01 17:09 ` Little, Morgan 2012-11-01 17:19 ` Paul Eggleton 2012-11-01 17:32 ` Joe MacDonald 2012-11-02 7:00 ` Martin Ertsås 2012-11-02 13:01 ` Joe MacDonald 2012-11-02 13:09 ` Martin Ertsås 2012-11-02 13:14 ` Joe MacDonald 2012-11-02 9:59 ` Paul Eggleton 2012-11-02 13:07 ` Joe MacDonald 2012-11-02 13:38 ` Paul Eggleton 2012-11-02 14:02 ` Joe MacDonald 2012-11-02 14:10 ` Paul Eggleton 2012-11-02 14:14 ` Joe MacDonald 2012-11-02 17:26 ` Paul Eggleton 2012-11-04 18:43 ` Joe MacDonald 2012-11-09 14:55 ` Little, Morgan 2012-11-09 15:04 ` Joe MacDonald 2012-11-10 13:22 ` Paul Eggleton 2012-11-02 21:09 ` Phil Blundell 2012-11-02 15:44 ` Phil Blundell
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.