All:

I've added a compiler switch -DNO_UPGRADE which disables both the manual
and automatic upgrade ability of hamclock.  Just add it to CXXFLAGS in the
Makefile.

This will be in the next release V4.20. I can also send a beta version now
if anyone wants to try it.

Elwood



On Wed, Jun 18, 2025 at 3:49 PM Elwood Downey <[email protected]>
wrote:

> Hello Jim,
>
> Wow, I am humbled and honored by the massive outpouring of support from
> the macports experts.
>
> Please see comments embedded below.
>
>
>
> On Wed, Jun 18, 2025 at 2:20 PM Jim DeLaHunt <[email protected]>
> wrote:
>
>> Hello, Elwood Downey, and welcome to MacPorts-dev!
>> On 2025-06-17 21:20, Elwood Downey wrote:
>>
>> ...I skimmed your instructions for submitting a new port but 1) I do not
>> have and do not want a github account and 2) I am super lazy when it comes
>> to systemy things, I only enjoy programming.
>>
>> So on the outside chance someone else would be willing to do it all for
>> me, I hereby humbly submit my amateur radio program HamClock
>> <https://clearskyinstitute.com/ham/HamClock> for consideration as a new
>> port.
>> ...[elided]...
>> name                hamclock
>> version             4.18
>> categories          amateur radio
>> platforms           darwin
>> license             MIT
>> maintainers         Elwood Downey, [email protected]
>> description         provides useful data for amateur radio operators
>> long_description    HamClock is a kiosk-style application that provides
>> real time space weather, radio propagation models, operating events and
>> other information particularly useful to the radio amateur.
>> homepage            https://www.clearskyinstitute.com/ham/HamClock
>> master_sites
>> https://www.clearskyinstitute.com/ham/HamClock/ESPHamClock.tgz
>>
>> What a lovely project! HamClock appears to integrate a lot of useful data
>> from many sources. I can imagine it being very valuable to the people for
>> whom it is intended. It would be a fine port IMHO.
>>
>
>
> Thank you for the kind words. According to my nightly scrub of server
> logs, there are about 10k hamclock instances running each day so evidently
> there is some agreement with your sentiment.  Unfortunately, the same logs
> report only a dozen or so instances running on macOS. This is ironic
> because HamClock development has always been entirely on macOS, with just
> basic regression testing performed before each release on a few linux
> distros, freebsd, solaris and aix.
>
>
> I took the liberty of doing a "systemy thing" for you: creating a Macports
>> trac ticket #72625[1] requesting that a port be created for Hamclock. This
>> doesn't commit me or anyone else to do the work, but it provides a starting
>> point for anyone interested. It includes a link to this thread[2] in the
>> macports-dev archives.
>>
>
> Yes, I received that and replied much as I will here to your same question.
>
>
> From my limited experience writing ports, I can imagine five or so
>> hurdles.
>>
>> One, as Ryan said, HamClock's self-update function conflicts with a
>> macports principle that ports don't modify themselves, only macports
>> modifies ports.
>>
>
> This policy comes as a surprise. I have been issuing new releases of
> HamClock at least monthly, or even daily when a significant bug
> needs attention, for the past ten years. It sounds like it will be quite a
> chore to keep the macport up to date. I'm certainly willing to accommodate
> but we'll have to hash out a mechanism.
>
>
>
>
>> Two, and related, there appears to be only URLs for the current version
>> of the source code, while macports works better with repositories which
>> offer URLs for each software version. So for HamClock that might be:
>>
>>  https://www.clearskyinstitute.com/ham/HamClock/4.18/ESPHamClock.tgz
>>
>>
> Older versions going back about a year are already online, the following
> example shows the pattern:
>
> https://clearskyinstitute.com/ham/HamClock/ESPHamClock-V4.19.tgz
>
> If we pick one for macports I will update my scripts to ensure it remains
> online forever.
>
>
>
> Normally, macports deal with target project version changes by having
>> someone update the portfile and submit it to Macports. Each version of a
>> portfile describes a specific version of the target project, and gives a
>> specific URL for that verion of the target project's source code. When the
>> target project releases a new version, someone notices and updates the
>> portfile to specify the new version and the new download URL. They submit
>> the new portfile to Macports. Eventually Macports users update their
>> Portfile collection from Macports. Then the user's copy of Macports becomes
>> aware of the new port version, and offers to perform the update.
>>
>> Three, as Dave Allured points out, the portfile author needs to figure
>> out what other libs HamClock depends on, and which ports supply those libs.
>> These dependencies get recorded in the portfile.
>>
>
> The only extra library HamClock uses is -lX11, nothing else. The only
> include files other than from POSIX are Xlib.h and Xutil.h. I admit I've
> never used the macports xorg so I don't know what it takes to use that one.
> I have always used Xquartz which puts these in /opt/X11.
>
> However, the top level Makefile does recurse into a few subdirectories to
> build libraries that are eventually used for linking. I guess your system
> can accommodate that in some manner.
>
>
>
>
>> Four, the HamClock top-level Makefile hard-codes some install paths and
>> library paths. The portfile will need to patch these. That is a normal
>> thing to do, and functions exist to do it, but it will be an extra task for
>> the portfile author.
>>
>> Five, HamClock can display graphics at various horizontal and vertical
>> pixel sizes, and as a local display (via X11) or as a web service. The
>> portfile can offer "variants" as a way to let the user choose these options
>> at build time. The portfile author might choose to offer these variants,
>> and tie them back to the Makefile targets. That is a further task.
>>
>
> This is currently handled with different *make* targets by just changing
> a few compiler -D flags. In fact, the default Makefile target just lists
> these, it does not build anything. Again, something to keep in mind in the
> macport version.
>
>
>
>> Also, at the risk of distracting you with "systemy" things, might I
>> suggest a few clarifications to the HamClock website[3]?
>>
>>    - The download tab did not make it clear to me that it offered source
>>    code. I interpreted it as offering precompiled binaries. Consider adding a
>>    subheading "Source code" before the first line of the tab, and changing 
>> the
>>    following line "revision history" to be a subheading.
>>
>>
> You just missed it, the first line of the Download tab clearly states,
> quote "*Download current stable HamClock release source code as zip or
> tgz.*".
>
>
>
>>
>>    - If you decide to have separate URLs to the various versions of the
>>    source code, then maybe you will want somewhere a list of versions, each
>>    with the download link for that version's source code.
>>
>>
> I do not publish URLs to prior versions intentionally. I don't want people
> to silently regress to avoid bugs, I want to know about them immediately so
> they are fixed.
>
>
>
>
>>    - The website doesn't make it clear that the project's code is freely
>>    licensed. Yes, the source code archive has a LICENSE file containing the
>>    MIT licence text, but that isn't visible before downloading. Consider
>>    having a tab "License", or a link from a relevant place like the source
>>    code link in the Download tab, pointing to the software license.
>>
>>
> You are quite correct so I have added FAQ 63 to answer this question.
>
>
>
>>
>>    -
>>    - Do you seek contributions of bug fixes and patches with
>>    improvements?  If so, I would expect to see a tab reading "How to
>>    contribute" or the like. I don't see that.
>>
>>
> No, I do not actively seek code submissions. All but a very few that I
> have received unsolicited did not meet my standards.
>
> But what I do encourage is submission of bug reports and feature ideas,
> these are sprinkled liberally throughout the FAQ answers.
>
>
>
>>
>>
>> Overall, HamClock looks like a lovely project. Thank you for proposing it
>> to macports. I hope someone takes the offer and finishes the portfile.
>>
>
> Looking forward to it.
>
>
>>
>> Best regards,
>>     —Jim "VE7YJD" DeLaHunt
>>
>>
>>
> 73
>
>
>> [1] hamclock: make a port for Hamclock project
>> <https://trac.macports.org/ticket/72625>
>> <https://trac.macports.org/ticket/72625>
>> [2] thread "submitting a new port, sort of"
>> <https://lists.macports.org/pipermail/macports-dev/2025-June/046320.html>
>> <https://lists.macports.org/pipermail/macports-dev/2025-June/046320.html>
>> [3] <https://www.clearskyinstitute.com/ham/HamClock/>
>> <https://www.clearskyinstitute.com/ham/HamClock/>
>>
>>
>> --
>> .   --Jim DeLaHunt, [email protected]     http://blog.jdlh.com/ 
>> (http://jdlh.com/)
>>       multilingual websites consultant, Vancouver, B.C., Canada
>>
>>

Reply via email to