ntpdate utility compiled in OpenEmbedded

October 30, 2017 — BarryK

Most of the binary packages used to build Quirky Pyro64 0.5 were compiled in OE, but not all. A few failed to compile, so I compiled them in a running Pyro64, and a few were never attempted in OE -- so these are all PETs.

Utility ntpdate is used by tasmod's Psync app, that syncs the time/date from an NTP server. Quirky/Easy have a rewritten version of Psync, named Qsync. This utility is in the ntp package.

I compiled ntp as a PET, because the recipe in OE is unsuitable. Unfortunately, although systemd is supposed to be an optional feature in OE, some developers are hard-coding it into build recipes. This makes life difficult for me, as I have to write my own recipe for that package.

I will turn this post into a small tutorial, showing how I wrote my own recipe for ntp.

A search with find revealed the recipe here:

meta-networking/recipes-support/ntp/ntp_4.2.8p10.bb

If I could just modify that recipe to suit my needs, I could have created this file:

meta-quirky/recipes-support/ntp/ntp_4.2.8p10.bbappend

...where meta-quirky is my custom layer. See the online github repo:

https://github.com/bkauler/oe-qky-src

However, I wanted to rewrite the recipe from scratch. The thing is, do not modify the original, create a new one. The new recipe, in my custom layer, will override the original:

meta-quirky/recipes-support/ntp/ntp_4.2.8p10.bb

How to write a recipe? Actually, this is made easy (well, easier) by a special script:

# recipetool create -o ntp_4.2.8p10.bb https://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/ntp-4.2.8p10.tar.gz

...this is neat. You specify the URL of the source package, and required name of the recipe file, and it will create a skeleton recipe. Which most likely will need further tweaking.

Examining the original recipe helps, as does having already compiled the package in a running Pyro64. From previous experience having compiled this package, I knew what configure options are needed, and the dependencies.

Dependencies, ah, this is a bit of a dark art. A few years ago, OE was structured differently. Now, each package is compiled in its own isolated mini-filesystem. You have to know all the required deps, and specify them. Not quite all, as the basic packages such as glibc are provided.

Here is my ntp_4.2.8p10.bb:

LICENSE = "MIT & LGPLv3"
LIC_FILES_CHKSUM = "file://COPYRIGHT;md5=e877a1d567a6a58996d2b66e3e387003 \
                    file://libjsmn/LICENSE;md5=5adc94605a1f7a797a9a834adbe335e3 \
                    file://sntp/COPYRIGHT;md5=e877a1d567a6a58996d2b66e3e387003"

SRC_URI = "https://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/ntp-${PV}.tar.gz"
SRC_URI[md5sum] = "745384ed0dedb3f66b33fe84d66466f9"
SRC_URI[sha256sum] = "ddd2366e64219b9efa0f7438e06800d0db394ac5c88e13c17b70d0dcdf99b99f"

# openssl has libcrypto...
DEPENDS = "bison-native libevent readline libcap openssl"

inherit perlnative autotools pkgconfig

# --with-yielding_select=yes is required when cross-compiling.
EXTRA_OECONF = "--with-yielding_select=yes --enable-ipv6 --with-crypto --enable-linuxcaps --with-lineeditlibs=readline"

# only want this one executable...
do_install () {
    mkdir -p ${D}/usr/sbin
    install -m 755 ${B}/ntpdate/ntpdate ${D}/usr/sbin
}

HOMEPAGE = "http://www.ntp.org/"
SUMMARY = "NTP is a protocol designed to synchronize the clocks of computers over a network"

I have added a few things to the original skeleton. For example, the original only has "bison-native" as dependency.

As I only want the ntpdate utility, I created a custom install function. Those variables are pre-defined: D=destination, B=build and S=source paths. The build folder is usually different from the source.

To examine the end result, the entire build is here (in the case of my own hard drive):

/mnt/sdb1/projects/oe/oe-quirky/buildPC/tmp-glibc/work/nocona-64-oe-linux/ntp/4.2.8p10-r0

...I did an "ldd ./ntpdate" to check that it had all the expected libs. Yep, ok.

To do the build, I added the ntp package by appending this line "IMAGE_INSTALL_append = " ntp"":

/mnt/sdb1/projects/oe/oe-quirky/buildPC/conf/local.conf

Then, to do the actual build:

# bitbake -c build ntp

If there is an error, and I did get one, I advise cleaning out the entire build. Although you could just run the "build" command again, some packages won't like it. The "clean" command erases everything, all of folder "4.2.8p10-r0" shown above.

# bitbake -c clean ntp

...then run a "build". The final installed result can be seen here:

/mnt/sdb1/projects/oe/oe-quirky/buildPC/tmp-glibc/work/nocona-64-oe-linux/ntp/4.2.8p10-r0/image

...it is the content of this image folder that will be imported into woofQ. However, one final step:

# bitbake -g core-image-quirky

...this creates some package-list and package-dependency files, pn-buildlist, recipe-depends.dot and task-depends.dot. The woofQ import script reads these, which is why they must be updated.

woofQ

Over in woofQ, there are two scripts for importing binary packages from OE, 0pre-oe and 0pre-oe-add. The former was run originally, the latter is for importing additional packages. Just run 0pre-oe-add:

# ./0pre-oe-add

...and it picks up the new ntp package and offers to import it.

It will also pickup packages previously in OE, now removed, and offer to remove them from woofQ.

Tags: oe