dbus does not install startupitem into /Library/LaunchAgents (was: Re: [MacPorts] KDE modified)

Joshua Root jmr at macports.org
Tue Jun 12 07:27:10 UTC 2018


The good news is that dbus shouldn't have to do most of these
workarounds any more. See
<https://github.com/macports/macports-ports/pull/2009>.

- Josh

On 2018-6-12 09:15 , Marcus Calhoun-Lopez wrote:
> Hopefully,
> https://github.com/macports/macports-ports/commit/9f3777a4f2afc180693e8ee9ae98829c25fcacba
> fixes the problem.
> 
> I have no idea how this has not been a problem before.
> Sorry for the error.
> 
> -Marcus
> 
> 
>> On Jun 11, 2018, at 3:22 PM, Rainer Müller <raimue at macports.org> wrote:
>>
>> On 2018-06-11 17:29, Jonathan Stickel wrote:
>>> OK. Now I see the symlink for org.macports.kdecache.plist, but the
>>> symlink for org.freedesktop.dbus-session.plist is definitely missing on
>>> my machine. As a consequence, dbus was not loaded in launchctl and KDE
>>> apps would not run for me this morning (until I loaded directly from
>>> /opt/local/Library/...). I do not have startupitem_install in my
>>> macports.conf, and so the default 'yes' should be in effect.
>>>
>>> Feel free to unroll my wiki edit (or I can do it). Should I open a bug
>>> on trac for dbus?
>>
>> Indeed, something is broken with dbus. 'port notes dbus' also shows the
>> wrong paths.
>>
>> dbus @1.12.2_0 still provided the symlink in /Library/LaunchAgents,
>> though, even after running a deactivate/activate cycle. After upgrading
>> to dbus @1.12.8_0, the symlink in /Library/LaunchAgents no longer exists.
>>
>> It looks like the conditions checking for ${startupitem.install} are no
>> longer evaluated as expected.
>>
>> Rainer
> 
> 



More information about the macports-dev mailing list