review requests

[Ken Cunningham]

Hello, fellow MacPorts developers.

While I am waiting for my commit permissions to be considered, I would 
appreciate anyone with some spare time and enthusiasm to consider a few PRs for 
committal/commission:


Lout: a  port update requested by a devoted MacPorts user on Sierra that needed 
to be updated to work properly. Reviewed by Ryan some while ago. Looks good to 
go:





Mplayer: a trivial fix to include some OpenGL headers on Tiger that keeps 
coming up every time MPlayer is bumped. Bullet-proof, I think:





Chromaprint to PortGroup cxx11 1.1: a trivial update that fixes the build on 
older systems for this dependency for other ports.





And if you are in the mood for something more fancy, two really great fixes 
that I'm quite proud of for webkit2-gtk and webkit2-gtk-devel that fix the 
build on 10.6 and up for these important ports. These have to potential to keep 
a modern browser in the fold for these systems for some time to come, and as 
webkit-gtk is nearly dead, seem quite timely:



and 





All the best,

Ken

Re: [MacPorts] Migration modified

[Thomas R. Murphy]

Re-sending to have the message go to the list:

Hello all,

As a long-time user of MacPorts, I've migrated a few times a memory from
one of those times was how disastrously poorly the migration went. Be it
my fault in following the directions or a problem with my setup, I ended
up hard-uninstalling everything and reinstalling ports from memory/as I
re-discovered needing them. Since then, I have actively sought out this
set of instructions. My edits were to bring the instructions into a
proactive position, knowing that the installed ports need to be logged
and reinstalled, versus a reactive position, having MacPorts not work
and direct you to the wiki page.

Better documenting on the Migration wiki page to express the full
context of the instructions would be useful. It may also be valuable to
include at least a link to the Migration page as an "Uncommon Tasks"
relative to https://guide.macports.org/chunked/using.common-tasks.html .
This would give users more exposure to the process *before* they ever
needed to use it rather than discovering additional effort as (some?)
ports are broken and MacPorts requires a full reinstall to get a
functioning system back.

Of course, it would be best if MacPorts could handle the majority of the
OS-change work and the documentation was almost as short as "Upgrade OS,
run `sudo port `, and let everything reinstall."

Meanwhile, while writing this email, I found an additional deficiency in
the current process in which re-setting the requested status doesn't
work reliably. I look forward to continuing to improve the documentation
once the overall structure of this page is decided on.

Thomas R. Murphy (thomas.russell.mur...@case.edu, tr...@case.edu)
GPG Key ID: 959D48BF
On 2017-08-29 12:09:14, Umesh Singla wrote:
> Hi
>
> On Tue, Aug 29, 2017 at 8:30 PM, Rainer Müller  > wrote:
>
> On 2017-08-29 16:41, Arno Hautala wrote:
> > Just as a message is sent to the user list when a new MacPorts
> version
> > is posted, a message could be sent when a new OS is released that
> > reminds users that migration will be required.
>
> Such a message would probably only reach a small amount of users...
>
> Before we discuss more workarounds, I still see no reason why it would
> be required to run these steps before upgrading the OS. Otherwise I
> would prefer to go back to the old order of steps that always work and
> are less confusing.
>
>
> Following the use case which it serves currently, I agree that it is
> best to go with the original sequence of steps.
> Probably, thomasrussellmurphy reinstalled the complete OS and the
> guide didn't serve his purpose.
>
> - Umesh



signature.asc
Description: OpenPGP digital signature

Re: Why does macports require a migration across major version bumps?

[Joshua Root]

On 2017-8-30 11:01 , Eitan Adler wrote:

What is the underlying reason to require a reinstall across major
versions? I did something silly/stupid/smart  and removed the check
from libexec/macports/lib/macports1.0/macports.tcl and just did 'sudo
port upgrade outdated' to rebuild the world. It got about 90% of the
way through and only errored on a few expected
broken-for-other-reasons ports.

Obvious I'm down the deep hole of unsupported actions but I'm curious
about what gets missed when someone does this?


It's the same reason there are separate installers per OS version in the 
first place: Many features are detected at configure time. If the same 
features are not available at runtime, stuff breaks.


It's possible that nothing relevant changes between certain major OS 
versions. It definitely does between others.


If we were able to detect all features at runtime, we could have a 
single (base) build that would work on all supported OS versions. All 
the many ports that detect features at configure time would still need 
to be reinstalled of course.


- Josh

Re: Help updating advancemame

[Joshua Root]

On 2017-8-30 09:29 , Frank Schima wrote:

Hi Josh,


On Aug 29, 2017, at 4:38 PM, Joshua Root > wrote:


On 2017-8-30 08:32 , Frank Schima wrote:

Hello,
I am attempting to update the advancemame port to version 3.5. But I 
am running into a configuration error:
configure: error: cannot find install-sh, install.sh, or shtool in 
"." "./.." "./../..”

My attempt is documented on Trac ticket #54692:
https://trac.macports.org/ticket/54692
Can anyone help me?


This is normally provided by autotools. Might need an autoreconf -i. 
If install-sh is the only thing missing, you could copy it from 
automake or libtool.


I tried adding:
     autoreconf.args     -fvi

But that didn’t seem to help. However, copying install-sh, config.sub 
and config.guess from automake in a pre-configure block allowed the 
configure to succeed. But then later hit a build error with libpng:


:info:build srcmess/artwork.c:2307:61: error: incomplete definition of 
type 'struct png_info_def'
:info:build         if (png.height != original->height || png.width != 
original->width)
:info:build   
  ^
:info:build /opt/local/include/png.h:484:16: note: forward declaration 
of 'struct png_info_def'


It doesn’t seem to like libpng 1.6. Any more ideas?


It needs to be patched to use the accessor functions instead of 
accessing members of the png_info struct directly. This has been 
required since libpng 1.5 BTW (and direct access has been deprecated for 
quite a bit longer).


- Josh

Re: [MacPorts] Migration modified

[Joshua Root]

On 2017-8-30 01:00 , Rainer Müller wrote:

On 2017-08-29 16:41, Arno Hautala wrote:

Just as a message is sent to the user list when a new MacPorts version
is posted, a message could be sent when a new OS is released that
reminds users that migration will be required.


Such a message would probably only reach a small amount of users...

Before we discuss more workarounds, I still see no reason why it would
be required to run these steps before upgrading the OS. Otherwise I
would prefer to go back to the old order of steps that always work and
are less confusing.


+1

- Josh