Re: rdepof:wine-devel +x11 +universal fails on installing xattr

[Ryan Schmidt]

On Sep 7, 2018, at 15:47, Gijs Vermeulen wrote:

> Hi again,
> 
> Thank you for the reply!
> 
> Op vr 7 sep. 2018 om 22:34 schreef Ryan Schmidt:
>> The xattr command is included in Mac OS X Leopard and later, so there should 
>> be no need to install the xattr port on recent systems. The xattr port only 
>> exists for Tiger, which did not include that command.
>> 
>> If MacPorts is trying to install the xattr port on your system, that implies 
>> that your operating system's /usr/bin/xattr command is missing. If that's 
>> so, restore it from your backups or reinstall macOS.
> 
> I am trying this on a clean (just installed xcode, command line tools, java 
> and macports) install of High Sierra (fully updated).
> I just checked and xattr exists in /usr/bin/xattr:
> 
> Gijss-MacBook-Pro:~ gverm$ which xattr
> /usr/bin/xattr
> 
> So I'm not sure what could be wrong.

Ah. Right.

The problem is that you are asking MacPorts to install *all* of wine-devel's 
recursive dependencies with the universal variant:

On Sep 7, 2018, at 12:19, Gijs Vermeulen wrote:

> I tried running port install -v rdepof:wine-devel +x11 +universal but it 
> fails when it tries to install xattr.

That includes the xattr port which you don't need.

If you just ran "sudo port install wine-devel" MacPorts should do the right 
thing.

If that's not possible for some reason and you need to explicitly list every 
port to install, then manually exclude xattr from the list:

sudo port -v install $( port echo rdepof:wine-devel and not xattr | sed 's/$/ 
+x11 +universal/' )


P.S: Note also the placement of the "-v" argument. Single-letter flags only 
have an effect if they are placed right after the "port" command, before the 
subcommand (before "install" in this case).

Re: rdepof:wine-devel +x11 +universal fails on installing xattr

[Ryan Schmidt]

Hello,

On Sep 7, 2018, at 12:19, Gijs Vermeulen wrote:

> I need some help installing wine dependencies.
> I tried running port install -v rdepof:wine-devel +x11 +universal but it 
> fails when it tries to install xattr.
> 
> I get "Error: xattr cannot be installed for the configured universal_archs 
> 'x86_64 i386' because it only supports the arch(s) 'i386 ppc'."
> 
> Is there anything wrong with the command I am running or is there something I 
> can do to fix it (I can't add ppc to the universal_archs because then other 
> stuff will start failing)?

On Sep 7, 2018, at 12:20, Gijs Vermeulen wrote:

> Sorry for the noise, but I'm running the latest version of macports on macOS 
> High Sierra, also the latest version.

You're right that you should not add ppc to universal_archs on macOS High 
Sierra. You cannot build ppc software with the compilers included with Xcode on 
High Sierra, nor could you run it even if you could build it.

The libtool port, which is a dependency of the wine ports, requires the xattr 
command in order to fix a packaging error in the current version of libtool. We 
will presumably be able to remove this dependency when the next version of 
libtool is released, assuming it is packaged correctly.

The xattr command is included in Mac OS X Leopard and later, so there should be 
no need to install the xattr port on recent systems. The xattr port only exists 
for Tiger, which did not include that command.

If MacPorts is trying to install the xattr port on your system, that implies 
that your operating system's /usr/bin/xattr command is missing. If that's so, 
restore it from your backups or reinstall macOS.

Re: nmap

[Ryan Schmidt]

On Sep 4, 2018, at 14:15, Daniel J. Luke wrote:

> On Sep 2, 2018, at 11:25 PM, James Linder wrote:
> 
>> It seems the port of nmap is quite different to linux nmap.
> 
> You haven't provided information to substantiate that assertion (but linux 
> and mac os x /are/ different, so you might just be seeing those differences?)
> 
>> What is happening
> 
> one difference in what you pasted is that your linux machine has nmap 7.60 
> and your mac has nmap 7.7.0

It looks like he's showing us that nmap on his Linux machine found 11 hosts 
while on his Mac it only found 6 hosts.

Re: OpenGL versions supported?

[Ryan Schmidt]

On Aug 30, 2018, at 15:15, Langer, Stephen A. (Fed) wrote:

> Earlier I had asked what version of OpenGL is supported by MacPorts' version 
> of mesa, and then was distracted by other issues and never got to the next 
> part of the question... 
>  
> Mesa 17.1.6 nominally supports OpenGL 4.5, but glxinfo says it's only 2.1:
>  
> >> port installed mesa
> The following ports are currently installed:
>   mesa @17.1.6_0+osmesa+python27 (active)
> >> glxinfo -B
> name of display: /private/tmp/com.apple.launchd.BNMe1Dpa8w/org.macports:0
> display: /private/tmp/com.apple.launchd.BNMe1Dpa8w/org.macports:0  screen: 0
> direct rendering: Yes
> OpenGL vendor string: ATI Technologies Inc.
> OpenGL renderer string: ATI Radeon HD 5770 OpenGL Engine
> OpenGL version string: 2.1 ATI-1.68.20   
> <-
> OpenGL shading language version string: 1.20
>  
> What do I have to do to get at least version 3.2?   I'm using vtk 8.1.1 and 
> it requires OpenGL 3.2 or later.   
>  
> If I build vtk for Cocoa and install all ports with "+quartz -x11", then vtk 
> works properly, using the OpenGL libraries provided by the system.  But that 
> requires building all ports with "+quartz -x11", which is a pain, and not 
> something that I can easily ask of other users of our software.

I'm not sure if anyone here knows the answer. The MacPorts maintainer of the 
mesa port has been busy with non-MacPorts projects recently and probably does 
not have time to answer. You may have to ask the developers of mesa directly.

Re: error building/configuring ninja

[Ryan Schmidt]

On Aug 30, 2018, at 01:32, Riccardo Mottola wrote:

> Hey,
> 
> I was upgrading ports on my Leopard system 10.5, I missed a couple of weeks.. 
> a lot of "big stuff" built well though :)
> 
> ninja fails - it is not directly selected for upgrade, it must be a 
> dependency.
> 
> bootstrapping ninja...
> "./src/inline.sh" kBrowsePy < ./src/browse.py > build/browse_py.h
> /usr/bin/g++-4.2 -MMD -MT build/browse.o -MF build/browse.o.d -g -Wall 
> -Wextra -Wno-deprecated -Wno-missing-field-initializers -Wno-unused-parameter 
> -fno-rtti -fno-exceptions -fvisibility=hidden -pipe 
> '-DNINJA_PYTHON="/opt/local/bin/python2.7"' -O2 -DNDEBUG -DNINJA_HAVE_BROWSE 
> -I. -pipe -Os -arch i386 -pipe -Os -arch i386 -c ./src/browse.cc -o 
> build/browse.o
> Traceback (most recent call last):
>  File "configure.py", line 470, in 
>if has_re2c():
>  File "configure.py", line 467, in has_re2c
>return int(proc.communicate()[0], 10) >= 1103
> ValueError: invalid literal for int() with base 10: ''
> Command failed:  cd 
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_ninja/ninja/work/ninja-1.8.2"
>  && /opt/local/bin/python2.7 configure.py 
> --with-python=/opt/local/bin/python2.7 --bootstrap --verbose
> Exit code: 1
> Error: Failed to configure ninja: configure failure: command execution failed
> 
> 
> Do you have an idea?

Hi Riccardo,

Run "sudo port selfupdate" and "sudo port upgrade outdated" to get re2c @1.1_1; 
re2c @1.1_0 had a bug. This affected all systems, not just Leopard.

-Ryan

Re: tcl-sqlite3

[Ryan Schmidt]

On Aug 26, 2018, at 07:54, Marius Schamschula wrote:

> On Aug 26, 2018, at 7:34 AM, Marius Schamschula wrote:
> 
>> I’ve added a sqlite3-tcl subport:
>> 
>> https://github.com/macports/macports-ports/commit/0e46e32ec2ff78ce3adc725cb3aed714b8203d5b

Do you want to make tcl-sqlite3 replaced_by sqlite3-tcl or should I?


> Note: tcl has to be modified not to install
> 
> ${prefix}/share/man/mann/sqlite3.n.gz

Do you want to do that or should I?

Re: tcl-sqlite3

[Ryan Schmidt]

On Aug 25, 2018, at 11:18, Joshua Root wrote:

> On 2018-8-26 01:22 , joerg van den hoff wrote:
> 
>> On 25.08.18 06:21, Joshua Root wrote:
 currently, this port is at version
 
 tcl-sqlite3 @3.6.22_3
 
 sqlite3, however, is already at 3.24. there have been relevant changes
 to sqlite between versions 22 and 24, so I now see "malformed schema"
 errors with the tcl package for databases generated with current sqlite3
 (identical to those I see with the sqlite3 at 3.22 port).
 
 question: any chance to see an update of the tcl-sqlite3 package soon?
>>> 
>>> The tcl-sqlite3 port could probably be updated if a ticket is filed. I
>> I could do that, of course, if required.
>> 
>>> think it may have languished in part because there was a question of how
>>> useful it is now that Tcl 8.6 has sqlite3 built in.
>> has it? I am not aware of this: there is no command `sqlite3' available
>> in my tclsh 8.6.8 (the one provided by macports) before I do `package
>> require sqlite3' (which loads the separately installed sqlite3 package,
>> e.g. the ports-provided one). of course, if you issue "sqlite3" at the
>> tlcsh prompt, you usually fire up the standalone `sqlite3' comand line
>> utility and get it's prompt. but that is of course not the same thing...
>> 
>> so if I have missed something: could you please elaborate a bit on this?
> 
> If you uninstall the tcl-sqlite3 port, you should find that 'package
> require sqlite3' loads a newer version of the package.
> 
> % port contents tcl | grep sqlite
>  /opt/local/lib/sqlite3.21.0/libsqlite3.21.0.dylib
>  /opt/local/lib/sqlite3.21.0/pkgIndex.tcl
>  /opt/local/lib/tcl8/8.6/tdbc/sqlite3-1.0.6.tm
>  /opt/local/share/man/mann/sqlite3.n.gz
>  /opt/local/share/man/mann/tdbc_sqlite3.n.gz

Soo... that loads the sqlite 3.21.0 version of the extension, which as you say 
is bundled with Tcl.

It seems like it would be better if we updated the tcl-sqlite3 port to match 
the version in the sqlite3 port, which is 3.24.0, and remove these parts from 
the tcl port.

We could make updates to tcl-sqlite3 automatic by making it a subport of the 
sqlite3 port.

Re: GIMP2 fails to build on 10.7

[Ryan Schmidt]

On Aug 25, 2018, at 15:03, Riccardo Mottola wrote:

> I am updating gimp2 and it fails to build:
> 
> /opt/local/bin/clang-mp-5.0 -DHAVE_CONFIG_H -I. -I../..  
> -DISO_CODES_LOCATION=\"/opt/local/share/xml/iso-codes\" 
> -DISO_CODES_LOCALEDIR=\"/opt/local/share/locale\" 
> -DG_LOG_DOMAIN=\"Gimp-Widgets\" -I../.. -I../.. -I../../app -I../../app 
> -D_REENTRANT -I/opt/local/include/gegl-0.4 -I/opt/local/include/json-glib-1.0 
> -I/opt/local/include/gio-unix-2.0/ -I/opt/local/include/glib-2.0 
> -I/opt/local/lib/glib-2.0/include -I/opt/local/include/babl-0.1 -D_REENTRANT 
> -I/opt/local/include/gtk-2.0 -I/opt/local/lib/gtk-2.0/include 
> -I/opt/local/include/pango-1.0 -I/opt/local/include/harfbuzz 
> -I/opt/local/include/pango-1.0 -I/opt/local/include/fribidi 
> -I/opt/local/include/cairo -I/opt/local/include/atk-1.0 
> -I/opt/local/include/cairo -I/opt/local/include/pixman-1 
> -I/opt/local/include/ossp -I/opt/local/include/freetype2 
> -I/opt/local/include/libpng16 -I/opt/local/include/gdk-pixbuf-2.0 
> -I/opt/local/include/libpng16 -I/opt/local/include/glib-2.0 
> -I/opt/local/lib/glib-2.0/include -I/opt/local/include -I/opt/local/include 
> -DGIMP_DISABLE_DEPRECATED -DBABL_DISABLE_DEPRECATED -DGSEAL_ENABLE 
> -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DGDK_MULTIHEAD_SAFE 
> -DGTK_MULTIHEAD_SAFE "-xobjective-c" -pipe -Os -arch x86_64 -Wall 
> -Wdeclaration-after-statement -Wmissing-prototypes -Werror=missing-prototypes 
> -Wstrict-prototypes -Wmissing-declarations -Winit-self -Wpointer-arith 
> -Wold-style-definition -Wmissing-format-attribute -Wformat-security  
> -Wtype-limits -fno-common -fdiagnostics-show-option -Wreturn-type   -MT 
> gimpwidgets-utils.o -MD -MP -MF .deps/gimpwidgets-utils.Tpo -c -o 
> gimpwidgets-utils.o gimpwidgets-utils.c
> gimpwidgets-utils.c:37:10: fatal error: 'CoreGraphics/CoreGraphics.h' file 
> not found
> #include 
> ^
> 1 error generated.
> make[3]: *** [gimpwidgets-utils.o] Error 1
> 
> 
> isn't this strange? CoreGraphics.h exists since quite some time….
> Ideas?
> 
> Riccard


CoreGraphics didn't become a top-level framework until OS X 10.8. On 10.7 it 
was only available as a part of ApplicationServices.

According to 
https://stackoverflow.com/questions/4170459/mac-adding-coregraphics-framework-for-cg-use-in-a-c-header/4173621#4173621,
 one should instead include .

Would you report this bug to the developers of gimp, if it has not already been 
reported to them?

https://gitlab.gnome.org/GNOME/gimp/issues

Re: SOS!

[Ryan Schmidt]

On Aug 20, 2018, at 12:42, Christopher Jones wrote:

> Honestly, I suspect the only safe fix here is to provide an uninstaller 
> (could just be a bash script) that does it safely for the user…

Yes, MacPorts should ship with an uninstaller script.

https://trac.macports.org/ticket/42207

Re: Failed to upgrade gstreamer1-gst-plugins-bad

[Ryan Schmidt]

The error in both logfile is "error: unknown type name 'CGLError'"


> On Aug 17, 2018, at 22:54, Carlo Tambuatco  wrote:
> 
> The errors on https://trac.macports.org/ticket/56781 don't look like the 
> errors I'm getting, so I don't see how my ticket is a 
> duplicate of this one...
> 
> On Fri, Aug 17, 2018 at 11:48 PM Ryan Schmidt  wrote:
> On Aug 17, 2018, at 21:46, Carlo Tambuatco wrote:
> 
> > On Fri, Aug 17, 2018 at 10:21 PM Ryan Schmidt wrote:
> > 
> >> On Aug 17, 2018, at 20:31, Carlo Tambuatco wrote:
> >> 
> >> > Doing routine port upgrading and gstreamer1-gst-plugins-bad
> >> > failed to upgrade
> >> 
> >> https://trac.macports.org/ticket/56781
> > 
> > I tried those workarounds and they did not work for me. I don't even know 
> > what the problem is...
> 
> I think if we knew what the problem was exactly, we could fix it. So we don't 
> need additional tickets for the same problem, we just need someone to figure 
> out the best solution.

Re: Failed to upgrade gstreamer1-gst-plugins-bad

[Ryan Schmidt]

On Aug 17, 2018, at 21:46, Carlo Tambuatco wrote:

> On Fri, Aug 17, 2018 at 10:21 PM Ryan Schmidt wrote:
> 
>> On Aug 17, 2018, at 20:31, Carlo Tambuatco wrote:
>> 
>> > Doing routine port upgrading and gstreamer1-gst-plugins-bad
>> > failed to upgrade
>> 
>> https://trac.macports.org/ticket/56781
> 
> I tried those workarounds and they did not work for me. I don't even know 
> what the problem is...

I think if we knew what the problem was exactly, we could fix it. So we don't 
need additional tickets for the same problem, we just need someone to figure 
out the best solution.

Re: Failed to upgrade gstreamer1-gst-plugins-bad

[Ryan Schmidt]

On Aug 17, 2018, at 20:31, Carlo Tambuatco wrote:

> Doing routine port upgrading and gstreamer1-gst-plugins-bad
> failed to upgrade

https://trac.macports.org/ticket/56781

Re: removing a local portfile repository

[Ryan Schmidt]

On Aug 16, 2018, at 12:41, Langer, Stephen A. (Fed) wrote:

> https://guide.macports.org/chunked/development.local-repositories.html 
> contains instructions for adding a local port file repository.  When I'm done 
> with the local repository, how can I delete it?  Is removing it from 
> sources.conf sufficient?  Do I somehow need to undo the effect of running 
> portindex?

Yes, removing the entry from sources.conf should be enough. You can then delete 
the local repository's directory from your disk, if desired.

Re: Problem starting gimp

[Ryan Schmidt]

On Jul 29, 2018, at 13:02, Gregory Bonar wrote:
> 
> When I type 'sudo port upgrade outdated' I get:
> 
> --->  Computing dependencies for poppler
> --->  Building poppler
> Error: Failed to build poppler: command execution failed
> Error: See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_poppler/poppler/main.log
>  for details.
> 
> Main.log.gz is attached

The error in the log is similar to the one you originally reported:

:info:build dyld: Library not loaded: /opt/local/lib/libtiff.3.dylib
:info:build   Referenced from: /opt/local/lib/libpoppler-glib.8.dylib
:info:build   Reason: image not found

MacPorts has offered libtiff.5.dylib for over 3 years; I don't remember how 
long it's been since we were on libtiff.3.dylib.

If you can't explain why this is happening, your easiest option is to uninstall 
all ports, then install the ones you want.

Re: Problem starting gimp

[Ryan Schmidt]

On Jul 29, 2018, at 12:24, Gregory Bonar wrote:

> I just installed Macports 2.5.3.
> When I try to start gimp I get the following messages:
> dyld: Library not loaded: /opt/local/lib/libpng14.14.dylib
>   Referenced from: /opt/local/bin/gimp
>   Reason: image not found
> Abort trap: 6
> 
> I'm new to Macports.
> I just typed 'gimp' on the command line.
> Can you tell me the correct way to start gimp?
> MacOS 10.13.6
> Thanks

libpng14 is very old; MacPorts moved on to libpng15 in September 2012 and 
libpng16 in December 2013. So either you installed these ports many years ago, 
and need to upgrade them as Chris suggested, or you installed them recently but 
then ran an ancient binary installer of gimp which overwrote what MacPorts 
installed; if the latter, then we don't know what all got overwritten, so your 
best bet is to uninstall all ports and then reinstall the ones you want.

Re: Port Upgrade Outdated Failure

[Ryan Schmidt]

On Jul 27, 2018, at 11:13, Christopher Stone wrote:
> 
> Your DNS servers incorrectly claim to know the address of nonexistent hosts. 
> This may cause checksum mismatches for some ports. See this page for more 
> information: 

I would start with what’s mentioned on that page. 

Re: verbose builds

[Ryan Schmidt]

On Jul 25, 2018, at 05:32, Rainer Müller wrote:

>> Would it be useful if port(1) had --disable-silent-rules
>> among configure.args by default? Or at least with port -vs?
>> Not having the actual commands renders the main.log a bit useless.
> 
> Yes, --disable-silent-rules should be used whenever possible. However,
> only configure scripts using automake will provide that option. Other
> configure scripts might also fail when unknown options are passed on the
> command line. Therefore I do not think it is not possible to make it a
> default.

I agree with Rainer that adding it to the default configure args now could 
break a lot of ports. If we had had it there from the beginning, ports that 
aren't compatible with it would already be removing it, but we didn't, and I 
don't want to break those ports now and spend the next few years finding and 
fixing them. If ports were already indicating via some variable that they use 
automake, we could add the flag only for those ports, but no such indication 
exists. So I think each port has to be responsible for ensuring a verbose build 
occurs, by whatever means is appropriate for that port. For automake ports, we 
usually add --disable-silent-rules to configure.args but one could add V=1 to 
build.args instead; other build systems may honor one or both of those methods 
too, or they may have other ways of achieving it (the cmake portgroup takes 
care of cmake's unique way of doing it, for example), or it may requires 
patches to the build system.

The reason why we didn't have that flag in the default configure args from the 
beginning is that the flag didn't used to exist; automake used to always use 
verbose rules. Then later (in automake 1.11), the option to use silent rules 
was introduced.

https://autotools.io/automake/silent.html

Then later, silent rules were made the default. We still want them disabled for 
MacPorts though, so that main.log files that users attach to bug reports 
contain useful information, so as projects' build systems are rebuilt with 
newer versions of autotools, a flag to disable the silent rules has to be added 
to those ports.

If we did want to add the flag by default, we would not want to put it in 
configure.args, because the purpose of configure.args is to be set by 
portfiles, and tons of them do; if we provided a default value for it in base, 
most ports would override it. We could put it in configure.pre_args instead, 
along with --prefix=${prefix}. Those ports that override configure.pre_args 
because they don't support --prefix=${prefix} probably don't support 
--disable-silent-rules either.

After writing the above, it occurs to me that adding V=1 to build.pre_args or 
build.post_args by default might be a solution. Unlike configure scripts, some 
of which complain about unknown flags being used, make isn't going to complain 
about unknown variables being set. There is of course still a possibility that 
some Makefiles may use a variable called V for some other purpose and that by 
overriding it to be 1 we might break those Makefiles. But my guess is that 
setting V=1 by default would break far fewer ports than using 
--disable-silent-rules by default. There are already 73 portfiles that set V=1 
manually, though there are a couple that set it to different values: cmus sets 
V=2, and lua51 sets V to a version number. And of course we have no idea how 
many ports' Makefiles internally use a variable called V that the Portfiles 
aren't currently setting.

Re: vnc

[Ryan Schmidt]

On Jul 24, 2018, at 08:48, Christopher Jones wrote:

> What exactly is your question ? The macPorts build of cotvnc is 64-bit and no 
> warnings are offered running it. 

Agreed. I use cotvnc all the time and I've seen no problems with it on High 
Sierra so far. Actually I use the cotvnc-devel port, to get the latest 
development version.

Re: Cannot uninstall local port with invalid version number

[Ryan Schmidt]

On Jul 20, 2018, at 13:52, S P Arif Sahari Wibowo wrote:

> On 2018-07-18, 16:56, S P Arif Sahari Wibowo wrote:
>> # port -f uninstall installed
>> Warning: Failed to open Portfile from registry for alpine 
>> @2.20_0.97.114.105.102.115.97.104.97.1+without_tcl
>> Error: port uninstall failed: Registry error: Invalid version 
>> '2.20_0.97.114.105.102.115.97.104.97.1+without_tcl' specified for alpine. 
>> Please specify a version as recorded in the port registry.
> 
> So, any thoughts?

Your message may not have reached all users, because you wrote to the defunct 
macosforge list address instead of the new macports list address. Messages do 
forward from the old address to the new one, but users with restrictive email 
server settings may not receive those forwards, so please write to the new list 
address in the future.


It has always been invalid to specify anything other than a nonnegative integer 
for the revision. It was a bug that previous versions of MacPorts allowed this 
to happen. MacPorts now correctly complains about it.

I do not know how you can uninstall this port now. I have a feeling that a 
similar situation has come up before; you could search the list archives.


> Where is this registry anyway?

You're not meant to modify this file manually, but the registry is an SQLite 3 
database located at:

/opt/local/var/macports/registry/registry.db 

If you wish to examine or manipulate the database, you will need to load the 
MacPorts SQLite extension into your SQLite client. I don't remember how to do 
that but it's been discussed on the list before; you can search the archives.

It's possible that changing the revision for this installed port from this 
invalid revision to a valid value will allow you to uninstall it. It's possible 
you would still have to delete the installed port's tbz2 file afterward, since 
its filename contains the revision.

Re: Using macports to create binary package

[Ryan Schmidt]

On Jul 20, 2018, at 13:24, Manav Bhatia wrote:

> No GUI. My app is a terminal application with plenty of dependencies. My 
> users are at places and on systems without root access. 
> 
> I am not sure what the best approach is here, but I am looking at various 
> options where I can distribute precompiled binaries. 
> 
> Dylibbundler sounds interesting but I have no experience to try to judge its 
> limitations. 
> 
> I am also looking at CPack (from cmake), which seems to have some promise as 
> it is cross-platform compatible, so I can use the same cmake configuration 
> script to create bundles on Mac and Linux. 
> 
> I need these to work in non-standard, non-root locations. 
> 
> This should not be so difficult. 

It's important to realize that macOS and Linux use different executable 
formats. Mac uses Mach-O, and Linux uses ELF, and they are not the same, and 
they were designed with different goals in mind and different capabilities. So 
a solution that works on Linux won't necessarily work on macOS, and vice versa.

On macOS, a library contains the absolute path to where it is installed. The is 
called its "install_name" and it is set at build time. If the library is later 
moved on disk, install_name_tool must be used to update the library's 
install_name to its new location. Similarly, any program (or other library) 
that links with that library does so by its install_name. If the library is 
moved, install_name_tool must be used to update the reference to the library in 
the program (or other library).

It is also possible to set install_names that are relative to one of several 
different places, instead of absolute. For example, you could set the 
install_name to be relative to the path of the program that loaded it. This is 
not appropriate for libraries that are meant to be used by many different 
programs that might be in many different locations -- this is the situation we 
have in MacPorts, which is why MacPorts does not attempt to use relative paths 
for libraries. But if you are creating a standalone package for one program (or 
a few related programs), such that you can dictate the relative paths between 
all the programs and libraries, and you want that standalone package to be 
relocatable, then you could use relative paths in the install_names.

dylibbundler automates the process of running the necessary install_name_tool 
commands to change absolute install_names to relative ones. However I believe 
it also assumes that what it is producing is a standard macOS application 
bundle. If you're not producing an app but instead just a directory of programs 
and libraries, you will have to see if you can use dylibbundler's various flags 
to produce the desired file layout.

For the purposes of dylibbundler, it does not matter if the programs and 
libraries that it is changing came from our build server's binaries or were 
compiled by you on your computer. However, for your project, it may matter. For 
example, you may wish to distribute something that runs on 10.9 or later, but 
you are running on 10.13. The binaries compiled on our build server for 10.13 
are intended for use on 10.13 only. If you want to compile something on 10.13 
that can still run on 10.9, you have to set MACOSX_DEPLOYMENT_TARGET to 10.9. 
MacPorts allows you to specify this in macports.conf, but for it to take 
effect, you have to compile ports yourself; binaries you get from us won't 
respect that setting. Alternately, you could prepare your package on a system 
running 10.9. You'll be able to use MacPorts 10.9 binaries, and they should 
work on later systems, though of course they won't be able to use any 
capabilities introduced in later macOS versions.

As Craig said, making the programs and libraries use relative install_names may 
not be all you need to do. The absolute install path might also be baked into 
the programs in other ways. You can grep all of the files you plan to 
distribute and see if they contain the old install path. If so, you'll have to 
investigate what needs to be done to fix it. Unfortunately, there is not a 
one-size-fits-all solution for this.

\r

Re: iTerm2 and High Sierra 10.13.6 incompatible...

[Ryan Schmidt]

On Jul 18, 2018, at 14:17, Richard L. Hamilton wrote:

> But...as soon as I tried to run it, it popped up its own updater telling me 
> that 3.1.7 was available.  Now I know enough NOT to use a non-MacPorts 
> updater on something installed via MacPorts, but IMO, the MacPorts build 
> really should (if there's a way to do it) disable the built-in updater, so as 
> not to tempt people to do the wrong thing.

Yes; by all means file a ticket about that.


> Presumably that also means it might be nice if someone updated the port to 
> 3.1.7. :-)

Yes. Someone has already filed a ticket: https://trac.macports.org/ticket/56779

Re: iTerm2 and High Sierra 10.13.6 incompatible...

[Ryan Schmidt]

On Jul 18, 2018, at 13:48, Comer Duncan wrote:

> The thing is that I've now uninstalled iTerm2 and tried to reinstall it but 
> the reinstall fails now with a complaint that no destroot for iTerm2 is found:
> 
> Failed to install iTerm2: no destroot found at: 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_iTerm2/iTerm2/work/destroot
> :debug:install Error code: NONE
> :debug:install Backtrace: no destroot found at: 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_iTerm2/iTerm2/work/destroot
> :debug:install while executing
> :debug:install "create_archive $location $portarchivetype"
> :debug:install (procedure "portinstall::install_main" line 27)
> :debug:install invoked from within
> :debug:install "$procedure $targetname"
> :error:install See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_iTerm2/iTerm2/main.log
>  for details.
> 
> Can you guys help me figure out why this happened?  

https://trac.macports.org/wiki/ProblemHotlist#nodestrootfound

Re: Julia subpackages

[Ryan Schmidt]

On Jul 17, 2018, at 16:57, Jonathan Stickel wrote:

> I just started using Julia. Julia installed fine via Macports. However, any 
> and all subpackages (e.g., IJulia and PyPlot) are missing from MacPorts. 
> Julia has its own packaging system, so these can be added from a Julia 
> interactive session, like so:
> 
> julia> Pkg.add("PyPlot")
> 
> But you have to be super careful to point Julia to existing Python commands, 
> e.g.,
> 
> julia> ENV["PYTHON"]="python"
> 
> or it will automatically install an entire miniconda environment inside the 
> hidden .julia directory inside your home directory! I find this quite 
> undesirable.
> 
> Are there other Macports' Julia users out there? Are you satisfied with this 
> situation? Is there interest in making ports of the popular Julia packages 
> that could be installed in /opt/local/? Some googling shows that it should be 
> possible, but it is certainly not popular.

I don't have an answer for your question, but I just want to remind you that 
MacPorts has moved away from macOS forge, and our list addresses have changed 
from lists.macosforge.org to lists.macports.org; please update any email 
addresses that may be in your address book or email program's saved addresses. 
Your message was redirected to the new list, and I received it, but users whose 
email providers have more restrictive security settings can't receive them, so 
it's important to address messages to the new list initially.

Re: iTerm2 and High Sierra 10.13.6 incompatible...

[Ryan Schmidt]

On Jul 17, 2018, at 17:04, Comer Duncan wrote:

> Today I upgraded my os to 10.13.6 and immediately saw that iTerm2 does not 
> work at all.  In the meantime I am using Terminal so can get by.  Hoping that 
> iTerm2 can soon work with 10.13.6, I am sending along this 'report'.

Works for me.

Re: inetutils permissions?

[Ryan Schmidt]

On Jul 15, 2018, at 08:49, Richard L. Hamilton wrote:

> Would it make sense if packages that installed GNU executables where that 
> sort of problem might arise also symlinked them into e.g. /opt/local/gnu/bin 
> without the g prefix?

Most already do, but the directory is /opt/local/libexec/gnubin.


> That would at least allow an easy workaround for such situations, by just 
> putting that directory in front of the PATH...provided we're not already 
> using tools that would conflict with as part of port processing.

That is typically not an appropriate change to make in a port, since it would 
allow GNU versions of *all* programs (that the user had installed) to override 
the macOS versions, not just the one we're interested in (e.g. "install" in 
this case), and that commonly leads to other problems. If a port needs a GNU 
program as a dependency, it should specify the complete path to that 
executable, in whatever way that port's build system needs.

Re: New version of lynx

[Ryan Schmidt]

On Jul 12, 2018, at 13:47, dan d. wrote:

> Is there any idea when it will be on macports?

If you want a port to be updated, please file a ticket in our issue tracker. Or 
you can do the update yourself and send a pull request.

Re: Subversion +mod_dav_svn error

[Ryan Schmidt]

On Jul 10, 2018, at 19:12, John Korchok wrote:

> After installing subversion +mod_dav_svn, then restarting apache2, I get:
> httpd: Syntax error on line 170 of /opt/local/etc/apache2/httpd.conf: Cannot 
> load /opt/local/libexec/mod_dav_svn.so into server: 
> dlopen(/opt/local/libexec/mod_dav_svn.so, 10): Symbol not found: 
> _dav_do_find_liveprop\n  Referenced from: /opt/local/libexec/mod_dav_svn.so\n 
>  Expected in: flat namespace\n in /opt/local/libexec/mod_dav_svn.so
> 
> Any ideas on how to fix this?

Googling this error, I found:

http://pablotips.blogspot.com/2012/02/install-svn-on-mac-os-x.html

which says:

> You must be shure (sic) to add the:
> 
> LoadModule dav_svn_module libexec/apache2/mod_dav_svn.so
> 
> line after the dav module:
> 
> LoadModule dav_fs_module libexec/apache2/mod_dav_fs.so
> 
> or you will get the following error trying to start Apache:
> 
> Cannot load /usr/libexec/apache2/mod_dav_svn.so into server: 
> dlopen(/usr/libexec/apache2/mod_dav_svn.so, 10): Symbol not found: 
> _dav_do_find_liveprop 

Re: Find Universal?

[Ryan Schmidt]

On Jul 10, 2018, at 12:23, Adam Dershowitz wrote:

> Is there a way to find what base ports that I have installed are universal?

"base port" is not a term I'm familiar with, but you can show which ports have 
been installed with the universal variant using:

port -q installed | grep +universal


> I have ended up with a lot of ports that are universal variants.  I think 
> that there are actually few, if any ports, that I have currently installed 
> that need to be universal, but a while back I had a port or two that needed 
> to be (ie wine).  And, then all the dependents ended up being universal.  Is 
> there any way to figure out if any of my manually installed ports default to 
> universal?

I suppose you could grep their Portfiles to see if they say "default_variants 
+universal".

port file requested | sort -u | xargs grep -E 
'default_variants[[:space:]]+\+universal'


> Or if it is just dependents?  And, if that’s the case, is there a way to 
> “update” those to be -universal?  

Not easily. I may have posted a long complicated command line to do that on 
this mailing list some years ago. 

It would be easy to reinstall *all* active ports to remove the universal 
variant, with something like:

sudo port upgrade --enforce-variants active -universal

But if any other port required any of those ports to be universal, that would 
break that other port. You could of course do this and then just see what 
breaks.


> I tried this:
> port echo requested |grep universal
> 
> And there are just 12, for example ghostscipt and findutils that default to 
> universal.  

They may be installed universal on your system, but that is not their default 
installation mode, and there is no inherent reason why either of them need to 
be installed universal, unless of course it is required by another port that 
depends on them. Neither of those ports' Portfiles even contains the word 
"universal".


> I know that it could be done all by hand, but at the moment I have a total of 
> 141 ports that are +universal, and no easy way to tell which default to that 
> variant, which are that variant because of dependency issues, and which are 
> that variant because of delated dependency issues.  That last category can be 
> reinstall, but would have to be done in the right order, I think?

By grepping Portfiles, I count only 10 ports in our collection that default to 
the universal variant. That number may be slightly off, but it is a very rare 
occurrence.

Ports that are not 64-bit compatible, and that therefore only install 32-bit, 
and that therefore require their dependencies to be installed universal, are 
probably more common. You could show those ports that are installed for 32-bit 
only by using:

port -vq installed | grep "archs='i386'"

Re: installation on OS X 10.14 beta

[Ryan Schmidt]

On Jul 5, 2018, at 07:35, Manav Bhatia wrote:

> What I had in mind was to make macports believe that it is still running on 
> 10.13, so that it could use the precompiled binaries already available on the 
> servers. 
> 
> MacPorts must have a way to figure out which OS version it is running on. If 
> there is a script that it uses for this, can’t I make a simple modification 
> to accomplish this? 
> 
> Of course, this will be on my own risk, but I think this is worth a try. 
> 
> I would appreciate any insights on this. 

I understand what you're suggesting, but I don't want to help you do that. 
MacPorts deliberately makes you rebuild ports when you upgrade to a new OS, to 
prevent problems. See https://trac.macports.org/wiki/Migration. I don't want to 
help you circumvent that. If you encounter a problem with MacPorts on the new 
OS, I want you to be able to report it to us so that we can investigate and 
hopefully fix it. I don't want us to have the uncertainty of wondering if the 
problem you're encountering is because you're using ports built for the wrong 
OS version.

Re: How to uninstall Gimp? Or how to install it correctly?

[Ryan Schmidt]

On Jul 4, 2018, at 09:24, Christoph Kukulies wrote:

> Thanks. Deinstallation of Gimp and macports worked via the link below. The 
> only thing that there is a relict in a folder named macports
> with a document showing a question mark and named „Idle“.
> 
> Would be fine if I could get rid of that also.

See https://trac.macports.org/ticket/52160

Re: installation on OS X 10.14 beta

[Ryan Schmidt]

On Jul 4, 2018, at 11:06, Manav Bhatia wrote:

> I am wondering if it is possible for MacPorts to install packages from 
> prebuilt binaries on 10.14 beta. Is it possible force this? Maybe there is a 
> way to tell MacPorts to assume 10.13 even though it is running on 10.14? 

No, we are not providing any precompiled binaries for macOS Mojave beta. We 
will set up a builder for macOS Mojave once the final version is released. We 
wait until then do this because Apple might yet change things between now and 
the final release. Also, the NDA you and everyone with access to the beta 
agreed to states that we will not disclose information about the OS to anyone; 
publishing binaries compiled on that OS might constitute such disclosure, so we 
don't want to risk that. See:

https://trac.macports.org/wiki/FAQ#prerelease

Re: Graphene Build Error

[Ryan Schmidt]

Remember to Reply All so the conversation stays on the list.


On Jul 3, 2018, at 16:08, Curtis Matz wrote:

> On Jul 3, 2018, at 3:12 PM, Ryan Schmidt wrote:
> 
>> Are you sure the logfile doesn't exist? It should, and we would need to see 
>> its contents to know for sure what happened. But I see you're building 
>> graphene universal, and I expect all users who attempt to do so will 
>> currently experience this problem: https://trac.macports.org/ticket/56766
> 
> less 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_graphene/graphene/main.log
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_graphene/graphene/main.log:
>  No such file or directory

If this was after running your custom ports update script, which cleans all 
installed ports, that would make sense, if you have a previous version of 
graphene installed. Cleaning deletes the log file, among other things.


> On Jul 3, 2018, at 3:12 PM, Ryan Schmidt wrote:
> 
>> What was the command you ran? This error message suggests you were asking 
>> MacPorts to do something to a port or set of ports that didn't exist.
> 
> I run my custom ports update script.  Here’s the content of that file.
> 
> #!/bin/sh
> if [ "$(whoami)" != 'root' ]; then
>   echo "command line: sudo myports"
>   exit 1
> fi
> 
> port selfupdate
> port outdated
> port upgrade outdated
> port uninstall inactive
> port uninstall leaves
> port clean --all installed >> /dev/null 2>&1

Ok, that makes sense. I guess you didn't have any inactive and/or leaf ports to 
uninstall, hence the error.

Re: Keeping selected ports to a previous version

[Ryan Schmidt]

On Jul 2, 2018, at 10:23, Riccardo Mottola wrote:

> can selected ports be kept at a previous version?

MacPorts is not intended to be used in that way, so it does not have good 
support for that.


> E.g. gimp 2.10 currently doesn't compile on older MacOS versions. I have 
> supplied Ken some patches that will fix it on 10.6, but 10.5 and 10.4 are 
> very dyfficult, perhaps impossible. 2.8 continues to work. I'd like to keep 
> that. Can I use e.g. Ken's repository just for that single, e.g. 
> https://github.com/kencu/LeopardPorts or do I need toc ompletely "switch" 
> repository?
> I suppose this is not the only port that is troublesome neither that I am the 
> only one in this situaation.

The best solution would be for the maintainers of the affected ports to modify 
them so that they offer whatever version of the software is appropriate for 
whatever version of macOS is being used.

Re: PATH not searched properly for gcc version

[Ryan Schmidt]

On Jul 3, 2018, at 12:40, Rainer Müller wrote:

> On 2018-07-03 19:02, Turner, Adrian Keith wrote:
>> Also, interesting are the results of which and whereis:
>> which gcc
>> /opt/local/bin/gcc
>> whereis gcc
>> /usr/bin/gcc
> 
> That is normal, whereis does not respect PATH.
> 
>> How do I make my system find the correct version of gcc without
>> specifying the full path?
> 
> Your shell has probably cached the location of the gcc binary from
> earlier before you created the symlink with 'port select'. Just open a
> new terminal window or execute 'hash -r' to clear the cache.

Adrian didn't say he had used 'port select'. If he hasn't, that's the first 
thing he should do, if he wants to be able to use gcc 7.3 as "gcc".

Re: Graphene Build Error

[Ryan Schmidt]

On Jul 3, 2018, at 07:48, Curtis Matz wrote:

> For the last few days Graphene won’t update due to some error.  When I copy 
> and paste the path to the log file it says it doesn’t exist.  Is there an 
> issue at this time with Graphene?  I’ve tried sudo port clean graphene but to 
> no help.
> 
> --->  Computing dependencies for graphene
> --->  Fetching archive for graphene
> --->  Attempting to fetch 
> graphene-1.8.2_0+universal.darwin_17.i386-x86_64.tbz2 from 
> https://packages.macports.org/graphene
> --->  Attempting to fetch 
> graphene-1.8.2_0+universal.darwin_17.i386-x86_64.tbz2 from 
> http://ywg.ca.packages.macports.org/mirror/macports/packages/graphene
> --->  Attempting to fetch 
> graphene-1.8.2_0+universal.darwin_17.i386-x86_64.tbz2 from 
> http://lil.fr.packages.macports.org/graphene
> --->  Fetching distfiles for graphene
> --->  Attempting to fetch graphene-1.8.2.tar.gz from 
> https://github.com/ebassi/graphene/tarball/1.8.2
> --->  Verifying checksums for graphene
> --->  Extracting graphene
> --->  Configuring graphene
> --->  Building graphene
> Error: Failed to build graphene: command execution failed
> Error: See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_graphene/graphene/main.log
>  for details.
> Error: Follow https://guide.macports.org/#project.tickets to report a bug.

Are you sure the logfile doesn't exist? It should, and we would need to see its 
contents to know for sure what happened. But I see you're building graphene 
universal, and I expect all users who attempt to do so will currently 
experience this problem: https://trac.macports.org/ticket/56766


> Error: No ports matched the given expression

What was the command you ran? This error message suggests you were asking 
MacPorts to do something to a port or set of ports that didn't exist.

Re: Official Gnucash and macports conflicting libgio-2.0.0.dylib

[Ryan Schmidt]

On Jun 30, 2018, at 09:28, nb wrote:

> I have macports 2.5.2 already installed.
> I have then installed Gnucash 3.2 dmg from gnucash.org.
> When I run gnucash, I have the error:
> 
> objc[93365]: Class GNotificationCenterDelegate is implemented in both 
> /Applications/Gnucash.app/Contents/Resources/lib/libgio-2.0.0.dylib 
> (0x10c333670) and /opt/local/lib/libgio-2.0.0.dylib (0x117a41620). One of the 
> two will be used. Which one is undefined.
> Segmentation fault: 11
> /opt/local/lib/libgio-2.0.0.dylib belongs to glib2 macports package.
> 
> If I rename /opt/local/lib/libgio-2.0.0.dylib, gnucash works fine. But this 
> can't be a solution.
> 
> I've also tried to set DYLB_LIBRARY_PATH to
> 
> /Applications/Gnucash.app/Contents/Resources/lib
> But this way I have the error
> 
> Segmentation fault: 11
> Is there a way to run gnucash while macports installed ?

It seems wrong that a supposedly standalone installation of gnucash would have 
any knowledge of things installed by MacPorts in /opt/local. Why does it do 
that?

I downloaded it and I don't see any occurrence of /opt/local in it. I opened 
the app from the dmg and I didn't see the problem you saw.

Could it be a setting on your system that's causing this? Might you be setting 
DYLD_LIBRARY_PATH in /etc/launchd.conf? If so, try not doing that.

Re: stupid question

[Ryan Schmidt]

On Jun 29, 2018, at 10:21, pagani laurent wrote:

> By the way, I tested the 3 other gcc-*-mp-7 (ranlib, ar, and nm) and all 
> complained :
> 
>> gcc-ranlib-mp-7
> gcc-ranlib-mp-7: Cannot find plugin ‘liblto_plugin.so'
> 
> Does it matter ?

Looks like nobody has worked on that problem:

https://trac.macports.org/ticket/38551

Re: smartctl - Can't run select span range

[Ryan Schmidt]

On Jun 28, 2018, at 19:43, Ubence Quevedo wrote:

> On Tue, Jun 26, 2018 at 9:31 PM Ryan Schmidt wrote:
> 
>> On Jun 26, 2018, at 07:32, Ubence Quevedo wrote:
>> 
>> > Ubences-MacBook-Pro:ata uquevedo$ smartctl -t long /dev/disk2
>> > smartctl 6.6 2017-11-05 r4594 [Darwin 17.6.0 x86_64] (local build)
>> > Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org
>> > 
>> > === START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
>> > Sending command: "Execute SMART Extended self-test routine immediately in 
>> > off-line mode".
>> > Drive command "Execute SMART Extended self-test routine immediately in 
>> > off-line mode" successful.
>> > Testing has begun.
>> > Please wait 206 minutes for test to complete.
>> > Test will complete after Tue Jun 26 08:52:02 2018
>> > 
>> > Use smartctl -X to abort test.
>> > 
>> > There’s no way that will complete under my system’s sleep schedule [three 
>> > hour timeout for sleep] which isn’t ideal anyways.
>> 
>> So tell the system not to sleep while the test is running.
>> 
>> caffeinate -i smartctl -t long /dev/disk2
>> 
>> For more info:
>> 
>> man caffeinate

> 
> I gave caffeinate a try, and set my system sleep time to a more reasonable 
> timeout [30 minutes], but since smartctl isn't an interactive process [a 
> tsr?], the system never stays awake long enough to finish a whole test.  I 
> even added the -m option to prevent the disk from idle sleeping but that 
> didn't help.

Oh, right. As I recall, smartctl exits immediately, and the test occurs on the 
disk in the background, and you later run smartctl again to get the result.

In that case, you can run smartctl normally, and then caffeinate a sleep 
command that takes at least as long as the test. For example, if the test will 
take 206 minutes, you could sleep for 207 minutes (12,420 seconds):

caffeinate -i sleep 12420

("sleep" in this context means "wait this many seconds").

Re: Advice on distributing a project

[Ryan Schmidt]

On Jun 28, 2018, at 14:56, Langer, Stephen A. (Fed) wrote:

> It's the same problem as https://trac.macports.org/ticket/56461 and 
> https://trac.macports.org/ticket/54981.   Is that a problem with glib2 or 
> with all of the ports that use it?

My understanding is that those other ports are not compatible with the 
modification that we've made for glib2, and those other ports will need to 
adapt.

Because the modifications we've made have not been included in the official 
glib2 sources yet, the developers of those other ports probably aren't aware of 
this situation yet.


> I thought I'd try to force the x11 variant of glib2 -- I restored the default 
> variants.conf, ran 'port install glib2' and 'port pkg glib2', copied the .pkg 
> file to the mpkg_packages directory for oof3d, changed variants.conf back to 
> quartz mode, and ran 'port mpkg oof3d'.  But MacPorts was too smart for that 
> and wanted to rebuild glib2 with +quartz.
>  
> Could I make a new port, called say glib2x11, whose +quartz variant is the 
> same as glib2's +x11 variant?   How would I tell all the ports that use glib2 
> to use glib2x11 instead?

If this is just for your own use, you can easily delete the quartz and x11 
variants from your local copy of the glib2 portfile and add the 
--with-appinfo-impl=generic configure flag to the global part of the portfile.

Re: Advice on distributing a project

[Ryan Schmidt]

On Jun 28, 2018, at 14:00, Langer, Stephen A. (Fed) wrote:

> It *is* rebuilding glib2 when I run "port mpkg oof3d".   I have -x11 +no_x11 
> +quartz in variants.conf, but glib2 is installed with +x11.   Is mpkg 
> noticing that the installed variant isn't the default variant and thinking 
> that it has to rebuild?

I remember that "port pkg" builds the port again and packages up the contents 
of the new destroot directory, rather than packaging the port that has already 
been installed. I'm not 100% sure why it does that. I don't know what "port 
mpkg" does but it wouldn't surprise me if it does the same thing. And if that's 
so, I can't think of a good way to pass a variant selection to only one of the 
dependencies. I guess the best solution would be to fix whatever's wrong with 
gtk2 that makes it not work with glib2's quartz variant.

Re: Advice on distributing a project

[Ryan Schmidt]

On Jun 28, 2018, at 13:10, Langer, Stephen A. (Fed) wrote:

> I just ran "sudo port mpkg oof3d", without any other arguments.  I had 
> changed my PATH so that only the minimal, non-standardly-located ports 
> directory was visible.  (Minimal means only dependencies of oof3 are 
> installed.)   I don’t remember any output showing that it switched glib2 
> versions, and only the x11 version is installed now.   I'll re-run mpkg to 
> make sure, but I made the mistake of running upgrade outdated, and it's going 
> to take forever.  Does it build everything from source because macports isn't 
> installed in the standard location?

Yes, not using the standard /opt/local prefix would disable the use of 
precompiled binaries and would require building everything from source.

Re: Advice on distributing a project

[Ryan Schmidt]

On Jun 28, 2018, at 11:02, Langer, Stephen A. (Fed) wrote:

> In any case, thanks to all of your suggestions, I can now build and install 
> using the Portfile.  I can create an mpkg and install from it.  However, the 
> contents of the mpkg are incorrect.   There are missing symbols in 
> libgio-2.0.dylib, which is installed by the glib2 port, so I suspect it has 
> something to do with with https://trac.macports.org/ticket/54981.   I 
> installed glib2 with +x11 and installed everything else with +quartz, which 
> is the only way to get gtk2 working on quartz.

This is surprising to me and probably not what we intended. If you want quartz, 
you're supposed to have to use the quartz variant for everything, and if you 
instead want x11, you're supposed to have to use the x11 variant for 
everything. I don't use the quartz variants so I don't have personal experience 
with them.

> Would mpkg have somehow pulled in the +quartz version?

It sounds like maybe it did. How did you invoke sudo port mpkg -- what 
arguments? Did any of its output show that it deactivated your x11 version of 
glib2 and activated the quartz version?

> If my port requires a particular version, do I have to do something to 
> enforce it when packaging the port?

The require_active_variants procedure of the active_variants 1.1 portgroup is 
the only way to "enforce" variants of a dependency.


> The correct libgio-2.0.dylb defines _g_desktop_app_info_get_type.

This is the +x11 variant of glib2.

> The one in the mpkg defines _g_osx_app_info_get_type instead.

This is the +quartz variant of glib2.

> Googling "glib osx_app_info" leads to a page with Ryan's name on it…

MacPorts patches glib2 to offer a quartz variant that changes how app_info 
works.

https://gitlab.gnome.org/GNOME/glib/issues/1263

Right now these patches are MacPorts-specific, until upstream decides to merge 
the changes into their official sources.

Re: Advice on distributing a project

[Ryan Schmidt]

On Jun 27, 2018, at 13:47, Langer, Stephen A. (Fed) wrote:
 
> It requires knowing the installation prefix during the distutils build stage, 
> which certainly can be done, but I don't think it's standard in the distutils 
> world.  At least, the prefix isn't accessible to the build_ext command in the 
> python 2.7 distutils.  The easiest solution would be for the distutils 
> build_ext command to copy the value from the distutils install command, but 
> that requires them to be run together in the MacPorts build phase, which 
> breaks the MacPorts model.  It could be set twice, once as a build argument 
> and once as an install argument, which is ugly but might work.  I'll try it.

Yes there are many ports that supply the same arguments and/or environment 
variables at both build and destroot time. It's a simple one-liner in a 
Portfile to copy all the args, for example.

macOS has been around for over 17 years. It would be weird if in all that time 
Python hasn't developed an easy way to create correct dylibs. My assumption 
therefore is that such an easy method does exist, I just don't know what it is 
since I'm not very familiar with Python.

Re: smartctl - Can't run select span range

[Ryan Schmidt]

On Jun 26, 2018, at 07:32, Ubence Quevedo wrote:

> Ubences-MacBook-Pro:ata uquevedo$ smartctl -t long /dev/disk2
> smartctl 6.6 2017-11-05 r4594 [Darwin 17.6.0 x86_64] (local build)
> Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org
> 
> === START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
> Sending command: "Execute SMART Extended self-test routine immediately in 
> off-line mode".
> Drive command "Execute SMART Extended self-test routine immediately in 
> off-line mode" successful.
> Testing has begun.
> Please wait 206 minutes for test to complete.
> Test will complete after Tue Jun 26 08:52:02 2018
> 
> Use smartctl -X to abort test.
> 
> There’s no way that will complete under my system’s sleep schedule [three 
> hour timeout for sleep] which isn’t ideal anyways.

So tell the system not to sleep while the test is running.

caffeinate -i smartctl -t long /dev/disk2

For more info:

man caffeinate

Re: Advice on distributing a project

[Ryan Schmidt]

On Jun 26, 2018, at 10:07, Langer, Stephen A. (Fed) wrote:

> That's what I don't understand.   When not using MacPorts, we use 
> install_name_tool to fix the libraries.  They're built in 
> $HOME/project/build/{lib, include, etc} and moved to $PREFIX /{lib, include, 
> etc}, at which point install_name_tool fixes their ids.

Can you not pass the correct -install_name=$PREFIX/lib/libsomething.dylib flag 
when you link it, and thus avoid needing to use install_name_tool later?

> With MacPorts, $PREFIX is ${destroot}${prefix}.  Are the files moved again 
> when the port is installed?  Does the destroot phase need to use an 
> install_name that's different from the actual name, anticipating the later 
> move?

The build phase is supposed to build the software, including building the 
libraries with the install_name set to where the files will ultimately be 
installed in $PREFIX.

The destroot phase is supposed to copy the files from the build directories to 
the correct layout in the destroot directory. Ideally the destroot phase should 
not need to use install_name_tool or modify the files in any other way, just 
copy them to where they need to go.

Re: python 2.7 usage failure

[Ryan Schmidt]

On Jun 25, 2018, at 09:02, Riccardo Mottola wrote:

> Hi,
> 
> today during my attempts of TFF build, I get this unexpected stacktrace:
> 
> Traceback (most recent call last):
>  File "/Users/multix/Documents/code/tenfourfox/mach", line 148, in 
>main(sys.argv[1:])
>  File "/Users/multix/Documents/code/tenfourfox/mach", line 76, in main
>mach = get_mach()
>  File "/Users/multix/Documents/code/tenfourfox/mach", line 67, in get_mach
>mach = check_and_get_mach(dir_path)
>  File "/Users/multix/Documents/code/tenfourfox/mach", line 42, in 
> check_and_get_mach
>return load_mach(dir_path, mach_path)
>  File "/Users/multix/Documents/code/tenfourfox/mach", line 30, in load_mach
>return mach_bootstrap.bootstrap(dir_path)
>  File "/Users/multix/Documents/code/tenfourfox/build/mach_bootstrap.py", line 
> 317, in bootstrap
>mach.load_commands_from_file(os.path.join(mozilla_dir, path))
>  File "/Users/multix/Documents/code/tenfourfox/python/mach/mach/main.py", 
> line 256, in load_commands_from_file
>module_name = 'mach.commands.%s' % uuid.uuid1().get_hex()
>  File 
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/uuid.py",
>  line 588, in uuid1
>clock_seq_hi_variant, clock_seq_low, node), version=1)
>  File 
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/uuid.py",
>  line 164, in __init__
>raise ValueError('field 6 out of range (need a 48-bit value)')
> ValueError: field 6 out of range (need a 48-bit value)
> Traceback (most recent call last):
>  File "/Users/multix/Documents/code/tenfourfox/mach", line 148, in 
>main(sys.argv[1:])
>  File "/Users/multix/Documents/code/tenfourfox/mach", line 76, in main
>mach = get_mach()
>  File "/Users/multix/Documents/code/tenfourfox/mach", line 67, in get_mach
>mach = check_and_get_mach(dir_path)
>  File "/Users/multix/Documents/code/tenfourfox/mach", line 42, in 
> check_and_get_mach
>return load_mach(dir_path, mach_path)
>  File "/Users/multix/Documents/code/tenfourfox/mach", line 30, in load_mach
>return mach_bootstrap.bootstrap(dir_path)
>  File "/Users/multix/Documents/code/tenfourfox/build/mach_bootstrap.py", line 
> 317, in bootstrap
>mach.load_commands_from_file(os.path.join(mozilla_dir, path))
>  File "/Users/multix/Documents/code/tenfourfox/python/mach/mach/main.py", 
> line 256, in load_commands_from_file
>module_name = 'mach.commands.%s' % uuid.uuid1().get_hex()
>  File 
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/uuid.py",
>  line 588, in uuid1
>clock_seq_hi_variant, clock_seq_low, node), version=1)
>  File 
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/uuid.py",
>  line 164, in __init__
>raise ValueError('field 6 out of range (need a 48-bit value)')
> ValueError: field 6 out of range (need a 48-bit value)
> python2.7 /Users/multix/Documents/code/tenfourfox/config/pythonpath.py -I 
> /Users/multix/Documents/code/tenfourfox/testing/mozbase/mozfile \
>
> /Users/multix/Documents/code/tenfourfox/python/mozbuild/mozbuild/controller/clobber.py
>  /Users/multix/Documents/code/tenfourfox
> Usage: clobber.py topsrcdir topobjdir
> 
> 
> I suppose python is acting up, since this always worked.
> Can you tell if it is core python or some modules acting up?
> 
> While not all packages I have are up-to-date since I have some issues to fix, 
> all python modules look to be except one. Here is the situation:
> py27-numpy @1.14.5 python/py-numpy
> 
> 
> the package currently has some issues installing, I will report about that. 
> Can it be related? Doesn't look like
> 
> Riccardo
> 

It looks like there was a bug in Python's uuid:

https://bugs.python.org/issue32502

It looks like it was fixed in Python 3.6.5. Can you use that instead of Python 
2.7?

Re: fail do install dbus

[Ryan Schmidt]

On Jun 25, 2018, at 02:44, Riccardo Mottola wrote:

> Hi,
> 
> installing dbus fails with this message:
> 
> --->  Cleaning dbus
> Error: Couldn't activate dbus 1.12.8_2: can't create directory 
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_dbus":
>  permission denied
> 
> Koreander:~ multix$ ls -l /opt/local/var/macports/
> total 0
> drwxr-xr-x4 root  admin136 Jun 25 09:01 build
> 
> 
> the build directory is owned by root - could it be that macports user is 
> trying to use it?

We are seeing a lot of reports of this type of problem since the release of 
MacPorts 2.5. I don't know why.

Re: libomp upgrade issues

[Ryan Schmidt]

On Jun 25, 2018, at 11:35, Riccardo Mottola wrote:

> I have a strange problem: I have libomp listed as upgradable.

The list is incorrect, because of https://trac.macports.org/ticket/55471.

You already have the latest libomp that is compatible with your system.

Re: Advice on distributing a project

[Ryan Schmidt]

On Jun 22, 2018, at 09:12, Langer, Stephen A. (Fed) wrote:

> If I change the MacPorts build phase so that it runs "python setup.py build 
> install --prefix=${destroot}, then everything that MacPorts needs to install 
> will be in ${destroot}/lib, ${destroot}/bin, etc.  Will the default MacPorts 
> destroot phase work properly in that case?  How do I restore the default 
> destroot after redefining build.cmd, since destroot.cmd uses build.cmd when 
> build.cmd is defined? 

I don't know how to do what you want to do properly in MacPorts; I'm not well 
versed in Python software. But your proposal is probably not the right way. 
With the vast majority of ports, you want to build in the build phase, and 
install the files into the destroot in the destroot phase; only a very small 
number of weird custom build systems can't accommodate that and have to combine 
these two tasks into a single phase.

I wasn't specific enough earlier. The destroot takes the place of the root of 
the filesystem (/). So, if, without using a destroot, files would have been 
installed to ${prefix}, then with a destroot files would be installed into 
${destroot}${prefix}. Files do not get installed directly to ${destroot}.

I agree with Joshua's suggestion to try using the python 1.0 portgroup.

Re: Advice on distributing a project

[Ryan Schmidt]

On Jun 21, 2018, at 16:46, Langer, Stephen A. (Fed) wrote:

> Hi--
>  
> I'm making some progress in writing a Portfile for my project, but I'm stuck 
> on one point.  The project's build script uses python distutils (which I'd be 
> happy to get rid of but that's not likely to happen soon).   The build 
> commands, outside of MacPorts, are
>  
> python setup.py build --3D 
> python setup.py install  --3D --prefix=/some/installation/directory
>  
> The Portfile contains this:
>  
> build.cmd   ${prefix}/bin/python2.7
> build.args  setup.py build  --portdir=${prefix}
> build.target""
> use_parallel_build  no
>  
> destroot.cmd${prefix}/bin/python2.7
> destroot.args   setup.py install --skip-install-name-tool
> destroot.target ""
> destroot.destdir--prefix=${destroot}${prefix}

It won't affect the issue you're having, but from an organizational standpoint, 
build.cmd and destroot.cmd should be "${prefix}/bin/python2.7 setup.py", 
build.target should be "build", build.args should be "--portdir=${prefix}", 
destroot.target should be "install", and destroot.args should be 
"--skip-install-name-tool".


> The portdir argument to "setup.py build" is used to get the right -I and -L 
> paths for the compiler. 
> This seems to work, in the sense that everything is compiled and moved to the 
> correct locations, but the libraries don't have the correct install names and 
> try to link to other libraries in the wrong locations.
>  
> The project consists of python files, C++ files that are compiled into simple 
> python extension modules, and C++ files that are compiled into shared 
> libraries that are used by those extensions.  Because distutils builds 
> everything in a temp directory and then installs into a target directory, the 
> setup script runs install_name_tool to fix the install names and rpaths in 
> the libraries.   But now it's installing into ${destroot}, which isn't the 
> final destination, so the script is giving the wrong arguments to 
> install_name_tool.  MacPorts must have the same issue, since it copies 
> libraries out of destroot, so I hoped that I could ignore the problem and let 
> MacPorts handle it.  I added the --skip-install-name-tool option to "setup.py 
> install" to try that, but it doesn't work.  "otool -L" shows that the 
> installed libraries have the wrong install names and are trying to link to 
> libraries in non-existing locations, so rev-upgrade fails.  For example:
>  
> % cd /opt/oofports/lib
> % otool -L liboof3dcommonGUI.dylib 
> liboof3dcommonGUI.dylib:
> 
> build/temp.macosx-10.12-x86_64-2.7-3d/shlib/liboof3dcommonGUI.dylib 
> (compatibility version 0.0.0, current version 0.0.0)  ç Wrong
> /opt/oofports/lib/libgtk-quartz-2.0.0.dylib (compatibility 
> version 2401.0.0, current version 2401.32.0)
> /opt/oofports/lib/libgdk-quartz-2.0.0.dylib (compatibility 
> version 2401.0.0, current version 2401.32.0)
>   [other correct lines omitted]
> 
> build/temp.macosx-10.12-x86_64-2.7-3d/shlib/liboof3dcommon.dylib 
> (compatibility version 0.0.0, current version 0.0.0) ç Wrong
>  
> So, how does MacPorts handle this?  Have I prevented MacPorts from solving 
> the install name problem by redefining destroot.cmd?   Would xinstall fix it? 
>  Should I run both the build and install phases of setup.py in the MacPorts 
> build phase, and use the default destroot phase?  How do I do that and still 
> redefine build.cmd, since destroot.cmd defaults to build.cmd?

MacPorts handles it by setting destroot.destdir to DESTDIR=${destroot} and 
assuming that the project's Makefile will use that variable correctly, as a 
staging directory into which the files will be installed but which will not be 
used by the build in any other way. It is also assumed that there will be 
another variable (e.g. PREFIX=/opt/local) or configure arg (e.g. 
--prefix=/opt/local) by which we can inform the build system of the ultimate 
install directory, the one to which MacPorts will move the files from the 
destroot, and that the build system will correctly use that variable as the 
basis for library install names.

If your project's build system does not support DESTDIR, maybe adding that 
support would be the best way forward. I'm not sure what the standard is in the 
land of distutils/setuptools for such support.

Re: Boost 1.67

[Ryan Schmidt]

On Jun 21, 2018, at 09:20, Michael Dickens wrote:

> See < https://trac.macports.org/ticket/56294 >.
> 
> Boost 1.67.0 has significant changes in the way it handles time computations 
> that are not ABI or API backward compatible with any prior Boost.
> 
> I think all of the ports I maintain are multi-Boost compatible, and I've seen 
> updates to others I don't maintain. But, there are some 234 ports ("port echo 
> depends:boost") that depend on Boost, and the ones I know work maybe account 
> for 40 of those ...
> 
> Thus, something that would be helpful / useful would be to use the patch 
> provided in the ticket above & update to the new Boost, then go through the 
> dependent ports & see if they install & if not then open a ticket for each 
> that doesn't. It'll be time-consuming and tedious (at least for me it would), 
> but that way we'll have a handle on how much work it'll be to do the update. 
> I think if we can hit 75% that either work are can be easily updated to work 
> (via a version update or a known-working patch), then we're hitting the 
> threshold for pushing this Boost update.
> 
> Note that these are my opinions as a co-maintainer of the port; I don't speak 
> for the rest of MacPorts nor the other co-maintainer.

Sounds good to me.

> Boost updates are tricky, and impact lots of ports, so we have to be careful 
> to test them out well.
> 
> Hope this is useful. - MLD
> 
> On Thu, Jun 21, 2018, at 8:52 AM, S. L. Garwood wrote:
>> Any hope of seeing boost 1.67?
>> If not and I set it up myself will maintainer give me a hand getting it 
>> ready for ‘official’ port?

Re: gnucash not finding dbus

[Ryan Schmidt]

On Jun 19, 2018, at 21:05, Lenore Horner wrote:

> On Jun 11, 2018, at 17:57, Lenore Horner wrote:
> 
>> gnucash is saying
>> Dynamic session lookup supported but failed: launchd did not provide a 
>> socket path, verify that org.freedesktop.dbus-session.plist is loaded!
>> 
>> but when I try to start dbus—session I get
>> /opt/local/Library/LaunchAgents/org.freedesktop.dbus-session.plist: service 
>> already loaded
>> 
>> so why isn’t gnucash seeing it?  
> 
> No one else is seeing this behavior and no one has any clue how to fix it?

Does unloading and then loading that plist help?

Re: Doing my weekly "port -u uninstall", and...

[Ryan Schmidt]

On Jun 18, 2018, at 18:47, Dave Horsfall wrote:

> On Sun, 17 Jun 2018, Ryan Schmidt wrote:
> 
>>> --->  Checking for unnecessary unrequested ports
>>> Error: reclaim failed: can't read "isrequested(adwaita-icon-theme)": no
>>> such element in array
>>> 
>>> OK; what went wrong this time?  I don't even know what
>>> "adwaita-icon-theme" is!
>> 
>> "adwaita-icon-theme" a port for a Gnome icon theme, which you presumably had 
>> installed.
> 
> Well, certainly not by choice, that's for sure, so I guess it's at the end of 
> a chain of dependencies or something; what was that command again, that tells 
> me what needs it?

One way is:

port installed depends:adwaita-icon-theme


>> Unfortunately I can't explain why you're encountering this error.
> 
> And neither can I find a log file, otherwise I would've attached it...

I don't know whether reclaim saves a log file. You can possibly produce more 
information by using the debug flag:

sudo port -d reclaim

Re: Question about port reclaim and dependencies...

[Ryan Schmidt]

On Jun 18, 2018, at 16:15, Carlo Tambuatco wrote:

> Doing some routine cleaning up of old unecessary ports and I was wondering 
> how port treats duplicate ports... I realised I've got two instances of the 
> xrender port installed so I'll use this as an example.
> 
> I've got these two ports installed
> 
>  xrender @0.9.10_0
>  xrender @0.9.10_0+universal (active)
> 
> and only the +universal variant is active. So does that mean that all 
> dependents of the 
> xrender port are really only dependent on the active version, through some 
> complex system of symlinks, and the inactive version is safe to uninstall 
> completely? 
> 
> I'm just using this port as one example, but generalizing to other ports, it 
> is completely safe to uninstall the inactive versions of a duplicate port 
> because their dependents are dependent only on the active versions? 
> 
> Have I got this right behind the scenes?

There are no symlinks involved. There used to be a system of hard links, but 
that was abandoned shortly after the release of Mac OS X Leopard because it 
caused problems for the new Time Machine feature.

What we do now is that an installed port is a compressed tarball. "Activating a 
port" means extracting that tarball, and "deactivating a port" means deleting 
the files that got extracted. "Uninstalling a port" means deleting the tarball.

The universal variant builds for multiple architectures -- x86_64 and i386 on 
modern systems. Not using the universal variant means using only the default 
architecture -- x86_64 on modern systems. So any port that was happy to use 
xrender without the universal variant should be just as happy to use xrender 
with the universal variant, since it provides the same software, just for more 
architectures.

The reverse is not necessarily true. You may have installed a port that 
requires 32-bit support, and therefore requires its dependencies to be 
installed with the universal variant. wine is the most common example of such a 
port.

Given the above list of installed ports, "sudo port reclaim" should uninstall 
the non-universal xrender, because it is inactive.

Re: Help with #!/usr/bin/perl

[Ryan Schmidt]

On Jun 16, 2018, at 17:01, Michael wrote:

> Let's say I have a bunch of scripts that start with #!/usr/bin/perl
> 
> There is a python_select,but not a perl_select.
> 
> How do I avoid the out of date system Perl, which doesn't have the needed 
> support modules, and installing those modules with Mac ports doesn't put them 
> where the system Perl sees them.

To do this for all files in a port's destroot directory whose names end with 
".pl":


post-destroot {
fs-traverse f ${destroot} {
if {[file extension ${f}] eq ".pl"} {
reinplace "s|^#!/usr/bin/perl|#!${prefix}/bin/perl${perl5.major}|" 
${f}
}
}
}


(Assuming you have properly included the perl5 1.0 portgroup, or else manually 
set perl5.major to the right value.)

Re: Help with a local port file -- compiling

[Ryan Schmidt]

On Jun 16, 2018, at 19:12, Rainer Müller wrote:

> On 2018-06-17 01:47, Michael wrote:
>> How do I force port to compile a port when I have a local port file?
>> 
>> If I say "port build git", it will build with my local port file, and local 
>> patches.
>> 
>> Unfortunately, I cannot figure out how to make it install this.
> 
> If you already have the port installed with the exact same combination
> of name/version/revision/epoch, it will not be rebuilt from source.
> 
> You will either have to increase the revision in the Portfile or
> uninstall the version you already have installed.

Or force a rebuild from source and reinstallation:

sudo port clean git
sudo port -ns upgrade --force git

Re: Help with a local port file

[Ryan Schmidt]

On Jun 16, 2018, at 18:13, Michael wrote:

> On 2018-06-16, at 3:51 PM, Michael wrote:
> 
>> I'm trying to use a local port file, and it's not working. What am I doing 
>> wrong?
>> 
>> bash-3.2# cat /opt/local/etc/macports/sources.conf
>> # $Id: sources.conf 106803 2013-06-08 16:22:39Z lar...@macports.org $
>> 
>> # For proper functionality of various resources (port groups, mirror
>> # sites, etc.), the primary MacPorts source must always be tagged
>> # "[default]", even if switched from the default "rsync://" URL.
>> 
>> file:///Users/michael/Documents/ports
>> rsync://rsync.macports.org/release/tarballs/ports.tar [default]
>> bash-3.2# ls /Users/michael/Documents/ports/devel/
>> .DS_Store  git/   
>> bash-3.2# ls /Users/michael/Documents/ports/devel/git/
>> total 16
>> 8 .DS_Store 8 Portfile  0 files/
>> bash-3.2# port dir git
>> /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/devel/git
>> bash-3.2# 
>> 
>> It refuses to find my local port directory/port file
> 
> Solution:
> 
> cd ~/Documents/ports/
> portindex

Yes of course your ports must be indexed for MacPorts to be able to find them.

Since you've listed the directory in sources.conf, "sudo port sync" should 
update and index them.

Re: Help with a local port file

[Ryan Schmidt]

On Jun 16, 2018, at 17:51, Michael wrote:

> rsync://rsync.macports.org/release/tarballs/ports.tar [default]

It's unrelated to the issue you're reporting, but that URL is deprecated; you 
should change it to:

rsync://rsync.macports.org/macports/release/tarballs/ports.tar [default]

Re: Doing my weekly "port -u uninstall", and...

[Ryan Schmidt]

On Jun 17, 2018, at 11:52, Dave Horsfall wrote:

> --->  Uninstalling sqlite3 @3.23.1_0+universal
> --->  Cleaning sqlite3
> You haven't run 'sudo port reclaim' in two weeks. It's recommended you run 
> this regularly to reclaim disk space. Would you like to run it now? [Y/n]:y
> --->  Checking for unnecessary unrequested ports
> Error: reclaim failed: can't read "isrequested(adwaita-icon-theme)": no 
> such element in array
> 
> OK; what went wrong this time?  I don't even know what 
> "adwaita-icon-theme" is!

"adwaita-icon-theme" a port for a Gnome icon theme, which you presumably had 
installed.

Unfortunately I can't explain why you're encountering this error.

Re: 'can't read "os.subplatform": can't read "os_subplatform": no such variable'

[Ryan Schmidt]

On Jun 16, 2018, at 16:02, Kevin Reid wrote:

> I just ran a selfupdate and it prompted me to run reclaim and during the 
> reclaim process produced this error.
> 
> --->  Updating MacPorts base sources using rsync
> MacPorts base version 2.4.3 installed,
> MacPorts base version 2.5.2 downloaded.
> ...
> --->  Building list of distfiles still in use
> Warning: Failed to open port libiconv from registry: can't read 
> "os.subplatform": can't read "os_subplatform": no such variable
> ...[repeat for what looks like every installed port]...
> Warning: Failed to open port gegl from registry: can't read "os.subplatform": 
> can't read "os_subplatform": no such variable
> --->  Searching for unused distfiles
> Found 135 files (total 725.69 MiB) that are no longer needed and can be 
> deleted.
> 
> So far, everything else seems to be proceeding normally, but I figured I'd 
> report this in case it's a bug that should be fixed or has other implications.

os.subplatform was added to MacPorts in version 1.9.0, back in 2010. It should 
always be set--to "macosx" if you are running MacPorts on macOS, or to 
"puredarwin" on any other Darwin variant. It should not be possible for you to 
encounter this error on macOS...

The way that MacPorts determines that you are running on Darwin is to inspect 
the $tcl_platform(os) variable, a standard Tcl variable: http://wiki.tcl.tk/1649

I don't know how Tcl determines the value of that variable, but presumably it's 
similar to how "uname -s" works. Does running "uname -s" on your system work 
correctly?

Re: Advice on distributing a project

[Ryan Schmidt]

On Jun 14, 2018, at 12:58, Langer, Stephen A. (Fed) wrote:

> Thanks for the advice.  If I make a new non-standardly located macports 
> directory on my system, build my program and all of its dependencies in that 
> directory (including dependencies that aren't packaged with macports), and 
> then package it with "port mpkg", is that guaranteed to avoid conflicts on 
> users' systems?  I'd be using both a non-default installation prefix in my 
> portfile, and also a non-default version of macports to build it.

Note that "port mpkg" will only include files that were (or can be) installed 
by MacPorts (with "sudo port install ..."). If your software depends on things 
that aren't in MacPorts, you'll have to write Portfiles for those things first, 
and either contribute them to MacPorts for inclusion in our repository, or at 
least have them available in the PortIndex of the MacPorts installation in 
which you run "port mpkg".

Re: gcc49 fails to build

[Ryan Schmidt]

On Jun 10, 2018, at 23:05, Dave Horsfall wrote:

> Sanitised version attached; it's a bit out of date, but the hardware has not 
> changed.
> 
> I'll attempt another High Sierra upgrade later, when I have a few hours to 
> spare, and report back.
> 
> -- Dave


Ok, so you have the MacBook6,1. That is supposed to be supported by High Sierra.

Re: gcc49 fails to build

[Ryan Schmidt]

On Jun 10, 2018, at 23:39, Dave Horsfall wrote:

> On Sun, 10 Jun 2018, Ken Cunningham wrote:
> 
>> Dave, I would be tempted to uninstall gcc49 and just see what happens. I 
>> don't think you need it.
> 
> OK, with trepidation:
> 
>ozzie:~ dave# port uninstall gcc49
>--->  Deactivating gcc49 @4.9.4_2
>--->  Cleaning gcc49
>--->  Uninstalling gcc49 @4.9.4_2
>--->  Cleaning gcc49
> 
> Well, nothing seemed to have depended upon it, but I guess I'll find out when 
> I run my regular weekly check :-)
> 
> Q: Shouldn't old stuff be cleaned out for me?  Or do I have to keep track of 
> them myself?
> 
> Sorry for seeming to be so obstreperous, but under FreeBSD this sort of thing 
> "just works"...  And no, I am not denigrating the Mac etc; it is just one of 
> the many horses in my stable.

MacPorts doesn't uninstall ports for you unless you ask it to.

The "leaves" pseudoport can be useful to find ports that you may no longer need:

port installed leaves

Re: gcc49 fails to build

[Ryan Schmidt]

On Jun 5, 2018, at 11:42, Dave Horsfall wrote:

> Speaking of Xcode, I keep being offered to upgrade it, but it will only run 
> on High Sierra.

I assume this upgrade offer is coming from the Mac App Store. I'm not sure why 
it would offer you a version of Xcode that's not compatible with your OS. It's 
supposed to know when something requires a newer OS, and only display it as an 
"incompatible update" which cannot be installed. That's what happens for me on 
Sierra.


> The first time I tried that, I got a message about something being 
> incompatible with this box which I couldn't write down fast enough before it 
> reverted to Sierra.  The next time I tried (paying more attention this time), 
> it bombed out because a critical file was missing...

I can't really diagnose the problem based on that description. Upgrading to 
High Sierra will not fix the gcc49 build failure, but if you'd like to upgrade 
to High Sierra anyway and are having trouble, please let us know your exact 
computer model, and the specific error messages you're encountering.

Re: gcc49 fails to build

[Ryan Schmidt]

On Jun 4, 2018, at 16:05, Dave Horsfall wrote:

> On Mon, 4 Jun 2018, Ryan Schmidt wrote:
> 
>>> I won't include the entire log (yet), as I'm sure that I'm not the only 
>>> one.  What I certainly do *not* want, however, is to rebuild GCC, so I 
>>> consider this to be a blessing in disguise :-)
>> 
>> We can't guess what the problem is. Please file a bug report and attach the 
>> compressed main.log.
> 
> I like to make sure that I'm not duplicating a bug report -- how do *you* go 
> bug-hunting? -- but OK, one hidously-long filename "main.log.gz" attached...
> 
> In the meantime, you seem to have missed the other part of my message, viz: 
> how do I *not* recompile GCC?  That will bring this old MacBook to its knees, 
> and I have better things to do with it than have character echo times 
> measured in seconds...
> 
> -- Dave

Here is the bug report corresponding to that problem:

https://trac.macports.org/ticket/56511

gcc4x is not compatible with Xcode 9.2. It may not be compatible with any Xcode 
9.x. Use gcc5 or later if possible. We don't plan to backport the fixes to make 
gcc4x compatible with newer Xcode.

Re: gcc49 fails to build

[Ryan Schmidt]

On Jun 4, 2018, at 03:42, Mojca Miklavec wrote:

> On 4 June 2018 at 05:36, Dave Horsfall wrote:
>> --->  Building gcc49
>> Error: Failed to build gcc49: command execution failed
>> Error: See
>> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc49/gcc49/main.log
>> for details.
>> Error: rev-upgrade failed: Error rebuilding gcc49
>> 
>> I won't include the entire log (yet), as I'm sure that I'm not the only one.
>> What I certainly do *not* want, however, is to rebuild GCC, so I consider
>> this to be a blessing in disguise :-)
> 
> To me this looks like the macports-libstdc++ issue that was solved in
> MacPorts 2.5.1.

Why do you suspect that?

The only change in MacPorts 2.5.0 is that it keeps track of which C++ standard 
library ports are using. 2.5.0 neglected to notice a few cases where it was 
possible to infer which C++ library was used when the port did not specify it. 
That's fixed in 2.5.1. So 2.5.1 might not consider gcc49 to be broken and to 
need a reinstall.

However nothing in 2.5.0 or 2.5.1 should have broken the compilation of gcc, so 
the build failure has a different cause.

Re: gcc49 fails to build

[Ryan Schmidt]

On Jun 3, 2018, at 22:36, Dave Horsfall wrote:

> --->  Building gcc49
> Error: Failed to build gcc49: command execution failed
> Error: See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc49/gcc49/main.log
>  for details.
> Error: rev-upgrade failed: Error rebuilding gcc49
> 
> I won't include the entire log (yet), as I'm sure that I'm not the only one.  
> What I certainly do *not* want, however, is to rebuild GCC, so I consider 
> this to be a blessing in disguise :-)

We can't guess what the problem is. Please file a bug report and attach the 
compressed main.log.

Re: GIMP 2.10.2 - two packages

[Ryan Schmidt]

On Jun 2, 2018, at 08:46, FritzS - gmx wrote:

> Am 02.06.2018 um 15:34 schrieb Rainer Müller:
> 
>> On 2018-06-02 10:00, FritzS - gmx wrote:
>>> Whats are the differences between this two packages of GIMP?
>>> 
>>> Make this version an GIMP.app?
>>> https://github.com/macports/macports-ports/blob/master/graphics/gimp/Portfile
>>> gimp 2.10.2 (source)
>>> GIMP - Batteries Included
>>> 
>>> https://github.com/macports/macports-ports/blob/master/graphics/gimp2/Portfile
>>> gimp2 2.10.2 (source)
>>> The GNU Image Manipulation Program
>> 
>> The gimp2 port is just GIMP itself. The gimp port installs gimp2 as a
>> dependency, but also additional plugins and a .app launcher provided by
>> the gimp2-launcher port.

Actually, the gimp port depends on the gimp-app port, not the gimp2-launcher 
port. I'm not sure why we have two different ports that provide gimp apps.


>> If you want GIMP with everything that is available, just install the
>> gimp port:
>> 
>> $ sudo port install gimp
>> 
>> Hope that helps,
>> Rainer
> 
> Thanks!
> 
> One question too, where gives an description how I could make an gimp.app?

You could read the code of the gimp-app or gimp2-launcher ports:

https://github.com/macports/macports-ports/blob/master/aqua/gimp-app/Portfile

https://github.com/macports/macports-ports/blob/master/aqua/gimp2-launcher/Portfile

Re: possible to enable debug symbols by default?

[Ryan Schmidt]

On Jun 1, 2018, at 22:11, Eitan Adler wrote:
> On 1 June 2018 at 02:14, Rainer Müller wrote:
>> On 1 June 2018 02:35:35 GMT+02:00, Eitan Adler wrote:
>>> Is it possible to get debug symbols enabled by default for ports? I'd
>>> like to always compile c-alike languages with "-g" and not have them
>>> stripped.
>> 
>> Wouldn't the debug symbols on macOS be written to a .dSYM bundle that is not 
>> installed?
> 
> ooh. good point. Where are those filtered out?

Who says they're filtered out? The better question is: how would they get 
installed, unless the project's Makefile included commands to do so? (And I'm 
guessing most do not.)


P.S: I removed the lists.macosforge.org address from Cc; we don't use that list 
server anymore.

Re: possible to enable debug symbols by default?

[Ryan Schmidt]

On May 31, 2018, at 21:50, Eitan Adler wrote:
> On 31 May 2018 at 19:45, Ryan Schmidt wrote:
>> 
>> On May 31, 2018, at 21:42, Eitan Adler wrote:
>>> On 31 May 2018 at 19:40, Ryan Schmidt wrote:
>>>> Or: A setting in macports.conf that makes MacPorts base add -g for all 
>>>> ports? That would cause the built result to be different. We could offer 
>>>> that, but would have to also make sure that MacPorts doesn't attempt to 
>>>> download any binaries from our packages servers, since they would not have 
>>>> been built with that setting.
>>> 
>>> This one. Personally I'd be fine with "best effort" and fallback to
>>> packages, but I imagine some would not be.
>> 
>> That's not how MacPorts works.
>> 
>> When you ask MacPorts to install a port, it tries to get a binary package. 
>> If that fails, it tries to build from source.
>> 
>> If we introduce a new macports.conf setting that lets you enable debug 
>> symbols, and that setting is not on by default, then that setting will not 
>> be on on our buildbot workers which produce the binary packages. So if you 
>> get a binary package, you will not get debug symbols, even if that setting 
>> is on on your system. You will only get debug symbols if the port, for 
>> whatever reason, builds from source on your system. That would be confusing. 
>> Therefore, so that you get consistent behavior, if we introduce such a new 
>> setting, it must also prevent all use of binary packages.
> 
> I understand, and that's besides the point for now. Would we be
> generally okay with adding a new option to add -g globally?

I am neither accepting nor rejecting this proposal at this time.

> Perhaps include_debug_symbols true.

Some ports already offer a debug variant to do this. Just as we've standardized 
the universal variant in MacPorts, we could decide to standardize the debug 
variant as the way to do this.


> This ought to have three effects
> (a) include -g
> (b) exclude strip(1)

How would that be accomplished?

> (c) port specific changes at their option
> 
> this ought not to change optimization or related.

Re: possible to enable debug symbols by default?

[Ryan Schmidt]

On May 31, 2018, at 21:42, Eitan Adler wrote:
> On 31 May 2018 at 19:40, Ryan Schmidt wrote:
>> Or: A setting in macports.conf that makes MacPorts base add -g for all 
>> ports? That would cause the built result to be different. We could offer 
>> that, but would have to also make sure that MacPorts doesn't attempt to 
>> download any binaries from our packages servers, since they would not have 
>> been built with that setting.
> 
> This one. Personally I'd be fine with "best effort" and fallback to
> packages, but I imagine some would not be.

That's not how MacPorts works.

When you ask MacPorts to install a port, it tries to get a binary package. If 
that fails, it tries to build from source.

If we introduce a new macports.conf setting that lets you enable debug symbols, 
and that setting is not on by default, then that setting will not be on on our 
buildbot workers which produce the binary packages. So if you get a binary 
package, you will not get debug symbols, even if that setting is on on your 
system. You will only get debug symbols if the port, for whatever reason, 
builds from source on your system. That would be confusing. Therefore, so that 
you get consistent behavior, if we introduce such a new setting, it must also 
prevent all use of binary packages.

Re: possible to enable debug symbols by default?

[Ryan Schmidt]

On May 31, 2018, at 21:10, Eitan Adler wrote:
> On Thursday, 31 May 2018, Ken Cunningham wrote:
>> Well, to do that, you would have to change the default configure.optflags in 
>> portconfigure.tcl
>> 
>> open 
>> 
>> /opt/local/libexec/macports/lib/port1.0/portconfigure.tcl
>> 
>> and change 
>> 
>> default configure.optflags  {-Os}
>> 
>> to something like
>> 
>> default configure.optflags  {"-O0 -g"}
>> 
>> perhaps, or whatever works for you.

> 
> Would it be reasonable to add a supported option to add -g to C flags without 
> changing other things? Even with optimizations having some symbols are better 
> than nothing. 

What are you asking for?

A command that can be inserted into a Portfile to automatically add -g to 
configure.optflags for that port? That would be no easier than what Ken 
suggested.

Or: A setting in macports.conf that makes MacPorts base add -g for all ports? 
That would cause the built result to be different. We could offer that, but 
would have to also make sure that MacPorts doesn't attempt to download any 
binaries from our packages servers, since they would not have been built with 
that setting.

Re: Testing Oracle InstantClient 12.2.0.1.0

[Ryan Schmidt]

On May 31, 2018, at 17:40, Daniel Wilks wrote:
> 
> Thanks.  I’ve already updated the Portfile and am installing the symlinks as 
> files which is working.  It just pointed out to me that I have no idea how to 
> install a symlink.

I haven't attempted to do this update yet, so I'm looking forward to your pull 
request or ticket!

Re: Anyone else seeing large numbers of configure failures post 2.5.0?

[Ryan Schmidt]

On May 31, 2018, at 08:04, Lee Bast wrote:

> Hello all,
>   Before I dive into this any farther I'm curious if anyone else has 
> noticed something or if it's specific to me. Across 3 different machines (2 
> MPs and an rMBP) running a mix of 10.12.6 and 10.13.4 I did a standard 
> self-update/upgrade outdated cycle and saw configure failures of everything 
> from ffmpeg to curl to openldap, most either are dependencies or configured 
> with no variant changes. No other system changes were made, and the installed 
> list isn't exotic. At least on one of them I have zfs installed so I can just 
> rollback, on the others I guess I'll nuke and pave and see whether it returns.
> 
>   When I first saw it affect curl I thought it might be just that one 
> port, but now that I've seen errors across a bunch of standard ports on 
> multiple systems I'm wondering if it might be something lower level (which 
> would make individual failures and their logs a red herring and not worth 
> bothering maintainers with error reports over). If no one else is having 
> issues though I'll poke at it myself later instead.

No, we've receive no other reports of that. If you show us the errors you're 
getting, maybe we can help figure out what's wrong.

Re: Hey there I got this output from the -d self update, plz help.

[Ryan Schmidt]

On May 29, 2018, at 08:58, Rainer Müller wrote:

> On 2018-05-29 06:24, Shuvayan wrote:
> 
>>> On 29-May-2018, at 9:47 AM, Shuvayan wrote:
>>> 
>>> Output:DEBUG: Copying
>>> /Users/shuvayan/Library/Preferences/com.apple.dt.Xcode.plist to
>>> /opt/local/var/macports/home/Library/Preferences
>>> Version number in metadata table is newer than expected.
>>> while executing
>>> "registry::open $db_path"
>>> (procedure "mportinit" line 642)
>>> invoked from within
>>> "mportinit ui_options global_options global_variations"
>>> Error: /opt/local/bin/port: Failed to initialize MacPorts, Version
>>> number in metadata table is newer than expected.
>>> 
>> 
> 
> I am not sure how you got into this state, but you should be able to
> recover by installing MacPorts 2.5.0 from the .pkg installer.

Isn't the metadata table part of the registry? Why would reinstalling MacPorts 
affect the registry?

Re: MacPorts 2.5.0-beta1 now available for testing

[Ryan Schmidt]

On May 26, 2018, at 14:38, Ken Cunningham wrote:

> On May 26, 2018, at 12:27 PM, Ryan Schmidt wrote:
> 
>> The error occurs when there is a mismatch between which C++ standard library 
>> a port says it uses (by setting configure.cxx_stdlib, or by leaving it set 
>> to its default value) and which C++ standard library it actually links with.
> 
> Right. 
> 
> Indeed I did not realize that each and every portfile would be examined for 
> cxx_stdlib overrides for each different system configuration, and that would 
> be integrated into the check mechanism for the build.
> 
> So if he had wanted to (and assuming the linkages worked out), Zero could 
> have also just as correctly put 
> 
> configure.cxx_stdlib libstdc++
> 
> into his unar portfile, and left things alone.

Yes, if unar does not link with any C++ libraries, and does not provide any C++ 
libraries, that would also be fine.

Re: MacPorts 2.5.0-beta1 now available for testing

[Ryan Schmidt]

On May 26, 2018, at 14:25, Ken Cunningham wrote:

> On May 26, 2018, at 9:49 AM, Ryan Schmidt wrote:
> 
>> On May 26, 2018, at 11:48, Ken Cunningham wrote:
>> 
>>> Well I think you did the cmake finaggeling last time Not sure you could 
>>> find a better way, but I wait to see...
>> 
>> I don't recall what you're referring to.
> 
> if {!((${os.platform} eq "darwin" && ${os.major} < 10) || ${build_arch} eq 
> "ppc" || ${build_arch} eq "ppc64")} {
>depends_lib-append port:libcxx
>configure.cxx_stdlib libc++
> }
> 
> So this forces a build against libc++ on systems that have cxx_stdlib set to 
> libstdc++.
> 
> Will this trigger an error? 

No, because the port correctly indicates, by setting configure.cxx_stdlib, 
which C++ standard library will be used.


> Maybe I don’t understand exactly how the error mechanism is setup.

The error occurs when there is a mismatch between which C++ standard library a 
port says it uses (by setting configure.cxx_stdlib, or by leaving it set to its 
default value) and which C++ standard library it actually links with.

Re: MacPorts 2.5.0-beta1 now available for testing

[Ryan Schmidt]

On May 26, 2018, at 11:48, Ken Cunningham wrote:

> Well I think you did the cmake finaggeling last time Not sure you could 
> find a better way, but I wait to see...

I don't recall what you're referring to.

Re: MacPorts 2.5.0-beta1 now available for testing

[Ryan Schmidt]

On May 26, 2018, at 11:15, Ken Cunningham wrote:

> On May 25, 2018, at 12:05 PM, Ryan Schmidt wrote:
> 
>> It's "broken" in that it links with libstdc++, even though MacPorts believes 
>> it will link with libc++ on your system. The rev-upgrade code in previous 
>> versions of MacPorts did not check for this kind of "broken".
>> 
>> Fix it by fixing the build system to use the right C++ standard library (the 
>> one in the ${configure.cxx_stdlib} variable).
> 
> So this particular port comes up with this error probably because the 
> deployment target is set to 10.6 in the xcode project. 
> 
> But there are _lots_ of ports that don’t build with the c++ stdlib specified 
> in cxx_stdlib.
> 
> These are forced one way or the other in a way that works to fix a problem — 
> eg. cmake and many others.

Then all of these ports need to be fixed. Either make the port use the C++ 
standard library that MacPorts sets in configure.cxx_stdlib, or else set 
configure.cxx_stdlib to the C++ standard library that the port will use (this 
is acceptable if the port uses no libraries and provides no libraries; mongodb 
is an example).


> Also, on systems with libcxxonoldersystems, xcodebuild will not accept 
> certain settings on certain systems, even if we know they could work with our 
> newer compilers.

Unfortunately, we have no way to tell Xcode to use one of our compilers. I 
believe we need to create some kind of Xcode-specific file to tell it about 
each of our compilers, then update the xcode portgroup to use that. Nobody's 
done that so far.


> We might see quite a few errors with this, I suspect…

Then we will have to fix quite a few things.

Re: reinstalling Macports

[Ryan Schmidt]

On Apr 18, 2018, at 23:42, Ryan Schmidt wrote:

> Thanks. I think this problem was introduced by a presumably unintentional 
> part of this commit:
> 
> https://github.com/macports/macports-ports/commit/e3710d6800e803ebaa9528d3bdb38fb2fcade513#diff-5513a677784c8c1520463fedf268a37f
> 
> I think that needs to be reverted, and the tk port's revision increased to 
> ensure any incorrect builds out there get fixed.
> 
> Vince?

The problem was brought up again in this ticket:

https://trac.macports.org/ticket/56531

I fixed by reverting Vincent's change:

https://github.com/macports/macports-ports/commit/a11b15ca0f34af6272ed560aba505e08da45e360

Re: MacPorts 2.5.0-beta1 now available for testing

[Ryan Schmidt]

On May 25, 2018, at 12:57, Zero King wrote:

> On Thu, May 17, 2018 at 11:36:39PM +1000, Joshua Root wrote:
>> It's been a week with no new tickets filed against base. I'll give it
>> one more week and then, if nothing comes up, tag a release candidate.
>> 
>> - Josh
> 
> I tried the rc1, and unar is now "broken". How can I fix it?
> 
> unar is using libstdc++ (this installation is configured to use libc++)
> Error: Port unar is still broken after rebuilding it more than 3 times.

It's "broken" in that it links with libstdc++, even though MacPorts believes it 
will link with libc++ on your system. The rev-upgrade code in previous versions 
of MacPorts did not check for this kind of "broken".

Fix it by fixing the build system to use the right C++ standard library (the 
one in the ${configure.cxx_stdlib} variable).

Re: libquicktime-devel hangs on build

[Ryan Schmidt]

On May 18, 2018, at 19:14, bunk3m wrote:

> I finally did the dist-upgrade to 2.4.4 on our iMac running 10.12.6
> 
> While doing a upgrade outdated, libquicktime-devel hangs.  So I can't update 
> transcode.  I see from the logs there are 404 not found errors.

The 404 errors relate to fetching a pre-compiled binary. Pre-compiled binaries 
are not available for this port, due to license restrictions of its dependency 
faac. So these 404 errors are normal.

When a precompiled binary is not available, MacPorts tries to fetch the source 
code and build it on your computer:

> :info:fetch cvs export: Updating libquicktime
> :info:fetch cvs export: [23:49:51] waiting for anoncvs_libquicktime's lock in 
> /cvsroot/libquicktime/libquicktime
> :info:fetch cvs export: [23:50:21] waiting for anoncvs_libquicktime's lock in 
> /cvsroot/libquicktime/libquicktime
> :info:fetch cvs export: [23:50:51] waiting for anoncvs_libquicktime's lock in 
> /cvsroot/libquicktime/libquicktime
> :info:fetch cvs export: [23:51:21] waiting for anoncvs_libquicktime's lock in 
> /cvsroot/libquicktime/libquicktime
> :info:fetch cvs export: [23:51:51] waiting for anoncvs_libquicktime's lock in 
> /cvsroot/libquicktime/libquicktime
> :info:fetch cvs export: [23:52:21] waiting for anoncvs_libquicktime's lock in 
> /cvsroot/libquicktime/libquicktime
> :info:fetch cvs export: [23:52:51] waiting for anoncvs_libquicktime's lock in 
> /cvsroot/libquicktime/libquicktime
> :info:fetch cvs export: [23:53:21] waiting for anoncvs_libquicktime's lock in 
> /cvsroot/libquicktime/libquicktime
> :info:fetch cvs export: [23:53:51] waiting for anoncvs_libquicktime's lock in 
> /cvsroot/libquicktime/libquicktime
> :info:fetch cvs export: [23:54:21] waiting for anoncvs_libquicktime's lock in 
> /cvsroot/libquicktime/libquicktime
> :info:fetch cvs export: [23:54:51] waiting for anoncvs_libquicktime's lock in 
> /cvsroot/libquicktime/libquicktime
> :info:fetch cvs export: [23:55:21] waiting for anoncvs_libquicktime's lock in 
> /cvsroot/libquicktime/libquicktime
> :info:fetch cvs export: [23:55:51] waiting for anoncvs_libquicktime's lock in 
> /cvsroot/libquicktime/libquicktime
> :info:fetch cvs export: [23:56:21] waiting for anoncvs_libquicktime's lock in 
> /cvsroot/libquicktime/libquicktime
> :info:fetch cvs export: [23:56:51] waiting for anoncvs_libquicktime's lock in 
> /cvsroot/libquicktime/libquicktime
> :info:fetch cvs export: [23:57:21] waiting for anoncvs_libquicktime's lock in 
> /cvsroot/libquicktime/libquicktime
> :info:fetch cvs export: [23:57:51] waiting for anoncvs_libquicktime's lock in 
> /cvsroot/libquicktime/libquicktime
> :info:fetch cvs export: [23:58:21] waiting for anoncvs_libquicktime's lock in 
> /cvsroot/libquicktime/libquicktime
> :info:fetch cvs export: [23:58:51] waiting for anoncvs_libquicktime's lock in 
> /cvsroot/libquicktime/libquicktime
> :info:fetch cvs [export aborted]: received interrupt signal

This port fetches from cvs, and some problem was encountered while doing so.

This project's development has moved to git, so the port should be updated. I 
filed a ticket for that:

https://trac.macports.org/ticket/56509#ticket

Fetching from git is more common, so you should experience fewer problems with 
that.

Re: Inkscape @0.92.3 appears to show wrong version ...

[Ryan Schmidt]

On May 11, 2018, at 05:35, g5pw wrote:

> On 11 May 2018, at 09:56, Roy Henderson wrote:
> 
>> With help from this list I think I have installed port Inkscape @0.92.3 but 
>> when I launch the application the Help/About screen shows 0.92.2 with a date 
>> of 2018-03-11.
>> 
>> My next step is to try and determine if this is a problem within the port or 
>> within Inkscape.
>> 
>> If anyone has Inkscape @0.92.3 installed I would appreciate if they could 
>> post the version information shown in the top-right corner of the Help/About 
>> screen.
> 
> Hmm, interesting, I also see "Inkscape 0.92.2 2405546, 2018-03-11” in the 
> help/about screen. This might just be an error in the string, though (maybe 
> the developers forgot to update it).

Here is the list of changes for the 0.92.x branch:

https://git.launchpad.net/inkscape/log/?h=0.92.x

The 0.92.3 tag was created on 2018-03-11 in 3ce5693 but the version in the 
configure.ac file was not updated to 0.92.3 until 2018-03-28 in d2272d9. So 
yes, the developers forgot to update it before the release.

If we need to rebuild inkscape for some other reason we should include that 
fix, but since it takes a long time to build and is not distributable, 
rebuilding just to fix the version string might be undesirable.

Re: non-interactive switch in shell mode?

[Ryan Schmidt]

On May 13, 2018, at 19:02, Richard DeLaurell wrote:

> The port command N-switch (for non-interactive) doesn't seem to work in shell 
> mode; is there an alternative?

It should work fine, to the extent that if you launch shell mode like this:

port -N

then the shell will not ask interactive questions.

Re: Octave 4.4.0

[Ryan Schmidt]

On May 13, 2018, at 02:25, david koloseni wrote:

> I have been installing octave on My machine Mac OS Siera, through Macports 
> package manager but it installs octave 4.2.2 instead of octave 4.4.0. what is 
> the problem? or what should I do to get Octave version 4.4.0?

File a ticket in the issue tracker requesting the maintainer update the port to 
version 4.4.0.

In the mean time, the octave-devel port is available, which uses version 4.3.0+.

Re: kde help center -- "The file or folder help:/XYZ does not exist

[Ryan Schmidt]

On May 11, 2018, at 16:46, Ian Wadham wrote:

> I think KDE 4 apps are still installed without docs in MacPorts because of an 
> intermittent
> build crash that could never get diagnosed and fixed.

Yup, it's still a problem.

https://trac.macports.org/ticket/53733#comment:4

Re: How to launch after a port?

[Ryan Schmidt]

On May 11, 2018, at 15:30, Ken Cunningham wrote:

> On 2018-05-11, at 12:52 PM, Ryan Schmidt wrote:
> 
>> At least when Inkscape is installed with the +x11 variant, its Dock icon 
>> will not function the way a normal Mac app's Dock icon would. Its icon will 
>> bounce forever
> 
> We should start moving ports to the new app PG enhancements so this kind of 
> thing stops happening.

I forgot about those.

Re: How to launch after a port?

[Ryan Schmidt]

On May 10, 2018, at 18:47, Roy Henderson wrote:

> However, when I try to launch it, Inkscape appears in the Dock bouncing so it 
> obviously wants some attention but I can’t figure what …

At least when Inkscape is installed with the +x11 variant, its Dock icon will 
not function the way a normal Mac app's Dock icon would. Its icon will bounce 
forever, for example, even when the application has launched normally; clicking 
the Dock icon after the app has been launched will do nothing; you cannot drag 
documents to the Dock icon; etc.

If you wish to switch to the +quartz variant, which may fix some of those 
issues, you should add +quartz to your sources.conf, and uninstall all ports 
that are installed with the +x11 variant and reinstall them with the +quartz 
variant.

Re: How to launch after a port? Now working - thanks!

[Ryan Schmidt]

On May 10, 2018, at 19:36, Roy Henderson wrote:

> Inkscape is 0.92.2 which is downlevel from the latest but perhaps MacPorts 
> doesn’t yet have the absolute latest version.

MacPorts Inkscape was updated to 0.92.3 on April 17:

https://github.com/macports/macports-ports/commit/605ff8491cd8b43ce5bacdcb5de7c4ad034abfb8

Run "sudo port selfupdate" to receive this and all other changes. Run 
selfupdate often to stay up to date.

Re: How install php7.2 with ZTS?

[Ryan Schmidt]

On May 8, 2018, at 15:10, Александр Искрижицкий wrote:

> I am new user of Mac and I need help.

Welcome!


> How I can install php7.2 with ZTS enabled? I need to work with pthreads 
> extension.

We don't have php with zts at this time. See discussion of the problems with 
that at https://github.com/macports/macports-ports/pull/437.

Re: kdelibs4@4.14.3_10 build fails on High Sierra

[Ryan Schmidt]

On May 2, 2018, at 21:41, Richard L. Hamilton wrote:

> Oddly enough, it builds fine on older e.g. El Capitan (I think even on Snow 
> Leopard, but that box is slow, so I don't know yet).
> 
> Will I have better luck using a different compiler, or does it just hate me? 
> :-)  I have 4.14.3_8 installed now (don't recall whether it was pre-built, or 
> whether I had any problems back then).
> 
> https://www.dropbox.com/s/4nldqbhvxbjgcig/main.log-kdelibs4.txt.gz?dl=0

The log shows these errors:

error: no member named 'openpty' in the global namespace

error: no type named 'login' in the global namespace

error: declaration of reference variable 'l_struct' requires an initializer

error: no type named 'logout' in the global namespace

I am not familiar with these errors, but I don't see why using a different 
compiler would change it. You should probably file a bug report in our issue 
tracker.

Re: ffmpeg on 10.5/PPC

[Ryan Schmidt]

On Apr 29, 2018, at 11:33, Riccardo Mottola wrote:

> On 2018-04-29 14:36:02 +0200 Ken Cunningham wrote:
> 
>> clang-3.4 will never work on PPC, so don't even bother.
> 
> In the sense that it is too broken? It actually starts compiling.

In the sense that the clang developers have not added enough support for 
PowerPC to clang to make it work.

Re: Compiling TeX Live on 10.5 (was: libatomic build failure 10.5/x86)

[Ryan Schmidt]

On Apr 25, 2018, at 13:46, Riccardo Mottola wrote:

> I need it just as a dependency of gtk2. It is interesting that my last 
> install (just 1 or 2 months ago) did not require it!

gtk2 requires gtk-doc. When gtk-doc was updated to version 1.28 last month, 
dblatex was added as a dependency.

https://github.com/macports/macports-ports/commit/638b959cbab079501073a9f1e9d3e931844e8c97

dblatex requires texlive.

Re: libatomic build failure 10.5/x86

[Ryan Schmidt]

On Apr 25, 2018, at 03:46, Riccardo Mottola wrote:

> Then I resume upgrading..  and something pulls in texlive-bin
> 
> --->  Computing dependencies for texlive-bin
> --->  Building texlive-bin
> Error: Failed to build texlive-bin: command execution failed
> Error: See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_tex_texlive-bin/texlive-bin/main.log
>  for details.
> Error: Problem while installing texlive-bin
> 
> 
> 
> I do not have it currently installed:
> 
>  texinfo @6.5_1 (active)
>  texlive-common @2017.1_0 (active)
> 
> 
> so it is not an upgraded but a new dependency?

Evidently.


> The error is an interna compiler error, not very reassuring!


> But gcc6 is checked as a dependency, I attach the log.
> 
> I notice this:
> :notice:configure --->  Configuring texlive-bin
> :debug:configure Preferred compilers: gcc-4.2 apple-gcc-4.2 gcc-4.0 
> macports-clang-3.4 macports-clang-3.3
> :debug:configure Using compiler 'MacPorts GCC 6'
> 
> toes this mean I have none of the "preferred" compilers ? I actually have 
> e.g. apple-gcc42 and also clang 3.4 from macports:
> 
> Koreander:~ multix$ port select clang
> Available versions for clang:
>   mp-clang-3.4
>   none (active)
> 
> So why is it using  gcc6? (not that gcc6 should ICE, but well...)

texlive-bin, like many other ports these days, requires a C++11-capable 
compiler. On PowerPC, we only use MacPorts gcc6 to build such ports.

Re: new installation trouble

[Ryan Schmidt]

On Apr 22, 2018, at 23:59, Ulrich Wienands wrote:

> On Apr 22, 2018, at 10:18 PM, Ulrich Wienands wrote:
> 
>> uli% sudo port -d selfupdate
>> Password:
>> DEBUG: Copying /Users/uli/Library/Preferences/com.apple.dt.Xcode.plist to 
>> /opt/local/var/macports/home/Library/Preferences
>> DEBUG: MacPorts sources location: 
>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs
>> --->  Updating MacPorts base sources using rsync
>> DEBUG: system: /usr/bin/rsync -rtzvl --delete-after 
>> rsync://rsync.macports.org/macports/release/tarballs/base.tar 
>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs
>> rsync: failed to connect to rsync.macports.org: No route to host (65)
>> rsync error: error in socket IO (code 10) at 
>> /SourceCache/rsync/rsync-45/rsync/clientserver.c(105) [receiver=2.6.9]
>> Command failed: /usr/bin/rsync -rtzvl --delete-after 
>> rsync://rsync.macports.org/macports/release/tarballs/base.tar 
>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs
>> Exit code: 10
>> [Ulis-MacBook-Pro:~] uli% 
>> 
>> So it says it cannot connect to rsync.macports.org. But I can ping it & it 
>> responds well.

> Ok, solved it myself: It looks like a firewall prevents rsync from working. 
> By Googling I found the workaround in editing the macports.conf file to use 
> https: instead. Now watching installs.
> 
> I do wonder whether there is a better way than to use Google to find the 
> answer.

It is true that MacPorts in its default configuration requires an rsync server 
in order to sync the ports tree, and in all configurations requires rsync in 
order to selfupdate base. It is true that firewalls, especially overly 
restrictive corporate firewalls, can prevent access to rsync servers, or any 
other servers, but rsync is prone to being blocked in this way because it uses 
a less-familiar port number than web or email servers. It is an error for 
network administrators to configure firewalls to block access to rsync servers, 
but unfortunately we cannot fix all network administrators.

Switching sources.conf to use an http tarball for sync works around the 
problem, at the expense of needing to transfer the full set of portfiles every 
time you sync. rsync has the advantage of only needing to transfer the 
differences since the last time you synced, which uses less bandwidth and is 
faster.

https://trac.macports.org/wiki/howto/PortTreeTarball

Another option is to have sources.conf get the ports directly from the Git 
repository. Like rsync, git transfers only differences, so updates are quick, 
but the disk space required is greater, and your computer has to spend time 
updating the portindex, because the portindex is created by the rsync server 
and is not stored in the git repository.

https://trac.macports.org/wiki/howto/SyncingWithGit

It might be nice if MacPorts came preconfigured to know about these various 
ways of getting the ports, and if one fails, it could try the others 
automatically, but nobody has worked on adding such functionality yet.

MacPorts doesn't support any method other than rsync for selfupdate. If you 
can't access rsync servers, you can't selfupdate; you have to manually install 
new versions of MacPorts base when they're released, for example by downloading 
and running the new installer from our web site.

It might be nice if selfupdate could optionally get sources from a web server 
instead, but no work has been done on that yet. It might be nice if selfupdate 
could download a pre-compiled binary (the official installer, for example) 
instead of having to compile from source, but no work has been done on that 
either.

It is an old issue. See https://trac.macports.org/ticket/16954

Re: missing icui18n for gem

[Ryan Schmidt]

On Apr 20, 2018, at 09:14, petr.2006 wrote:

> I am trying to instal gollum in gem:
> 
> sudo gem install gollum
> Building native extensions.  This could take a while...
> ERROR:  Error installing gollum:
>   ERROR: Failed to build gem native extension.
> 
>current directory: 
> /Library/Ruby/Gems/2.3.0/gems/charlock_holmes-0.7.6/ext/charlock_holmes
> /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/bin/ruby -r 
> ./siteconf20180420-50387-908xpy.rb extconf.rb
> checking for main() in -licui18n... no
> checking for main() in -licui18n... no
> 
> 
> ***
> *** icu required (brew install icu4c or apt-get install libicu-dev) 
> ***
> ***
> 
> I have 
> 
> port installed icu
> The following ports are currently installed:
>  icu @58.2_2 (active)
> 
> and 
> 
> in /opt/local/lib
> ls *icui18*
> libicui18n.58.2.dylib libicui18n.58.dylib libicui18n.a
> libicui18n.dylib
> 
> where could be the problem?

You haven't told "gem" where your MacPorts icu is located (and I don't know 
ruby so I don't know how to tell it).

Re: Jupyter 2 and Jupyter 3

[Ryan Schmidt]

On Apr 19, 2018, at 12:12, pagani laurent wrote:

> After totally cleaning my macports installation and reinstalling everything, 
> I ended up having py27-jupyter and py36-jupyter installed :
> 
> Macports>port -v installed py36-jupyter
> The following ports are currently installed:
>  py36-jupyter @1.0.0_1 (active) platform='darwin 16' archs='noarch' 
> date='2018-04-19T17:14:49+0200'
> Macports>port -v installed py27-jupyter
> The following ports are currently installed:
>  py27-jupyter @1.0.0_1 (active) platform='darwin 16' archs='noarch' 
> date='2018-04-19T11:58:23+0200’
> 
> but to activate the 2.7 version I can type :
> 
> jupyter notebook
> 
> while for activating the 3.6 version I finally found that I have to type the 
> old style command :
> 
> ipython3 notebook
> 
> Why can’t I activate a jupyter3 version ? I tried this command :
> 
> sudo port select --set jupyter3 py36-jupyter
> Password:
> Selecting 'py36-jupyter' for 'jupyter3' failed: The specified group 
> 'jupyter3' does not exist.
> 
> without success (ok, it was not offered but I tried…).

Looks like the py-juypyter port does not support the select mechanism. The 
request to add that support is here:

https://trac.macports.org/ticket/51529

Re: issue while building gdk-pixbuf on PPC

[Ryan Schmidt]

On Apr 20, 2018, at 01:17, Riccardo wrote:

> while installing gimp dependencies, on Leopart 10.5 PPC
> 
> --->  Building gdk-pixbuf2
> Error: Failed to build gdk-pixbuf2: command execution failed
> Error: See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_gdk-pixbuf2/gdk-pixbuf2/main.log
>  for details.
> 
> 
> there I see link errors:
> 
> :info:build /bin/sh ../libtool  --tag=CC   --mode=link /usr/bin/gcc-4.2 -arch 
> ppc  -pipe -Os -arch ppc -Wall  -L/opt/local/lib 
> -Wl,-headerpad_max_install_names -arch ppc -o pixbuf-read pixbuf-read.o 
> ../gdk-pixbuf/libgdk_pixbuf-2.0.la -L/opt/local/lib -lgmodule-2.0 -lgio-2.0 
> -lgobject-2.0 -lglib-2.0 -lintl -Wl,-framework -Wl,CoreFoundation -lpng16
> -L/opt/local/lib -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -lintl 
> -Wl,-framework -Wl,CoreFoundation
> :info:build libtool: link: /usr/bin/gcc-4.2 /usr/bin/gcc-4.2 -arch ppc -pipe 
> -Os -arch ppc -Wall -Wl,-headerpad_max_install_names -arch ppc -o 
> .libs/pixbuf-read pixbuf-read.o -Wl,-framework -Wl,CoreFoundation 
> -Wl,-framework -Wl,CoreFoundation  -L/opt/local/lib 
> ../gdk-pixbuf/.libs/libgdk_pixbuf-2.0.dylib /opt/local/lib/libgio-2.0.dylib 
> /opt/local/lib/libpng16.dylib /opt/local/lib/libgobject-2.0.dylib 
> /opt/local/lib/libgmodule-2.0.dylib /opt/local/lib/libgthread-2.0.dylib 
> /opt/local/lib/libglib-2.0.dylib /opt/local/lib/libintl.dylib
> :info:build ld: in /usr/bin/gcc-4.2, can't link with a main executable
> :info:build collect2: ld returned 1 exit status
> :info:build make[3]: *** [pixbuf-read] Error 1
> :info:build make[3]: Leaving directory 
> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_gdk-pixbuf2/gdk-pixbuf2/work/gdk-pixbuf-2.36.12/tests'
> 
> I attach the log.
> 
> is something not setup correctly on my side? Doing the "same" installs on 
> 10.5 but on x86 worked.

It builds fine for us on our PowerPC Leopard buildbot worker. We distribute a 
binary of it; I'm not sure why you didn't receive it.

Do you have the ld64 port installed? If not, try that. It provides a newer 
linker.

Re: upcoming removal of components from macOS Server: opportunity?

[Ryan Schmidt]

On Apr 18, 2018, at 06:07, William H. Magillwrote:

> One assumes that a big problem with any migration guide (or automated 
> process) will be with Apache and MAMP
> 
> I haven’t run OSX Server for several years now, but the difference in 
> locations between OSX Server’s locations (Site, etc.) and the standard Apache 
> 2 locations were always annoying. Then Apache changed its locations with 
> Apache 2.4 - which we just updated in the  port file notes, and partially 
> updated the MacPorts instructions on the WIKI. ( 
> https://trac.macports.org/wiki/howto/Apache2 ) 

Well, MacPorts changed the locations where we install Apache httpd, when we 
updated the apache2 port from version 2.2.x to 2.4.x. It wasn't related to any 
decision made by the Apache httpd project.


> One presumes that the remainder of the integration products - MAMP - MySQL / 
> PHP — will also be an issue.
> 
> I never used the MediaWiki part of OSX server, but one assumes it will have 
> the same Apache 2.4 integration issues.

macOS Server included MediaWiki? I thought it included a custom Apple-created 
wiki software.

Re: reinstalling Macports

[Ryan Schmidt]

Thanks. I think this problem was introduced by a presumably unintentional part 
of this commit:

https://github.com/macports/macports-ports/commit/e3710d6800e803ebaa9528d3bdb38fb2fcade513#diff-5513a677784c8c1520463fedf268a37f

I think that needs to be reverted, and the tk port's revision increased to 
ensure any incorrect builds out there get fixed.

Vince?


On Apr 18, 2018, at 04:08, pagani laurent wrote:

> Ryan,
> 
> I removed explicit tk installation from the myport.txt list, uninstalled tk 
> and restarted restore_ports.tcl myport.txt and all went through nicely.
> Tk has been reinstalled as requested from python ports as dependent port. And 
> in that case, it does not contain explicitly X.h and other such header files 
> as you can see in the new ”port contents tk” command return which I attach to 
> this mail but I also provide directly the difference between the two (left 
> side is the one from requested installation, left one from indirect 
> installation)  :
> 
> Macports>diff tk_contents.txt tk_contents_2.txt 
> 4,12d3
> <   /opt/local/include/X11/X.h
> <   /opt/local/include/X11/Xatom.h
> <   /opt/local/include/X11/Xfuncproto.h
> <   /opt/local/include/X11/Xlib.h
> <   /opt/local/include/X11/Xutil.h
> <   /opt/local/include/X11/cursorfont.h
> <   /opt/local/include/X11/keysym.h
> <   /opt/local/include/X11/keysymdef.h
> <   /opt/local/include/X11/xbytes.h
> 15,16d5
> <   /opt/local/include/tkIntXlibDecls.h
> <   /opt/local/include/tkMacOSX.h
> 18,19d6
> <   /opt/local/lib/Tk.icns
> <   /opt/local/lib/Tk.tiff
> 
> Hope this helps.
> 
> L.
> 
>