Re: Python and python3

[Rainer Müller]

On 01/05/2024 23.17, ideal.cat9...@fastmail.com wrote:
> I’m relatively new to MacPorts, and I notice that the pythonX packages
> create a python but not python3 link. Is there a reason for that? Both
> the system python and other package managers use python3, and that’s a
> hard habit to switch after so many years, and I don’t want to
> accidentally use the wrong (in this case, system) python.

You can control both the python and python3 symlinks in the prefix with
the 'port select' action, for example:

  sudo port select --set python python312
  sudo port select --set python3 python312

Rainer

Re: bash prints errors for every non-existing command

[Rainer Müller]

On 24.04.24 18:33, Baerenblau via macports-users wrote:
I'm on macOS 14.4.1 (23E224) and continue to experience a long standing 
problem with bash from Macports


% which bash
/opt/local/bin/bash

% bash --version
GNU bash, Version 5.2.26(1)-release (x86_64-apple-darwin23.2.0)

For every command which is not found a error similar error like this is 
printed:


$ asdf
objc[1321]: +[__SwiftNativeNSStringBase initialize] may have been in 
progress in another thread when fork() was called.
objc[1321]: +[__SwiftNativeNSStringBase initialize] may have been in 
progress in another thread when fork() was called. We cannot safely call 
it or ignore it in the fork() child process. Crashing instead. Set a 
breakpoint on objc_initializeAfterForkError to debug.

Abort trap: 6

Xcode has been installed today. Then MacPorts has been updated to the 
latest version, machine is rebooted, issue continues to exist.


This is indeed a very long standing issue:
https://trac.macports.org/ticket/41248
https://trac.macports.org/ticket/68638

It appears that this crash is actually caused by gettext, when 
localizing the error message in the child process forked by bash.


Rainer

Re: XZ Utils Compromised Releases

[Rainer Müller]

On 29/03/2024 18.52, Blair Zajac wrote:
> In https://www.openwall.com/lists/oss-security/2024/03/29/4
>  it says
> 
> == Bug reports ==
> 
> Given the apparent upstream involvement I have not reported an upstream
> bug….
> 
> 
> I suggest not waiting for an upstream release and instead revert our
> commit and add an epoch line.

You are right. That is the best way as we cannot be sure what else just
has not been discovered in the backdoor-ed releases.

Joshua already pushed the downgrade to xz @5.4.6 with the epoch bumped.
Thank you!

https://trac.macports.org/ticket/69619
https://github.com/macports/macports-ports/commit/a1388aee09c9e921e3a9d47cf9d37e5d3f3c10ad

Rainer

Re: XZ Utils Compromised Releases

[Rainer Müller]

On 29/03/2024 18.40, Fred Wright wrote:
> 
> On Fri, 29 Mar 2024, Frank Dean wrote:
> 
>> I received a security announcement on the Debian mailing list [1].  It
>> appears versions 5.6.0 of XY Utils and later may be compromised.  I
>> also found a discussion on Openwall [2].
>>
>>
>> [1]:
>> https://lists.debian.org/debian-security-announce/2024/msg00057.html
>> 
>>
>> [2]: https://www.openwall.com/lists/oss-security/2024/03/29/4
>> 
>>
>>
>> I'm afraid that's all I know.  Just a heads-up.

Wow. That's an awful story.

The exploit seems to specifically target Linux systems only ("[...] it
is likely the backdoor can only work on glibc based systems.").

> In [1] they mention reverting to 5.4.5 to fix it.  It's not 100% clear
> from that whether 5.4.6 is affected, but it sounds like it's not.  Since
> MacPorts is currently at 5.4.6, the port is probably OK as long as it
> doesn't do any overzealous upgrading.

The xz port was updated to 5.6.1 just two days ago:
https://github.com/macports/macports-ports/commit/784e59f99e51adbadc663b1b689d66363adf193a

Based on the current information, the risk seems low for macOS system.
Should we still be cautious and revert to version 5.4.6 and bump the
epoch to force a downgrade for everyone? Or do we expect a new upstream
release soon to sort this out?

Rainer

Re: Questions on postfix

[Rainer Müller]

On 29/12/2023 15.28, Ubence Quevedo (thatrat) wrote:
> That’s just it, I am using mail from /opt/local/bin/:
> uquevedo@ubence-mini-wired ~ % which mail
> /opt/local/bin/mail
> 
> I shouldn’t have to use a specific executable if it’s attaching to a
> standard port for a running service…?
> 
> Unless there’s something configuration wise that I’m not seeing about
> what port the postfix from MacPorts is doing…?

mail(1) does not connect to port 25 or 587 by default, if you wanted to
imply that. Unless you configured it differently, /opt/local/bin/mail
might probably still use /usr/sbin/sendmail, but I am not sure about that.

Depending on your macOS version, it already ships with postfix. The
relevant sockets are already bound by launchd to run the macOS postfix
installation on-demand. You won't see any running daemon processes as it
is only activated by launchd on an incoming connection as configured in
the /System/Library/LaunchDaemons/com.apple.postfix.master.plist file.
There is no way to get rid of this postfix setup unless you disable
System Integrity Protection (SIP).

If your intention is just to set up a relay over an external SMTP
server, you could just use the macOS provided postfix. I described such
a setup on my personal blog a while ago with a specific setup that was
required for macOS 10.12 Sierra, but the general instructions should
still apply today:

https://raimue.blog/2018/03/22/postfix-with-relayhost-over-stunnel-on-macos-10-12-sierra/

Rainer

Re: Help with zef Portfile

[Rainer Müller]

On 25.11.23 16:07, Joshua Root wrote:
The default destroot phase builds a string to pass to 'system' by 
combining destroot.cmd, destroot.args, etc. In this case, it might be 
easiest to use those for the rakudo command, and create the symlinks in 
a post-destroot block?


Also note that all files have to be put into ${destroot} during the destroot 
phase. The files will afterwards be put into an archive from this ${destroot} 
and will only later be moved to the real ${prefix} when activating the port.

When moving these symlink commands to a post-destroot phase, these should look 
like this:

post-destroot {
ln -s "${prefix}/share/perl6/site/bin/zef"   "${destroot}${prefix}/bin/zef"
ln -s "${prefix}/share/perl6/site/bin/zef-m" 
"${destroot}${prefix}/bin/zef-m"
}

Rainer

Re: code signing and the future of MacPorts

[Rainer Müller]

Hello,

here is an older concept from 2016 I had written for gdb/lldb as Apple began to 
require code-signing for debuggers. This applies to more actions by now, but 
with the same requirements. The replies are also relevant and discuss 
alternatives.

https://lists.macports.org/pipermail/macports-dev/2016-September/033518.html

I still think adding a local private key to the trust store for code-signing at 
install/activation time is the only option. I do not see that code-signing 
binary archives created on the buildbots would be a feasible approach. This 
would essentially turn MacPorts into a binary-only distribution. Most parts are 
not ready for that and features like rev-upgrade rely on local rebuilds.

Rainer

Re: Failure Notice

[Rainer Müller]

On 10/03/2022 09.38, Ryan Schmidt wrote:
> On Mar 9, 2022, at 19:55, Lenore Horner wrote:
> 
>> Begin forwarded message:
>>
>>> From: mailer-dae...@yahoo.com
>>> Subject: Failure Notice
>>> Date: March 9, 2022 at 20:50:45 EST
>>> To: lenorehor...@sbcglobal.net
>>>
>>> Sorry, we were unable to deliver your message to the following address.
>>>
>>> :
>>> 554: 5.7.1 Service unavailable
> 
> I'm not sure why service was unavailable. Maybe there was a temporary server 
> problem. Clemens or Rainer would be the ones who could check the server logs 
> to find out. Obviously whatever problem existed no longer exists, since you 
> were able to send this next message.

Apparently the message was cut-off by yahoo. The full message returned
by our mail server included the real reason:

554 5.7.1 Service unavailable; Client host [66.163.189.87] blocked using
dnsbl.sorbs.net; Currently Sending Spam See:
http://www.sorbs.net/lookup.shtml?66.163.189.87; [...]

We rely on a few anti-spam blocklists such as SORBS to avoid accepting
mails from servers that are known to send spam. In this case, one of the
outgoing mail servers of Yahoo is currently listed there. Yahoo needs to
take action to get it removed from this list.

Sorry for the inconvenience that caused for you.

Rainer

Re: Failed to build graphviz

[Rainer Müller]

Hello Greg,

On 10/02/2022 13.12, Greg Bell wrote:
> I'm trying to update yt-dlp (a youtube-dl fork with additional features and 
> fixes)
> 
> and incurred this…
> Error: Failed to build graphviz: command execution failed
> 
> I'm unsure how to interpret the log.
> Log output attached in zipped folder.

The most relevant error message from the log is this one:

:info:build
/opt/local/libexec/llvm-11/bin/../include/c++/v1/__bit_reference:172:38:
error: no member named 'min' in namespace 'std::__1'

There is already a ticket which describes the same problem for graphviz:
https://trac.macports.org/ticket/60962

> Running OS X 10.6.8 (my maximum OS for 2 GHz Intel Core 2 Duo)

That is a very old system... I honestly do not know the state of
libstdc++ vs. libc++ these days on legacy systems, but could it be some
mismatch between the two C++ runtime libraries?

Rainer

Re: New ports.macports.org website

[Rainer Müller]

On July 20, 2021 1:15:50 AM GMT+02:00, Saagar Jha  wrote:
>This looks awesome! We had some discussion earlier of what kinds of
>things we should be posting to social media, and I think major new
>redesigns and efforts at modernization are a great thing to highlight.
>I’d suggest posting this to Twitter, or I could figure out how to do
>that too if you want.

I posted this on Twitter here:
 https://twitter.com/macports/status/1417603005134905350

We could still need a more detailed post on the news section of the website. 
Any volunteers for a draft? Please submit a pull request here:

https://github.com/macports/macports.github.io

Rainer

Re: Why don't p5-* ports mark their dependencies?

[Rainer Müller]

On 12/06/2021 18.32, Bill Cole wrote:
> On 2021-06-12 at 12:11:47 UTC-0400 (Sat, 12 Jun 2021 09:11:47 -0700)
> Kastus Shchuka 
> is rumored to have said:
> 
>> I wish it could be so easy to remove perl5.28. Apparently, I have to
>> keep it because of git:
> 
> port uninstall git
> port install git -perl5_28 +perl5_30

sudo port upgrade --enforce-variants git -perl5_28 +perl5_30

https://guide.macports.org/#using.port.upgrade

Rainer

Re: Binary archive for mpich-default is available but not used

[Rainer Müller]

On 24/04/2021 10.42, Davide Liessi wrote:

I'm trying to install mpich-default with default variants on macOS 10.13.6.
The package is available at http://packages.macports.org/mpich-default/
but port is refusing to install from the prebuilt binary.

$ sudo port -b install mpich-default
--->  Computing dependencies for mpich-default
Error: Failed to archivefetch mpich-default: Binary-only mode
requested with no usable archive sites configured
Error: See 
/opt/local/var/macports/logs/_opt_macports-git_macports-ports_science_mpich/mpich-default/main.log
for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port mpich-default failed

main.log attached, but I cannot see anything meaningful in there with
respect to this problem.

I have just updated many other ports in binary-only mode without any problems.
Any ideas?


The mpich-default port clears the archive_sites which will prevent the lookup of 
binary archives for download. That is why no download attempt is in the provided 
log excerpt. The buildbots are not aware of this and will publish these archives 
after building, but they will never be found.


https://github.com/macports/macports-ports/blob/7541d508815705d370fbe619b3a407e30963edf1/science/mpich/Portfile#L223

Rainer

Re: Forcing python39 on M1

[Rainer Müller]

On 12/03/2021 12.16, Peter West wrote:
>> I ran intoa brick wall with gexiv2, which was because the g-ir-* python files
>> were specifying python38. I tried building gobject-introspection with 39, but
>> fails. I don’t know whether I can classify this as a bug and make a report. 
>> In
>> any case, has anyone else been tinkering with python39 builds on M1?
> :info:build g-ir-scanner: GLib: warning: 627 warnings suppressed (use 
> --warn-all
> to see them)
> :info:build Traceback (most recent call last):
> :info:build   File
> "/opt/local/var/macports/build/_Users_pbw_Software_ports_gnome_gobject-introspection/gobject-introspection/work/gobject-introspection-1.60.2/./g-ir-scanner",
> line 99, in 
> :info:build     sys.exit(scanner_main(sys.argv))
> :info:build   File "./giscanner/scannermain.py", line 615, in scanner_main
> :info:build     write_output(data, options)
> :info:build   File "./giscanner/scannermain.py", line 469, in write_output
> :info:build     passthrough_gir(main_f_name, temp_f)
> :info:build   File "./giscanner/scannermain.py", line 260, in passthrough_gir
> :info:build     parser.parse(path)
> :info:build   File "./giscanner/girparser.py", line 60, in parse
> :info:build     self.parse_tree(tree)
> :info:build   File "./giscanner/girparser.py", line 69, in parse_tree
> :info:build     self._parse_api(tree.getroot())
> :info:build   File "./giscanner/girparser.py", line 106, in _parse_api
> :info:build     for node in root.getchildren():
> :info:build AttributeError: 'xml.etree.ElementTree.Element' object has no
> attribute 'getchildren'

This specific method had been deprecated for a while and was eventually removed
in Python 3.9. It is a known problem at upstream that has already been fixed.
The fix would be included in gobject-introspection >= 1.65.0

https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/325

Your best option would be to also bump the port version to get a version
compatible with Python 3.9.

Rainer

Re: migration hickup

[Rainer Müller]

On 08/03/2021 17.44, joerg van den hoff wrote:
> Now, after the data transfer completed, on the new machine I do have a
> (seemingly/so far) working Macports installation: Migration Assistant actually
> transferred the stuff in /opt, too.
> 
> BUT, when now trying to selfupdate on the new machine, I get the 
> message/warning:
> 
> Warning: Failed to copy com.apple.dt.Xcode.plist to
> /opt/local/var/macports/home/Library/Preferences: could not set owner for file
> "/opt/local/var/macports/home/Library/Preferences/com.apple.dt.Xcode.plist":
> user "macports" does not exist
> 
> although `finger macports' reports for the new machine that the user is known
> 
> Login: macports   Name: MacPorts
> Directory: /opt/local/var/macports/home    Shell: /usr/bin/false
> Never logged in.
> No Mail.
> No Plan.
> 
> as does `id macports'.
> 
> what am I missing?

I am not sure, but it might be that the message shown above is a bit inaccurate
and it is the "macports" group that is missing?

Please check that the user and group do exist for dscl (Directory Services):

  dscl . -read /Users/macports
  dscl . -read /Groups/macports

In any case, running the MacPorts install either from the .dmg or from source
once again should recreate both the user and group named "macports".

Rainer

Re: Apple notarisation process - LC_VERSION_MIN_MACOSX

[Rainer Müller]

On 05/03/2021 04.43, Ken Cunningham wrote:
> Apple is not using LC_VERSION_MIN_MACOSX any longer, as at least one helpful
> person pointed out. So — we will never “fix” the problem of this not being
> added, as it is — gone, it appears.
> 
> See https://developer.apple.com/forums/thread/127450
>  and other links.

There was a separate load command for the minimum version of each platform:
 - LC_VERSION_MIN_MACOSX
 - LC_VERSION_MIN_IPHONEOS
 - LC_VERSION_MIN_WATCHOS
 - LC_VERSION_MIN_TVOS
They have been replaced with LC_BUILD_VERSION, which encodes both the platform
and the minimum required version.

If your binary does not have LC_VERSION_MIN_MACOSX, it will have
LC_BUILD_VERSION instead. This is the same information, just encoded
differently. You should be able to decode this with `otool -l`.

Rainer

Re: ARM gdb compilation fails with implicit function declaration error ioctl

[Rainer Müller]

On 19/02/2021 22.14, Dave Horsfall wrote:
> On Fri, 19 Feb 2021, Ryan Schmidt wrote:
> 
> [...]
> 
>> As I said in my previous message from December:
>>
>> * Don't forget to Reply All so the conversation stays on the list.
> 
> Better still, set the reply to the list only?  I have a beef with "Reply
> All" because I don't need my own personal copy.

You can disable the extra copy in your personal mailman preferences by disabling
duplicates. Mailman will then no longer send you a copy when your mail address
was already listed in To or CC.

https://www.list.org/mailman-member/node21.html

Rainer

Re: Build servers going offline due to inclement weather

[Rainer Müller]

Hello Ryan,

On 19/02/2021 16.38, Ryan Schmidt wrote:
> Build servers remain offline. Since my last update, power was out here for 32 
> hours but is back on now. Power is restored in most of Austin but the Texas 
> electric grid operator still asks us to conserve electricity.

Thank you for the update. I hope you are well and stay warm!

Rainer

Re: MacPorts bash on Big Sur as default shell

[Rainer Müller]

On 10/02/2021 22.35, Mike Summers via macports-users wrote:
> I'm not able to get MacPorts bash working in Terminal as the default shell.
> 
> This is fresh install of Big Sur 11.2 on a new machine, fresh install of
> MacPorts. Only bash and bash-autocomplete are installed
> 
> Setting the shell in either the Terminal preferences or for my user to
> /opt/local/bin/bash always leaves me in /bin/bash 

Make sure you use the correct command to lauch in the Terminal preferences.
See here for the details:

https://trac.macports.org/wiki/howto/bash-completion#Terminal.app

> The "best" workaround so far is to start in zsh which has the PATH set 
> correctly
> and exec bash from there.

The MacPorts installer only added PATH to the login shell of your user account.
For zsh, you can find the addition the .zprofile file in your home directory.

If you want to use a different shell, you need to make sure to configure PATH
for that shell. For bash that means you need to configure it in your
.bash_profile accordingly.

https://guide.macports.org/chunked/installing.shell.html#installing.shell.postflight

> My old machine where has been through many upgrades including Big Sur "just 
> works", 
> 
> I've run out of ideas, I'd appreciate pointers.

Those older machines may already have the PATH settings in .bash_profile,
because you most probably installed MacPorts while bash was the login shell.

Rainer

Re: Access to workdir on the build server?

[Rainer Müller]

Hello Janosch,

thank you for contributing these ports for MacPass!

I think this topic would have been better on the macports-dev@ mailing list, as
it reaches more developers that can help with writing Portfiles.

On 10/02/2021 13.44, Janosch Peters via macports-users wrote:
> I am currently investigating a build failure of the new port keepasskit
> .

First of all, this port must be updated with a proper versioning scheme. You
cannot use the git commit hash, because the version must have a defined sort
order. Hashes are "arbitrary" values and with just two hashes, there is no way
to tell which one is newer. This is important as with the current versioning
scheme the port might never show up as outdated. The port would only be upgraded
if the next hash happens to be sorted alphabetically after the current one.

Normally tagged releases should be preferred, but apparently there are no recent
tags that are suitable for MacPass and KeePassKit.

For repositories without tags, a common option would be to use the date of the
commit in MMDD format. Or if this will return to "normal" version numbers at
some point, start from the last tagged release 2.4.7 and add an increment as a
suffix, such as 2.4.7-snapshotMMDD or similar.

https://guide.macports.org/#reference.portgroup.github.distfile

To correct this you will also have to increment the 'epoch' of the port, as that
is the only way to ensure the new version number format will upgrade all
existing installation.

> The problem only occurs on the build server, not on my local machine:
> 
> Error: Failed to extract keepasskit: error renaming
> "/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_security_keepasskit/keepasskit/work/phc-winner-argon2-b31aa322566a8559403d419b2e9cd3f57957e394"
> to
> "/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_security_keepasskit/keepasskit/work/keepasskit-76e6ecda942f9e328efde7883ad75aed7290b632/Argon2":
> no such file or directory
> 
> The full logfile is here:
> https://build.macports.org/builders/ports-11_x86_64-builder/builds/19836/steps/install-port/logs/stdio
> 
> Is there a way to inspect the workdir on the build server? I have a suspicion
> that this is a problem with case-sensitiveness but to be sure I would need to
> inspect the workdir.

Your suspicion is correct, all buildbots run on case-sensitive filesystems.
Direct access is not possible and it is wiped directly after the build as disk
space is a rare resource for this setup.

You can already see it when inspecting the tarball directly:

$ tar tf 76e6ecda942f9e328efde7883ad75aed7290b632.tar.gz
KeePassKit-76e6ecda942f9e328efde7883ad75aed7290b632/
...

I am not sure if there is a canonical way to solve this with the github port
group, but I think it could work to set the worksrcdir with the right
capitalization:

worksrcdirKeePassKit-${version}

Rainer

Mails rejected today due to SpamCop blocklist

[Rainer Müller]

Hello,

there was a problem with our mail server today. Any mail handled today may have
been rejected in error due to a problem at the SpamCop blocklist. Their domain
name expired, which had the effect that all sending IPs were blocked.

For mailing list posts sent today, please look for any bounce message or double
check with the mailing list archive that it has been received. Direct replies in
threads going to other mail servers succeeded, which is why some replies of
today might have missing context.

Also be aware that you might have missed notifications from GitHub if they go to
your @macports.org address.

Sorry for the inconvenience. We temporarily disabled this blocklist, so as of
now no problems should occur. Please contact us on IRC or RocketChat [1] if you
still have problems.

Rainer

[1] https://trac.macports.org/wiki/Chat

Re: how use bash 5.0 port

[Rainer Müller]

On 31/08/2020 18.32, Murray Eisenberg wrote:
> So then I successfully installed the MacPorts port bash @5.0.17_0.
> 
> —> But how do I make this bash 5.0 my shell when I open Terminal?

It's a bit hard to find, but this wiki page has instructions for both
Terminal.app and iTerm2:

https://trac.macports.org/wiki/howto/bash-completion#Step3:UsebashfromMacPortsinyourterminal

Rainer

Re: macports-users Digest, Vol 166, Issue 6

[Rainer Müller]

On 17/06/2020 02.08, Thomas Bodlien wrote:
> I have set region to german and language to us english.
> Macports installs everything in german
> How can I fix this?

You are likely hit by this bug in gettext, which causes it to select the wrong
language for messages:
https://savannah.gnu.org/bugs/index.php?49560

This will be fixed with gettext 0.20.x for which the update is currently still a
work in progress:
https://trac.macports.org/ticket/58526

Until then, the only workaround is to explicitly select the language by
exporting the locale variables LANG and LC_ALL in the environment, which should
override the language preferences set in the macOS settings.

For example, add this to your shell startup file:

  export LANG="en_US.UTF-8"
  export LC_ALL="en_US.UTF-8"

Rainer

Re: Scheduled downtime on Jun 11, 8 UTC

[Rainer Müller]

On 08/06/2020 20.03, Rainer Müller wrote:
> it has been a while since we did a full operating system upgrade on our server
> braeburn.macports.org, which provides most of our self-hosted services. We are
> taking the opportunity to do so this Thursday. As the duration is hard to
> predict, the end date is a conservative estimation.
> 
> Start: 2020-06-11 08:00:00 UTC
> End:   2020-06-11 16:00:00 UTC (expected)
> 
> You can convert the event to your local timezone here:
> https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200611T08
> 
> This will affect the website and guide at macports.org, Trac, the mailing 
> lists,
> mail forwards and the PR bot automation including log file storage from 
> Travis.
> 
> GitHub can be used as usual, but any WebHook sent from GitHub to Trac during 
> the
> downtime will fail and will have to be re-triggered manually once the system 
> is
> online again. 'port selfupdate' and port updates in general will not be 
> affected
> and will work as usual.

The maintenance is now finished. Website and guide were actually available the
whole time via the CDN. As you can read this, mailing lists and mail forwards
are also back again.

Trac is now deployed with a new threading workers approach based on gunicorn
that should hopefully improve performance and reduce memory usage. Please report
back if you get any errors or timeouts.

Rainer

Scheduled downtime on Jun 11, 8 UTC

[Rainer Müller]

Hello,

it has been a while since we did a full operating system upgrade on our server
braeburn.macports.org, which provides most of our self-hosted services. We are
taking the opportunity to do so this Thursday. As the duration is hard to
predict, the end date is a conservative estimation.

Start: 2020-06-11 08:00:00 UTC
End:   2020-06-11 16:00:00 UTC (expected)

You can convert the event to your local timezone here:
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200611T08

This will affect the website and guide at macports.org, Trac, the mailing lists,
mail forwards and the PR bot automation including log file storage from Travis.

GitHub can be used as usual, but any WebHook sent from GitHub to Trac during the
downtime will fail and will have to be re-triggered manually once the system is
online again. 'port selfupdate' and port updates in general will not be affected
and will work as usual.

As the mailing lists and mail forwards are going to be down, you can still reach
us on IRC in #macports on Freenode or via RocketChat at chat.macports.org during
the downtime.

Rainer

Re: macports localinstall github tries to download from macports

[Rainer Müller]

On 28/04/2020 06.02, Ryan Schmidt wrote:
> 
> 
> On Apr 27, 2020, at 14:15, macpo...@parvis.nl wrote:
> 
>> i’m trying to do a macports localinstall portgroup github for downtimed but 
>> it downloads from macports.org, not github.com.
> 
> It attempts to download from all locations, including GitHub and the MacPorts 
> mirrors. The file isn't on any of them because you've specified the wrong 
> values to github.setup.

For testing during development of new ports or updates, you can skip the mirrors
by using the following flag for the fetch action:

  $ sudo port fetch --no-mirrors

Note that this is a local flag that only works with fetch and cannot be
specified when the fetch phase is run as a dependency for any other action such
as checksum, build, or install.

Rainer

Re: Problem with uninstall instructions

[Rainer Müller]

On 27.02.20 00:50, k...@cornell.edu wrote:
> I am using the uninstall instructions given here:
> 
> https://guide.macports.org/chunked/installing.macports.uninstalling.html
> 
> I got as far as this command:
> 
> $ dscl -p . -delete /Users/macports
> 
> 
> After I typed in my password, it responded:
> 
> Data source (.) is not valid.
> 
> I am using macOS 10.13.6 (my hardware allows no higher version, and my
> finances allow no higher hardware).
> 
> What should I do?

I can reproduce the problem and 'dscl -p .' does not work for me either.
Therefore I replaced the command with 'sudo dscl .' instead.

https://github.com/macports/macports-guide/commit/5aa58c602c4a0a38965c497f17b7b474a347ad94

Rainer

Re: Dovecot port changes

[Rainer Müller]

On 22.02.20 12:41, Gerben Wierda wrote:
> port dovecot is now installing dovecot 2
> port dovecot2 is now installing dovecot 1

No, there is no Dovecot 1.x i the ports tree any more.

dovecot2 is a port that has been marked as replaced_by dovecot. As the
epoch was increased, it will be considered more recent than the old 2.x
version, although it reads 1.x. I agree this might be a bit confusing,
but it should work as intended.

This is the usual way port removal or renames are handled and eventually
the dovecot port will be removed completely as already noted in the
Portfile.

Rainer

Re: MacPorts' VLC cannot stream to my Chromecast

[Rainer Müller]

On 17/08/2019 10.05, Andrew Udvare wrote:
> Site seems to be down?
> 
>  $ ping -4 trac.macports.org
> PING braeburn.macports.org (136.243.18.213) 56(84) bytes of data.
> --- braeburn.macports.org ping statistics ---
> 2 packets transmitted, 0 received, 100% packet loss, time 21ms

Please see this mail for information about the outage:
https://lists.macports.org/pipermail/macports-dev/2019-August/040984.html

Sorry, I had not added macports-users to CC as I did not think this affected
users much.

Rainer

Re: What am I forgetting?

[Rainer Müller]

On 14/08/2019 15.12, Ryan Schmidt wrote:
> 
> 
> On Aug 12, 2019, at 20:22, Mojca Miklavec wrote:
> 
>> If not, "sudo port install" or "sudo port upgrade" (without port name)
> 
> `port upgrade` will always find the port in the default tree. It will not 
> find the port in the local directory. So you don't want to use `port upgrade` 
> in this case. We've discussed this surprising behavior before...

Indeed, this is one of the oldest tickets. However, it is still stuck in the
design phase to define what the behavior should be...

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

Rainer

Re: [MacPorts-announce] MacPorts 2.5.4 has been released

[Rainer Müller]

Hello Al,

On 08.06.19 11:01, Al Varnell via macports-users wrote:
> Still confused about why this issue is being ignored.
> 
> You still list USA, Seattle as a viable mirror on
> .
> 
> I went to some trouble tracking down those responsible for it and passed
> the information that I received back on to you, but nothing has been done.
> 
> The server still responds to pings but has not been updated so either
> improperly decommissioned or simply not being maintained.
> 
> If you still feel the need to have this mirror, I will be glad to push
> back to them on their failure to properly decommission or maintain, just
> let me know.
> 
> I've moved on to USA, Austin (thanks for obtaining a USA based
> alternative), so it's immaterial to me, but not really fair to other
> users to continue to list it as a MacPorts mirror, IMHO.

Thank you for keeping track of this!

I created a ticket in Trac as a central point to track the issue:
https://trac.macports.org/ticket/58580

I fully agree with your assessment of the situation and have already
removed sea.us.* as a mirror for distfiles and packages. It is also no
longer listed on the wiki page.

I have not yet removed the DNS records in order not to immediately break
downloads for those that still have it listed in their ports tree, but
will follow through with this later.

Rainer

Re: Necessary library is a leaf for unknown reason

[Rainer Müller]

On 10.03.19 09:54, Andrew Udvare wrote:
>  $ port info mas
> mas @1.6.2 (sysutils, aqua)
> Variants: universal
> 
> Description:  Mac App Store command line interface.
> Homepage: https://github.com/mas-cli/mas
> 
> Library Dependencies: Commandant, Result
> Platforms:macosx
> License:  MIT
> Maintainers:  none
> 
> I thought library dependencies never get removed until the dependent package 
> is removed, and as long as they are not requested. In my case, mas is 
> requested so I expect all its library dependencies to remain.

Correct, that would be expected behavior.

It is not entirely clear to me whether this exact version of the mas
Portfile was installed? The dependency information for calculation of
leaves is always taken from the registry and not from the Portfile in
the ports tree.

Rainer

Re: port reclaim exclude build dependencies

[Rainer Müller]

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.

You could still end up in a situation where you would keep the build
dependencies based on the ports tree, but still uninstall a possibly new
library dependency based on the registry information, because it was not
in use by any other installed port. I doubt this will ever become a
perfect solution with MacPorts being this hybrid between source and
binary installation methods.

Rainer

Re: Failed to build Bitkeeper

[Rainer Müller]

On 06.01.19 22:34, Bill Cole wrote:
> On 6 Jan 2019, at 15:56, Dave Horsfall wrote:
> 
>> Odd...
>>
>>     ozzie:~ dave# port upgrade -p outdated
>>     --->  Computing dependencies for bitkeeper
>>     --->  Staging bitkeeper into destroot
>>     --->  Installing bitkeeper @7.3.3_0
>>     --->  Cleaning bitkeeper
>>     --->  Computing dependencies for bitkeeper
>>     --->  Deactivating bitkeeper @7.3.2_1
>>     --->  Cleaning bitkeeper
>>     --->  Activating bitkeeper @7.3.3_0
>>     --->  Cleaning bitkeeper
>>
>> Huh?  Did the "-p" flag really make that difference?
> 
> I would expect it to. That flag tells 'port' to ignore the failure in
> the 'destroot' stage of installation and proceed to archiving the
> (presumably bad) staged package and installing it from the somehow bad
> destroot directory.

No, that is not correct. The -p flag makes the port command to proceed
with the next port, but it does not override errors in a phase.

I assume the destroot.cmd worked on the second execution for whatever
reason. Maybe the dependencies within the BitKeeper build system are not
correct, causing it to assume this already succeeded previously...?

> I would NOT expect Bitkeeper to work. I would also expect 'port contents
> bitkeeper' to show less than the necessary compliment of files.

That would be a good assumption, it is most probably missing some files.

Rainer

Scheduled downtime on Dec 14

[Rainer Müller]

Hello,

due to maintenance on the network in the data center where our server is
hosted, there will be a 20-minute disconnection in the time frame given
below.

Start:  2018-12-14 03:00:00 UTC
End:2018-12-14 05:00:00 UTC (expected)

This will mostly affect the website, Trac, and the mailing lists. GitHub
can be used as usual, but any WebHook sent from GitHub to Trac during
the downtime will fail and will have to be re-triggered manually once
the system is online again.

Rainer

Security Issues using Homebrew or Macports, malicious binary insertion

[Rainer Müller]

On 06.11.18 23:29, Nicholas Papadonis wrote:
> Do you know anything about the process to integrate new source code,
> review changes that are Mac specific, mark branches stable, build and
> release?  Do particular users have privileged access to be part of this
> process?

There are no special privileges with regard to any part of the ports
tree or base development. All project members have the same access
level. Things that are only handled by the infrastructure team would be
server administration and ownership of the GitHub project.

Code review happens over pull requests on GitHub and also the mailing
list macports-changes [1], where all commits to base and ports are
announced. Note there are only a handful of regular base developers.

Creation of new base branches is usually announces on the macports-dev
mailing list. For new 2.x.0 releases, we usually have several release
candidates first, for which everyone should feel invited to test the
changes.

> I suspect this is an issue with any open source project, however am
> curious how MacPorts itself ensures the code from the project makes it
> to release as original as possible.  I hope these are the right
> questions to ask form a security standpoint.

Hm, I do not think there is anything special in place. Whoever signs a
MacPorts base release has also built the binaries. We have to trust the
release builder in the same way any user that receives such a package
installer has to trust them.

Rainer

[1] https://lists.macports.org/mailman/listinfo/macports-changes
[2] https://lists.macports.org/mailman/listinfo/macports-dev

Re: What's the difference between macports docker port and docker.com's docker?

[Rainer Müller]

On 02.11.18 19:25, Carlo Tambuatco wrote:
> Macports docker port, aka The Moby project...is upstream of the official
> Docker, so...
> 
> I guess I'm asking is there anything Docker can do that macports docker
> can't do?

Not sure I understand the question, because for every software that
MacPorts provides there is an upstream project. MacPorts is merely
packaging software developed by the corresponding upstream projects.

If the software in question is completely open source, the software
distributed in MacPorts will usually offer exactly the same
functionality as distributed elsewhere.

Rainer

Re: how make python37 the binary called by "python"

[Rainer Müller]

On 2018-10-29 21:05, Murray Eisenberg wrote:
> After
> 
> sudo port select --set python python37
>    Selecting 'python37' for 'python' succeeded. 'python37' is now active.
> I have:
> 
> port select --list python
>    Available versions for python:
>    none
>    python27
>    python27-apple
> python37 (active)
>    
> Nonetheless:
> 
> which python
>    /opt/local/bin/python
> python --version
>    Python 2.7.3
> 
> And how do I get the version invoked by “python” at command line to be 3.7?

Your shell cached "python" to mean "/usr/bin/python". It is not
evaluating the full PATH on every command invocation as it would be
quite slow to walk the filesystem every time.

This cache will not be updated unless you tell your shell to do so.
Either run 'hash -r' or close and reopen your terminal window.

Rainer

Re: rsyncd with macports 2.5.4 on macOS 10.13.6

[Rainer Müller]

On 2018-10-24 16:51, Kevin Layer wrote:
> When I installed rsync, I executed the command that was suggested by
> the port command.  I forget what it was.

Probably that was the usual 'sudo port load rsync'.

> After a reboot, every 30 seconds, I see this in /var/log/system.log:
> 
> com.apple.xpc.launchd[1] (org.macports.rsyncd[1044]): Service exited with 
> abnormal code: 2

That means the rsyncd process exited with an error. You need to look at
the error messages to find out why.

Try this command to capture the output:
sudo launchctl debug system/org.macports.rsync --stdout --stderr

Rainer

Re: git stash problem with `port sync'

[Rainer Müller]

On 2018-09-15 12:49, Werner LEMBERG wrote:
> after doing various network hacks, calling `port -d sync' now fails.
> 
>   --->  Updating the ports tree
>   Synchronizing local ports tree from file:///opt/macports/macports-ports
>   DEBUG: /opt/local/bin/git pull --rebase --autostash
>   DEBUG: system -W /opt/macports/macports-ports: /opt/local/bin/git pull 
> --rebase --autostash

MacPorts automatically switches to the user owning the top-level ports
tree directory to run the 'git pull'. Make sure this directory belongs
to your user or apply the appropriate configuration to the owner
(probably root?).

Rainer

Re: Distfiles mirroring not working

[Rainer Müller]

On 2018-08-01 09:03, Davide Liessi wrote:
> Apparently the distfiles mirroring is not working properly.
> See, e.g., the ports appstream-glib and gcab, missing versions 0.7.10
> and 1.1, respectively:
> http://distfiles.macports.org/appstream-glib/
> http://distfiles.macports.org/gcab/
> However, the buildbot reports success, if I understand correctly:
> https://build.macports.org/builders/jobs-mirror/builds/30942

It may take a few hours before a file mirrored on build.macports.org is
actually transferred to and served from distfiles.macports.org.

The distfiles for the mentioned port versions seem to be available by now.

Rainer

Re: verbose builds

[Rainer Müller]

On 2018-07-25 07:21, Jan Stary wrote:
> In a recent thread, I came over the folowing:
> 
> On Jul 24 09:26:18, h...@stare.cz wrote:
>> On Jul 23 15:51:49, michae...@macports.org wrote:
>>> Looks like the link command is missing LAPACK or the equivalent (e.g. 
>>> maybe: Atlas, OpenBLAS, Eigen), but since the log doesn't include the 
>>> actual link command I can't say for certain. Maybe add some verbosity to 
>>> the build stage to show the actual link command? - MLD
>>
>> How do I do that on port(1) level?
>> Or do I need to tweak the actual Portfile with
>> something like --disable-silent-rules?
> 
> On Jul 24 11:17:18, michae...@macports.org wrote:
>> This would be a Portfile change, adding in the flag you mention.
>> ---enable-static
>> +--enable-static \
>> +--disable-silent-rules
> 
> Would it be useful if port(1) had --disable-silent-rules
> among configure.args by default? Or at least with port -vs?
> Not having the actual commands renders the main.log a bit useless.

Yes, --disable-silent-rules should be used whenever possible. However,
only configure scripts using automake will provide that option. Other
configure scripts might also fail when unknown options are passed on the
command line. Therefore I do not think it is not possible to make it a
default.

The -v flag should not change the build process. It only changes what is
displayed right on the terminal, while the log file will always contain
messages of all log levels. Use 'port log' [1] to view/filter the log
output after a failed build attempt.

Rainer

[1] https://man.macports.org/port-log.1.html

Re: vnc

[Rainer Müller]

On 2018-07-24 07:55, James wrote:
> For ages I have used Chicken but High Sierra warns me of it being a 32bit app.
> macports has cotvnc and also vnc
> Any opinions sage words or other

Usually I use the builtin VNC client of macOS. You can launch it by
opening a vnc:// URL from Finder's "Connect to Server" dialog or with
open(1) from a terminal window, for example:

  open vnc://hostname:5190

Hope that helps,
Rainer

PS: Please use the new @lists.macports.org addresses as we are no longer
on macOS Forge.

Re: Cannot uninstall local port with invalid version number

[Rainer Müller]

On 2018-07-20 21:32, Ryan Schmidt wrote:
>> Where is this registry anyway?
> 
> You're not meant to modify this file manually, but the registry is an SQLite 
> 3 database located at:
> 
> /opt/local/var/macports/registry/registry.db 
> 
> If you wish to examine or manipulate the database, you will need to load the 
> MacPorts SQLite extension into your SQLite client. I don't remember how to do 
> that but it's been discussed on the list before; you can search the archives.

It is documented in the source code here:

https://github.com/macports/macports-base/blob/master/src/cregistry/README.sqlext

Rainer

Re: PATH not searched properly for gcc version

[Rainer Müller]

On 2018-07-03 21:15, Ryan Schmidt wrote:
> 
> On Jul 3, 2018, at 12:40, Rainer Müller wrote:
> 
>> On 2018-07-03 19:02, Turner, Adrian Keith wrote:
>>> Also, interesting are the results of which and whereis:
>>> which gcc
>>> /opt/local/bin/gcc
>>> whereis gcc
>>> /usr/bin/gcc
>>
>> That is normal, whereis does not respect PATH.
>>
>>> How do I make my system find the correct version of gcc without
>>> specifying the full path?
>>
>> Your shell has probably cached the location of the gcc binary from
>> earlier before you created the symlink with 'port select'. Just open a
>> new terminal window or execute 'hash -r' to clear the cache.
> 
> Adrian didn't say he had used 'port select'. If he hasn't, that's the first 
> thing he should do, if he wants to be able to use gcc 7.3 as "gcc".

Nothing else would provide /opt/local/bin/gcc, so I assumed he used that...

Rainer

Re: PATH not searched properly for gcc version

[Rainer Müller]

On 2018-07-03 19:02, Turner, Adrian Keith wrote:
> Also, interesting are the results of which and whereis:
> which gcc
> /opt/local/bin/gcc
> whereis gcc
> /usr/bin/gcc

That is normal, whereis does not respect PATH.

> How do I make my system find the correct version of gcc without
> specifying the full path?

Your shell has probably cached the location of the gcc binary from
earlier before you created the symlink with 'port select'. Just open a
new terminal window or execute 'hash -r' to clear the cache.

Rainer

Re: smartctl - Can't run select span range

[Rainer Müller]

On 2018-06-29 10:03, Ryan Schmidt wrote:
> 
> On Jun 28, 2018, at 19:43, Ubence Quevedo wrote:
> 
>> I gave caffeinate a try, and set my system sleep time to a more reasonable 
>> timeout [30 minutes], but since smartctl isn't an interactive process [a 
>> tsr?], the system never stays awake long enough to finish a whole test.  I 
>> even added the -m option to prevent the disk from idle sleeping but that 
>> didn't help.
> 
> Oh, right. As I recall, smartctl exits immediately, and the test occurs on 
> the disk in the background, and you later run smartctl again to get the 
> result.
> 
> In that case, you can run smartctl normally, and then caffeinate a sleep 
> command that takes at least as long as the test. For example, if the test 
> will take 206 minutes, you could sleep for 207 minutes (12,420 seconds):
> 
> caffeinate -i sleep 12420
> 
> ("sleep" in this context means "wait this many seconds").

You can just start caffeinate without any arguments in a separate
terminal window to prevent the system from sleeping until you kill the
process (with Ctrl-C).

Rainer

Re: Odd mpv configure series failure following fresh reinstall

[Rainer Müller]

On 2018-06-20 03:19, Lee Bast wrote:
>   Just wanted to give a small follow up: in the end I think the mpv port 
> is just entirely broken for me. I kept trying things until I ended up doing a 
> total fresh install again following updating to Xcode 9.4. Starting entirely 
> from scratch and just doing a plain "port install mpv" with no variants or 
> anything else installed first I still get the exact same error where 
> configure fails on
> 
>> :info:configure Checking for Lua 
>>  : no ('lua-5.2 >= 5.2.0' not found) 

Just checking, is the lua52 port installed and active?

$ port installed lua52
The following ports are currently installed:
  lua52 @5.2.4_1 (active)

> It looks like MacPorts' mpv is about a year old now so it might just be 
> related to age, and since ticket #54867 is already accepted for updating it 
> at some point I'm not sure if there is any point in opening a new ticket 
> until that's done. Once it's updated maybe that'll resolve it by itself. 
> Although Ken indicated it built, so yeah, not really sure what else to try if 
> a clean install fails as the first port, although I'd be happy to give it a 
> shot if there are suggestions.
> 
> Fresh install log but nothing particularly interesting I think. Also thanks 
> again for your earlier reply Ken!

The problem can probably only be debugged further by looking into
config.log, which contains the details how and where mpv expected to
find Lua. Use this command to find this file after the failed build attempt:

$ find $(port work mpv) -name config.log

Also, to make another guess on what is going on, what is the result of
the following command on your system?

$ pkg-config --libs --cflags lua-5.2
-I/opt/local/include/lua-5.2 -L/opt/local/lib/lua-5.2 -llua-5.2 -lm

Rainer

Re: Help with a local port file -- compiling

[Rainer Müller]

On 2018-06-17 01:47, Michael wrote:
> How do I force port to compile a port when I have a local port file?
> 
> If I say "port build git", it will build with my local port file, and local 
> patches.
> 
> Unfortunately, I cannot figure out how to make it install this.

If you already have the port installed with the exact same combination
of name/version/revision/epoch, it will not be rebuilt from source.

You will either have to increase the revision in the Portfile or
uninstall the version you already have installed.

Rainer

Re: Help with Perl email

[Rainer Müller]

On 2018-06-16 08:26, Michael wrote:
> I'm trying to use git send-email, and I got this error message out at the end:
> 
> Send this email? ([y]es|[n]o|[q]uit|[a]ll): y
> Can't locate Net/SMTP/SSL.pm in @INC (@INC contains: 
> /opt/local/lib/perl5/site_perl/5.16.2/darwin-thread-multi-2level [...]

Are you really still using perl5.16? The git port currently depends on
perl5.26, so your installation seems to be out of date.

$ port -q installed git perl5.26
  git @2.17.1_0+credential_osxkeychain+doc+pcre+perl5_26+svn (active)
  perl5.26 @5.26.2_0+universal (active)

$ port provides /opt/local/lib/perl5/vendor_perl/5.26/Net/SMTP/SSL.pm
/opt/local/lib/perl5/vendor_perl/5.26/Net/SMTP/SSL.pm is provided by:
p5.26-net-smtp-ssl

HTH,
Rainer

Re: Advice on distributing a project

[Rainer Müller]

On 2018-06-13 21:37, Langer, Stephen A. (Fed) wrote:
>  (2) Package all of the compiled libraries and dependencies into a Mac-like 
> app and distribute binaries, but not a portfile.  Will "port pkg"  do this if 
> I write a portfile for the project?  Can I tell it to include the vtk 
> libraries that have been built outside of MacPorts?

You could use 'sudo port mpkg', which creates a single .pkg installer
that includes the files for the port and all of its dependencies. This
assumes that you have a port that provides the required vtk libraries.
It is not possible to include extra files that are not provided by a port.

If you are going to distribute this installer, please use a prefix other
than /opt/local for it, to avoid a collision for users that also use
MacPorts.

https://guide.macports.org/#using.binaries.binary-packages

Rainer

Re: gcc49 fails to build

[Rainer Müller]

On 2018-06-11 06:39, Dave Horsfall wrote:
> On Sun, 10 Jun 2018, Ken Cunningham wrote:
> 
>> Dave, I would be tempted to uninstall gcc49 and just see what happens.
>> I don't think you need it.
> 
> OK, with trepidation:
> 
>     ozzie:~ dave# port uninstall gcc49
>     --->  Deactivating gcc49 @4.9.4_2
>     --->  Cleaning gcc49
>     --->  Uninstalling gcc49 @4.9.4_2
>     --->  Cleaning gcc49
> 
> Well, nothing seemed to have depended upon it, but I guess I'll find out
> when I run my regular weekly check :-)

As gcc49 would usually only be necessary for building, that would be
expected. You can always remove pure build dependencies without breaking
any installed ports. However, they might be reinstalled again on the
next upgrade if they are still required.

> Q: Shouldn't old stuff be cleaned out for me?  Or do I have to keep
> track of them myself?
Unrequested ports without dependents can be removed with the command
'sudo port reclaim' which should be used regularly.

Rainer

Re: GIMP 2.10.2 - two packages

[Rainer Müller]

On 2018-06-02 10:00, FritzS - gmx wrote:
> Whats are the differences between this two packages of GIMP?
> 
> Make this version an GIMP.app?
> https://github.com/macports/macports-ports/blob/master/graphics/gimp/Portfile
> gimp 2.10.2 (source)
> GIMP - Batteries Included
> 
> https://github.com/macports/macports-ports/blob/master/graphics/gimp2/Portfile
> gimp2 2.10.2 (source)
> The GNU Image Manipulation Program

The gimp2 port is just GIMP itself. The gimp port installs gimp2 as a
dependency, but also additional plugins and a .app launcher provided by
the gimp2-launcher port.

If you want GIMP with everything that is available, just install the
gimp port:

$ sudo port install gimp

Hope that helps,
Rainer

Re: possible to enable debug symbols by default?

[Rainer Müller]

On 1 June 2018 02:35:35 GMT+02:00, Eitan Adler  wrote:
>Is it possible to get debug symbols enabled by default for ports? I'd
>like to always compile c-alike languages with "-g" and not have them
>stripped.

Wouldn't the debug symbols on macOS be written to a .dSYM bundle that is not 
installed?

Rainer

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

[Rainer Müller]

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

Apparently the registry was already updated, but the MacPorts
installation is too old to use it.

I have no idea how that happened (besides manually installing 2.4.x
after selfupdate), but installing MacPorts 2.5.0 should make the
MacPorts installation match the registry format version.

Rainer

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

[Rainer Müller]

On 2018-05-29 06:24, Shuvayan wrote:
> 
> 
>> On 29-May-2018, at 9:47 AM, Shuvayan > > wrote:
>>
>> Output:DEBUG: Copying
>> /Users/shuvayan/Library/Preferences/com.apple.dt.Xcode.plist to
>> /opt/local/var/macports/home/Library/Preferences
>> Version number in metadata table is newer than expected.
>>     while executing
>> "registry::open $db_path"
>>     (procedure "mportinit" line 642)
>>     invoked from within
>> "mportinit ui_options global_options global_variations"
>> Error: /opt/local/bin/port: Failed to initialize MacPorts, Version
>> number in metadata table is newer than expected.
>>
> 

I am not sure how you got into this state, but you should be able to
recover by installing MacPorts 2.5.0 from the .pkg installer.

Rainer

Re: waiting for lock

[Rainer Müller]

On 2018-05-25 04:37, Jihyun In wrote:
> I accidentally closed my terminal while updating my port. Now it says
> waiting for lock on /opt/ocal/var/macports/registry/.registry.lock I
> tried to uninstall macports so that I could reinstall it, but it still
> gives me that. What should I do? Answers would be much appreciated.
> Thank you!

This means that the port command is still running in the background
after you closed the terminal window. You have to kill this process to
free the lock. Check for "tclsh" in Activity Monitor.

Rainer

Re: port:distcc status?

[Rainer Müller]

On 2018-05-17 15:47, René J.V. Bertin wrote:
> What's status of the distcc port? I see it hasn't been maintained for about 5 
> years. Anyone using it on 10.9 or later?

Apparently, you were one of the last who worked on distcc [1]. But the
proposed changes were never submitted in a way that allowed to apply
them to the ports tree.

The distcc project has also moved to GitHub in the mean time and there
is a new release [2].

Rainer

[1] https://trac.macports.org/ticket/43071
[2] https://github.com/distcc/distcc/releases/tag/v3.3

Re: Online MacPorts Meeting on 21st April at 13:00 UTC - suggestion

[Rainer Müller]

On 2018-04-19 11:24, Rainer Müller wrote:
> On 2018-04-18 01:11, Rainer Müller wrote:
>> On 2018-04-13 13:34, Mojca Miklavec wrote:
>>> If we find three volunteers (I volunteer, so only two more needed), we
>>> could perhaps do a technology test run tomorrow at 13:00 UTC (that's
>>> precisely 7 days earlier)
>>> ... (or at any other potentially more suitable hour depending on who
>>> wants to participate).
>>>
>>> We could then test:
>>> - Hangouts
>>> - Discord
>>> - (potentially Skype, but it needs personal invitations etc.)
>>> - any other video conferencing tool, in case there are better suggestions
>>> and see which one fits best, but only if we get some proposal early enough.
>>>
>>> We could have IRC as a backup for coordination in case of technical
>>> problems etc.
>>
>> As nobody replied, I assume the test run did not happen...
>> Unfortunately, I could not make it either.
> 
> We should figure out the technical side, so we can focus on the
> discussion on Saturday.
> 
> Let's give it another try today at 17:00 UTC, meet on #macports IRC.
> Who else would be willing to join the test run?
> 
> https://www.timeanddate.com/worldclock/fixedtime.html?msg=MacPorts+Online+Meeting+Test+Run=20180419T17
> 
> I know this time of day is not ideal for anyone not in Europe, but the
> time is scarce until the meeting on Saturday.

Thanks everyone who joined the test run!
We tested today:

* Google Hangouts (Video)
  + worked out of the box for everyone
  - requires Google account
  - has a limit of maximum 10 people

* Discord (Audio)
  + does not require an account
  + runs in the browser
  - some people could only hear a subset of participants

* Zoom (Video)
  - forces you to install a .pkg, which already installs an app to
/Applications in the preflight script; we aborted the test

* Mumble (Audio)
   - requires a native app
   - very difficult to set up with certificate-based auth
   - default settings for voice activation did not work

* talky.io (Video)
   + does not require an account
   + runs in the browser
   - some people could only hear a subset of participants


As it was the only option that worked out of the box for everyone,
we decided to use Google Hangouts on Saturday.

We assume (and hope) that we will not be more than 10 people who want to
participate in the meeting. The link to join the call will be posted to
the corresponding wiki page for the meeting.

Rainer

Re: Online MacPorts Meeting on 21st April at 13:00 UTC - suggestion

[Rainer Müller]

On 2018-04-18 01:11, Rainer Müller wrote:
> On 2018-04-13 13:34, Mojca Miklavec wrote:
>> If we find three volunteers (I volunteer, so only two more needed), we
>> could perhaps do a technology test run tomorrow at 13:00 UTC (that's
>> precisely 7 days earlier)
>> ... (or at any other potentially more suitable hour depending on who
>> wants to participate).
>>
>> We could then test:
>> - Hangouts
>> - Discord
>> - (potentially Skype, but it needs personal invitations etc.)
>> - any other video conferencing tool, in case there are better suggestions
>> and see which one fits best, but only if we get some proposal early enough.
>>
>> We could have IRC as a backup for coordination in case of technical
>> problems etc.
> 
> As nobody replied, I assume the test run did not happen...
> Unfortunately, I could not make it either.

We should figure out the technical side, so we can focus on the
discussion on Saturday.

Let's give it another try today at 17:00 UTC, meet on #macports IRC.
Who else would be willing to join the test run?

https://www.timeanddate.com/worldclock/fixedtime.html?msg=MacPorts+Online+Meeting+Test+Run=20180419T17

I know this time of day is not ideal for anyone not in Europe, but the
time is scarce until the meeting on Saturday.

Rainer

Re: problem installing gnureadline

[Rainer Müller]

On 2018-04-18 15:07, pagani laurent wrote:
> after uninstalling everything and following the ”migration” tuto (and 
> removing tk from requested ports), I tried to install py36-jupyter but it 
> stopped again with the gnureadline install which still fails in the same way 
> as before (complaining about some scipy directory) though in principle there 
> is nothing left from outside/weird installations.

No port command will get rid of this file/directory when it is not
provided by a MacPorts port. You will have to clean it up manually.

> --->  Configuring py36-gnureadline
> --->  Building py36-gnureadline
> Error: Failed to build py36-gnureadline: command execution failed
> Error: See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-gnureadline/py36-gnureadline/main.log
>  for details.
> 
> (attached)
> 
>>
>> Is this file provided by a port? If not, you must have installed it in
>> some other way.
>>
>> port provides
>> /opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/scipy-0.19.1.dist-info
> 
> it says it is a directory.
> Note also that py36-scipy was installed earlier today with MP on my request 
> without failure. 

This file is definitely not coming from the current version of
py36-scipy. I assume you used 'sudo pip install' before (or some script
did) and that installed python packages directly into the MacPorts prefix.

The simplest solution is to just move this directory away:

sudo mv
/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/scipy-0.19.1.dist-info
~/Desktop/

Rainer

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

[Rainer Müller]

On 2018-04-18 10:09, Jan Stary wrote:
> On Apr 16 19:39:11, rlha...@smart.net wrote:
>> "In fall 2018, Apple will stop bundling open source services such as 
>> Calendar Server, Contacts Server, the Mail Server, DNS, DHCP, VPN Server, 
>> and Websites with macOS Server. Customers can get these same services 
>> directly from open-source providers. This way, macOS Server customers can 
>> install the most secure and up-to-date services as soon as they’re 
>> available."  https://support.apple.com/en-us/HT208312 
>> 
>>
>> For which of these (and others listed on the link) is there already a port,
>> esp. for the recommended (or most nearly identical) replacement?
> 
> We have unbound and nsd in the ports.
> 
>> Should there maybe also be a mention on a FAQ or wiki page of the
>> collective availability of easily installable alternatives via MacPorts?
> 
> I don't think this deserves another extra wiki page.
> MP provides software that does not come with MacOS itself.
> This situation is nothing new in that regard.

Similar to the migration guide from Apple linked below, there could be a
document to explain how to migrate these services to MacPorts.

Especially for internet-facing services it would be better to get more
users to install from a maintained repository with regular updates
instead of installing only once from source.

>> Anything else that might be an opportunity
>> to mitigate this annoyance that I haven't mentioned?
> 
> 
> Apple has been replacing fundamental parts of the OS with opensource
> for some time; a lot of the utils come from FreeBSD, the firewall is
> OpenBSD's pf, the SSL implementation is OpenBSD's LibreSSL, etc.
> That's not a bad thing: just use the good code, as opposed to
> reimplementing your own poorly. But e.g. groff (not really server related)
> that comes with the latest MacOS is groff 1.19.2, from 2004. That's ancient.
> And now they are saying they cannot even be bothered to do that anymore
> (after all, Apple is just a multibilion company).
> Dear user, install the actual software yourself.

That is the last version of GNU roff licensed as GPL-2+ before they
changed the license to GPL-3+. This is the reason you do not get any
more recent GNU tools and why GNU make or bash are that old. Apple
avoids the GPLv3 for its patent and anti-tivoization clauses. They are
not alone with this, other companies do the same.

>> https://developer.apple.com/support/macos-server/macOS-Server-Service-Migration-Guide.pdf
> 
> This looks like a last note from a frustrated admin
> leaving a company tomorrow for greener pastures.

Assuming Apple tested this process, it would be a good idea to check
whether the instructions given in this document match our ports
regarding startup items and other configuration options. Any volunteers?

Rainer

Re: Online MacPorts Meeting on 21st April at 13:00 UTC - suggestion

[Rainer Müller]

On 2018-04-13 13:34, Mojca Miklavec wrote:
> If we find three volunteers (I volunteer, so only two more needed), we
> could perhaps do a technology test run tomorrow at 13:00 UTC (that's
> precisely 7 days earlier)
> ... (or at any other potentially more suitable hour depending on who
> wants to participate).
> 
> We could then test:
> - Hangouts
> - Discord
> - (potentially Skype, but it needs personal invitations etc.)
> - any other video conferencing tool, in case there are better suggestions
> and see which one fits best, but only if we get some proposal early enough.
> 
> We could have IRC as a backup for coordination in case of technical
> problems etc.

As nobody replied, I assume the test run did not happen...
Unfortunately, I could not make it either.

In any case, we are approaching the deadline to suggest topics.
I created a wiki page to track the agenda:

https://trac.macports.org/wiki/Meetings/2018-04-21

Rainer

Re: problem installing gnureadline

[Rainer Müller]

On 2018-04-16 20:07, pagani laurent wrote:
> Rainer,
> 
> I just updated the outdated ports before trying to install py36-jupyter :
> 
> Macports>sudo port upgrade outdated
> Password:
> Nothing to upgrade.
> 
> but py36-scipy was not installed (I was on py35 until now because of the
> py36-readline bug).
> 
> So I installed py36-scipy but the error remains the same.
> Same permission error in the logfile.

Is this file provided by a port? If not, you must have installed it in
some other way.

port provides
/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/scipy-0.19.1.dist-info

Knowing where it comes from would help to find out how to clean it up.
Did you install python packages with pip, that is 'sudo pip install'?

Rainer

Re: problem installing gnureadline

[Rainer Müller]

On 2018-04-16 16:32, pagani laurent via macports-users wrote:
> Hi,
> 
> I have python3.6 updated, and selected to run on command python3 and ipython3.
> I tried to install py36-jupyter (never installed before).
> It crashed on trying to install py36-gnureadline.
> I cleaned py36-gnureadline and tried again. Crashed again (attached the log) :
> 
> --->  Fetching distfiles for py36-gnureadline
> --->  Verifying checksums for py36-gnureadline
> --->  Extracting py36-gnureadline
> --->  Applying patches to py36-gnureadline
> --->  Configuring py36-gnureadline
> --->  Building py36-gnureadline
> Error: Failed to build py36-gnureadline: command execution failed
> Error: See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-gnureadline/py36-gnureadline/main.log
>  for details.
> Error: Follow https://guide.macports.org/#project.tickets to report a bug.
> Error: Processing of port py36-gnureadline failed

This is actually a problem with a file installed by the py36-scipy port:

:info:build PermissionError: [Errno 13] Permission denied:
'/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/scipy-0.19.1.dist-info'

Note the current version of py-scipy is 1.0.1. This file or a similar
file is not part of the current py36-scipy archive.

You should upgrade the outdated ports on your system:
  sudo port selfupdate
  sudo port upgrade outdated

Rainer

Re: help needed to compile a C program

[Rainer Müller]

On 2018-04-13 21:26, macpo...@parvis.nl wrote:
> 
>> On 2018-04-13, at 20:17, Rainer Müller <rai...@macports.org> wrote:
>>
>> On 2018-04-13 18:21, macpo...@parvis.nl wrote:
>>> with makefile:
>>> ---
>>> pango-list-typefaces:   pango-list-typefaces.c
>>> cc -o $@ -Wall -g pango-list-typefaces.c \
>>> $(pkg-config --cflags --libs pango) \
>>> $(pkg-config --cflags --libs cairo) \
>>> $(pkg-config --cflags --libs pangocairo) \Currently 
>>> $(pkg-config --cflags --libs glib-2.0)
>>
>> The Makefile is your problem. $(foo) is a normal variable expansion.
>> This should be: $(shell pkg-config ...)
>>
>> Rainer
> 
> my mistake: I changed `pkg-config ..` to $(..).
> but neither $(shell pkg-config nor `pkg-config helped. same error.
> question remains open.

Works for me. Use "Download ZIP" to the upper right here, extract and
run make in the directory:
https://gist.github.com/raimue/634213828f7ff86b9a6f4698ed488d85
> any suggestions on my aother questions?
> 
> Currently I have glib2 installed, but there is also glib2-devel, and they 
> conflict with each other.
> Same for pango and pango-devel.
> - What is the difference?
> - Which should I use?

*-devel ports are pre-releases, beta or unstable. You usually do not
want them unless you really need the bleeding edge.

> I don't know what the include path will be. 
> - How should I use 'port provides glib.h' ?

Use an absolute path:

$ port provides /opt/local/include/glib-2.0/glib.h
/opt/local/include/glib-2.0/glib.h is provided by: glib2

If instead you meant you do not know which ports provides a specific
file, there is unfortunately no index available for that.

Rainer

Re: help needed to compile a C program

[Rainer Müller]

On 2018-04-13 18:21, macpo...@parvis.nl wrote:
> with makefile:
> ---
> pango-list-typefaces:   pango-list-typefaces.c
>         cc -o $@ -Wall -g pango-list-typefaces.c \
>         $(pkg-config --cflags --libs pango) \
>         $(pkg-config --cflags --libs cairo) \
>         $(pkg-config --cflags --libs pangocairo) \Currently 
>         $(pkg-config --cflags --libs glib-2.0)

The Makefile is your problem. $(foo) is a normal variable expansion.
This should be: $(shell pkg-config ...)

Rainer

Re: Rsync and --protect-decmpfs

[Rainer Müller]

Please keep the discussion on the mailing list by using Reply All.

On 2018-04-13 13:10, Christopher Stone wrote:
> On 04/13/2018, at 05:33, Rainer Müller <rai...@macports.org
> <mailto:rai...@macports.org>> wrote:
>> I think you are talking about the hfs-compression.diff patch. We used
>> to apply this patch, but the commit [1] that removed it said that it
>> was marked as broken with rsync 3.1.3.
> 
> 
> Hey Rainer,
> 
> Yes.  Apologies – I intended to mention the patch name and forgot.
>  Chalk that up to my inexperience with them.
> 
>> If there is a newer compatible version of that patch around somewhere
>> we could use that.
> 
> The attached hfs-compression.diff file is distributed with rsync 3.1.3.
>  It supposedly compiles and passes the test suite.
> 
> https://download.samba.org/pub/rsync/

I do not know where the information that the hfs-compression.diff patch
is broken comes from. It is not mentioned in the pull request [1] either.

I added jabenninghoff to CC.

Rainer

[1] https://github.com/macports/macports-ports/pull/1299

Re: Rsync and --protect-decmpfs

[Rainer Müller]

On 2018-04-13 11:05, Christopher Stone wrote:
> My friend's advice and a few places on the Net recommend using this switch on 
> the Mac:
> 
> --protect-decmpfs (patch by Mike Bombich of CCC fame)
> 
> MacPorts rsync version 3.1.3 protocol version 31 doesn't have this option 
> available.
> 
> How desirable is this option?
> 
> Is there a way to add the option when building rsync with MacPorts?
>
> If so I would expect to see a variant, but I've mostly used default ports and 
> am uneducated about variants.
> 
> I have't fooled with `make` for quite a while (preferring to let MacPorts do 
> the dirty work for me), but I expect I can make from source if I have to.

I think you are talking about the hfs-compression.diff patch. We used to
apply this patch, but the commit [1] that removed it said that it was
marked as broken with rsync 3.1.3.

If there is a newer compatible version of that patch around somewhere we
could use that.

Rainer

[1]
https://github.com/macports/macports-ports/commit/3b08efaebe3b7413093b981f2f4ad661d27cffac#diff-c915c59a1e788fdf85b0d74e8116b961R32

MacPorts 2.4.3 has been released

[Rainer Müller]

On 2018-04-12 19:15, Ryan Schmidt wrote:
> 
> On Apr 12, 2018, at 11:27, Rainer Müller wrote:
> 
>> On 2018-04-12 17:42, Ryan Schmidt wrote:
>>> On Apr 12, 2018, at 03:50, Clemens Lang wrote:
>>>>
>>>> Can you remove the -q flag and/or retry running git fetch? That should 
>>>> give us
>>>> an idea what went wrong here.
>>>
>>> No change. No additional output is produced. 
>>
>> The problem is that ${RBASE} is fetching from ${TBASE} on the local
>> filesystem,
> 
> Ah! I didn't realize we were doing that.
> 
>> but the former did not fetch any tags.
>>
>> Hopefully fixed with:
>> https://github.com/macports/macports-infrastructure/commit/db64051c6dce12135eeb8114c6f77f320d5097f8
> 
> This doesn't appear to have helped.
> 
> 2018-04-12T17:09:42+ + '[' '!' -d 
> /Volumes/RAID/opt/local/var/rsync/macports ']'
> 2018-04-12T17:09:42+ + '[' -d 
> /Volumes/RAID/var/tmp/mprsyncup/trunk/base/.git ']'
> 2018-04-12T17:09:42+ + /opt/local/bin/git -C 
> /Volumes/RAID/var/tmp/mprsyncup/trunk/base pull -q
> 2018-04-12T17:09:44+ + /opt/local/bin/git -C 
> /Volumes/RAID/var/tmp/mprsyncup/trunk/base fetch --tags
> 2018-04-12T17:09:44+ + /bin/mkdir -p 
> /Volumes/RAID/opt/local/var/rsync/macports/trunk/base
> 2018-04-12T17:09:45+ + /opt/local/bin/rsync -q -aIC --delete 
> /Volumes/RAID/var/tmp/mprsyncup/trunk/base/ 
> /Volumes/RAID/opt/local/var/rsync/macports/trunk/base
> 2018-04-12T17:11:46+ + read -r RELEASE_URL
> 2018-04-12T17:11:46+ + '[' -z 
> https://github.com/macports/macports-base/tags/v2.4.3 ']'
> 2018-04-12T17:11:46+ + RBASE_CHANGED=1
> 2018-04-12T17:11:46+ + '[' -d 
> /Volumes/RAID/var/tmp/mprsyncup/release/base/.git ']'
> 2018-04-12T17:11:47+ + cd /Volumes/RAID/var/tmp/mprsyncup/release/base
> 2018-04-12T17:11:47+ + /opt/local/bin/git fetch --tags
> 2018-04-12T17:11:48+ ++ /opt/local/bin/git rev-parse HEAD
> 2018-04-12T17:11:48+ + 
> RBASE_OLD_REV=68708e1c5e2a4f21afa95e733c5d34cd0f5c71de
> 2018-04-12T17:11:48+ ++ /usr/bin/basename 
> https://github.com/macports/macports-base/tags/v2.4.3
> 2018-04-12T17:11:48+ + /opt/local/bin/git checkout -q v2.4.3
> 2018-04-12T17:11:48+ error: pathspec 'v2.4.3' did not match any file(s) 
> known to git.

Please check:

Is the v2.4.3 tag in TBASE now?
$ git -C /Volumes/RAID/var/tmp/mprsyncup/trunk/base tag -l | grep v2.4.3
Expected: v2.4.3

Where is TBASE configured to sync from?
$ git -C /Volumes/RAID/var/tmp/mprsyncup/trunk/base config remote.origin.url
Expected: https://github.com/macports/macports-base.git

What is TBASE configured to sync?
$ git -C /Volumes/RAID/var/tmp/mprsyncup/trunk/base config remote.origin.fetch
Expected: +refs/heads/*:refs/remotes/origin/*


I tried to simulate this locally by deleting the v2.4.3 tag again,
but it works for me:


// start clean
$ rm -rf /var/tmp/macports/
# initialize repos
$ ./mprsyncup

// reset to the state of 2.4.2
$ git -C /var/tmp/macports/trunk/base/ tag -d v2.4.3
$ git -C /var/tmp/macports/release/base/ tag -d v2.4.3
$ git -C /var/tmp/macports/release/base/ reset --hard v2.4.2

// sync again
$ ./mprsyncup
...
+ '[' -d /var/tmp/macports/trunk/base/.git ']'
+ /opt/local/bin/git -C /var/tmp/macports/trunk/base pull -q
+ /opt/local/bin/git -C /var/tmp/macports/trunk/base fetch --tags
+ /bin/mkdir -p /var/tmp/rsync/macports/trunk/base
+ /opt/local/bin/rsync -q -aIC --delete /var/tmp/macports/trunk/base/
/var/tmp/rsync/macports/trunk/base
+ read -r RELEASE_URL
+ '[' -z https://github.com/macports/macports-base/tags/v2.4.3 ']'
+ RBASE_CHANGED=1
+ '[' -d /var/tmp/macports/release/base/.git ']'
+ cd /var/tmp/macports/release/base
+ /opt/local/bin/git fetch --tags
>From /var/tmp/macports/trunk/base
 * [new tag]   v2.4.3 -> v2.4.3
++ /opt/local/bin/git rev-parse HEAD
+ RBASE_OLD_REV=68708e1c5e2a4f21afa95e733c5d34cd0f5c71de
++ /usr/bin/basename https://github.com/macports/macports-base/tags/v2.4.3
+ /opt/local/bin/git checkout -q v2.4.3
++ /opt/local/bin/git rev-parse HEAD
+ RBASE_NEW_REV=a393413460aae5ac9749b994681381087089cdb5
+ '[' 68708e1c5e2a4f21afa95e733c5d34cd0f5c71de =
a393413460aae5ac9749b994681381087089cdb5 ']'
+ /bin/mkdir -p /var/tmp/rsync/macports/release/base
+ /opt/local/bin/rsync -q -aIC --delete /var/tmp/macports/release/base/
/var/tmp/rsync/macports/release/base


Rainer

Re: MacPorts 2.4.3 has been released

[Rainer Müller]

On 2018-04-12 17:42, Ryan Schmidt wrote:
> On Apr 12, 2018, at 03:50, Clemens Lang wrote:
>>
>> Can you remove the -q flag and/or retry running git fetch? That should give 
>> us
>> an idea what went wrong here.
> 
> No change. No additional output is produced. 

The problem is that ${RBASE} is fetching from ${TBASE} on the local
filesystem, but the former did not fetch any tags.

Hopefully fixed with:
https://github.com/macports/macports-infrastructure/commit/db64051c6dce12135eeb8114c6f77f320d5097f8

Rainer

Re: Online MacPorts Meeting on 21st April at 13:00 UTC - suggestion

[Rainer Müller]

On 2018-04-07 14:18, William H. Magill wrote:
> IRC is still quite popular in Europe, but is little used in the US.
IRC on our #macports channel is fine to ask questions for which you do
not want to write a lengthy email or to debug problems with quick
back-and-forth on what to check or try.

However, meetings on IRC are slow, as you have to wait for others to
type, you have no notifications whether others still have something to
say, etc.

For such a scheduled meeting, I would prefer audio chat as that would
make the communication more direct and faster.

> One alternative to IRC is “Discord” — it has the same “type text” 
> capabilities as IRC, but as far as I’m concerned, it is MUCH easier to use.
> It also supports voice channels.
> 
> And, yes, there is a Mac client - OSX and IOS - as well as access through the 
> browser.
> 
> https://discordapp.com
> 
> It is pitched as “for gamers,” mainly because of its voice capabilities.

Discord looks fine to me. Apparently we would not even be the first open
source project to use it [1]. Apparently you can use it directly in a
browser without registration ("claiming the account").

The other well-known option would of course be Skype. However, with
Skype one person would have to collect interested developers first and
then invite them to a group call. With Discord it seems like you can
just create a room that everyone can join, which would be a lot simpler.

There is also Jitsi [2], an open source solution for video conferencing
via WebRTC in the browser. However, browser support seems to be limited,
especially with Safari.

Rainer

[1] https://discordapp.com/open-source
[2] https://jitsi.org/

Re: platforms

[Rainer Müller]

On 2018-03-24 13:54, Jan Starý wrote:
> The 'platforms' field of a Portfile is currently
> both _required_ and _ignored_. By the Guide,
> 
>   A list of the platforms on which the port has been tested.
>   Required, but not interpreted in any way by the software
>   at this time; it is purely informational for user
> Also, it is allowed to say .e.g. "freebsd" but not e.g. "openbsd".
> I propose that the 'platforms' field be no longer required
> if it is ignored, and if it stays, let it be a free form text,
> as opposed to a predefined definitive list of all unixes.

I see the list of possible values in the guide as examples and
non-exhaustive. The wording could be better, though.

> Better yet, drop it altogether. The fact that I tested on Solaris
> or Debian means nothing regarding the MP port. I have also tested
> it on darwin of course, but that goes without saying.

As the guide says, it is "informational" at the moment. In the past,
more people were using MacPorts on FreeBSD, therefore they added their
test results to the port.

I agree it could be optional for the common case of "platforms darwin"
without any specific requirements on the version.

> (What would be kinda useful is if it pointed to the actual _ports_
> on the other systems - often there are things we can learn, as they
> battle a lot of the same GNUisms etc. For example, the patch for opus
> https://github.com/macports/macports-ports/pull/1217 is basically
> the OpenBSD patch for opus. So if opus 'platforms' pointed to
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/audio/opus/
> it would be usefull. Unlike now.)

If a specific patch was taken from another distribution, information
should be right in the patch file. Some ports are already using
"Upstream:" or "Upstream-Status:" header lines in the patches. There is
no formal format for MacPorts, but it was loosely adopted from
OpenEmbedded [1].

I do not want to keep a list of all other package managers providing
libopus. There is already repology for this [2].

Rainer

[1]
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines#Patch_Header_Recommendations:_Upstream-Status
[2] https://repology.org/metapackage/opus/versions

Re: Questions on port development

[Rainer Müller]

On 2018-03-25 16:19, macpo...@parvis.nl wrote:
> I'm working on a port for munin 2 as the current macports version 1.4.7 is of 
> 14 mar 2012.
> The munin-node seems to work fine, the server part requires more testing.

Great! That port is really in the need of an update.

> (1)
> 
> I need a port install munin@2.0.35 buth without a destroot phase.
> Is there a dummy command for destroot.cmd that allows to build without 
> install? exit 1? 

For testing, you can run the various port phases separately. Running
'sudo port -v build' would only complete the build phase and you can
examine the results in the work/ directory, which is available via the
work symlink next to the Portfile, or with 'port work'. You can also run
'sudo port destroot' and examine the files that would be installed at
work/destroot/.

> (2)
> 
> To prevent clashes with the current macports installation, I think it is best 
> to create a second one.
> 
> Guide 2.2.4 Install Multiple MacPorts Copies ( 
> https://guide.macports.org/#installing.macports.source.multiple ) talks about 
> that. I assume that 2.2.3 Git Install should be done before. confirmation 
> please.

This is usually not required for port development, unless you do not
want to uninstall the existing munin port.

> (3)
> 
> If I succeed in making this port, how should I do it?
> - create new port munin2 with no relation to munin @1.4.7
> - make this an upgrade for the current version.

I see no reason to keep 1.x around. On a quick check, most other
distributions are also only providing 2.x.

Rainer

Re: distfile downloads failing on https

[Rainer Müller]

On 2018-02-21 20:14, Jan Stary wrote:
> If I am reading https://guide.macports.org/chunked/reference.phases.html
> right, there is are no "fetch dependencies". Would it make sense
> to introduce fetch dependencies just like we have build dependencies
> and run dependencies, so that the affected ports could specify e.g. curl,
> and MP vuld use _that_ for those ports?

depends_fetch exists, but apparently is not documented in the guide.

However, there should not be individual workarounds in ports, as it is a
general problem. Sorry, but your system has become too old to
communicate with servers on the internet. You will experience the same
problem with more and more servers over time as they begin to require
TLS 1.2.

The best workaround would be distfile mirroring, as everyone would
benefit from that. Most mirrors are still accessible with no TLS or less
strict cipher requirements.

Rainer

Re: glib2 +x11/+quartz

[Rainer Müller]

On 2018-02-22 11:33, Jan Stary wrote:
> Why is it that one of those variants is required?
> Is there any problem with having glib2 without both?

The glib2 port uses a MacPorts-specific patch [1] to either use .desktop
files (+x11) or macOS app bundles (+quartz) for the GAppInfo API. This
has to be selected at build time. One of these has to be used; there is
no way to build without this module.

The glib2 upstream source without this patch would always use the
equivalent of +quartz on macOS, which is not what we want as our ports
are not building app bundles.

Rainer

[1] https://bugzilla.gnome.org/show_bug.cgi?id=781548

Re: OpenSSH with Mac Keychain

[Rainer Müller]

On 2018-01-31 21:28, Chao-Chin Yang wrote:
> I can continue to log into the remote system without entering again the
> passphrase.  However, once I completely log out of my Mac and re-log
> into my Mac, the terminal does not remember my passphrase anymore.

As of macOS 10.12 Sierra, this is the intended behavior:

https://developer.apple.com/library/content/technotes/tn2449/_index.html#//apple_ref/doc/uid/DTS40017589

> After googling around, it seems that the Mac native SSH has added a new
> SSH keyword “UseKeychain”, while the MacPorts version does not have this
> keyword and is having problem talking to Keychain.  I cannot find any
> solution to this.
> 
> Does anyone know any solution or is working on one?

Unfortunately, the keychain support is a custom patch by Apple that is
not in the upstream sources. The patch will only be applied when
installing it with the +gsskex variant, however, I have not tested it
myself.

Personally, I usually use /usr/bin/ssh because of the keychain
integration, but I have the following lines in my ~/.ssh/config that
stop /opt/local/bin/ssh from choking on the unknown options:

  IgnoreUnknown AddKeysToAgent,UseKeychain
  AddKeysToAgent yes
  UseKeychain yes

Hope that helps,
Rainer

Re: Apple Source Browser

[Rainer Müller]

On 2018-02-03 18:40, Jan Stary wrote:
> e.g. https://opensource.apple.com/source/copyfile/
> contains various subdirectories with version numbers.
> Can someone please explain how these correspond
> to the actual MacOSX releases?
> 
> https://opensource.apple.com/source/copyfile/copyfile-146
> seems the contain the most recent manpage.

I think you have to check the overview page for the macOS releases,
where the corresponding version is linked to. For example for 10.13.1,
it is copyfile-146, but for 10.13.2, it is copyfile-146.30.2.

https://opensource.apple.com/release/macos-10131.html
  -> https://opensource.apple.com/source/copyfile/copyfile-146/

https://opensource.apple.com/release/macos-10132.html
  -> https://opensource.apple.com/source/copyfile/copyfile-146.30.2/

Rainer

Re: Using MacPorts "Offline"

[Rainer Müller]

On 2018-01-30 01:15, Jepeway, Chris wrote:
> This is the last line of sources.conf:
> 
>   file:///Users/chrjep2/share/macports/ports.tar [default] [nosync]

The correct syntax would be to put the flags into the same brackets:

file:///Users/chrjep2/share/macports/ports.tar [default,nosync]

Rainer

Re: MacPorts Meeting 2018

[Rainer Müller]

Thank you for taking the initiative again! The meeting 2016 in Slovenia
was really a great experience. Not only that we were productive and had
some nice results, but it was also a very nice social event.

I think we already learned a lot from last time on how we should
schedule and especially document the sessions. We might also want to
look into getting some more remote involvement this time, like hosting a
video conference. However, of course I rather want all of you to attend
the meeting in person. :-)

Rainer

Re: livecheck timeout

[Rainer Müller]

On 2017-11-23 18:13, db wrote:
> On 23 Nov 2017, at 17:06, Ryan Schmidt  wrote:
>> ftp connections fail in many circumstances, due to either the use or non-use 
>> of passive mode, or for other reasons. I'm certainly tired of attempting to 
>> debug them, which is why it's great when we can remove the use of ftp from a 
>> portfile and replace it with http(s).
> 
> Before the change, it should have timed out in 30", not in 30'. Why didn't it?

I still have no idea what these units are, please communicate clearly.
Always provide debug logs as that would have helped to identify FTP much
earlier.

I can confirm that the previous Portfile version that used ftp:// for
livecheck also hangs longer than 30 seconds for me. It hangs the same
way with curl(1) on command line, after EPSV.

The timeout we configure is only for the initial connection, but the
transfer itself may take as long as it takes. I am not sure why the
configured speed limit does not cause the transfer to be aborted after a
while, though...

We could provide an additional flag for our 'curl fetch' API in Pextlib
to set an overall timeout with CURLOPT_TIMEOUT that is only used for
livecheck. However, I do not think it is worth to invest effort into
that. Hosts or protocols that fail for some users are a bad option value
anyway. It is better not to use FTP at all.

Rainer

Re: livecheck timeout

[Rainer Müller]

On 2017-11-23 11:09, db wrote:
> On 23 Nov 2017, at 06:42, Ryan Schmidt  wrote:
>> How long is too long?
> 
> 30'

The connect timeout of 30 seconds for downloads using libcurl is
hardcoded in base [1] and cannot be configured.

Rainer

[1]
https://github.com/macports/macports-base/blob/a1e0b3bd5c062ff4d6eb1fd23badd395bdd39c7f/src/pextlib1.0/curl.c#L57

Re: ssh-agent no longer being started

[Rainer Müller]

On 2017-11-05 23:44, René J.V. Bertin wrote:
> I do have a SSH_AUTH_SOCK var in the launchctl env, but it points to a socket 
> that's used only by launchd itself and by gpg-agent . I see that gpg-agent is 
> started from 
> ${prefix}/etc/LaunchAgents/org.macports.gpg-agent/org.macports.gpg-agent.plist,
>  which also sets SSH_AUTH_SOCK . When I remove that Sockets key from that 
> launchd plist, ssh-agent functionality is restored.

The gpg-agent port used to provide this LaunchAgent, but it was recently
marked as obsolete and replaced by gnupg2 [1]. Just uninstall the
gpg-agent port and switch to gnupg2. gpg-agent will now be launched
on-demand by gpg itself.

Rainer

[1]
https://github.com/macports/macports-ports/commit/ce526e044d46adfff3e5bef452188fe15760ccbf

Re: MacPorts shell mode

[Rainer Müller]

On 2017-10-19 18:25, -dan d. wrote:
> 
> I make an "mp" alias of the below which allows doing a port command without
> repeated sudo inputs.  In effect it puts your pasword into sudo for you:
> 
> echo your-password | /usr/bin/sudo -S port $1 $2 $3 $4 $5

Not a good idea. This means your password is in plain text on disk and
it will be visible to all users at runtime in the list of processes.

If you really want to run a command without typing your password,
configure the sudoers file accordingly. There are plenty of guides on
the web on how to do this, or see 'man sudoers' and 'man visudo'.

Be aware of the security implications such a configuration has. Allowing
to run port without sudo effectively allows to run any command as root,
as it is trivial to execute other binaries.

Rainer

Re: Macports installation problem

[Rainer Müller]

On 2017-10-18 11:25, John wrote:
> Hi, 
> 
>    I tried to install Cairo graphics 
> 
> https://www.cairographics.org/download/
> 
>    and I need to install Macports. 
> 
>    I tried to install Macports on my Mac OS Sierra 10.12.6, and type
> "sudo port install cairo", but it did not respond. I haven't seen any
> file name or app called Macports, but one file called "port" which is
> located at
> 
> loca/bin/port"
> 
>    How should I do it? 

Follow the setup instructions to add the port command to your PATH:
https://guide.macports.org/chunked/installing.shell.html

Rainer

Re: High Sierra and MacPorts

[Rainer Müller]

On 2017-10-12 12:02, Chris Jones wrote:
> See
> 
> https://lists.macports.org/pipermail/macports-announce/2017-October/date.html
> 
> 
> Maybe its not in the below because it was sent to the announce list, and
> cc'ed to users ?

Sorry, that was my fault. The announce for 2.4.2 was meant to be sent to
the users list.

Somehow I managed to make a mistake in the address format putting the
macports-dev list twice into the CC header instead of also including
macports-users.

Rainer

Re: establish installed dependency not in portfile

[Rainer Müller]

On 2017-10-09 15:24, db wrote:
> On 9 Oct 2017, at 13:00, Rainer Müller <rai...@macports.org> wrote:
>> The statistics can be viewed here:
>> http://stats.macports.neverpanic.de/
> 
> Strange enough http://stats.macports.neverpanic.de/ports lists ~32K ports.

What is so strange about that? The current PortIndex has ~20K ports and
these statistics also include historical data on obsolete ports that no
longer exist in our ports tree.

Rainer

Re: establish installed dependency not in portfile

[Rainer Müller]

On 2017-10-09 15:21, db wrote:
> On 09/10/17 14:05, Chris Jones wrote:
>> There will be a lot more than 3K ports now, Ryan's message was a while back. 
>> Give it a week or so and pretty much it will have caught up with the others, 
>> I suspect.
> 
> There are still no binaries for all ports for the previous supported OS 
> releases, i.e., 10.11 and 10.12.

Due to license conflicts, we cannot distribute binaries for all ports.

Rainer

Re: establish installed dependency not in portfile

[Rainer Müller]

On 2017-10-08 12:17, db wrote:
> On 8 Oct 2017, at 01:17, Ryan Schmidt  wrote:
>> py-numpy requires a Fortran compiler. Xcode doesn't contain one, so we must 
>> use one provided by MacPorts. You can choose which compiler to use by using 
>> variants:
> 
>> For modern systems, the default gcc port that the compilers portgroup uses 
>> used to be gcc6, and was changed to gcc7 a few days ago:
>> https://github.com/macports/macports-ports/commit/c347ac662f932c0db8b15ec982eb4a563174bcfc
> 
> Since py27-numpy is the only port installed requiring gcc7, I rather choose 
> gcc6 which is used by many others instead. Is there any way to install a port 
> like scapy, which ultimately depends on py27-numpy built by default by gcc7, 
> using gcc6 instead, i.e., to pass a variant to a dependency of the port to be 
> installed? Or, is installing the dependency variant, then setting it to not 
> requested, next installing the dependent port, the only way?

Selected variants will be passed down to dependencies, if they are not
yet installed, even if the port given on the command line does not have
such a variant.

In your case, assuming py27-numpy is not yet installed, the command
  sudo port install scapy +gcc6
would install py27-numpy +gcc6 as dependency.

Rainer

Re: curl error:1407742E:SSL

[Rainer Müller]

On 2017-10-03 18:53, db wrote:
> On 3 Oct 2017, at 17:30, Ken Cunningham  
> wrote:
>> Please see 
> 
> No option in config file to avoid recompiling MP? I was thinking about 
> symlinking to MP's version as a last resort.

No, we are using libcurl which is linked in. You cannot change that
easily without recompiling.

Rainer

Re: Uninstall a port and ONLY THAT PORT's dependencies?

[Rainer Müller]

On 10/03/2017 02:12 AM, Carlo Tambuatco wrote:
> 
>> On Oct 2, 2017, at 2:24 AM, Mojca Miklavec > > wrote:
>>
>> Some ports may be installed as build dependencies. Or some ports you 
>> installed
>> now need different dependencies than they used to. Macports won't auto-notify
>> you when some dependencies are no longer needed, so ports may accumulate over
>> time.
>>
> 
> Sounds like a feature request to me...

MacPorts 2.4.0 already introduced the 'sudo port reclaim' command, which will
identify and uninstall unrequested ports that have no requested dependents.

However, the common tasks section in the guide could need some documentation and
examples for the new port action. Contributions welcome!

https://guide.macports.org/#using.common-tasks

Rainer

Re: Midnight Commander build is failed for High Sierra

[Rainer Müller]

On 2017-09-29 16:18, Jack wrote:
> I think the build script for Midnight commander is failed on High Sierra.
> 
> The error log is in the attachment.

Already reported and being worked on in this ticket:
https://trac.macports.org/ticket/54774

Rainer

PS: Please use the new @lists.macports.org instead of the old list
address at macOS Forge for future emails.

Re: Mulberry v4.1d1 for MacPorts?

[Rainer Müller]

On 2017-09-26 09:58, FritzS - gmx wrote:
> why did’t Mulberry v4.1d1 available in MacPorts?
> http://trac.mulberrymail.com/mulberry/browser#Mulberry/branches/v4.1d1
> 
> Mulberry is an old IMAP Client and now OpenSource.

MacPorts is a completely volunteer-driven project. Nobody else has
invested time and effort yet to write and submit a Portfile for Mulberry.

You are welcome to contribute to MacPorts and help with making new
software ports available in the MacPorts ports tree. The guide can get
you started with Portfile development, but help with writing Portfiles
is usually provided on the macports-dev mailing list.

https://guide.macports.org/#development

In this case, however, my personal opinion would be that it is not worth
the effort for Mulberry. Although the source code was published under an
open source license in 2007, it did not see any significant development
over the last 10 years and at this point it looks like a dead project.

Rainer

Re: kmymoney4 failure on Sierra (was In a mess with libc++ libstdc++ and OSX 10.7.5 Lion)

[Rainer Müller]

On 2017-09-17 05:16, Ian Wadham wrote:
> I went through the procedure to register with GitHub, but I have not received 
> a
> confirmatory email from there, despite checking the email address I entered 
> and
> requesting a resend many times.  I also checked spam boxes and gmail website.

Sorry to hear that. Please contact GitHub support to get assistance with
setting up your account:

https://github.com/contact

Rainer

Re: qbs failed to update...logfile is attached.

[Rainer Müller]

On 2017-09-15 11:17, Carlo Tambuatco wrote:
> Sorry, I sent a previous message without actually attaching the log file.
> 
> qbs is a dependency for Qt5-Creator, and it failed to configure and build for 
> some reason.
> 
> Log file is attached.

Looks like the same problem as in this ticket:
https://trac.macports.org/ticket/54792

Rainer

Re: running macports along with homebrew

[Rainer Müller]

On 08/30/2017 12:17 AM, Mojca Miklavec wrote:
> On 29 August 2017 at 23:43, David Strubbe wrote:
>> Hi Mojca,
>>
>> How do you hide a prefix when installing?
> 
> You could have your path set to something like
> 
> 
> /opt/local/bin:/opt/local/sbin:/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
> 
> and then you would set it to
> 
> /opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11/bin
> 
> when installing packages to MacPorts.

MacPorts will not use the PATH environment variable configured by the user at
all for building. These two examples should make no difference for MacPorts.
However, I do not know if having /opt/local/bin:/opt/local/sbin on PATH causes
problems for Homebrew.

> I think that MacPorts already takes some measures to hide the path
> that's irrelevant (so setting this might not necessarily make any
> difference to MacPorts, but doing something equivalent for Hombrew
> would probably help - unless they implement this feature recently in
> which case it wouldn't make any difference). I don't want to make any
> claims about current functionality as I didn't follow precisely.
> 
> BUT: note that if Homebrew is installed in /usr/local, there's
> generally no way to hide packages from the compiler (except when using
> "port install -t"). If you install Hombrew to /usr/local and want to
> keep MacPorts and run into problems probably only god can help you fix
> the issues :) :) :)

This is the main problem. If you want to use Homebrew in parallel to MacPorts,
choose a different prefix than /usr/local.

Rainer

Re: mcrypt failure?

[Rainer Müller]

On 2017-08-24 22:50, Richard L. Hamilton wrote:
> Attempting
> mcrypt  -a  enigma  --keymode  scrypt --bare --decrypt  
> with a file containing "testing\n" and encrypted (via old Unix crypt(1)) with 
> key "abcdefg", I get the response
> 
> File /tmp/test was NOT decrypted successfully.
> 
> The same procedure works on CentOS, Ubuntu, and Cygwin, at least.  Why is it 
> failing with the MacPorts installation of mcrypt (on Sierra)?

Apparently you also need to add the option --no-openpgp, as mcrypt
otherwise expects input in the OpenPGP format.

  $ mcrypt -a enigma -o scrypt --bare --decrypt --no-openpgp < /tmp/test
  Enter passphrase:

  testing
  Stdin was decrypted.

I don't know if this behavior is controlled by a configure option and
also could not spot any difference in a quick comparison with the Debian
package. No idea what what causes this.

Rainer

Re: Apache 2.4 any time soon?

[Rainer Müller]

On 2017-08-12 01:52, Bill Christensen wrote:
> I see that Apache 2.2 officially hit EOL as of the latest release
> (7/11/17).
> 
> Any chance we'll see an Apache 2.4 for production in MacPorts in the
> near future?

It is already in the ports tree as apache24-devel. As the corresponding
ticket for making Apache 2.4 the default got no attention from Ryan as
maintainer yet, I assume help and patches to make this work would be
appreciated.

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

Rainer

Re: macports' hardlinks and time machine backups

[Rainer Müller]

On 08/13/2017 07:57 PM, db wrote:
> On 13 Aug 2017, at 18:46, Clemens Lang  wrote:
>> MacPorts no longer uses hardlinks. We now keep the pristine state in 
>> archives in /opt/local/var/macports/software instead of hardlinking 
>> everything from there.
> 
> Not even for other parts that I'm not aware of, that would explain the 
> difference between Finder and du?

Finder on macOS uses base 10, so "GB" stands for 1000*1000*1000 Bytes.
du(1) uses base 2, so "G" means 1024*1024*1024 Bytes.

https://support.apple.com/en-us/HT201402

Rainer

Re: port upgrade outdated reports weird problems with deadline and poplar

[Rainer Müller]

On 08/05/2017 12:25 AM, list_em...@icloud.com wrote:
> * readline was reported as disabled:
> 
> $ sudo port selfupdate
> Password:
> --->  Updating MacPorts base sources using rsync
> MacPorts base version 2.4.0 installed,
> MacPorts base version 2.4.1 downloaded.
> --->  Updating the ports tree
> --->  MacPorts base is outdated, installing new version 2.4.1
> Warning: Disabling readline support due to readline in /usr/local
> 
> There is no readline directory in /usr/local.

This is just about base itself. The interactive port(1) command will not use
readline. It has nothing to do with ports you install.

> * I next ran $ sudo port upgrade outdated which resulted in:
> 
> --->  Computing dependencies for poppler
> --->  Fetching archive for poppler
> --->  Attempting to fetch poppler-0.56.0_0.darwin_15.x86_64.tbz2 from 
> https://packages.macports.org/poppler
> --->  Attempting to fetch poppler-0.56.0_0.darwin_15.x86_64.tbz2 from 
> http://sea.us.packages.macports.org/macports/packages/poppler
> --->  Attempting to fetch poppler-0.56.0_0.darwin_15.x86_64.tbz2 from 
> http://kmq.jp.packages.macports.org/poppler
> --->  Fetching distfiles for poppler
> --->  Attempting to fetch poppler-0.56.0.tar.xz from 
> https://distfiles.macports.org/poppler
> --->  Verifying checksums for poppler
> --->  Extracting poppler
> --->  Configuring poppler
> Error: Failed to configure poppler, consult 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.56.0/config.log
> Error: Failed to configure poppler: configure failure: command execution 
> failed
> Error: See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_poppler/poppler/main.log
>  for details.
> 
> The referenced log file is attached. It mentions a problem loading 
> libreadline as such (thus the mention of readline above):
> 
> :info:configure dyld: Library not loaded: /opt/local/lib/libreadline.6.dylib

The problem is caused by /opt/local/bin/gawk, which is still linked against the
old libreadline. However, gawk is not in the dependency chain, but just picked
up opportunistically by the configure script.

The solution is to upgrade gawk first. Run the following port command to check
your MacPorts installation for linking problems and then fix them. This should
upgrade or rebuild gawk.
  $ sudo port rev-upgrade

If that does not help at all for some reason, force a manual upgrade/rebuild of
this particular port:
  $ sudo port -ns upgrade --force gawk

Afterwards you should be able to upgrade the outdated ports as usual.

Rainer

Re: [MacPorts] #54469: problem using python 3.6 in Sierra 10.12.5/Xcode 8.3.3

[Rainer Müller]

On 2017-07-12 17:40, pagani laurent via macports-users wrote:
> My XCode info window says I have 8.3.3
> When I run softwareupdate :
> 
> Lorenzo>softwareupdate --list
> Software Update Tool
> 
> Finding available software
> No new software available.
> 
> it finds nothing to update. So my CLT should be uptodate. I don’t understand 
> why python3.6 is finding an older version.

Did you install CLT at all?
Try to trigger an installation with 'xcode-select --install'.

Rainer