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, [email protected] 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 <[email protected]> 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, [email protected], 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 <[email protected]> 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 <[email protected]
>>>> <mailto:[email protected]>> 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 <[email protected]
>>>>>> <mailto:[email protected]>> wrote:
>>>>>>
>>>>>>
>>>>>> Yeah, this is a better idea, perhaps.
>>>>>>
>>>>>> On Tue, Jan 21, 2025 at 10:13 AM Jason Liu <[email protected]
>>>>>> <mailto:[email protected]>> 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 <[email protected]
>>>>>>> <mailto:[email protected]>> 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 <[email protected]
>>>>>>>> <mailto:[email protected]>> 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
>>>>>>>>>
>>>
>
