Re: Texmaker installation failed due to inability to build qt5 web engine

[Mojca Miklavec]

Dear Gregory,

On Fri, 4 Nov 2022 at 06:10, Gregory Dodwell wrote:
>
> :error:build Failed to build qt5-qtwebengine: command execution failed
...
> Other errors deep in the text-dump. Too long to paste here. Should I send a 
> .zip file of the build log somewhere? At a loose end.

The best way to report such issues is Trac where you can upload
main.log with complete logs of the failure:
https://trac.macports.org/wiki/Tickets

(It's nothing wrong if you ask for further advice on the list anyway,
but having the log available, or someone else with access to the
latest OS, is essential to be able to proceed).

Mojca

Re: Where Is pgAdmin3 Installed?

[Mojca Miklavec]

On Sat, 22 Sep 2018 at 10:27, Mike Crawford wrote:
>
> > > MacPorts doesn't have psql.
> >
> > Yes it does.
>
> No it doesn't.
>
> I've got postgresql10 installed, but it didn't come with psql,

There is a binary
/opt/local/bin/psql10
and if you run
sudo port select --set postgresql postgresql10
you'll have a working "psql" symlink to that binary.

> nor is psql a package in MacPorts.

This is never the correct criterium. You don't get a separate package
for each binary. It's pretty common to have multiple binaries in the
same package. (But yes, I admit that I often miss "MacPorts, please
tell me in which package I can find file X.")

> There is a question about psql and MacPorts on StackOverflow which
> suggests getting it from homebrew.

It would help to link to the question (and answer) rather than just
referring to "someone somewhere on the internet said it cannot be
done".
Installing Linux to get psql running is an equally legitimate
suggestion, but it doesn't mean that you cannot run it on MacPorts,
and in any case it doesn't mean that each StackOverflow answer is
correct or optimal.

Mojca

Re: `port install' from github tarball fails

[Mojca Miklavec]

Dear Werner,

Lion does not properly support HTTPS. You might need to recompile
MacPorts from source to link against a version of libcurl with full
SSL support.

See for example:
https://trac.macports.org/ticket/51516

Mojca

On Tue, 25 Sep 2018 at 11:15, Werner LEMBERG wrote:
>
>
> [macports-base 60483e6e71054bcd741a55901c52117077ec7c43]
>
> I'm working on a new Portfile for the `extractpdfmark' tool.  Within
> the file I have
>
>   github.setuptrueroad extractpdfmark 1.0.2 v
>   github.tarball_from releases
>
> After `port sync' I tried `port -v install' and I got
>
>   --->  Attempting to fetch extractpdfmark-1.0.2.tar.gz from
>   http://nue.de.distfiles.macports.org/extractpdfmark
>   [...]
>   --->  Attempting to fetch extractpdfmark-1.0.2.tar.gz from
>   https://github.com/trueroad/extractpdfmark/releases/download/v1.0.2
>   [...]
>   Error: Failed to fetch extractpdfmark: The requested URL returned error: 404
>
> Saying `curl --version' returns
>
>   curl 7.61.1 (x86_64-apple-darwin11.4.2)
> libcurl/7.61.1 OpenSSL/1.0.2p zlib/1.2.11 libidn2/2.0.5
> libpsl/0.20.2 (+libidn2/2.0.5)
>   Release-Date: 2018-09-05
>   Protocols: dict file ftp ftps gopher http https imap imaps pop3
> pop3s rtsp smb smbs smtp smtps telnet tftp
>   Features: AsynchDNS IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP
> UnixSockets HTTPS-proxy PSL
>
> which looks OK to me.
>
> Doing some manual tests with `curl' I tried
>
>   curl -o x 
> https://github.com/trueroad/extractpdfmark/releases/download/v1.0.2/extractpdfmark-1.0.2.tar.gz
>
> which returned a `you are redirected' HTML document (attached).
> However, adding the `-L' flag to curl (to follow redirections) makes
> the program successfully download the tarball.
>
> How shall I proceed?  It seems to me that I've hit a bug in
> macports...
>
>
> Werner
>
>
> PS: Looking into the log file I see
>
>   :notice:fetch --->  Attempting to fetch extractpdfmark-1.0.2.tar.gz
> from 
> https://github.com/trueroad/extractpdfmark/releases/download/v1.0.2
>   :debug:fetch Fetching distfile failed: error:1407742E:SSL
> routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version
>
> Maybe this is related also.

Re: Long build?

[Mojca Miklavec]

Dear Adam,

On Tue, 6 Nov 2018 at 05:24, Adam Dershowitz wrote:
>
> I’m upgrading dvisvgm from to 2.3.4_4 to 2.6.1_0.  I’m on a fairly recent 
> MacBook pro, and it has been building for 13 hours!  The process is “make” 
> and it’s taking 100% of just one CPU.  Does this sound correct?

No. Anything longer than a couple of minutes sounds wrong. The build
is not super fast as for some lightweight ports, but it's not
particularly heavy either.

> Should I just kill it and clean the port, then retry?

Yes.

> Also, is there a way to determine which ports are available as binaries from 
> the buildbots?

I agree that it would be cool to have a command to check that
automatically, but at the moment you can check it manually on
packages.macports.org, for example:
http://packages.macports.org/gcc7/

However the folder for dvisvgm doesn't exist due to:

$ port_binary_distributable.tcl -v dvisvgm
"dvisvgm" is not distributable because its license "GPL-3+"
conflicts with license "GPL-2" of dependency "libpaper"

(I wasn't aware that not ever GPL-2 is compatible with GPL-3+? Doesn't
that sound particularly strange?)

Sometimes the binary would not be available due to the builders not
being able to keep up with the queue fast enough, in particular when
someone submits a patch to all gcc compilers at once :), but this
clearly wasn't the case here.

Mojca

Re: How Mojave-ready is MacPorts?

[Mojca Miklavec]

On Mon, 12 Nov 2018 at 21:34, Dave Horsfall wrote:
> On Mon, 12 Nov 2018, Ryan Schmidt wrote:
>
> >> So I see; well, it's served me well for nine years...  I only upgrade
> >> hardware when forced to, so I guess it's time to put some of my pension
> >> aside for a MacBook Air or something.
> >
> > There are usually ways of shoehorning newer operating systems into
> > unsupported older systems, at the expense of some performance problems
> > or other issues.
>
> Sure, but after trying to upgrade to High Sierra twice (failing with
> different errors each time; the first was something about incompatibility,
> and the second was a critical file missing), I don't really feel like
> going through it all over again with Mojave.

Since you are talking about the optical drive and 10.6: is your
hardware even officially supported? The last OS officially working
with my MacBook pro from 2009 (hardly different from those from 2012,
the last ones being sold with optical drives) was 10.11. The fun thing
is that once I finally decided to upgrade it, I could no longer even
download 10.11. Yes, I could probably upgrade to 10.12 in one way or
another, but I would then likely get into troubles with security
patches, and I could run into performance issues, at which point I
would probably be better off with hackintosh :)

> Besides, the hardware is
> slowly dying on me; the audio chip is dead (I'm using either USB or BT as
> takes my fancy), the optical drive is damaged, the (replacement) battery's
> lifetime can be measured in minutes, and the system drive is external USB,
> so portable it ain't.

I replaced the SATA cable only three or four times, I bet it could be
the same problem at your end (I've never heard of sata cables failing
on other laptops). But probably not worth fixing if you plan to stop
using it soon anyway.

> For the record, I've been running this thing ever since Snow Leopard,
> faithfully updating all the time.

Mojca

Re: How Mojave-ready is MacPorts?

[Mojca Miklavec]

On Mon, 12 Nov 2018 at 22:32, Ryan Schmidt  wrote:
> On Nov 12, 2018, at 15:25, db wrote:
> > On 11 Nov 2018, at 13:00, Ryan Schmidt wrote:
> >
> >> I'll probably need to write a script to pull all the failures out of the 
> >> buildbot logs, since we don't have anything set up to do that yet. If 
> >> there are ports you want to use, check whether any issues are filed 
> >> against them in Trac before upgrading the OS.
> >
> > Whatever you write, could you add it to macports-contrib? I thought myself 
> > to pull all failures to know beforehand if and what should/could be 
> > upgraded from time to time, but it remains in my todo. It's a missing 
> > feature of MacPorts, at least for those that build from source. Is this 
> > information available throught the JSON API [1]?
> >
> > [1] https://build.macports.org/json/help
>
> What we really want is a web site where this information can more easily be 
> seen. I'm not writing that web site now, but if I get around to the scripts 
> and they give me the information we want, moving that into web space might be 
> the next task on the list.
>
> This was a GSoC project that didn't get done.
>
> https://trac.macports.org/wiki/SummerOfCode#build-stats

Maybe better links with two documents:
https://github.com/macports/macports-webapp/tree/master/docs

> I don't really want the public making massive numbers of http requests to the 
> buildmaster (which is what the script would do) because I fear it might be 
> slow and clog up the bandwidth. I can run the scripts on the same network as 
> the buildmaster and so not use up its bandwidth.

This is a no-go and it would takes forever anyway, even if there was
just a single person trying to do that (I know, I have a script :).

Mojca

Re: gimp2 install

[Mojca Miklavec]

On Wed, 14 Nov 2018 at 10:30, Chris Jones wrote:
> On 14/11/18 02:33, Uli Wienands wrote:
> > Ok, so I did upgrade tk. That went ok, sort of. In the process of
> > upgrading tk it butchered several other ports ("found 61 broken files, 5
> > broken ports"). In the process of fixing those it ran aground trying to
> > install zstd. As a result, my octave 4.2.1 is now kaput :-(.
> >
> > (Which explains why I do not routinely upgrade things. If it ain't broke
> > don't fix it.)
>
> chicken and egg. The update likely only broke *because* you do it so
> infrequently. If you update regularly there is a lot less chance of
> problems, as each update is much more incremental.

It's worth noting that one will almost definitely get something broken
when updating just a few ports at a time. Of course you can start
updating a few, but then you still need to run "sudo port upgrade
outdated" at the end, as well as perhaps make sure that some ports are
not accidentally pinned at an older version (I'm not sure about the
easiest and most reliable way to do that check).

>From the above text it's not clear whether other ports were upgraded or not.

Mojca

Re: Anyone running X11 apps on Mojave?

[Mojca Miklavec]

On Mon, 26 Nov 2018 at 10:36, Dr M J Carter wrote:
> On Sat, Nov 24, 2018 at 11:58:16AM +, Christopher Jones wrote:
>
> > Note that the version of Xquartz from [2]www.xquartz.com is in fact
> > just a packaging of the MacPorts version ! In fact, the maintainer
> > of the Xquartz releases has stated that they may well no longer make
> > releases there, and only maintain the MacPorts provided version (via
> > the xorg-server port) going forward.
>
> That's going to prove interesting for those of us using MacTeX: its
> copy of gs-X11 seems to request and require libraries in /opt/X11 at
> runtime, not just at setup.

There's no easy solution to this.

The only workaround would be using @rpath trickery to allow using a
dylib from a different path (but even then you could only perhaps
check /opt/local/lib, not any other random prefix that MacPorts might
be installed under). Or load the library at runtime. But if you do
require X11, you need to get it from somewhere, and defaulting to the
version from MacPorts for ghoscript in MacTeX would be utterly
strange. MacPorts ships with its own version of ghostscript (which
doesn't need /opt/X11), and there's no need to install ghostscript
with MacTeX (I never do) if you have MacPorts installed already.

Additionally, when I built the binaries for legacy macs (for any
system that's no longer supported by Apple; shipped with TeX Live by
default, but not with MacTeX which no longer works there), I tried to
make sure to not support X11 in any way, so you don't get any X11
bindings with metafont for example. Precisely because I hate to have
failing binaries just because the user did not install /opt/X11.

> (In our setups, /usr/local/bin comes
> before /opt/local/bin, for reasons I can be tedious about on request,
> so MacTeX's gs preempts MacPorts's.)

Mojca

Re: sunclock

[Mojca Miklavec]

On Tue, 11 Dec 2018 at 04:12,  wrote:
>
> Hi again,
>
> It didn't take as long as I thought it might.
> I created a local port and installed it.

Wonderful. May I suggest that you submit a pull request (or perhaps
open a trac ticket)?

(If this was a modification of an old port, it would probably be nice
to figure out how to convince git to connect the history with that old
file.)

> It compiled, installed and activated and said:
>
>   --->  No broken files found.
>   --->  Found 1 broken port, determining rebuild order
>   You can always run 'port rev-upgrade' again to fix errors.
>   The following ports will be rebuilt: llvm-gcc42 @2336.11+universal

Which OS version are you using? (Did you migrate MacPorts / the list
of desired ports from an earlier OS version?)

This error is harmless for your desire to have that other port
working, but it could be that we forgot to revbump llvm-gcc42 when
updating one of its dependencies, so maybe worth fixing in our
repository. I suspect that not many users ever install that port
except on super old systems.

Mojca

Re: macpro burning through hard drives -- ? video card pulling too much power?

[Mojca Miklavec]

On Tue, 8 Jan 2019 at 03:03, Ken Cunningham wrote:
>
> This has nothing to do with Macports, but  there are many people here who 
> know stuff about this...
>
> About six months ago I put a new Metal-capable Sapphire HD 7950 video card in 
> my 2010 MacPro (8 processors) to run Mojave. It required two extra power 
> cables to give it all the extra juice it needs, in addition to the usual bus 
> power. It seems to pull up to nearly 200W according to Tom's hardware 
> .
>
> Since then, I have bricked three SATA hard drives on that MacPro, two older 
> 2TB ones (2012 era) but one 2016 4TB SSHD that was pretty new.
>
> All three of the drives just disappeared off the desktop unexpectedly with a 
> message about not powering them off properly, and then at reboot would not 
> spin up, and never did work again.
>
> I'm suspicious that the 7950 is pulling too much power and causing the SATA 
> hard drives to fail. I also have an AJA Kona 3G in that machine that pulls 
> 20W.
>
> Anyone seen this?

I don't have a Mac Pro, so no such experience.
I only had to replace the broken SATA cable on my previous laptop
about 4 times, and the laptop before that was happily frying at 105
degrees (Celsius) and kept displaying the gray screen of death. (No,
these were by far not the only issues, just somewhat related ones to
yours.)

You are not supposed to replace parts in apple hardware, you should
buy new one. (I was surprised to see that the best pro one can buy is
just $7k nowadays, it used to be $12k.)

Mojca

Re: Python/boost problem

[Mojca Miklavec]

On Tue, 8 Jan 2019 at 01:18, Dave Horsfall wrote:
>
> Sierra, latest MacPorts.  Doing the usual "port upgrade outdated"...
>
>  --->  Staging itstool into destroot
>  --->  Installing itstool @2.0.2_3
>  --->  Activating itstool @2.0.2_3
>  --->  Cleaning itstool
>  Error: boost: Variant python27 conflicts with python36
>  Error: Unable to open port: Error evaluating variants

This "Unable to open port: Error evaluating variants" is totally
strange in any case.

(I'm totally speculating now, but it could even be a bug in MacPorts
base, but I don't know if you could explain how to reproduce it, and
without having a way to reproduce it, it's super difficult to figure
out what went wrong.)

Other than than, I would probably clean boost (or perhaps clean all
ports), run "port outdated" to check which ports are still in the
queue for update, and then retry.

Mojca

Re: gdb

[Mojca Miklavec]

Dear James,

On Sun, 6 Jan 2019 at 01:39, James Linder wrote:
>
> /Applications/Xcode.app/Contents/Developer/usr/bin/make -f Makefile all
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
>  -c -pipe -stdlib=libc++ -g -std=gnu++11  -arch x86_64 -isysroot 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk
>  -mmacosx-version-min=10.12 -Wall -W -fPIC -DQT_DEPRECATED_WARNINGS 
> -DQT_GUI_LIB -DQT_CORE_LIB -I. -I. 
> -I/opt/Qt5.12.0/5.12.0/clang_64/lib/QtGui.framework/Headers 
> -I/opt/Qt5.12.0/5.12.0/clang_64/lib/QtCore.framework/Headers -I. 
> -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/OpenGL.framework/Headers
>  
> -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/AGL.framework/Headers
>  -I/opt/Qt5.12.0/5.12.0/clang_64/mkspecs/macx-clang 
> -F/opt/Qt5.12.0/5.12.0/clang_64/lib -o main.o main.cpp
>
>
> [Haycorn] /Users/jam/nodups [511]% lldb nodups.app/Contents/MacOS/nodups
> (lldb) target create "nodups.app/Contents/MacOS/nodups"
> warning: (x86_64) 
> /Users/jam/nodups/nodups.app/Contents/Frameworks/QtGui.framework/Versions/5/QtGui
>  empty dSYM file detected, dSYM was created with an executable with no debug 
> info.
> warning: (x86_64) 
> /Users/jam/nodups/nodups.app/Contents/Frameworks/QtCore.framework/Versions/5/QtCore
>  empty dSYM file detected, dSYM was created with an executable with no debug 
> info.
> Current executable set to 'nodups.app/Contents/MacOS/nodups' (x86_64).

This merely says:
.../QtGui empty dSYM file detected
that the Qt which you are building against has not been compiled with
debug info.

Did you compile Qt manually (and in debug mode)?

Mojca

Re: Some glitches while porting Ola (openlighting.org) - autoreconf not found

[Mojca Miklavec]

Dear Christoph

On Sat, 12 Jan 2019 at 17:12, Christoph Kukulies wrote:
>
> Following the steps in
>
> https://www.openlighting.org/ola/mac-install/

Do you just want to use the port or did you want to help with the
development of that port?

It seems that we have the latest version of the software already
packaged in MacPorts, so unless that's broken (you should let us know
if it is), by far the easiest way to install it would be via

sudo port install ola

and this is probably also what the official documentation should
suggest trying first.


I'll try to answer some of the other questions nonetheless:

> I’m stumbling across some hurdles:
>
> first off: they ask me to install py27-protobuf
>
> and in the next step I should do a python —version and should install the 
> pyXX-protobuf fitting my python version.

That's probably a slightly unfortunate wording. What I suspect the
author meant was that if you happened to have python2.6 installed by
default (instructions might be of an older date), you would install
py26-protobuf INSTEAD OF py27-protobuf. Note that python2.6 should no
longer be used anyway.

In your case you probably did
sudo port select python python36
which gives the python version that's likely too new for ola (I didn't
check if it supports python 3; the version in MacPorts uses python 2.7
in any case).

(Or, reading further from your latest reply, it's more likely that you
installed python3 via Homebrew? What does "which python" return? If
you are mixing HomeBrew and MacPorts, you should at least try to
remove one from the path to make sure that you don't end up with half
of the binaries from one manager and the other half from another.)

You could set the environment to use python 2.7 by default (and then
switch back) with
sudo port select python python27
or you can use
/opt/local/bin/python2.7
direction when needed.

> But python —version gives 3.6.7 with me here. I don’t want tp spoil my python 
> environment, so I did nothing about it.
>
> Then comes the actual reason of my question:
>
> I did a git clone of the project and then I’m instructed to do a
>
> autoreconf -i
>
> but there is no autoreconf.

It comes with
sudo port install autoconf

Mojca

Re: Some glitches while porting Ola (openlighting.org) - autoreconf not found

[Mojca Miklavec]

On Sat, 12 Jan 2019 at 17:45, Christoph Kukulies wrote:
>
> Finally I tried:
>
> Christophs-MBP:ola kuku$ sudo port install ola
> Password:
> --->  Computing dependencies for ola
> Error: Can't install protobuf3-cpp because conflicting ports are active: 
> protobuf-cpp

That's most likely the result of the manual installation of that port
when you followed the installation instructions:

# not asking you to repeat this!
sudo port install pkgconfig cppunit protobuf-cpp libmicrohttpd
libusb py27-protobuf

So most likely
sudo port deactivate protobuf-cpp
should solve the problem. If it doesn't, it will tell you which other
ports depend on protobuf-cpp, and then you can check whether you can
deactivate/uninstall those.

Mojca

Re: conflicting variants while rebuilding a dependency

[Mojca Miklavec]

Dear Riccardo,

On Sat, 12 Jan 2019 at 19:17, Riccardo Mottola via macports-users
 wrote:
>
> Hi all!
>
> I get this (Lion 10.7):
>
> -->  Scanning binaries for linking errors
> Could not open /opt/local/lib/libexiv2.26.dylib: Error opening or
> reading file (referenced from /opt/local/lib/libgexiv2.2.dylib)
> --->  Found 1 broken file, matching files to ports
> --->  Found 1 broken port, determining rebuild order
> You can always run 'port rev-upgrade' again to fix errors.
> The following ports will be rebuilt: gexiv2 @0.10.8+python27+python36
> Continue? [Y/n]:
> Error: boost: Variant python27 conflicts with python36
> Error: Unable to open port: Error evaluating variants
> Error: rev-upgrade failed: Error rebuilding gexiv2
> Error: Follow https://guide.macports.org/#project.tickets to report a
> bug.
>
>
> is this a "change" ? my current active port has indeed both variants:
>
> The following ports are currently installed:
>gexiv2 @0.10.8_1+python27+python36 (active)
>
> So, I suppose that when it was installed, the two python variants were
> possible, but now now anymore?

gexiv2 still has both variants enabled by default. In some ports this
is allowed, but in many it is not, if nothing else because one cannot
run a single configure step that would enable two python versions.

I didn't test, but I assume that you might be able to do
sudo port install gexiv2
but not
sudo port install gexiv2 +python27 +python36
if some of the dependencies with python variants are not yet
installed, or waiting for update.

This might well be a bug, or rather an unfortunate coincidence with no
easy workaround.
What happens if you clean all the ports and run
sudo port install gexiv2
manually instead of waiting for rev-upgrade?

Mojca

Re: problem with reactivating ports

[Mojca Miklavec]

Dear Werner,

On Sun, 13 Jan 2019 at 14:26, Werner LEMBERG wrote:
>
> I wanted to compile a project under MacPorts, and at the same time I
> wanted to protocol what MacPorts packages must be installed in advance
> before starting compilation.  My glorious idea was to say
>
>   port echo active > macports.active
>   sudo port deactivate `cat macports.active`
>
> to deactivate all MacPorts packages.  I tried with the `-y' flag in
> advance, just to be sure...

I understand the first command, but a much better way for the second
one would be
sudo port deactivate active

> It seems now that this was actually a bad idea.  First of all, `port'
> aborted in the middle, talking about not being able to deactivate
> `libgcc8' (which is on the `macports.active' list).

I'm not really sure, but one thing that might happen is that the list
of ports to be deactivated comes in wrong order. If B depends on A and
you call
sudo port deactivate A B
then I might fail to deactivate since port is processing them in the
same order as they are written and complains that B depends on A, so A
cannot be deactivated unless you force it or run it in a recursive
way.

(Reading further, another reason could be that the ports you tried to
deactivate cannot be deactivated as they are needed for the port
command itself.)

>  Secondly,
> restarting `port' no longer works; it complains as follows
>
>   dlopen(/opt/local/libexec/macports/lib/pextlib1.0/Pextlib.dylib, 6):
> Library not loaded: /opt/local/lib/libcurl.4.dylib
>   Referenced from: /opt/local/libexec/macports/lib/pextlib1.0/Pextlib.dylib
>   Reason: Incompatible library version:
> Pextlib.dylib requires version 10.0.0 or later,
> but libcurl.4.dylib provides version 7.0.0

This is somewhat strange. This is my blind guess / speculation of what
you did (I might be wrong). 10.7 became nearly hopeless with respect
to fetching the sources (distfiles) after the servers started
requiring a newer version of SSL protocol than what 10.7 can handle by
default. So you probably recompiled MacPorts with something like
--with-curl=/opt/local, but making a self-reference, and you ended up
with a chicken-and-egg problem?

> As a first aid I tried to re-install `port' from `macports-base', but
> I still get this error.
>
> My questions.
>
> * How can I restore (i.e., re-activate) all installed MacPorts
>   packages?  Given that I'm on Lion, I would *really* avoid
>   recompiling everything from scratch...

If you want to avoid recompiling the ports themselves, it would
probably make most sense to recompile macports (without
--with-curl=/opt/local, or perhaps with another curl that's installed
elsewhere) and run the port command again.

If you want to use a different libcurl, you could install that libcurl
somewhere else. You can install two parallel macports (just make sure
that you configure it properly to avoid clashes in
/Applications/MacPorts, disable the services etc.) and then use one of
them just as "supporting system" for the other one. We would have
fixed this long ago if it wasn't for the chicken-and-egg issue :)

> * Is there a simple way to protocol needed MacPorts packages?

Needed by/for what? You can list recursive dependencies, inside the
port you can run trace mode to make sure that no other files are used,
listing active packages is possible (but note that you'll probably end
up with build dependencies as well if you are building from source
...)

Mojca

Re: Some glitches while porting Ola (openlighting.org) - autoreconf not found

[Mojca Miklavec]

On Sun, 13 Jan 2019 at 10:07, Christoph Kukulies wrote:
>
> I got it working (port install ola) finally by following the latest 
> suggestion in the port output (deactivate py27-protobuf)

Thanks for the logs. I added the missing conflict between
py27-protobuf and py27-protobuf3:
https://github.com/macports/macports-ports/pull/3415

> Looking forward to what else might be broken after this :-(
> At least port install ola went through now.

I'm glad that it worked. Let us know if anything else needs to be
fixed. I would suggest to ask the ola developers to change the
instructions, at least in the way that won't ask users to install the
ports that are not conflicting with the real dependencies.

Mojca

Re: port reclaim exclude build dependencies

[Mojca Miklavec]

On Tue, 22 Jan 2019 at 16:36, Jonathan Stickel wrote:
>
> > 2. You can exercise judgment in doing a 'port setrequested' for some
> > common dependency ports that you know you will always want (e.g.
> > autoconf, boost, ncurses, etc.) and avoid having to save no regularly.
>
> This takes work that could be automated. If there isn't interest, OK,
> I'll keep doing what I'm doing.

I'm aware that the number of developers with both the skill and time
to fix this is very limited, so I don't consider it some ultra high
priority, but I would also be in favour of "keeping track of build
dependencies". That is: if I installed port A on my computer and if A
installed autoconf (as a build dependency) as well as B as runtime
dependency, I would like to have the ability to keep autoconf
installed after running reclaim, in the same way as B is kept. Of
course this would have to be optional, so that it would be equally
easy to remove build dependencies as it would be keeping them.

(A particular port might have been fetched from the buildbot, or built
locally, and MacPorts could in theory treat those two cases
differently, so that it would only keep the build dependencies of
ports you'll likely need to build again. But that's already nitpicking
and probably not really needed.)

Debian tells you about dependencies you may remove immediately after
uninstalling a particular package.

Mojca

Re: port reclaim exclude build dependencies

[Mojca Miklavec]

On Sun, 27 Jan 2019 at 19:57, Rainer Müller wrote:
> On 27.01.19 19:42, Ryan Schmidt wrote:
> > On Jan 27, 2019, at 12:26, Rainer Müller wrote:
> >
> >> The main problem here would be that information about build dependencies
> >> is not stored in the registry. Only if we this information was kept on
> >> installation as a first step, we could then respect it during reclaim.
> >
> > Hmm, why is that a prerequisite? "port_cutleaves" manages to implement 
> > approximately this feature without that information in the registry. I 
> > assume it's getting the build dependencies from the current portfile. Can't 
> > "port reclaim" do the same?
>
> I have not checked in detail, but I think port_cutleaves gets everything
> from the ports tree.
>
> > And isn't that actually what we want? Who cares if an outdated
> installed port had a particular build dependency. What we care about is
> whether the current version has that build dependency. The goal is to
> prevent the uninstallation of build dependencies that are likely to be
> needed in the future; we don't care about build dependencies that were
> once required in the past.
>
> Mixing the information from the registry with the information from the
> ports tree seems like a bad idea. Once you start with that, it just gets
> more and more complicated.

Should we file a ticket for the base to (a) store that information and
(b) consider it in reclaim?

Mojca

Re: GCC

[Mojca Miklavec]

Dear Thomas,

On Sat, 2 Feb 2019 at 23:33, Thomas Bodlien wrote:
>
> I have installed gcc8 and now x86_64-apple-darwin18-gcc-8.2.0 is available.
> But where is the g++ Compiler?

It should be called "g++-mp-8", you can find it under
/opt/local/bin/g++-mp-8
or, more generally, with the help of
port contents gcc8
which tells you which files a particular port installed.

If you would like to call just "g++" in the future, you can use
sudo port select set mp-gcc8
See
port help select
port select --list gcc

Mojca

Re: suggestions

[Mojca Miklavec]

Dear Chilli,

Welcome to MacPorts.

On Wed, 20 Feb 2019 at 01:36, chilli.names...@gmail.com wrote:
>
> A little embarrassing, but I need some direction. I realize macports user 
> support does not really exactly support the port I need (ffmpeg),

We don't have any official user support :)
We have just a bunch of subscribers / volunteers who read mails, and a
bunch of people helping fix the ports, with quite a bit of an overlap
:)

> I am running snow leopard 10.6, and while I don't expect support to continue 
> forever

The support will continue as long as we have volunteer willing to fight :)
This is entirely unrelated to how long Apple will sell its DVDs, the
security patches are no longer available for many many many years
already.

> ffmpeg and a few other ports are critical to my scripts, and I broke ffmpeg, 
> and can't rev-upgrade. I went a long time without upgrading,

In the case of MacPorts I would say that too long of a time period
without upgrading might be bad. If anything, if you don't upgrade for
more than a year, you might not be able to upgrade at all since we may
not keep compatibility layer for upgrades for more than a year.
Generally it might go well, but there's some chance that it breaks
(the longer you wait, the more likely it is) and then you would need
to install from scratch or do some trickery. Also, if you upgrade on
regular basis, it might be easier to roll back the older versions,
report the problem immediately, and figure out how to fix it faster.

But yes, 10.6 is not the main focus, and not that many people are
running it, so there's a chance that you'll experience some issues
with individual upgrades, I just say that those issues might be easier
to fix than if you don't upgrade for two years.

> ffmpeg is still broken... the error should look familiar when I call ffmpeg, 
> I get
>
> dyld: Library not loaded: /opt/local/lib/libvpx.5.dylib
>  Referenced from: /opt/local/bin/ffmpeg
>  Reason: image not found
> Trace/BPT trap

This means that it's referencing an older version of the library which
was already upgraded.

> the rebuilds for ffmpeg fail with
>
> Error: Failed to fetch libsdl2: Building libsdl2 @2.0.9 on Mac OS X 10.6 
> requires the MacOSX10.7.sdk to be present in /Developer/SDKs/
>
>
> So my understanding, if correct, is a dependency of the next (or current) rev 
> of ffmpeg requires 10.7 SDK, which is never going to be present on my snow 
> leopard box.

There's no reason why it couldn't be. That is exactly what we did on
our buildbot slave and the package was built successfully:
http://packages.macports.org/libsdl2/
Is there any reason why you are not getting binary packages? Do you
have a libc++ build setup or do you use a different prefix? (Under
default setup you would have gotten this package automatically.)

Ryan even started working on a slightly more automated way to install
a different SDK, but for some reason this didn't end upstream yet:
https://github.com/ryandesign/macports-ports/commits/MacOSX.sdk
All you need to do is download the appropriate xcode version from
Apple, extract it and put the 10.7 SDK next to the other SDKs on your
machine.

I believe there's also xcode which ships 10.7 SDK that's compatible
with 10.6, but that one was behind a paywall. (Don't take my word for
it, and I would not suggest to install that one either.)

See also
https://trac.macports.org/ticket/52210
which is something we might want to push in our repository.

> I don't need the current build of ffmpeg. Last build that worked... was fine. 
> I don't know why I messed with it, but if I can get a working build, I'll 
> just freeze my system and stop upgrading the ports.

Ken and others are doing a marvellous job keeping the latest versions
of ports working.

Also, if you need to go back to an older state, you could just do a
git checkout of macports-ports and go back to a date where you think
the system was still working. And you could easily install all the old
packages from there. (MacPorts is not too happy to install older
versions of ports automatically, but you could always start from
scratch.)

> I don't want to waste anyone's time with my problems. I thought there might 
> be someone still running snow leopard and ffmpeg subscribed to the list.

Ken is running Tiger PPC :)
And he successfully built libsdl2.

> If not, I would be grateful for some direction or perhaps a better 
> understanding of just how deep my troubles run.

What you describe should be perfectly solvable.

One "sin" that the MacPorts project is doing is that we didn't yet
switch to a newer libc++ by default. Many ports would nowadays be
broken due to lack of support for C++11 on older systems. You can
remedy that with
https://trac.macports.org/wiki/LibcxxOnOlderSystems
but since it's not the default configuration, you cannot fetch binary packages.

With libc++ setup you can build a huge number of ports that you would
never get working on a stock 10.6 :)

> And probably direct co

Re: A general philosophical question about MacPorts

[Mojca Miklavec]

On Tue, 19 Feb 2019 at 14:13, S. L. Garwood via macports-users wrote:
>
> So my philosophical question is “Why MacPorts these days?”.

If your question is: "Why a package manager for Mac these days", just
a few numbers.

We don't have any good analytics data, but our competitor saw more
than 6 million installs (not counting those who opted out) of the most
popular package in the last year. This at least tells you that there
is interest in people using a native package manager. I know that our
traffic runs in many terrabytes, but I forgot even the sample numbers.

If you don't care about running your software natively, it's better to
switch to Linux and forget about the expensive hardware.

I would have left macOS if I didn't have a package manager available,
the computer would be next-to-useless.
Even if the software is not packaged (yet), it is orders of magnitude
easier to build it for Mac than without the package manager.

Mojca


Mojca

Re: A general philosophical question about MacPorts

[Mojca Miklavec]

On Wed, 20 Feb 2019 at 16:33, Bill Cole wrote:
>
> The departure of MacPorts from Mac OS Forge as it was
> being wound down was announced in
> https://lists.macports.org/pipermail/macports-dev/2016-August/033405.html

While I wouldn't mind if Apple continued to provide hardware building
capacity, the move to GitHub probably saved (and boosted) the project.

Mojca

Re: Heads up: poppler won't build

[Mojca Miklavec]

Dear Dave,

On Mon, 25 Feb 2019 at 00:55, Dave Horsfall wrote:
>
> Sierra 10.12.6 + latest security updates, MacPorts 2.5.4.
>
> Doing my regular Monday "port upgrade outdated", and...
>
>  --->  Computing dependencies for poppler
>  --->  Configuring poppler
>  Error: poppler cannot be built while another version of poppler is 
> active.
>  Error: Please forcibly deactivate the existing copy of poppler, e.g. by 
> running:
>  Error:
>  Error: sudo port -f deactivate poppler
>  Error:
>  Error: Then try again.
>  Error: Failed to configure poppler: poppler is active

Yes, I would count it as a bug. Primarily as a bug in poppler build
system, but as a consequence also a bug on our side. I don't know what
precisely happened, but I assume that poppler picks its own installed
headers from the previous version from $prefix and then fails to
build.

This message tells you what precisely to do to work around the issue:
sudo port -f dectivate poppler
sudo port install poppler

We usually do something like deactivate hack
https://trac.macports.org/wiki/PortfileRecipes#deactivatehack
but I don't know why it wasn't done this way (maybe it doesn't work,
maybe there were other reasons ...).

By far the best way would be to fix the poppler build system. I
believe that using the correct order of include flags should work to
find the local version of header files first.

> Note that I do not file bug reports unless I am 100% sure that it is
> indeed a bug, and not my own silly fault; I've had this policy for 40+
> years.
>
> So,
>
>  ozzie:~ dave$ sudo port -f deactivate poppler
>  --->  Unable to deactivate poppler @0.72.0_0, the following ports depend 
> on it:
>  --->   gimp2 @2.10.8_3+python27
>  Warning: Deactivate forced.  Proceeding despite dependencies.
>  --->  Deactivating poppler @0.72.0_0
>  --->  Cleaning poppler

This is expected. You probably wouldn't have poppler installed if it
wasn't for another piece of software that pulled it in. The force
deactivate was there precisely for that reason: you would temporarily
leave some port broken until you reinstall that package.

> Hmmm...  Proceed regardless:
>
>  ozzie:~ dave$ sudo port -p upgrade outdated
>  Nothing to upgrade.
>
> (Yes, I'm in the habit of using "-p" to get past broken ports.)
>
> Well, I don't (yet) use GIMP, and I have no idea what "poppler" is, so I
> guess I can live with it.

Just run "sudo port install poppler".
(That's not a question for you, but doesn't gimp need to be rebuilt
after poppler update?)

Mojca

Re: Install macports again after uninstalling homebrew

[Mojca Miklavec]

On Thu, 28 Feb 2019 at 19:37, Ulrich Wienands wrote:
>
> I’d check .bashrc or .profile to see if Homebrew somehow messed with your 
> path.
>
> For me, port points to /opt/local/bin/port. Does that exist?

In fact this was most likely just missing PATH setup.

Even if you don't have PATH setup in correct way, you should be able
to run "/opt/local/bin/port " directly, or simply edit
~/.bash_profile or wherever your PATH is initialized.

Mojca

Re: Perl/Tk

[Mojca Miklavec]

Dear Dave,

We have ports for:
- p5-tk
- p5-tkk
- p5-tcl-ptk

Sadly most of the comments about Perl/Tk are still true, the situation
hasn't really changed a bit since the last century (not sure if a
smiley or sad face belongs here), most likely because the interest for
Perl faded away in favour of Ruby, Python etc., or at least there were
no serious developers working on Macs.

t5-tk in fact still doesn't work without X11. Yes, wish does, but
Perl/Tk probably copied the original Tk code and modified it for its
own use, without ever following up when Tcl/Tk was ported to Quartz.

Some of the other solutions work with Quartz, but I forgot how things
go exactly. Maybe tkk is a super lightweight wrapper around Tcl/Tk,
requiring a completely different syntax than Perl/Tk, while ptk uses
some hacks to try to support the same syntax as Perl/Tk, and then
allowing the rendering in Quartz. But don't take my word for it.

Mojca

Re: Perl/Tk

[Mojca Miklavec]

On Thu, 7 Mar 2019 at 16:08, Christopher Chavez wrote:
>
> To clarify, there is no `p5-tkk` port, it's probably a misspelling.

Sorry, yes, that was a typo. It was supposed to be tkx rather than tkk.

Mojca

Re: Making `port mpgk' create smaller packages

[Mojca Miklavec]

Dear Werner,

On Sun, 10 Mar 2019 at 08:24, Werner LEMBERG wrote:
>
> trying
>
>   port mpkg lilypond-devel
>
> creates a 1.5GByte bundle, which is far too large to be used for
> distribution.  Is there a possibility to reduce the number of packages
> that gets bundled?
>
> As far as I can see, the main problem is that build and run
> dependencies are intermixed in Portfiles: If `foo' is necessary for
> building and running, it gets only listed in `depends_lib'.

That's a clear bug in a Portfile specification (rather than in MacPorts).

Any dependency that's not required for running should be
depends_build[-append] and any dependency that's not required for
building the port should be depends_run[-append]. There's also
depends_test, depends_fetch, ... (maybe more).

> Is it possible to provide a finer granularity?  For example,
> `lilypond-devel' needs `texlive' for building only but not for
> running.

In that case just move it from depends_lib[-append] to
depends_build[-append] (in a PR, probably)

> Or may `port
> mpkg' gets a new command line option to specify a list of packages
> that should be omitted (together with its dependencies).

I'm pretty sure there is a lot of room for improvement of port mpkg.
Maybe open a ticket for base in our Trac? (Improvements to mpkg might
potentially even be suitable for GSOC projects.)

Mojca

Re: Anyone using cmake for iOS development?

[Mojca Miklavec]

On Wed, 13 Mar 2019 at 15:57, René J.V. Bertin wrote:
>
> Hi,
>
> Is anyone using cmake for the development of applications for Apple's 
> non-desktop OS flavours (iOS, WatchOS etc)?
>
> Reason for asking is that CMake doesn't set the Info.plist flags necessary 
> for high-DPI support because it uses the same template plist for all 
> application bundles regardless of the targeted Apple OS.
>
> A priori the only thing required for that support is to set the 
> NSPrincipalClass property to NSApplication and that would be easy to add to 
> the plist template, as a MacPorts patch. The question is whether a variant 
> should be provided to disable that patch.

Can you please ask upstream and link the answer? Ideally open a bug
report with a minimal example?

I don't think that variants are a good idea (even if we make a patch,
it's better to avoid variants). If it's needed, it should really be
upstreamed. Imagine users with MacPorts happily testing their apps,
figuring out they work ok, and then this would no longer work on
someone else's PC, without anyone from the developers noticing, or
taking them hours, days etc. to figure out why it suddenly broke.

Mojca

Re: How can I install a MacPorts port that is linked with an earlier MacOS release?

[Mojca Miklavec]

Dear Michael,

On Wed, 13 Mar 2019 at 16:03, Michael A. Leonetti wrote:
>
> How an I install the port packages that support El Capitan (or any specific
> MacOS version) and above to link against?

By far the least painful way would be to install El Capitan inside a
VM and build there.

The other option would be to contribute patches to provide better
support for doing these kind of builds (which would in fact be
useful). You can ask MacPorts to do universal builds, you can ask it
to link against a different SDK etc., but it mostly lacks better
support for building for an older OS. When I tried to do some
bootstrapping for 10.5 on 10.6 one of the biggest issue was that the
ports sometimes use code that is only executed on a particular OS
version. Even if you set the environmental variables to link against
an older SDK, define the variable for the target OS etc. ... you might
still be bitten by those if-else parts of the code that check what
your current OS is, not the OS you want to target.

Personally I would welcome patches to fix that, but that would
probably take quite some effort.

Mojca

Re: MariaDB upgrade to 10.3?

[Mojca Miklavec]

Dear Bill,

On Mon, 18 Mar 2019 at 17:35, Bill Christensen
 wrote:
>
> If I had the time, I'd be happy to take on the maintainer position on this 
> and several other ports.  Unfortunately, I'm currently working a contract job 
> with 50 hr weeks (with 1 hr commute) plus running my servers in my 'spare' 
> time.  I'd probably make a lousy maintainer at this point.

Even if you are not officially a maintainer, it would already be of
enormous help if you would manage to upgrade the port, or do any other
improvement to it, and submit a pull request.

Mojca

Re: Using Macports' gcc8 to build C programs and libraries

[Mojca Miklavec]

On Mon, 1 Apr 2019 at 12:18, Sean Lake wrote:
>
> As far as I know I have command line tools installed - I'm not even
> sure how I could get MacPorts installed without them. Adding
> "-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include"
> to CFLAGS appears to have fixed the problem

Does that mean that clang automatically searches the relevant path and gcc not?
Does that mean that we would need to somehow find a fix for our gcc ports?

It's true that gcc is a second-class citizen on macs nowadays. It
makes perfect sense to make sure that the project is buildable with
gcc, in particular if you spend a lot of time optimizing flags, but it
would also be nice to test compilations with clang, just in case.

(You probably know this, but note that if you plan to distribute
binaries for your software and you compile it with gcc, the users
might need to have macports installed as well, since the binaries will
depend on libstdc++ which is not present on stock macOS. Unless you
statically link with libstdc++ which is slightly less trivial than on
Linux.)

Mojca

Re: Mirror unpacks distfile before sending

[Mojca Miklavec]

On Thu, 4 Apr 2019 at 06:34,  wrote:
>
> it's wierd. i'm seeing the same Content-Encoding header
> but curl doesn't un-gzip the download for me. neither
> /usr/bin/curl (7.43.0) nor /opt/local/bin/curl (7.64.1).
> neither does wget. i wonder what the difference is.

Probably not relevant for this, but some time ago I also had the same
issue of auto-extracting tarballs; I thought it was the firewall (some
content / antivirus checking software there) as I only had this
problem in my office; everywhere else it worked as expected.

Mojca

Please welcome the four GSOC projects this year

[Mojca Miklavec]

Dear MacPorters,

I'm happy to announce that MacPorts will be participating at Google's
GSOC with four awesome projects this year.

(Those who followed the heavy traffic on the development mailing list
are probably already aware of the excessive amount of traffic we
received in March and April.)

The selected projects are listed here:
https://summerofcode.withgoogle.com/organizations/4814249782673408/

1.) Ahmad Satryaji Aulia: Phase Out Xcode Dependency
Mentored by: Marcus Calhoun-Lopez, Clemens Lang
A project touching the MacPorts base should remove the need to install
full Xcode.

2.) Arjun Salyan: Web App (with API) to Collect PortIndex, Build
History and Installation Statistics
Mentored by: Mojca Miklavec, Umesh Singla
A standalone Django app telling you everything about individual ports.

3.) Karan Sheth: Automating Packaging for Macports
Mentored by: Cyril Roelandt (upt author), Renee Otten
A python package to supersede cpan2port, pypi2port etc.

4.) Rajdeep Bharati: Macports Custom Views Plugin for Buildbot
Mentored by: Pierre Tardy, Povilas Kanapickas (both from buildbot),
Mojca Miklavec
Upgrading our build infrastructure to the latest version of buildbot
with new and better views and other improvements.

I would like to congratulate all the students for getting selected and
thank all the mentors, in particular the three external ones who
jumped in to help us deal with the much higher amount of good
proposals than in previous years. We could sadly not accept all the
projects that we would have wanted.

The next three weeks are devoted to the community bonding period when
active participation of student is expected (with mentors' help) to
learn more about the tools and community, improve the planning and
potentially revise the goals and deadlines if needed, and get up to
speed for the great summer coding experience.

Mojca

Re: OpenBLAS binary packages

[Mojca Miklavec]

On Wed, 15 May 2019 at 12:23, Artur Szostak  wrote:
>
> After our 4 years of experience preparing RPM and MacPorts package 
> repositories of our software we have seen that MacPorts packages take an 
> order of magnitude more time to build and cause significantly more problems 
> than RPMs. Mainly because there is a non-trivial probability that some port 
> in the dependency tree will start breaking, and there is no way to pin or 
> encode version ranges for the Portfile dependencies to prevent this.

On top of what Ryan replied ...

1.) Most linux distributions simply freeze all the software. If you
want something newer, you need a newer distribution. That's a lot
easier to test.

>From what I remember CentOS 6(?) doesn't even have proper support for
C++11 out of the box.

If you take a rolling release like Arch linux or Debian experimental
you are also highly likely to run into various issues; you would
usually run at least Debian testing or even stable, and simply live
with ancient software that never gets updated except for security
patches. If you freeze the software, you can do a lot more testing. We
could also freeze all software with every major OS release, but that
would make the distribution much less attractive (not to say mostly
useless). While it would be useful to have a model similar to Debian
with some experimental and stable branches of MacPorts, we simply
don't have sufficient workforce to do that.

If we now update libpng, we should theoretically test (build from
source and run the test suite) every single package that depends on
libpng, and we don't even have CPU capacities to do such kind of
testing.

2.) We have too many abandoned packages and lots of broken software,
so it's nearly impossible to differentiate between something that's
not used by anyone and should have been axed years ago, and software
that's used by many and has only recently been broken. Part of this
will hopefully be easier to monitor after this summer with one of the
GSOC projects.

Mojca

Re: [GSoC 2019] Web App Project Update

[Mojca Miklavec]

Dear Arjun,

Thanks a lot for sending out the report.

Dear MacPorts users,

I would warmly welcome everyone to check what has been done so far,
provide feedback, but in particular volunteer to run
sudo port install mpstats-gsoc
to help us get more statistics ready by the time Arjun starts working
on that part (about two weeks from now; it would be really cool to
have more than one month worth of statistics from a sufficient number
of users well before the GSOC ends to be able to know whether we'll be
heading in the right direction).

The detailed statistics is not there yet, but you can probably guess
whether your statistics submission has been successful by checking the
following page:
https://frozen-falls-98471.herokuapp.com/statistics/
right before and after you install the port. You can also manually run
/opt/local/libexec/mpstats-gsoc submit
or
/opt/local/libexec/mpstats-gsoc show
if you just want to see what gets submitted.

Thank you very much,
Mojca

(I CC-ed macports-users to get some more visibility and hopefully get
more volunteers to submit their statistics, but any further discussion
probably only makes sense on macports-dev. Even though ... one of the
student contributors complained that we didn't post anything about
GSOC to the macports-announce ...)

On Fri, 7 Jun 2019 at 22:21, Arjun Salyan wrote:
>
> Hi,
>
> I am working on the web app to collect build and installation statistics and 
> show information about ports, maintainers etc.
>
> Repository: https://github.com/macports/macports-webapp
>
> We have deployed a demo on Heroku: https://frozen-falls-98471.herokuapp.com . 
> Any feedback and feature requests on this are very welcome.
>
> Currently we are working on build history and port information. Port 
> information is fetched from Portindex after converting it to JSON using 
> portindex2json.tcl and build history is fetched from JSON API of buildbot, it 
> is planned to be kept updated using HttPStatusPush reporter on Buildbot.
>
> Keeping the port informtation up-to-date is a challenge given the large size 
> of the portindex. We are looking at two aspects:
> - Incremental updates using difference between two port indices [1]
> - Full updates to completely sync the database with latest portindex
>
> Full updates are dead slow on an Amazon RDS free tier instance, and probably 
> it won't be feasible on any externally hosted database. On a local database, 
> full updates take more than 5 minutes.
>
> For installation statistics, we have setup a temporary port (mpstats-gsoc) 
> which would submit stats to the demo app. This is important becuase it would 
> give us enough data to write proper views and do testing. Please consider 
> installing mpstats-gsoc.
>
> We are looking to deploy the app on MacPorts' server and host it on a 
> macports.org subdomain using Docker.
>
> Thank you for your time, any suggestions would be very helpful.
>
> [1] https://github.com/macports/macports-base/pull/121
>
> Arjun

Re: [GSoC 2019] Web App Project Update

[Mojca Miklavec]

V sob., 8. jun. 2019 17:32 je oseba Christopher Chavez napisala:

>
> I would like to participate in sending usage statistics. However I
> currently have made out-of-tree modifications to a few ports for testing
> patches and prerelease versions, using versions/revisions greater than
> in the official tree so that I can easily switch between the official
> port and my modified port using `port activate`.
>
> Is there any issue posed by reporting "invalid" port info? I would guess
> that the main goal of the statistics is likely for analyzing the more
> popular "official" ports than for worrying about unpopular or "invalid"
> ones, but want to make sure first.
>

No, there is absolutely no problem if you submit "invalid" port info.
Anyone contributing patches will have different ports installed at some
point or even all the time.

Thanks a lot in advance,

Mojca

Re: [GSoC 2019] Web App Project Update

[Mojca Miklavec]

Hi,

This is just to say a huge thank you to everyone who volunteered to
contribute. In just a week we collected statistics from nearly half as
many machines compared to our existing (semi-official) site. At the
moment the site is only showing OS version distribution, but we expect
other data to be shown soon (ideally in about two weeks).

Thank you very much,
Mojca

(And of course feel free to provide feedback about the rest of the site.)

On Sat, 8 Jun 2019 at 14:52, Mojca Miklavec wrote:
>
> Dear MacPorts users,
>
> I would warmly welcome everyone to check what has been done so far,
> provide feedback, but in particular volunteer to run
> sudo port install mpstats-gsoc
> to help us get more statistics ready by the time Arjun starts working
> on that part (about two weeks from now; it would be really cool to
> have more than one month worth of statistics from a sufficient number
> of users well before the GSOC ends to be able to know whether we'll be
> heading in the right direction).
>
> The detailed statistics is not there yet, but you can probably guess
> whether your statistics submission has been successful by checking the
> following page:
> https://frozen-falls-98471.herokuapp.com/statistics/
> right before and after you install the port. You can also manually run
> /opt/local/libexec/mpstats-gsoc submit
> or
> /opt/local/libexec/mpstats-gsoc show
> if you just want to see what gets submitted.
>
> Thank you very much,
> Mojca
>
> (I CC-ed macports-users to get some more visibility and hopefully get
> more volunteers to submit their statistics, but any further discussion
> probably only makes sense on macports-dev. Even though ... one of the
> student contributors complained that we didn't post anything about
> GSOC to the macports-announce ...)
>
> On Fri, 7 Jun 2019 at 22:21, Arjun Salyan wrote:
> >
> > Hi,
> >
> > I am working on the web app to collect build and installation statistics 
> > and show information about ports, maintainers etc.
> >
> > Repository: https://github.com/macports/macports-webapp
> >
> > We have deployed a demo on Heroku: https://frozen-falls-98471.herokuapp.com 
> > . Any feedback and feature requests on this are very welcome.
> >
> > Currently we are working on build history and port information. Port 
> > information is fetched from Portindex after converting it to JSON using 
> > portindex2json.tcl and build history is fetched from JSON API of buildbot, 
> > it is planned to be kept updated using HttPStatusPush reporter on Buildbot.
> >
> > Keeping the port informtation up-to-date is a challenge given the large 
> > size of the portindex. We are looking at two aspects:
> > - Incremental updates using difference between two port indices [1]
> > - Full updates to completely sync the database with latest portindex
> >
> > Full updates are dead slow on an Amazon RDS free tier instance, and 
> > probably it won't be feasible on any externally hosted database. On a local 
> > database, full updates take more than 5 minutes.
> >
> > For installation statistics, we have setup a temporary port (mpstats-gsoc) 
> > which would submit stats to the demo app. This is important becuase it 
> > would give us enough data to write proper views and do testing. Please 
> > consider installing mpstats-gsoc.
> >
> > We are looking to deploy the app on MacPorts' server and host it on a 
> > macports.org subdomain using Docker.
> >
> > Thank you for your time, any suggestions would be very helpful.
> >
> > [1] https://github.com/macports/macports-base/pull/121
> >
> > Arjun

Re: texlive no longer finds (some of) its style files?

[Mojca Miklavec]

On Mon, 8 Jul 2019 at 14:27, Ryan Schmidt wrote:
>
> I don't think MacPorts will uninstall a port unless you tell it to (directly 
> by name@version_revision+variants, or using a pseudoport (like "inactive" or 
> "leaves"), or using port(1)'s "-u" flag).
>
> What could happen, though, is that MacPorts might deactivate a port if 
> another port has replaced its functionality. For example, if a port 
> texlive-old no longer exists but a port texlive-new now provides the same 
> files that texlive-old used to, then when you install or upgrade texlive-new, 
> it will automatically deactivate texlive-old. The result should be that the 
> files you want are still there. If somehow that didn't end up being the case, 
> you could reactivate texlive-old.
>
> If you selectively update ports, you can run into situations where some of a 
> port's dependencies have been updated but others haven't. This can result in 
> a variety of problems, possibly including the one you mentioned. For this 
> reason, we recommend using "sudo port upgrade outdated" to upgrade all of the 
> outdated ports at once, and not selectively upgrading ports.

With TeX Live one can definitely run into situations of a package
being in one collection, then moved to another collection next year.
And your document suddenly no longer compiles despite having the same
packages installed (but now some files missing), and the only safe way
around it is to install the full texlive.

Mojca

MacPorts meeting 12.-16. October 2019

[Mojca Miklavec]

Dear MacPorts users & developers,

We would like to organise an extended MacPorts hacking weekend in
Trieste, Italy (or eventually Slovenia) from Saturday 12th of October
to Wednesday, the 16th of October (arrivals on Friday evening or
Saturday morning, departures on Wednesday afternoon).

We will fix the place & price for food & accommodation as soon as
possible, but we'll try to keep the costs down.

I would like to ask everyone interested in participating to reply
(either on the list or off-list), so that we have a rough estimate
about the number of participants and can plan accordingly.

We would explicitly like to invite our GSOC students to join us for
the event, I'll send separate instructions to you.

We would like to use the opportunity to wrap-up the summer experience,
to brainstorm about the future, deploy and test the missing bits and
pieces, come up with new ideas, and simply enjoy hacking together and
spending some nice evenings together. We would probably be covering
various topics (our CI infrastructure would definitely be on the
menu).

Mojca

PS: Those who confirmed attendance so far: me & Aljaž as organizers,
Umesh Singla, Clemens Lang, Jackson Isaac (just for the weekend).

[GSOC] Request for feedback for the new web application

[Mojca Miklavec]

Dear MacPorts users and developers,

As most of you probably know already, we have 4 GSOC projects this
year, one of them for a web application.

The application written by Arjun made a decent progress so far and is
available under a temporary URL:
http://ec2-52-34-234-111.us-west-2.compute.amazonaws.com/

We would be extremely happy for any feedback you might have, either
here or under
https://github.com/macports/macports-webapp/issues
so that we can make the application better and more useful while Arjun
is still working on it full time.

You are also invited to opt-in to statistics submission by running
sudo port install mpstats-gsoc

Samples of statistics collected in the last two months can be seen
here, for example:
http://ec2-52-34-234-111.us-west-2.compute.amazonaws.com/statistics/
http://ec2-52-34-234-111.us-west-2.compute.amazonaws.com/port/wget/?tab=stats
Thank you very much to everyone who is participating.

Thank you very much,
Mojca

Re: Installing port `findutils` does not seem to create any binaries

[Mojca Miklavec]

On Sun, 28 Jul 2019 at 07:28, Dmitri Zaitsev wrote:
>
> I had successfully installed the port `findutils`:
>
> ➜  ~ sudo port installed findutils
> Password:
> The following ports are currently installed:
>   findutils @4.6.0_0 (active)
> ➜  ~
>
> Which should install some standard utils:
>
> ➜  ~ port search findutils
> findutils @4.6.0 (sysutils)
> findutils contains GNU find, xargs, and locate
> ➜  ~
>
> However, none of these files had been created under /opt/local/bin
>
> Any advice about what happens here?

You can use "port contents" to find out what files the port provides.
In this case you get the following files (among others):

> port contents findutils
Port findutils contains:
  /opt/local/bin/gfind
  /opt/local/bin/glocate
  /opt/local/bin/gupdatedb
  /opt/local/bin/gxargs
  /opt/local/libexec/gbigram
  /opt/local/libexec/gcode
  /opt/local/libexec/gfrcode
  /opt/local/libexec/gnubin/find
  /opt/local/libexec/gnubin/locate
  /opt/local/libexec/gnubin/updatedb
  /opt/local/libexec/gnubin/xargs
  ...

Mojca

Re: [GSOC] Request for feedback for the new web application

[Mojca Miklavec]

Dear Dmitri,

On Sun, 28 Jul 2019 at 17:22, Dmitri Zaitsev wrote:
>
> Feedback posted here:
> https://github.com/macports/macports-webapp/issues/51

That's enough suggestions that instead of spending a week addressing
them, we should probably let Arjun spend a week writing developer
documentation, then organise a quick one-hour hackathon with some
volunteer developers, each trying to fix one or two reported issues,
and provide feedback about code readability and the quality of
developer documentation :) :) :)

Thank you very much,
Mojca

(That wasn't an entirely non-serious suggestion :)

> On Sun, Jul 28, 2019 at 4:24 AM Mojca Miklavec wrote:
>>
>> Dear MacPorts users and developers,
>>
>> As most of you probably know already, we have 4 GSOC projects this
>> year, one of them for a web application.
>>
>> The application written by Arjun made a decent progress so far and is
>> available under a temporary URL:
>> http://ec2-52-34-234-111.us-west-2.compute.amazonaws.com/
>>
>> We would be extremely happy for any feedback you might have

Re: Why is Julia so outdated?

[Mojca Miklavec]

On Thu, 1 Aug 2019 at 12:07, Thomas Ruedas wrote:
>
> As the Julia programming language has recently received some attention,
> I thought of giving it a try and wanted to install it from Macports.
> However, the Macports version (0.6.2) is outdated by some 2 years; the
> current version according to the Julia homepage is v.1.1.1, with newer
> releases apparently already on the horizon. Is there a reason why Julia
> is not being kept up to date?

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

Mojca

Re: output like "port list all" over the web?

[Mojca Miklavec]

On Mon, 5 Aug 2019 at 02:32, Richard L. Hamilton wrote:
>
> That got me to wondering if there's a way to get the equivalent of "port list 
> all", all on one page, over the web; for someone that might not want to
> install MacPorts, but wanted to see what its current versions of all its 
> packages were (and perhaps even generate feedback on availability of newer
> packages), that might be useful.
>
> I can get that on https://www.macports.org/ports.php?by=all but that's not 
> all on one page, and it has a lot of other stuff that makes it more difficult
> to consume as machine-readable.

See
https://trac.macports.org/wiki/SummerOfCode/2019#webapp
with the temporary deployment at
http://ec2-52-34-234-111.us-west-2.compute.amazonaws.com/
and API specification being written & discussed at
https://github.com/macports/macports-webapp/pull/45/files
if you want to do something with machine-readable format.

The API with port names should already work, but the URL might change,
so I would not yet use it for production.

But there's

rsync://rsync.macports.org/macports/trunk/dports/PortIndex_darwin_18_i386/PortIndex.json
if you want more instantanous information.
(There is a high probability that there's also some http(s) equivalent
of the rsync link, I'm just not sure where.)

Macports also offers something like "port livecheck "
which you could feed with "port livecheck all" and would tell you
which ports are likely outdated. But lots of those checks are broken
and the command takes "forever" to run. We are working on deploying a
job that would run on regular basis, check for potential updates and
provide reports. That's just not done yet.

I would say that at the moment one of the best sources of information
about outdated OpenSource software might be https://repology.org/

Mojca

PS: I'm not using any other updater. The number of apps I have on the
mac outside of MacPorts is relatively limited, and many of them update
automatically. I just never bothered enough about keeping them up to
date to use an external service for it.

Re: I'm already using Homebrew for a couple of things, Is it problematic to use Homebrew and MacPorts side by side?

[Mojca Miklavec]

Dear Gerben,

On Sat, 10 Aug 2019 at 00:44, Gerben Wierda wrote:
>
> See subject.

If you must do it, install HomeBrew to a location other than
/usr/local, make sure that you don't have MacPorts in PATH when
building HB packages from source (not sure if that's still a thing,
they are moving to binary-only), and ideally don't have HB in path
when building for MacPorts, even though MacPorts should usually be
immune to that (unless you have HB in /usr/local, in which case you
are "screwed by definition" and should not expect anything to work
correctly; 
https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-package-managers/).

Mojca

PS: on MacPorts TeX Live works at least all the way down to 10.5 PPC
;), while HB fetches the few gigabytes from MacTeX page which strictly
only supports the last three OSes. That's a pretty good approximation
of different approaches both projects are taking.
https://ports.macports.org/port/texlive-bin

Re: To root or not to root?

[Mojca Miklavec]

Dear Gerben,

We have a FAQ entry on that, I just couldn't find it right now.

On Mon, 12 Aug 2019 at 22:40, Gerben Wierda wrote:
>
> But I’m wondering if I should move back to running everything as ordinary 
> user.

No.

What if one of the ports has "rm -rf $HOME" inside the Makefile?
And what if you actually need to install some stuff as root (like
installing a service to run your server for X)?

> Are there disadvantages to running to port commands as root?

No, but there are disadvantages to running it as an ordinary user.
You can run plenty of commands without sudo (port search, port info,
port list, port livecheck, ...)
[In theory also stuff like "port configure" or build, even though you
are then exposed to the same security risk if you build as regular
user and it doesn't help you either as you won't be able to install
such port without sudo permissions anyway.]

> If I want to revert, what should I chown to that user? How should ownership 
> in /opt be?

root:admin

If you want to install as ordinary user, you would probably want to
put the package manager somewhere inside your HOME dir, and you'll
have to compile everything from source. (I'm actually not sure what
happens if you try to install as regular user under default prefix,
but I suspect you need to install MacPorts from source and explicitly
say that, and then binary packages also get disabled, but please don't
hold my word for that.)

Some users posted recipes to avoid having to type the password for the
"port" command.

Mojca

Re: What am I forgetting?

[Mojca Miklavec]

On Tue, 13 Aug 2019 at 01:24, Gerben Wierda  wrote:
>
> I have my own cloud git directory tree
> I cd to $thattree/net/unbound
> I edit the Portfile (startupitem), set revision to 1 (there was no revision)
> I run sudo port install unbound
> It is not built and installed as nothing has changed (but there has)
>
> What am I forgetting?

Did you add your local git checkout to configuration as your local
repository with higher preference?
https://guide.macports.org/chunked/development.local-repositories.html
Check this with
port dir unbound
If not, "sudo port install" or "sudo port upgrade" (without port name)
or "sudo port install subport=unbound" should take the port from the
current dir, but "sudo port install unbound" will probably take the
one that's configured globally and returned by "port dir unbound".

Mojca

Re: What am I forgetting?

[Mojca Miklavec]

On Tue, 13 Aug 2019 at 10:25, Gerben Wierda  wrote:
>
> I have my own cloud git directory tree
> I cd to $thattree/net/unbound
> I edit the Portfile (startupitem), set revision to 1 (there was no revision)
> I run sudo port install unbound
> It is not built and installed as nothing has changed (but there has)
>
> What am I forgetting?
>
>
> Did you add your local git checkout to configuration as your local
> repository with higher preference?
>https://guide.macports.org/chunked/development.local-repositories.html
> Check this with
>port dir unbound
>
>
> I did edit sources.conf. It contains:
>
> file:///Users/sysbh/MacPortsDev
> rsync://rsync.macports.org/macports/release/tarballs/ports.tar [default]
>
> But whatever is in there, port dir unbound gets met the standard repository.
>
> Albus:nsd sysbh$ port dir unbound
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/unbound
>
> So, als with
>
> file:///Users/sysbh/MacPortsDev/macports-port
> rsync://rsync.macports.org/macports/release/tarballs/ports.tar [default]

Later in the mail you reference "macports-port" with "macports-ports"
instead. Which one is it?
Also, you need to run "portindex" inside of macports-ports. Just in
case that you didn't do it already.

Mojca

Re: harfbuzz - strange compiler issues with gcc on 10.5

[Mojca Miklavec]

On Wed, 14 Aug 2019 at 15:05, Ryan Schmidt wrote:
> On Aug 14, 2019, at 02:14, Riccardo Mottola wrote:
>
> > I tried building with clang-3.7 but it doesn't work, because the port wants 
> > then to issue -stdlib=macports-libstdc++, which clang 3.7 does not 
> > understand.
>
> We didn't backport that feature to clang-3.7? I wonder why we didn't.

At that time the patch took forever to merge even for the latest
version because everyone was afraid of the consequences or breakages,
and Jeremy did not provide feedback for a very long time.

At the end it was more like "it cannot do much harm if we only include
this in the experimental version", and from that point on we kept
adding it to all newer versions, and I don't remember any issues.

I assume there should be no harm in backporting it to older versions.

Mojca

Re: libuv fails to build on 10.8.5

[Mojca Miklavec]

I'm away from computer, but on anything older than 10.9 you need to either
compile macports from source and link against a newer curl (bootstrapping)
or download manually and put files to correct location, or fetch files from
the macports mirror which still offers http.

Maybe port fetch could support a special flag to use alternative download
method.

Mojca

V sob., 17. avg. 2019 13:50 je oseba Dmitri Zaitsev 
napisala:

> Maybe I should add that this issue is not due to my system's curl and git
> clients,
> both are up-to-date and work fine without the issues mentioned there.
>
> Also I can easily access the same URL and download the files manually.
>
> The issue seems to be only with MacPorts apparently not using my newer
> clients.
>
>
> On Saturday, August 17, 2019, Dmitri Zaitsev  wrote:
>
>> Hi Werner,
>>
>> Many thanks!
>>
>> However, it says:
>> > This is an extremely minimal, bare bootstrap of curl, and git, and
>> little else, specifically targeted at OSX 10.7.5.
>>
>> I am on 10.8.5.
>>
>>
>> On Saturday, August 17, 2019, Werner LEMBERG  wrote:
>>
>>>
>>> > I do appreciate your time and fully understand that this is not your
>>> > concern but would be still thankful if anyone could advice on how to
>>> > configure MacPorts to use the recent ssl.
>>>
>>> Try this for bootstrapping:
>>>
>>>   https://try.gitea.io/donbright/lm
>>>
>>>
>>> Werner
>>>
>>
>>
>> --
>> Dmitri Zaitsev
>> School of Mathematics
>> Trinity College Dublin
>>
>> WWW:  http://www.maths.tcd.ie/~zaitsev/
>>
>>
>
> --
> Dmitri Zaitsev
> School of Mathematics
> Trinity College Dublin
>
> WWW:  http://www.maths.tcd.ie/~zaitsev/
>
>

Re: New MacPorts ports database site

[Mojca Miklavec]

Dear Chris,

On Mon, 19 Aug 2019 at 11:52, Chris Jones wrote:
>
> Looks great. One question though, how are the port dependencies
> determined exactly?

At the moment they are sadly only taken from a single OS, but it
should be the latest one.

The source of information is here:

http://nue.de.rsync.macports.org/macports/release/ports/PortIndex_darwin_18_i386/PortIndex.json

> I ask as the site does not seem to happen ports
> where the deps are OS dependent. For instance
>
> 
>
> lists clang-8.0 as a build dep,  but this is only correct on < macOS 10.13.

I'm not behind my mac now, but what does you portindex entry say for
root6 (it's just a slightly more compressed format than the one linked
above). The above linked file lists
["path:bin/cmake:cmake","port:gcc9","port:pkgconfig","port:clang-8.0"]

Now, I'm not sure what OS version is running on the machine that is
generating PortIndex (Ryan might be able to tell that). It could be
that there is a flaw in the code that generates portindex for a
different OS version.


On an "unrelated note": I did think of potential issues with ports
behaving in completely different ways on different OS versions, but it
seemed to me that it was way more important to implement one simple
and stable solution now than end up with way too complicated design
that would never even be finished in the scope of the summer and
potentially never deployed.

We can still think of how we could improve the application in the
future to take different OS versions into account, I just felt that
this was somewhat non-trivial to do right, and a disproportional
effort compared to the benefits it would bring. We also lack
information about dependencies for individual variants, which would be
another super useful information to have, but it's missing from
portindex at the moment, so it's also less trivial to add it.

Mojca

> On 19/08/2019 5:17 am, Joshua Root wrote:
> > MacPorts' new ports database is live at .
> > Please consider installing the "mpstats" port to enable submission of
> > anonymous information about your system and installed ports for
> > statistical purposes.
> >
> > The information collected is currently:
> > * MacPorts version
> > * OS name and version
> > * CPU architecture
> > * Selected C++ standard library
> > * Xcode, command line tools, and GCC versions
> > * Name, version, selected variants, and requested status of each
> > installed port
> > * A UUID so we can tell whether submissions are from distinct users
> >
> > The site also shows which OS versions each port was successfully built
> > on, has links to open Trac tickets, and more.
> >
> > This new site is the result of much hard work by our GSoC student,
> > Arjun Salyan. We hope you find it useful.
> >
> > Josh
> > (on behalf of the MacPorts Port Managers)
> >

Re: New MacPorts ports database site

[Mojca Miklavec]

Dear Chris,

On Mon, 19 Aug 2019 at 13:15, Chris Jones wrote:
> On 19/08/2019 12:00 pm, Mojca Miklavec wrote:
> > On Mon, 19 Aug 2019 at 11:52, Chris Jones wrote:
> >>
> >> Looks great. One question though, how are the port dependencies
> >> determined exactly?
> >
> > At the moment they are sadly only taken from a single OS, but it
> > should be the latest one.
>
> If it where the lastest OS, 10.13+, then clang-8.0 should not be listed
> as a build dep.

I would change this into "if the portindex script was working
correctly". The idea is that the script should work correctly if you
specify the target OS version. If it doesn't we have a problem that
needs to be fixed.

> > The source of information is here:
> >  
> > http://nue.de.rsync.macports.org/macports/release/ports/PortIndex_darwin_18_i386/PortIndex.json
> >
> >> I ask as the site does not seem to happen ports
> >> where the deps are OS dependent. For instance
> >>
> >> <https://ports.macports.org/port/root6/?tab=summary>
> >>
> >> lists clang-8.0 as a build dep,  but this is only correct on < macOS 10.13.
> >
> > I'm not behind my mac now, but what does you portindex entry say for
> > root6 (it's just a slightly more compressed format than the one linked
> > above). The above linked file lists
> >  ["path:bin/cmake:cmake","port:gcc9","port:pkgconfig","port:clang-8.0"]
>
> I am not sure what you are suggesting I look at ?

See the section of

http://nue.de.rsync.macports.org/macports/release/ports/PortIndex_darwin_18_i386/PortIndex

which reads:

root6 1168
variants {debug native root7 qt4 veccore valgrind vc xrootd graphviz
fftw3 gsl fitsio odbc roofit tmva opengl python27 python35 python36
python37 davix xml sqlite3 mysql mariadb percona postgresql pythia
cocoa x11} depends_build {path:bin/cmake:cmake port:gcc9
port:pkgconfig port:clang-8.0} portdir science/root6 description {ROOT
is a data analysis framework from CERN} homepage https://root.cern.ch/
depends_run port:root_select epoch 0 platforms darwin name root6
depends_lib {path:lib/libgcc/libgcc_s.1.dylib:libgcc port:expat
port:gmp port:giflib port:jpeg port:libpng port:lzma port:pcre
port:tiff port:xz port:gl2ps port:lz4 port:vdt port:tbb port:git
path:lib/libopenblas.dylib:OpenBLAS path:lib/libssl.dylib:openssl
port:python37 port:py37-numpy port:py37-jupyter port:py37-gnureadline
port:py37-metakernel port:xrootd path:bin/dot:graphviz port:gsl
port:davix port:libxml2} long_description {The ROOT system provides a
set of frameworks with all the functionality needed to handle and
analyze large amounts of data in a very efficient way.} license
LGPL-2.1+ maintainers {{jonesc @cjones051073} {mojca @mojca}}
categories science version 6.18.00 revision 3

This is what users get by default.

This means that any users getting portindex from the server will have
wrong entries and might end up having to install clang first.

> port deps root6 (on macOS10.13) says
>
> Full Name: root6
> @6.18.00_3+cocoa+davix+graphviz+gsl+opengl+python37+roofit+tmva+xml+xrootd
> Build Dependencies:   cmake, gcc9, pkgconfig
> Library Dependencies: libgcc, expat, gmp, giflib, jpeg, libpng, lzma,
> pcre, tiff, xz, gl2ps, lz4, vdt, tbb, git, OpenBLAS, openssl, python37,
> py37-numpy,
>py37-jupyter, py37-gnureadline, py37-metakernel,
> xrootd, graphviz, gsl, davix, libxml2
> Runtime Dependencies: root_select
>
>
> This is for my local machine though, where I use a git checkout of the
> ports tree and thus portindex was generated locally.

I wanted to ask for the copy of your section of PortIndex which would
ideally be the same as the one above (but probably isn't).

We likely need to file a bug report for base (portindex).

Mojca


> > Now, I'm not sure what OS version is running on the machine that is
> > generating PortIndex (Ryan might be able to tell that). It could be
> > that there is a flaw in the code that generates portindex for a
> > different OS version.
> >
> >
> > On an "unrelated note": I did think of potential issues with ports
> > behaving in completely different ways on different OS versions, but it
> > seemed to me that it was way more important to implement one simple
> > and stable solution now than end up with way too complicated design
> > that would never even be finished in the scope of the summer and
> > potentially never deployed.
> >
> > We can still think of how we could improve the application in the
> > future to take different OS versions into account, I just felt that
> > this was somewhat non-trivial to do right, and a disproportional
> > effort

Re: Can't compile `lilypond-devel`

[Mojca Miklavec]

On Mon, 2 Sep 2019 at 15:18, Ken Cunningham wrote:
>
> It's correct base behavior. Base sees a port compiled against libstdc++ on a 
> system configured to use libc++, and knows this is most often bad, and needs 
> to be fixed. So it flags this as an error.
>
> If the portfile author investigates and works out that it's OK for this port 
> to do that (as it doesn't use with any other c++ libraries or provide any for 
> other ports to use) then that "error"  can be overridden by forcing the 
> configure.cxx_stdlib in the portfile, and base will stop flagging it.

I tend to disagree.

Shouldn't base be able to distinguish between the system libstdc++ and
the one from gcc shipped by MacPorts?
Why would the base want to rebuild ports that were built with gcc?

Also, assume that a port allows compilation with both MacPorts gcc, as
well as one of the newer clangs. In that case it's impossible to
hardcode the stdlib. It could also be that a particular port was built
with gcc based on user (who knows what he's doing) request. Rebuilding
those ports would be undesired.

Mojca

MacPorts Meeting 11th-16th October 2019

[Mojca Miklavec]

Dear MacPorters,

We are happy to announce the 3rd international MacPorts meeting in
Bohinj, Slovenia, from 11th to the 16th of October. (Meeting starts on
Friday 11th with the dinner and ends on Wednesday after lunch.)

Some basic information (to be completed):
https://trac.macports.org/wiki/Meetings/MacPortsMeeting2019
Registration form:
https://forms.gle/JbSLkykLSZRu7Q4b8

We'll announce the exact fee soon, but for early-bird registrants it
should hopefully not exceed 200 EUR for five days covering food &
accommodation.

We are really going inter-continental this year, with expected
developers from China, Indonesia and four people from India. After an
extremely successful GSOC summer almost all students and most mentors
are expected to be present.

The meeting is an excellent opportunity to meet fellow developers &
users, brainstorm together & hack together for a couple of days to
make the software and its ecosystem even better.

Bohinj is one of the nicest places in Slovenia, also really nice to
bring your family members (it would have been even better in the
middle of summer or winter, but then it would be overcrowded anyway
:). It's next to the lake, in the middle of the mountains and within a
national park, relatively easily reachable also with means of public
transportation (but we'll try to pick up as many participants as we
could).

If you have any questions, feel free to ask.

Mojca

Re: [portgroups] Python

[Mojca Miklavec]

On Fri, 13 Sep 2019 at 03:51, Bjarne D Mathiesen wrote:
>
> Richard L. Hamilton wrote:
> > Depending on the results, with some effort, it might be possible to drop 
> > some of the intermediate versions. But only if a later suitable (for 
> > everything dependent on it) version is possible on every supported OS. And 
> > it would mean bumping portfiles, and rebuilding everything depending on 
> > dropped versions.  It probably wouldn't be worth the bother, and given all 
> > the constraints, might only get rid of a few versions.
> >
>
> so we've got 2 issues here :
> - which pythonXY the pyXY-{name} support
>   and whether theese can be brought up to python37
> - whether any Portfile that demands a pythonXY that isn't python37
>   can be updated to depend on python37 instead
>
> We'll need some statistict / overview on this matter.
> I'll look into this.
>
> It's also a question about keeping the macports infrastructure up-to-date.
>
> I've eg somehow gotten libsvm installed, and it has :
> Variants:  [+]java, [+]python27, python34, [+]tools, universal
> as well as being seriously out-of-date:
> libsvm @3.20_2 -> Version 3.24, September 2019

This looks like an obvious example of a port that simply no-one
touched for years and should probably be easy to update, replace
python34 with python37 (as well as make that one default if it works
as expected).

In general updating from 2.7 to 3.7 is not always possible, in
particular we still don't have the port for wxWidgets (Phoenix), and
software needs to be rewritten to use that one as well.

I would say that we'll need to keep 2.7 around, but of course switch
to 3.7 as much as possible.

Personally I don't mind if we remove all traces of Python 2.4-2.6
which should be very easy. Almost nothing depends on that, it's just
there if someone would want to some extent still run the older python.

Removing any traces of 3.x up to 3.6 should be straightforward, but
requiring quite a bit of (tedious) work.

Mojca

PS: just removing the numbers from portgroup is not sufficient. All
ports that don't specify the default version need to be revbumped and
checked that they are compatible with python 3.7 at least, or at least
those should specify the default python version.

Re: Problems with MP 2.6.0 on Snow Leopard

[Mojca Miklavec]

On Mon, 23 Sep 2019 at 11:38, Rob Widdicombe wrote:
>
> Hi,
>
> Bear with me - I'm a musician, not a Unix expert, but I'm doing my best!
>
> I'm still resolutely running Snow Leopard and last night did a port 
> selfupdate to take me up to MP 2.6.0. So far so good.
>
> However, when I then tried to do a port rev-upgrade, the problems began.

Without looking at the individual logs yet ... as Ryan mentioned, we
would generally advice users of < 10.9 to wait a couple of more days
before doing the actual update.

https://lists.macports.org/pipermail/macports-users/2019-September/047381.html

This is something that we should probably write with some big warning
sign to both the homepage (download section) as well as under github
release.

Some pretty big fundamental changes were done for these old systems
and there were two options:
- put an extensive amount of effort and horsepower to run both
configurations in parallel for an extended period of time
- switch the default and cope with some issues for a limited period of
time, hoping that not too many users will be affected (too much)

Due to lack of manpower we went for the second option.

According to https://build.macports.org/waterfall?tag=10.6 the
buildbot workers were not even re-started yet, and I would expect a
couple of days (or weeks) for them to catch up. Ideally you would want
to wait at least until some basic binaries get built on the server. I
assume that your existing binaries still work?

Arjun: we should check in case the web app needs any adjustments. We
will probably no longer have the "legacy" workers.

Mojca

Re: Problems with MP 2.6.0 on Snow Leopard

[Mojca Miklavec]

On Mon, 23 Sep 2019 at 16:50, Joshua Root wrote:
>
> Hi Rob,
>
> Rob Widdicombe wrote:
> > I'm still resolutely running Snow Leopard and last night did a port 
> > selfupdate to take me up to MP 2.6.0. So far so good.
> >
> > However, when I then tried to do a port rev-upgrade, the problems began. It 
> > fails on the first step, upgrading gmp. Looking at the log files, it seems 
> > like it's expecting to find clang 8, and I have no idea why - I've never 
> > installed it and so, not surprisingly, it's not there.
> >
> > I'm using:
> >
> > Xcode 3.2
> > Component versions: DevToolsCore-1608.0; DevToolsSupport-1591.0
> > BuildVersion: 10D575
>
> It won't fix this problem, but it's recommended to update to Xcode 3.2.6.
>
> > Here are the log files:
>
> This seems to be an issue specific to gmp. It does some manipulation of
> the selected compiler which relies on assumptions that are no longer
> true in MacPorts 2.6. Please file a ticket.

Here it is:
https://trac.macports.org/ticket/59097

(I also wonder why the web app doesn't pick this ticket up:
https://ports.macports.org/port/gmp/tickets)

Mojca

Re: mpkg package variants

[Mojca Miklavec]

On Sat, 28 Sep 2019 at 20:49, Werner LEMBERG  wrote:
>
>
> Folks,
>
>
> I wonder how package variants are handled while creating `mpkg'
> bundles.  As an example, consider the output of
>
>   port rdeps lilypond-devel +mactex
>
> Looking at it you can see
>
>   ...
>   ossp-uuid
> perl5.26
> ...
>
> and
>
>   ...
>   llvm-3.4
> perl5
>   perl5.28
>   ...
>
> The created `mpgk-packages' directory indeed contains both perl 5.26
> and 5.28.
>
> However, it is possible to install `ossp-uuid' as
>
>   port install ossp-uuid +perl5_28
>
> In other words, it would be possible to omit a dependency on
> `perl5.26' altogether.  What must I do to enforce this for `port
> mpkg'?  This would reduce the size of the bundle by approx 16MByte...

On my machine "port info ossp-uuid" says that default in 5.28 now, but
you might have installed it when 5.26 was still the default, so I'm
not quite sure what goes wrong here (does installing with 5.28 variant
help?).

By far the best bet would be to remove 5.26 from this port and all its
dependents (or all ports, for that matter).

We need some help finishing https://trac.macports.org/ticket/58361 (or
maybe even go straight to 5.30 :).

Mojca

MacPorts Meeting 11th-16th October

[Mojca Miklavec]

Dear MacPorters,

I would like to remind everyone that we are hosting the 3rd
international meeting in Bohinj, Slovenia, from Friday 11th to
Wednesday 16th of October.

We'll be located in one of the nicest corners of the small country in
central Europe, next to a glacier lake, surrounded by the Alps, with
lots of options for hiking, cycling, etc. before the meeting, or
during the meeting if you happen to bring your own family.

We tried hard to make the meeting acceptable to everyone, with just
150 EUR for both accommodation and full board for five nights.

We expect participants from China, India, Indonesia, Germany, Italy,
Slovenia, ...

It's a wonderful opportunity to start hacking together and get your
long-awaited features done.

https://trac.macports.org/wiki/Meetings/MacPortsMeeting2019

Please consider spending an awesome extended weekeng with us and register here:

https://forms.gle/JbSLkykLSZRu7Q4b8

Mojca

Re: gnutls dependencies

[Mojca Miklavec]

On Tue, 1 Oct 2019 at 06:42, Kastus Shchuka wrote:
>
> Hi,
>
> gnutls was recently upgraded to 3.6.10_0. When I try to upgrade gnutls, it 
> pulls in a tall list of dependencies:
>
> --->  Computing dependencies for gnutls
> The following dependencies will be installed:
>  clang-8.0
>...
>
> Version 3.6.9_0 did not need them and worked just fine.

Which macOS version are you using? What does the "port rdeps gnutls"
say about the chain that leads to clang-8.0?
I don't see clang on the list for 10.13, but I'm pretty sure it's
needed on older systems after upgrade to MacPorts 2.6.0.

It's a lot more likely that the dependency was pulled in after you
updated MacPorts base rather than the port itself.

Mojca

Re: Octave.app 64-bit?

[Mojca Miklavec]

On Thu, 10 Oct 2019 at 23:12, Murray Eisenberg wrote:
>
> Is the current version of octave.app, installed with octave+app, 64-bit and 
> hence compatible with Catalina?
>
> if not, what are the prospects?
>
> In general, is there any way to tell which macports ports are, or are not, 
> 64-bit?

A dirty and maybe not 100% reliable way:
grep -r i386 | grep -v x86_64 | grep supported_archs

This returns 75 results, but some are just bogus, like TeXShop, when
there's a newer TeXShop4 port available, or Qt 3, ...

Probably the most problematic ones are Wine, some other emulators
(dosbox, ...) ... the rest are ancient apps that probably nobody would
notice if they get removed.

Mojca

Re: mpv, ffmpeg seg fault in macOS catalina

[Mojca Miklavec]

V čet., 17. okt. 2019 22:58 je oseba Gill Bates  napisala:

> I recently updated to catalina (10.15) and Xcode (11.1), installed
> MacPorts from source (2.6.1) and had it build mpv and its dependencies.
> However, mpv (and ffmpeg for example) do not run apparently related to some
> new default compiler option enforcing 16 byte stack alignment? See:
> https://trac.ffmpeg.org/ticket/8073
> https://github.com/mpv-player/mpv/issues/7053
> https://forums.developer.apple.com/thread/121887
>

I first saw https://github.com/LuaJIT/LuaJIT/issues/518, but that one
eventually leads to the same thread linked above.

 The advice seems to be to revert Xcode but will rebuilding everything with
> Xcode 10.3 on macos 10.15 really be a workaround? Or is a better choice to
> modify portfiles to include the CFLAG option to disable stack checks as
> mentioned in the linked posts and use Xcode 11.1?
>

Workaround is to either blacklist the compiler which has this option turned
on by default (which is what Chris replied) or in fact use a flag to
disable this. But disabling this flag is not needed for non-broken
compilers, so it's probably better to just blacklist the compiler, and the
latest compiler with be automatically used again when the bug gets fixed.

"Part B" is a question for my understanding, is this a really an
> Xcode/compiler issue or a problem with the source software packages?
>

I would say that this is in fact an issue with the compiler. As they said,
the bug has been present before, it's just that nobody noticed it until it
was switched on by default. I've seen an email saying that this is likely
to be fixed in one of the next Xcode updates, so it's just a matter of time.

I believe this affects only source code which uses some heavy
optimisations, which is why you would not see it in most of the software
where high performance is not crucially important for the functionality.

Mojca

Re: XCode 11 on Mojave problem, again

[Mojca Miklavec]

Dear Ruben,

This definitely looks like a bug in Xcode. I would suggest you to file
a bug report to Apple.

Can you please try to compile a simple hello world with just the
following contents

// test.cpp:
#include 
int main() { return 0; }

and compile it with:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
test.cpp \
-isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk

Mojca

On Fri, 8 Nov 2019 at 15:27, Ruben Di Battista
 wrote:
>
> Hello people,
>
> I saw this kind of errors quite often lately around. But this times I’m 
> hitting this with a local project, not a port in Macports. A project that 
> used to build correctly with Xcode 10, now it seems to miss stuff in  
> header.
>
> ninja -j 1
> [1/48] Building CXX object src/libs/CMakeFiles/Mercurve.dir/BlockMerger.cxx.o
> FAILED: src/libs/CMakeFiles/Mercurve.dir/BlockMerger.cxx.o
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
>   -DMercurve_EXPORTS -I../src/libs -isystem /opt/local/include/vtk-8.1 
> -isystem /opt/local/include -isystem /opt/local/include/mpich-mp -isystem 
> /opt/local/include/libxml2 -g -isysroot 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
>  -mmacosx-version-min=10.14 -fPIC   -Wall -Wno-long-long -pedantic 
> -fcolor-diagnostics -std=gnu++11 -MD -MT 
> src/libs/CMakeFiles/Mercurve.dir/BlockMerger.cxx.o -MF 
> src/libs/CMakeFiles/Mercurve.dir/BlockMerger.cxx.o.d -o 
> src/libs/CMakeFiles/Mercurve.dir/BlockMerger.cxx.o -c 
> ../src/libs/BlockMerger.cxx
> In file included from ../src/libs/BlockMerger.cxx:21:
> In file included from ../src/libs/BlockMerger.h:28:
> In file included from ../src/libs/types.h:25:
> In file included from 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/unordered_set:363:
> In file included from 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__hash_table:19:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:314:9:
>  error: no member named 'signbit' in the global namespace
> […]
>
> I read a bit the tickets of other ports, but they don’t fit exactly with what 
> I have. Any fast hint? Do I need to downgrade Xcode?
>
>   _
> -. .´  |
>   ',  ;|∞∞
> ˜˜ |∞ RdB
> ,.,|∞∞
>   .'   '.  |
> -'   `’
>
> https://rdb.is

Re: ksh93

[Mojca Miklavec]

On Fri, 15 Nov 2019 at 23:46, joerg van den hoff wrote:
> On 15.11.19 23:00, Christopher Jones wrote:
>  >
>  >> Hello,
>  >>If you put in a ticket to https://trac.macports.org/wiki/Tickets
>  it can be monitored.  It is up
> to the maintainer or someone else to update.
>  >
>  > or, even better, submit a PR with the update yourself at
>  >
>  > https://github.com/macports/macports-ports/pulls
> 
>
> a pull request? really? I mean, no offense meant (promise!) but the
> macports project sure has a policy for its maintained packages regarding
> updating them automatically on a regular basis?

MacPorts, as well as many other projects, is run by volunteers
receiving precisely zero money in exchange for their effort, and
anyone is welcome to join the team at any time.

Our biggest problem are unmaintained packages (which we have a lot
more than maintained ones), and for the explicitly maintained packages
it very often turns out that some people have abandoned the project
and we no longer have a way to reach them, and if we notice that, we
try to remove maintainers from packages.

Maintainers are generally expected to keep their packages up to date,
but most of them have "real life" as well :)

Depending on the volunteer, they would check for outdated packages
from time to time, but if there's an explicit request to deal with
something before they notice it, there's a bigger chance that a
package will be updated before others.

The "maintained" package that you are referring to belong to a
maintainer taking care of over 1000 packages
(https://ports.macports.org/maintainer/github/ryandesign/), and I can
tell you that updating some packages might literally take days, or
very often at least hours to get it done right. Sure, some are more
trivial, one can just increase the revision, send it to the CI and
merge it if it passes. But please note that people have the right to
"real life" beyond MacPorts as well.

While some automatism is possible, new version often need manual
intervention: sometimes upstream changes the build system, sometimes
they break it for us, sometimes they come with unacceptable new bugs,
maybe dependent packages break, maybe the patches no longer apply or
new patches are needed, sometimes location of the upstream project
changes, ...

> all those 20k+ packages
> are sure not updated manually by a handful of individuals on explicit
> request of a user, right?

Not all of them are updated on user request, but all of them are
updated manually. Often tools are used to get simple changes done, but
it's still done by people manually running the tools.

We are also always happy if someone can help us write and improve the
tooling to be able to do this more efficiently.

And yes, the maintainer in question has 23k+ commits (data taken from
openhub, it might be more depending on what you count, and this
doesn't include all other contributions made, any rebased changes
etc). All of them were done more or less manually.
(Just for comparison: our competitor's most active contributor has
35k+ commits according to openhub. And no, that's still not a robot.
Their robot has 140k+.)

> in the case at hand, the ksh93 "releases" reside as tarballs at
>
> https://github.com/att/ast/releases
>
> but this obviously is known to the package maintainer, I'd say... so why
> would a PR be in order?

- maintainer might be offline for a while

- while he might available, he might have other more important task
(including his real life!) that he needs done first

- if someone prepares a PR, the maintainer may look at it, and based
on CI results and experience with that particular software, and
depending on the extent to which the author has already tested the
changes, maybe decide to just click on the merge button while waiting
at a traffic light with his phone, greatly speeding up the process

- if the maintainer is not even online or otherwise available for a
certain amount of time, others may merge the changes

> and apart the pain caused by having to deal with git(hub) in the first
> place ;): in my view, the whole point of a descent package management
> system (which macports sure is these days more than ever) is that it
> frees the user from having to deal with the "low level" stuff while
> enabling him to just use the software he needs/wants.

Yes. Any decent software should be of great help to users ... provided
the developers spent an enormous amount of effort to make that
software great.

The whole point of going to a restaurant is to have a tasty dinner
served without the need to spend time cooking yourself. But that
assumes that you have some competent people working there, who put a
lot of effort into both learning and preparing your meal. Except in
this case you have volunteers working in the kitchen after-shifts
(when they come back from their regular paying jobs in the late
evening) and you don't pay a dime to eat t

Re: Test in local repository without privileges

[Mojca Miklavec]

On Fri, 17 Jan 2020 at 23:44, Christopher Jones
 wrote:
> On 17 Jan 2020, at 10:36 pm, Dave Allured - NOAA Affiliate via macports-users 
>  wrote:
>
> Chris, thanks for the quick reply.  You are correct, a private macports 
> installation would enable testing ports without special privilege.  Actually 
> I have already done this many times for testing and debugging other cases.
>
> However, I would like to find an intermediate solution that avoids full 
> build-up from sources.  My main reasons are (1) test sensitivity to installed 
> ports in the system prefix; (2) save time and effort; and (3) be able to 
> provide compact, uncomplicated reproducers to third parties.
>
> If not currently possible, it would be nice to have a new feature to enable 
> local repository testing, with fallback to the system prefix for everything 
> not found in the local repository.
>
> What you are asking for is I am afraid really not possible, I suspect. The 
> installation prefix is a fundamental parameter in most port builds. Many 
> directly use this via the ${prefix} variable, which is a single valued path. 
> What you are asking for is for a port use to use one location for some ports 
> and a second one from others. I just don’t see how that could work.
>
> I think your only option is really to go with a second installation using a 
> custom prefix.

The only thing we could potentially do (but sadly I don't see it
coming any time soon unless we get a devoted developer with sufficient
time and skillset willing to work on this) is to support
"relocatability" of packages to avoid building everything from source.
It should be possible to a certain extent (at least our competitors
did it).

However installing some packages in one prefix and others in another
is going to lead to countless troubles. Binaries have absolute links
to their dependencies. So if you have library A, library B which
depends on A, and binary C which depends on B, you install all three
to /opt/local and then decide to test B in local installation using A
from global prefix, this will generate a mess and will stop working as
soon as A in global prefix is updated. Moreover you also need to
install C to local prefix, else the test won't be "complete". I could
keep on talking about problems, but long story short: not an option.

Mojca

Re: Dependency untangling riddle

[Mojca Miklavec]

On Wed, 5 Feb 2020 at 19:19, Ryan Schmidt wrote:
> On Feb 5, 2020, at 11:48, Vincent Habchi wrote:
>
> > So basically I have a long list of dependents to install, one (or more) of 
> > which itself/themselves depend(s) on python 3.7, at least in its/their 
> > default version(s). Since I don’t want to have python3.7 installed 
> > alongside python3.8, how can I find out (easily) which port(s) in the list 
> > is/are requiring python37?
>
> Just let MacPorts install what it wants to and the port should work. It is 
> normal for ports to have dependencies on things that you don't otherwise wish 
> to use yourself. That is ok.
>
> For some reason many port maintainers are selecting python37 when they need a 
> python3. I wish they would use the latest stable version, python38, instead.

In probably all the cases the use of python37 rather than 38 is a sole
consequence of:
(A) nobody bothering to change that to 37 in that particular port (I'm
pretty sure some of my own ports still depend on python 3.7, but
there's no "dear macports, please tell me which ports I need to
update" command)
(B) or maybe someone trying to change it, but eventually figuring out
that not all py38-* dependencies are available, and not being
proactive enough to try to change the full chain.

Last time I tried to upgrade buildbot to 3.8 it probably took me two
hours to fix all dependencies which were still missing support for
3.8, and once I did it, both master and worker on my machines became
broken (and it took me quite some time to figure out the reason)
because the launch file hardcodes python version, and one needs to
manually fix it and restart the service (as well as properly stop the
old one, which is not always straightforward). Not that any single
module care about whether it's running python 3.7 or 3.8, it's just
that historic reasons / too many ports have their own consequences.

That said, feel welcome to submit pull requests to update individual ports.

Mojca

Re: Befuddled

[Mojca Miklavec]

On Sat, 15 Feb 2020 at 07:22, Jeff Greenberg wrote:
>
> Hi. After restarting my mac, localhost is refusing connections, and 
> attempting to restart apachectl results in this error message:
>
> httpd: Syntax error on line 168 of /opt/local/etc/apache2/httpd.conf: Cannot 
> load lib/apache2/modules/mod_php72.so into server: 
> dlopen(/opt/local/lib/apache2/modules/mod_php72.so, 10): Library not loaded: 
> /opt/local/lib/libicui18n.58.dylib\n  Referenced from: 
> /opt/local/lib/apache2/modules/mod_php72.so\n  Reason: image not found

Try to run
port provides /opt/local/lib/apache2/modules/mod_php72.so
to see which port is broken.
You need to update that port. (We should set up a database of all the
files provided by the individual packages at some point.)

Based on the logs it might be php72-apache2handler. Try
sudo port upgrade php72-apache2handler

But generally you need to run
sudo port selfupdate
sudo port upgrade outdated
and this should upgrade all ports.
You were just a bit unlucky that one of the ports was broken and that
broke the rest of the update process.

The error when building gtk-doc says
/opt/local/bin/ranlib: object: .libs/libtester.a(tester.o)
malformed object (unknown load command 1)
but I have no clue what that means.

According to
https://ports.macports.org/port/gtk-doc/builds
the build did succeed on 10.14 in August 2019 and other tickets listed in
https://ports.macports.org/port/gtk-doc/tickets
seem unrelated.

You may not need gtk-doc for now, so if you update all other ports
your system should at least be functional again, and in parallel you
can file a ticket and we can try to diagnose what could go wrong. Run
port outdated
to see what else needs updating. (You could run "sudo port upgrade
outdated and not gtk-doc", and hope that no other ports depends on it,
so that update would continue.)

Mojca

Re: provided, was Re: Befuddled

[Mojca Miklavec]

On Sat, 15 Feb 2020 at 12:47, Richard L. Hamilton wrote:
> > On Feb 15, 2020, at 05:45, Mojca Miklavec wrote:
> >
> >  (We should set up a database of all the
> > files provided by the individual packages at some point.)
>
> Variants complicate that, I think.

Yes, variants definitely complicate that, but having a database of
files provided by the default variants would already be enormously
helpful.

Buildbot already prints the list of files as it builds ports. All we
need is to enter those data into the web app, no need to crowdsource
information collection, and crowdsourcing (telemetry) would not by
itself solve the problem of someone needing to do the coding necessary
to make the information nicely accessible and searchable (within the
scope of the website made last year during GSOC).

As far as accurate info goes: you cannot get that unless you really
build every single port with every single variant combination. And
even then you might get ports which opportunistically find
dependencies and change behaviour based on that, so the info would not
be 100% accurate anyway.

> So much as I'd enjoy the quick response it might provide, I wonder about the 
> real-world utility given the effort (and what else might benefit more from 
> the effort).

I'm not sure I understood what you wanted to ask / say here.

Mojca


Mojca

Re: Pruning old Perl installs

[Mojca Miklavec]

On Tue, 7 Apr 2020 at 06:23, Bill Cole wrote:
>
> Go for it. At worst, you'll need to reinstall a few Perl ports, and they
> mostly install quite fast.
>
> (NOTE: if Mojca gives a different answer, feel free to totally ignore
> mine. )

p5.24-* ports were supposed to be uninstalled automatically at some point?
Not sure why they were not if "sudo port upgrade outdated" was
executed on regular basis (or at least one per year).

That said, ... we really need a volunteer to replace p5.26 with either
5.28 or 5.30 in all ports depending on these modules

Mojca

Re: mingw-w64 and gcc 9.3.0

[Mojca Miklavec]

On Sun, 3 May 2020 at 00:46, Ryan Schmidt wrote:
>
> On Apr 30, 2020, at 17:08, Ces VLC wrote:
>
> > I'd like to use gcc 9.3.0 with mingw-w64 (the list of bugfixes in 9.3.0 
> > looks significant). I don't know how much effort will this update require, 
> > I just add my vote for it here, thanking your great support once more!
>
> A ticket in the issue tracker is the usual way to request a port update.

Except that in this case a pull request was already there:
https://github.com/macports/macports-ports/pull/6822
and now the latest version should already be available.

Mojca

Call for designers for our ports website

[Mojca Miklavec]

Dear MacPorters,

As part of a GSOC project Arjun has been working on great new features
for our web application with information about ports.

The application from last year has been deployed at
https://ports.macports.org/
while the new testing site is temporarily located at
http://macports.silentfox.tech/

The website already looks nice, but if we had some talented designers
among our users willing to help us go one step beyond what we have
right now, we would be extremely grateful for either just some advice
or potentially some more extensive help. There are a lot of minor
tweaks that could be done, but neither of us is a designer, and I'm
not able to give any competent advice about how to best improve the
layout.

Here are some concrete examples of subpages:
- http://macports.silentfox.tech/port/root6/
- http://macports.silentfox.tech/port/gnuplot/stats/?days=365&days_ago=0
- http://macports.silentfox.tech/search/?installed_file=&q=root&name=on

Thank you very much in advance,
Mojca

Re: MacPorts webapp project updates

[Mojca Miklavec]

Hi,

I just figured out that we forgot to send this email to the users mailing
list, it only went to developers.

Arjun has done an awesome job improving the work on the ports website as
part of a GSOC project.

We would be extremely grateful to get your feedback about
http://macports.silentfox.tech/
before it gets deployed to ports.macports.org.

Thank you very much,
Mojca

PS: Since last week when the message was written the splashscreen and the
dark mode have been implemented (among others).

On Sun, 12 Jul 2020 at 20:56, Arjun Salyan wrote:

> Hello all,
>
> This is in continuation to my previous emails regarding updates about the
> webapp. The temporary version is deployed at
> http://macports.silentfox.tech/
>
> *New features:*
>
> *Accounts:*
> Users can now create accounts on the webapp using email/password or login
> with their GitHub handles.
>
> *Watchlist and notifications:*
> Logged-in users can add ports to the watchlist. Notifications are
> displayed whenever a port gets updated. An overview of the followed ports
> is displayed with filters for "broken builds", "outdated livecheck" etc.
>
> *"Followed by me" ports*
> Logged-in users can get an overview of the ports that they maintain (this
> is done by matching their emails and GitHub handles with those supplied in
> the Portfiles).
>
> *"Splash screen" (upcoming)*
> It was pointed out that our current port page (
> http://macports.silentfox.tech/port/cctools/) contains a lot of technical
> information which might not be useful for the general user. This reduces
> the odds of user acquisition. So, we plan to add a page with a focus on the
> software version and installation instructions. It will have a link to the
> existing page under "Details". Maintainers and advanced users will be able
> to by-pass this page (setting a cookie with the preferred page) and reach
> the details page directly. Existing links will be maintained in this
> process.
>
> Feedback and suggestions would be very constructive.
>
> Thank You
>
>

Re: info

[Mojca Miklavec]

On Fri, 27 Nov 2020 at 16:27, Giovanni Cantele wrote:
>
> Dear All,.
>
> I’m searching the web but I cannot find any response to the following 
> question:
>
> is there any ongoing project for porting the whole macports staff on the new 
> Apple silicon architecture?

There is no "special ongoing project". There are volunteer owners of
Apple silicon trying to fix the bugs they encounter.
MacPorts itself should work, lots of ports work, some complex software
requires non-trivial patches from upstream.

> What happens to those who extensively make use of macports and have bought 
> the recent released MacBook Pro running on the new processors?

You should be able to install MacPorts and many ports. But you should
not be surprised if you hit some that will refuse to build and you may
need to wait for upstream to fix the issue (or try to fix it yourself
and submit a patch or find someone else capable of fixing it ...).

You brought up an interesting point though, we should probably publish
some official statement about arm support on our main website.

On Fri, 4 Dec 2020 at 16:19, Alejandro Imass wrote:
>
> What you are saying suggests that nothing major has changed except the LLVM 
> target to arm64, is this correct?

Disclaimer: I don't have any experience with an arm-based mac.

As far as MacPorts is concerned, I would say that indeed "almost
nothing major" has changed in principle (other than the processor,
which is ... well, a really major change).

A lot of relatively simple, well-written software with a well-written
build system should often work out of the box.

But a lot of software may either have some hard-coded assumptions in
either their build system or the source, it may require some
intel-specific intrinsics, or it may depend on some complex
third-party library that doesn't compile. Apple also likes to increase
security standards each year which may break many ports in various
ways.

If you have your favourite port, you can quickly check the build
results on, say,
https://ports.macports.org/port/wget/stats
and check for either green port status or some reported installations
on arm64, check for open tickets etc. Keep in mind that many port
builds haven't been attempted yet.

(I also see that some builds like wget were successful, but missing on
the list, while some like youtube-dl are redirected to the x86_64
builder and also don't end up on that list.)

Mojca

Re: updating TeX Live

[Mojca Miklavec]

On Thu, 11 Feb 2021 at 22:34, Henning Hraban Ramm wrote:
>
> Hi, is there a possibility to update the MacPorts version of TeX Live 2020?

It depends on whether you are willing to wait for TeX Live 2021, or
willing to volunteer to create devel subports yourself. See:
https://github.com/macports/macports-ports/tree/master/tex

Otherwise ... not really.

> (I’m debugging at a customer’s LaTeX project, colleagues and build server 
> have different versions of TeX Live 2020. I installed the MacPorts version 
> because I needed it as a dependency anyway, but now I’d need an update, and I 
> don’t dare to just overwrite anything in /opt/local/)

If you need the latest version, go for
http://www.tug.org/texlive/acquire-netinstall.html or MacTeX.

Mojca

Re: Build servers going offline due to inclement weather

[Mojca Miklavec]

On Sat, 20 Feb 2021 at 08:41, Richard L. Hamilton  wrote:
>
> Ok, thanks. In the future then, I might do that if after 2-3 days, the outage 
> was expected to continue for perhaps that much more, so that I didn't get too 
> far behind; and I'd probably blow away the clone and switch back after things 
> were back to normal (since it wouldn't be worth the slowdown the rest of the 
> time).

I'm exclusively using git for updating ports.

Running portindex only takes forever the first time you do it. Or if
you don't update for a very very long time. Any subsequent updates
from git and portindex runs are fast. Actually, if you are updating
very often, updates via git are probably faster.

(The only drawback of updating through git is that you may get updated
definitions "slightly too soon". If you get portindex with some delay,
it's more likely that buildbot has already finished building the
package in the meantime.)

Mojca

Re: Class wxDisclosureNSButton is implemented in both … One of the two will be used. Which one is undefined.

[Mojca Miklavec]

On Fri, 26 Mar 2021 at 20:40, Ken Cunningham wrote:
>
> wxWidgets-3.0 on the buildbot was built back in January 
>  when install_name_tool had a 
> bug in it. That bug has since been fixed.
>
>
> sudo port -f uninstall wxWidgets-3.0
> sudo port -v -s install wxWidgets-3.0
>
> should get you fixed up.
>
> Someone might consider revbumping wxWidgets-3.0 at some point when they feel 
> it’s a good time to do that.

Hi,

I'm sorry for this, but I hope that it has finally been fixed.

Mojca

Re: clang: error: invalid version number in 'MACOSX_DEPLOYMENT_TARGET=11.3'

[Mojca Miklavec]

Hi,

On Sat, 1 May 2021 at 12:22, Joshua Root wrote:
>
> This usually indicates that your Command Line Tools are outdated. If
> Software Update won't update them, you are affected by an Apple bug, and
> will need to follow the instructions here:
> 

I wasn't experiencing the exact same problem, but it might be related,
and I'm confused.

Basically my problems started after I upgraded Big Sur and rebooted
two days ago. I never installed Xcode, only the command-line tools.

I had a repository that would be automatically built with CMake &
Ninja (triggered via buildbot). The problem can be summarized as [1]:

/Library/Developer/CommandLineTools/usr/bin/cc test.c -o test
test.c:1:10: fatal error: 'stdio.h' file not found
#include 
 ^
1 error generated.

(Note that just "clang test.c -o test" works just fine.)

Curiously it helped when I made a clean checkout of the repository
without doing anything else. Apparently CMake picked the compiler in a
different way then(???), I have no clue [2].

I initially planned to somewhat ignore the problem I had earlier, but
then MacPorts started pointing me to the above link on the Trac about
how to reinstall CLT. I followed the steps. It downloaded 1 GB of
stuff, and (as expected) kept saying that I needed to update CLT for
Xcode 12.4 and 12.5 even after the download was completed. I tried
running it again, just in case, but I never actually saw anything
being updated, I just saw the files being downloaded (it took too long
to watch till the end) and when I came back to the computer,
everything was as if nothing had happened, just prompting me to
install the two updates again.

I believe that MacPorts stopped complaining about broken CLT, but the
above command that initially failed
/Library/Developer/CommandLineTools/usr/bin/cc test.c -o test
still fails to work.

I'm just totally confused.

Mojca


[1] https://build.contextgarden.net/#/builders/92/builds/35
[2] https://build.contextgarden.net/#/builders/92/builds/36

Re: New portfile writer looking for help with ConvertAll

[Mojca Miklavec]

On Tue, 13 Jul 2021 at 05:15, Kevin Horton wrote:
>
> I assume that I would submit this via Trac to see it possibly someday show up 
> in MacPorts.

While this is perfectly OK, a lot more people are watching pull requests:
https://github.com/macports/macports-ports/pulls
By submitting a pull request, it will be seen by multiple developers
multiple times which is not necessarily true for Trac (which is
perfectly suitable for bug reports, in particular when ports have
maintainers, but it gets attention from far less people).

> I dig into the docs a bit more first to see if there are any other Portfile 
> fields I should populate, or if I can find any best practices that I have 
> violated.

GitHub is also much better than Trac to get this kind of feedback.

Mojca

Re: Workflows and best practices for pull requests?

[Mojca Miklavec]

Dear Kevin,

On Wed, 14 Jul 2021 at 05:05, Kevin Horton wrote:
>
> I'm new to working with a team of committers, and I'm a very basic git user, 
> so I'm struggling to figure out workflows and best practices when making a 
> pull request and reviewing comments on a pull request.
>
> Questions:
> 1. One of the checkboxes when making a pull request is "squashed and 
> minimized your commits".  I tend to make many small commits when working on 
> my personal projects.  What is the best way to squash those commits before 
> making the pull request?  Google seems to suggest an interactive rebase is 
> the way to go.  Comments?

The idea of "squashing and minimizing" applies to the case when someone:
- makes a change
- finds an issue
- commits a fix
- finds another issue
- commits another fix
- etc.

Basically we want to prevent a long list of bugfixing.

It's generally still preferable to use atomic commits for unrelated
changes, it's just desirable to squash "bug fixes for previous faulty
commits".

> 2. I'm completely baffled by the GitHub interface for dealing with comments 
> on a pull request.  Assuming I have made and testing the changes suggested by 
> reviewers, what is my next action?  Make a new pull request?  Is there a way 
> to modify the existing pull request?

No, the best way to handle suggestions is to push changes to the same
branch, which will update the existing pull request.
If you made some mistakes (that others warned you about), the idea is
to amend the commit and force push to that same branch.

Opening a new pull request is counter-productive as you then lose
older discussions.

Mojca

New ports.macports.org website

[Mojca Miklavec]

Dear MacPorts users and developers,

I'm really thrilled to see the new version of the ports website
finally being deployed at
 https://ports.macports.org

I'm extremely grateful for the excellent work that Arjun did during
the GSOC summers of 2019 and 2020. He kept maintaining the code after
GSOC and made the migration to his own server (the previous server was
running out of resources to be able to cope with the additional
requirements introduced in the last summer).

Many thanks also to Amar with a much deeper understanding of Django
and related technologies who co-mentored the project in 2020 and made
sure that we ended up with a product of much higher quality than any
one of us could have achieved.

Some exciting new features involve:
- Dark mode.
- Better REST API.
- Remove dependency on Google Charts (blocked in some parts of the world).
- More advanced / extensive search & filtering for ports.
- Find ports that provide a particular file.
- The site runs livecheck and reports outdated ports.
- Ability to log in with GitHub OAuth and follow your favourite ports.
You can check whether they are outdated or broken on some platforms,
making it easier to see where contributions are needed.

You can read a bit more about the project on Arjun's blog:
https://arjunsalyan.com/gsoc20-report/

The code lives at
https://github.com/macports/macports-webapp

We would be most happy to see contributions to this project, both in
terms of programming as well as for design, ideas etc.
Arjun did an impressive job already (everything from backend to
design), but if we have some talented designers around, please speak
up.

I would also like to invite everyone who hasn't done that already to
opt-in for anonymous statistics submissions:

sudo port install mpstats

Thank you,
Mojca

PS: The old version will still live at
https://port-old.macports.org
for a little while, just in case.

Re: code::blocks and X11 via MacPorts: is this as it is supposed to be?

[Mojca Miklavec]

Hi,

code::blocks is in a dire need for some love from a developer.

There has been a release 20.03 in the meantime, but we are still
shipping 17.12 (17 stands for 2017, just in case it isn't clear).
>From what I remember wxWidgets 3.0 never worked satisfactory in that
(older) port, which is partially the reason why the +wxgtk28 variant
was left there in the port in the first place. The upstream lacks some
macOS-savy developer workforce.

(When I last touched the port, it also took forever to build it on a
2009 laptop, making it more annoying to try out various patches,
variants etc.)

It would be great if someone could try to update the port (which most
likely includes writing some potentially non-trivial patches to make
it build) and see if wxWidgets support got any better in the meantime.

Mojca

Re: Add M1 Hypervisor Support for QEMU Port?

[Mojca Miklavec]

On Wed, 27 Oct 2021 at 06:02, Ryan Schmidt wrote:
> On Oct 20, 2021, at 22:06, Sriranga Veeraraghavan wrote:
>
> > Is there a way to add an optional variant to the QEMU Portfile that would 
> > apply this patch?
>
> Yes, it is technically possible to do that. However, we prefer not to include 
> and forever maintain unofficial patches. Instead, we would prefer for such 
> patches to be submitted to the upstream developers of the software. If they 
> include it, then MacPorts will automatically get that and any other changes 
> when we update to the next version of the software. If upstream elects not to 
> include a patch, then we would have to seriously consider whether it would be 
> appropriate for us to second-guess their decision and include it in MacPorts 
> anyway.

I checked their patch procedure which looks pretty involved ...

... but according to
https://github.com/Homebrew/homebrew-core/pull/85173
it looks like upstream has already merged the changes.

It's hard to follow exactly because commits don't exactly match the
contents of that patch, but by looking at and blaming individual files
(touched by that patch) in the master branch, the first three randomly
chosen changes seem to be included, some of them in the "staging"
branch, whatever that means.

Given that HB has started this and seems to be actively involved in
maintaining the patches, I would say that it's probably perfectly safe
to include the patches on any arm machine at least. Most likely the
patches will either no longer be needed with the next release, or in
the worst case we can copy them over from HB once again.

Ranga, if you are willing to prepare a pull request, I would support
that. I don't think we need a variant for that, I would just
unconditionally apply the patch, at least on any arm-based CPU.

Mojca

Any Django volunteers to co-mentor for Google Summer of Code?

[Mojca Miklavec]

Hi,

I wanted to ask if we happen to have any volunteers to co-mentor a
Django project for GSOC
for further improvements of https://ports.macports.org/

We have some mentoring force right now, but not enough to apply for
GSOC unless we can recruit at least one more devoted person.
The potential co-mentor doesn't necessarily need any experience with
MacPorts (so we could look outside of the existing community), but
being able to provide quality feedback and suggestions in the area of
web development would be of enormous help.

Thank you,
Mojca

Re: Bad macports.org link to Available Ports page

[Mojca Miklavec]

On Sun, 6 Feb 2022 at 09:17, list_email--- via macports-users wrote:
>
> Sorry if this has been reported before.
>
> The Available Ports page at https://ports.macports.org/ reports Error 503 
> Backend fetch failed.

I don't know whether Arjun explicitly fixed something, but the page
seems to be back.

Mojca

Re: IRC channel

[Mojca Miklavec]

On Mon, 7 Mar 2022 at 04:06, Michele Venturi wrote:
>
> Anyway RocketChat should be fixed as it doesn't work...

Aljaž is aware of the problem.

He was hoping that the latest upgrade would fix the issue, but
apparently it doesn't:
https://github.com/RocketChat/Rocket.Chat/issues/24460
https://github.com/RocketChat/Rocket.Chat/issues/24355

I'm not sure what could/should be done (other than someone stepping up
to help the rocketchat team fix the issue, or migrate to something
else; we discarded the idea of using Discord as it's being blocked in
some countries).

Mojca

Re: IRC channel

[Mojca Miklavec]

On Sun, 8 May 2022 at 00:20, Michele Venturi wrote:
>
> you should care enough to look for someone to do it if you can not do it
> and I should not need to tell you what to do with it, no?

No, the person who voluntarily offered the server and set up the chat
the first time around, is not a tiny bit any more obliged to continue
running the service than me or you are.

The whole project is run by volunteers with full time jobs, families
and other hobbies beyond MacPorts.
The community will happily accept contributions from anyone who's
capable of improving the overall experience of using MacPorts in any
given area.

So if you know how to configure the server yourself or if you know how
to find someone to do it for us, we'll be more than happy to see it
come back to life.

If we collect sufficient donations (or in some other way), we might be
able to ask Rocket.Chat developers themselves for support (for fixing
the bug that broke oauth in recent versions). If you know how to tell
rocket chat that they "should fix their bug" (we are not currently
paying them a dime), that kind of help from you would also be more
than welcome.

Mojca

Re: A simple request (MkHexGrid) turned into ...

[Mojca Miklavec]

On Sat, 14 May 2022 at 16:20, Michael wrote:
>
> So I thought I'd install a simple little hex map generator. Mkhexgrid.
>
> Hasn't been updated in years, should be simple, right?
>
> Three versions of Python (37, 38, and 39)
> A full reinstall of X
>
> I mean, I can sort-of understand perl, one python, and ssl -- maybe it needed 
> to rebuild something, and needed updated ssh fetching and rebuilding the 
> compilation environment.
>
> But everything else? And three versions of python? And not just python 2 vs 
> python 3.

For me python 2.7 sneaks in as a build dependency of ICU (that only
affects users of the latest macOS).
I see neither python 3.7 nor python 3.8 on the dependency list. Those
could be side-effects of something that you have installed earlier
which keeps depending on an older version of python. Or maybe you are
using a different OS version that has slightly different dependencies.

The following patch for ICU that replaces python 2.7 with 3.10 seems
to work for me:

--- a/devel/icu/Portfile
+++ b/devel/icu/Portfile
@@ -113,9 +113,9 @@ if {${subport} eq ${name} || ${subport} eq "${name}-lx"} {
test.args VERBOSE=1

if {${os.platform} eq "darwin" && (${os.major} < 11 || ${os.major} > 20)} {
- depends_build-append port:python27
- license_noconflict python27
- configure.python ${prefix}/bin/python2.7
+ depends_build-append port:python310
+ license_noconflict python310
+ configure.python ${prefix}/bin/python3.10
}

if {${build_arch} eq "ppc" || ${build_arch} eq "ppc64"} {

This patch should probably be applied anyway.

(Ken: is there some Tiger-like reason to keep python 2.7 as a build
dependency of ICU?)

You can check why you are getting weird dependency by running the
following command:
port rdeps mkhexgrid

Say, the reason why you need python 3.9 is because meson currently
declares a dependency on python 3.9 and that should definitely be
changed as well.
There's an open pull request for meson from 2 days ago.

> I'm assuming that somewhere, some graphical library was being used that could 
> output to X as well as to ascii/curses. I just have no idea what.

Yes, mkhexgrid depends on gd2 which depends on X11 by default. Try to
run "port info gd2" or check
https://ports.macports.org/port/gd2/details/

You can avoid the need to install x11 by installing "sudo port install
gd2 -x11" before installing mkhexgrid.

All I can say is that the situation with multiple versions of
python/perl/etc. could and should be improved.
Whether or not the default variant to install gd2 with X11 support is
something that I'm not competent to judge.

"port rdeps " will usually provide you enough information to
figure out why some dependency is there.
Sometimes it makes sense, sometimes it's something that could be improved.

Btw: you should usually update all your ports before installing a new port.
It could happen that by installing a new port, one of the libraries (a
dependency) will be upgraded, while another port that depends on that
same library won't be updated and may stop working.

Mojca

Re: A simple request (MkHexGrid) turned into ...

[Mojca Miklavec]

On Sat, 14 May 2022 at 19:55, Michael wrote:
> On 2022-05-14, at 9:27 AM, Mojca Miklavec wrote:
> > On Sat, 14 May 2022 at 16:20, Michael wrote:
> >>
> >> So I thought I'd install a simple little hex map generator. Mkhexgrid.
> >>
> >> Hasn't been updated in years, should be simple, right?
> > ...
> > You can check why you are getting weird dependency by running the
> > following command:
> >port rdeps mkhexgrid
>
> Hmm. Just some highlights. It took a compiler??

In such cases it's crucial to also provide information about the macOS
version that you are using.

Your list is suggesting that the compiler installation was required by
the port dav1d which uses meson for building.

See:

https://github.com/macports/macports-ports/blob/master/multimedia/dav1d/Portfile#L47-L50
suggesting that this looks like a workaround for a bug in the meson
build system that has been ignored for more than a year:
https://github.com/mesonbuild/meson/issues/8307
and it looks as if this was only relevant for macOS <= 10.9.

If you install the port from the binary archive, you shouldn't be
getting the compiler though. The command "port rdeps" lists all
dependencies, including build dependencies.

Other than fixing the bug upstream in the meson build system, I don't
have any better idea about what could be done about this (unless it
has already been fixed in the meantime and nobody noticed it).

> Cairo was another port installed, and not on that list. (Checked -- it's 
> +quartz -X11)

If you want to know which port requires x11, you can run "port depend
", like this, but using the relevant name:

% port depend xz
libarchive depends on xz
libxml2 depends on xz
python310 depends on xz
tiff depends on xz
zstd depends on xz

Mojca

Re: Macports needs a little marketing ....

[Mojca Miklavec]

On 8 November 2016 at 20:26, Bachsau wrote:
> Am 08.11.2016 um 06:57 schrieb Ryan Schmidt:
>>
>> Also, who decides what is stable?
>>
>> Who decides when to update it?
>
> Apple. A new stable version should be released for every iteration of macOS.

This would possibly be the lease useful approach.

Before a new macOS release gets published, it is pretty much forbidden
to discuss any problems publicly and the audience is limited to
adventurous developers with payed membership subscriptions. Once a new
OS gets released, a whole lot of problems get discovered and must be
fixed. It can be as fundamental as broken Perl which is a dependency
of a huge number of ports. Some of the problems need to wait until
developers of the broken software are able to install the new OS and
fix the issues. Fixing problems can take days, weeks, months, ... So
who then decides the cut-off date for the new release of MacPorts? And
who will keep backporting new fixes after the release?

For Debian it is an easy cut. They release a new OS version when all
the packages have been tested thoroughly. For macOS it is vice versa.
Apple working for a year or more in full secrecy without letting
anyone (other than perhaps a few apple insiders who happen to be port
maintainers) to do any testing at all.

Realistically we could perhaps only release a "stable" version for
10.11 short before 10.12 gets released, but I don't see any added
value of that.

And then you have cases like certain ports that need to be upgraded,
but the new version is known not to work with another port (VLC
doesn't work with ffmpeg version 3 for example and upstream is not
eager to do any progress any time soon, on the other hand other
software would not work with version 2; some software doesn't work
with wxWidgets 3 etc. and the situation is not likely to improve any
time soon). Fixing everything is nearly impossible.

The only thing that could be done would be a slight delay between
master and "stable". For example everything that's in master would go
to "quasi-stable" after a week unless some problems are discovered
(and then the port would be held back). But this requires extra
manpower again. Something we lack already.

Mojca

Re: p5.22-specio failed to uninstall

[Mojca Miklavec]

On 22 November 2016 at 04:29, Dave Horsfall  wrote:
> On Mon, 21 Nov 2016, Lawrence Velázquez wrote:
>
>> > Why would an inactive replaced port have dependents?
>>
>> I'm not sure.
>
> Well, I've come to a grinding halt because of this.  What further
> information can I supply so this can be fixed?

Try
sudo port uninstall 'p5.22*'

> Note that I don't even
> know what that port is (I assume it's to do with Perl), as it's required
> by something else.

It was probably required by some other port, but it has been replaced
by p5.24-specio, so it should be safe to remove it and all its
dependents.

All ports that depend on it must be inactive unless you modified
something manually on your machine only.

I have no idea why MacPorts is facing problems and complains when you
try to uninstall a port that's a dependency of another inactive port,
but I experience the same kind of problems when I run "port reclaim"
(from master). Now I try to avoid running "port reclaim" :)

Mojca

Re: Broken ports?

[Mojca Miklavec]

On 22 November 2016 at 02:31, Justin C. Walker wrote:
> On Nov 21, 2016, at 17:04 , Marius Schamschula wrote:
>
>> Justin,
>>
>> See https://trac.macports.org/changeset/154370
>
> That explains a lot!
>
> Thanks.
>
> Justin

Following
https://sourceforge.net/p/surf/bugs/14/
I discovered a potential replacement:
https://imaginary.org/program/surfer
https://github.com/IMAGINARY/SURFER

Mojca

Re: PowerMac download statistics?

[Mojca Miklavec]

On 6 January 2017 at 22:48, Jeffrey Walton wrote:
> Hi Everyone,
>
> I'm looking for statistics on the number of Macports users and the
> number of PowerMac users.
>
> Does MacPorts track the statistics?

No, unless you run "sudo port install mpstats" which is not even advertized.

> If so, are they publicly available?

There is some (useless) statistics from a small number of volunteers at
http://stats.macports.neverpanic.de/os_statistics

But maybe someone from the infrastructure team could provide some
numbers from the binary archives from our mirrors (now that we have
the ppc binaries). Again this would miss everyone setting gcc6 as
their main compiler.

Mojca

Re: override local port

[Mojca Miklavec]

On 2 February 2017 at 09:17, db wrote:
> How can I override a local portfile without deleting it? I want to keep some 
> ports locally, for example, after I submitted a new, locally tested port that 
> made it in the repo, or when I want to keep an older portfile until I fully 
> tested the latest version of an application.

You can set up multiple local repositories. If you add the second
local repository on top (with a higher preference), that other
repository will "override" the first one (in case both contain the
same port).

One option is that you set up a local repository that consist just of
symlinks. If you want to remove a port, you just delete the symlink
and the original stays untouched where it was.

One option is to use git manipulations (different branches and then
switching between them, merging them, cherry-picking changes, going
back to history, ...)

Mojca

Re: override local port

[Mojca Miklavec]

On 2 February 2017 at 16:02, db  wrote:
> I already have a local repo — I'd like a port in the rsync tree to 
> exceptionally override the local one (higher preference) while keeping both 
> in place.

If you only want to do it once, you can cd to the folder with the port
that you want to use and run "sudo port ..." from there.

Mojca

Re: new ports not showing in search

[Mojca Miklavec]

On 6 February 2017 at 19:28, db wrote:
> Could you tell when a new port is listed at macports.org?
>
> E.g., hstr has already been accepted but it doesn't show up.
>
> https://www.macports.org/ports.php?by=name&substr=hstr

Updating the website has not been deployed yet (we have some scripts
that are supposed to update the website, but they are not running
yet).

Mojca

Re: Will using only dolphin be too much overhead?

[Mojca Miklavec]

On 9 February 2017 at 07:38, Dorien Herremans wrote:
>
> However, sudo port install gtk2+x11 doesn't seem to be valid.

Maybe just a typo (space between the port name and option)?

Mojca

Re: Newbie need help for upgrading python on snow leopard

[Mojca Miklavec]

Hi,

On 16 February 2017 at 01:10, Elim Qiu wrote:
> I don't even know if this list is about any system software upgrade... But I
> did get problem about upgrade python 2.6 to python 2.7.
>
> It seems easy just download a dmg file, apply it to get pythong 2.7. But
> after that I cannot get ipython to work. And I encountered a lot of
> path/config problem.
>
> If I asked the right group, please advise me what to do so that pythong 2.7
> and ipython can work properly.

This list is about installing a package manager and upgrading packages
from within the package manager. See:
https://www.macports.org/install.php

Once you install MacPorts, you can install any version of python
(ideally 2.7 as well as 3.5 or 3.6, ...) as well as "any other open
source software". You just run
sudo port install python27

without any headaches with dmg files and broken paths. You might want
to remove the python you install via the above mentioned dmg.

For ipython you should install
sudo port install py27-ipython
and/or
sudo port install py36-ipython

Mojca

Re: Newbie need help for upgrading python on snow leopard

[Mojca Miklavec]

On 17 February 2017 at 02:56, Elim Qiu wrote:
> I installed macpots to both my iMac and my black macbook(both with snow
> leopard). And use it to install python27, py27-ipython.
>
> It turns out the black macbook worked but my iMac didn't work. I still can
> only bring up python 2.6 after successfully installed python27. Even I cd to
> /opt/local/bin and call python, it still brought python 2.6 for me. What I
> have to do?

You should either call "python2.7" or run
 sudo port select --set python python27
if you want the "python" command to always execute pyhon 2.7 from
MacPorts. (I don't know how ipython works.)

Mojca

Re: port selfupdate / port reclaim

[Mojca Miklavec]

On 25 February 2017 at 19:55, Aljaž Srebrnič wrote:
>> On 19 feb 2017, at 11:16, Mark Bestley wrote:
>>
>> 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
>> Error: reclaim failed: wrong # args: should be "macports::reclaim_main opts"
>>
>> How do I fix this and what parts have not run?
>
>
> Hmm.. that’s weird, do we have a ticket for that?

This was fixed in the new release of macports.

Mojca