Re: [macports-ports] branch master updated: py-*: add missing subports for python 3.5 and 3.6

[Mojca Miklavec]

On 12 April 2018 at 04:23, Ryan Schmidt wrote:
> On Apr 11, 2018, at 21:22, Joshua Root wrote:
>> On 2018-4-12 11:49 , Ryan Schmidt wrote:
>>>
>>> These performance problems predate the existence of our 
>>> getNextBuildOnPortBuilder function.
>>>
>>> It smells to me like a missing database index problem. I don't know how to 
>>> determine that though.
>>
>> I'm guessing we probably run into trouble when the number of pending
>> builds exceeds our cachedbuildrequests number. Is that at the default
>> 1000 as set in master.cfg?
>
> Aha! Sure, I don't know why its value would be anything other than what we've 
> told it to be in master.cfg. So we should increase that to a much higher 
> number.

Joshua, thank you very much for figuring out what the problem was and
saving our buildbot.

> Along with maybe some of the other values.

You might want to increase the number of builds retained in history. I
suspect that currently the builds get deleted after roughly 10.000 new
builds come in.


I owe a deep apology. I did commit perl updates (with more than 1k
ports) a couple of times without ever experience a problem as big as
this one. This list seemed super short in comparison, but I didn't
anticipate that so many perl subports would be broken and that the
list would end up containing more than 1k ports per builder.

The queue for 10.13 has finally been digested, so I'll go over the
list of failed ports and probably open a ticket to track progress on
fixing the issues.

Mojca

Re: port version reports 2.4.2 when built from tag v2.4.3

[Enrico Maria Crisostomo]

> On 12 Apr 2018, at 02:30, Ryan Schmidt  wrote:
> 
> 
> On Apr 11, 2018, at 08:48, Enrico Maria Crisostomo wrote:
> 
>> Well, I replicated it:
>> 
>> * Clean the repo (e.g.: git clean -xfd)
>> * git checkout v2.4.2
>> * build and install 2.4.2:
>> 
>> $ export PATH=/bin:/sbin:/usr/bin:/usr/sbin
>> $ MP_PREFIX=/opt/macports-2.4.2
>> $ ./configure --prefix=$MP_PREFIX 
>> --with-applications-dir=$MP_PREFIX/Applications
>> $ make
>> $ sudo make install
>> 
>> * open new terminal
>> * git checkout v2.4.3
>> * configure 2.4.3:
>> 
>> $ export PATH=/bin:/sbin:/usr/bin:/usr/sbin
>> $ MP_PREFIX=/opt/macports-2.4.3
>> $ ./configure --prefix=$MP_PREFIX 
>> --with-applications-dir=$MP_PREFIX/Applications
>> 
>> * At this point src/macports1.0/macports_autoconf.tcl correctly contains 
>> `variable macports_version "2.4.3"`
>> * build and install 2.4.3:
>> 
>> $ make
>> $ sudo make install
>> 
>> * At this point 
>> /opt/macports-2.4.3/libexec/macports/lib/macports1.0/macports_autoconf.tcl 
>> correctly contains `variable macports_version "2.4.3"`.
>> * But port reports 2.4.2:
>> 
>> % echo path
>> 
>> /opt/macports-2.4.3/bin:/opt/macports-2.4.3/sbin:/bin:/usr/bin:/usr/ucb:/usr/local/bin
>> % type port
>> port is /opt/macports-2.4.3/bin/port
>> % port version
>> Version: 2.4.2
> 
> Just to be absolutely certain which `port' binary you're running:
> 
> What happens if you run:
> 
> /opt/macports-2.4.3/bin/port version

Hi Ryan,

This happens:

% /opt/macports-2.4.3-clean/bin/port version
Version: 2.4.3

Support for python 2.6, 3.3 and 3.4

[Mojca Miklavec]

Hi,

There are still some python modules that provide support for python
2.6 and 3.3. Is it ok to put all of them to py-graveyard?

There are a number of broken py34-* ports due to missing dependencies
(notably py34-matplotlib).

Do we want to:
(a) Temporarily add those missing dependencies until the rest of
3.5/3.6 ports are tested & working?
(b) Try to remove support for 3.4 ASAP.

Thank you,
Mojca

Re: How to submit changes with a GitHub Pull Request (was Re: CI system for PR builds)

[db]

On 11 Apr 2018, at 19:24, Perry E. Metzger  wrote:
> The main steps are:
> […]
> [By the way, if someone wants to turn this email into a document, I
> was pretty careful writing what's above so that would be easy.]

Thanks for the write-up. Although I probably rather prefer the PR way, it's 
getting around git+GitHub vs. attaching a portfile in Trac. Would you mind 
adding it to the guide's section 'Using Git and GitHub' you recently created?

Re: CI system for PR builds

[db]

On 8 Apr 2018, at 02:04, Rainer Müller  wrote:
> So here is the full plan in detail:

Side note: Wouldn't it be feasible to adjust portfiles based on CI's feedback? 
Let's say, you have something build on 10.6-10.13, but for whatever reason it 
fails on 10.9, so that could be reflected in the portfile in order to avoid 
having users build from source in vain, when the result is already known. Then, 
when there's a fix for 10.9, that change is reverted.

Re: How to submit changes with a GitHub Pull Request (was Re: CI system for PR builds)

[Mojca Miklavec]

On 12 April 2018 at 13:59, db wrote:
> On 11 Apr 2018, at 19:24, Perry E. Metzger wrote:
>> The main steps are:
>> […]
>> [By the way, if someone wants to turn this email into a document, I
>> was pretty careful writing what's above so that would be easy.]
>
> Thanks for the write-up. Although I probably rather prefer the PR way, it's 
> getting around git+GitHub vs. attaching a portfile in Trac.

What nobody mentioned so far is that one can also simply click "Edit"
on the existing Portfile on GitHub interface and that will also open a
pull request. That basically requires zero skill in git.
(In case that we would need to fix commit message or squash commits,
this requires "manual fixes" though.)

Mojca

Re: CI system for PR builds

[Mojca Miklavec]

On 12 April 2018 at 13:59, db wrote:
>
> Side note: Wouldn't it be feasible to adjust portfiles based on CI's 
> feedback? Let's say, you have something build on 10.6-10.13, but for whatever 
> reason it fails on 10.9, so that could be reflected in the portfile in order 
> to avoid having users build from source in vain, when the result is already 
> known. Then, when there's a fix for 10.9, that change is reverted.

Yes. That's https://trac.macports.org/ticket/15712

Mojca

Re: New guide section on Git and GitHub

[Perry E. Metzger]

On Wed, 11 Apr 2018 19:30:56 -0400 Andrew Moore 
wrote:
> As someone who only reads the manual as last resort, I think
> Section 7 of the MacPorts Guide could be retitled from “MacPorts
> Project” to “Contributing to MacPorts”.  And then steps for
> creating pull requests via GitHub spelled out tutorial-wise.
> Perhaps steal an existing tutorial
> .

Pull requests to make these changes would be quite welcome!

> While I appreciate the intent, I think “easing into” GitHub is more
> obfuscating, and actually adds an extra hurdle for contributors.
> For instance the section immediately following “Using Git and
> GitHub” is titled “New Ports” and proceeds with steps for
> contributing a Trac ticket.

Only after saying please use GitHub preferentially in boldface and
first saying "use github! but if you're using trac, do this!"

Perry
-- 
Perry E. Metzgerpmetz...@macports.org

Re: Support for python 2.6, 3.3 and 3.4

[Perry E. Metzger]

On Thu, 12 Apr 2018 11:59:17 +0200 Mojca Miklavec
 wrote:
> Hi,
> 
> There are still some python modules that provide support for python
> 2.6 and 3.3. Is it ok to put all of them to py-graveyard?

As a data point, Python 2.6 and Python 3.3 are both past End of
Life and are no longer supported by the Python folks.

> There are a number of broken py34-* ports due to missing
> dependencies (notably py34-matplotlib).
> 
> Do we want to:
> (a) Temporarily add those missing dependencies until the rest of
> 3.5/3.6 ports are tested & working?
> (b) Try to remove support for 3.4 ASAP.

Not sure here, but generally, I think it's better to try to move
forward.

Perry
-- 
Perry E. Metzgerpe...@piermont.com

Re: port version reports 2.4.2 when built from tag v2.4.3

[Ryan Schmidt]

On Apr 12, 2018, at 03:39, Enrico Maria Crisostomo wrote:

> On 12 Apr 2018, at 02:30, Ryan Schmidt wrote:
> 
>> On Apr 11, 2018, at 08:48, Enrico Maria Crisostomo wrote:
>> 
>>> Well, I replicated it:
>>> 
>>> * Clean the repo (e.g.: git clean -xfd)
>>> * git checkout v2.4.2
>>> * build and install 2.4.2:
>>> 
>>>$ export PATH=/bin:/sbin:/usr/bin:/usr/sbin
>>>$ MP_PREFIX=/opt/macports-2.4.2
>>>$ ./configure --prefix=$MP_PREFIX 
>>> --with-applications-dir=$MP_PREFIX/Applications
>>>$ make
>>>$ sudo make install
>>> 
>>> * open new terminal
>>> * git checkout v2.4.3
>>> * configure 2.4.3:
>>> 
>>>$ export PATH=/bin:/sbin:/usr/bin:/usr/sbin
>>>$ MP_PREFIX=/opt/macports-2.4.3
>>>$ ./configure --prefix=$MP_PREFIX 
>>> --with-applications-dir=$MP_PREFIX/Applications
>>> 
>>> * At this point src/macports1.0/macports_autoconf.tcl correctly contains 
>>> `variable macports_version "2.4.3"`
>>> * build and install 2.4.3:
>>> 
>>>$ make
>>>$ sudo make install
>>> 
>>> * At this point 
>>> /opt/macports-2.4.3/libexec/macports/lib/macports1.0/macports_autoconf.tcl 
>>> correctly contains `variable macports_version "2.4.3"`.
>>> * But port reports 2.4.2:
>>> 
>>>% echo path
>>>
>>> /opt/macports-2.4.3/bin:/opt/macports-2.4.3/sbin:/bin:/usr/bin:/usr/ucb:/usr/local/bin
>>>% type port
>>>port is /opt/macports-2.4.3/bin/port
>>>% port version
>>>Version: 2.4.2
>> 
>> Just to be absolutely certain which `port' binary you're running:
>> 
>> What happens if you run:
>> 
>> /opt/macports-2.4.3/bin/port version
> 
> Hi Ryan,
> 
> This happens:
> 
>% /opt/macports-2.4.3-clean/bin/port version
>Version: 2.4.3

Then I would say that MacPorts is working correctly. I would guess that the 
problem occurred because of your shell's cached lookup of the port command in 
the previous /opt/macports-2.4.2 location.

Re: CI system for PR builds

[Ryan Schmidt]

On Apr 12, 2018, at 06:59, db wrote:

> On 8 Apr 2018, at 02:04, Rainer Müller wrote:
>> So here is the full plan in detail:
> 
> Side note: Wouldn't it be feasible to adjust portfiles based on CI's 
> feedback? Let's say, you have something build on 10.6-10.13, but for whatever 
> reason it fails on 10.9, so that could be reflected in the portfile in order 
> to avoid having users build from source in vain, when the result is already 
> known. Then, when there's a fix for 10.9, that change is reverted.

1. MacPorts does not have a method of declaring that a port does not build on a 
version of macOS. Such a feature is being discussed:

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

In the absence of this feature, we write pre-fetch blocks that manually check 
the OS version and print an error.

2. A portfile author is welcome (and encouraged) to add such blocks to their 
portfile to provide a friendlier error message to the user, if we already know 
in advance that it will not build on their system.

3. There is no plan to have any automated process add such blocks.

Re: How to submit changes with a GitHub Pull Request (was Re: CI system for PR builds)

[db]

On 12 Apr 2018, at 14:27, Mojca Miklavec  wrote:
> What nobody mentioned so far is that one can also simply click "Edit" on the 
> existing Portfile on GitHub interface and that will also open a pull request.

Interesting. It seems that 'Create new file' would have a similar effect. 
'Upload files' is disabled though.

"You’re creating a file in a project you don’t have write access to. Submitting 
a change will create the file in a new branch in your fork USER/macports-ports, 
so you can send a pull request."

Re: How to submit changes with a GitHub Pull Request (was Re: CI system for PR builds)

[Craig Treleaven]

> On Apr 12, 2018, at 1:35 PM, db  wrote:
> 
> On 12 Apr 2018, at 14:27, Mojca Miklavec  wrote:
>> What nobody mentioned so far is that one can also simply click "Edit" on the 
>> existing Portfile on GitHub interface and that will also open a pull request.
> 
> Interesting. It seems that 'Create new file' would have a similar effect. 
> 'Upload files' is disabled though.
> 
> "You’re creating a file in a project you don’t have write access to. 
> Submitting a change will create the file in a new branch in your fork 
> USER/macports-ports, so you can send a pull request."

Is there a playground somewhere to try out such features?  For those of us that 
are somewhat git- and github-challenged.

Craig

Re: CI system for PR builds

[db]

On 12 Apr 2018, at 18:52, Ryan Schmidt  wrote:
> 1. MacPorts does not have a method of declaring that a port does not build on 
> a version of macOS. Such a feature is being discussed:
> https://trac.macports.org/ticket/15712
> In the absence of this feature, we write pre-fetch blocks that manually check 
> the OS version and print an error.

Opened 10 years ago. Fat chance, I guess.

> 3. There is no plan to have any automated process add such blocks.

Precisely that I wanted to know. I'd like the powers that be to consider this — 
delivering portfiles that won't build (in certain platforms) doesn't make much 
sense.

Re: CI system for PR builds

[Ryan Schmidt]

On Apr 12, 2018, at 13:14, db wrote:

> On 12 Apr 2018, at 18:52, Ryan Schmidt wrote:
>> 1. MacPorts does not have a method of declaring that a port does not build 
>> on a version of macOS. Such a feature is being discussed:
>> https://trac.macports.org/ticket/15712
>> In the absence of this feature, we write pre-fetch blocks that manually 
>> check the OS version and print an error.
> 
> Opened 10 years ago. Fat chance, I guess.

You may have noticed that discussion about the issue resumed 4 weeks ago, and a 
milestone was assigned.
 

>> 3. There is no plan to have any automated process add such blocks.
> 
> Precisely that I wanted to know. I'd like the powers that be to consider this 
> — delivering portfiles that won't build (in certain platforms) doesn't make 
> much sense.

The method by which we want to accomplish that is the above-referenced ticket.

Re: [macports-ports] branch master updated: py-*: add missing subports for python 3.5 and 3.6

[Ryan Schmidt]

On Apr 12, 2018, at 02:53, Mojca Miklavec wrote:

> On 12 April 2018 at 04:23, Ryan Schmidt wrote:
>> On Apr 11, 2018, at 21:22, Joshua Root wrote:
>>> On 2018-4-12 11:49 , Ryan Schmidt wrote:
 
 These performance problems predate the existence of our 
 getNextBuildOnPortBuilder function.
 
 It smells to me like a missing database index problem. I don't know how to 
 determine that though.
>>> 
>>> I'm guessing we probably run into trouble when the number of pending
>>> builds exceeds our cachedbuildrequests number. Is that at the default
>>> 1000 as set in master.cfg?
>> 
>> Aha! Sure, I don't know why its value would be anything other than what 
>> we've told it to be in master.cfg. So we should increase that to a much 
>> higher number.
> 
> Joshua, thank you very much for figuring out what the problem was and
> saving our buildbot.
> 
>> Along with maybe some of the other values.
> 
> You might want to increase the number of builds retained in history. I
> suspect that currently the builds get deleted after roughly 10.000 new
> builds come in.

Yes, we do only keep the 10,000 most recent builds per builder. Do you really 
think we need to keep more than that?


> I owe a deep apology. I did commit perl updates (with more than 1k
> ports) a couple of times without ever experience a problem as big as
> this one. This list seemed super short in comparison, but I didn't
> anticipate that so many perl subports would be broken and that the
> list would end up containing more than 1k ports per builder.

No worries. I appreciate the work you're doing, and we need to fix 
infrastructure such as buildbot to be compatible with how we work, so I'm glad 
we figured out how to let the buildbot deal with a larger number of pending 
builds.

I'm not sure why the mass perl changes before worked better...


> The queue for 10.13 has finally been digested, so I'll go over the
> list of failed ports and probably open a ticket to track progress on
> fixing the issues.

Dave has been adding some missing select files and missing setuptools 
dependencies.

Re: How to submit changes with a GitHub Pull Request (was Re: CI system for PR builds)

[db]

On 12 Apr 2018, at 19:52, Craig Treleaven  wrote:
> Is there a playground somewhere to try out such features?  For those of us 
> that are somewhat git- and github-challenged.

Not that I'm aware of. Just fork some repo or create a new one and make it your 
playground.

Re: CI system for PR builds

[db]

On 12 Apr 2018, at 20:16, Ryan Schmidt  wrote:
> You may have noticed that discussion about the issue resumed 4 weeks ago, and 
> a milestone was assigned.

I didn't notice the milestone. Is 2.6 next year's?

Re: CI system for PR builds

[Ryan Schmidt]

On Apr 12, 2018, at 13:38, db wrote:

> On 12 Apr 2018, at 20:16, Ryan Schmidt wrote:
>> You may have noticed that discussion about the issue resumed 4 weeks ago, 
>> and a milestone was assigned.
> 
> I didn't notice the milestone. Is 2.6 next year's?

Milestones don't have specific dates. We want to implement this feature, but no 
work has been done yet, so it's unrealistic to expect it to be in 2.5, which 
already has a lot of work done for it and which want to release soon. Therefore 
it's targeted for 2.6.

Re: [macports-ports] branch master updated: abgx360: Add modeline, update master_sites

[Ryan Schmidt]

On Apr 12, 2018, at 13:35, Jackson Isaac wrote:

> Jackson Isaac (JacksonIsaac) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/5ed97fc2b4fe6ecb8953371fdeefa3bc8da73ea9
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 5ed97fc  abgx360: Add modeline, update master_sites
> 
> 5ed97fc is described below
> 
> 
> commit 5ed97fc2b4fe6ecb8953371fdeefa3bc8da73ea9
> 
> Author: ijackson
> AuthorDate: Fri Apr 13 00:05:51 2018 +0530
> 
> 
> abgx360: Add modeline, update master_sites
> 
> ---
>  games/abgx360/Portfile | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)


> @@ -20,11 +22,9 @@ long_description \
>  maintainers nomaintainer
>  homepagehttp://abgx360.xecuter.com/
>  
> -master_siteshttp://abgx360.xecuter.com/dl
> +master_siteshttp://abgx360.xecuter.com/download.php

Please revert:


$ sudo port fetch --no-mirrors abgx360
--->  Fetching distfiles for abgx360
--->  Attempting to fetch abgx360-1.0.6.tar.gz from 
http://abgx360.xecuter.com/download.php
$ sudo port checksum abgx360
--->  Verifying checksums for abgx360
Error: Checksum (rmd160) mismatch for abgx360-1.0.6.tar.gz
Error: Checksum (sha256) mismatch for abgx360-1.0.6.tar.gz
***
The non-matching file appears to be HTML. See this page for possible reasons
for the checksum mismatch:

***
The file has been moved to: 
/Users/rschmidt/macports/distfiles/abgx360/abgx360-1.0.6.tar.gz.html
Error: Failed to checksum abgx360: Unable to verify file checksums
Error: See 
/opt/local/var/macports/logs/_Users_rschmidt_macports_macports-ports-svn-trunk_games_abgx360/abgx360/main.log
 for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port abgx360 failed

Re: CI system for PR builds

[Rainer Müller]

On 2018-04-12 20:14, db wrote:
> On 12 Apr 2018, at 18:52, Ryan Schmidt  wrote:
>> 1. MacPorts does not have a method of declaring that a port does not build 
>> on a version of macOS. Such a feature is being discussed:
>> https://trac.macports.org/ticket/15712
>> In the absence of this feature, we write pre-fetch blocks that manually 
>> check the OS version and print an error.
> 
> Opened 10 years ago. Fat chance, I guess.

Do I have to explain again that we run on volunteers only?
Apparently, nobody volunteered to implement this.

Priority and focus shifts with what people are willing to work on.
This was not that important before. It is now becoming important as we
want to have it on the buildbot.

>> 3. There is no plan to have any automated process add such blocks.
> 
> Precisely that I wanted to know. I'd like the powers that be to consider this 
> — delivering portfiles that won't build (in certain platforms) doesn't make 
> much sense.

Please think about the implications first. When a build fails on all
versions, do you automatically want to list them all as unsupported?

It is up to the maintainer (or any contributor) to add the appropriate
list of supported platforms after determining the cause of build
failures, so we will not run the check again next time.

Rainer

Re: [MacPorts] #15712: Add versions to platforms

[Craig Treleaven]

> On Apr 12, 2018, at 5:09 PM, MacPorts  wrote:
> 
> #15712: Add versions to platforms
> --+
>  Reporter:  raimue   |  Owner:  larryv
>  Type:  enhancement  | Status:  assigned
>  Priority:  Normal   |  Milestone:  MacPorts 2.6.0
> Component:  base |Version:
> Resolution:   |   Keywords:
>  Port:   |
> --+
> 
> Comment (by raimue):
> 
> …

> Overall, we mostly care whether the current platform is supported or not.
> There is no need for complicated blacklists or whitelists. There is
> usually only a need to express a maximum or minimum version requirement
> for each platform.
> 
> …

> I do not understand why you also bring dependencies into this... They can
> declare whatever they want and yes, it might stop us from installing
> dependents. But this has no influence on the way we specify `platforms` in
> this port. We will check whether the current platform is supported each
> time we want to install ports, so we automatically do it for the
> dependency. If it does not support it, we stop at this point and all the
> dependents cannot be installed. To give an appropriate error message we
> have to evaluate this for each port separately anway, so I do not see when
> we would have to merge anything.

Are we intending to extend the port info command to report if a port is 
supported on the current platform or not?  Or at least report if the port is 
known to be NOT supported?  A given port is not supported if any of its 
dependencies are not supported.

For example, AFAICT, MythTV’s code has always been compatible with bascially 
any version of OS X.  However, it relies extensively on Qt and that generally 
defines the minimum platform that the system will run on.  

I don’t know how we handle this efficiently, though.  There are 200+ recursive 
deps for Myth!

Craig

Re: port version reports 2.4.2 when built from tag v2.4.3

[Jack Howarth]

This issue might also be impacting the High Sierra macports 2.4.3 installer
image as well. After installing it on a machine with no /opt/local, I get
the following from 'sudo port self update'...

--->  Updating MacPorts base sources using rsync

MacPorts base version 2.4.3 installed,

MacPorts base version 2.4.2 downloaded.

--->  Updating the ports tree

--->  MacPorts base is probably trunk or a release candidate


The ports tree has been updated. To upgrade your installed ports, you
should run

  port upgrade outdated

When I execute 'sudo port upgrade outdated', I get...

Nothing to upgrade.


On Thu, Apr 12, 2018 at 12:44 PM, Ryan Schmidt 
wrote:

>
> On Apr 12, 2018, at 03:39, Enrico Maria Crisostomo wrote:
>
> > On 12 Apr 2018, at 02:30, Ryan Schmidt wrote:
> >
> >> On Apr 11, 2018, at 08:48, Enrico Maria Crisostomo wrote:
> >>
> >>> Well, I replicated it:
> >>>
> >>> * Clean the repo (e.g.: git clean -xfd)
> >>> * git checkout v2.4.2
> >>> * build and install 2.4.2:
> >>>
> >>>$ export PATH=/bin:/sbin:/usr/bin:/usr/sbin
> >>>$ MP_PREFIX=/opt/macports-2.4.2
> >>>$ ./configure --prefix=$MP_PREFIX --with-applications-dir=$MP_
> PREFIX/Applications
> >>>$ make
> >>>$ sudo make install
> >>>
> >>> * open new terminal
> >>> * git checkout v2.4.3
> >>> * configure 2.4.3:
> >>>
> >>>$ export PATH=/bin:/sbin:/usr/bin:/usr/sbin
> >>>$ MP_PREFIX=/opt/macports-2.4.3
> >>>$ ./configure --prefix=$MP_PREFIX --with-applications-dir=$MP_
> PREFIX/Applications
> >>>
> >>> * At this point src/macports1.0/macports_autoconf.tcl correctly
> contains `variable macports_version "2.4.3"`
> >>> * build and install 2.4.3:
> >>>
> >>>$ make
> >>>$ sudo make install
> >>>
> >>> * At this point 
> >>> /opt/macports-2.4.3/libexec/macports/lib/macports1.0/macports_autoconf.tcl
> correctly contains `variable macports_version "2.4.3"`.
> >>> * But port reports 2.4.2:
> >>>
> >>>% echo path
> >>>/opt/macports-2.4.3/bin:/opt/macports-2.4.3/sbin:/bin:/usr/
> bin:/usr/ucb:/usr/local/bin
> >>>% type port
> >>>port is /opt/macports-2.4.3/bin/port
> >>>% port version
> >>>Version: 2.4.2
> >>
> >> Just to be absolutely certain which `port' binary you're running:
> >>
> >> What happens if you run:
> >>
> >> /opt/macports-2.4.3/bin/port version
> >
> > Hi Ryan,
> >
> > This happens:
> >
> >% /opt/macports-2.4.3-clean/bin/port version
> >Version: 2.4.3
>
> Then I would say that MacPorts is working correctly. I would guess that
> the problem occurred because of your shell's cached lookup of the port
> command in the previous /opt/macports-2.4.2 location.
>
>
>

Re: port version reports 2.4.2 when built from tag v2.4.3

[Ryan Schmidt]

On Apr 12, 2018, at 17:42, Jack Howarth wrote:

> This issue

"This issue" isn't an issue, it's just a misunderstanding of how the shell 
caches information.

> might also be impacting the High Sierra macports 2.4.3 installer image as 
> well. After installing it on a machine with no /opt/local, I get the 
> following from 'sudo port self update'...
> 
> --->  Updating MacPorts base sources using rsync
> MacPorts base version 2.4.3 installed,
> MacPorts base version 2.4.2 downloaded.
> --->  Updating the ports tree
> --->  MacPorts base is probably trunk or a release candidate
> 
> The ports tree has been updated. To upgrade your installed ports, you should 
> run
>   port upgrade outdated
> 
> When I execute 'sudo port upgrade outdated', I get...
> 
> Nothing to upgrade.

That's a server problem that should be resolved within the hour.

Re: port version reports 2.4.2 when built from tag v2.4.3

[Rainer Müller]

On 2018-04-13 00:42, Jack Howarth wrote:
> This issue might also be impacting the High Sierra macports 2.4.3
> installer image as well. After installing it on a machine with no
> /opt/local, I get the following from 'sudo port self update'...
> 
> --->  Updating MacPorts base sources using rsync
> 
> MacPorts base version 2.4.3 installed,
> 
> MacPorts base version 2.4.2 downloaded.

It is actually an unrelated problem. The new version is not yet
available over selfupdate. The script that is supposed to update the
rsync server is failing.

Check this and following messages in the thread on macports-users:
https://lists.macports.org/pipermail/macports-users/2018-April/044969.html

Rainer

Re: port version reports 2.4.2 when built from tag v2.4.3

[Jack Howarth]

On Thu, Apr 12, 2018 at 6:47 PM, Rainer Müller  wrote:

> On 2018-04-13 00:42, Jack Howarth wrote:
> > This issue might also be impacting the High Sierra macports 2.4.3
> > installer image as well. After installing it on a machine with no
> > /opt/local, I get the following from 'sudo port self update'...
> >
> > --->  Updating MacPorts base sources using rsync
> >
> > MacPorts base version 2.4.3 installed,
> >
> > MacPorts base version 2.4.2 downloaded.
>
> It is actually an unrelated problem. The new version is not yet
> available over selfupdate. The script that is supposed to update the
> rsync server is failing.
>
> Check this and following messages in the thread on macports-users:
> https://lists.macports.org/pipermail/macports-users/2018-April/044969.html
>
> Rainer
>

So I assume there is no simple way to just reconfigure the installed 2.4.3
macports to use a 2.4.3 branch git repo?

Re: port version reports 2.4.2 when built from tag v2.4.3

[Ryan Schmidt]

On Apr 12, 2018, at 17:54, Jack Howarth wrote:

> On Thu, Apr 12, 2018 at 6:47 PM, Rainer Müller wrote:
>> It is actually an unrelated problem. The new version is not yet
>> available over selfupdate. The script that is supposed to update the
>> rsync server is failing.
>> 
>> Check this and following messages in the thread on macports-users:
>> https://lists.macports.org/pipermail/macports-users/2018-April/044969.html
> 
> So I assume there is no simple way to just reconfigure the installed 2.4.3 
> macports to use a 2.4.3 branch git repo? 

What do you mean?

You already have MacPorts 2.4.3 installed. There is nothing left to do but to 
go forth and use it.

Re: py36 sub-ports fail to build

[Bjarne D Mathiesen]

Joshua Root wrote:
> On 2018-4-6 06:15 , Bjarne D Mathiesen wrote:
>> 2) filing a bug
> 
> Yes. Against py-nuitka in our trac, and probably against setuptools
> upstream.

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

-- 
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
--
denne besked er skrevet i et totalt M$-frit miljø
macOS 10.13.4 High Sierra (17E199)
2 x 3,46 GHz 6-Core Intel Xeon ; 48 GB 1333 MHz DDR3 ECC
ATI Radeon HD 5770 1024 MB

Any testers for proposed opportunistic filesystem compression?

[Eric A. Borisch]

https://github.com/macports/macports-base/pull/76

During the extract-from-package step, if bsdtar exists **and** supports
--hfsCompression, use the flag during the extraction.

To test:
 * make sure libarchive is installed
 * check disk usage
 * deactivate & re-activate a large port (llvm / gcc / clang)
 * check disk usage again. If everything is working, you should have more
space available.

I've been using it for months and have been very happy with the space
savings (especially on packages with lots of text files. *cough* compilers
*cough*.)

It is slower to extract, but I don't notice any slowdown after the that
point. Most Apple-installed tools are compressed, from the spot-checking
I’ve done.

Downsides:
 * Doesn't detect if the compression will be lost (and therefore pointless
work/time) when moving for activation. This is the case if different
mountpoints are involved for the extraction directory and the final
activation locations. Scrapped detection of this as corner case with
significantly increased complexity. (And it’s not broken in the corner
case, just burns some extra cycles during extraction.)
 * Slower to extract than when not in use -- shouldn't be a surprise.

Thanks,
  - Eric

Re: port version reports 2.4.2 when built from tag v2.4.3

[Ryan Schmidt]

On Apr 12, 2018, at 18:02, Jack Howarth wrote:

> Okay. I was confused as to whether the installer contained the complete ports 
> repo or if it had to download that from the servers. I'm used to fink where 
> the installer only provides a core set of the base package files and the rest 
> have to be obtained from their servers. 

MacPorts is the same. The installer installs the base code, and then runs "sudo 
port selfupdate" which updates base to the latest version *and* downloads the 
collection of portfiles. The collection of portfiles is not tied to a specific 
version of MacPorts, but is meant to always be used with the latest (or nearly 
the latest) version of MacPorts.

polari broken?

[Jack Howarth]

Is anyone on 10.13 able to start polari such that a window appears? It
seems to cause the xors-server app to launch but only produces the
following output in the terminal without opening the Polari window...

$ polari


(.:18119): Gjs-*WARNING* **: 20:07:49.426: Some code accessed the property
'DropTargetIface' on the module 'pasteManager'. That property was defined
with 'let' or 'const' inside the module. This was previously supported, but
is not correct according to the ES6 standard. Any symbols to be exported
from a module must be defined with 'var'. The property access will work as
previously for the time being, but please fix your code anyway.


(.:18119): Gjs-*WARNING* **: 20:07:49.469: Some code accessed the property
'Application' on the module 'application'. That property was defined with
'let' or 'const' inside the module. This was previously supported, but is
not correct according to the ES6 standard. Any symbols to be exported from
a module must be defined with 'var'. The property access will work as
previously for the time being, but please fix your code anyway.

dbus[18119]: Dynamic session lookup supported but failed: launchd did not
provide a socket path, verify that org.freedesktop.dbus-session.plist is
loaded!


(org.gnome.Polari:18119): GLib-GIO-*CRITICAL* **: 20:07:49.548:
g_dbus_proxy_new_sync: assertion 'G_IS_DBUS_CONNECTION (connection)' failed

dbus[18119]: Dynamic session lookup supported but failed: launchd did not
provide a socket path, verify that org.freedesktop.dbus-session.plist is
loaded!


(org.gnome.Polari:18119): Gjs-*WARNING* **: 20:07:49.581: JS ERROR:
TypeError: this._accountManager is null

AccountsMonitor<._init
@resource:///org/gnome/Polari/js/accountsMonitor.js:28:13

wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22

_Base.prototype._construct@resource:///org/gnome/gjs/modules/_legacy.js:18:5

Class.prototype._construct/newClass
@resource:///org/gnome/gjs/modules/_legacy.js:114:32

getDefault@resource:///org/gnome/Polari/js/accountsMonitor.js:11:22

_RoomManager<._init@resource:///org/gnome/Polari/js/roomManager.js:25:33

wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22

_Base.prototype._construct@resource:///org/gnome/gjs/modules/_legacy.js:18:5

Class.prototype._construct/newClass
@resource:///org/gnome/gjs/modules/_legacy.js:114:32

getDefault@resource:///org/gnome/Polari/js/roomManager.js:14:22

Application<.vfunc_startup
@resource:///org/gnome/Polari/js/application.js:230:29

wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22

Application<._init/<@resource:///org/gnome/Polari/js/application.js:48:17

main@resource:///org/gnome/Polari/js/main.js:46:12

run@resource:///org/gnome/gjs/modules/package.js:221:12

start@resource:///org/gnome/gjs/modules/package.js:205:5

@:1:1


Gjs-*Message*: 20:07:49.582: JS WARNING:
[resource:///org/gnome/Polari/js/application.js 627]: reference to
undefined property "_accountsMonitor"


(org.gnome.Polari:18119): Gjs-*WARNING* **: 20:07:49.582: JS ERROR:
TypeError: this._accountsMonitor is undefined

Application<._onStartClient
@resource:///org/gnome/Polari/js/application.js:627:13

wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22

Application<.vfunc_activate
@resource:///org/gnome/Polari/js/application.js:264:9

wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22

main@resource:///org/gnome/Polari/js/main.js:46:12

run@resource:///org/gnome/gjs/modules/package.js:221:12

start@resource:///org/gnome/gjs/modules/package.js:205:5

@:1:1



(org.gnome.Polari:18119): Gjs-*WARNING* **: 20:07:49.582: Some code
accessed the property 'MainWindow' on the module 'mainWindow'. That
property was defined with 'let' or 'const' inside the module. This was
previously supported, but is not correct according to the ES6 standard. Any
symbols to be exported from a module must be defined with 'var'. The
property access will work as previously for the time being, but please fix
your code anyway.

dbus[18119]: Dynamic session lookup supported but failed: launchd did not
provide a socket path, verify that org.freedesktop.dbus-session.plist is
loaded!


(org.gnome.Polari:18119): GLib-GObject-*CRITICAL* **: 20:07:50.245: Custom
constructor for class Gjs_RoomList returned NULL (which is invalid). Please
use GInitable instead.


(org.gnome.Polari:18119): GLib-GObject-*CRITICAL* **: 20:07:50.245:
g_object_setv: assertion 'G_IS_OBJECT (object)' failed


(org.gnome.Polari:18119): GLib-GObject-*CRITICAL* **: 20:07:50.245:
g_object_setv: assertion 'G_IS_OBJECT (object)' failed


(org.gnome.Polari:18119): GLib-GObject-*CRITICAL* **: 20:07:50.245:
g_object_set_data_full: assertion 'G_IS_OBJECT (object)' failed


(org.gnome.Polari:18119): GLib-GObject-*CRITICAL* **: 20:07:50.245:
g_object_ref: assertion 'G_IS_OBJECT (object)' failed


(org.gnome.Polari:18119): GLib-GObject-*CRITICAL* **: 20:07:50.245:
g_object_unref: assertion 'G_IS_OBJECT (object)' failed

dbus[18119]: Dynamic session lookup supported but failed: launchd 

Re: Support for python 2.6, 3.3 and 3.4

[Ryan Schmidt]

On Apr 12, 2018, at 04:59, Mojca Miklavec wrote:

> There are still some python modules that provide support for python
> 2.6 and 3.3. Is it ok to put all of them to py-graveyard?
> 
> There are a number of broken py34-* ports due to missing dependencies
> (notably py34-matplotlib).
> 
> Do we want to:
> (a) Temporarily add those missing dependencies until the rest of
> 3.5/3.6 ports are tested & working?
> (b) Try to remove support for 3.4 ASAP.

If you want to graveyard python 3.x modules < 3.5, it'd be nice to first update 
the three remaining ports that depend on such old modules:


$ port echo depends:':py3[01234]-' and not name:'^py3[01234]-'
jrnl
livestreamer
lirc


And remove the old python variants from the several ports that still have them:


$ port echo variant:'(^|\s)python3[01234]($|\s)'
boost   
boost-numpy 
cmake   
cmake-devel 
coccinelle  
flann   
grc 
htcondor
liblinear   
libproxy
libpwquality
libsbml 
libsvm  
MacVim  
mycli   
nghttp2 
octave-symbolic 
ompl
opencv  
pgcli   
pybombs 
pybombs-devel   
pymol   
pypi2port   
qgis3   
quickfix
root5   
root6   
salt
spot
uhd 
uhd-devel   
vigra   
vim 
vips
volk
volk-devel  
weechat 
weechat-devel   
xonsh   
xonsh-devel 
xorg-libxcb 
xorg-xcb-proto  
xraylib 
youtube-dl  
znc 

Re: Support for python 2.6, 3.3 and 3.4

[Craig Treleaven]

> On Apr 12, 2018, at 8:42 PM, Ryan Schmidt  wrote:
> 
> 
> On Apr 12, 2018, at 04:59, Mojca Miklavec wrote:
> 
>> There are still some python modules that provide support for python
>> 2.6 and 3.3. Is it ok to put all of them to py-graveyard?
>> 
>> There are a number of broken py34-* ports due to missing dependencies
>> (notably py34-matplotlib).
>> 
>> Do we want to:
>> (a) Temporarily add those missing dependencies until the rest of
>> 3.5/3.6 ports are tested & working?
>> (b) Try to remove support for 3.4 ASAP.
> 
> If you want to graveyard python 3.x modules < 3.5, it'd be nice to first 
> update the three remaining ports that depend on such old modules:
> 
> 
> $ port echo depends:':py3[01234]-' and not name:'^py3[01234]-'
> jrnl
> livestreamer
> lirc
> 

lirc now updated to use python 3.6:

https://github.com/macports/macports-ports/commit/3fd165e46f62f25e2e703c2febf9536aa72d1407

Craig