| Submitter | Morgan Little |
|---|---|
| Date | Oct. 23, 2012, 4:20 p.m. |
| Message ID | <1351009220-30119-4-git-send-email-morgan.little@windriver.com> |
| Download | mbox | patch |
| Permalink | /patch/38469/ |
| State | Accepted |
| Commit | d102fc3fe64844f5c85ff350874728139a63fe78 |
| Headers | show |
Comments
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
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
[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.
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
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
[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.
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
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
[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.
[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.
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
[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.
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
[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.
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
[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.
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.
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
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.
[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?
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
[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.
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
Patch
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"
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(-)