Difference between emacs-app and emacs-mac-app ports?

[Richard Cobbe]

I'd like to install Emacs via MacPorts as a native MacOS app, as opposed to
something that runs inside a Terminal window.

I see both emacs-app and emacs-mac-app packages.  Forgive what may be a
silly question, but what's the difference between the two?  I've looked at
"port info" for both packages, but that information doesn't really clarify
things, and the homepage for emacs-mac-app is just the bitbucket repository.

Thanks,

Richard

Xcode 12 on Catalina?

[Richard Cobbe]

I've been putting off the upgrade to XCode 12 for a while, since I kinda
got burned by the upgrade from 10 to 11.  I haven't seen any reports of
problems with the new version, but I thought I'd ask -- any reason not to
upgrade at this point?

Thanks,

Richard

Re: boost upgrade from 1.70.0_0 to 1.71.0_0 does not trigger ledger rebuilt

[Richard Cobbe]

On Wed, Sep 04, 2019 at 09:22:23AM -0500, Ryan Schmidt wrote:

> The developers of boost do not believe in library versioning. They never
> change the version numbers of their libraries, even though they are not
> necessarily compatible from one release to the next.

Ugh.  How irritatingly anti-social.

> When we update boost to a new version, we may therefore need to revbump
> some or all ports that link with boost. If we forgot to do that when we
> recently updated boost, then that was a mistake.

Best you can do, really.  The problem was easily and quickly fixed as soon
as I noticed it and filed the ticket, so thanks to all for prompt action.

And I'm glad to have the background explanation; I'll watch out for this
next time I see a boost upgrade.

Richard

Re: boost upgrade from 1.70.0_0 to 1.71.0_0 does not trigger ledger rebuilt

[Richard Cobbe]

On Sun, Sep 01, 2019 at 08:38:11PM -0700, Kastus Shchuka wrote:
> I ran “port upgrade outdated” today and it installed a new version of boost:



> After that ledger fails to start:



> If I uninstall and install again ledger, I am getting the same error.
>
> I had to build ledger from source:



> Now ledger runs properly.
>
> Is it a bug in ledger port file that ledger does not detect upgrade of
> boost? Should I better report it in trac? Or is there a different way of
> going through boost upgrade?

I encountered this yesterday myself, with exactly the same results that you
describe.  I filed a ticket on this at
, and it was just marked as
"fixed."  I haven't actually looked yet myself; perhaps there's a new
ledger package that fixes the issue?

Richard

Re: how to report bug against xorg-server?

[Richard Cobbe]

On Sat, Jun 01, 2019 at 08:00:49AM -0500, Ryan Schmidt wrote:
>
>
> On Jun 1, 2019, at 00:25, Richard Cobbe wrote:
>
> > What's the best way to report a bug against xorg-server?  I'm happy to open
> > a ticket on the MacPorts trac instance, but this is more an application
> > problem than a compilation or installation issue, and the ticket guidelines
> > at <https://guide.macports.org/#project.tickets> suggest that application
> > errors should be reported to the upstream developers -- and I've lost track
> > of who that is at this point.  This is clearly a MacOS issue, so I very
> > much doubt that reporting it to x.org is appropriate.
>
> https://www.xquartz.org/Bug-Reporting.html

Ok, thanks.  I'll give that a shot, but I'll need to do a bit of digging to
see if I can figure out the right component to log it under.

Thanks for your help!

Richard

Re: how to report bug against xorg-server?

[Richard Cobbe]

On Sat, Jun 01, 2019 at 10:44:05AM +0100, Chris Jones wrote:
> Hi,
>
> If the issue is with Xorg’s server, then the correct place to report bugs 
> against that is with upstreams bug reporting system. Macports trac is the 
> place if the issue is specific to macports packaging.

Ah -- I left out perhaps the most important part of the question: who is
upstream?  'port info xorg-server' only lists x.org, not xquartz.org, but
fortunately Ryan Schmidt provided the correct info.

Richard

Re: best way to start desired X clients on login with xorg-server?

[Richard Cobbe]

On Sat, Jun 01, 2019 at 10:32:10AM -0400, Richard L. Hamilton wrote:
>
> >> One thing to add before starting urxvt if you want color to work!!
> >> export TERMINFO=/opt/local/share/terminfo
> >>
> >> because the rxvt-unicode-256color entry is only there, not in
> >> /usr/share/terminfo.  I noticed that as soon as I installed urxvt and ran
> >> the system version of vi or vim (as opposed to the MacPorts version,
> >> which will look in the MacPorts terminfo directory without being told).
> >
> > Huh -- there's something weird going on here.  As you say, that terminfo
> > entry is only in /opt/local/share/terminfo, not under /usr/share/terminfo.
> > However, I was able to start /usr/bin/vi in urxvt, with
> > TERM=rxvt-unicode-256-color, *without* setting TERMINFO, and I'm getting
> > color just fine.
>
> Are you sure it was /usr/bin/vi and not /opt/local/bin/vi?  The latter
> uses the MacPorts libncurses, which knows its own TERMINFO location.

Quite sure.  I tried both binaries by typing their full paths at the bash
prompt.

However, I only just discovered that I had previously set TERMINFO_DIRS to
"/usr/share/terminfo:/opt/local/share/terminfo" in my .bashrc, and both the
OS-provided and MacPorts-provided terminfo libraries appear to respect this
variable.  So we can explain that mystery, at least!

As per my other question, this presumably won't work for items that I add
to the server's Applications menu unless I add it to the /usr/bin/env
argument list, but that's easily done where necessary.

> > One other thing: it is possible to set XDG_CONFIG_HOME in the X server's
> > environment?  I'm finding that applications that I add to the
> > "Applications" menu aren't seeing that variable, despite it being set in
> > one of the files in .xinitrc.d.
>
> I suspect it's not the X server at all, but the app program that acts
> like a wrapper, which handles the app's dock menu items. The whole issue
> of environment variables and Mac app bundles is a bit nasty; there used
> to be a file to put those in, but that's not supported for a long time.



Yeah, that does sound like a bit of a mess.  Even though I'm the only
person who ever uses these computers, I don't like the idea of putting a
user-specific setting into system config files, so I think I'll just leave
it in the Applications menu entries.

Thanks!

Richard

how to report bug against xorg-server?

[Richard Cobbe]

What's the best way to report a bug against xorg-server?  I'm happy to open
a ticket on the MacPorts trac instance, but this is more an application
problem than a compilation or installation issue, and the ticket guidelines
at  suggest that application
errors should be reported to the upstream developers -- and I've lost track
of who that is at this point.  This is clearly a MacOS issue, so I very
much doubt that reporting it to x.org is appropriate.

(The specific bug: the dialog box that appears when I choose "Customize..."
from the Applications menu does not handle Mojave's dark mode well at all;
it's borderline unusable.)

Thanks,

Richard

Re: best way to start desired X clients on login with xorg-server?

[Richard Cobbe]

[Responding to the list this time]

On Wed, May 29, 2019 at 04:10:56AM -0400, Richard L. Hamilton wrote:

> While the system xinitrc does plenty you don't want, it might still be
> worth looking at; having an ~/.xinitrc.d directory with separate files
> for different setup actions, running xmodmap if the files for it are
> present, etc, may be useful.

Ah, yes, I'd forgotten about that; thanks for the reminder!

> One thing to add before starting urxvt if you want color to work!!
> export TERMINFO=/opt/local/share/terminfo
>
> because the rxvt-unicode-256color entry is only there, not in
> /usr/share/terminfo.  I noticed that as soon as I installed urxvt and ran
> the system version of vi or vim (as opposed to the MacPorts version,
> which will look in the MacPorts terminfo directory without being told).

Huh -- there's something weird going on here.  As you say, that terminfo
entry is only in /opt/local/share/terminfo, not under /usr/share/terminfo.
However, I was able to start /usr/bin/vi in urxvt, with
TERM=rxvt-unicode-256-color, *without* setting TERMINFO, and I'm getting
color just fine.

One other thing: it is possible to set XDG_CONFIG_HOME in the X server's
environment?  I'm finding that applications that I add to the
"Applications" menu aren't seeing that variable, despite it being set in
one of the files in .xinitrc.d.  (And I know that setting is happening for
the clients started later in that file, because I'm getting the expected
font in urxvt.  Since xquartz is also started in that file, I'd expect it
to pick up that variable as well.)

I can edit the command in the Applications menu entry to be

/usr/bin/env LC_CTYPE=en_US.UTF-8 XDG_CONFIG_HOME=/Users/cobbe/etc 
/opt/lcoal/bin/urxvt

and this works just fine, but I'm wondering if there's a more elegant way
to set that up.

Thanks!

Richard

Re: Difference in rendering xft fonts in xorg-server and XQuartz.app

[Richard Cobbe]

On Wed, May 29, 2019 at 03:58:32PM +0100, Chris Jones wrote:
>
>
> On 29/05/2019 3:51 pm, Richard Cobbe wrote:
> >
> > I gotta say, it would be so much more helpful if I could find diagnostics
> > or log messages from the X server on this stuff.  Are those written
> > anywhere that I can access?
>
> The X11 server logs are written to ~/Library/Logs/X11/

Aha!  That's very helpful; thanks!

Richard

Re: Difference in rendering xft fonts in xorg-server and XQuartz.app

[Richard Cobbe]

On Wed, May 29, 2019 at 03:11:57AM -0500, Ryan Schmidt wrote:
>
>
> On May 28, 2019, at 10:50, Richard Cobbe wrote:
>
> >> It appears to me that the first (i.e. liked) font is Menlo 13 while the 
> >> second (disliked) font is Andale Mono 13. I too like Menlo a lot and have 
> >> been using it in my Terminal since Apple started shipping it with macOS.
> >
> > Actually, the first font is Consolas, although Menlo is quite nice too.
> > The second one could easily be Andale Mono, as I do have it installed on
> > the machine, but I'm not really sure.
>
> You may have intended for the font to be Consolas, you may even have told X11 
> to use Consolas, but the lowercase "l" and "r" of Consolas do not look like 
> the ones in either of the screenshots. As best I can tell, the font you like 
> is Menlo, the one you don't like is Andale Mono. See attached comparison 
> image.

Huh -- good catch.  I certainly requested Consolas, but you're right,
that's not what's in the screenshot.

The odd thing is that, with XQuartz on my *old* MacBook, I *do* appear to
be getting Consolas.  The only difference that I've been able to find after
a quick investigation is that the font is installed in
/Library/Fonts/Microsoft on the old machine, rather than ~/Library/Fonts or
~/Library/Fonts/Microsoft on the new one.  I may dig into this further when
I have more time, although I really need to wipe the old machine and take
it to FedEx tomorrow for the trade-in value, or the offer will expire.

I gotta say, it would be so much more helpful if I could find diagnostics
or log messages from the X server on this stuff.  Are those written
anywhere that I can access?  As far as fontconfig goes, I know about
FC_DEBUG (see the fonts-conf manpage for details), and that's better than
nothing, but I wonder if there's another way to get additional info.

(Also, the behavior of silently falling back on an approximation if the
font can't be found is really not helpful -- I mean, sure, use an
approximation so I can get a terminal open and continue to investigate, but
maybe let me know that there's a problem?)

Thanks,

Richard

best way to start desired X clients on login with xorg-server?

[Richard Cobbe]

I'm in the process of switching away from XQuartz to macports' xorg-server
package, since it seems the former is no longer supported.

I would like to start X and a client automatically upon login.  Adding
/Applications/MacPorts/X11.app to the list of login items in System
Preferences is easy enough, and it starts X, but it also starts xterm, and
I'd prefer to start urxvt instead, and in a specific environment.

More precisely, I want to do the following on starting X:

1) xrdb ~/.Xresources
2) start /opt/local/bin/urxvt in environment that contains the
following variables:
LC_CTYPE=en_US.UTF_8
XDG_CONFIG_HOME=~/etc

I'd like to use quartz-wm in rootless mode, and I'd strongly prefer that
the X server continue running even if I close the urxvt started in step 2.
I'd also like to avoid having other extraneous X clients start
automatically.

I think I've found a way to do this, but it seems a bit sloppy and I'm
wondering if there's a cleaner way.

First, run the command
defaults write org.macports.X11 write app_to_run /usr/bin/true
This seems to only be necessary once; the setting appears to persist.

Then, create ~/.xinitrc with the following contents:

## Tell fontconfig to read ~/etc/fontconfig/fonts.conf
export XDG_CONFIG_HOME=~/etc

/opt/local/bin/xrdb ~/.Xresources

## start urxvt in my home directory, not the root directory
cd
LC_CTYPE=en_US.UTF_8 /opt/local/bin/urxvt &
exec /opt/local/bin/quartz-wm

If I don't change the app_to_run setting in the defaults, then I get an
xterm as well as urxvt, which is undesirable.  If I just delete the
app_to_run setting, then the next time I start X, it resets app_to_run back
to its default value of /opt/local/bin/xterm, and then it starts an xterm
as well as urxvt.  Setting it to /usr/bin/true (effectively a NOP) seems to
be the only way to prevent the unwanted xterm from starting and to have the
setting persist.

Is this the best way to do this?

Thanks,

Richard

Re: Difference in rendering xft fonts in xorg-server and XQuartz.app

[Richard Cobbe]

On Wed, May 29, 2019 at 12:35:06AM -0400, Richard L. Hamilton wrote:
> Have you tried creating ~/.fonts directory and putting the font(s) in
> there? Looking at both /opt/local/etc/fonts/fonts.conf and
> /opt/X11/lib/X11/fontconfig/fonts.conf, I see it listed as one of the
> directories (although as one that will likely go away in the future, with
> what per-user alternative, I don't know).

Well, I suppose I could symlink the fonts into there; I'd like the font to
be accessible to native MacOS programs like TextEdit and Pages as well.

That said, /opt/local/etc/fonts/fonts.conf does have a comment that says
~/.fonts is a deprecated location, and I'd prefer not to have this break
suddenly on me when I install a fontconfig update in 8 months, because I
will undoubtedly have forgotten about this stuff in the interim.

Interestingly, it appears that there's some daemon that's watching
~/Library/Fonts, because when I copied the .ttf files into that location,
fonts.list and fonts.scale just automagically appeared.  I did have to run
mkfontdir by hand to generate fonts.dir, though.

In any case, I figured out how to set the relevant environment variables at
the right time on login, although it's a bit krufty, so I think I'm set.

Thanks a bunch for your help!

Richard

Re: Difference in rendering xft fonts in xorg-server and XQuartz.app

[Richard Cobbe]

On Tue, May 28, 2019 at 09:19:12AM -0700, Richard Cobbe wrote:
> On Tue, May 28, 2019 at 09:53:54AM -0400, Richard L. Hamilton wrote:
>
> > > I don't know where X11 or its terminal stores its font settings...
> > >
> >
> > Native macOS font locations:
> > ~/Library/Fonts/
> > /Library/Fonts/
> > /Network/Library/Fonts/
> > /System/Library/Fonts
>
> The desired font is a truetype, stored in ~/Library/Fonts/Microsoft, which
> I created myself, and this could easily be the problem.  There is a
> fonts.dir in that directory, but the directory is naturally not listed as
> part of the font path when I run `xset q`.  (Interestingly, neither is
> ~/Library/Fonts, although /Library/Fonts and /System/Library/Fonts are both
> present.)
>
> I'm fairly sure that rxvt uses fontconfig, so I checked out
> /opt/local/etc/fonts, and there too I see /Library/Fonts,
> /Network/Library/Fonts, and /System/Library/Fonts, but not
> ~/Library/Fonts, and certainly not ~/Library/Fonts/Microsoft.

This was it.  Copying the font files to /Library/Fonts solved the problem
nicely, and for this particular client app, it's definitely fontconfig's
path settings, not the X server's.

For a variety of reasons, I'd prefer to keep the font files in
~/Library/Fonts rather than copying them to /Library, and I'd also rather
not put /Users/cobbe/Library/Fonts into a system configuration file.  (It'd
probably be OK in practice, since I'm the only person to use this computer,
but it still feels really sloppy.)

I looked at the fonts-conf manpage, and although it suggests that it reads
~/.fonts.conf, this doesn't appear to actually be the case.  It does,
however, read $XDG_CONFIG_HOME/fontconfig/fonts.conf, and creating that
file with the appropriate  entry works fine.

Now I just have to figure out how to automatically set XDG_CONFIG_HOME
before I start X, since I want to start X and urxvt automatically on
login.  That's a separate thread, I think.

Richard

Re: Difference in rendering xft fonts in xorg-server and XQuartz.app

[Richard Cobbe]

On Tue, May 28, 2019 at 09:53:54AM -0400, Richard L. Hamilton wrote:

> > I don't know where X11 or its terminal stores its font settings...
> >
>
> Native macOS font locations:
> ~/Library/Fonts/
> /Library/Fonts/
> /Network/Library/Fonts/
> /System/Library/Fonts

The desired font is a truetype, stored in ~/Library/Fonts/Microsoft, which
I created myself, and this could easily be the problem.  There is a
fonts.dir in that directory, but the directory is naturally not listed as
part of the font path when I run `xset q`.  (Interestingly, neither is
~/Library/Fonts, although /Library/Fonts and /System/Library/Fonts are both
present.)

I'm fairly sure that rxvt uses fontconfig, so I checked out
/opt/local/etc/fonts, and there too I see /Library/Fonts,
/Network/Library/Fonts, and /System/Library/Fonts, but not
~/Library/Fonts, and certainly not ~/Library/Fonts/Microsoft.

Once I get home from work this evening and have a bit more time, I'll try
copying the font into /Library/Fonts, or possibly tweaking the font paths,
and see what happens.



Thank you for providing this detail!  As I said elsewhere in the thread,
modern X11 font management is a mystery to me, and this helps to clear up a
great deal of that.  The last time I really got into this stuff in detail
(ah, the bad old days of XFree86), font specifications tended to look like

-*-fixed-medium-r-*-*-15-*-*-*-*-*-iso8859-*

so it's been a while, and a lot's changed since then!  :-)

> Individual X11 apps may have different ways of specifying which fonts
> they use. Xt based apps will probably have entries in resource files, for
> example /opt/local/share/X11/app-defaults/XTerm, or in loaded resources
> (output of xrdb -q, generally initialized from ~/.Xdefaults). Qt and gtk
> toolkits have their own configuration mechanisms.

Right; this part I'm fairly familiar with, at least for Xt apps.  Normally
I rely on a line in ~/.Xresources to set the font for this particular
client, but for the purposes of this investigation, I commented that out,
reloaded the resource database, and fell back on the command-line option in
my original message.

Thanks again!

Richard

Re: Difference in rendering xft fonts in xorg-server and XQuartz.app

[Richard Cobbe]

On Tue, May 28, 2019 at 07:11:34AM -0500, Ryan Schmidt wrote:
>
>
> On May 28, 2019, at 02:55, Chris Jones wrote:
>
> > On 28/05/2019 1:25 am, Richard Cobbe wrote:

> >> I've put screen shots of the results at <https://imgur.com/a/TTNFx8b>.  The
> >> first image contains the results under XQuartz, and the second under
> >> xorg-server.  This is urxvt from the rxvt-unicode port, v9.22, on MacOS
> >> 10.14.5 started with the command
> >> LC_CTYPE=en_US.UTF-8 urxvt -fn xft:Consolas:pixelsize=16
> >> I prefer the first rendering quite strongly.  Is there a way (installing
> >> a missing package, perhaps?) for me to get this rendering in xorg-server?
> >
> > Honestly, I cannot see any difference between those two screen shots. What 
> > exactly is it about the [first] you say is different and you prefer ?
>
> The font appears to be different. Look at the lowercase "i" which has a 
> bottom serif in the first screenshot, while it doesn't in the second 
> screenshot. I see subtle differences in other letters as well, like the 
> lowercase "l" which is more curved in the first screenshot than in the second 
> and the capital "Q" which has a straight tail in the first screenshot but a 
> curved one in the second. Overall the text in the first screenshot has a 
> slightly heavier weight as well.

Oh, good catch -- I hadn't even noticed that they're different fonts!  I
chiefly noticed the heavier weight and the tighter letterspacing in the
first screenshot, both of which make the first one far easier on my eyes.
(Part of this effect may be due to differences in how the two servers do
the rendering on the relevant display, a brand-new MacBook Pro, or due to
the precise brightness etc. settings.  These effects may or may not be
reflected in the screenshots.)

> It appears to me that the first (i.e. liked) font is Menlo 13 while the 
> second (disliked) font is Andale Mono 13. I too like Menlo a lot and have 
> been using it in my Terminal since Apple started shipping it with macOS.

Actually, the first font is Consolas, although Menlo is quite nice too.
The second one could easily be Andale Mono, as I do have it installed on
the machine, but I'm not really sure.

> I don't know where X11 or its terminal stores its font settings...

X11 font management is a deep mystery to me.  I can tell you that urxvt,
like a number of other terminal programs, accepts its font settings via the
-fn switch in my original post, as well as a couple of other places.  I
don't fully understand the precise values one can pass to the -fn switch,
but the value quoted above has worked for me under XQuartz for years, with
pixelsize adjusted slightly for different displays and as my eyes have
gotten worse over time.

This may or may not be relevant, but I usually configure that setting via
the following entry in the X resource database, but I commented that out
in favor of the command line for the purposes of this investigation.

URxvt.font: xft:Consolas:size=16

Oh, that's interesting -- I just realized that I'm not consistent here in
the size-vs-pixelsize option in the font string.  Once I get home from work
this evening, I'll investigate whether that makes a difference, though it
seems unlikely.

The main problem, as far as I can tell, is that xorg-server and XQuartz
interpret the same font specification differently.  This suggests that it's
a server problem (or at least a server configuration problem), but I have
no idea where to start debugging this.

Richard

Difference in rendering xft fonts in xorg-server and XQuartz.app

[Richard Cobbe]

I just got a new MacBook and I'm setting up macports on it as part of the
initial configuration.  I've been using macports with XQuartz for many
years, but I gather that XQuartz is no longer actively maintained, so I
figured I'd try xorg-server instead.  Everything installed fine and I'm
able to open and use clients, but using xft fonts in urxvt (also installed
via macports) doesn't produce the same results on screen under xorg-server
as it does under XQuartz.

I've put screen shots of the results at .  The
first image contains the results under XQuartz, and the second under
xorg-server.  This is urxvt from the rxvt-unicode port, v9.22, on MacOS
10.14.5 started with the command
LC_CTYPE=en_US.UTF-8 urxvt -fn xft:Consolas:pixelsize=16
I prefer the first rendering quite strongly.  Is there a way (installing
a missing package, perhaps?) for me to get this rendering in xorg-server?

Interestingly, while testing out various combinations, I discovered that if
I tried to open the terminal while running xorg-server but with XQuartz.app
installed, I got the nicer rendering.  I'm about as sure as I can be that I
was in fact running the X server from xorg-server in this case, as the
value of $DISPLAY ended in "org.macports:0", and right-clicking on the dock
icon for the running X server and selecting Options > Show In Finder
pointed to an .app in /Applications/MacPorts.

Uninstalling XQuartz.app and restarting the X server produced the inferior
rendering again.

Any suggestions welcome!

Thanks,

Richard

lbdb warning when searching MacOS contacts

[Richard Cobbe]

MacOS 10.12.4, MacPorts v2.4.1, lbdb 0.42_0+gpg2.

I've recently noticed that lbdbq issues noisy warnings when querying the
MacOS contacts:

[ridcully:~]$ lbdbq cobbe
CoreData: warning: dynamic accessors failed to find @property 
implementation for 'uniqueId' for entity ABCDInfo while resolving selector 
'uniqueId' on class 'ABCDInfo'.  Did you remember to declare it @dynamic or 
@synthesized in the @implementation ?
CoreData: warning: dynamic accessors failed to find @property 
implementation for 'uniqueId' for entity ABCDContact while resolving selector 
'uniqueId' on class 'ABCDContact'.  Did you remember to declare it @dynamic or 
@synthesized in the @implementation ?
CoreData: warning: dynamic accessors failed to find @property 
implementation for 'uniqueId' for entity ABCDEmailAddress while resolving 
selector 'uniqueId' on class 'ABCDEmailAddress'.  Did you remember to declare 
it @dynamic or @synthesized in the @implementation ?
CoreData: warning: dynamic accessors failed to find @property 
implementation for 'address' for entity ABCDEmailAddress while resolving 
selector 'address' on class 'ABCDEmailAddress'.  Did you remember to declare it 
@dynamic or @synthesized in the @implementation ?
CoreData: warning: dynamic accessors failed to find @property 
implementation for 'label' for entity ABCDEmailAddress while resolving selector 
'label' on class 'ABCDEmailAddress'.  Did you remember to declare it @dynamic 
or @synthesized in the @implementation ?
CoreData: warning: dynamic accessors failed to find @property 
implementation for 'isPrimary' for entity ABCDEmailAddress while resolving 
selector 'isPrimary' on class 'ABCDEmailAddress'.  Did you remember to declare 
it @dynamic or @synthesized in the @implementation ?
CoreData: warning: dynamic accessors failed to find @property 
implementation for 'orderingIndex' for entity ABCDEmailAddress while resolving 
selector 'orderingIndex' on class 'ABCDEmailAddress'.  Did you remember to 
declare it @dynamic or @synthesized in the @implementation ?
lbdbq:   17 matches
<>

It does print the matches, but after generating a lot of noise that kind of
interferes with using it in mutt, for example.  My .lbdbrc file:

METHODS="m_osx_addressbook"

The precise warning text and number of messages vary depending on what I'm
searching for, but the general shape of the messages is similar to the
above example.  I've worked around this by wrapping lbdbq in a script that
sends stderr to /dev/null, but that's kind of fragile.

I've only just started to use lbdb again after a long period of not using
it, so I can't say when this behavior was introduced.

Have others noticed this?  Should I file a bug against the package, or
let the upstream authors know?  (Does anyone else even use lbdb?  The
package has no maintainer, and the last post to the mailing list that I
could find about this port was from me, about a different problem, 4 years
ago.)

Thanks,

Richard

Re: Weird uninstall error

[Richard Cobbe]

On Tue, Nov 08, 2016 at 09:45:59AM -0600, Ryan Schmidt wrote:
>
> > On Nov 7, 2016, at 7:07 PM, Dave Horsfall  wrote:
> >
> > (Apologies for possible duplicate)
> >
> > Doing my regular "port -u uninstall", I never saw this one before:
> >
> >--->  Cleaning p5.22-datetime
> >--->  Unable to uninstall p5.22-specio @0.280.0_0, the following ports 
> > depend on it:
> >---> p5.22-datetime-locale @1.80.0_0
> >---> p5.22-datetime-timezone @2.50.0_0
> >Error: org.macports.uninstall for port p5.22-specio returned: Please 
> > uninstall the ports that depend on p5.22-specio first.
>
> And does first uninstalling the ports that depend on p5.22-specio work?

What should one do if one would be unable to reinstall the dependent ports?

I'm running into this with p5.22-perl-ldap, and the 'final' dependent, if
you will, is lbdb +ldap -- which I can't rebuild, due to the issue at
.

Richard