Re: Ubuntu 18.04.4 on older Apple hardware

[db]

On 5 Apr 2020, at 14:00, macports-users-requ...@lists.macports.org wrote:
> Message: 1
> Date: Sun, 5 Apr 2020 01:21:40 -0700
> From: Ken Cunningham 
> To: macports-users@lists.macports.org
> Subject: Ubuntu 18.04.4 on older Apple hardware
> Message-ID: 
> Content-Type: text/plain; charset=us-ascii
> 
> Although many here, including me, are focused on bringing current software to 
> older Apple hardware within the constraints of the software capabilities last 
> available on that OS version, there is another alternative; to install a 
> current version of linux, such as Ubuntu, on those systems. I spent some time 
> doing that on an older MacBook 2,1 today, and I was pleasantly surprised at 
> the success, in the end.
> […]

Did you try a current version of macOS on top of ESXi? I'd be curious if anyone 
has tested this setup and how is the performance.

Re: macports-users Digest, Vol 150, Issue 4

[db]

On 4 Feb 2019, at 13:00, macports-users-requ...@lists.macports.org wrote:
> Message: 5
> Date: Sun, 3 Feb 2019 20:24:48 -0800
> From: Al Varnell 
> To: James Linder 
> Cc: macports-users@lists.macports.org
> Subject: Re: browser recomendations
> Message-ID: <8d355b58-5608-452d-9dc8-216c6015a...@mac.com>
> Content-Type: text/plain; charset="utf-8"
> 
> I would stay away from Google Chrome. Takes up lots of room, many adware 
> vulnerabilities and Google tracking is alive and well.

Let's throw ungoogled-chromium [1] to the pit. It's Google Chromium, sans 
integration with Google.

[1] https://github.com/Eloston/ungoogled-chromium

Re: How Mojave-ready is MacPorts?

[db]

On 12 Nov 2018, at 22:32, Ryan Schmidt  wrote:
> What we really want is a web site where this information can more easily be 
> seen.

> I don't really want the public making massive numbers of http requests to the 
> buildmaster (which is what the script would do)

I just want that every build reports its failure somewhere I can query a list 
of failed builds from — that should certainly not be a large one, neither 
number nor size. So from your answer I'll assume that I cannot get that info 
from the JSON API.

Re: How Mojave-ready is MacPorts?

[db]

On 11 Nov 2018, at 13:00, macports-users-requ...@lists.macports.org wrote:
> Message: 11
> Date: Sat, 10 Nov 2018 15:27:51 -0600
> From: Ryan Schmidt 
> To: Dave Horsfall 
> Cc: MacPorts Users 
> Subject: Re: How Mojave-ready is MacPorts?
> Message-ID: <5035eaa0-bd67-48d0-aae3-57af03245...@macports.org>
> Content-Type: text/plain; charset=us-ascii
> 
> […]
> I'll probably need to write a script to pull all the failures out of the 
> buildbot logs, since we don't have anything set up to do that yet. If there 
> are ports you want to use, check whether any issues are filed against them in 
> Trac before upgrading the OS.
> […]

Whatever you write, could you add it to macports-contrib? I thought myself to 
pull all failures to know beforehand if and what should/could be upgraded from 
time to time, but it remains in my todo. It's a missing feature of MacPorts, at 
least for those that build from source. Is this information available throught 
the JSON API [1]?

[1] https://build.macports.org/json/help

Re: portindex fails due to portfile parsing

[db]

On 19 Mar 2018, at 16:56, Ryan Schmidt  wrote:
> Probably an unintended consequence of one of my changes last month.
> What version of macOS and what version of Xcode are you using?

OS X 10.8.5, Xcode 5.1.1.

portindex fails due to portfile parsing

[db]

Today I tried syncing and it failed, see log below. It succeeded when I moved 
the portfile away. Base is from source.


$ sudo port -v sync
--->  Updating the ports tree
Synchronizing local ports tree from file:///opt/local/myports
Creating port index in /opt/local/myports

Total number of ports parsed:   0 
Ports successfully parsed:  0 
Ports failed:   0 
Up-to-date ports skipped:   80

Synchronizing local ports tree from 
file:///opt/local/var/macports/sources/github.com/macports/macports-ports/
Current branch master is up to date.
Creating port index in 
/opt/local/var/macports/sources/github.com/macports/macports-ports
Error: Unable to determine location of a macOS SDK.
Failed to parse file editors/textmate2/Portfile: can't read 
"configure.sdkroot": Unable to determine location of a macOS SDK.

Total number of ports parsed:   1 
Ports successfully parsed:  0 
Ports failed:   1 
Up-to-date ports skipped:   19396

Command failed: /opt/local/bin/portindex 
/opt/local/var/macports/sources/github.com/macports/macports-ports
Exit code: 1
Error: updating PortIndex for 
file:///opt/local/var/macports/sources/github.com/macports/macports-ports/ 
failed

telling devs about macports installation alternative - was Re: Is there and "rdist" for Mac?

[db]

On 18 Mar 2018, at 23:28, ↪︎nudge <nudge...@fastmail.fm> wrote:
> On Sun, 18 Mar 2018, at 23:08, db wrote:
>> Good to know. Unfortunately, although gitless is already in MP, the 
>> developer doesn't mention it, but alas, HB 
>> (https://github.com/sdg-mit/gitless#installing-via-homebrew-macos-only).
> Unless I'm mistaken that text was added by a third party via a github pull 
> request in November 2016 and anyone wishing to add MP can do likewise.

The point is, a port maintainer or submitter can send a PR or contact a dev to 
indicate that there's an alternative installation via macports, if he's so 
inclined to.

Re: Is there and "rdist" for Mac?

[db]

On 17 Mar 2018, at 20:48, ↪︎nudge  wrote:
> Another option worth considering
> http://gitless.com/

Good to know. Unfortunately, although gitless is already in MP, the developer 
doesn't mention it, but alas, HB 
(https://github.com/sdg-mit/gitless#installing-via-homebrew-macos-only).

Re: index warning and bash-completion

[db]

On 11 Mar 2018, at 04:01, Ryan Schmidt <ryandes...@macports.org> wrote:
> On Mar 10, 2018, at 17:47, db wrote:
>> Btw, how can I change the two-week period for the warning. I couldn't find 
>> an option in macports.conf, either to change the period or to suppress it 
>> altogether.
> I don't think we offer any options to configure that. We want users to stay 
> up to date; we don't want to field bug reports about problems we've already 
> fixed.

I think I read about such an option a couple of years ago, but couldn't find 
anything now. Anyway, if there's actually none I suppose I could change it 
myself and have other means to remind me about when I want to resync.

https://github.com/macports/macports-base/blob/1e9e6f19670b22a47b3cc2bb9a9da985986b6203/src/macports1.0/macports.tcl#L1235

Re: index warning and bash-completion

[db]

On 10 Mar 2018, at 23:15, Clemens Lang  wrote:
>  
> https://github.com/macports/macports-ports/blob/master/sysutils/bash-completion/files/port
> so if you have time you could try modifying it to drop stderr into nirvana 
> and submit a pull request for that.

Ok, I'll have to take a closer look, as it doesn't show for certain actions 
like info.

Btw, how can I change the two-week period for the warning. I couldn't find an 
option in macports.conf, either to change the period or to suppress it 
altogether.

Re: index warning and bash-completion

[db]

On 10 Mar 2018, at 20:05, Ryan Schmidt  wrote:
> Are your port definitions in fact more than two weeks old?

Yes, but I'd expect the warning after I actually ran the command.

index warning and bash-completion

[db]

bash-completion for port outputs stderr on pressing tab, right before it 
completes a word, on certain actions like contents.

$ port contents bash-complWarning: port definitions are more than two weeks 
old, consider updating them by running 'port selfupdate'.
etion

Can anyone reproduce it?

Re: request for port peg command, to lock down a port at the currently installed version

[db]

On 6 Mar 2018, at 15:50, Ken Cunningham  wrote:
> port peg PORTNAME

brew pin FORMULA? There shouldn't be shame in mentioning it. As Arno pointed 
out, it gets tricky with deps, it's eventually overridden if necessary.

As I raised in another topic, port upgrade could preempt building ports with 
open defects by querying trac first.

On 6 Mar 2018, at 16:16, Ken Cunningham  wrote:
> How do you use --no-upgrade, exactly?

He might be referring to upgrade action's switches -n (no dependencies) and -R 
(dependents), which is different from peg.

Re: running macports along with homebrew

[db]

On 6 Mar 2018, at 10:49, Ryan Schmidt  wrote:
> The portindex indexes Portfiles, not portgroups. So the port's version must 
> be set in the Portfile, not anywhere else.

Would then portindex fail if the port's version in the portfile is a variable 
set to a command?

Re: running macports along with homebrew

[db]

On 6 Mar 2018, at 02:34, Ryan Schmidt <ryandes...@macports.org> wrote:
> On Mar 5, 2018, at 05:43, db wrote:
>> As I said in my previous post, you can get HEAD's hash with 'git ls-remote 
>> --heads'. And store it somewhere.
> Who are you suggesting should run this command and when? The port maintainer? 
> The user trying to install the port? MacPorts itself?

MacPorts itself. I haven't tried it yet, but I suppose gh_version could be set 
to the value returned by that command. Then the only difference from a devel 
port that uses portgroup github would be the hardcoded date.

Re: running macports along with homebrew

[db]

On 5 Mar 2018, at 11:39, Ryan Schmidt  wrote:
> hash+date is specific, predictable, repeatable. The portfile developer tests 
> a specific hash+date, and when satisfied, commits it to make it available to 
> MacPorts users.

As I said in my previous post, you can get HEAD's hash with 'git ls-remote 
--heads'. And store it somewhere. Devel ports that use hash+date only add the 
date, and I doubt they are much tested. But hey, I'm glad Ken found this and I 
can use it locally at least.

Re: running macports along with homebrew

[db]

On 4 Mar 2018, at 05:16, Ken Cunningham  wrote:
>github.setupauthor project HEAD
>checksum {}

Thanks, Ken. I didn't think it'd be that easy. Only caveat is that it fails the 
livecheck and there's no way to correlate HEAD to a date. The commit could be 
read with 'git ls-remote --heads https://github.com/author/repo | cut -f 1'.

> MacPorts could easily incorporate this if it wanted to, but it's a specific 
> decision not to allow it. You can use this on your own devel ports if you'd 
> like to.

I know, but I don't see how HEAD is pragmatically that much different from the 
devel ports that use a hash+date instead.

Re: how to make a portfile for a github project?

[db]

On 3 Mar 2018, at 00:48, Mojca Miklavec  wrote:
> At some point this documentation about the GitHub PortGroup should end up in 
> the online guide:
>https://github.com/macports/macports-guide/pull/12/files

Yeah, in the long meantime 
/opt/local/var/macports/sources/github.com/macports/macports-ports/_resources/port1.0/group/github-1.0.tcl.

Re: Search for a MacPorts Mascot: looking for talented artists

[db]

On 21 Feb 2018, at 17:32, Mojca Miklavec  wrote:
> Something in the spirit of ...
>http://en.wikifur.com/w/images/4/46/Hexley_fork_450.png

I like that MacPorts lacks a mascot identity. But if you really need, want one, 
then I probably choose Darwin's Hexley. Another that I'd consider, and since 
there're already 20K+ ports, is some sort of behemoth, e.g.

http://monster.wikia.com/wiki/Behemoth
https://alexgilble.deviantart.com/art/Behemoth-The-Land-Monster-413063725

Re: running macports along with homebrew

[db]

On 14 Feb 2018, at 20:46, Ken Cunningham  
wrote:
> In a recent poll 
> , homebrew was 
> recommended 375 to 25 over MacPorts.
> Most developers who offer their software for download and building manually 
> recommend homebrew for supporting software. Almost nobody recommends MacPorts.

I couldn't care less about polls, but I do care that quite often, when I find 
an interesting piece of software at github, the developer recommends homebrew. 
Another point is port submissions that gather dust (see vagrant and ELK 
mentioned earlier). And although I got accustomed to MacPorts and shun 
homebrew's alky lingo, I rather have latter as a fallback and not the other way 
around.

Re: running macports along with homebrew

[db]

On 14 Feb 2018, at 19:20, Ken Cunningham  
wrote:
> For git, I'd have to look at the github portgroup to see how to do that.
> But as you heard from Ryan, it appears it's not ever going to make it into 
> macports in general…

Yeah, the thing is having at the very least the feature for local use.

> Well, my guess is that if you just downloaded macports current source 
> archive, it would just build and install on linux.

I wonder what the requirements would be just to give it a try.

Re: running macports along with homebrew

[db]

On 14 Feb 2018, at 14:56, Ryan Schmidt  wrote:
> I'm aware of "cask" being a feature of Homebrew. If that's what you're 
> referring to, what does the feature do / what do you want MacPorts to do in 
> regard to this?

Manage (and here the terminology gets trickier) more generally available 
application bundles, from DEVONthink to ungoogled chromium.

> We will definitely never offer a user-facing feature for building the HEAD 
> version of a port's code.

I still think the feature should be added, specially for devel ports, even if 
it's not supported when problems arise.

>> LinuxPorts (analog to Linuxbrew),
> What does this do / what do you want this to do?

I haven't tried it yet, but I guess I could install the same or similar set of 
tools using the same package manager interface.

> I see a submission for rb-vagrant; is that the same thing?
> https://trac.macports.org/ticket/43225

> elasticsearch is in MacPorts.
> The submissions of logstash and kibana are here:
> https://trac.macports.org/ticket/44824
> https://trac.macports.org/ticket/44822

I couldn't find elasticsearch in macports. The submissions for vagrant, 
logstash and kibana are abandoned or work in progress since more that 3 years.

Re: running macports along with homebrew

[db]

On 13 Feb 2018, at 19:52, Ken Cunningham  
wrote:
> 1. cask:
> […]
> I think nobody finds this in general to be all that magical or useful though, 
> and so nobody bothers to spend any time on building these sorts of Portfiles.
> You want Adobe Air? Just go to the website and install it.

It's going to every site n times vs. one command to install n applications plus 
another to uninstall them and their related files (plists, caches).

> 2. HEAD variants.
> This is a specific MacPorts decision, based on the "reproducible builds" 
> philosophy. It's open for debate at times, I would think.  It's easy to do 
> it, but we just don't do it on purpose.
> I have overridden this and allowed a +HEAD variant on one occasion at the 
> request of a heavy user of the software (see the widelands Portfile).
> Anyone with a passing level of MacPorts knowledge can bump a Portfile to the 
> latest commit on their own in a few seconds, esp if it uses the github 
> Portgroup. I do this all the time.
> This could be added quite easily if MacPorts wanted to do it -- a small 
> change in the github portgroup would likely suffice to add a +HEAD variant to 
> all github ports.

I have some devel ports locally, that I have to manually update for the latest 
commit, instead of automatically updating for the current master. I have to 
check that wielands port.

> 3. LinuxPorts
> I think Rene has this working (@RJVB). Haven't tried it, though. I bought a 
> couple of linux machines for this reason, but just ran out of time to play 
> with them.

Do you mean this repo [1] or am I missing something?

[1] https://github.com/RJVB/lnxports

> 4. Vagrant and ELK
> I can take a look at these.

There's a ticket for vagrant. I used it as a starting point, but eventually 
gave up. And, if you have a chance and could review the portfiles I submitted 
for ipfs and stem, a while ago.

Re: running macports along with homebrew

[db]

On 13 Feb 2018, at 07:01, Ken Cunningham  
wrote:
> If there is anything worth having in MacPorts that is in Homebrew but not 
> MacPorts, just ask for it.

I'm trying homebrew as a fallback for MacPorts, but since you said anything, 
here's a wish list: cask, building from HEAD, LinuxPorts (analog to Linuxbrew), 
and specific ports: vagrant and ELK stack for starters. Just daydreaming…

Re: running macports along with homebrew

[db]

On 12 Feb 2018, at 23:08, Jeremy Lavergne  wrote:
> MacPorts can deny any access to Homebrew during builds in trace mode.
> Less invasive than renaming files or folders.
>> port -t install PORTNAME

Depending on who you ask, there's much overhead, in any case, >%50.

Re: running macports along with homebrew

[db]

On 12 Feb 2018, at 16:13, Mojca Miklavec  wrote:
> Exceptions might occur for formulas that put stuff outside of /usr/local

AFAIR from the documentation everything that's built locally is contained in 
so-called cellars under its prefix, so I could just rename it (no SIP or SIP 
disabled) or move it away (SIP doesn't allow renaming of /usr/local even after 
clearing flags). I couldn't figure out another way, e.g., by setting users and 
permissions to keep them out of each other's way though.

Re: running macports along with homebrew

[db]

Would it suffice to rename /usr/local during build time to avoid any conflicts? 
I ask because I just want to make sure that I'm not missing anything else.

Re: Build Failure on ports-10.8_x86_64_legacy: lowdown

[db]

https://trac.macports.org/ticket/51516#comment:19

On 24 Jan 2018, at 18:10, Jan Stary  wrote:

> Looking at
> https://build.macports.org/builders/ports-10.8_x86_64_legacy-builder/builds/49810/steps/install-port/logs/stdio
> it seems that the buildbot failed to even download the tarball:
> 
> --->  Attempting to fetch lowdown-0.3.1.tar.gz from 
> https://kristaps.bsd.lv/lowdown/snapshots/
> 
> Error: Failed to fetch lowdown: error:140770FC:SSL 
> routines:SSL23_GET_SERVER_HELLO:unknown protocol
> 
> Does the buildbot's downloader have a problem with https?
> 
>   Jan
> 
> 
> On Jan 24 15:36:06, build...@macports.org wrote:
>> Status:   Failure
>> Build slave:  ports-10.8_x86_64_legacy
>> Full logs:
>> https://build.macports.org/builders/ports-10.8_x86_64_legacy-watcher/builds/12098
>> Build reason: The SingleBranchScheduler scheduler named 'ports' triggered 
>> this build
>> Port list:lowdown
>> Subport list:
>>  - lowdown
>> Variants: None
>> Revision: 3e6e14df71146d6c3a97f56968ceb42b45d9d076
>> Build time:   0:00:33
>> Author:   Jan Starý 
>> 
>> Log from failed builds:
>>  Building 'lowdown' ... [ERROR]
>>  > maintainers: h...@stare.cz.
>> 
>> Broken ports:
>>  - lowdown
>> 
>> Responsible maintainers:
>>  - h...@stare.cz
>> 
>> Links to individual build jobs:
>> - ports-10.8_x86_64_legacy-builder #49810
>>  
>> https://build.macports.org/builders/ports-10.8_x86_64_legacy-builder/builds/49810
>> 
>> -- 
>> Best regards,
>> MacPorts Buildbot
>> https://build.macports.org/
>> 

Re: scp ignores case in filenames?

[db]

On 19 Jan 2018, at 17:09, "Richard L. Hamilton"  wrote:
> At a mere guess, I'd say there'd be very little of that.  Most of the code 
> originated on Linux or one of the *BSD's; and most of them would default to 
> case-sensitive filesystems, even if they had the option.  So their code would 
> be well-behaved.

I agree — I had rather applications with a GUI in mind.

Re: scp ignores case in filenames?

[db]

On 19 Jan 2018, at 15:23, Vincent Habchi  wrote:
> I’ve been working for years on case-sensitive HFS+/APFS file systems (coming 
> from BSD Unix) and never encountered any problem. Only PyCharm needs an extra 
> configuration line to be inserted. But that’s the only side effect I ever 
> stumbled upon.

A while ago I read about some applications having problems, namely Steam, 
CrashPlan, Adobe Creative Suite, Norton AV. But since this is MacPorts, I 
wonder if anyone has had problems specifically with a port not working and 
crashing.

Re: trace mode by default

[db]

On 9 Jan 2018, at 08:52, Joshua Root  wrote:
> 'porttrace yes' in macports.conf should do it. Note that then there's no way 
> to turn it off from the command line.

Can not all ports be built in trace mode? Clemens mentioned go.

Do you have any numbers for the performance penalty using port with trace on?

trace mode by default

[db]

I couldn't find this neither on port's manpage nor in macports.conf.

Is there an option to set trace mode by default?

Could the performace penalty be roughly quantified?

meltdown and spectre

[db]

In case anyone hasn't heard of it yet,

https://meltdownattack.com/
https://lwn.net/Articles/742999/

Re: livecheck timeout

[db]

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?

Re: livecheck timeout

[db]

On 23 Nov 2017, at 16:52, Ryan Schmidt  wrote:
> $ time port livecheck gnutls
> real  0m1.252s
> user  0m0.196s
> sys   0m0.079s

Hmm…master_sites was updated, 
https://github.com/macports/macports-ports/commit/1ca7e7e669f82b834b993270053c0b9331caf526#diff-7672b36dcb72869ed4708bfef213e57d.

Is there a timeout for ftp?

Re: livecheck timeout

[db]

On 23 Nov 2017, at 15:14, Rainer Müller  wrote:
> The connect timeout of 30 seconds for downloads using libcurl is hardcoded in 
> base [1] and cannot be configured.
> [1]
> https://github.com/macports/macports-base/blob/a1e0b3bd5c062ff4d6eb1fd23badd395bdd39c7f/src/pextlib1.0/curl.c#L57

Can you tell then why is gnutls timing out after 30 minutes?

Re: livecheck timeout

[db]

On 23 Nov 2017, at 06:42, Ryan Schmidt  wrote:
> How long is too long?

30'

Re: installing binary archives as non-root user

[db]

On 18 Nov 2017, at 20:38, Ryan Schmidt  wrote:
> Yeah, really, nope. Ports are able to make decisions based on the install 
> user; some ports do different things when installing as root vs. installing 
> as a normal user.

I've been reading some of Homebrew's documentation before giving it a try and 
found out that it doesn't use root. How would you compare both approaches?

https://docs.brew.sh/FAQ.html#why-does-homebrew-say-sudo-is-bad

Re: MacPorts installation processes

[db]

On 11 Nov 2017, at 15:08, Mojca Miklavec  wrote:
> But after that the lives of the 2.4 branch and the master branch start 
> diverging. The release 2.4.3 will still be "wildly different from master". 
> The releases x.y.z where z > 0 are not created from the master branch, the 
> release 2.5.0 will come from master.
> The master branch is getting new functionality, but the release branch is 
> only getting bug fixes.

Thanks Mojca, that clears it up. I was somewhat confused by the versioning of 
master as 2.4.99.

Re: MacPorts installation processes

[db]

On 11 Nov 2017, at 10:40, Ryan Schmidt  wrote:
> "2.4.99" means some point along the way of developing 2.5.x, but not any 
> particular point; you can update your git clone and rebuild to get a newer 
> "2.4.99".

Bear with me. If I understood correctly, if I checkout a hypothetical 2.4.3 
commit I get v2.4.3, but if I checkout the commit right after that one I should 
get v2.4.99 and as such a version almost equivalent to 2.4.3?

Re: MacPorts installation processes

[db]

On 10 Nov 2017, at 23:18, Mojca Miklavec <mojca.miklavec.li...@gmail.com> wrote:
> On 10 November 2017 at 23:00, db wrote:
>> Is it possible to install a snapshot from master and later upgrade to a 
>> release?
> Only to a release that's derived from master. That is: if you install
> a snapshot from master now, you will only be able to go "back" to one
> of the 2.5.x releases.

I installed master from past 11th of October. If there were a 2.4.3 release, 
could I upgrade to it, or only just 2.5.x? I ask because I noticed port version 
returns 2.4.99.

Re: MacPorts installation processes

[db]

On 10 Nov 2017, at 14:04, Rainer Müller  wrote:
> Unfortunately, there is no way to roll back these changes to the registry. 
> Either you have to keep using development versions, or you have to uninstall 
> MacPorts completely, then reinstall the latest stable release and all ports 
> from scratch. I recommend the latter.

Is it possible to install a snapshot from master and later upgrade to a release?

files manually installed in $prefix

[db]

I wrote a plugin file for a port and put it in the same directory as the 
default ones, because I considered it convenient at that time, not realising 
that it could be invoked by its full path from another location.

How can I get files manually installed in $prefix? I'm asking out of curiosity. 
I suppose I could get them by ownership if it wasn't modified or, less 
practically, by uninstalling installed and checking for remnants. Comparing 
recursive ls and port contents installed would be tricky. Any other ways?

Re: buildbot build time

[db]

On 27 Oct 2017, at 15:54, Ken Cunningham  
wrote:
> https://wiki.gentoo.org/wiki/Genlop

Thanks Ken, I'll keep that in mind. My purpose was a much modest shell script 
that parses outdated ports and retrieves build or cpu time (or any stat that 
could give an estimate) from the builders and thereupon makes a decision to 
upgrade or delay the task and notify the user.

Re: buildbot build time

[db]

I still think some indication of build time is useful, for example, _relative_ 
to other ports that I might estimate or know its build time. For how long is 
build information retained, like in 
https://build.macports.org/builders/ports-10.13_x86_64-builder/builds/10627 ?

buildbot build time (was: establish installed dependency not in portfile)

[db]

On 25 Oct 2017, at 07:35, Mojca Miklavec <mojca.miklavec.li...@gmail.com> wrote:
> On 23 October 2017 at 10:40, db wrote:
>> On 9 Oct 2017, at 12:46, Mojca Miklavec wrote:
>>> That info is easy to read and collect from the buildbot. The keyword is: 
>>> "to collect".
>> I checked https://build.macports.org/json/help, but couldn't find it.
> For example:
> - 
> https://build.macports.org/json/builders/ports-10.13_x86_64-builder/builds/10627?as_text=1
> which corresponds to
> - https://build.macports.org/builders/ports-10.13_x86_64-builder/builds/10627
> 
> The idea would be to write a script to iterate through all numbers
> from 1 on and store results somewhere.
> 
> If you want the time estimate specifically, here might be the relevant
> information:
> 
>  "name": "install-port",
> ...
>  "times": [
>1508901749.648058,
>1508901850.387383
>  ]
> 
> I guess the difference represents the seconds spent building the port.

Thanks. I was searching for "to collect" there and in base, to no avail.

Those are the start/end epochs that I need to subtract, for a single port.

How can I correlate portname to buildnumber?

Re: macports owns my user folder in most of my backups

[db]

On 15 Oct 2017, at 23:16, Lenore Horner <lenorehor...@sbcglobal.net> wrote:
> On Oct 15, 2017, at 03:28, db <iams...@gmail.com> wrote:
>> Check this post for some background, 
>> https://lists.macports.org/pipermail/macports-dev/2017-September/036431.html.
> Well that tells me what probably happened but unfortunately leaves me 
> clueless about how to fix or get around the problem.  Is there a way to log 
> onto my machine as the macports user so that my backup thinks I own the 
> files?  Or is that user not going to be able to open folders owned by system? 
>  At the moment, even using sudo from the command line will not let me see the 
> contents of my backed-up user directories.

Check pondini.org.

Re: macports owns my user folder in most of my backups

[db]

On 15 Oct 2017, at 00:41, Lenore Horner  wrote:
> I use Time Machine to backup my hard drive to an external drive.  At some 
> point (and I don’t know when) MacPorts became the owner of my folder in Users 
> for most or all of my backups.  Folders above that level are owned by the 
> system.  sudo chown will not change those permissions (the response is 
> operation not permitted).  Is there any way to fix this or are these backups 
> useless?

Check this post for some background, 
https://lists.macports.org/pipermail/macports-dev/2017-September/036431.html.

Re: High Sierra and MacPorts

[db]

On 12 Oct 2017, at 12:51, Ryan Schmidt  wrote:
> https://lists.macports.org/pipermail/macports-users/2017-September/043743.html
> The High Sierra buildbot worker is still busy building ports. If you want to 
> have a higher probability that you can receive binaries from us, instead of 
> having to build from source, don't upgrade yet. Same goes for High 
> Sierra-specific build failures of specific ports that we haven't fixed or 
> even discovered yet. If you want a higher probability that we find and fix 
> those problems, wait.

In which order is the High Sierra buildbot building the binaries? How long does 
it take for all ports to build, in case it's set to do so?

Re: cannot sync - pulling is not possible because you have unmerged files

[db]

On 10 Oct 2017, at 17:42, "Daniel J. Luke"  wrote:
> If the OP does have a need to be syncing from the git repository, he should 
> be able to manage any conflicts like this without help from the list.

As I said, I didn't modify the checkout.

Re: cannot sync - pulling is not possible because you have unmerged files

[db]

On 10 Oct 2017, at 15:17, Chris Jones  wrote:
> So one or more of those modifications are your problem. The modifications in 
> your checkout conflict with something coming in from the sync. You need to 
> resolve these conflicts before trying again.

I didn't modify the checkout: I installed base from source four days ago, 
synced, upgraded and now cannot sync. I installed that same source on a VM and 
it syncs normally. I don't know why git status is listing those modifications.

Re: establish installed dependency not in portfile

[db]

On 9 Oct 2017, at 16:17, Rainer Müller  wrote:
> 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.

Exactly that, historical data and obsolete ports.

Re: establish installed dependency not in portfile

[db]

On 9 Oct 2017, at 11:16, Chris Jones  wrote:
> Why do you always build from source instead of use the tarballs when 
> available ? Its not entirely reasonable on one hand to complain about build 
> times, and at the same time turn off a feature designed to avoid them...

No buildbot for 10.8 and libc++.

Re: establish installed dependency not in portfile

[db]

On 8 Oct 2017, at 22:05, Ryan Schmidt  wrote:
> No, we don't have anything that estimates build time.

Would a feature request make sense? Having build time and open tickets 
(defect/platform) when running `port outdated` would spare quite a few 
headaches. As of now, I have to pin compilers locally to avoid rebuilding for 
every release bump and review the list of outdated ports and eventually query 
for open tickets. Getting more information from ports would certainly help 
automatize updating.

Re: establish installed dependency not in portfile

[db]

On 8 Oct 2017, at 21:19, Ryan Schmidt <ryandes...@macports.org> wrote:
> On Oct 8, 2017, at 05:17, db wrote:
>> Since py27-numpy is the only port installed requiring gcc7, I rather choose 
>> gcc6 which is used by many others instead.
> You can do that, but since gcc7 is the latest stable version of gcc, ports 
> that currently use gcc6 by default will be updated over time to use gcc7 
> instead.

Until then, since I always build from source, I rather save CPU time. Speaking 
of which, getting back to my first post, is there any way to query the build 
time from the buildbots? It'd be useful to estimate when to do an update.

Re: establish installed dependency not in portfile

[db]

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?

Re: establish installed dependency not in portfile

[db]

On 7 Oct 2017, at 15:41, db <iams...@gmail.com> wrote:
> On 7 Oct 2017, at 15:15, Jeremy Lavergne <jer...@lavergne.me> wrote:
>> Something like `port dependents gcc7`
> I forgot to mention it.
> $ port rdependents gcc7
> gcc7 has no dependents.

It seems that gcc7 comes from portgroup compilers. From the logs I kept when 
upgrading, gcc7 seems to never have been built for building py-numpy before.

Re: establish installed dependency not in portfile

[db]

On 7 Oct 2017, at 15:15, Jeremy Lavergne  wrote:
> Something like `port dependents gcc7`

I forgot to mention it.

$ port rdependents gcc7
gcc7 has no dependents.

establish installed dependency not in portfile

[db]

I updated my ports and realised that gcc7 was built, but couldn't establish for 
which port it was necessary. I thought something like `port cat installed | 
grep '^name\|gcc7'` would help reveal it. Then I tried `port rdeps installed | 
grep ' ports\|gcc7'` and noticed py27-gnuplot, py27-numpy and scapy needed it, 
but by skimming through their respective files I couldn't establish the 
dependency.

How can I check if a dependency that requires such long build time is required 
beforehand?

uninstall inactive port breaks active port

[db]

py-readline was replaced by py-gnureadline

https://github.com/macports/macports-ports/commit/9beeded98a3eba28030e4993153a037366f5bda5

Can I safely uninstall it?


$ port installed inactive
The following ports are currently installed:
  py27-readline @6.2.4.1_1
$ 
$ sudo port uninstall inactive
Note: It is not recommended to uninstall/deactivate a port that has dependents 
as it breaks the dependents.
The following ports will break: scapy @2.3.3_0
Continue? [y/N]: n
--->  Cleaning py27-readline
$ 
$ port rdeps scapy | grep readline
  py27-gnureadline
  readline
$ 
$ port rdependents py27-readline
The following ports are dependent on py27-readline:
  scapy


--->  py27-readline is replaced by py27-gnureadline
--->  Computing dependencies for py27-gnureadline
--->  Fetching distfiles for py27-gnureadline
--->  Attempting to fetch 
python-gnureadline-38f917de65ff089a22d551775f41a7300eb13010.tar.gz from 
http://nue.de.distfiles.macports.org/py-gnureadline
--->  Verifying checksums for py27-gnureadline  
 
--->  Extracting py27-gnureadline
--->  Applying patches to py27-gnureadline
--->  Configuring py27-gnureadline
--->  Building py27-gnureadline
--->  Staging py27-gnureadline into destroot
--->  Installing py27-gnureadline @6.3.3-20151013_0
--->  Cleaning py27-gnureadline
--->  Unable to deactivate py27-readline @6.2.4.1_1, the following ports depend 
on it:
--->scapy @2.3.3_0+gnuplot+graphviz
Warning: Deactivate forced.  Proceeding despite dependencies.
--->  Deactivating py27-readline @6.2.4.1_1
--->  Cleaning py27-readline
--->  Computing dependencies for py27-gnureadline
--->  Activating py27-gnureadline @6.3.3-20151013_0
--->  Cleaning py27-gnureadline

Re: ffmpeg fails to configure

[db]

On 6 Oct 2017, at 23:06, Ken Cunningham  wrote:
> we should probably just search the macports database for everything that 
> requires port:openjpeg and flag them all. Almost all of them are probably 
> broken again - last openjpeg update just finished and we probably aren't done 
> cleaning up from that update …

#55023

Re: ffmpeg fails to configure

[db]

On 6 Oct 2017, at 21:52, Ken Cunningham  wrote:
> Every time openjpeg does a decimal point update, it changes the headers and 
> everything breaks. What a PITA. -- Ken

Thanks. I pinned ffmpeg 3.3.3 in my local repo. Should I file a ticket for 
3.3.4?

ffmpeg fails to configure

[db]

Could anyone please take a look at this log? It seems that ffmpeg 3.3.4 misses 
a bunch of headers on 10.8.

http://www.mediafire.com/file/u2z139htht93411/config.log

ffmpeg fails to configure

[db]

Could anyone please take a look at this log? It seems that ffmpeg 3.3.4 misses 
a bunch of headers on 10.8.

http://www.mediafire.com/file/u2z139htht93411/config.log

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

[db]

On 4 Oct 2017, at 06:00, Dave Horsfall  wrote:
> Someone (I've forgotten who) pointed out is was likely that I installed them 
> before MacPorts honoured the "requested" flag (I've had this MacBook for 
> quite a few years).

Are those ports listed in `port echo requested`?

Re: curl error:1407742E:SSL

[db]

On 3 Oct 2017, at 22:19, Ryan Schmidt  wrote:
> Once we get automatic distfile mirroring back online it will be a nonissue.

Any date? In any case, please do announce it in the lists.

Re: curl error:1407742E:SSL

[db]

On 3 Oct 2017, at 17:30, Ken Cunningham  wrote:
> Please see 

You could add it to https://guide.macports.org/#installing.macports.source .

Is it safe to just recompile MP overwriting the package installation?

Re: curl error:1407742E:SSL

[db]

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.

curl error:1407742E:SSL

[db]

I'm getting the error below when fetching from pypi. Can I force use of MP's 
curl instead of OS X (10.8)'s?

--->  Attempting to fetch cffi-1.11.0.tar.gz from 
https://distfiles.macports.org/py-cffi
DEBUG: Fetching distfile failed: The requested URL returned error: 404
--->  Attempting to fetch cffi-1.11.0.tar.gz from 
https://files.pythonhosted.org/packages/source/c/cffi
DEBUG: Fetching distfile failed: error:1407742E:SSL 
routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version

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

[db]

On 2 Oct 2017, at 15:56, Carlo Tambuatco  wrote:
> Is —follow-dependencies smart enough to uninstall dep(A), but not dep(A,B,C)…?

From port's man page:
To uninstall portname and then recursively uninstall all ports it depended on, 
use --follow-dependencies. This will not uninstall dependencies that are marked 
as requested or that have other dependents.

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

[db]

On 1 Oct 2017, at 18:57, Ryan Schmidt  wrote:
> On Oct 1, 2017, at 05:50, Carlo Tambuatco wrote:
>> Is there a way to uninstall a port and only those ports that are 
>> dependencies of just that port?
>> So I want to uninstall port A and dependencies of A: dep(A) but not 
>> dep(A,B,C,…) where 
>> dep(A,B,C…) are dependencies of A and B and C, etc…
> Not particularly.

I thought --follow-dependencies was intended for such case.

Re: xcode, clt or both

[db]

On 19 Sep 2017, at 23:06, Ryan Schmidt <ryandes...@macports.org> wrote:
> On Sep 19, 2017, at 11:40, db wrote:
>> On 19 Sep 2017, at 01:01, Ryan Schmidt wrote:
>>> For certain subsets of ports, you can get by with installing just one or 
>>> the other.
>> How can I know this beforehand? That's the reason I'm actually asking what 
>> exactly MP needs Xcode, CLT or both for. For example, if a port uses 
>> portgroup xcode, I may infer that it most certainly will need that 
>> application.
> 
> I'm not aware of a way to know in advance.

I thought I could at least assume that any port whose interface is a command 
line and whose features allegedly don't use any particular Apple framework that 
I'm aware of, wouldn't need Xcode. Is it trial and error then?

Re: xcode, clt or both

[db]

On 19 Sep 2017, at 01:01, Ryan Schmidt  wrote:
> For certain subsets of ports, you can get by with installing just one or the 
> other.

How can I know this beforehand? That's the reason I'm actually asking what 
exactly MP needs Xcode, CLT or both for. For example, if a port uses portgroup 
xcode, I may infer that it most certainly will need that application.

> Remember in the future to address your posts to 
> macports-users@lists.macports.org; the @lists.macosforge.org address is 
> deprecated.

Yeah, sorry, a glitch selecting the correct address in Mail.

Re: In a mess with libc++ libstdc++ and OSX 10.7.5 Lion

[db]

On 14 Sep 2017, at 13:25, Ian Wadham <iandw...@gmail.com> wrote:
> On 14/09/2017, at 7:57 PM, db wrote:
>> In case you have Time Machine or a clone, just restore /opt/local/ and 
>> /Applications/MacPorts/.
> Heh, heh!  Someone else suggested that and it was also one of the first 
> things I
> thought of.  But guess what.  I have TimeMachine, but my settings exclude
> backing up /opt/local and several other build/object-code areas, on the basis 
> that
> they are large and the wherewithal to re-create them is easily available 
> elsewhere.
> in source-code directories, MacPorts servers, etc.

I didn't intend to re-post a suggestion, but that one missed the second path 
(see man porthier).

I also had my prefix excluded from Time Machine until I encountered some bug in 
vim that went for weeks unresolved. Not worth the time and you can always 
delete older backups to make room in your disk. From then on I try to port 
upgrade right after a TM backup. This is just pragmatic. You could use git 
branch as others proposed, but I presume you'll end up with a full set of older 
dependencies for some ports.

You might want to try your most used tools first in a VM with 10.12 or 10.13. 
Also, in addition to the migration page, check 
https://trac.macports.org/wiki/SierraProblems.

Re: Searching macports-users Archives

[db]

On 4 Sep 2017, at 15:46, Craig Treleaven  wrote:
> http://www.mail-archive.com/macports-users@lists.macosforge.org/

http://www.mail-archive.com/macports-users@lists.macports.org/maillist.html

Re: running macports along with homebrew

[db]

On 2 Sep 2017, at 01:06, Ryan Schmidt <ryandes...@macports.org> wrote:
>> On Sep 1, 2017, at 03:22, db <iams...@gmail.com> wrote:
>> On 31 Aug 2017, at 21:34, Craig Treleaven <ctrelea...@macports.org> wrote:
>>> Gentle reminders, regularily applied, tend to cure the ‘missing ports and 
>>> updated versions’ issue.
>> It shouldn't work like that. Actually, it didn't.
> Ok. How would you like us to proceed?

You explained not long ago that everything is handled on a best-effort basis. 
Still, I think, you could have a role for new submissions and update requests 
that's assigned amongst commiters. Or am I reaching?

Re: running macports along with homebrew

[db]

On 31 Aug 2017, at 21:34, Craig Treleaven  wrote:
> Gentle reminders, regularily applied, tend to cure the ‘missing ports and 
> updated versions’ issue.

It shouldn't work like that. Actually, it didn't.

> I understand the attraction to having a command line way to check for and 
> update my major packaged applications.  But, AFAICT, it is never going to 
> work for purchased applications (Carbon Copy Cloner, Parallels Desktop, etc).

> Maybe I’m missing something important.

Yeah, searching first, http://caskroom.github.io/search. Both are there.

Re: running macports along with homebrew

[db]

On 31 Aug 2017, at 21:46, Daniel J. Luke  wrote:
> Indeed, a quick look at pacakges.macports.org indicates there are 22,957 
> binary archives available.

As of now 19944 ports. No vagrant, no stem — yet.

Re: running macports along with homebrew

[db]

On 31 Aug 2017, at 17:53, Ken Cunningham  
wrote:
> I think homebrew gets attention for two reasons.
> 
> 
> 1. a one-line copy & paste install command that is pasted into the terminal  
> (macports could / should do that too, BTW).
> 
> 2. the fact that it symlinks it's stuff into /usr/local, making it easier to 
> use it's installed products for building other software for amateurs 
> (macports could do that too).
> 
> 3. My impression is that it's not so difficult to get things accepted. If a 
> submission builds on Travis on 10.10 to 10.12, it's usually in homebrew 
> within a day or so, it seems.
> 
> On the other hand:
> 
> 1. MacPorts, in general, pays more attention to the details. There is 
> significantly more OCD in the submission reviews, which is both very good and 
> sometimes deflating. But a port in macports is very trustworthy, and in the 
> end, that is the single most important thing.
> 
> 2. MacPorts has a couple of real superstars who can fix things it seems 
> nobody else can fix. So we have gcc6 working perfectly well all the way back 
> to Tiger, for example, and the latest-greatest clang / llvm features, etc.

The first three points are certainly not what appeals to me from homebrew. I do 
agree on the latter two though.

To give you a couple of examples: vagrant — there's a ticket but the dev seems 
to haven't finished it, and ipfs — I wrote the port and the ticket's now in the 
twilight zone, no feedback whatsoever (I have other portfiles that I don't even 
bother submitting). Both are in homebrew. And as I mentioned earlier, cask has 
already 3.7K binaries to manage, which is quite convenient.

I don't want to get rid of MacPorts, but complement it without breaking 
anything.

Re: running macports along with homebrew

[db]

On 31 Aug 2017, at 15:35, Craig Treleaven  wrote:
> What is it that you want that MacPorts does not provide?

As I said in my OP, missing ports and updated versions, cask...

Re: running macports along with homebrew

[db]

On 30 Aug 2017, at 10:16, Richard L. Hamilton  wrote:
> the newer, safer convention is distinct subdirectories of /opt, for each 
> package or set of commonly managed packages; thus, MacPorts by default uses 
> /opt/local, XQuartz uses /opt/X11 (for the stuff that's not elsewhere), etc.

Is it a tacit convention? I couldn't find a source myself.


Thank you all for the useful information. It seems only Umesh is actually using 
homebrew though.

Re: running macports along with homebrew

[db]

On 29 Aug 2017, at 23:39, Mojca Miklavec  wrote:
> But most important: in case you do end up with two systems, make sure to 
> quadruple check before submitting any bug reports to make sure that the error 
> is not due to the packages intermixed with each other.

I'm well aware of that. At any rate I would try in a clean VM first before 
submitting any report.

Re: running macports along with homebrew

[db]

On 29 Aug 2017, at 23:24, Ryan Schmidt  wrote:
> The best practice is not to do that. We don't support it. It can cause you 
> problems that we don't want to spend time investigating, because they 
> wouldn't be problems if you hadn't also used a second package manager.

You already made the same point in the list years ago.

Could you please summarize the problems one could encounter?

Aren't these actually only related to homebrew using /usr/local/?

Re: running macports along with homebrew

[db]

On 29 Aug 2017, at 19:27, Ken Cunningham  
wrote:
> FYI, it's actually not hard to write a portfile to install a binary, and it's 
> useful in some cases.

Yes, but cask already has 3.7K. Convenient, isn't it?

> But MacPorts so far has explicitly stated they are not interested in getting 
> into this line of software package management at present.

Where? Why?

Re: running macports along with homebrew

[db]

On 29 Aug 2017, at 14:55, Umesh Singla  wrote:
> /opt/local/bin:/opt/local/sbin:/usr/local/gradle/gradle-2.11/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin
> 
> It simply looks for the packages in the default macports directory 
> (/opt/local) first and then others, I guess. Though I constantly run into 
> problems with different versions of pythons I have installed and need to 
> specify the path every time. Nonetheless, it works.

You mean python installed by macports or manually by you?

> This one guy came up with a script [0] to wrap macports executables with the 
> appropriate environment before using them. I think this is what you might be 
> looking for.

I saw that workaround too, but it seems much of a hassle.

I read that the defaults should work, with the caveat of tools picking wrong 
versions from /usr/local/ at build time when using macports, which eventually 
could be circumvented in trace mode.

I was thinking of adding a different path for homebrew to link its binaries 
from, but I haven't checked the docs if it's possible.

running macports along with homebrew

[db]

I searched the docs, the list's archive and stackexchange amongst other sources 
for sort of a best practice for running macports along with homebrew, to no 
avail.

From those I gathered that the only problem one could run into, it seems, would 
be at build time — hence some advise on changing the PATH possibly with a 
script while building or upgrading.

Besides missing ports and updated versions, what appeals to me from homebrew is 
cask (I have to read its documentation though), which could even install 
macports. What it doesn't: ruby, learning the peculiarities of another package 
manager and the whole Schraderbräu lingo.

Is anyone actually using both package managers that could advise on a best way 
to run them together?

Re: Anyone successfully install "meld"? Failed on gstreamer1-gst-plugins-bad

[db]

On 16 Aug 2017, at 14:12, James Kulp  wrote:
> Thanks all for the help.  After a selfupdate, gstreamer1-gst-plugins-bad 
> installed ok, and the rest of the dependencies from "meld" also were fine, 
> and "meld" is good.

Can anyone take a look at #51512 (3.16.0)? Alternatively, this version is also 
available at https://github.com/yousseb/meld/releases.

Re: macports' hardlinks and time machine backups

[db]

On 14 Aug 2017, at 14:16, Rainer Müller  wrote:
> Finder on macOS uses base 10

Thanks. Somehow I thought it had been reverted without ever verifying. Oh well…

Re: macports' hardlinks and time machine backups

[db]

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?

macports' hardlinks and time machine backups

[db]

I perchance stumbled upon this post [1] and couldn't find what's the actual 
state.

In my system du reports ~8.8G for my prefix while Finder ~9.4.

What's changed from then?

[1] https://lists.macports.org/pipermail/macports-dev/2010-May/011938.html

Re: Anyone successfully install "meld"? Failed on gstreamer1-gst-plugins-bad

[db]

It's good to know that meld is on macports. In trac, there's a patch at 
https://trac.macports.org/ticket/51512 for 3.16.0, which you might want to give 
a try.

Re: python36 uninstall problem

[db]

On 18 Jul 2017, at 16:16, Ray Zimmerman  wrote:
> However, I notice there is still a 105 MB directory at …
> /opt/local/Library/Frameworks/Python.framework/Versions/3.6

What's the output for this command?

port provides /opt/local/Library/Frameworks/Python.framework/Versions/3.6/Python

Re: nmap doesn't like libc++ ?

[db]

On 12 Jul 2017, at 22:42, Ryan Schmidt  wrote:
> On Jul 12, 2017, at 14:27, Ken Cunningham wrote:
> You could do this in the portfile:
>> configure.cxxflags-append -stdlib=libc++
>> configure.ldflags-append -stdlib=libc++
>> and your build should proceed through. Should. Usually works.
> As I mentioned, some of the Makefile lines in question only use CFLAGS, not 
> CXXFLAGS or LDFLAGS, and another uses none of them. The correct fix seems 
> like it would be to edit the Makefile to use CXXFLAGS every time a C++ file 
> is compiled.

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

Re: get portfiles from all sources

[db]

On 3 Jul 2017, at 18:02, Rainer Müller  wrote:
> I would consider this a bug in 'port search', as libsdl2 as a port argument 
> will always refer to the first one, so it does not make sense to print 
> additional results.

Couldn't the pseudo-portname `all` do what the documentation says and port keep 
the first tree in sources.conf shadowing subsequent entries? Or must it be 
mutually exclusive?

Re: get portfiles from all sources

[db]

On 3 Jul 2017, at 13:45, Rainer Müller  wrote:
> You can only use the Portfile from the first ports tree providing a port with 
> that name.

I though that `all` should get it from all trees, according to port's man page

The pseudo-portnames are:

   o   all: all the ports in each ports tree listed in sources.conf

get portfiles from all sources

[db]

I don't seem to find a way to get all portfiles from sources listed in 
sources.conf. In my case:

file:///opt/local/myports
file:///opt/local/var/macports/sources/github.com/macports/macports-ports/ 
[default]
#rsync://rsync.macports.org/release/tarballs/ports.tar [default]

I thought this should have worked, but it doesn't.

port file all | grep port_name

Re: logging all port command activity

[db]

On 29 Jun 2017, at 02:47, Ryan Schmidt  wrote:
> There's no such capability built in. 

Would implementing such a feature be feasible (and worth filing a ticket)?

Re: replace existing attachment of the same name in trac

[db]

On 26 Jun 2017, at 21:06, Ryan Schmidt  wrote:
> I hadn't noticed. If it does that, it would probably be a Trac bug.

If anyone confirms it, I leave it to him to file.

Re: Mac port error

[db]

> I would like to ask also if the mac port platform could be used as a virtual 
> computer with the Lnux shell on it.

If I guess what you mean — use xhyve (http://www.pagetable.com/?p=831) or qemu.

Re: Missing /opt/local/share/man/whatis DB

[db]

On 22 Jun 2017, at 05:09, Richard L. Hamilton  wrote:
> And ideally, anything that installs (or removes) man pages from a man page 
> directory should, after installing (or removing) the pages, run makewhatis, 
> e.g.
> 
> /usr/libexec/makewhatis /opt/local/'share/man

If you have man 1.6g via macports you might want to use `sudo makewhatis -w`, 
but it doesn't seem to work.

-w Use manpath obtained from `man --path`

$ sudo makewhatis -w
tr: Illegal byte sequence

On the other hand

$ sudo /usr/libexec/makewhatis -v `man --path | tr : ' '`

works but duplicates some entries, as expected I suppose.