Re: Releasing code as portgroup instead of in base/

2014-10-09 Thread Ryan Schmidt 

On Sep 29, 2014, at 10:59 AM, Daniel J. Luke wrote:

> On Sep 28, 2014, at 2:55 AM, Ryan Schmidt wrote:
>> 
>> Moving this code to a portgroup would make it possible for us to fix this 
>> problem and any other problems that might come up later without having to 
>> produce a new MacPorts release.
> 
> I think we really should move in the other direction:
> 
> -make releases easier
> -less code in portgroups (move as much as possible to base/)
> 
> someone can say "I did foo with macports version x.y.z", it's hard for an 
> end-user to know "I did foo with macports verison x.y.z and the revision of 
> portgroup blah that I got in my last portsync which corresponds with rXX 
> in your repo"

Sorry for my delay in responding to this.

I disagree that we should move as many portgroups as possible into base. Moving 
the portgroups out of base and into the ports tree years ago has been of great 
benefit in encouraging the development of portgroups. No matter how agile the 
release process of base may become, nothing compares to being able to put a 
file in a directory and having it available to the entire MacPorts userbase in 
minutes.

Conceptually, the portgroups belong with the ports. It has often been necessary 
to make a change to a portgroup and changes to the ports that use it 
simultaneously in the same commit; that's not possible when there is a 
non-automated or delayed release process for base, as there currently is and as 
there probably needs to continue to be.

I don't oppose making base releases easier, however I don't think we want to go 
as far as we go with the ports tree. We want to have some sort of testbed for 
base changes before they go to all users. We want developers to be able to run 
a development version of base before potential problems inconvenience regular 
users.

Another argument against putting all portgroups back in base: When I'm making a 
change to a portgroup, I don't want to also be responsible for also 
understanding all other changes that went into base since the last release. All 
I care about when changing a portgroup is the portgroup and the ports that use 
it.

I'm not against moving *some* portgroups' functionalities into base, such as 
the compiler_blacklist_versions, conflicts_build and muniversal portgroups. The 
spirit of the archcheck portgroup is already in base. But portgroups that are 
closely tied to a particular subset of ports, like language modules, feel like 
they belong where they currently are.

We could even talk about moving support for some build systems into base. Xcode 
and cmake are certainly popular build systems that aren't going away, and the 
portgroup haven't needed to change that much recently, so they may be stable 
enough to be in base. So "PortGroup cmake 1.0" would change to "use_cmake yes" 
for example.

I continue to think that xmkmf/imake support should be moved out of base and 
into a portgroup. Why should someone trying to read and understand base code 
have to encounter xmkmf/imake code applicable to only a handful of old ports? 
Further, the xmkmf/imake support in base is incomplete (doesn't use the right 
compiler, doesn't use -arch flags, doesn't add the universal variant). I can 
either leave this aspect of those ports broken, or spend time figuring out what 
to modify in base to fix this, or I can trivially fix this with a few lines in 
a portgroup I've already written. I would like to do the latter. I'm trying to 
make the needed changes to all the ports that use imake and make sure they 
build before committing this.



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

Re: [126340] trunk/dports/kde/kdelibs4

2014-10-09 Thread Ryan Schmidt 
On Oct 8, 2014, at 6:03 AM, ni...@macports.org wrote:
> 
> 126340
> Author
> ni...@macports.org
> Date
> 2014-10-08 04:03:41 -0700 (Wed, 08 Oct 2014)
> Log Message
> 
> kdelibs4: update to 4.13.3
> add patches
> review dependencies

> --- trunk/dports/kde/kdelibs4/Portfile2014-10-08 10:38:21 UTC (rev 
> 126339)
> +++ trunk/dports/kde/kdelibs4/Portfile2014-10-08 11:03:41 UTC (rev 
> 126340)

> @@ -29,14 +28,12 @@
>  depends_build-append port:flex port:gmake port:docbook-xsl-ns
>  
>  depends_lib-append  port:bzip2 port:zlib \
> -port:soprano port:cyrus-sasl2 \
> +port:soprano \
>  port:strigi port:gettext \
>  port:pcre port:shared-mime-info \
> -lib:libgif:giflib port:tiff \
> +lib:libgif:giflib \
>  port:jpeg port:libpng \
>  port:jasper port:openexr \
> -port:expat port:libart_lgpl \
> -port:libidn port:libiconv \
>  path:lib/pkgconfig/glib-2.0.pc:glib2 \
>  port:openssl port:enchant \
>  port:aspell port:aspell-dict-en \

The giflib dependency should be written "port:giflib". "lib:" (and "bin:") 
dependencies are only used when you want to allow a library (or binary) outside 
of the MacPorts prefix to be able to satisfy the dependency, and it's rare that 
we want that.


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

Re: [126400] trunk/dports/graphics/opencv/Portfile

2014-10-09 Thread Ryan Schmidt 

> On Oct 9, 2014, at 6:52 AM, strom...@macports.org wrote:
> 
> Revision
> 126400
> Author
> strom...@macports.org
> Date
> 2014-10-09 04:52:07 -0700 (Thu, 09 Oct 2014)
> Log Message
> 
> opencv: add qt5 and vtk variants

> Modified: trunk/dports/graphics/opencv/Portfile (126399 => 126400)
> --- trunk/dports/graphics/opencv/Portfile 2014-10-09 11:30:23 UTC (rev 
> 126399)
> +++ trunk/dports/graphics/opencv/Portfile 2014-10-09 11:52:07 UTC (rev 
> 126400)
> @@ -65,12 +65,14 @@
>  -DWITH_CARBON=OFF \
>  -DWITH_CUBLAS=OFF \
>  -DWITH_CUDA=OFF \
> +-DWITH_VTK=OFF \
>  -DWITH_CUFFT=OFF \
> +-DWITH_CUBLAS=OFF \
>  -DWITH_EIGEN=OFF \
>  -DWITH_FFMPEG=ON \
>  -DWITH_GSTREAMER=OFF \
>  -DWITH_GTK=OFF \
> --DWITH_IMAGEIO=OFF \
> +-DWITH_IMAGEIO=ON \
>  -DWITH_IPP=OFF \
>  -DWITH_JASPER=ON \
>  -DWITH_JPEG=ON \

Changing WITH_IMAGEIO from OFF to ON probably means you want to increase the 
port's revision.


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

Re: [126395] trunk/dports/python

2014-10-09 Thread Joshua Root 
On 2014-10-10 05:10 , Lawrence Velázquez wrote:
> On Oct 9, 2014, at 7:11 AM, Joshua Root  wrote:
> 
>> On 2014-10-9 20:32 , Ryan Schmidt wrote:
>>
>>> py-graveyard doesn't seem to be taking the epoch into account. Note that 
>>> before, py25-boto was epoch 1 version 2.8.0 revision 0, and now it's epoch 
>>> 0 version 2.8.0 revision 1. I don't understand why it nevertheless seems to 
>>> be working:
> 
> A happy accident, I'm afraid. I didn't think about epochs at all.
> 
>> The version didn't change. An epoch is only relevant when comparing
>> different versions.
> 
> Is this behavior intentional?

Yes.

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

Re: [126395] trunk/dports/python

2014-10-09 Thread Lawrence Velázquez 
On Oct 9, 2014, at 7:11 AM, Joshua Root  wrote:

> On 2014-10-9 20:32 , Ryan Schmidt wrote:
> 
>> py-graveyard doesn't seem to be taking the epoch into account. Note that 
>> before, py25-boto was epoch 1 version 2.8.0 revision 0, and now it's epoch 0 
>> version 2.8.0 revision 1. I don't understand why it nevertheless seems to be 
>> working:

A happy accident, I'm afraid. I didn't think about epochs at all.

> The version didn't change. An epoch is only relevant when comparing
> different versions.

Is this behavior intentional?

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

Re: [MacPorts] #45311: Error: org.macports.build for port ttf2pt1 returned: command execution failed

2014-10-09 Thread Craig Treleaven 

At 2:08 PM + 10/9/14, MacPorts wrote:

#45311: Error: org.macports.build for port ttf2pt1 returned: command execution
failed
-+
  Reporter:  asnedden@Š  |  Owner:  macports-tickets@Š
  Type:  defect  | Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |Version:  2.3.1
Resolution:  |   Keywords:  tt2pt1
  Port:  tt2pt1  |
-+

Comment (by asnedden@Š):

 I guess this may be useless since there isn't a maintainer...

--
Ticket URL: 


Plus upstream hasn't had a release since 2003!!

However, if there is any hope of addressing this, 
we'll need a clean build log.  Enter:


sudo port clean ttf2pt1 && sudo port install ttf2pt1

If it fails again, the last few lines of output 
will tell you the location of the build log.


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

Re: [126395] trunk/dports/python

2014-10-09 Thread Joshua Root 
On 2014-10-9 20:32 , Ryan Schmidt wrote:
> 
>> On Oct 9, 2014, at 3:26 AM, lar...@macports.org wrote:
>>
>> Revision
>> 126395
>> Author
>> lar...@macports.org
>> Date
>> 2014-10-09 01:26:13 -0700 (Thu, 09 Oct 2014)
>> Log Message
>>
>> py25-boto: Replace with py27-boto
> 
>> Modified: trunk/dports/python/py-boto/Portfile (126394 => 126395)
>> --- trunk/dports/python/py-boto/Portfile 2014-10-09 08:26:10 UTC (rev 
>> 126394)
>> +++ trunk/dports/python/py-boto/Portfile 2014-10-09 08:26:13 UTC (rev 
>> 126395)
>> @@ -8,7 +8,7 @@
>>  set real_name   boto
>>  epoch   1
>>  version 2.8.0
>> -python.versions 25 26 27
>> +python.versions 26 27
>>  maintainers nomaintainer
>>  license MIT
>>  supported_archs noarch
>> Modified: trunk/dports/python/py-graveyard/Portfile (126394 => 126395)
>> --- trunk/dports/python/py-graveyard/Portfile2014-10-09 08:26:10 UTC 
>> (rev 126394)
>> +++ trunk/dports/python/py-graveyard/Portfile2014-10-09 08:26:13 UTC 
>> (rev 126395)
>> @@ -35,6 +35,7 @@
>>  antlr3  3.1.3_1 25
>>  aspects 1.3_1   25
>>  blessings   1.5_1   25 31 32
>> +boto2.8.0_1 25
>>  buzhug  1.8_1   25
>>  cherrypy3   3.2.0_1 24 25
>>  dap 2.2.6.7_1   24 25
> 
> py-graveyard doesn't seem to be taking the epoch into account. Note that 
> before, py25-boto was epoch 1 version 2.8.0 revision 0, and now it's epoch 0 
> version 2.8.0 revision 1. I don't understand why it nevertheless seems to be 
> working:
> 
> $ port install py25-boto
> --->  Computing dependencies for py25-boto
> --->  Fetching distfiles for py25-boto
> --->  Verifying checksums for py25-boto
> --->  Extracting py25-boto
> --->  Configuring py25-boto
> --->  Building py25-boto
> --->  Staging py25-boto into destroot
> --->  Installing py25-boto @2.8.0_0
> --->  Activating py25-boto @2.8.0_0
> --->  Cleaning py25-boto
> $ port sync
> --->  Updating the ports tree
> $ port outdated py25-boto
> The following installed ports are outdated:
> py25-boto  2.8.0_0 < 2.8.0_1  
> $

The version didn't change. An epoch is only relevant when comparing
different versions.

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

Re: [126395] trunk/dports/python

2014-10-09 Thread Ryan Schmidt 

> On Oct 9, 2014, at 3:26 AM, lar...@macports.org wrote:
> 
> Revision
> 126395
> Author
> lar...@macports.org
> Date
> 2014-10-09 01:26:13 -0700 (Thu, 09 Oct 2014)
> Log Message
> 
> py25-boto: Replace with py27-boto

> Modified: trunk/dports/python/py-boto/Portfile (126394 => 126395)
> --- trunk/dports/python/py-boto/Portfile  2014-10-09 08:26:10 UTC (rev 
> 126394)
> +++ trunk/dports/python/py-boto/Portfile  2014-10-09 08:26:13 UTC (rev 
> 126395)
> @@ -8,7 +8,7 @@
>  set real_name   boto
>  epoch   1
>  version 2.8.0
> -python.versions 25 26 27
> +python.versions 26 27
>  maintainers nomaintainer
>  license MIT
>  supported_archs noarch
> Modified: trunk/dports/python/py-graveyard/Portfile (126394 => 126395)
> --- trunk/dports/python/py-graveyard/Portfile 2014-10-09 08:26:10 UTC (rev 
> 126394)
> +++ trunk/dports/python/py-graveyard/Portfile 2014-10-09 08:26:13 UTC (rev 
> 126395)
> @@ -35,6 +35,7 @@
>  antlr3  3.1.3_1 25
>  aspects 1.3_1   25
>  blessings   1.5_1   25 31 32
> +boto2.8.0_1 25
>  buzhug  1.8_1   25
>  cherrypy3   3.2.0_1 24 25
>  dap 2.2.6.7_1   24 25

py-graveyard doesn't seem to be taking the epoch into account. Note that 
before, py25-boto was epoch 1 version 2.8.0 revision 0, and now it's epoch 0 
version 2.8.0 revision 1. I don't understand why it nevertheless seems to be 
working:

$ port install py25-boto
--->  Computing dependencies for py25-boto
--->  Fetching distfiles for py25-boto
--->  Verifying checksums for py25-boto
--->  Extracting py25-boto
--->  Configuring py25-boto
--->  Building py25-boto
--->  Staging py25-boto into destroot
--->  Installing py25-boto @2.8.0_0
--->  Activating py25-boto @2.8.0_0
--->  Cleaning py25-boto
$ port sync
--->  Updating the ports tree
$ port outdated py25-boto
The following installed ports are outdated:
py25-boto  2.8.0_0 < 2.8.0_1  
$


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

Re: [126385] trunk/dports/irc/quassel/Portfile

2014-10-09 Thread Ryan Schmidt 
On Oct 9, 2014, at 4:11 AM, Ryan Schmidt wrote:
> 
> 
>> On Oct 9, 2014, at 3:23 AM, siche...@macports.org wrote:
>> 
>> Revision
>> 126385
>> Author
>> siche...@macports.org
>> Date
>> 2014-10-09 01:23:42 -0700 (Thu, 09 Oct 2014)
>> Log Message
>> 
>> quassel: add *llvm-gcc-4.2 to blacklist
> 
>> Modified: trunk/dports/irc/quassel/Portfile (126384 => 126385)
>> 
>> --- trunk/dports/irc/quassel/Portfile2014-10-09 08:12:33 UTC (rev 
>> 126384)
>> +++ trunk/dports/irc/quassel/Portfile2014-10-09 08:23:42 UTC (rev 
>> 126385)
>> @@ -18,7 +18,7 @@
>> 
>> # Blacklist compilers not supporting C++11
>> compiler.blacklist-append \
>> -*gcc-4.0 *gcc-4.2 {clang < 137}
>> +*gcc-4.0 *gcc-4.2 *llvm-gcc-4.2 {clang < 137}
> 
> "*gcc-4.2" already matches llvm-gcc-4.2

The reason for the build failure on Snow Leopard is that although the Xcode 
clang compiler collection is being used, on Xcode 3 there is no clang++ 
compiler to handle C++ code, therefore the Xcode clang compiler collection uses 
llvm-g++-4.2 as the C++ compiler on Xcode 3.

The solution is to blacklist those versions of clang by adding "{clang < 137}" 
to the compiler.blacklist.

You've already done this! But it is not having any effect because you have 
forgotten to add the line "PortGroup compiler_blacklist_version 1.0" to the top 
of the portfile. It is the compiler_blacklist_versions portgroup that knows how 
to blacklist only specific versions of compilers; MacPorts base itself only 
knows how to blacklist compilers by name.

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

Re: [126385] trunk/dports/irc/quassel/Portfile

2014-10-09 Thread Ryan Schmidt 

> On Oct 9, 2014, at 3:23 AM, siche...@macports.org wrote:
> 
> Revision
> 126385
> Author
> siche...@macports.org
> Date
> 2014-10-09 01:23:42 -0700 (Thu, 09 Oct 2014)
> Log Message
> 
> quassel: add *llvm-gcc-4.2 to blacklist

> Modified: trunk/dports/irc/quassel/Portfile (126384 => 126385)
> 
> --- trunk/dports/irc/quassel/Portfile 2014-10-09 08:12:33 UTC (rev 126384)
> +++ trunk/dports/irc/quassel/Portfile 2014-10-09 08:23:42 UTC (rev 126385)
> @@ -18,7 +18,7 @@
>  
>  # Blacklist compilers not supporting C++11
>  compiler.blacklist-append \
> -*gcc-4.0 *gcc-4.2 {clang < 137}
> +*gcc-4.0 *gcc-4.2 *llvm-gcc-4.2 {clang < 137}

"*gcc-4.2" already matches llvm-gcc-4.2

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

Re: Issue with c++11 support

2014-10-09 Thread Ryan Schmidt 

On Oct 8, 2014, at 9:23 AM, Nicolas Pavillon wrote:

> When trying to upgrade akonadi, I realised that it fails on 10.8 and earlier, 
> as it seems to require in the latest versions a full c++11 support, so that 
> it fails with errors of the type:
> /opt/local/var/macports/build/_opt_mports_dports_devel_akonadi/akonadi/work/akonadi-1.13.0/server/tests/unittest/akappendhandlertest.cpp:523:26:
>  error: no matching constructor for initialization of 'const 
> std::vector &'
>updateTags(tags, { { QLatin1String("PLAIN"), utf8String } });
> As trying to force the build with -stdlib=libc++ would provide libraries with 
> issues on runtime, I am not sure of what could be done, as there is 
> apparently no switch in the code to use older syntaxes. 
> 
> One possibility would be to make an additional port akonadi112 that older 
> systems could rely on, but this seems quite a hassle. I am missing something 
> that could tackle the issue?

You've basically got it. If a project needs C++11, then it needs libc++, which 
for now means it needs OS X 10.9 or later.


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