From esr at thyrsus.com Thu Nov 1 02:01:11 2018 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 31 Oct 2018 22:01:11 -0400 Subject: ntpsec | Authenticated out-of-bounds write in ntp_parser.y (#510) In-Reply-To: <20181031184426.3E3B440605C@ip-64-139-1-69.sjc.megapath.net> References:

<20181031184426.3E3B440605C@ip-64-139-1-69.sjc.megapath.net> Message-ID: <20181101020111.GA14120@thyrsus.com> Hal Murray via devel : > The old buffer allocation pool is still there. That could be cleaned up. > > refclock_generic still calls get_free_recv_buffer > There are 2 calls in ntp_io > I think they could be replaced by chunks on the stack or globals. > > Checking/understanding the data input path for refclocks might be interesting. > There are 2 cases. The ACSII text mode uses readline so the driver gets a > complete message on each call. The binary mode has to take whatever data is > available and the driver has to keep collecting until it gets a whole message. > > > If you want a medium size project that is well localized... Good training, Ian. I recommend it, > ntp_control is the server side of ntpq. It's table driven, but there are 2 or > 3 tables that must be kept in sync by hand. (One is a set of #defines, so it > isn't actually a "table".) We should be able to compress that to a single > table with a good macro. I'm a little reluctant to add C macroloogy at this point. Plans for Go translation aren't *on* the horizon at this point, but they're not far over it. On the other hand generating one nice table from declarative markup with a Python helper would map over well to Go when we get there, and is the sort of "do things as declratively as possible, as high level as possible" technique that Ian should be learning. -- Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. From hmurray at megapathdsl.net Thu Nov 1 10:28:57 2018 From: hmurray at megapathdsl.net (Hal Murray) Date: Thu, 01 Nov 2018 03:28:57 -0700 Subject: ntpsec | Authenticated out-of-bounds write in ntp_parser.y (#510) In-Reply-To: Message from "Eric S. Raymond" of "Wed, 31 Oct 2018 22:01:11 EDT." <20181101020111.GA14120@thyrsus.com> Message-ID: <20181101102857.3655740605C@ip-64-139-1-69.sjc.megapath.net> esr at thyrsus.com said: > I'm a little reluctant to add C macroloogy at this point. Plans for Go > translation aren't *on* the horizon at this point, but they're not far over > it. The current code has things like: #define CS_LEAP 1 #define CS_STRATUM 2 #define CS_PRECISION 3 #define CS_ROOTDELAY 4 ... That makes it hard to insert something. Is there any way to get the next number. I'd like to do something like #magic foo++ #define xxx $foo > On the other hand generating one nice table from declarative markup with a > Python helper would map over well to Go when we get there, and is the sort of > "do things as declratively as possible, as high level as possible" technique > that Ian should be learning. The places where it gets used: { CS_LEAP, RW, "leap" }, /* 1 */ { CS_STRATUM, RO, "stratum" }, /* 2 */ { CS_PRECISION, RO, "precision" }, /* 3 */ { CS_ROOTDELAY, RO, "rootdelay" }, /* 4 */ That's to translate a string to a magic number which happens to be the index into a table. and case CS_LEAP: ctl_putuint(sys_var[CS_LEAP].text, sys_vars.sys_leap); break; case CS_STRATUM: ctl_putuint(sys_var[CS_STRATUM].text, sys_vars.sys_stratum); break; case CS_PRECISION: ctl_putint(sys_var[CS_PRECISION].text, sys_vars.sys_precision); break; That's to translate the named slot into a printed value. It's possible that we don't need a name for the index. If we extend the first table with a value to be printed and a tag for the type of value, then we can pass around a pointer to the slot rather than a magic number. The key idea is to collect all the info in one place. I don't know if a pre-processor is necessary or appropriate. -- These are my opinions. I hate spam. From udovdh at xs4all.nl Thu Nov 1 15:29:00 2018 From: udovdh at xs4all.nl (Udo van den Heuvel) Date: Thu, 1 Nov 2018 16:29:00 +0100 Subject: build error Message-ID: Hello, After the recent commits I get: [259/261] Processing build/main/tests/test_libparse [260/261] Processing build/main/tests/test_ntpd [261/261] Processing build/main/tests/test_libntp a2x: ERROR: "xsltproc" --stringparam callout.graphics 0 --stringparam navig.graphics 0 --stringparam admon.textlabel 1 --stringparam admon.graphics 0 "/etc/asciidoc/docbook-xsl/manpage.xsl" "/usr/src/redhat/BUILD/ntpsec-1.1.2/build/main/ntpclients/ntpmon-man.txt.xml" returned non-zero exit status 5 I happens on one box, not on another. So what could be the cause? Kind regards, Udo From jamesb.fe80 at gmail.com Thu Nov 1 16:25:34 2018 From: jamesb.fe80 at gmail.com (James Browning) Date: Thu, 1 Nov 2018 09:25:34 -0700 Subject: build error In-Reply-To: References: Message-ID: On Thu, Nov 1, 2018 at 8:29 AM Udo van den Heuvel via devel < devel at ntpsec.org> wrote: > Hello, > > After the recent commits I get: > > [259/261] Processing build/main/tests/test_libparse > [260/261] Processing build/main/tests/test_ntpd > [261/261] Processing build/main/tests/test_libntp > a2x: ERROR: "xsltproc" --stringparam callout.graphics 0 --stringparam > navig.graphics 0 --stringparam admon.textlabel 1 --stringparam > admon.graphics 0 "/etc/asciidoc/docbook-xsl/manpage.xsl" > > "/usr/src/redhat/BUILD/ntpsec-1.1.2/build/main/ntpclients/ntpmon-man.txt.xml" > returned non-zero exit status 5 > > > I happens on one box, not on another. > So what could be the cause? > > > Kind regards, > Udo > It looks like an exit code '5' from xsltproc, which would indicate a stylesheet error. My suggestion is to check the asciidoc package via whatever means are distro appropriate. It looks like my resposibility as the last person to touch the man page generation and that particular manpage. -------------- next part -------------- An HTML attachment was scrubbed... URL: From udovdh at xs4all.nl Thu Nov 1 16:58:11 2018 From: udovdh at xs4all.nl (Udo van den Heuvel) Date: Thu, 1 Nov 2018 17:58:11 +0100 Subject: build error In-Reply-To: References: Message-ID: On 01-11-18 17:25, James Browning via devel wrote: > On Thu, Nov 1, 2018 at 8:29 AM Udo van den Heuvel via devel > > wrote: > > After the recent commits I get: > > [259/261] Processing build/main/tests/test_libparse > [260/261] Processing build/main/tests/test_ntpd > [261/261] Processing build/main/tests/test_libntp > a2x: ERROR: "xsltproc"? --stringparam callout.graphics 0 --stringparam > navig.graphics 0 --stringparam admon.textlabel 1 --stringparam > admon.graphics 0? "/etc/asciidoc/docbook-xsl/manpage.xsl" > "/usr/src/redhat/BUILD/ntpsec-1.1.2/build/main/ntpclients/ntpmon-man.txt.xml" > returned non-zero exit status 5 > > > I happens on one box, not on another. > So what could be the cause? > > It looks like an exit code '5' from xsltproc, which would indicate a > stylesheet error. > My suggestion is to check the asciidoc package via whatever means are > distro appropriate. A retry made the build succeed. I noticed also that the build `sits` at certain spots without much CPU usage or other activity. > It looks like my resposibility as the last person to touch the man page > generation and that particular manpage. Hmmm... How to correlate these? Udo From hmurray at megapathdsl.net Sun Nov 4 22:46:57 2018 From: hmurray at megapathdsl.net (Hal Murray) Date: Sun, 04 Nov 2018 14:46:57 -0800 Subject: ntpleapfetch broken on FreeBSD 11.2 or NetBSD 8.0 Message-ID: <20181104224657.D260740605C@ip-64-139-1-69.sjc.megapath.net> "function" seems not to work in sh scripts. I doubt if ntpleapfetch ever worked. I don't use it. This showed up with the bin_check addition. (Thanks!) Anybody recognize this? FreeBSD: [murray at ted3 ~/ntpsec/play]$ ./ted3/main/ntpclients/ntpleapfetch --version > foo ./ted3/main/ntpclients/ntpleapfetch: function: not found [murray at ted3 ~/ntpsec/play]$ [murray at ted3 ~/ntpsec/play]$ head foo Usage: ntpleapfetch [options] [leapfile] Verifies and if necessary, updates leap-second definition file All arguments are optional: Default (or current value) shown: -s Specify the URL of the master copy to download https://www.ietf.org/timezones/data/leap-seconds.list -4 Use only IPv4 -6 Use only IPv6 -p 4|6 -------- NetBSD: Waf: Leaving directory `/home/murray/ntpsec/play/bob3/main' running: main/ntpclients/ntpleapfetch --version FAILED function: not found main/ntpclients/ntpleapfetch: 117: Syntax error: "}" unexpected -- These are my opinions. I hate spam. From jamesb.fe80 at gmail.com Sun Nov 4 23:46:11 2018 From: jamesb.fe80 at gmail.com (James Browning) Date: Sun, 4 Nov 2018 15:46:11 -0800 Subject: ntpleapfetch broken on FreeBSD 11.2 or NetBSD 8.0 In-Reply-To: <20181104224657.D260740605C@ip-64-139-1-69.sjc.megapath.net> References: <20181104224657.D260740605C@ip-64-139-1-69.sjc.megapath.net> Message-ID: On Sun, Nov 4, 2018, 2:47 PM Hal Murray via devel > "function" seems not to work in sh scripts. > > I doubt if ntpleapfetch ever worked. I don't use it. This showed up with > the > bin_check addition. (Thanks!) > > Anybody recognize this? > > FreeBSD: > > [murray at ted3 ~/ntpsec/play]$ ./ted3/main/ntpclients/ntpleapfetch > --version > > foo > ./ted3/main/ntpclients/ntpleapfetch: function: not found > [murray at ted3 ~/ntpsec/play]$ > > [murray at ted3 ~/ntpsec/play]$ head foo > Usage: ntpleapfetch [options] [leapfile] > > Verifies and if necessary, updates leap-second definition file > > All arguments are optional: Default (or current value) shown: > -s Specify the URL of the master copy to download > https://www.ietf.org/timezones/data/leap-seconds.list > -4 Use only IPv4 > -6 Use only IPv6 > -p 4|6 > > -------- > > NetBSD: > > Waf: Leaving directory `/home/murray/ntpsec/play/bob3/main' > running: main/ntpclients/ntpleapfetch --version FAILED > function: not found > main/ntpclients/ntpleapfetch: 117: Syntax error: "}" unexpected > I was working on that a little try checking out merge request !831 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gem at rellim.com Mon Nov 5 05:06:07 2018 From: gem at rellim.com (Gary E. Miller) Date: Sun, 4 Nov 2018 21:06:07 -0800 Subject: ntpleapfetch broken on FreeBSD 11.2 or NetBSD 8.0 In-Reply-To: <20181104224657.D260740605C@ip-64-139-1-69.sjc.megapath.net> References: <20181104224657.D260740605C@ip-64-139-1-69.sjc.megapath.net> Message-ID: <20181104210607.09306c17@spidey.rellim.com> Yo Hal! On Sun, 04 Nov 2018 14:46:57 -0800 Hal Murray via devel wrote: > I doubt if ntpleapfetch ever worked. I don't use it. It always worked for me. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem at rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can?t measure it, you can?t improve it." - Lord Kelvin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 851 bytes Desc: OpenPGP digital signature URL: From hmurray at megapathdsl.net Mon Nov 5 05:34:01 2018 From: hmurray at megapathdsl.net (Hal Murray) Date: Sun, 04 Nov 2018 21:34:01 -0800 Subject: ntpleapfetch broken on FreeBSD 11.2 or NetBSD 8.0 Message-ID: <20181105053401.7FDF640605C@ip-64-139-1-69.sjc.megapath.net> >> I doubt if ntpleapfetch ever worked. I don't use it. > It always worked for me. Sorry. I meant never worked on FreeBSD/NetBSD. It's only after bin_check got added to waf check that it gets regularly tested. Don't we have a BSD machine in the testing collection on gitlab? Doesn't the every-checkin stuff do a waf check? Why didn't this get noticed sooner? ... -- These are my opinions. I hate spam. From hmurray at megapathdsl.net Mon Nov 5 05:47:14 2018 From: hmurray at megapathdsl.net (Hal Murray) Date: Sun, 04 Nov 2018 21:47:14 -0800 Subject: Testing merge requests Message-ID: <20181105054714.F247540605C@ip-64-139-1-69.sjc.megapath.net> [Was: Subject: Re: ntpleapfetch broken on FreeBSD 11.2 or NetBSD 8.0] > I was working on that a little try checking out merge request !831 How do I do that? That should be simple, but it's not in my working set. I think I asked a while ago and didn't get an answer that stuck. There is probably an interesting property in git or gitlab that I don't understand. I need a way to back out if I don't like the change. Work in a clone and throw it away if you don't like it is a possible answer, but I expect there is something better. -- These are my opinions. I hate spam. From jamesb.fe80 at gmail.com Mon Nov 5 09:38:48 2018 From: jamesb.fe80 at gmail.com (James Browning) Date: Mon, 5 Nov 2018 01:38:48 -0800 Subject: Testing merge requests In-Reply-To: <20181105054714.F247540605C@ip-64-139-1-69.sjc.megapath.net> References: <20181105054714.F247540605C@ip-64-139-1-69.sjc.megapath.net> Message-ID: On Sun, Nov 4, 2018 at 9:47 PM Hal Murray via devel wrote: > [Was: Subject: Re: ntpleapfetch broken on FreeBSD 11.2 or NetBSD 8.0] > > > I was working on that a little try checking out merge request !831 > > How do I do that? > > That should be simple, but it's not in my working set. I think I asked a > while ago and didn't get an answer that stuck. There is probably an > interesting property in git or gitlab that I don't understand. > > I need a way to back out if I don't like the change. Work in a clone and > throw it away if you don't like it is a possible answer, but I expect > there is > something better. > > > -- > These are my opinions. I hate spam. > What I would do I I were checking out say Pauls work on ./docs would be to 'git remote add' his upstream repository mirror to my working repository. Somehow I don't think that was the answer you were looking for, but it's all I've got. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthew.Selsky at twosigma.com Mon Nov 5 15:01:40 2018 From: Matthew.Selsky at twosigma.com (Matthew Selsky) Date: Mon, 5 Nov 2018 15:01:40 +0000 Subject: Testing merge requests In-Reply-To: <20181105054714.F247540605C@ip-64-139-1-69.sjc.megapath.net> References: <20181105054714.F247540605C@ip-64-139-1-69.sjc.megapath.net> Message-ID: <20181105150139.GA3556@twosigma.com> On Sun, Nov 04, 2018 at 09:47:14PM -0800, Hal Murray via devel wrote: > [Was: Subject: Re: ntpleapfetch broken on FreeBSD 11.2 or NetBSD 8.0] > > > I was working on that a little try checking out merge request !831 > > How do I do that? > > That should be simple, but it's not in my working set. I think I asked a > while ago and didn't get an answer that stuck. There is probably an > interesting property in git or gitlab that I don't understand. > > I need a way to back out if I don't like the change. Work in a clone and > throw it away if you don't like it is a possible answer, but I expect there is > something better. If you click the "command line" link on https://gitlab.com/NTPsec/ntpsec/merge_requests/831, you'll see a pop-up with instructions on how to checkout that branch and play around with it: git fetch https://gitlab.com/jamesb_fe80/ntpsec.git ntpleapfetch.sh git checkout -b jamesb_fe80/ntpsec-ntpleapfetch.sh FETCH_HEAD Or similar. See also these tips for shortcuts for checkout out MRs: https://docs.gitlab.com/ee/user/project/merge_requests/#checkout-merge-requests-locally Thanks, -Matt From udovdh at xs4all.nl Mon Nov 5 15:03:27 2018 From: udovdh at xs4all.nl (Udo van den Heuvel) Date: Mon, 5 Nov 2018 16:03:27 +0100 Subject: --- PYTHONDARCHIR not in PYTHONPATHloading the Python ntp library may be troublesome --- Message-ID: <07aec83a-469a-e4c4-f4c0-28de6e0edfcf@xs4all.nl> Hello, Wheile trying to debug the slow/failing ntpsec builds since upgrading to fedora 29, I noticed this: # ./waf build --- building host --- Waf: Entering directory `/usr/src/redhat/BUILD/ntpsec-1.1.2/build/host' Waf: Leaving directory `/usr/src/redhat/BUILD/ntpsec-1.1.2/build/host' --- building main --- Waf: Entering directory `/usr/src/redhat/BUILD/ntpsec-1.1.2/build/main' --- PYTHONDARCHIR not in PYTHONPATHloading the Python ntp library may be troublesome --- [ 98/123] Compiling build/main/ntpd/ntp.conf-man.txt.man-tmp [114/123] Compiling build/main/ntptime/ntptime-man.txt.man-tmp (cut) When I googled PYTHONDARCHIR I only found the ntpsec waf file as a hit. If this is not a typo, please explain how to set up this variable. Kind regards, Udo From jamesb.fe80 at gmail.com Mon Nov 5 15:25:58 2018 From: jamesb.fe80 at gmail.com (James Browning) Date: Mon, 5 Nov 2018 07:25:58 -0800 Subject: --- PYTHONDARCHIR not in PYTHONPATHloading the Python ntp library may be troublesome --- In-Reply-To: <07aec83a-469a-e4c4-f4c0-28de6e0edfcf@xs4all.nl> References: <07aec83a-469a-e4c4-f4c0-28de6e0edfcf@xs4all.nl> Message-ID: On Mon, Nov 5, 2018 at 7:03 AM Udo van den Heuvel via devel < devel at ntpsec.org> wrote: > Hello, > > Wheile trying to debug the slow/failing ntpsec builds since upgrading to > fedora 29, I noticed this: > > # ./waf build > --- building host --- > Waf: Entering directory `/usr/src/redhat/BUILD/ntpsec-1.1.2/build/host' > Waf: Leaving directory `/usr/src/redhat/BUILD/ntpsec-1.1.2/build/host' > --- building main --- > Waf: Entering directory `/usr/src/redhat/BUILD/ntpsec-1.1.2/build/main' > --- PYTHONDARCHIR not in PYTHONPATHloading the Python ntp library may be > troublesome --- > [ 98/123] Compiling build/main/ntpd/ntp.conf-man.txt.man-tmp > [114/123] Compiling build/main/ntptime/ntptime-man.txt.man-tmp > (cut) > > When I googled PYTHONDARCHIR I only found the ntpsec waf file as a hit. > If this is not a typo, please explain how to set up this variable. > > Kind regards, > Udo > Yes, proof omniquantism is the way. j/k I get hits on samba before the first hit on NTPsec. PYTHONARCHDIR is the environment variable that specifies where (outside of PATH presumably) to look for C compiled python module bits. The method of setting is shell specific. you might try 'export PYTHONARCHDIR=/usr/local/' or something simmilar. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason at azze.org Mon Nov 5 16:52:43 2018 From: jason at azze.org (Jason Azze) Date: Mon, 05 Nov 2018 11:52:43 -0500 Subject: --- PYTHONDARCHIR not in PYTHONPATHloading the Python ntp library may be troublesome --- In-Reply-To: References: <07aec83a-469a-e4c4-f4c0-28de6e0edfcf@xs4all.nl> Message-ID: <1541436763.501793.1566305952.181CE7C1@webmail.messagingengine.com> On Mon, Nov 5, 2018, at 10:25 AM, James Browning via devel wrote: > On Mon, Nov 5, 2018 at 7:03 AM Udo van den Heuvel via devel > wrote:>> >> When I googled PYTHONDARCHIR Udo is pointing out that our PYTHONDARCHIR has its "D" in an odd place. Looks like a typo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rlaager at wiktel.com Mon Nov 5 20:11:01 2018 From: rlaager at wiktel.com (Richard Laager) Date: Mon, 5 Nov 2018 14:11:01 -0600 Subject: --- PYTHONDARCHIR not in PYTHONPATHloading the Python ntp library may be troublesome --- In-Reply-To: <1541436763.501793.1566305952.181CE7C1@webmail.messagingengine.com> References: <07aec83a-469a-e4c4-f4c0-28de6e0edfcf@xs4all.nl> <1541436763.501793.1566305952.181CE7C1@webmail.messagingengine.com> Message-ID: <23456601-63d3-5e3f-8244-b56edbd2669f@wiktel.com> On 11/5/18 10:52 AM, Jason Azze via devel wrote: > Udo is pointing out that our?PYTHONDARCHIR has its "D" in an odd place. > Looks like a typo. Easy fix. I submitted a MR: https://gitlab.com/NTPsec/ntpsec/merge_requests/841/ Also, this line was missing the comma and space at the end, so the words were running together. I fixed that too. -- Richard From rlaager at wiktel.com Mon Nov 5 20:13:38 2018 From: rlaager at wiktel.com (Richard Laager) Date: Mon, 5 Nov 2018 14:13:38 -0600 Subject: --- PYTHONDARCHIR not in PYTHONPATHloading the Python ntp library may be troublesome --- In-Reply-To: <23456601-63d3-5e3f-8244-b56edbd2669f@wiktel.com> References: <07aec83a-469a-e4c4-f4c0-28de6e0edfcf@xs4all.nl> <1541436763.501793.1566305952.181CE7C1@webmail.messagingengine.com> <23456601-63d3-5e3f-8244-b56edbd2669f@wiktel.com> Message-ID: <7988d2d8-8235-a1ae-cc32-f7ea54c4150e@wiktel.com> On 11/5/18 2:11 PM, Richard Laager via devel wrote: > On 11/5/18 10:52 AM, Jason Azze via devel wrote: >> Udo is pointing out that our?PYTHONDARCHIR has its "D" in an odd place. >> Looks like a typo. > > Easy fix. I submitted a MR: > https://gitlab.com/NTPsec/ntpsec/merge_requests/841/ > > Also, this line was missing the comma and space at the end, so the words > were running together. I fixed that too. I see this clashed with Matt fixing the typo. I rebased the MR so it only has the latter change. -- Richard From hmurray at megapathdsl.net Mon Nov 5 23:05:56 2018 From: hmurray at megapathdsl.net (Hal Murray) Date: Mon, 05 Nov 2018 15:05:56 -0800 Subject: ntpsec | add mid 2018s leap-second.list file under ./etc (!839) In-Reply-To: Message from James Browning of "Mon, 05 Nov 2018 19:18:58 GMT." Message-ID: <20181105230556.D5DBD40605C@ip-64-139-1-69.sjc.megapath.net> (Moved to devel@ where more people will see it.) gitlab at mg.gitlab.com said: > Someone should carry it on a fast, reliable website. http://hpiers.obspm.fr > is presumably bandwidth limited, the USNO has a slow FTP site, the IETF is > out of date, and https://github.com/eggert/tz updates late. We should be very very careful not to contribute to DoS-ing somebody else's resources. Crappy NTP implementations have a long history of being involved in abuse. The wiki page is pretty good. https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse I think Dave Plonka's writeup of the U-Wisc event should be required reading for any CS networking class. We should all reread it every now and then. http://pages.cs.wisc.edu/~plonka/netgear-sntp/ There can also be problems on the server side. The return address on UDP queries can be forged. That lets the attacker hide. The server can do traffic limiting, with the obvious trade off between blocking small attacks and blocking legitimate traffic. Many years ago, ntpd was setup to support amplification. A small ntpq request could generate a huge response. That's a wonderful resource for DDoS-ers. (The current code requires a cookie on large responses. The cookie ensures that the request came from the return address.) ---------- Back to leap-seconds. Their are 2 cases to consider: big servers with many clients and end-users with no clients. There is probably a gray area in between. End-clients don't need a leap-seconds file and/or can get it from their distro. Big servers should probably have a leap-seconds file. We shouldn't include it in our source tree. It's only good for a year, and the timer starts when the upstream file is released, not when somebody grabs our tarball (which gets created N months after the official release). Any distro using it from our tarball will break if they don't keep up to date. They should be able to update leap-seconds without touching the rest of the package. We shouldn't wire in any URLs that could possibly be abused unless we control the target and/or have explicit permission. (The pool sites in a sample ntp.conf are the only case I can think of where we have permission.) We could setup a web site to distribute copies of the file. We should use a separate DNS name so we can move the load to another site if problems develop. I think distros can piggyback on the tzdata/IANA site. It gets updated several times a year. Distros are used to their updates. I'm pretty sure we could convince them to push a special update if nothing else is going on. How long does it take a distro to push out a tzdata update? -- These are my opinions. I hate spam. From hmurray at megapathdsl.net Tue Nov 6 05:38:51 2018 From: hmurray at megapathdsl.net (Hal Murray) Date: Mon, 05 Nov 2018 21:38:51 -0800 Subject: ntpsec | add mid 2018s leap-second.list file under ./etc (!839) In-Reply-To: Message from Mark Atwood of "Mon, 05 Nov 2018 18:41:22 PST." Message-ID: <20181106053851.9906440605C@ip-64-139-1-69.sjc.megapath.net> fallenpegasus at gmail.com said: > The distros have gotten used to pushing tzdata every 6 months. > If we could get the leapsecond data into that package, it would be ideal. It's already in the package they send to IANA and on the IANA servers. The tzdata-base is updated more often than every 6 months. They are up to "g" so far this year. But they come in clusters rather than a uniform distribution. Examples are at the bottom of: ftp://ftp.iana.org/tz/ Latest version is here: ftp://ftp.iana.org/tz/data/leap-seconds.list I can't find a https URL to just that file. There are URLs for the whole tarball. The catch is they don't update it automatically. Somebody has to tell them to fetch a new version. No big deal, just an email. I'm pretty sure we could get them to do a leap-seconds only release if they didn't have any other changes to push out. If we wanted to be helpful, we could write a script that does whatever and sends them a merge request. --------- The other problem is to get distros to distribute the leap-seconds file. I poked Fedora, they did it, but got the wrong format. (I didn't even know there was another format.) Time to poke them again. -- These are my opinions. I hate spam. From hmurray at megapathdsl.net Tue Nov 6 22:44:12 2018 From: hmurray at megapathdsl.net (Hal Murray) Date: Tue, 06 Nov 2018 14:44:12 -0800 Subject: Testing Message-ID: <20181106224412.C42F740605C@ip-64-139-1-69.sjc.megapath.net> There is a discussion on the TZ list about a screwup in medical software that can't handle DST changes. It's also on RISKS. (But not on their archives yet.) http://catless.ncl.ac.uk/Risks/ So I'm thinking about testing. What can we do to help people test NTP? Does anybody have a list of rough edges? What should we test before a release to make sure our code is doing what we expect? What should end users test to make sure our code is working in their setup? Are those the same lists? Or would priorities change? What does priority mean? Should we collect directions (or a script) to semi-automate making leap seconds? One possibility would be a build option to enable a config option for leap-tonight. That's a kludge, but simple for testers who aren't NTP geeks to understand. Plan B would be to hack the leap seconds file. Cleaner for the ntpd code, but more complicated overall. -- These are my opinions. I hate spam. From jamesb.fe80 at gmail.com Sun Nov 11 18:42:30 2018 From: jamesb.fe80 at gmail.com (James Browning) Date: Sun, 11 Nov 2018 10:42:30 -0800 Subject: ntpsec | add mid 2018s leap-second.list file under ./etc (!839) In-Reply-To: <20181106053851.9906440605C@ip-64-139-1-69.sjc.megapath.net> References:

<20181106053851.9906440605C@ip-64-139-1-69.sjc.megapath.net> Message-ID: On Mon, Nov 5, 2018 at 9:38 PM Hal Murray via devel wrote: > > fallenpegasus at gmail.com said: > > The distros have gotten used to pushing tzdata every 6 months. > > If we could get the leapsecond data into that package, it would be > ideal. > > It's already in the package they send to IANA and on the IANA servers. > > The tzdata-base is updated more often than every 6 months. They are up to > "g" > so far this year. But they come in clusters rather than a uniform > distribution. Examples are at the bottom of: > ftp://ftp.iana.org/tz/ > > Latest version is here: > ftp://ftp.iana.org/tz/data/leap-seconds.list > I can't find a https URL to just that file. There are URLs for the whole > tarball. > > The catch is they don't update it automatically. Somebody has to tell > them to > fetch a new version. No big deal, just an email. I'm pretty sure we > could > get them to do a leap-seconds only release if they didn't have any other > changes to push out. > > If we wanted to be helpful, we could write a script that does whatever and > sends them a merge request. > > --------- > > The other problem is to get distros to distribute the leap-seconds file. > I > poked Fedora, they did it, but got the wrong format. (I didn't even know > there was another format.) Time to poke them again. > > > -- > These are my opinions. I hate spam. > Ubuntu ( or clan Debian) seems to be the exception to the rule afaict. Slackware and NetBSD package the non-usable derivative and most other distros seem to not include it at all. I could try posting an ebuild patch to Gentoo, and look at a PKGBUILD patch for Arch. https://github.com/eggert/tz/ seems to be the repository for the tz data build files with the leap-seconds.list file convieniently in the root directory. I might pencil in on my (lack of a) calender to check for a bulletin C in January and July. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hmurray at megapathdsl.net Wed Nov 28 10:18:11 2018 From: hmurray at megapathdsl.net (Hal Murray) Date: Wed, 28 Nov 2018 02:18:11 -0800 Subject: getdents64 Message-ID: <20181128101811.7FB33406061@ip-64-139-1-69.sjc.megapath.net> I just added it to the seccomp list. It's needed by Fedora 29 i686. Interesting that I was the first to notice. Fedora 29 has been out for a while. Please keep an eye out for troubles. There might be some distros with kernels that don't have it. If you find one, add the ifdef. (should be obvious - copy from some nearby code) -- These are my opinions. I hate spam. From jason at azze.org Thu Nov 29 12:58:12 2018 From: jason at azze.org (Jason Azze) Date: Thu, 29 Nov 2018 07:58:12 -0500 Subject: pipefail doesn't work on NetBSD or FreeBSD In-Reply-To: <20181013045330.82B26406063@ip-64-139-1-69.sjc.megapath.net> References: <20181013045330.82B26406063@ip-64-139-1-69.sjc.megapath.net> Message-ID: <1543496292.806087.1593055800.0BF34F2C@webmail.messagingengine.com> On Fri, Oct 12, 2018, at 11:53 PM, Hal Murray via devel wrote: > Context is de-bashing tests/option-tester.sh and tests/python3-tester.sh Now that I got my home CI system up and running again, I see this fails for Ubuntu 14, too. [ubu14-test1] $ /bin/sh -xe /tmp/jenkins1012014110254104847.sh + ./tests/option-tester.sh ./tests/option-tester.sh: 12: set: Illegal option -o pipefail From gem at rellim.com Thu Nov 29 21:47:57 2018 From: gem at rellim.com (Gary E. Miller) Date: Thu, 29 Nov 2018 13:47:57 -0800 Subject: pipefail doesn't work on NetBSD or FreeBSD In-Reply-To: <1543496292.806087.1593055800.0BF34F2C@webmail.messagingengine.com> References: <20181013045330.82B26406063@ip-64-139-1-69.sjc.megapath.net> <1543496292.806087.1593055800.0BF34F2C@webmail.messagingengine.com> Message-ID: <20181129134757.4a548431@spidey.rellim.com> Yo Jason! On Thu, 29 Nov 2018 07:58:12 -0500 Jason Azze via devel wrote: > Now that I got my home CI system up and running again, I see this > fails for Ubuntu 14, too. What shell does Ubuntu use for /bin/sh? > [ubu14-test1] $ /bin/sh -xe /tmp/jenkins1012014110254104847.sh > + ./tests/option-tester.sh > ./tests/option-tester.sh: 12: set: Illegal option -o pipefail How about yoou just comment out line 12? RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem at rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can?t measure it, you can?t improve it." - Lord Kelvin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 851 bytes Desc: OpenPGP digital signature URL: From hmurray at megapathdsl.net Thu Nov 29 21:55:42 2018 From: hmurray at megapathdsl.net (Hal Murray) Date: Thu, 29 Nov 2018 13:55:42 -0800 Subject: pipefail doesn't work on NetBSD or FreeBSD Message-ID: <20181129215542.91905406061@ip-64-139-1-69.sjc.megapath.net> > How about yoou just comment out line 12? It's necessary. ------- You added that code when converting things from bash to sh The goal is to get the return status of the test. The problem is that it gets piped to tee so normal results see the return from tee rather than the test. -- These are my opinions. I hate spam. From gem at rellim.com Thu Nov 29 23:15:02 2018 From: gem at rellim.com (Gary E. Miller) Date: Thu, 29 Nov 2018 15:15:02 -0800 Subject: pipefail doesn't work on NetBSD or FreeBSD In-Reply-To: <20181129215542.91905406061@ip-64-139-1-69.sjc.megapath.net> References: <20181129215542.91905406061@ip-64-139-1-69.sjc.megapath.net> Message-ID: <20181129151502.75df7bde@spidey.rellim.com> Yo Hal! On Thu, 29 Nov 2018 13:55:42 -0800 Hal Murray wrote: > > How about yoou just comment out line 12? > > It's necessary. I know. I'm curious how much else will need fixing. If pipefail is the only problem then I may have a solution. > You added that code when converting things from bash to sh Yes, it removed a bashism, and worked on some POSIX shells. Silly me, I thought POSIX compliant actually meant something... > The goal is to get the return status of the test. The problem is > that it gets piped to tee so normal results see the return from tee > rather than the test. Yup. But is that the only problem left? RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem at rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can?t measure it, you can?t improve it." - Lord Kelvin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 851 bytes Desc: OpenPGP digital signature URL: From hmurray at megapathdsl.net Fri Nov 30 02:23:16 2018 From: hmurray at megapathdsl.net (Hal Murray) Date: Thu, 29 Nov 2018 18:23:16 -0800 Subject: pipefail doesn't work on NetBSD or FreeBSD Message-ID: <20181130022316.C69F1406063@ip-64-139-1-69.sjc.megapath.net> > > How about yoou just comment out line 12? ... > I know. I'm curious how much else will need fixing. If pipefail is the only > problem then I may have a solution. It dies at the end, trying to test PYTHONPATH ./tests/option-tester.sh: 98: ./tests/option-tester.sh: PYTHONPATH: parameter not set If I also comment out line 14. it works on old Ubuntu, NetBSD, and FreeBSD. -- These are my opinions. I hate spam. From hmurray at megapathdsl.net Fri Nov 30 02:16:36 2018 From: hmurray at megapathdsl.net (Hal Murray) Date: Thu, 29 Nov 2018 18:16:36 -0800 Subject: PYTHONPATH Message-ID: <20181130021637.068EE406061@ip-64-139-1-69.sjc.megapath.net> Can somebody give me a lesson in PYTHONPATH? My setup seems to work without it. ./waf configure gives a warning, but it can easily get lost is all the other stuff flying by. We should at least give a URL for a good explanation. Should waf crash rather than warn? Should it defer the test to the end where the warning might get seen? -- These are my opinions. I hate spam. From gem at rellim.com Fri Nov 30 02:37:10 2018 From: gem at rellim.com (Gary E. Miller) Date: Thu, 29 Nov 2018 18:37:10 -0800 Subject: PYTHONPATH In-Reply-To: <20181130021637.068EE406061@ip-64-139-1-69.sjc.megapath.net> References: <20181130021637.068EE406061@ip-64-139-1-69.sjc.megapath.net> Message-ID: <20181129183710.09f80bb2@spidey.rellim.com> Yo Hal! On Thu, 29 Nov 2018 18:16:36 -0800 Hal Murray via devel wrote: > Can somebody give me a lesson in PYTHONPATH? For some reason the concept is difficult for people. Basically it contains the places to look for Python modules that are not installed in the system locations. > My setup seems to work without it. Where are you modules getting isntalled to? Are you sure you have no PYTHONPATH? > ./waf configure gives a warning, but it can easily get lost is all > the other stuff flying by. Yup. Which is why many of the Python programs also give error messages when modules are not found to check the PYTHONPATH. > We should at least give a URL for a good explanation. https://docs.python.org/2/using/cmdline.html#envvar-PYTHONPATH > Should waf crash rather than warn? Certainly not. You said your system works, that would break it. PYTHONPATH is not needed to build and install. PYTHONPATH is not needed for system installs (/usr instead of /usr/local). A PYTHONPATH check is pointless for cross compiling. Very common to install NTPsec and then later fix the PYTHONPATH. > Should it defer the test to the end where the warning might get seen? If we do that for PYTHONPATH we need to do it for a ton of other stuff too. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem at rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can?t measure it, you can?t improve it." - Lord Kelvin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 851 bytes Desc: OpenPGP digital signature URL: From gem at rellim.com Fri Nov 30 02:50:16 2018 From: gem at rellim.com (Gary E. Miller) Date: Thu, 29 Nov 2018 18:50:16 -0800 Subject: pipefail doesn't work on NetBSD or FreeBSD In-Reply-To: <20181130022316.C69F1406063@ip-64-139-1-69.sjc.megapath.net> References: <20181130022316.C69F1406063@ip-64-139-1-69.sjc.megapath.net> Message-ID: <20181129185016.590ff56a@spidey.rellim.com> Yo Hal! On Thu, 29 Nov 2018 18:23:16 -0800 Hal Murray wrote: > > > How about yoou just comment out line 12? > ... > > I know. I'm curious how much else will need fixing. If pipefail > > is the only problem then I may have a solution. > > It dies at the end, trying to test PYTHONPATH Good. Then this may be the workaround for pipefal: https://stackoverflow.com/questions/13084352/how-to-implement-set-o-pipefail-in-a-posix-way-almost-done-expert-help-nee > ./tests/option-tester.sh: 98: ./tests/option-tester.sh: PYTHONPATH: > parameter not set Weird. Stupid shell. Just test that PYTHONPATH exists before trying to echo it. > If I also comment out line 14. it works on old Ubuntu, NetBSD, and > FreeBSD. Then we know what needs fixing. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem at rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can?t measure it, you can?t improve it." - Lord Kelvin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 851 bytes Desc: OpenPGP digital signature URL: From hmurray at megapathdsl.net Fri Nov 30 06:08:12 2018 From: hmurray at megapathdsl.net (Hal Murray) Date: Thu, 29 Nov 2018 22:08:12 -0800 Subject: pipefail doesn't work on NetBSD or FreeBSD Message-ID: <20181130060812.E24E8406061@ip-64-139-1-69.sjc.megapath.net> >> ./tests/option-tester.sh: 98: ./tests/option-tester.sh: PYTHONPATH: >> parameter not set > Weird. Stupid shell. Just test that PYTHONPATH exists before trying to echo > it. Actually, there is already a test. That's where it is dying. I assume we can unset whatever it is called. ------ > Good. Then this may be the workaround for pipefal: > https://stackoverflow.com/questions/13084352/how-to-implement-set-o-pipefai= > l-in-a-posix-way-almost-done-expert-help-nee We have a policy of no hacks around POSIX bugs. The referenced we page looks pretty ugly to me. How about adding a comment to the code saying "If this doesn't work, you have a buggy sh and you have to check the results by hand" -- These are my opinions. I hate spam. From rlaager at wiktel.com Fri Nov 30 14:57:53 2018 From: rlaager at wiktel.com (Richard Laager) Date: Fri, 30 Nov 2018 08:57:53 -0600 Subject: PYTHONPATH In-Reply-To: <20181130021637.068EE406061@ip-64-139-1-69.sjc.megapath.net> References: <20181130021637.068EE406061@ip-64-139-1-69.sjc.megapath.net> Message-ID: <6c4aa562-e580-c0cf-b4b5-bd034b16a9ee@wiktel.com> On 11/29/18 8:16 PM, Hal Murray via devel wrote: > Can somebody give me a lesson in PYTHONPATH? When doing a module import, Python searches a list of paths. This list is available in the Python environment as sys.path. You can see that list as follows (adjust executable names if necessary for your distro): Python 2: python -c 'import sys; print sys.path' Python 3: python3 -c 'import sys; print(sys.path)' When you run ntpsec's ./waf configure, it will print out PYTHONDIR and PYTHONARCHDIR locations. If those locations are in your sys.path already, then your current setup is fine. If those locations are not in your current sys.path, then you can add those directories to sys.path by setting the environment variable PYTHONPATH. The contents of the environment PYTHONPATH (which is colon-separated) are added to sys.path. They are added at index 1 (just after '', which represents the current working directory), so they will be search before the default directories. You can test its effects: python3 -c 'import sys; print(sys.path)' PYTHONPATH=foo python3 -c 'import sys; print(sys.path)' Note that PYTHONDIR and PYTHONARCHDIR may be the same path or different paths. NTPsec currently installs to (only) PYTHONARCHDIR, but used to install to (only) PYTHONDIR prior to: commit 767e48b051179e3ac856223ec9614a0c0131eaab Author: Ian Bruene Date: Mon Aug 13 15:00:39 2018 +0000 Changed to PYTHONARCHDIR. -- Richard From hmurray at megapathdsl.net Fri Nov 30 19:09:13 2018 From: hmurray at megapathdsl.net (Hal Murray) Date: Fri, 30 Nov 2018 11:09:13 -0800 Subject: ntpleapfetch on NetBSD Message-ID: <20181130190913.3FA9A406061@ip-64-139-1-69.sjc.megapath.net> Ian said: > That is in there because I needed to test if this worked properly and > ntpleapfetch's status is in flux at the moment anyway. It works if I change function foo to foo () Who is working on ntpleapfetch? Can I push a fix without stepping on WIP? -- These are my opinions. I hate spam. From jamesb.fe80 at gmail.com Fri Nov 30 19:24:02 2018 From: jamesb.fe80 at gmail.com (James Browning) Date: Fri, 30 Nov 2018 11:24:02 -0800 Subject: ntpleapfetch on NetBSD In-Reply-To: <20181130190913.3FA9A406061@ip-64-139-1-69.sjc.megapath.net> References: <20181130190913.3FA9A406061@ip-64-139-1-69.sjc.megapath.net> Message-ID: On Fri, Nov 30, 2018 at 11:09 AM Hal Murray via devel wrote: > It works if I change function foo to foo () > > Who is working on ntpleapfetch? Can I push a fix without stepping on WIP? > I was in !831, haven't worked on it for a while now as I think I had it ready for merge. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hmurray at megapathdsl.net Fri Nov 30 20:35:49 2018 From: hmurray at megapathdsl.net (Hal Murray) Date: Fri, 30 Nov 2018 12:35:49 -0800 Subject: Warnings from asciidoc Message-ID: <20181130203549.2510C406061@ip-64-139-1-69.sjc.megapath.net> I'm seeing a blizzard of warnings. Anybody understand this stuff? [ 52/167] Compiling docs/ntpd.txt /usr/bin/asciidoc:471: DeprecationWarning: Flags not at the start of the expression '^(?u)[^\\W\\d][-\\w]*$' return re.match(r'^'+NAME_RE+r'$',s) is not None That's on Fedora 29, asciidoc 8.6.10 -- These are my opinions. I hate spam. From gem at rellim.com Fri Nov 30 21:42:55 2018 From: gem at rellim.com (Gary E. Miller) Date: Fri, 30 Nov 2018 13:42:55 -0800 Subject: Warnings from asciidoc In-Reply-To: <20181130203549.2510C406061@ip-64-139-1-69.sjc.megapath.net> References: <20181130203549.2510C406061@ip-64-139-1-69.sjc.megapath.net> Message-ID: <20181130134255.54a9b135@spidey.rellim.com> Yo Hal! On Fri, 30 Nov 2018 12:35:49 -0800 Hal Murray via devel wrote: > I'm seeing a blizzard of warnings. Anybody understand this stuff? > > [ 52/167] Compiling docs/ntpd.txt > /usr/bin/asciidoc:471: DeprecationWarning: Flags not at the start of > the expression '^(?u)[^\\W\\d][-\\w]*$' > return re.match(r'^'+NAME_RE+r'$',s) is not None > > That's on Fedora 29, asciidoc 8.6.10 I also have asciidoc 8.6.10, but I see no such thing. I don't even see the "Compiling docs/ntpd.txt". What is your command line to get there, from a clean git clone. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem at rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can?t measure it, you can?t improve it." - Lord Kelvin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 851 bytes Desc: OpenPGP digital signature URL: From hmurray at megapathdsl.net Fri Nov 30 21:52:49 2018 From: hmurray at megapathdsl.net (Hal Murray) Date: Fri, 30 Nov 2018 13:52:49 -0800 Subject: Warnings from asciidoc Message-ID: <20181130215249.D74B1406061@ip-64-139-1-69.sjc.megapath.net> > I also have asciidoc 8.6.10, but I see no such thing. I don't even see the > "Compiling docs/ntpd.txt". What is your command line to get there, from a > clean git clone. The default is to not build documentation. Add --enable-doc -- These are my opinions. I hate spam. From gem at rellim.com Fri Nov 30 22:11:48 2018 From: gem at rellim.com (Gary E. Miller) Date: Fri, 30 Nov 2018 14:11:48 -0800 Subject: pipefail doesn't work on NetBSD or FreeBSD In-Reply-To: <20181130060812.E24E8406061@ip-64-139-1-69.sjc.megapath.net> References: <20181130060812.E24E8406061@ip-64-139-1-69.sjc.megapath.net> Message-ID: <20181130141148.6b992082@spidey.rellim.com> Yo Hal! On Thu, 29 Nov 2018 22:08:12 -0800 Hal Murray wrote: > >> ./tests/option-tester.sh: 98: ./tests/option-tester.sh: PYTHONPATH: > >> parameter not set > > > Weird. Stupid shell. Just test that PYTHONPATH exists before > > trying to echo it. > > Actually, there is already a test. That's where it is dying. > > I assume we can unset whatever it is called. Ditto. > > Good. Then this may be the workaround for pipefal: > > https://stackoverflow.com/questions/13084352/how-to-implement-set-o-pipefai= > > l-in-a-posix-way-almost-done-expert-help-nee > > We have a policy of no hacks around POSIX bugs. It ain't a bug, its a feature. What the POSIX shell is doing is well documented as expected behavior. > The referenced we page looks pretty ugly to me. Not proposed as an ultimate solution. But it is a common one used by many. It does show a way around the issue. > How about adding a comment to the code saying "If this doesn't work, > you have a buggy sh and you have to check the results by hand" Once again: Not a bug, a feature. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem at rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can?t measure it, you can?t improve it." - Lord Kelvin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 851 bytes Desc: OpenPGP digital signature URL: From gem at rellim.com Fri Nov 30 22:17:21 2018 From: gem at rellim.com (Gary E. Miller) Date: Fri, 30 Nov 2018 14:17:21 -0800 Subject: Warnings from asciidoc In-Reply-To: <20181130215249.D74B1406061@ip-64-139-1-69.sjc.megapath.net> References: <20181130215249.D74B1406061@ip-64-139-1-69.sjc.megapath.net> Message-ID: <20181130141721.4cca6d87@spidey.rellim.com> Yo Hal! On Fri, 30 Nov 2018 13:52:49 -0800 Hal Murray wrote: > > I also have asciidoc 8.6.10, but I see no such thing. I don't even > > see the "Compiling docs/ntpd.txt". What is your command line to > > get there, from a clean git clone. > > The default is to not build documentation. Add --enable-doc Thanks. Now I am building the docs. No warnings for me: [ 51/167] Compiling docs/ntp_keys.txt [ 52/167] Compiling docs/ntpd.txt [ 53/167] Compiling docs/ntpdig.txt # asciidoc --version asciidoc 8.6.10 asciidoc calls a large toolchain. Maybe another component differs between us? Here are 3 important prerequisites: app-text/docbook-xml-dtd-4.5-r1 app-text/docbook-xsl-stylesheets-1.79.1-r2 dev-libs/libxslt-1.1.32 RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem at rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can?t measure it, you can?t improve it." - Lord Kelvin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 851 bytes Desc: OpenPGP digital signature URL: From hmurray at megapathdsl.net Fri Nov 30 22:26:03 2018 From: hmurray at megapathdsl.net (Hal Murray) Date: Fri, 30 Nov 2018 14:26:03 -0800 Subject: Warnings from asciidoc Message-ID: <20181130222603.57A00406061@ip-64-139-1-69.sjc.megapath.net> > asciidoc calls a large toolchain. Maybe another component differs between = > us? > Here are 3 important prerequisites: > app-text/docbook-xml-dtd-4.5-r1 > app-text/docbook-xsl-stylesheets-1.79.1-r2 > dev-libs/libxslt-1.1.32=20 I'm on Fedora. The package names don't quite match. I've got: docbook-dtds.noarch 1.0-71.fc29 @fedora docbook-style-xsl.noarch 1.79.2-8.fc29 @fedora libxslt.x86_64 1.1.32-3.fc29 @fedora -- These are my opinions. I hate spam.