Netatalk 4.x

blake at netjibbing.com blake at netjibbing.com
Wed Feb 12 02:19:00 UTC 2025


I have made some good progress on this port. However, the startup item functionality in the profile is giving me some difficulty. 

What I have in the ports is…

startupitem.create  yes
startupitem.name    ${name}
startupitem.executable  "${prefix}/sbin/netatalk -d -F ${prefix}/etc/afp.conf"
startupitem.logfile ${prefix}/var/log/${name}.log
startupitem.logfile.stderr ${prefix}/var/log/${name}-stderr.log
startupitem.logevents yes
startupitem.pidfile auto /var/run/netatalk.pid
startupitem.debug          yes


So after building the port I’m running 
 sudo port load netatalk4

Then in the log file /opt/local/var/log/netatalk.log I see errors that seem to be from the daemondo helper tool. 
Netatalk4: Unable to launch process /opt/local/sbin/netatalk -d -F /opt/local/etc/afp.conf

Launchctl shows the following…

launchctl print system/org.macports.netatalk4
system/org.macports.netatalk4 = {
        active count = 1
        path = /opt/local/etc/LaunchDaemons/org.macports.netatalk4/org.macports.netatalk4.plist
        type = LaunchDaemon
        state = running

        program = /opt/local/bin/daemondo
        arguments = {
                /opt/local/bin/daemondo
                --label=netatalk4
                --start-cmd
                /opt/local/sbin/netatalk -d -F /opt/local/etc/afp.conf
                ;
                --verbosity=1
                --pid=fileauto
                --pidfile
                /var/run/netatalk.pid
        }

        stdout path = /opt/local/var/log/netatalk4.log
        stderr path = /opt/local/var/log/netatalk4-stderr.log
        default environment = {
                PATH => /usr/bin:/bin:/usr/sbin:/sbin
        }

        environment = {
                XPC_SERVICE_NAME => org.macports.netatalk4
        }

        domain = system
        minimum runtime = 10
        exit timeout = 5
        runs = 1
        pid = 62809
        immediate reason = speculative
        forks = 1
        execs = 1
        initialized = 1
        trampolined = 1
        started suspended = 0
        proxy started suspended = 0
        last exit code = (never exited)

        spawn type = daemon (3)
        jetsam priority = 40
        jetsam memory limit (active) = (unlimited)
        jetsam memory limit (inactive) = (unlimited)
        jetsamproperties category = daemon
        submitted job. ignore execute allowed
        jetsam thread limit = 32
        cpumon = default
        probabilistic guard malloc policy = {
                activation rate = 1/1000
                sample rate = 1/0
        }

        properties = keepalive | inferred program
}


Running the program + arguments on the shell works as expected. Possibly PATH needs to be set, but I don’t see that option in port startupitem syntax. 

Suggestions for debugging?

The software comes with a launchd plist that’s a little bare bones. I could edit/patch that for use.

Write my own launchd plist without daemondo?

Thanks,
Blake


> On Jan 22, 2025, at 7:37 PM, blake at netjibbing.com wrote:
> 
> For now focused on getting the db48 library and headers to be picked up by meson build system. Avoiding db53 for now as it's not building on arm64. 
> https://github.com/Netatalk/netatalk/issues/1909
> 
>> On Jan 22, 2025, at 1:06 AM, Sergey Fedorov <vital.had at gmail.com> wrote:
>> 
>> Netatalk can be a shim to pick this or that version, and then having several versions in parallel does not create a confusion.
>> On Jan 22, 2025 at 11:35 +0800, blake at netjibbing.com, wrote:
>>> OK thanks for that info. With Netatalk, it shows as building and running back to Snow leopard i386 now. What if I make a netatalk4 port and give that some time to bake before making changes to the netatalk port to select the newer version based on OS? Install count looks super low however. I 100% don’t want to break any older setups that already are working. 
>>> 
>>> For now I’ll focus on the meson build issues and getting that all sorted. 
>>> 
>>>> On Jan 21, 2025, at 6:11 PM, Jason Liu <jasonliu at umich.edu> wrote:
>>>> 
>>>> Take a look at the Portfile for MoltenVK:
>>>> 
>>>> https://github.com/macports/macports-ports/blob/master/graphics/MoltenVK/Portfile
>>>> 
>>>> The base MoltenVK port, which is just a stub, will select the correct versioned subport based on the user's macOS version. Unfortunately, there is no way to know how to divide up the if-else statements unless you know which macOS versions can handle which version of netatalk. The only way to find out this information is to either gather it from the historical changelogs of the upstream package, or to actually test using old macOS versions (this is really the only truly accurate method). The second method is often considered to be a compelling reason why those of us MacPorts devs who are interested in supporting older macOS versions will sometimes set up virtual machines for each and every older macOS version.
>>>> 
>>>> -- 
>>>> Jason Liu
>>>> 
>>>> 
>>>> On Wed, Jan 22, 2025 at 9:12 AM Blake Garner <blake at netjibbing.com <mailto:blake at netjibbing.com>> wrote:
>>>>> I like that idea. Is there a good example port that already does this? My plan is to get a functional PR started and hope for some collaborative advice.  
>>>>> 
>>>>> I’m not very interested in spending a lot of effort testing every possible version of macOS. Can these supports have their own supported macOS versions? 
>>>>> 
>>>>> Can older OS versions select the netatalk2 support? 
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Jan 20, 2025, at 6:37 PM, Sergey Fedorov <vital.had at gmail.com <mailto:vital.had at gmail.com>> wrote:
>>>>>> 
>>>>>> 
>>>>>> Yeah, this is a better idea, perhaps.
>>>>>> 
>>>>>> On Tue, Jan 21, 2025 at 10:13 AM Jason Liu <jasonliu at umich.edu <mailto:jasonliu at umich.edu>> wrote:
>>>>>>> Whoever updates the Portfile, can you make sure to preserve the old version(s) of netatalk using a versioned subport, i.e. 'netatalk3', 'netatalk2' (or whatever), so that old versions of macOS can still use the older netatalk packages? I think that the 'netatalk' port should be whatever is the latest version of the package, instead of having a new port called 'netatalk4'.
>>>>>>> 
>>>>>>> -- 
>>>>>>> Jason Liu
>>>>>>> 
>>>>>>> 
>>>>>>> On Tue, Jan 21, 2025 at 4:28 AM Sergey Fedorov <vital.had at gmail.com <mailto:vital.had at gmail.com>> wrote:
>>>>>>>> I had a port for netatalk 3 somewhere; as I recall, it needed some fixes for the build. That was a while ago, I do not know what is the current status.
>>>>>>>> Very much likely that netatalk 4 will be broken on older systems and possibly less useful than earlier versions.
>>>>>>>> So yeah, I think it should be a separate port rather than an upgrade of existing one.
>>>>>>>> 
>>>>>>>> On Tue, Jan 21, 2025 at 3:23 AM <blake at netjibbing.com <mailto:blake at netjibbing.com>> wrote:
>>>>>>>>> The Netatalk package has seen some serious updates recently with a new team working on it. I have made a couple efforts and getting a working port for the 4.x versions but meson build system is tripping me up. Also looking at compatbility it seems like we would want a netatalk4 package vs just updating the netatalk package. That said there is a support statment to consider. 
>>>>>>>>> 
>>>>>>>>> "18th of January 2025
>>>>>>>>> The Netatalk Project has published its End of Life policy. We guarantee that each release series will be supported with security patches for 12 months after the release of the superseding feature release.
>>>>>>>>> Most urgently, this means that the long-running 3.1 release series will be out of support after May 31st, 2025. Users and downstream packagers are encouraged to upgrade to the latest Netatalk 4.1 release series."
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> My “works on my machine” WIP for the port https://github.com/trodemaster/macports-ports/blob/add-netatalk4/net/netatalk4/Portfile
>>>>>>>>> 
>>>>>>>>> The meson build system only has one flag for the path to bdb for example. With include and lib needing to be specified for MacPorts compatibility, it seems like I would need to hack up the meson config to get the current version to build. For no I’m pointin to some local filesystem as a hack to make it build.
>>>>>>>>>  /Users/blake/scratch/netatalk/bdb/
>>>>>>>>> ├──  db48 -> /opt/local/lib/db48/
>>>>>>>>> ├──  include -> /opt/local/include/db48/
>>>>>>>>> └── lib -> /opt/local/lib/db48/
>>>>>>>>> 
>>>>>>>>> There are also a bunch of other binaries that are part of hte package and having those built as variants seems like a good plan. See features setion https://netatalk.io <https://netatalk.io/>
>>>>>>>>> 
>>>>>>>>> Suggestions for ports using meson that are good reference?
>>>>>>>>> 
>>>>>>>>> Homebrew reference https://github.com/Homebrew/homebrew-core/blob/67dd3977058cd517d3d5394afd400ad00e708f38/Formula/n/netatalk.rb
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> Blake
>>>>>>>>> 
>>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20250211/05787265/attachment-0001.htm>


More information about the macports-dev mailing list