Re: How to discontinue ports completely (py26 deprecation) ...

[Fred Wright]

On Fri, 12 Aug 2016, Chris Jones wrote:
> On 11/08/16 20:40, Fred Wright wrote:
[...]
> > Well, leaving something alone that's working just fine is hardly much of a
> > maintenance burden.
>
> On the other hand, whats the rationale for keeping 2.6, given 2.7 is the
> official upstream production version of the 2.x series. What use case
> requires 2.6 and cannot move to 2.7 ?

Testing code against 2.6 (among others), because it's intended to run on a
wide range of platforms, and one wants to make as few assumptions as
possible about what Python version(s) the end user might have installed.
Some distros lag *way* behind in versions of various things, including
Python.

If the python.org folks had their way, all 2.x versions would be
eradicated, but there were too many pitchforks at the gates to let that
happen. :-)

Fred Wright
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to discontinue ports completely (py26 deprecation) ...

[Chris Jones]

On 11/08/16 20:40, Fred Wright wrote:



On Wed, 10 Aug 2016, Lawrence Velázquez wrote:


On Aug 10, 2016, at 5:21 PM, Fred Wright  wrote:


I don't consider Python 2.6 to be "cruft".  Developers need many
versions of Python installed for testing, and that includes any
packages that are also needed.  It's annoying to have to create local
versions of portfiles solely to add versions that are missing for no
substantive reason.


The substantive reason is that every additional version of CPython we
support is a maintenance burden, especially one that saw its last
feature release 6 years ago and its last bugfix release nearly 3 years
ago.


Well, leaving something alone that's working just fine is hardly much of a
maintenance burden.


On the other hand, whats the rationale for keeping 2.6, given 2.7 is the 
official upstream production version of the 2.x series. What use case 
requires 2.6 and cannot move to 2.7 ?


Chris



BTW, there's some erroneous information that making code compatible with
both Python 2 and Python 3 requires 2.7.  I have yet to encounter any
issues with "polyglot" code per se on Python 2.6.  Anything earlier is
definitely problematic, however.

Fred Wright
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: port install v port mpkg | mdmg

[Rainer Müller]

Hello,

On 2016-08-10 17:23, Craig Treleaven wrote:
> Is it possible for a port to take different actions depending on
> whether the user has initiated ‘port install’ v. 'port mpkg’ (or
> ‘port mdmg’)?

Unfortunately, no, as all phases can be run individually. So up to the
destroot phase, there is no knowledge whether the following step would
be install or mpkg.

> My mythtv-pkg.27 is intended to be used to create an all-in-one
> installer package for MythTV.  I have a VM with a custom prefix for
> this.  The resulting mpkg needs daemondo, so I created the nasty hack
> in MacPorts_daemondo.  However, mythtv-pkg.27 could be a nice
> shortcut for a MacPorts user that wants to install a complete MythTV
> system in one go.  In such case, they don’t need MacPorts_daemondo.

One solution for this could be in base to automatically include daemondo
in the mpkg when it is used by the port being packaged.

See portmpkg::make_dependency_list in src/package1.0/portmpkg.tcl [1]
where the list of dependencies is generated. If the port to be packaged
has a startupitem, additionally include MacPorts_daemondo in the result
list.

Of course MacPorts_daemondo itself would still be a hack and require
force activation...

Rainer

[1]
https://trac.macports.org/browser/trunk/base/src/package1.0/portmpkg.tcl?rev=134837#L61
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [150851] users/devans/GNOME-3/unstable/dports/gnome/gdm

[Ryan Schmidt]

On Jul 29, 2016, at 11:11 PM, dev...@macports.org wrote:
> 
> Revision
> 150851
> Author
> dev...@macports.org
> Date
> 2016-07-29 21:11:56 -0700 (Fri, 29 Jul 2016)
> Log Message
> 
> GNOME-3/unstable: gdm, update to version 3.21.4, configure fails due to want 
> of libsystemd.


> Modified: 
> users/devans/GNOME-3/unstable/dports/gnome/gdm/files/patch-configure.ac.diff 
> (150850 => 150851)


>  -if test -x /usr/X11/bin/Xserver; then
> 
> -+if test -x @MP_PREFIX@/bin/Xquartz; then
> -+   X_PATH="@MP_PREFIX@/bin"
> -+   X_SERVER_PATH="@MP_PREFIX@/bin"
> -+   X_SERVER="@MP_PREFIX@/bin/Xquartz"
> 
> ++if test -x /opt/local/bin/Xquartz; then
> ++   X_PATH="/opt/local/bin"
> ++   X_SERVER_PATH="/opt/local/bin"
> ++   X_SERVER="/opt/local/bin/Xquartz"
> 
>  +   X_CONFIG_OPTIONS="-audit 0"

Perhaps an unintentional change?

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: A separate PortIndex for libc++ on older systems

[Ryan Schmidt]

> On Aug 11, 2016, at 3:13 PM, David Evans  wrote:
> 
> On 8/10/16 1:37 AM, Ryan Schmidt wrote:
>> On Jul 31, 2016, at 3:25 AM, dev...@macports.org wrote:
>> 
>>> Revision
>>> 150854
>>> Author
>>> dev...@macports.org
>>> Date
>>> 2016-07-31 01:25:57 -0700 (Sun, 31 Jul 2016)
>>> Log Message
>>> 
>>> gnome-maps: update to version 3.20.2, 3.18.3 for systems that don't support 
>>> libc++, now uses maps from MapBox.
>>> Modified Paths
>>> 
>>> • trunk/dports/gnome/gnome-maps/Portfile
>> 
>>> platform darwin {
>>> 
>>> if {${configure.cxx_stdlib} eq "libstdc++"} {
>>> 
>>> -version 3.18.2
>>> -revision1
>>> -checksums   rmd160  aecfc78e6299cea8328a8803037141ee15f13fc2 \
>>> -sha256  
>>> 693ff1559252eabe5d8c9c7354333b5aa1996e870936456d15706a0e0bac9278
>>> 
>>> +version 3.18.3
>>> +set branch  [join [lrange [split ${version} .] 0 1] .]
>>> +master_sites gnome:sources/${name}/${branch}/
>>> +checksums   rmd160  48567c80b517e8982a57b3e3e9ed6b8d126dd31e \
>>> +sha256  
>>> b164eda021a88cc7ec6773fd48428d102334b98cc196d69fa0186258b9c8b6ed
>>> 
>> 
>> 
>> Currently, there is only one PortIndex file generated on the server, and 
>> published to the rsync server, for each OS name/version/endianness 
>> combination. So for example, there is one PortIndex for Darwin 12 Intel. 
>> There is not currently a separate PortIndex for Darwin 12 Intel with libc++, 
>> so anyone with e.g. OS X 10.8 with libc++ syncing from the rsync server will 
>> see the version of this port as 3.20.2 not 3.18.3 when querying the index, 
>> for example when running port info or port outdated. If we're going to 
>> change Portfile attributes such as version that get stored in the index 
>> based on the C++ library, and I agree this is a situation that would arise 
>> more and more as newer versions of software require libc++, should we make a 
>> separate libc++ PortIndex for 10.6/10.7/10.8?
>> 
> 
> OK, I just tumbled to what you're saying here.  As you say, the indexed 
> version of this port will be determined by the
> value of configure.cxx_stdlib on the machine that is doing the indexing and, 
> for those that use the rsynced indexes,
> that machine may not be running the same C++ configuration (or even the same 
> OS version) as the user's machine.

We generate a portindex for each macOS version. And for 10.4 and 10.5 which run 
on Intel and PowerPC, we generate separate indexes for Intel and PowerPC. So 
although the portindex is not generated individually on each macOS version (in 
fact, for several years, it has been generated on a Linux machine), it contains 
information specific to that macOS version. However, the portindexing process 
does not currently know about libc++ and libstdc++ and that things in the 
index, such as a port's version, might differ based on that variable. I'm 
proposing we teach the indexing process about that and create a second index 
for macOS < 10.9 with libc++.


> This
> works for me because, as a maintainer, I use subversion to fetch Portfiles 
> and regenerate the PortIndex myself.  In that
> context this works fine.

That's right. Those using svn generate their own indexes and don't see the ones 
on the rsync server.


> As you say, the world is quickly moving on. Even projects like Inkscape, 
> which has been slow to update to C++11 and gtk3
> has announced that the upcoming 0.92 release will be the last to support 
> C++98 (libstdc++) and gtk2.  Trunk development
> has already moved to requiring C++11 and libc++ to build.
> 
> Similarly, glibmm, gtkmm3 and friends have required C++11 (libc++) to build 
> for two stable release cycles now and are
> proposing requiring C++14 in the next based on the fact that that is the 
> default standard for gcc6.  So, while I have
> been tracking the latest releases in my C++11 respositories,  I have been 
> holding back on some of these releases for a
> while pondering how to handle this libstdc++/libc++ dichotomy.
> 
> Personally, given time and resouces, I would rather dispense with maintaining 
> outdated versions of GNOME ports
> altogether and just use the cxx11 PortGroup where applicable.  It makes sense 
> to me that we should put pressure on
> users with older platforms to configure themselves to use libc++ where they 
> possibly can rather than giving them further
> excuses to stay with libstdc++ and C++98.  Maybe put the onus on those who 
> want to stay with the older systems to curate
> a separate repository(ies) altogether of ports whose versions are cherry 
> picked to be compatible with their systems.
> You could even provide separate buildbots for these systems.
> 
> So, before coming up with more complex indexing systems, etc, maybe we need 
> to take a clear look at what we can really
> afford to support.  At the very least, the newer standards should have a 
> higher priority for support over the older.
> Right