gmane.os.apple.macports.devel

Re: [MacPorts] #34570: perl5.16 - new port

Ryan Schmidt — 2012-05-24T01:44:10

On May 23, 2012, at 20:25, Bjarne D Mathiesen wrote:


portindex always only concerns itself with the single ports tree you're running the command in.

Re: [MacPorts] #34552: mysql55 - using builtin readline breaksbuilding

Bradley Giesbrecht — 2012-05-24T01:43:11

On May 23, 2012, at 6:29 PM, Ryan Schmidt wrote:


Me too...

Re: [MacPorts] #34552: mysql55 - using builtin readline breaksbuilding

Ryan Schmidt — 2012-05-24T01:29:39

On May 23, 2012, at 20:04, Bradley Giesbrecht wrote:


That's what I'm using as well. If you post your main.log of the successful build, and I post mine of my failed build, we can compare them. If we build them without ccache or parallel building and without the universal variant they'll be easier to diff:

sudo port clean mysql55
sudo port build mysql55 -universal configure.ccache=no build.jobs=1

I'll start that on my system now....

Re: [MacPorts] #34570: perl5.16 - new port

Bjarne D Mathiesen — 2012-05-24T01:25:31

OK ... It's working now :-D

I had to do the following to get it to work

1) modify the perl5-1.0.tcl by overwriting it with a modified copy
2) copy the whole perl5.16 port from my private repo
3) delete the two PortIndex* files
4) portindex

Doing each of (1) to (3) alone wasn't enough ... _all_ three steps has
to be taken ... and I think I've tried all eight combinations ;-) incl
forgetting to do (1) because a /port sync/ had restored the default.

So ... portindex is  -as a minimum- _unable_ to combine a private repo
with the official repo in a case like this.

bash-4.2$ port list name:^p5.16
p5.16-acme-lolcat              < at >0.0.5          perl/p5-acme-lolcat
p5.16-algorithm-annotate       < at >0.100.0        perl/p5-algorithm-annotate
p5.16-algorithm-c3             < at >0.80.0         perl/p5-algorithm-c3
...
p5.16-yaml-syck                < at >1.170.0        perl/p5-yaml-syck
p5.16-yaml-tiny                < at >1.510.0        perl/p5-yaml-tiny
p5.16-zeromq                   < at >0.180.0        perl/p5-zeromq


Now for some

Re: [MacPorts] #34552: mysql55 - using builtin readline breaksbuilding

Lawrence Velázquez — 2012-05-24T01:18:12



% sw_vers -productVersion; xcodebuild -version
10.7.4
Xcode 4.3.2
Build version 4E2002

vq

Re: [MacPorts] #34552: mysql55 - using builtin readline breaksbuilding

Bradley Giesbrecht — 2012-05-24T01:04:12

On May 23, 2012, at 5:54 PM, Ryan Schmidt wrote:


Are the failed builds with a particular Xcode?

What versions of Xcode or on the buildbot?

Here is what I'm building with:
sw_vers -productVersion; xcodebuild -version
10.7.2
Xcode 4.1
Build version 4B110

sw_vers -productVersion; xcodebuild -version
10.6.8
Xcode 3.2.6
Component versions: DevToolsCore-1809.0; DevToolsSupport-1806.0
BuildVersion: 10M2518



Regards,
Bradley Giesbrecht (pixilla)

Re: [MacPorts] #34552: mysql55 - using builtin readline breaksbuilding

Ryan Schmidt — 2012-05-24T00:54:36

On May 23, 2012, at 19:39, Bradley Giesbrecht wrote:

 se_tarballs_ports_databases_mysql55/mysql55/work/mysql-5.5.24/storage/innobase/handler -I/macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports
 _databases_mysql55/mysql55/work/mysql-5.5.24/sql -I/macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_databases_mysql55/mysql55/work/mysql-5.5.24/regex -I/macports/include    -I/macports/include -o CMakeFiles/innobase.dir/dict/dict0load.c.o   -c /macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_databases_mysql55/mysql55/work/mysql-5.5.24/storage/innobase/dict/dict0load.c

I don't see an arch mismatch? I see a computer running Lion (which always requires an x86_64 processor; the "arch i386" refers to the architecture of the kernel, which is irrelevant), and I see it compiling with "-arch x86_64" which is as it should be.

Re: [MacPorts] #34552: mysql55 - using builtin readline breaksbuilding

Bradley Giesbrecht — 2012-05-24T00:39:13

I see this in Bjarne's log file.
...
:debug:main OS darwin/11.3.0 (Mac OS X 10.7) arch i386
...
:info:build cd /macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_databases_mysql55/mysql55/work/mysql-5.5.24/storage/innobase && /usr/bin/clang  -DHAVE_CONFIG_H -DUNIV_MUST_NOT_INLINE -DHAVE_IB_GCC_ATOMIC_BUILTINS=1 -DHAVE_IB_ATOMIC_PTHREAD_T_GCC=1 -DSIZEOF_PTHREAD_T=8 -pipe -O2 -arch x86_64  -O3 -DNDEBUG -DDBUG_OFF -arch x86_64 -I/macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_databases_mysql55/mysql55/work/mysql-5.5.24/include -I/macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_databases_mysql55/mysql55/work/mysql-5.5.24/storage/innobase/include -I/macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_databases_mysql55/mysql55/work/mysql-5.5.24/storage/innobase/handler -I/macports/var/macports/build/_macports_v

Re: apache2 httpd 2.4.2

Ryan Schmidt — 2012-05-24T00:36:51

On May 23, 2012, at 19:28, Bradley Giesbrecht wrote:


Hmm, I had thought there would be more than that.



Note that mod_ssi_func isn't a good example because it specifically requires apache 2.0; it does not work with 2.2 or later, as I understand it.



Agreed!

Re: apache2 httpd 2.4.2

Bradley Giesbrecht — 2012-05-24T00:28:45

On May 23, 2012, at 4:05 PM, Ryan Schmidt wrote:


Is this not accurate?
port file depends:apache2 or variant:apache | sort -u | wc -l
      44


Might not be that big of a project.
$ echo $MP_SVNDPORTS 
/opt/local/var/macports/sources/svn.macports.org/trunk/dports
$ find $MP_SVNDPORTS -maxdepth 3 -name Portfile -exec echo {} \; -exec grep -E "/apache2" {} \; | grep -B1 -v /Portfile

Some ports would become simpler with apxs in PATH.

/opt/local/var/macports/sources/svn.macports.org/trunk/dports/www/mod_ssi_func/Portfile
...
build {
    foreach mod ${mods} {
        system "cd ${worksrcpath}/${mod} && \
            make APXS=${prefix}/apache20/bin/apxs"
    }
}

destroot {
    foreach mod ${mods} {
        system "cd ${worksrcpath}/${mod} && \
            make install APXS=${prefix}/apache20/bin/apxs DESTDIR=${destroot}"
    }
}
...
becomes
...
build.cmd    apxs
build {
    foreach mod ${mods} {
        build.dir                  ${mod}
        command_exec    build
    }
}

destroot {
    foreach mod ${mod

Re: [MacPorts] #34570: perl5.16 - new port

Lawrence Velázquez — 2012-05-24T00:19:42



This is also the way that subports for Python modules work.

vq

Re: [MacPorts] #34570: perl5.16 - new port

Ryan Schmidt — 2012-05-24T00:14:24

On May 22, 2012, at 15:12, Bjarne D Mathiesen wrote:


And you're sure the perl5-1.0.tcl file you're modifying is the one in the directory /macports/var/macports/sources/rsync.macports.org/release/tarballs/ports/_resources/port1.0/groups?

If so, then maybe portindex does some kind of mtime checking and only indexes Portfiles newer than the PortIndex files. In that case, try deleting PortIndex and PortIndex.quick before running portindex. If that solves it, then I guess we'll have to manually intervene on the servers too when we do this update.

It seems weird to me that a change in the portgroup should be allowed to create new subports in ports that have not themselves been modified to indicate that that's ok. It seems to me that instead each p5 port should be specifying which perl versions it's compatible with. Thus, when a new version of perl is released, each p5 port would be modified to indicate its compatibility with that new version, thus getting that port's new p5.16 subport into the index at that t

Re: apache2 httpd 2.4.2

Bjarne D Mathiesen — 2012-05-23T23:17:18

We could also do another thing :

1) keep the layout as it is now and upgrade completely to 2.4.x as was
posited by you -Ryan- in a previous post.

2) work on a longterm project where we gradually find every port that
assumes the current layout and convert them

3) after testing (2) make a _BIG_ _BANG_ upgrading from the present
layout to a layout that doesn't violate mtree

I find it of more value to get 2.4.x into the tree than to wait any
longer for a new layour which we don't have any time frame for. We are
already a couple of months late in releasing 2.4.x to the public.

:-)

Re: apache2 httpd 2.4.2

Ryan Schmidt — 2012-05-23T23:05:46

On May 23, 2012, at 16:39, Bradley Giesbrecht wrote:


The only one I can think of is that tons of other ports currently assume that's the layout. Thus changing the apache2 layout requires changing tons of ports in unison.

If we instead made a new apache24 port we would be free to give it any layout we wanted, and then over time adapt all the other ports to depend on apache24 instead of apache2. It would still be an unpleasant time for users of those ports until all of them are converted and apache2 is deprecated.

Re: How to fix "broken ports"?

Ryan Schmidt — 2012-05-23T22:59:51

On May 22, 2012, at 23:55, Marko Käning wrote:


For the record, that's not how it is on my system. On my system it appears to be made properly:

$ otool -L /opt/local/lib/libphonon.4.dylib
/opt/local/lib/libphonon.4.dylib:
/opt/local/lib/libphonon.4.dylib (compatibility version 4.4.0, current version 4.4.2)
/opt/local/lib/libQtDBus.4.dylib (compatibility version 4.7.0, current version 4.7.3)
/opt/local/lib/libQtXml.4.dylib (compatibility version 4.7.0, current version 4.7.3)
/opt/local/lib/libQtGui.4.dylib (compatibility version 4.7.0, current version 4.7.3)
/opt/local/lib/libQtCore.4.dylib (compatibility version 4.7.0, current version 4.7.3)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.10)



install_name_tool is really a last resort kind of thing. You should be able to specify the library's install_name at link time (with the -install_name parameter), and indeed on my system that's pr

Re: apache2 httpd 2.4.2

Bradley Giesbrecht — 2012-05-23T21:39:29

On May 23, 2012, at 1:43 PM, Bjarne D Mathiesen wrote:


It's been brought up before. Something like this upgrade to 2.4 is likely the only time this layout can be improved.

http://thread.gmane.org/gmane.os.apple.macports.devel/4462/focus=4468
http://thread.gmane.org/gmane.os.apple.macports.user/7154/focus=7160
There are more examples.

What is the argument for apache2 to continue violating mtree?

Re: apache2 httpd 2.4.2

Bjarne D Mathiesen — 2012-05-23T20:43:24

I'm actually very satisfied with the current situation.
So unless the hive-mind collectively decides otherwise, I'm not going to
work on implementing this.

Re: apache2 httpd 2.4.2

Bjarne D Mathiesen — 2012-05-23T20:27:33

Well, it's not a module that I'm at present going to use, but I do think
I can post our problems as well as the solution on their mailing list.

As to maintaining the port, I'm more or less at present the one taking
care of the whole Apache httpd 2.4.x migration mess as well as all of
the mod_* stuff ;-)


:-)

Re: [enhancement] proposal - make all ports independent of whichversion of Perl is installed or the major one

Daniel J. Luke — 2012-05-23T20:24:44

which is precisely the reason why we should just focus on 'one good' version of perl (and associated perl modules) unless/until someone has time to make something better work.

We can fairly easily have ports for other perls (and just not provide p5 ports for them) for the (few) cases where someone needs to have a specific version of perl that isn't our default perl.

--
Daniel J. Luke                                                                   
+========================================================+                        
| *---------------- dluke-2DB0d86rw/3k1uMJSBkQmQ< at >public.gmane.org ----------------* |                          
| *-------------- http://www.geeklair.net -------------* |                          
+========================================================+                        
|   Opinions expressed are mine and do not necessarily   |                          
|          reflect the opinions of my employer.          |                          
+================================

Re: apache2 httpd 2.4.2

Bjarne D Mathiesen — 2012-05-23T20:23:53

I've just done almost the same ... but within macports ...

DEBUG: Privilege de-escalation not attempted as not running as root.
DEBUG: patch phase started at Wed May 23 22:14:49 CEST 2012
DEBUG: Executing org.macports.patch (mod_fastcgi)
--->  Applying patches to mod_fastcgi
--->  Applying byte-compile-against-apache24.diff
DEBUG: Environment: CPATH='/macports/include'
CC_PRINT_OPTIONS_FILE='/macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_www_mod_fastcgi/mod_fastcgi/work/.CC_PRINT_OPTIONS'
LIBRARY_PATH='/macports/lib' CC_PRINT_OPTIONS='YES'
MACOSX_DEPLOYMENT_TARGET='10.7'
DEBUG: Assembled command: 'cd
"/macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_www_mod_fastcgi/mod_fastcgi/work/mod_fastcgi-2.4.6"
&& /usr/bin/patch -p1'
DEBUG: Executing command line:  cd
"/macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_www_mod_fastcgi/mod_fastcgi/work/mod_fastc

Re: apache2 httpd 2.4.2

Daniel J. Luke — 2012-05-23T20:13:57

[removed -users]

On May 23, 2012, at 3:32 PM, Daniel J. Luke wrote:


I did just try the patch there (which is actually at https://github.com/ByteInternet/libapache-mod-fastcgi/blob/byte/debian/patches/byte-compile-against-apache24.diff) and it built fine and a simple test shows it working with apache2.4 (both apache and mod_fastcgi built outside of macports).

--
Daniel J. Luke                                                                   
+========================================================+                        
| *---------------- dluke-2DB0d86rw/3k1uMJSBkQmQ< at >public.gmane.org ----------------* |                          
| *-------------- http://www.geeklair.net -------------* |                          
+========================================================+                        
|   Opinions expressed are mine and do not necessarily   |                          
|          reflect the opinions of my employer.          |                          
+=======================================