--enable-doc waf config option removed
It looks like the --enable-doc waf configuration option was removed in the commit "Add support for other asciidoc processors". Was there any discussion about this change? ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: All hands - we need to test Fred's build changes pronto
On Tue, Sep 26, 2017 at 5:35 AM, Eric S. Raymond via devel wrote: > Please, everybody get on the stick and test on every platform you can > reach. We need to know that, *without* a PYTHONPATH set, I tested CentOS 6.6. I used to have to export PYTHONPATH on this platform. Now all tools in build/main/ntpclients/ run without setting PYTHONPATH. OS: CentOS release 6.6 (Final) Python: Python 2.6.6 NTPsec: [root@cent66-pa18 ntpsec]# ./build/main/ntpd/ntpd --version ntpd ntpsec-0.9.7+1409 2017-09-26T07:36:31-0400 [root@cent66-pa18 ntpsec]# git show --oneline f7d063e Renove a magic link obsolesced by PYTHONPATH changes. To test I did a fresh clone on a machine where I've never run NTPsec before. I ran the buildprep script, ./waf configure, ./waf build, ./waf install (all as root) then successfully ran the various tools in build/main/ntpclients/ (except for ntpleapfetch due to an unrelated problem with shasum. I'll open a tracker issue for it.) ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Duplicate issue-closed messages
On Wed, Sep 27, 2017 at 1:28 PM, Hal Murray via devel wrote: > I'm getting duplicates of issue-closed messages from gitlab. > > Are you doing anything interesting? Is anybody else getting them? I also got a duplicate on the ntpleapfetch closure message. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Fix for Python library path problem
On Wed, Sep 27, 2017 at 4:19 PM, Eric S. Raymond via devel
wrote:
> Just to be sure, though, people with access to other platforms - like Red Hat
> and FreeBSD - should run these checks in Python
>
[x for x in sys.path if x.find('/usr/lib') != -1]
>
[x for x in sys.path if x.find('/usr/lib') != -1 and x.replace('/usr/lib',
'/usr/local/lib') == -1]
>
> If the second one ever comes up non-empty we could have a problem.
I checked CentOS 6.9 and CentOS 7.3 and, after I figured out I had to
import sys, I can confirm that the second expression comes back empty.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: Is it time to plan a move to Go?
Whoops. I failed to list reply. On Mon, Nov 6, 2017 at 4:44 PM, Jason Azze wrote: > On Sat, Nov 4, 2017 at 7:59 PM, Eric S. Raymond via devel > wrote: >> Here's my big question about the next year of development: should we >> be moving the codebase out of C to Go? > > Would this be a direct translation--warts and all? Do you refactor as > you translate? > > I've worked on infrastructure projects before where the task was to > move a complex service to a greenfield with the mandate "don't change > anything about how the service functions, just move the thing, we'll > optimize later." > > I can testify that the temptation to rebuild things as you go in this > scenario is overwhelming at times. We get into a lot of friendly > arguments about what "warts" to preserve for the sake of being able to > trace breakage to a very limited set of changes. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Help debugging gitlab and/or shell script
On Fri, Nov 24, 2017 at 2:51 AM, Hal Murray via devel wrote: > Did this work before my change? Is somebody working on the gitlab stuff and > my push just happened at the right time to uncover a bug? I suspect this was a transient CI error or possibly related to work Matt was doing at that time (as you suggest). It looks like the CI build for that commit recovered automagically on a second try. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Testing
On Wed, Dec 6, 2017 at 2:22 PM, Matthew Selsky via devel wrote: > We also don't have formal code reviews (before commit) since many devs push > directly to "master". So we can't enforce any policies to code before they > get committed to master. > > At some point, maybe soonish, can we stop pushing directly to master and > instead push to branches (either in the main repo, or a personal fork) and > then submit MRs and go through the review/approval workflow that's built into > GitLab? There's a lesser variation of code-review-as-quality-gate that might satisfy ESR's desire for rapid response and turnaround, but that will still add a layer of defense against some kinds of errors. I'm not sure if the Gitlab CI system can do this: Everyone pushes commits to a single working branch. These commits are built and tested by the CI automation. IFF the code builds and tests pass then the CI system auto-merges with the master branch. If an auto-merge isn't possible, it gets bounced to a human for intervention. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Does ntpq have a command line history mechanism?
On Sat, Dec 23, 2017 at 3:24 PM, Eric S. Raymond via devel wrote: > > This is highly annoying. We've done someting in our interpreter that busts > that feature, but it is not obvious what. Perhaps the polyglot changes? > > I'll dig into this further when I get back from sword class > -- > I happen to have an older version of NTPsec installed on this here Ubuntu 16.04.2 box. My up and down arrows work in ntpq. root@protactinium:/home/jazze/code/ntpsec# ntpq -V ntpq ntpsec-0.9.7+68 2017-03-31T08:38:03Z ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
./waf install is not idempotent?
While freshening my NTPsec install to test the ntpq command history
bug, I accidentally ran ./waf install twice in a row because I thought
I had forgotten to run it at all. I thought I had forgotten because
ntpq -V still showed my old version 0.9.7+68.
On the second run, (which at the moment I thought was the first), I
got a Python error.
```
Waf: Leaving directory `/home/jazze/code/ntpsec/build/main'
Build failed
Traceback (most recent call last):
File
"/home/jazze/code/ntpsec/.waf-1.9.14-d7f6128a2aa20a656027b134f0b4f4a6/waflib/Task.py",
line 145, in process
ret=self.run()
File
"/home/jazze/code/ntpsec/.waf-1.9.14-d7f6128a2aa20a656027b134f0b4f4a6/waflib/Build.py",
line 564, in run
fun(x.abspath(),y.abspath(),x.path_from(launch_node))
File
"/home/jazze/code/ntpsec/.waf-1.9.14-d7f6128a2aa20a656027b134f0b4f4a6/waflib/Build.py",
line 600, in do_install
raise Errors.WafError('Could not install the file %r'%tgt,e)
WafError: Could not install the file
'/usr/local/lib/python2.7/dist-packages/ntp/control.pyc'
```
On the third run, ./waf install worked fine and installed the correct
version of ntpq.
So . . . I just kept running ./waf install, and I think it just cycles
through these three modes:
1) installs ntpq 0.9.7
2) Python error
3) installs ntpq 1.0.1+183
I ran a ./waf distclean before my configure, build, install steps. I
will try from a fresh clone.
Before I open a GitLab issue, is this unexpected behavior?
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: ./waf install is not idempotent?
On Sat, Dec 23, 2017 at 5:47 PM, Hal Murray wrote: > >> I ran a ./waf distclean before my configure, build, install steps. I will >> try from a fresh clone. > >> Before I open a GitLab issue, is this unexpected behavior? > > It sure looks unexpected to me. There shouldn't be anything about 0.9.7 > left. (except in history) > > Try grepping for 0.9.7 and see if you find anything interesting. A bunch of stuff in the packaging directory under SUSE and RPM, and this: ./pylib/version.py:VCS_TAG = "NTPsec_0_9_7" ./pylib/version.py:VERSION = "0.9.7" I could not reproduce the weirdness with a fresh clone. So, as I've said before, ./waf distclean can't be trusted and ./waf clean can be trusted even less. :-) ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpd/varsion.h
On Sun, Dec 24, 2017 at 3:02 PM, Fred Wright via devel wrote: > > The GPSD approach isn't necessarily ideal, but it's a lot less > inconvenient than what ntpsec currently does. Let's not copy exactly what gpsd does. I have bug #52661 "gpsd -V - Different version strings generated between shallow clone and full clone builds" open against it right now. :-) ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Request for data / ntpsnmpd report
On Tue, Jan 9, 2018 at 10:26 AM, Ian Bruene via devel wrote: > > I have nearly finished filling out the MIB tree for SNMP. What gaps are left > involve data I do not know how to get: At the risk of sounding like a drop-out from a Scrum Master training camp, could you explain briefly what the "story" is for this tool? I use SNMP every day to monitor the health of lots of servers and services, but, to be honest, I haven't been able to follow what you're trying to achieve with ntpsnmpd. If I run it on a time server, will I (in my capacity as a sysadmin running time servers) be able to aim my monitoring system at it make queries about the state of ntpd? Health and performance monitoring is certainly my use case for ntpviz. It would be great to be able to get metrics from time servers using monitoring tools I'm familiar with (Cacti, Icinga, Nagios, OpenNMS, etc.). Just to clarify, I'm not criticizing your effort or purpose. I just literally don't know what the goal is even though I feel like I've been following along. Best, Jason ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.0.1 and ntpsnmpd
On Mon, Feb 26, 2018 at 7:18 PM, Richard Laager via devel wrote: > On 02/26/2018 06:16 PM, Sanjeev Gupta wrote: >> Richard, I am using cacti. > > That's what I was hoping to hear, since I also run Cacti. Are you > willing to share your templates? I'm also a Cacti user, though it has been years since I logged on to the Cacti forums to search for a template. If you have one that works, Sanjeev, I'd also like to get in on the action. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: More gitlab quirks: What is this trying to tell me?
On Tue, Feb 27, 2018 at 3:46 PM, Hal Murray via devel wrote: > > What does "pages:deploy" do? On the diagram of all the steps, it's the lower > of the pair on the right. > It looks like it is a CI job dedicated to: python ./waf configure --enable-doc --prefix=/tmp/docbot-local --htmldir=`pwd`/public/latest/ build install I discovered this by examining the console output of one of the successful runs. The failed build you saw doesn't provide any useful diagnostic info that I can see. I suspect it was a transient failure in the CI system on gitlab. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.0.1 and ntpsnmpd
On Fri, Mar 2, 2018 at 12:17 AM, Sanjeev Gupta wrote: > Please see > > https://github.com/netniV/cacti-templates/tree/master/NTP > Sanjeev, was this template created in response to your bounty? I finally worked through getting ntpsnmpd up and talking to AgentX on my test machine, but all of my Cacti graphs from netniV's template come up NaN. Ian, could you recommend an snmpwalk command or something similar that will help answer the question: "How do I know I've got ntpsnmpd working?" ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.0.1 and ntpsnmpd
On Thu, Mar 15, 2018 at 7:09 PM, Sanjeev Gupta wrote: > Jason, yes, that is the result of the bounty offer. > > I have not had a chance to play with it, but the offer included a > requirement to upstream into cacti and provide a working example. > For reasons I can't explain yet, my Cacti server started collecting data presented by ntpsnmpd at about 2030 UTC last night. I may have restarted a service while flailing around before leaving the office. To expand on Ian's answer to my question "How do I know I've got ntpsnmpd working?", you should be able to get back data from snmp walking like this (assuming you're using public as your community string because, like me, you were too lazy to change it.): :~ $ snmpwalk -v 2c -c public localhost .1.3.6.1.2.1.197.1.3.1.1.1 iso.3.6.1.2.1.197.1.3.1.1.1.1 = Gauge32: 13212 iso.3.6.1.2.1.197.1.3.1.1.1.2 = Gauge32: 13214 iso.3.6.1.2.1.197.1.3.1.1.1.3 = Gauge32: 13216 iso.3.6.1.2.1.197.1.3.1.1.1.4 = Gauge32: 13217 iso.3.6.1.2.1.197.1.3.1.1.1.5 = Gauge32: 13218 iso.3.6.1.2.1.197.1.3.1.1.1.6 = Gauge32: 13219 iso.3.6.1.2.1.197.1.3.1.1.1.7 = Gauge32: 13220 iso.3.6.1.2.1.197.1.3.1.1.1.8 = Gauge32: 13221 iso.3.6.1.2.1.197.1.3.1.1.1.9 = Gauge32: 13222 iso.3.6.1.2.1.197.1.3.1.1.1.10 = Gauge32: 13223 :~ $ snmpwalk -v 2c -c public localhost .1.3.6.1.2.1.197.1.3.1.1.2 iso.3.6.1.2.1.197.1.3.1.1.2.1 = STRING: "0.0.0.0" iso.3.6.1.2.1.197.1.3.1.1.2.2 = STRING: "208.88.126.235" iso.3.6.1.2.1.197.1.3.1.1.2.3 = STRING: "129.250.35.251" iso.3.6.1.2.1.197.1.3.1.1.2.4 = STRING: "209.242.224.97" iso.3.6.1.2.1.197.1.3.1.1.2.5 = STRING: "162.210.111.4" iso.3.6.1.2.1.197.1.3.1.1.2.6 = STRING: "38.229.71.1" iso.3.6.1.2.1.197.1.3.1.1.2.7 = STRING: "174.138.107.37" iso.3.6.1.2.1.197.1.3.1.1.2.8 = STRING: "69.164.213.136" iso.3.6.1.2.1.197.1.3.1.1.2.9 = STRING: "35.171.237.77" iso.3.6.1.2.1.197.1.3.1.1.2.10 = STRING: "65.19.142.137" etc. Or, for the whole deal, just do snmpwalk -v 2c -c public localhost .1.3.6.1.2.1.197.1.3.1.1 I've got graphs! https://imgur.com/a/uXMdK ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: How do I fix a typo in a git commit comment?
On Sun, Mar 25, 2018 at 9:15 PM, Eric S. Raymond via devel wrote: > > A lot of typos got fixed when the GPSD repo moved off Savannah. Did gpsd get moved off of Savannah? To where? I missed that. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Something broken - decodenetnum
On Wed, May 2, 2018, at 4:30 PM, Matthew Selsky via devel wrote: > Maybe the docker images that clang-* and python-coverage are based on I agree. It looks like the failing runs are all . . . Using docker image sha256:e7bdbd137f66d65e7cecae48f860acb0dbbfcfd3426d9282a16c3940f3fcf330 for ruby:2.5 ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Using Heaptrack to Find Memory Leaks
I mentioned on the IRC channel that I was playing with a tool called Heaptrack, which I read about on Hacker News, to search for why the memory footprint of ntpd is (is it?) larger than we expect. I found a leak that ESR said looked "pretty nasty." Because I have no idea what I'm doing with debugging symbols, profilers, etc. -- I'll write down the steps to reproduce the report I'm looking at. Here's the Heaptrack release announcement https://www.kdab.com/heaptrack-v1-1-0-release/ Here's the source code https://github.com/KDE/heaptrack I grabbed the Appimage from one of these mirrors https://download.kde.org/stable/heaptrack/1.1.0/heaptrack-v1.1.0-x86_64.AppImage.mirrorlist and saved it to my Ubuntu 16.04 box, which is named tin. # I got a fresh clone of NTPsec. ~/code $ git clone https://gitlab.com/NTPsec/ntpsec.git ~/code $ cd ntpsec # Configure for a build with debugging symbols [master]:~/code/ntpsec $ ./waf configure --enable-debug-gdb [master]:~/code/ntpsec $ ./waf build [master]:~/code/ntpsec $ sudo ./waf install # Or, if you are GEM, do this as root. Now become root in your favorite way. I didn't have luck with Heaptrack using sudo. (See, GEM is right.) #Make sure ntpd isn't running. # for systemd (my case) root@tin:~# systemctl stop ntp root@tin:~# ps -ef |grep [n]tpd # Looks good # Now start ntpd wit the Heapcheck Appimage. The -n (no fork) is important, otherwise I think you only catch ntpd dropping root. root@tin:~# /home/jazze/installers/heaptrack-v1.1.0-x86_64.AppImage /usr/sbin/ntpd -p /var/run/ntpd.pid -g -n -c /etc/ntp.conf -u 121:130 # Note, id 121:130 is ntp:ntp on my machine. ymmv Let ntpd cook for as long as needed. I don't know how long that is. In another shell, find the ntpd PID and kill it. root@tin:~# ps -ef |grep [n]tpd root 3227 28886 0 14:02 pts/21 00:00:00 /bin/bash /tmp/.mount_heaptrUKPaLq/AppRun /usr/sbin/ntpd -p /var/run/ntpd.pid -g -n -c /etc/ntp.conf -u 121:130 root 3229 4024 0 14:02 ?00:00:00 /home/jazze/installers/heaptrack-v1.1.0-x86_64.AppImage /usr/sbin/ntpd -p /var/run/ntpd.pid -g -n -c /etc/ntp.conf -u 121:130 root 3234 3227 0 14:02 pts/21 00:00:00 /bin/sh /tmp/.mount_heaptrUKPaLq//opt/bin/heaptrack /usr/sbin/ntpd -p /var/run/ntpd.pid -g -n -c /etc/ntp.conf -u 121:130 ntp 3249 3234 2 14:02 pts/21 00:00:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -n -c /etc/ntp.conf -u 121:130 root@tin:~# kill 3249 Now in the shell where you launched Heaptrack, you should see something like: heaptrack stats: allocations:798 leaked allocations: 170 temporary allocations: 127 Heaptrack finished! Now run the following to investigate the data: heaptrack --analyze "/root/heaptrack.ntpd.3234.zst" The advice for launching the analyzer isn't perfect, because we're using the Appimage. Instead do: root@tin:~# /home/jazze/installers/heaptrack-v1.1.0-x86_64.AppImage --analyze "/root/heaptrack.ntpd.3234.zst" You should get a GUI report. I believe Heaptrack has some CLI-only reports, which you may find more tasteful, but I can't figure out how to get heaptrack_print. Maybe if you build from source. Best, Jason ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Why admin's do not trust daemons to do their own packet filtering (was Re: Resuming the great cleanup)
On Tue, May 29, 2018, at 4:28 PM, Richard Laager via devel wrote: > Choosing _which_ interfaces to listen() on at all is not userspace > packet filtering. This is my instinct as well. I suspect I don't understand what we're talking about, so I am hesitant to comment. Are you suggesting removing the feature that makes ntpd configurable to listen on a specified interface so that it will instead listen on all interfaces (including docker0, vibr0, etc.) with the idea that -- if a sysadmin wanted ntpd to use only one interface, they "shoulda used Netfilter"? I'd be pretty pissed off if, let's say, the Postfix or MySQL people took this attitude. That's why I think I'm misunderstanding. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Preparing for upcoming release
On Mon, Aug 13, 2018, at 4:54 PM, Eric S. Raymond via devel wrote: > That was my intent. I'll remove the comment and keep an ear out for any > report > of CentOS operation going sproing. I updated #450 with a report of CentOS/RHEL behavior as I observed it this morning. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Anybody testing/using Big endian?
On Fri, Aug 24, 2018, at 10:51 PM, Hal Murray via devel wrote: > > On a PowerPC: > > TEST(numtoa, RefidStr)../../tests/libntp/numtoa.c:19::FAIL: Expected > '68.51.34.17' Was '17.34.51.68' > > It's probably a bug in the test code. > I'm working, very very slowly, on setting up a CI runner on the University of Campinas' OpenPower minicloud. I got as far as creating an account for us, getting approval, and then setting up a VM that turned out to be little endian. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: --- PYTHONDARCHIR not in PYTHONPATHloading the Python ntp library may be troublesome ---
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. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: pipefail doesn't work on NetBSD or FreeBSD
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 ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
ntpsnmpd testing notes
Mostly for Ian, who was trying to recall where he left off with ntpsnmpd. I had a working ntpsnmpd instance running on a workstation which has, sadly, been consumed by entropy along with the rest of the assay I was using. However, I do recall that I had a Cacti instance collecting data from ntpsnmpd and drawing pretty graphs for me. The configuration and setup documentation, IIRC, needed work (or, perhaps, to be written). And I was doing something crude to start the service (rc.local). I had this in my /etc/rc.local because I was too lazy to write a systemd unit file. /usr/local/bin/ntpsnmpd Then I had a file, /etc/ntpsnmpd.conf that contained: master-addr "/var/agentx/master" ntp-addr "127.0.0.1" logfile "/var/log/ntpsnmpd.log" loglevel 8 Hope that helps the recollection process. -- Jason Azze ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: no ssl.h on macos?
On Sat, Feb 9, 2019, at 8:28 AM, Hal Murray via devel wrote: > I thought we got farther than this last night. > > Does macos have OpenSSL? What version? > This ( https://stackoverflow.com/questions/43415106/openssl-conf-h-file-not-found-error-on-macos-sierra) stackoverflow answer suggests it does, but it's deprecated. It makes the following suggestion: " Apple has deprecated use of OpenSSL in favor of its own TLS and crypto libraries If you need to have this software first in your PATH run: echo 'export PATH="/usr/local/opt/openssl/bin:$PATH"' >> ~/.zshrc For compilers to find this software you may need to set: LDFLAGS: -L/usr/local/opt/openssl/lib CPPFLAGS: -I/usr/local/opt/openssl/include For pkg-config to find this software you may need to set: PKG_CONFIG_PATH: /usr/local/opt/openssl/lib/pkgconfig " ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: The libaes_siv dependency
On Thu, Feb 14, 2019, at 12:56 PM, Eric S. Raymond via devel wrote: > I've added a mandatory waf check for the libaes_siv library. [snip] > At some point it will probably be taken into OpenSSL and this separate > dependency will go away. Hmmm. I certainly understand why this is necessary to move forward with NTS development, but it leaves me unsure how to proceed with the CI system I run (separate from the GitLab CI that Matt manages). My, admittedly arbitrary, approach is to build NTPsec on various Linux distros using the NTPsec source code from GitLab and only _packaged_ dependencies from those distros. I chose this approach because I think it's something a conservative sysadmin would be willing to do if they wanted to try NTPsec as a replacement for classic. Package maintainers will also be looking for a simple build process. Now that we've introduced a dependency on a "third-party library" (even though Daniel ain't really a third party!) that isn't packaged by anyone as far as I can tell -- my builds are all broken. And I think they should remain broken until they again meet my arbitrary standard. I also wonder if the distro packagers who've been friendly to the project so far will be willing to build a third-party dependency. But I'll let them speak for themselves. I predict that ESR will ask me for an alternative approach. He won't like my recommendation. It's to use a feature or development branch for a change as big as the introduction of NTS. -- Jason ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
