From afb at macports.org Sun Jul 1 01:19:47 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Oct 9 16:40:25 2007 Subject: defluffing Portfiles (port lint) Message-ID: <04d7aa6ce326e56b98441724699ceee7@macports.org> Apparently one of the oldest feature requests around... http://trac.macports.org/projects/macports/ticket/463 I created a basic implementation, for later expansion: http://trac.macports.org/projects/macports/ticket/12211 It does the following: - implicitly checks that Tcl syntax is reasonable - checks the document for invalid UTF-8 sequences - checks for blank newlines after certain fields - checks for trailing whitespace before newline - checks that PortSystem is present (but only once) - checks that all required variables are present - checks for maintainer darwinports@opendarwin.org Results are divided into (fatal) errors and warnings, while passed checks can be viewed using the -v flag. There are several other Portfile checks left TODO, but at least it's a start in the right direction... Note: it currently *only* checks the Portfile, and not the files directory nor the generated destroot. --anders PS. Of course it is inspired by FreeBSD portlint(1) http://www.freebsd.org/cgi/man.cgi? query=portlint&sektion=1&manpath=FreeBSD+Ports From afb at macports.org Sun Jul 1 05:10:50 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Oct 9 16:40:25 2007 Subject: Platform versions and Binaries Message-ID: <475c409bd49ef88377ab5d7a4a8a1d25@macports.org> There is a upcoming problem that will occur with the binary archives/packages, in that most of the code currently only checks for ${os.platform} and ${os.arch} when looking for binaries, ignoring ${os.version} which might be important ? e.g. Panther and Tiger will try to use the same binaries and archives, and ditto for FreeBSD STABLE and CURRENT... So we might need to include at least the major version in the paths used, so that they will become something like: darwin/9/i386/ darwin/9/ppc/ darwin/8/i386/ darwin/8/ppc/ darwin/7/ppc/ freebsd/7/i386/ freebsd/6/i386/ freebsd/5/i386/ ... This goes for /opt/local/var/macports/packages, and for remote fetching. It also goes for all RPM repositories. Universal packages should probably go in a special place too, since they use the 10.4.u SDK and the "fat" arch ? Eventually one _might_ want to share "noarch"* packages between architectures, and maybe even between platforms. --anders * http://trac.macports.org/projects/macports/ticket/12206 From bwaters at nrao.edu Mon Jul 2 08:23:02 2007 From: bwaters at nrao.edu (Boyd Waters) Date: Tue Oct 9 16:40:25 2007 Subject: symbolic link traversal Message-ID: Howdy all! When you get finished playing with your shiny new iPhone, I have a maybe-stupid question about symbolic links: 1) Does MacPorts traverse symlinks in the middle of a path/like/this (where "like" would be a symlink) I found a likely bit of Tcl code, and attempted to set it up to recursively resolve symlinks correctly during path traversal, but was not able to fix the problem. I've been holding off on committing my Python ports -- which permit multiple, parallel versions of MacPorts to co-exist on a system -- but I would rather get this path-traversal thing addressed and then clean up the work-arounds in my ports. A related issue: the binary PKG files that are produced by MacPorts are very dangerous for a similar reason: they don't resolve intermediate symlinks, either. Instead, the installer with *wipe out* the intermediate symlink, replacing it with a "real directory" -- which of course only contains the stuff in that particular package. For example, /etc -- which is a symlink to /private/etc -- is *deleted* and *replaced* by an /etc that only contains an X11 subdir by the emacs binary pkg installer. Ouch! 2) I will try to clean up pkg-creation, unless someone else wants to hit it. Who maintains the PKG binary-installer part of MacPorts? Thanks! - boyd Boyd Waters National Radio Astronomy Observatory middle of nowhere New Mexico USA From afb at macports.org Wed Jul 4 01:19:32 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Oct 9 16:40:25 2007 Subject: Platform versions and Binaries In-Reply-To: <475c409bd49ef88377ab5d7a4a8a1d25@macports.org> References: <475c409bd49ef88377ab5d7a4a8a1d25@macports.org> Message-ID: > So we might need to include at least the major version in > the paths used, so that they will become something like: > > darwin/9/i386/ > darwin/9/ppc/ > darwin/8/i386/ > darwin/8/ppc/ > darwin/7/ppc/ > freebsd/7/i386/ > freebsd/6/i386/ > freebsd/5/i386/ > ... There is now an ${os.major} variable that can be used for this purpose, as in: ${os.platform}/${os.major}/${os.arch} http://trac.macports.org/projects/macports/changeset/26693 --anders From afb at macports.org Wed Jul 4 03:00:31 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Oct 9 16:40:25 2007 Subject: Release 1.5 branch created In-Reply-To: References: Message-ID: Juan Manuel Palacios wrote: > I finally created the release_1_5 branch wherefrom we'll start > cutting the 1.5.x releases, really soon now I hope! For those willing > to help around in sanitizing, please reinstall off this branch and > test as thoroughly as posible, reporting any findings you may come by. > I'll rework the roadmap to move open tickets in the 1.4 milestone to > 1.5, as well as those that were fixed in it but not released to users > (committed to trunk, which as of r26608 is the same as release1_5) but > not to the release_1_4 branch. Any new ticket on the base component > should be submitted to the 1.5 milestone, consider 1.4 closed! These are the issues affecting "selfupdate" on FreeBSD: http://trac.macports.org/projects/macports/ticket/12168 http://trac.macports.org/projects/macports/ticket/12173 http://trac.macports.org/projects/macports/ticket/12212 http://trac.macports.org/projects/macports/ticket/12225 http://trac.macports.org/projects/macports/ticket/12230 http://trac.macports.org/projects/macports/ticket/12231 It would be nice if these could go into MacPorts 1.5... With OpenDarwin now gone, it's good to have a free option available for testing MacPorts on (FreeBSD with GNUstep) It will come as a FreeBSD Port (pkg_add -r macports), so that it's easy to install just like the Mac OS X Package. Supporting FreeBSD is much easier than supporting e.g. Solaris or GNU/Linux, due to the Mac OS X similarities. Especially since the support was already in DarwinPorts, it just needed a little updating to work out of the box... --anders From simon at ruderich.com Wed Jul 4 11:23:40 2007 From: simon at ruderich.com (Simon Ruderich) Date: Tue Oct 9 16:40:25 2007 Subject: Problem with configure.env and build.env Message-ID: <468BE5AC.3090002@ruderich.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I'm trying to build qt3-mac but it failed with the same error like reported on [trac][]. After doing some debugging I found the problem. The environment specified in build.env is not set and so the libraries are not found because DYLD_LIBRARY_PATH is not set correctly. I don't know why the environment is not setup correctly, but it looks like it's not working for configure.env either. The output with port -d shows the build environment is empty and the configuration environment is only filled with default values and not those from the Portfile. - ---> Configuring qt3-mac DEBUG: Executing com.apple.configure (qt3-mac) DEBUG: Environment: CXXFLAGS='-O2' CPPFLAGS='-I/opt/local/include' CFLAGS='-O2' LDFLAGS='-L/opt/local/lib' DEBUG: Assembled command: ... ... - ---> Building qt3-mac with target symlinks src-qmake src-moc sub-src sub-tools DEBUG: Executing com.apple.build (qt3-mac) DEBUG: Environment: DEBUG: Assembled command: ... I fixed this problem temporarily by added the following line to the build rules in the Portfile. build.cmd "export DYLD_LIBRARY_PATH='${worksrcpath}/lib'; make" But this is of course no real solution, but so I could build qt3-mac. If you please could look into this. I'm using port version 1.442 (fresh 4.000 install and updated using port selfsync). Thanks for your help, Simon [trac]: http://trac.macports.org/projects/macports/ticket/11895 - -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGi+WsYRX4BO+zMikRCn0ZAKDXl7W+XJVBW/ZQ3Q616XdGhuqTAACgof51 dU4JK3EfV/TMeJa2TD6ntxQ= =LnEK -----END PGP SIGNATURE----- From markd at macports.org Wed Jul 4 12:19:33 2007 From: markd at macports.org (markd@macports.org) Date: Tue Oct 9 16:40:25 2007 Subject: Problem with configure.env and build.env In-Reply-To: <468BE5AC.3090002@ruderich.com> References: <468BE5AC.3090002@ruderich.com> Message-ID: Hi Simon, I pasted your workaround to the trac ticket. This type of feedback is very helpful and helps get bugs fixed sooner, so consider getting a trac account (if you don't already have one) and modifying tickets with this type of thing. Thanks for reporting it! Mark Simon Ruderich on Wednesday, July 4, 2007 at 11:23 AM -0800 wrote: >I'm trying to build qt3-mac but it failed with the same error like >reported on [trac][]. > >After doing some debugging I found the problem. The environment >specified in build.env is not set and so the libraries are not found >because DYLD_LIBRARY_PATH is not set correctly. > >I don't know why the environment is not setup correctly, but it looks >like it's not working for configure.env either. The output with port -d >shows the build environment is empty and the configuration environment >is only filled with default values and not those from the Portfile. > >- ---> Configuring qt3-mac >DEBUG: Executing com.apple.configure (qt3-mac) >DEBUG: Environment: CXXFLAGS='-O2' CPPFLAGS='-I/opt/local/include' >CFLAGS='-O2' LDFLAGS='-L/opt/local/lib' >DEBUG: Assembled command: ... >... >- ---> Building qt3-mac with target symlinks src-qmake src-moc sub-src >sub-tools >DEBUG: Executing com.apple.build (qt3-mac) >DEBUG: Environment: >DEBUG: Assembled command: ... > >I fixed this problem temporarily by added the following line to the >build rules in the Portfile. > >build.cmd "export DYLD_LIBRARY_PATH='${worksrcpath}/lib'; make" > >But this is of course no real solution, but so I could build qt3-mac. > >If you please could look into this. I'm using port version 1.442 (fresh >4.000 install and updated using port selfsync). > >Thanks for your help, >Simon > >[trac]: http://trac.macports.org/projects/macports/ticket/11895 From landonf at macports.org Wed Jul 4 13:59:43 2007 From: landonf at macports.org (Landon Fuller) Date: Tue Oct 9 16:40:25 2007 Subject: Release 1.5 branch created In-Reply-To: References: Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070704/624fa2f6/PGP.bin From afb at macports.org Wed Jul 4 14:23:18 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Oct 9 16:40:25 2007 Subject: Release 1.5 branch created In-Reply-To: References: Message-ID: Landon Fuller wrote: >> http://trac.macports.org/projects/macports/ticket/12173 > Outside of my immediate jurisdiction. It's just a failed test case or two anyway, not library code. >> http://trac.macports.org/projects/macports/ticket/12212 > I -think- the right solution for this is to use > -fconstant-string-class=NSConstantString for GNUstep. As a start, > check out the OD_OBJC_NSCONSTANTSTRING macro I wrote here: > > http://svn.sourceforge.net/viewvc/substrate/trunk/aclocal.m4? > revision=283&view=markup Actually I just wanted MacPorts 1.5 to limp along and compile, as far as I know nothing is actually *using* tclobjc just yet and there was no test case for it to check whether it worked... > http://trac.macports.org/projects/macports/ticket/12230 > > I added a new pthread macro, committed to trunk. Was using "PTHREAD_LIBS=-lpthread ./configure" first, but that kinda broke any attempts to have it just selfupdate. Your macro is much better than either patch or workaround. >> http://trac.macports.org/projects/macports/ticket/12231 > > Personally I'm in favor of just using?--with-tcl-sqlite3, but I could > be swayed either way. That would probably be much better, the idea was to provide enough of defaults so that "selfupdate" didn't choke and die... The initial BSD installation did provide an actual location. Another reason was that not providing a location for sqlite3 means it will try and compile the included sqlite3 library, which seems even more hardcoded for Darwin than the path was. > I'll look into merging these changes into the 1.5 release branch, > assuming nobody objects. I'm sure there will be lots of objections, as all patches were for making MacPorts "work" on FreeBSD which might be against the will of both several people and the project as a whole... My point was just that "we're not supporting FreeBSD anymore" doesn't *have* to mean "actively deleting everything freebsd" ? It was under my impression that it would still be tolerated. But if we want to go ahead and wipe puredarwin/freebsd, OK. My main objective is testing RPM packaging anyway, and I have another option if MacPorts doesn't support FreeBSD anymore... --anders From jmpp at macports.org Wed Jul 4 14:43:17 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:25 2007 Subject: Platform versions and Binaries In-Reply-To: <475c409bd49ef88377ab5d7a4a8a1d25@macports.org> References: <475c409bd49ef88377ab5d7a4a8a1d25@macports.org> Message-ID: Rereading this initial post after Kevin committed r26693, with which we're now recording ${os.major}. On Jul 1, 2007, at 8:10 AM, Anders F Bj?rklund wrote: > There is a upcoming problem that will occur with the binary > archives/packages, in that most of the code currently only > checks for ${os.platform} and ${os.arch} when looking for > binaries, ignoring ${os.version} which might be important ? When you say this, what exactly are you referring to? Who is checking those variables and ignoring ${os.version}, base/src/port1.0/ portmain.tcl? Upon what operation? Or are you instead referring to "archivemode"? And with r26693 and ${os.major} in sight, don't we have more flexibility now to check for the major platform number we're interested in? From what I understand, r26693 just records $ {os.major} (e.g. Darwin *8*)... but we're not yet using it anywhere? > > > e.g. Panther and Tiger will try to use the same binaries > and archives, and ditto for FreeBSD STABLE and CURRENT... > > > So we might need to include at least the major version in > the paths used, so that they will become something like: > > darwin/9/i386/ > darwin/9/ppc/ > darwin/8/i386/ > darwin/8/ppc/ > darwin/7/ppc/ > freebsd/7/i386/ > freebsd/6/i386/ > freebsd/5/i386/ > ... > > This goes for /opt/local/var/macports/packages, and for > remote fetching. It also goes for all RPM repositories. I guess having the "rpm" target share some code with "archivemode", if possible, would be good, to factor out things like platform/major/ architecture/others detection and not duplicate it in every single packaging target we support. I figure a package1.0/package_util.tcl TCL package would be in order.... And I agree that we should further make the distinction of platform version when creating and storing these packages (archivemode, generated rpms, debs, etc...), I guess that we just need to hook up $ {os.major} properly. Platform architecture is already checked for but "noarch" should be included too. Not fully acquainted with how the "archive" target detects the necessary info, I'm thinking we could leverage the "platforms" declaration present at the top of every Portfile to make our decisions, through its extension with some keywords. True that "platforms" is there to announce on what platform(s) a given Portfile is meant to work on, and that the paths above are created at runtime to record what specific platform the package is built for... but my point is that precisely those two things should coincide at least up to a point. What I propose is we extend "platforms" as follows: 1) The current case: -) "platforms darwin" -) "platforms darwin freebsd" Means the port is declared to work both on darwin and freebsd, no architecture restriction 2) Proposed extensions: -) "platforms darwin ppc" -) "platforms darwin i386" -) "platforms darwin noarch" These architecture declarations would restrict what platform the port is allowed to work on when present. So, for instance, a port declared "darwin i386" would return with the nice error code suggested by Landon in one of his recent posts (c.f. http:// lists.macosforge.org/pipermail/macports-dev/2007-June/002015.html, return -code error "An error, here") when tried on ppc. A port declared "noarch" would have no restrictions but the keyword would be carried along with it when creating an archive/package. No architecture keyword (different from supplying 'noarch') would simply mean no restrictions and default to the host hardware (same for no os.major keyword). Some form of grouping would have to be thought of to be able to say, for example, 'darwin 9' *and* 'freebsd pcc' in a single platforms declaration in an unequivocal manner (that is, not mix keywords). Finally, the code currently making platform decisions in port1.0 and "archivemode" would have to be adapted to read this "platforms array" first and then fallback on defaults if no info is found. This approach, if technically sound and viable, would allow us to solve the "noarch" problem and to get rid of the dreadful "exit" calls maintainers put in some Porfiles to restrict what platforms the corresponding port is allowed to work on, all in one fell swoop! A Portfile declaring something like "platforms darwin 8" would see the port1.0 layer returning with an error code that would in essence implement Jordan's "ui_fatal" suggestion when attempted on Panther. > > > > Universal packages should probably go in a special place > too, since they use the 10.4.u SDK and the "fat" arch ? > Eventually one _might_ want to share "noarch"* packages > between architectures, and maybe even between platforms. If what I propose above is viable, I guess 'universal' could be another valid keyword... > > --anders > > * http://trac.macports.org/projects/macports/ticket/12206 Regards,.... -jmpp From jmpp at macports.org Wed Jul 4 15:24:35 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:25 2007 Subject: Release 1.5 branch created In-Reply-To: <4AFF556B-9216-4FCE-9A9F-17DDA5CAB54B@orcaware.com> References: <468682BB.7030404@orcaware.com> <1DB87759-7559-4D51-8412-7CEBBB9F2533@macports.org> <4AFF556B-9216-4FCE-9A9F-17DDA5CAB54B@orcaware.com> Message-ID: <9BA95B9A-5612-43EF-9A6B-7DB2B5C77607@macports.org> On Jun 30, 2007, at 8:32 PM, Blair Zajac wrote: > > The page isn't very long and it's really the only page that exists > for it. There's one step on the branch > > $ svnmerge.py init > $ svn commit -F svnmerge-commit-message.txt > > And then if there's a commit on trunk > > $ svnmerge.py merge > $ svn commit -F svnmerge-commit-message.txt > > Much easier then keeping track of revision numbers :) > > I would just suggest setting it up before doing any merges. > > Regards, > Blair Thanks for the pointers Blair! It took me a little while to realize I actually needed to commit the init action before starting my merge activity, but after that it was all smooth from there! My commit logs should illustrate what I merged and what I left out of the branch.... so anyone interested in having or pulling something, please do inspect the commit logs and feel free to scream at me ;-) (I realize I left out the FreeBSD support commits, but I'm figuring Anders will want that in? are they stable enough to be merged at this point in the game?). One thing that I did find as a shortcoming of svnmerge.py is that you need to ci whenever you execute a given action. That is, you can't do something like: -) svnmerge.py merge -r -) (look around) -) svnmerge.py block -r -) (look around some more) -) svnmerge.py merge -r -) svn ci -F message Instead, you have to ci after each of those merges/blocks, a bit of a shortcoming in my opinion (could simply be that what I attempted is not viable to begin with, given how svn properties work). But other than that, sweet tool! Thanks again for the recommendation. Regards,... -jmpp From afb at macports.org Wed Jul 4 15:41:49 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Oct 9 16:40:25 2007 Subject: Platform versions and Binaries In-Reply-To: References: <475c409bd49ef88377ab5d7a4a8a1d25@macports.org> Message-ID: Juan Manuel Palacios wrote: >> There is a upcoming problem that will occur with the binary >> archives/packages, in that most of the code currently only >> checks for ${os.platform} and ${os.arch} when looking for >> binaries, ignoring ${os.version} which might be important ? > > When you say this, what exactly are you referring to? Who is checking > those variables and ignoring ${os.version}, > base/src/port1.0/portmain.tcl? Upon what operation? Or are you instead > referring to "archivemode"? Well, we have archivemode but that's only local so not very important No - the main users of the code was for remote fetching, either inside of MacPorts with the proposed patches or outside of MacPorts using some kind of Package Manager like for instance Yum/APT-RPM/Smart... > And with r26693 and ${os.major} in sight, don't we have more > flexibility now to check for the major platform number we're > interested in? From what I understand, r26693 just records ${os.major} > (e.g. Darwin *8*)... but we're not yet using it anywhere? Nope, not aside from RPM building. And actually installing those built RPMs does require a system package that is yet to be decided anyway... (i.e. the RPM providing all the org.macports.* virtual dependencies) > And I agree that we should further make the distinction of platform > version when creating and storing these packages (archivemode, > generated rpms, debs, etc...), I guess that we just need to hook up > ${os.major} properly. Platform architecture is already checked for but > "noarch" should be included too. The alternative to noarch is of course storing the same package in both i386 and ppc, the same goes for the alternative to fat architecture... (store the same +universal one in both i386 and ppc depending on builder) So neither of them is terribly important, just a little "optimization". > Not fully acquainted with how the "archive" target detects the > necessary info, I'm thinking we could leverage the "platforms" > declaration present at the top of every Portfile to make our > decisions, through its extension with some keywords. True that > "platforms" is there to announce on what platform(s) a given Portfile > is meant to work on, and that the paths above are created at runtime > to record what specific platform the package is built for... but my > point is that precisely those two things should coincide at least up > to a point. Not sure if platforms is anything more than an informational effort, like you say the important things are decided elsewhere anyhow... (the code - being manipulated in variants, and the packaging targets) > What I propose is we extend "platforms" as follows: > > 1) The current case: > -) "platforms darwin" > -) "platforms darwin freebsd" > Means the port is declared to work both on darwin and freebsd, no > architecture restriction > 2) Proposed extensions: > -) "platforms darwin ppc" > -) "platforms darwin i386" > -) "platforms darwin noarch" > These architecture declarations would restrict what platform the > port is allowed to work on when present. So, for instance, a port > declared "darwin i386" would return with the nice error code suggested > by Landon in one of his recent posts (c.f. > http://lists.macosforge.org/pipermail/macports-dev/2007-June/ > 002015.html, return -code error "An error, here") when tried on ppc. A > port declared "noarch" would have no restrictions but the keyword > would be carried along with it when creating an archive/package. No > architecture keyword (different from supplying 'noarch') would simply > mean no restrictions and default to the host hardware (same for no > os.major keyword). > > Some form of grouping would have to be thought of to be able to say, > for example, 'darwin 9' *and* 'freebsd pcc' in a single platforms > declaration in an unequivocal manner (that is, not mix keywords). > Finally, the code currently making platform decisions in port1.0 and > "archivemode" would have to be adapted to read this "platforms array" > first and then fallback on defaults if no info is found. > > This approach, if technically sound and viable, would allow us to > solve the "noarch" problem and to get rid of the dreadful "exit" calls > maintainers put in some Porfiles to restrict what platforms the > corresponding port is allowed to work on, all in one fell swoop! A > Portfile declaring something like "platforms darwin 8" would see the > port1.0 layer returning with an error code that would in essence > implement Jordan's "ui_fatal" suggestion when attempted on Panther. Not sure about the syntax, if you can make the above parse it might be an idea (after all the platform variants work) But I was more concerned about platform versions than arch. Where I'm from OS and ARCH are different, but I'm flexible. I was interested in how to split various releases, similar to the "dist" problem we're seeing with Linux RPM packages. i.e. how to separate darwin6/darwin7/darwin8/darwin9 binaries --anders From markd at macports.org Wed Jul 4 15:53:50 2007 From: markd at macports.org (markd@macports.org) Date: Tue Oct 9 16:40:25 2007 Subject: [26694] trunk/base/ChangeLog In-Reply-To: <20070704061754.094336A06C2@cvs.opensource.apple.com> References: <20070704061754.094336A06C2@cvs.opensource.apple.com> Message-ID: macports-dev@lists.macosforge.org on Tuesday, July 3, 2007 at 11:17 PM -0800 wrote: >+ - Added new variable ${os.major} that contains the Tcl major version >(eridius r26693, ticket #12224). Kevin, Can you please explain the naming of this variable? If it represents the major Tcl version, shouldn't it be named accordingly? Doesn't os.major imply that it represents the major version of the OS? Mark From afb at algonet.se Wed Jul 4 16:07:38 2007 From: afb at algonet.se (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Oct 9 16:40:25 2007 Subject: Release 1.5 branch created In-Reply-To: <9BA95B9A-5612-43EF-9A6B-7DB2B5C77607@macports.org> References: <468682BB.7030404@orcaware.com> <1DB87759-7559-4D51-8412-7CEBBB9F2533@macports.org> <4AFF556B-9216-4FCE-9A9F-17DDA5CAB54B@orcaware.com> <9BA95B9A-5612-43EF-9A6B-7DB2B5C77607@macports.org> Message-ID: Juan Manuel Palacios wrote: > Thanks for the pointers Blair! It took me a little while to realize I > actually needed to commit the init action before starting my merge > activity, but after that it was all smooth from there! My commit logs > should illustrate what I merged and what I left out of the branch.... > so anyone interested in having or pulling something, please do inspect > the commit logs and feel free to scream at me ;-) (I realize I left > out the FreeBSD support commits, but I'm figuring Anders will want > that in? are they stable enough to be merged at this point in the > game?). Depends on if you want FreeBSD to still work or not ? Just seems strange to leave it in the "undead" state, either it's revived again or it's properly buried :-) If it's just crazy old me, I can patch in here locally. I'm not a die-hard FreeBSD fan, I just find the whole Mac lock-in part a bit scary and want to stay portable... With OpenDarwin gone, it looked like the easiest target. If you do want the FreeBSD platform, I have some patches to the dozen or so ports needed to install the RPM port. --anders PS. You do want to bring this one over, though: (it's a bug) http://trac.macports.org/projects/macports/ticket/12168 Without it, *everything* will link to Foundation framework. From eridius at macports.org Wed Jul 4 17:11:51 2007 From: eridius at macports.org (Kevin Ballard) Date: Tue Oct 9 16:40:25 2007 Subject: [26694] trunk/base/ChangeLog In-Reply-To: References: <20070704061754.094336A06C2@cvs.opensource.apple.com> Message-ID: Erm... I wrote the commit message wrong. Blame that on the beer ;) That's the major version number of the Darwin system, so for me on 10.4.10 it's 8. -Kevin Ballard Feel free to go change it if you want. On Jul 4, 2007, at 3:53 PM, markd@macports.org wrote: > macports-dev@lists.macosforge.org on Tuesday, July 3, 2007 at 11:17 PM > -0800 wrote: >> + - Added new variable ${os.major} that contains the Tcl major >> version >> (eridius r26693, ticket #12224). > > Kevin, > > Can you please explain the naming of this variable? If it > represents the > major Tcl version, shouldn't it be named accordingly? Doesn't > os.major > imply that it represents the major version of the OS? -- Kevin Ballard http://kevin.sb.org kevin@sb.org http://www.tildesoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20070704/78879b2f/attachment.html From jmpp at macports.org Thu Jul 5 00:12:52 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:25 2007 Subject: Release 1.5 branch created In-Reply-To: References: <468682BB.7030404@orcaware.com> <1DB87759-7559-4D51-8412-7CEBBB9F2533@macports.org> <4AFF556B-9216-4FCE-9A9F-17DDA5CAB54B@orcaware.com> <9BA95B9A-5612-43EF-9A6B-7DB2B5C77607@macports.org> Message-ID: <1C40450C-5F82-4E06-BF86-2AD9091428BC@macports.org> On Jul 4, 2007, at 7:07 PM, Anders F Bj?rklund wrote: > Juan Manuel Palacios wrote: > >> Thanks for the pointers Blair! It took me a little while to >> realize I actually needed to commit the init action before >> starting my merge activity, but after that it was all smooth from >> there! My commit logs should illustrate what I merged and what I >> left out of the branch.... so anyone interested in having or >> pulling something, please do inspect the commit logs and feel free >> to scream at me ;-) (I realize I left out the FreeBSD support >> commits, but I'm figuring Anders will want that in? are they >> stable enough to be merged at this point in the game?). > > Depends on if you want FreeBSD to still work or not ? > Just seems strange to leave it in the "undead" state, > either it's revived again or it's properly buried :-) The only reason why FreeBSD support was "left behind", as opposed to flat out pulled, is that at the time no one seemed to be using (Darwin)MacPorts on any platform other than Mac OS X (not even on [pure | open]Darwin), which seems logical to me as most other platforms already have their own packaging tools/ports trees best suited for them. So the question was: why should we be putting of energy into supporting scenarios (MacPorts on another platforms) that not only will have a very limited audience, but also that people are likely to choose against? (seems logical to me that they'd choose their own platform's packaging system/ports tree). So the support was "left behind" due to a sort of generalized lack of interest. But it was not "voted against", we never deemed it as something we would be fundamentally opposed to, as long as there's someone interested enough in the support to provide it him/her- self... like you have in this case ;-) What we did agree on was, seeing MacPorts on other platforms was almost not a real life thing, that on refocusing solely on Mac OS X we would not stop ourselves from using whatever Mac OS X specific technologies we could get our hands on to improve MacPorts just for the sake of keeping it portable... just to safeguard a portability that practically no one was leveraging in real life (again, with good reason in my opinion) and possibly miss out on pretty cool things Mac OS X has to offer. The inclusion of the tcl-objc bridge is an example of this.... but, again, there's no fundamental opposition to portability, I believe. So if someone interested enough, like you ;-), comes along to hook up the bridge with GNUStep to make i work on other than Mac OS X, then big woot for that! As team manager, I have no opposition to merging this set of changes into the release_1_5 branch and shipping MacPorts 1.5 with FreeBSD support again, as long as the code is stable and doesn't cause any failures/regressions on Mac OS X, our by far main focus (cf. my previous question on stability). > > If it's just crazy old me, I can patch in here locally. > I'm not a die-hard FreeBSD fan, I just find the whole > Mac lock-in part a bit scary and want to stay portable... I understand portability and love it and embrace it (this is ports tree of open source software after all, and I dedicate quite a bit of time to it ;-), so I understand your concern. But in this particular case I do have to ask: what does portability buy not only the MacPorts project... but MacPorts users themselves? Are they really gonna fire up a FreeBSD box, remove its native (and much larger) ports tree and use MacPorts? I guess I just don't understand the motivation for that (maybe I haven't used FreeBSD's ports tree enough, if you know what I mean ;-). But if there is an audience out there wanting to do exactly that, then by all means! Still, however, Mac OS X is by far our main focus and I want to safeguard that. So I guess I could simply sum-up my position as follows: "whatever you want, as long as it doesn't hurt our Mac OS X focus in any way.... and also as long as it's not crack smoking!" ;-) And that goes for other platforms too, not just FreeBSD (someone using MacPorts on Linux? ;-) So, now to everybody.... any objections to merging FreeBSD support into release_1_5? James and Markus? You cool? going once.... going twice.... ;-) > > With OpenDarwin gone, it looked like the easiest target. > If you do want the FreeBSD platform, I have some patches > to the dozen or so ports needed to install the RPM port. Please, be my guest, by all means do commit! > > --anders > > PS. You do want to bring this one over, though: (it's a bug) > http://trac.macports.org/projects/macports/ticket/12168 > Without it, *everything* will link to Foundation framework. Landon made three commits that I've been reviewing this evening, the one addressing this bug was the first. If FreeBSD support does go into 1.5 this one will certainly be included. Thanks for your dedication to extending MacPorts feature set (and sorry for removing the autoconf tclsh tests & checks in my branch ;-) Regards,... -jmpp From jmpp at macports.org Thu Jul 5 00:17:27 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:25 2007 Subject: Release 1.5 branch created In-Reply-To: References: Message-ID: On Jul 4, 2007, at 5:23 PM, Anders F Bj?rklund wrote: > Landon Fuller wrote: > >>> http://trac.macports.org/projects/macports/ticket/12173 >> Outside of my immediate jurisdiction. > > It's just a failed test case or two anyway, not library code. Cc'd Kevin on the ticket so that he can take a look at this, while setting the ticket to "needs dev review" for easy tracking. > >>> http://trac.macports.org/projects/macports/ticket/12212 >> I -think- the right solution for this is to use -fconstant-string- >> class=NSConstantString for GNUstep. As a start, check out the >> OD_OBJC_NSCONSTANTSTRING macro I wrote here: >> http://svn.sourceforge.net/viewvc/substrate/trunk/ >> aclocal.m4?revision=283&view=markup > > Actually I just wanted MacPorts 1.5 to limp along and compile, > as far as I know nothing is actually *using* tclobjc just yet > and there was no test case for it to check whether it worked... Put this ticket also in "needs dev review". > >> http://trac.macports.org/projects/macports/ticket/12230 >> >> I added a new pthread macro, committed to trunk. > > Was using "PTHREAD_LIBS=-lpthread ./configure" first, but > that kinda broke any attempts to have it just selfupdate. > Your macro is much better than either patch or workaround. > >>> http://trac.macports.org/projects/macports/ticket/12231 >> >> Personally I'm in favor of just using --with-tcl-sqlite3, but I >> could be swayed either way. > > That would probably be much better, the idea was to provide > enough of defaults so that "selfupdate" didn't choke and die... > The initial BSD installation did provide an actual location. > > Another reason was that not providing a location for sqlite3 > means it will try and compile the included sqlite3 library, > which seems even more hardcoded for Darwin than the path was. So fire up the autoconf foo and write up & commit the glue ;-) > >> I'll look into merging these changes into the 1.5 release branch, >> assuming nobody objects. > > I'm sure there will be lots of objections, as all patches were > for making MacPorts "work" on FreeBSD which might be against > the will of both several people and the project as a whole... > > My point was just that "we're not supporting FreeBSD anymore" > doesn't *have* to mean "actively deleting everything freebsd" ? > It was under my impression that it would still be tolerated. Totally tolerated in my opinion, as long as it doesn't hurt Mac OS X development and possibly leveraging platform specific technologies that simply wont work elsewhere... but I already made this point detailed enough in my previous post. > > But if we want to go ahead and wipe puredarwin/freebsd, OK. > My main objective is testing RPM packaging anyway, and I have > another option if MacPorts doesn't support FreeBSD anymore... > > --anders "Show me the packages!" ;-) Regards,.... -jmpp From jmpp at macports.org Thu Jul 5 00:24:00 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:25 2007 Subject: Release 1.5 branch created In-Reply-To: References: Message-ID: On Jul 4, 2007, at 4:59 PM, Landon Fuller wrote: > . > I'll look into merging these changes into the 1.5 release branch, > assuming nobody objects. I'm sure you'd love me green lighting this, Landon ;-) Well, I already kinda did in one of my previous posts, please do feel free to reply to it with your opinions on my position, would love to hear them! > Also, do you have a commit bit for base? (Do we still separate > base/ and dports/ ?). If not, you probably should =) Anders does have commit and the project is no longer divided in ports, base & docs subprojects with different ACLs, just one big pool with a single access list. So he should be able to commit at will (and has, actually). We as team managers just ask that those who are not that experienced/acquainted with base ask for peer review before diving into it; I've gone with Anders over practically every single one of his commits. > > -landonf Regards,.... -jmpp From jmpp at macports.org Thu Jul 5 00:34:45 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:25 2007 Subject: Release 1.5 branch created In-Reply-To: References: Message-ID: On Jul 4, 2007, at 4:59 PM, Landon Fuller wrote: > > I'll look into merging these changes into the 1.5 release branch, > assuming nobody objects. > Also, do you have a commit bit for base? (Do we still separate > base/ and dports/ ?). If not, you probably should =) > > -landonf One thing I forgot to say, I started using svnmerge.py to manage the release branch per Blair's advice and it is indeed proving to be quite a nifty tool. The help/tutorial claims it handles manual merges just fine and still offers quite a bit of magic if they happen... but maybe not as much as if they hadn't (still haven't used it enough to know what we'd be loosing if we mix). So in any case, could you please consider using it if you're gonna handle merging? Otherwise I can do it if you prefer. Regards,... -jmpp From afb at macports.org Thu Jul 5 00:46:32 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Oct 9 16:40:25 2007 Subject: Release 1.5 branch created In-Reply-To: <1C40450C-5F82-4E06-BF86-2AD9091428BC@macports.org> References: <468682BB.7030404@orcaware.com> <1DB87759-7559-4D51-8412-7CEBBB9F2533@macports.org> <4AFF556B-9216-4FCE-9A9F-17DDA5CAB54B@orcaware.com> <9BA95B9A-5612-43EF-9A6B-7DB2B5C77607@macports.org> <1C40450C-5F82-4E06-BF86-2AD9091428BC@macports.org> Message-ID: Juan Manuel Palacios wrote: >> Depends on if you want FreeBSD to still work or not ? >> Just seems strange to leave it in the "undead" state, >> either it's revived again or it's properly buried :-) > > The only reason why FreeBSD support was "left behind", as opposed to > flat out pulled, is that at the time no one seemed to be using > (Darwin)MacPorts on any platform other than Mac OS X (not even on > [pure | open]Darwin), which seems logical to me as most other > platforms already have their own packaging tools/ports trees best > suited for them. So the question was: why should we be putting amount> of energy into supporting scenarios (MacPorts on another > platforms) that not only will have a very limited audience, but also > that people are likely to choose against? (seems logical to me that > they'd choose their own platform's packaging system/ports tree). Sure, and either way makes sense - keeping it portable or focussing just on a single os platform for simplicity... Just that the code had all the "platforms" stuff left in ? So my impression that it was still portable, just out-of-synch. > So the support was "left behind" due to a sort of generalized lack of > interest. But it was not "voted against", we never deemed it as > something we would be fundamentally opposed to, as long as there's > someone interested enough in the support to provide it him/her-self... > like you have in this case ;-) What we did agree on was, seeing > MacPorts on other platforms was almost not a real life thing, that on > refocusing solely on Mac OS X we would not stop ourselves from using > whatever Mac OS X specific technologies we could get our hands on to > improve MacPorts just for the sake of keeping it portable... Portability is just one aspect, while user's freedom is another. Relying on proprietary Mac things like Xcode or Cocoa will kill any portability dead anyway, so then the whole issue is moot... This is also why I think a Darwin or FreeBSD "base" is important ? > just to safeguard a portability that practically no one was leveraging > in real life (again, with good reason in my opinion) and possibly miss > out on pretty cool things Mac OS X has to offer. The inclusion of the > tcl-objc bridge is an example of this.... but, again, there's no > fundamental opposition to portability, I believe. So if someone > interested enough, like you ;-), comes along to hook up the bridge > with GNUStep to make i work on other than Mac OS X, then big woot for > that! > > As team manager, I have no opposition to merging this set of changes > into the release_1_5 branch and shipping MacPorts 1.5 with FreeBSD > support again, as long as the code is stable and doesn't cause any > failures/regressions on Mac OS X, our by far main focus (cf. my > previous question on stability). There's sure to be some objections like "why can't this Darwin-only patch go on always" or "why can't I hardcode these path values that work just fine on my Tiger box"... One could argue that those are poor practices either way. >> If it's just crazy old me, I can patch in here locally. >> I'm not a die-hard FreeBSD fan, I just find the whole >> Mac lock-in part a bit scary and want to stay portable... > > I understand portability and love it and embrace it (this is ports > tree of open source software after all, and I dedicate quite a bit of > time to it ;-), so I understand your concern. But in this particular > case I do have to ask: what does portability buy not only the MacPorts > project... but MacPorts users themselves? Are they really gonna fire > up a FreeBSD box, remove its native (and much larger) ports tree and > use MacPorts? I guess I just don't understand the motivation for that > (maybe I haven't used FreeBSD's ports tree enough, if you know what I > mean ;-). You mean just like one deletes Installer.app on Mac OS X ? ;-) MacPorts is just an optional install, in its own little prefix - it doesn't mess about (much) with the /usr or /usr/local trees. > But if there is an audience out there wanting to do exactly that, then > by all means! Still, however, Mac OS X is by far our main focus and I > want to safeguard that. So I guess I could simply sum-up my position > as follows: "whatever you want, as long as it doesn't hurt our Mac OS > X focus in any way.... and also as long as it's not crack smoking!" > ;-) And that goes for other platforms too, not just FreeBSD (someone > using MacPorts on Linux? ;-) Other platforms such as GNU/Linux or Sun Solaris requires more code, and there is this little "BSD versus GNU" ongoing preferences battle. FreeBSD is on the same side as Darwin (Mac OS X) there, so to speak. >> PS. You do want to bring this one over, though: (it's a bug) >> http://trac.macports.org/projects/macports/ticket/12168 >> Without it, *everything* will link to Foundation framework. > > Landon made three commits that I've been reviewing this evening, the > one addressing this bug was the first. If FreeBSD support does go into > 1.5 this one will certainly be included. My point here was this this particular bug doesn't have anything to do with FreeBSD or GNUstep, it goes for Mac OS X and Cocoa too. (library frameworks like universal binaries are a Mac OS X thing) --anders From jwa at macports.org Thu Jul 5 05:19:18 2007 From: jwa at macports.org (Jyrki Wahlstedt) Date: Tue Oct 9 16:40:25 2007 Subject: Q: variants specified in dependencies Message-ID: I remember there has been discussion about this, i.e. variants specified in dependencies. I wonder what the current status is, as I noticed the ticket about this (#126, the oldest one open, I believe) was milestoned to 1.5. At least in one earlier discussion there were objections to do this due to the difficulty in implementing, but I would like to see this, e.g. because mpkg is based on very short trial useless without this capability (and mpkg is something that I could use). If this means that I should dive into the deep core of MacPorts, I would be willing to give it a try. ! ! Jyrki Wahlstedt ! http://www.wahlstedt.fi/jyrki/ ! ! Our life is no dream; but it ought to become one and perhaps will. ! PGP key ID: 0x139CC386 fingerprint: F355 B46F 026C B8C1 89C0 A780 6366 EFD9 139C C386 From jberry at macports.org Thu Jul 5 08:38:59 2007 From: jberry at macports.org (James Berry) Date: Tue Oct 9 16:40:25 2007 Subject: Release 1.5 branch created In-Reply-To: <1C40450C-5F82-4E06-BF86-2AD9091428BC@macports.org> References: <468682BB.7030404@orcaware.com> <1DB87759-7559-4D51-8412-7CEBBB9F2533@macports.org> <4AFF556B-9216-4FCE-9A9F-17DDA5CAB54B@orcaware.com> <9BA95B9A-5612-43EF-9A6B-7DB2B5C77607@macports.org> <1C40450C-5F82-4E06-BF86-2AD9091428BC@macports.org> Message-ID: <7D7A8BFF-B80D-478C-BB3A-89EC466FCA1E@macports.org> On Jul 5, 2007, at 12:12 AM, Juan Manuel Palacios wrote: >> If it's just crazy old me, I can patch in here locally. >> I'm not a die-hard FreeBSD fan, I just find the whole >> Mac lock-in part a bit scary and want to stay portable... > > > I understand portability and love it and embrace it (this is ports > tree of open source software after all, and I dedicate quite a bit > of time to it ;-), so I understand your concern. But in this > particular case I do have to ask: what does portability buy not > only the MacPorts project... but MacPorts users themselves? Are > they really gonna fire up a FreeBSD box, remove its native (and > much larger) ports tree and use MacPorts? I guess I just don't > understand the motivation for that (maybe I haven't used FreeBSD's > ports tree enough, if you know what I mean ;-). But if there is an > audience out there wanting to do exactly that, then by all means! > Still, however, Mac OS X is by far our main focus and I want to > safeguard that. So I guess I could simply sum-up my position as > follows: "whatever you want, as long as it doesn't hurt our Mac OS > X focus in any way.... and also as long as it's not crack > smoking!" ;-) And that goes for other platforms too, not just > FreeBSD (someone using MacPorts on Linux? ;-) > > So, now to everybody.... any objections to merging FreeBSD support > into release_1_5? James and Markus? You cool? going once.... going > twice.... ;-) I don't have any problems with some relatively minor patches required to support use of MacPorts in other environments, such as FreeBSD. A couple of points though: - I might change my mind of the extent of such patches began to impact the maintainability of the MacPorts base code. - There may be times when some of the things we do to MacPorts may not be easily supportable on other OS's. One example being that I'd like to make a bunch of new changes to Startupitem support sometime around the leopard release (when we can finally _assume_ launchd support) that may not be so easy to replicate on other OS's. Given MacPorts charter as a Mac system, I'm not going to let the compatibility with other OS's stand in the way of adding support for Mac-only features. James From landonf at macports.org Thu Jul 5 11:04:04 2007 From: landonf at macports.org (Landon Fuller) Date: Tue Oct 9 16:40:25 2007 Subject: Q: variants specified in dependencies In-Reply-To: References: Message-ID: <1FFB1536-1287-4D0E-9308-6BA5D932D459@macports.org> On Jul 5, 2007, at 05:19, Jyrki Wahlstedt wrote: > I remember there has been discussion about this, i.e. variants > specified in dependencies. I wonder what the current status is, as > I noticed the ticket about this (#126, the oldest one open, I > believe) was milestoned to 1.5. At least in one earlier discussion > there were objections to do this due to the difficulty in > implementing, but I would like to see this, e.g. because mpkg is > based on very short trial useless without this capability (and mpkg > is something that I could use). If this means that I should dive > into the deep core of MacPorts, I would be willing to give it a try. My own (potentially unpopular) opinion is that this is possible to implement and impossible to support, as it would introduce exponential complexity to the dependency tree. -landonf -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070705/e771f2a2/PGP.bin From barrywark at gmail.com Thu Jul 5 11:04:24 2007 From: barrywark at gmail.com (Barry Wark) Date: Tue Oct 9 16:40:25 2007 Subject: deploying pre-build ports with macports Message-ID: I'm planning a deployment of scientific software to several users in my lab. The software depends on several libraries that aren't installed by default on OS X. We've settled on macports for providing those dependencies (and have been very impressed with the whole project- kudos!). I would like to deploy our whole package, including macports, as a single installer. Here was my plan. I'd appreciate feedback from any of the devs about whether this will work: As part of the metapackage for deploying our entire software suite, I plan to include the stock macports installer (to add the appropriate receipt to /Library/Receipts), followed by an installer that overwrites the /opt/local tree with the /opt/local tree from our development machine that has all of the dependencies built and activated (all machines are the same OS version and architecture). Will this work or will I hose the macports installation on the target machines? Thanks, Barry From jmpp at macports.org Thu Jul 5 11:33:43 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:25 2007 Subject: [26727] trunk/dports/python In-Reply-To: <3ff6107cb9564eb56d46726620b63e0c@algonet.se> References: <20070705130057.9D6736A425F@cvs.opensource.apple.com> <3ff6107cb9564eb56d46726620b63e0c@algonet.se> Message-ID: <47C3C99D-7E6D-4505-BD8D-88D77571E2A1@macports.org> On Jul 5, 2007, at 2:30 PM, Anders F Bj?rklund wrote: > >>> +depends_lib-append port:py-celementtree >> >> Why use an append construct if we're not modifying any >> already defined depends array? We should always use 'depends_lib >> ' to first define the array and only then modify it with '- >> {append,delete}' if need be (variants, most likely), regardless of >> whether or not your construct above works to begin with (I think >> it does after Kevin fixed a related bug a while ago, but still....). > > I was under the impression that the PortGroup defined depends_lib, > but I will be happy to change the port above. > > --anders > Then please do completely ignore me and let me crawl back into my cave if that's the case (didn't even notice you were calling a PortGroup!). Let me run now ;-) -jmpp From bwaters at nrao.edu Thu Jul 5 11:57:25 2007 From: bwaters at nrao.edu (Boyd Waters) Date: Tue Oct 9 16:40:25 2007 Subject: deploying pre-build ports with macports In-Reply-To: References: Message-ID: <7BBA2A77-6727-4605-B422-0732E762B346@nrao.edu> On Jul 5, 2007, at 12:04 PM, Barry Wark wrote: > I'm planning a deployment of scientific software to several users in > my lab. The software depends on several libraries that aren't > installed by default on OS X. We've settled on macports for providing > those dependencies (and have been very impressed with the whole > project- kudos!). I would like to deploy our whole package I had the same sort of project for our astronomy software. My first thing was to create a meta-package that installed binary versions of all of our MacPorts dependencies. Then I ran another package that installed our (non-MacPorts) things. Note that the binary packages that MacPorts creates have little to do with MacPorts itself: in particular, they do not create MacPorts "receipts". If you expect to be able to install binary packages on top of a "standard" MacPorts distribution, and then subsequently build MacPorts that depend upon the binary-installed things, then you'll be in for a surprise: MacPorts will go ahead and install everything from source, ignoring the binary packages. That is, the binaries and the source ports are two different things and don't talk to one another. For us, this lead to lots of confusion for everyone: scientists, IT staff, developers. So now, I just build everything I need to - MacPorts for the community- developed things! - and then I create a tarball installer that includes all of our stuff (which isn't in MacPorts yet), and the handful of dynamic libs and binary commands that are required by our system (mostly Python). I don't know if my response helps you, but if you have other questions, I'd be happy to discuss them with you -- I'd like to know how other scientific applications are being deployed when using MacPorts. Regards, - boyd Boyd Waters National Radio Astronomy Observatory Socorro, New Mexico From bwaters at nrao.edu Thu Jul 5 12:31:46 2007 From: bwaters at nrao.edu (Boyd Waters) Date: Tue Oct 9 16:40:25 2007 Subject: deploying pre-build ports with macports In-Reply-To: References: <7BBA2A77-6727-4605-B422-0732E762B346@nrao.edu> Message-ID: <3971D4C1-9CBA-412E-BD58-546C76D8FE1C@nrao.edu> On Jul 5, 2007, at 1:11 PM, Barry Wark wrote: > Boyd, > > It sounds like you've been down this road already, then :) > >> From your answer, it sounds like things won't work. I'm a bit > confused, though. I thought that macports would keep receipts for the > installed ports (e.g. hdf5) (in /opt/local/var/db/dports/?) and that > those receipts would do the trick on the client machine as well. I > planned to compile the dependencies (e.g. hdf5) using "port install > XXX"--a source install--, then to make an installer that has it's root > at /opt/local and with an install target of /opt/local. Wouldn't the > client macports still have those receipts? > > Sorry for my confusion. Wow, you don't need to be sorry -- I think it is confusing. The binary package created with "port pkg" won't write that receipt to ${prefix}/var/db/dports/? I'm talking about binary packages created with MacPorts -- via the "port pkg" command -- they cause me no end of trouble. My opinion. I'd like to find the time to fix the MacPorts package-creation stuff, but my Tcl skills may not be adequate. Anyway. I created a large collection of packages - one for each port - via the "port pkg" command. I gave these to my fellow developers, and many scientists, who also had Macports installed. They double-click the pkg file, which launches the Apple installer, and installs the libraries, binaries, under /opt/local. Great. Then later they want to go build some MacPorts that need the packages that they've already installed with the bianry installer. Example: I gave them the fortran compiler as a binary package created from MacPorts, and they want to install (from source) a package that needs this compiler. When they say "port build fortran-thing", MacPorts *ignores* the binary-installed fortran compiler -- even though it came from a MacPorts-created binary package -- and goes ahead and builds every last little thing. Which may take hours. And may fail, depending upon which MacPorts tree they have. MacPorts packages that I have created have another nasty nasty bug, in that they cannot handle symbolic links in directory paths. The example I gave earlier on this list was MacPorts emacs -- which all of our users assumed they needed (they don't know that OS X already has it). The emacs package wants to add a file to /etc/X11. But /etc is a symlink to /private/etc. Since the MacPorts installer doesn't handle that, it *deletes* the symlink to /private/etc, creates a new, blank directory at /etc, and then write its file, and claims that installation completed successfully. Rendering the Macintosh unusable in the process. So I gave up on distributing binary packages created from MacPorts, and I just rely upon MacPorts on my developer-build box, and roll a tarball "by hand" for our scientific application. The tarball includes its own distribution of Python, Qt, etc. Since we roll out the application to people in different institutions, different configurations, this is the most robust: we try to assume as little as possible about what might already be set up on the end- users' Macs. Hope this helps! Some.. - boyd From jmpp at macports.org Thu Jul 5 22:05:13 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:25 2007 Subject: RPM/SRPM target change for 1.5 In-Reply-To: <46c8962fb07cb4f5442476cc831acd1a@macports.org> References: <46c8962fb07cb4f5442476cc831acd1a@macports.org> Message-ID: <96FD1260-A30D-467F-B5F5-E767FCFDC19D@macports.org> On Jul 5, 2007, at 11:38 AM, Anders F Bj?rklund wrote: > FYI, > These packaging changes should go in MacPorts 1.5 as well...: > http://trac.macosforge.org/projects/macports/changeset/26730 > http://trac.macosforge.org/projects/macports/changeset/26731 These two have been merged. > Will commit another change to those two, to make it word wrap. That's changeset r26737, I need to know whether you want it merged into 1.5 or not. While on it, I would really like to encourage you to please create a base/src/package1.0/package_util.tcl TCL package into which we can factor out common code shared between all the packaging targets, properly abstracted if need be. It may sound like a bit of an undertaking, but maybe we can start low and slow with the word wrap proc that you had to duplicate between the rpm and srpm targets...? > > --anders > Regards,... -jmpp From jmpp at macports.org Thu Jul 5 22:31:29 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:25 2007 Subject: 1.5 rc1 tag created ([26762] tags/release_1_5_0-rc1/) References: <20070706051629.E8BE66A5F1A@cvs.opensource.apple.com> Message-ID: Evening everyone! I'm happy to announce that I'm almost done with the preparations for the 1.5 release, available time being the sole constraint, as always. I believe the release branch is almost ready to ship so I created a first and hopefully only release candidate tag in r26762 below, which we should all take for a test drive ;-) I will wait for two more things: 1) final word on http://trac.macports.org/projects/macports/ticket/ 12231, whether that's a final solution to the issue or just an advice to leave it out of the release for the time being; 2) final word on whether or not I should merge Anders' r26737. After that I'll start preparations for the final release, including creating the ports tree archive, the dmg installer, release announcement and whatever else is relevant, finally! In short, do speak up quick if you have anything to report ;-) Regards,... -jmpp Begin forwarded message: > From: source_changes@macosforge.org > Date: July 6, 2007 1:16:29 AM GMT-04:00 > To: macports-changes@lists.macosforge.org > Subject: [26762] tags/release_1_5_0-rc1/ > Reply-To: macports-dev@lists.macosforge.org > > Revision 26762 Author jmpp@macports.org Date 2007-07-05 22:16:29 > -0700 (Thu, 05 Jul 2007) Log Message Tagging a first and hopefully > only release candidate of the 1.5 branch. Added Paths > tags/release_1_5_0-rc1/ > Diff > Copied: tags/release_1_5_0-rc1 (from rev 26761, branches/release_1_5) > _______________________________________________ > macports-changes mailing list > macports-changes@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-changes From jmpp at macports.org Thu Jul 5 22:46:24 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:25 2007 Subject: Release 1.5 branch created In-Reply-To: <7D7A8BFF-B80D-478C-BB3A-89EC466FCA1E@macports.org> References: <468682BB.7030404@orcaware.com> <1DB87759-7559-4D51-8412-7CEBBB9F2533@macports.org> <4AFF556B-9216-4FCE-9A9F-17DDA5CAB54B@orcaware.com> <9BA95B9A-5612-43EF-9A6B-7DB2B5C77607@macports.org> <1C40450C-5F82-4E06-BF86-2AD9091428BC@macports.org> <7D7A8BFF-B80D-478C-BB3A-89EC466FCA1E@macports.org> Message-ID: <2062E3DF-5686-4477-9857-DA67B9D8C4B9@macports.org> On Jul 5, 2007, at 11:38 AM, James Berry wrote: > > On Jul 5, 2007, at 12:12 AM, Juan Manuel Palacios wrote: > >>> If it's just crazy old me, I can patch in here locally. >>> I'm not a die-hard FreeBSD fan, I just find the whole >>> Mac lock-in part a bit scary and want to stay portable... >> >> >> I understand portability and love it and embrace it (this is >> ports tree of open source software after all, and I dedicate quite >> a bit of time to it ;-), so I understand your concern. But in this >> particular case I do have to ask: what does portability buy not >> only the MacPorts project... but MacPorts users themselves? Are >> they really gonna fire up a FreeBSD box, remove its native (and >> much larger) ports tree and use MacPorts? I guess I just don't >> understand the motivation for that (maybe I haven't used FreeBSD's >> ports tree enough, if you know what I mean ;-). But if there is an >> audience out there wanting to do exactly that, then by all means! >> Still, however, Mac OS X is by far our main focus and I want to >> safeguard that. So I guess I could simply sum-up my position as >> follows: "whatever you want, as long as it doesn't hurt our Mac OS >> X focus in any way.... and also as long as it's not crack >> smoking!" ;-) And that goes for other platforms too, not just >> FreeBSD (someone using MacPorts on Linux? ;-) >> >> So, now to everybody.... any objections to merging FreeBSD >> support into release_1_5? James and Markus? You cool? going >> once.... going twice.... ;-) > > I don't have any problems with some relatively minor patches > required to support use of MacPorts in other environments, such as > FreeBSD. A couple of points though: > > - I might change my mind of the extent of such patches began to > impact the maintainability of the MacPorts base code. > > - There may be times when some of the things we do to MacPorts may > not be easily supportable on other OS's. One example being that I'd > like to make a bunch of new changes to Startupitem support sometime > around the leopard release (when we can finally _assume_ launchd > support) that may not be so easy to replicate on other OS's. Given > MacPorts charter as a Mac system, I'm not going to let the > compatibility with other OS's stand in the way of adding support > for Mac-only features. > > James Not sure if it's necessary as I believe I already stated my position clearly, but I'll do it here again just to be safe. I believe James' comments above echo my position to a large extent, even though he states his somewhat more firmly and stricter. Maybe in the long term we can reach a middle point somewhere, but in a nutshell we agree fully on what the project course will be. The extra mile I'm willing to go and which I could negotiate for is keeping support for other platforms in as long as there are active interests maintaining it, just as there are now, and as long as they work hard to keep the compatibility code from becoming the development impacting roadblock James talks about above. As long as those two points are met I don't see a problem in keeping support for other platforms in, this is an open source project after all and we do embrace these ideals! Hope MacPorts on FreeBSD rocks as much as on Mac OS X, keep up the good work Anders! Regards,... -jmpp From jmpp at macports.org Thu Jul 5 23:34:57 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:25 2007 Subject: Draft of a minimalist MacPorts Guide In-Reply-To: References: Message-ID: <362A3EAC-0F62-47AD-B49F-8F36B3A1CDF8@macports.org> Hi Mark! I've only managed to skim over your draft but I think it seems pretty good to begin with, kudos! Even though the existing guide is pretty outdated in some aspects, I wouldn't know where to stand between this draft of yours and our existing sources (there is some good material there!), haven't really had the time to do any serious comparisons. I'd love it if you could team up with Maun Suang and Brian Campbell, who've been actively contributing to documentation lately, and come up with a plan to rewrite as much as you can while keeping the best of both. Doing it in docbook format would be sweet, we already have automated guide regen straight off svn sources going on Daniel Luke's box, meaning that whatever we commit to the doc/ svn dir is reflected on the regen'd html files automagically, no fuss! (what's the regen periodicity, Daniel?). We also have a temporary location for the guide up at Daniel's site (http://geeklair.net/macports_guide/), but I am coordinating with Kevin Van Vechten a move to MacOSForge servers with a static link to it and automated uploads, this time for real. We're are also working on a mechanism to grant wiki write access to documentation contributors who do not yet have full svn write access, so that we can broaden our contributors base in a much faster and way. I'll get back to everybody once all this is in place, though. So as you can see, we already have this ball rolling with revived energies, so I'd really love it if you could team up and work people like Maun Suang and Brian (and any other willing to dedicate some time to this, most welcome!), providing your new draft as a base for a major guide redesign and refresh. Again, kudos for this great effort! Regards,... -jmpp On Jul 5, 2007, at 4:10 PM, markd@macports.org wrote: > I think the structure of the original guide is fundamentally > flawed. I > cooked up a draft of a minimalist approach. What do y'all think? > > http://homepage.mac.com/duling/macports/guide.html > > I used the stylesheet from another document I had handy, so don't > mind the > format or the fact that it isn't chunked. The colors and text of the > original guide make it look more professional I think but I didn't > have > time to mess with the stylesheet, especially since I don't know if > people > will really like this approach anyway. > > Mark > > _______________________________________________ > macports-users mailing list > macports-users@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-users From afb at macports.org Fri Jul 6 00:24:25 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Oct 9 16:40:25 2007 Subject: Release 1.5 branch created In-Reply-To: <2062E3DF-5686-4477-9857-DA67B9D8C4B9@macports.org> References: <468682BB.7030404@orcaware.com> <1DB87759-7559-4D51-8412-7CEBBB9F2533@macports.org> <4AFF556B-9216-4FCE-9A9F-17DDA5CAB54B@orcaware.com> <9BA95B9A-5612-43EF-9A6B-7DB2B5C77607@macports.org> <1C40450C-5F82-4E06-BF86-2AD9091428BC@macports.org> <7D7A8BFF-B80D-478C-BB3A-89EC466FCA1E@macports.org> <2062E3DF-5686-4477-9857-DA67B9D8C4B9@macports.org> Message-ID: <0df0645eed1124911d64cb343522bb31@macports.org> Juan Manuel Palacios wrote: > Not sure if it's necessary as I believe I already stated my position > clearly, but I'll do it here again just to be safe. I believe James' > comments above echo my position to a large extent, even though he > states his somewhat more firmly and stricter. Maybe in the long term > we can reach a middle point somewhere, but in a nutshell we agree > fully on what the project course will be. > > The extra mile I'm willing to go and which I could negotiate for is > keeping support for other platforms in as long as there are active > interests maintaining it, just as there are now, and as long as they > work hard to keep the compatibility code from becoming the development > impacting roadblock James talks about above. > > As long as those two points are met I don't see a problem in keeping > support for other platforms in, this is an open source project after > all and we do embrace these ideals! I think it's important that the "base" of MacPorts remains Open Source, and usable with such operating systems - whether it's Darwin or FreeBSD. And I do believe that items such as License metadata (Trac Ticket #7493) is much more important than petty issues like Noarch metadata (#12206) ? > Hope MacPorts on FreeBSD rocks as much as on Mac OS X, keep up the > good work Anders! I don't see any reason why it shouldn't work just as good on that system. (granted the number of ports is much smaller, but I mean the base and RPM) Can give it a whirl on (Pure)Darwin 8.0.1 as well, see how it goes there ? It would also have to use GNUstep of course, there is no Cocoa for Darwin. --anders From afb at macports.org Fri Jul 6 00:28:53 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Oct 9 16:40:25 2007 Subject: RPM/SRPM target change for 1.5 In-Reply-To: <96FD1260-A30D-467F-B5F5-E767FCFDC19D@macports.org> References: <46c8962fb07cb4f5442476cc831acd1a@macports.org> <96FD1260-A30D-467F-B5F5-E767FCFDC19D@macports.org> Message-ID: <3e631246de42b5e84bc9e277ac6e8c7c@macports.org> Juan Manuel Palacios: >> Will commit another change to those two, to make it word wrap. > > That's changeset r26737, I need to know whether you want it merged > into 1.5 or not. It would be nice, it only affects the descriptions of the RPMs. (otherwise they'll wrap at the end of the screen, or not at all) > While on it, I would really like to encourage you to please create a > base/src/package1.0/package_util.tcl TCL package into which we can > factor out common code shared between all the packaging targets, > properly abstracted if need be. It may sound like a bit of an > undertaking, but maybe we can start low and slow with the word wrap > proc that you had to duplicate between the rpm and srpm targets...? Please go ahead and do so, as you can see my Tcl is rather poor... It's a generic routine, so you can move it outside packaging too ? --anders From markd at macports.org Fri Jul 6 01:23:07 2007 From: markd at macports.org (markd@macports.org) Date: Tue Oct 9 16:40:25 2007 Subject: Draft of a minimalist MacPorts Guide In-Reply-To: <362A3EAC-0F62-47AD-B49F-8F36B3A1CDF8@macports.org> References: <362A3EAC-0F62-47AD-B49F-8F36B3A1CDF8@macports.org> Message-ID: Juan Manuel Palacios on Thursday, July 5, 2007 at 11:34 PM -0800 wrote: > Even though the existing guide is pretty outdated in some aspects, I >wouldn't know where to stand between this draft of yours and our >existing sources (there is some good material there!), haven't really >had the time to do any serious comparisons. Oops, resending to the lists with my subscribed address .... Yes there is good stuff in the old Guide. I am mining it for all I can to make sure that nothing in it gets left out, but I just got started and I'm not done yet. Or perhaps the more advanced stuff in the old Guide won't easily fit into my "minimalist" Guide; if so it can be accomodated separately. Either way, I don't want to leave anything out. > I'd love it if you could >team up with Maun Suang and Brian Campbell, who've been actively >contributing to documentation lately, and come up with a plan to >rewrite as much as you can while keeping the best of both. Yes, I have the same idea. > > Doing it in docbook format would be sweet Yes I thought so too. DocBook gives a lot of flexibility. Mark From afb at macports.org Fri Jul 6 01:29:09 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Oct 9 16:40:25 2007 Subject: deploying pre-build ports with macports In-Reply-To: <3971D4C1-9CBA-412E-BD58-546C76D8FE1C@nrao.edu> References: <7BBA2A77-6727-4605-B422-0732E762B346@nrao.edu> <3971D4C1-9CBA-412E-BD58-546C76D8FE1C@nrao.edu> Message-ID: Boyd Waters wrote: >> From your answer, it sounds like things won't work. I'm a bit >> confused, though. I thought that macports would keep receipts for the >> installed ports (e.g. hdf5) (in /opt/local/var/db/dports/?) and that >> those receipts would do the trick on the client machine as well. I >> planned to compile the dependencies (e.g. hdf5) using "port install >> XXX"--a source install--, then to make an installer that has it's root >> at /opt/local and with an install target of /opt/local. Wouldn't the >> client macports still have those receipts? >> >> Sorry for my confusion. > > Wow, you don't need to be sorry -- I think it is confusing. > > The binary package created with "port pkg" won't write that receipt to > ${prefix}/var/db/dports/? None of the binary packages (pkg, rpm, deb, etc.) will write receipts. The binary archives (tgz, tbz, xar, etc.) however, will work as ports. What makes matters *really* confusing, however, is that the "archives" used to be called packages in FreeBSD Ports and are stored in packages: /opt/local/var/db/dports/packages (need to set: "portarchivemode yes") > I'm talking about binary packages created with MacPorts -- via the > "port pkg" command -- they cause me no end of trouble. My opinion. I'd > like to find the time to fix the MacPorts package-creation stuff, but > my Tcl skills may not be adequate. "port pkg" creates Mac OS X packages, rather than MacPorts packages. And the old command of "make package" is now "port archive" instead. > Anyway. I created a large collection of packages - one for each port - > via the "port pkg" command. > > I gave these to my fellow developers, and many scientists, who also > had Macports installed. > > They double-click the pkg file, which launches the Apple installer, > and installs the libraries, binaries, under /opt/local. > > Great. > > Then later they want to go build some MacPorts that need the packages > that they've already installed with the bianry installer. > > Example: I gave them the fortran compiler as a binary package created > from MacPorts, and they want to install (from source) a package that > needs this compiler. > > When they say "port build fortran-thing", MacPorts *ignores* the > binary-installed fortran compiler -- even though it came from a > MacPorts-created binary package -- and goes ahead and builds every > last little thing. Which may take hours. And may fail, depending upon > which MacPorts tree they have. You can't build off the binary packages, you will need ports/archives for that - or else you also need to build any new ports as .pkg too ? (i.e. they could install a "fortran-thing" package along with the "fortran" binary package and those two would then work together...) But you cannot mix and match ports/archives and the binary packages. Even if MacPorts creates them, those packages are for "outside" use. > MacPorts packages that I have created have another nasty nasty bug, in > that they cannot handle symbolic links in directory paths. The example > I gave earlier on this list was MacPorts emacs -- which all of our > users assumed they needed (they don't know that OS X already has it). > The emacs package wants to add a file to /etc/X11. But /etc is a > symlink to /private/etc. Since the MacPorts installer doesn't handle > that, it *deletes* the symlink to /private/etc, creates a new, blank > directory at /etc, and then write its file, and claims that > installation completed successfully. Rendering the Macintosh unusable > in the process. I think this one is a "feature" of the Mac OS X Installer.app, though ? (Just like the missing "Uninstall" button, for .pkg already installed.) Some of the reasons why I would recommend using RPM over PKG, actually. But I did think later versions of PackageMaker.app fixed the bug above ? i.e. by automatically moving any /etc/ files into /private/etc/ instead. (also, having wrong permissions on / was another way to hose a system...) > So I gave up on distributing binary packages created from MacPorts, > and I just rely upon MacPorts on my developer-build box, and roll a > tarball "by hand" for our scientific application. The tarball includes > its own distribution of Python, Qt, etc. > > Since we roll out the application to people in different institutions, > different configurations, this is the most robust: we try to assume as > little as possible about what might already be set up on the > end-users' Macs. If you want your users to be able to use "port" themselves, then you should probably use the archives. If you plan on building it centrally and then distributing the binaries, then you should use the packages. This will work better when the Remote Fetching feature is implemented... Then the MacPorts port command or the Package Manager* will try to fetch pre-built binaries from a server, before starting to do a source build. * such as e.g. the Smart Package Manager, for handling RPM packages --anders From cssdev at mac.com Fri Jul 6 04:20:12 2007 From: cssdev at mac.com (cssdev@mac.com) Date: Tue Oct 9 16:40:25 2007 Subject: Release 1.5 branch created In-Reply-To: <2062E3DF-5686-4477-9857-DA67B9D8C4B9@macports.org> References: <468682BB.7030404@orcaware.com> <1DB87759-7559-4D51-8412-7CEBBB9F2533@macports.org> <4AFF556B-9216-4FCE-9A9F-17DDA5CAB54B@orcaware.com> <9BA95B9A-5612-43EF-9A6B-7DB2B5C77607@macports.org> <1C40450C-5F82-4E06-BF86-2AD9091428BC@macports.org> <7D7A8BFF-B80D-478C-BB3A-89EC466FCA1E@macports.org> <2062E3DF-5686-4477-9857-DA67B9D8C4B9@macports.org> Message-ID: On Jul 6, 2007, at 1:46 AM, Juan Manuel Palacios wrote: > Hope MacPorts on FreeBSD rocks as much as on Mac OS X, keep up the > good work Anders! I used MacPorts on a FreeBSD box previously. I built the MacPorts rsync port to easily back up my Mac to the FreeBSD box along with resource forks and extra attributes. There were a few small glitches getting base to work, but my use wasn't very extensive. In practice, I used MacPorts strictly for packages and patches not available through the FreeBSD Ports Collection. I don't have that box anymore, but I liked knowing there was some portability beyond just Mac OS X. Plus, writing Portfiles was much easier than writing Makefiles. ;) Chris From mccdo at iastate.edu Fri Jul 6 08:13:20 2007 From: mccdo at iastate.edu (Doug McCorkle) Date: Tue Oct 9 16:40:25 2007 Subject: The fetch command in Portfiles Message-ID: Hello, I would like to use: fetch.ignore_sslcrt in my Portfile or: fetch.args in my Portfile but I get an error about the commands not being recognized. Is there a new way to work with the fetch target? Thanks. Doug From afb at macports.org Fri Jul 6 15:20:12 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Oct 9 16:40:25 2007 Subject: 1.5 rc1 tag created ([26762] tags/release_1_5_0-rc1/) In-Reply-To: References: <20070706051629.E8BE66A5F1A@cvs.opensource.apple.com> Message-ID: Juan Manuel Palacios wrote: > I will wait for two more things: > > 1) final word on > http://trac.macports.org/projects/macports/ticket/12231, whether > that's a final solution to the issue or just an advice to leave it out > of the release for the time being; > 2) final word on whether or not I should merge Anders' r26737. Main reason for #12231 is coping with selfupdate and ./configure. It works from the BSD port anyway, since that sets all arguments. If you're considering FreeBSD support, it should also be noted that configure currently assumes bash and the makefiles assumes gnumake... This means that "selfupdate" might not work out-of-the-box on systems where /bin/sh is some other shell and make is some other make (bsd) ? I think the very latest version of FreeBSD's sh is OK to use now (or one could edit configure to say /bin/bash), and using gmake instead of make will call FreeBSD's gnumake instead of bsdmake (the errors are due to GNU-make constructs like ifeq/ifneq...) If you want to address this portability problem, you can test with "./configure && bsdmake" - or you can just demand GNU make ? --anders From landonf at macports.org Fri Jul 6 16:57:02 2007 From: landonf at macports.org (Landon Fuller) Date: Tue Oct 9 16:40:25 2007 Subject: 1.5 rc1 tag created ([26762] tags/release_1_5_0-rc1/) In-Reply-To: References: <20070706051629.E8BE66A5F1A@cvs.opensource.apple.com> Message-ID: <9175AB54-5F69-4891-8BD9-00936F47CA07@macports.org> On Jul 6, 2007, at 3:20 PM, Anders F Bj?rklund wrote: > Juan Manuel Palacios wrote: > >> I will wait for two more things: >> >> 1) final word on http://trac.macports.org/projects/macports/ticket/ >> 12231, whether that's a final solution to the issue or just an >> advice to leave it out of the release for the time being; >> 2) final word on whether or not I should merge Anders' r26737. > > Main reason for #12231 is coping with selfupdate and ./configure. > It works from the BSD port anyway, since that sets all arguments. > > > If you're considering FreeBSD support, it should also be noted that > configure currently assumes bash and the makefiles assumes gnumake... > > This means that "selfupdate" might not work out-of-the-box on systems > where /bin/sh is some other shell and make is some other make (bsd) ? > > I think the very latest version of FreeBSD's sh is OK to use now > (or one could edit configure to say /bin/bash), and using gmake > instead of make will call FreeBSD's gnumake instead of bsdmake > (the errors are due to GNU-make constructs like ifeq/ifneq...) > > If you want to address this portability problem, you can test > with "./configure && bsdmake" - or you can just demand GNU make ? The Makefiles used to be BSD make compatible. If configure && makefiles are incompatible with non-GNU tools, I'd consider that a bug. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070706/7ea68566/PGP.bin From afb at macports.org Sat Jul 7 01:16:37 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Oct 9 16:40:25 2007 Subject: 1.5 rc1 tag created ([26762] tags/release_1_5_0-rc1/) In-Reply-To: <9175AB54-5F69-4891-8BD9-00936F47CA07@macports.org> References: <20070706051629.E8BE66A5F1A@cvs.opensource.apple.com> <9175AB54-5F69-4891-8BD9-00936F47CA07@macports.org> Message-ID: Landon Fuller wrote: >> If you're considering FreeBSD support, it should also be noted that >> configure currently assumes bash and the makefiles assumes gnumake... > > The Makefiles used to be BSD make compatible. If configure && > makefiles are incompatible with non-GNU tools, I'd consider that a > bug. Added it as: http://trac.macports.org/projects/macports/ticket/12247 Haven't verified that the MACOSX_DEPLOYMENT_TARGET works as intended, but the other two fixes should be OK - tested with "bsdmake" on Tiger. From what I recall the generated configure didn't work with the original FreeBSD 6.2 release version of /bin/sh, but did work after a portupgrade. If the 1.5.0 is going to be the *only* release in the "1.5 series" MacPorts, it would be great if it could be working out-of-the-box on FreeBSD 6.2 too ? But that'll also need the fixes for #12151, #12153, #12173, #12212, #12231... Then some of the ports need revisions, especially python24, icu and sqlite3 ? --anders From eloy.de.enige at gmail.com Sat Jul 7 05:55:23 2007 From: eloy.de.enige at gmail.com (Eloy Duran) Date: Tue Oct 9 16:40:25 2007 Subject: RubyCocoa 0.11.1 In-Reply-To: References: <8193F3E0-65E3-4E75-9F86-6AA7024ED0B9@macports.org> Message-ID: Hello, Took a while, before I had some time again to play with this... First of, Ryan you were right that it was another port complaining about the universal variant. It was rb-hpricot, I added "universal_variant no" to the portfile which works great. Also rubygems has a problem with the universal variant, I added the following to the portfile to fix it: variant universal { configure.args-delete --disable-dependency-tracking } Is this the correct way to do it? One other thing I hadn't noticed earlier is that ruby itself does not work with the universal variant. I could of course also add "universal_variant no", but this will defeat the purpose of building rubycocoa as a universal.... So does anybody know if ruby is already being worked on? On another topic, I haven't yet heard back from the maintainer of the rubycocoa portfile. How do you guys deal with these kinds of issues? Is there a period or so after which a new maintainer could step in? Cheers, Eloy On 6/30/07, Ryan Schmidt wrote: > On Jun 30, 2007, at 14:40, Eloy Duran wrote: > > > On 6/30/07, Ryan Schmidt wrote: > > > >> On Jun 30, 2007, at 09:48, Eloy Duran wrote: > >> > >> > Second, I'm not allowed to use the universal variant because > >> it's not > >> > a configure script based installation. Is there some way to > >> override > >> > this? Because now I have a builduniversal variant, but this is > >> not so > >> > nice... > >> > >> It should suffice to just redefine the universal variant: > >> > >> variant universal { > >> configure.args-append --build-universal=yes > >> } > > > > Unfortunately it doesn't. Macports complains that the universal > > variant is only supported on "configure" based ports... > > Don't forget to reply to all so that your reply goes to the list, > too, and not just to me. > > Run the install in debug mode (sudo port -dv install). It's not > complaining about your port; it's complaining about a different one. > See my similar experience here: > > http://trac.macosforge.org/projects/macports/ticket/12170 > > If you'll tell us which port it's complaining about, we can disable > its universal variant like I did in #12137 for XFree86. That will > work around the problem. > > From ryandesign at macports.org Sat Jul 7 20:14:06 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:25 2007 Subject: [26771] trunk/dports/devel/git-core In-Reply-To: <20070706214149.B89776A85BE@cvs.opensource.apple.com> References: <20070706214149.B89776A85BE@cvs.opensource.apple.com> Message-ID: <64578A0D-408D-4BBA-921A-3285758E6467@macports.org> On Jul 6, 2007, at 16:41, source_changes@macosforge.org wrote: > Revision: 26771 > http://trac.macosforge.org/projects/macports/changeset/26771 > Author: mgrimes@macports.org > Date: 2007-07-06 14:41:49 -0700 (Fri, 06 Jul 2007) > > Log Message: > ----------- > Update to git-core 1.5.2.3 > > - Add p5-error (Fix #12240) > - Refresh and rename patch files to literal naming conventions instead > of functional. > - Add darwin_9 variant to workaround ticket #12245. > - whitespace fixes It would be better if you could commit whitespace changes separately from functional changes. This makes it much easier to tell by glancing at a diff what functional changes have been made in a given revision. From mgrimes at macports.org Sat Jul 7 22:14:43 2007 From: mgrimes at macports.org (Mark Grimes) Date: Tue Oct 9 16:40:25 2007 Subject: [26771] trunk/dports/devel/git-core In-Reply-To: <64578A0D-408D-4BBA-921A-3285758E6467@macports.org> References: <20070706214149.B89776A85BE@cvs.opensource.apple.com> <64578A0D-408D-4BBA-921A-3285758E6467@macports.org> Message-ID: <20070707221443689056.be21f8d4@macports.org> On Sat, 7 Jul 2007 22:14:06 -0500, Ryan Schmidt wrote: > On Jul 6, 2007, at 16:41, source_changes@macosforge.org wrote: > >> Revision: 26771 >> http://trac.macosforge.org/projects/macports/changeset/26771 >> Author: mgrimes@macports.org >> Date: 2007-07-06 14:41:49 -0700 (Fri, 06 Jul 2007) >> >> Log Message: >> ----------- >> Update to git-core 1.5.2.3 >> >> - Add p5-error (Fix #12240) >> - Refresh and rename patch files to literal naming conventions instead >> of functional. >> - Add darwin_9 variant to workaround ticket #12245. >> - whitespace fixes > > It would be better if you could commit whitespace changes separately > from functional changes. This makes it much easier to tell by > glancing at a diff what functional changes have been made in a given > revision. Thanks for the heads up! Yup went over this with the maintainer -- since I'm decentralized I have a non-standard excuse: it was late when I committed it to my local git branch and I forgot that it was bundled when I pushed it up to svn the next day. Unfortunately with subversion I can't go back and amend (re-edit metadata and update the tree) the commit without svnadmin voodoo... Indeed git has spoiled me. I will check my local branches more carefully before pushing upstream. Cheers! Mark Grimes, MacPorts http://www.macports.org/ From simon at ruderich.com Sun Jul 8 12:53:13 2007 From: simon at ruderich.com (Simon Ruderich) Date: Tue Oct 9 16:40:25 2007 Subject: Prevent removal of configured files after Portfile change Message-ID: <469140A9.7070504@ruderich.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, is it possible to prevent the complete removal of all configured/compiled data if the Portfile was changed. I'm just updating configuration parameters but port completely removes the project data and starts again. Thanks for your help, Simon - -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGkUCpYRX4BO+zMikRCmqJAKDB0nlMLlpEi3/PMkEx9nXShkrucgCgrcF7 N67UPiiRSCankBTt8s9i1t8= =SOD+ -----END PGP SIGNATURE----- From ryandesign at macports.org Sun Jul 8 18:13:20 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:25 2007 Subject: Prevent removal of configured files after Portfile change In-Reply-To: <469140A9.7070504@ruderich.com> References: <469140A9.7070504@ruderich.com> Message-ID: <97B5DD54-A9B7-42C8-8907-ABBA6DC8D375@macports.org> On Jul 8, 2007, at 14:53, Simon Ruderich wrote: > is it possible to prevent the complete removal of all > configured/compiled data if the Portfile was changed. I'm just > updating > configuration parameters but port completely removes the project data > and starts again. I think you're saying that you have a port that installs a configuration file, and that you've then changed the configuration file, and when you upgrade the port, your changes to the configuration file are lost. The solution is for the port to install a *sample* configuration file, and for the user to manually copy the sample to the real configuration file name when configuring. See the apache2 portfile's httpd.conf.sample for an example. From ryandesign at macports.org Sun Jul 8 18:35:07 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:25 2007 Subject: RubyCocoa 0.11.1 In-Reply-To: References: <8193F3E0-65E3-4E75-9F86-6AA7024ED0B9@macports.org> Message-ID: <37DCB7C9-9139-4501-B977-4D48D0B30934@macports.org> On Jul 7, 2007, at 07:55, Eloy Duran wrote: > On 6/30/07, Ryan Schmidt wrote: > >> On Jun 30, 2007, at 14:40, Eloy Duran wrote: >> >>> On 6/30/07, Ryan Schmidt wrote: >>> >>>> On Jun 30, 2007, at 09:48, Eloy Duran wrote: >>>> >>>>> Second, I'm not allowed to use the universal variant because >>>>> it's not a configure script based installation. Is there some way >>>>> to override this? Because now I have a builduniversal variant, >>>>> but this is not so nice... >>>> >>>> It should suffice to just redefine the universal variant: >>>> >>>> variant universal { >>>> configure.args-append --build-universal=yes >>>> } >>> >>> Unfortunately it doesn't. Macports complains that the universal >>> variant is only supported on "configure" based ports... >> >> Run the install in debug mode (sudo port -dv install). It's not >> complaining about your port; it's complaining about a different one. >> See my similar experience here: >> >> http://trac.macosforge.org/projects/macports/ticket/12170 >> >> If you'll tell us which port it's complaining about, we can disable >> its universal variant like I did in #12137 for XFree86. That will >> work around the problem. > > First of, Ryan you were right that it was another port complaining > about the universal variant. It was rb-hpricot, I added > "universal_variant no" to the portfile which works great. Ok, so either "universal_variant no" should be added to the rb- hpricot port, or the rb-hpricot port should be fixed so it can build universal. I'm Cc'ing Paul Guyot who maintains rb-hpricot. > Also rubygems has a problem with the universal variant, I added the > following to the portfile to fix it: > > variant universal { > configure.args-delete --disable-dependency-tracking > } > > Is this the correct way to do it? No. You have effectively made the port no longer attempt to build universal by doing that. Remember: when you write "variant universal {...}" in your portfile, you are *replacing* the default universal variant, which reads: variant universal { if {[tbool use_xmkmf] || ![tbool use_configure]} { return -code error "Default universal variant only works with ports based on configure" } configure.args-append ${configure.universal_args} if {![file exists /Developer/SDKs/MacOSX10.4u.sdk/]} { return -code error "MacOS X 10.4 universal SDK is not installed (are we running on 10.3? did you forget to install it?) and building with +universal will very likely fail" } configure.cflags-append ${configure.universal_cflags} configure.cppflags-append ${configure.universal_cppflags} configure.cxxflags-append ${configure.universal_cxxflags} configure.ldflags-append ${configure.universal_ldflags} } See portmain.tcl: http://trac.macosforge.org/projects/macports/browser/trunk/base/src/ port1.0/portmain.tcl The various universal_*flags are defined thus: default configure.universal_args --disable-dependency-tracking default configure.universal_cflags {"-isysroot /Developer/SDKs/ MacOSX10.4u.sdk -arch i386 -arch ppc"} default configure.universal_cppflags {} default configure.universal_cxxflags {"-isysroot /Developer/SDKs/ MacOSX10.4u.sdk -arch i386 -arch ppc"} default configure.universal_ldflags {"-arch i386 -arch ppc"} See portconfigure.tcl: http://trac.macosforge.org/projects/macports/browser/trunk/base/src/ port1.0/portconfigure.tcl What you probably want instead of "variant universal {...}" is: pre-configure { if {[variant_isset universal]} { configure.args-delete --disable-dependency-tracking } } That's assuming, of course, that it's really necessary to remove "-- disable-dependency-tracking". The reason it's there by default for +universal is that it's needed for most (all?) configure-based software when building universal. Now, rb-cocoa is in the ruby portgroup. These changes you're making to make it universal... might they also be relevant for the other ports in the ruby portgroup? If so, perhaps your changes, once you figure out how to build a ruby thing universal, should go into MacPorts base, rather than into each individual ruby-related portfile. > One other thing I hadn't noticed earlier is that ruby itself does not > work with the universal variant. I could of course also add > "universal_variant no", but this will defeat the purpose of building > rubycocoa as a universal.... So does anybody know if ruby is already > being worked on? No idea. Have you already asked Paul? He's also the maintainer of the ruby port. Also, have you already built all of Ruby's dependencies universal? That would be the first required step. > On another topic, I haven't yet heard back from the maintainer of the > rubycocoa portfile. How do you guys deal with these kinds of issues? > Is there a period or so after which a new maintainer could step in? The policy is that if you have changes you want made to a portfile, you file a ticket in Trac and attach a diff and assign it to the maintainer (if in the list) and Cc yourself and the maintainer. If the maintainer does not react within 72 hours, then you can email the list with the ticket number and request that someone else commit the change. From simon at ruderich.com Mon Jul 9 05:46:08 2007 From: simon at ruderich.com (Simon Ruderich) Date: Tue Oct 9 16:40:25 2007 Subject: Prevent removal of configured files after Portfile change In-Reply-To: <97B5DD54-A9B7-42C8-8907-ABBA6DC8D375@macports.org> References: <469140A9.7070504@ruderich.com> <97B5DD54-A9B7-42C8-8907-ABBA6DC8D375@macports.org> Message-ID: <46922E10.9040502@ruderich.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Ryan Schmidt wrote: > I think you're saying that you have a port that installs a configuration > file, and that you've then changed the configuration file, and when you > upgrade the port, your changes to the configuration file are lost. The > solution is for the port to install a *sample* configuration file, and > for the user to manually copy the sample to the real configuration file > name when configuring. See the apache2 portfile's httpd.conf.sample for > an example. Thanks for your answer, but I meant something else. When I'm working on a new Portfile I often have to run for example the "port -d configure" command very often, because some libraries are not found and I have to experiment with the options (for configure). But every time I change the Portfile it removes the old extracted data and starts it all again. The same occurs with the "port -d build" command. So my question is how can I prevent the removal of the files which were extracted in the port's "work" directory. Thanks for your help, Simon - -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGki4PYRX4BO+zMikRCtqDAJ9tbBHdfO/iA8Ypmux0YLTMF1RcwwCeNyZL C/CwFhXNUjiTJ/i7ivbuc1g= =+jqM -----END PGP SIGNATURE----- From yves at macports.org Mon Jul 9 06:00:17 2007 From: yves at macports.org (Yves de Champlain) Date: Tue Oct 9 16:40:25 2007 Subject: Prevent removal of configured files after Portfile change In-Reply-To: <46922E10.9040502@ruderich.com> References: <469140A9.7070504@ruderich.com> <97B5DD54-A9B7-42C8-8907-ABBA6DC8D375@macports.org> <46922E10.9040502@ruderich.com> Message-ID: <0509692A-BF16-4985-B02C-29B7E418B41A@macports.org> Le 07-07-09 ? 08:46, Simon Ruderich a ?crit : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Ryan Schmidt wrote: >> I think you're saying that you have a port that installs a >> configuration >> file, and that you've then changed the configuration file, and >> when you >> upgrade the port, your changes to the configuration file are lost. >> The >> solution is for the port to install a *sample* configuration file, >> and >> for the user to manually copy the sample to the real configuration >> file >> name when configuring. See the apache2 portfile's >> httpd.conf.sample for >> an example. > > Thanks for your answer, but I meant something else. > When I'm working on a new Portfile I often have to run for example the > "port -d configure" command very often, because some libraries are not > found and I have to experiment with the options (for configure). > But every time I change the Portfile it removes the old extracted data > and starts it all again. The same occurs with the "port -d build" > command. > So my question is how can I prevent the removal of the files which > were > extracted in the port's "work" directory. you mean "port -o" (as seen in the manpage) yves From ehainry at free.fr Mon Jul 9 07:12:13 2007 From: ehainry at free.fr (Emmanuel Hainry) Date: Tue Oct 9 16:40:25 2007 Subject: Prevent removal of configured files after Portfile change In-Reply-To: <46922E10.9040502@ruderich.com> References: <469140A9.7070504@ruderich.com> <97B5DD54-A9B7-42C8-8907-ABBA6DC8D375@macports.org> <46922E10.9040502@ruderich.com> Message-ID: On 09 Jul 2007, at 14:46, Simon Ruderich wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Ryan Schmidt wrote: >> I think you're saying that you have a port that installs a >> configuration >> file, and that you've then changed the configuration file, and >> when you >> upgrade the port, your changes to the configuration file are lost. >> The >> solution is for the port to install a *sample* configuration file, >> and >> for the user to manually copy the sample to the real configuration >> file >> name when configuring. See the apache2 portfile's >> httpd.conf.sample for >> an example. > > Thanks for your answer, but I meant something else. > When I'm working on a new Portfile I often have to run for example the > "port -d configure" command very often, because some libraries are not > found and I have to experiment with the options (for configure). > But every time I change the Portfile it removes the old extracted data > and starts it all again. The same occurs with the "port -d build" > command. > So my question is how can I prevent the removal of the files which > were > extracted in the port's "work" directory. > When I have to tweak with the configure arguments or build environment, I do that manually instead of relying on port: going inside the build dir and trying configure, make, even make install (with special prefix) in order to get a working process. Only after that do I write the Portfile and try trace mode to check for dependencies. There is no use in writing a portfile for something you are not sure will compile... Unless if you are able to guess everything in two tries and write patchfiles directly. Emmanuel From dluke at geeklair.net Mon Jul 9 07:46:45 2007 From: dluke at geeklair.net (Daniel J. Luke) Date: Tue Oct 9 16:40:26 2007 Subject: Q: variants specified in dependencies In-Reply-To: <1FFB1536-1287-4D0E-9308-6BA5D932D459@macports.org> References: <1FFB1536-1287-4D0E-9308-6BA5D932D459@macports.org> Message-ID: <13C14B66-531C-487F-98CC-F0B6D4B0EDC1@geeklair.net> On Jul 5, 2007, at 2:04 PM, Landon Fuller wrote: > My own (potentially unpopular) opinion is that this is possible to > implement and impossible to support, as it would introduce > exponential complexity to the dependency tree. I agree. The current workarounds for this lack of functionality (include as much functionality as possible in the port, create another port with the necessary functionality for other ports to depend on) work fairly well. Of course, the complexity of the dependency tree doesn't matter as much now as it could if we start building/testing all of the ports as has been talked about many times. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070709/3977b027/PGP.bin From simon at ruderich.com Mon Jul 9 08:47:13 2007 From: simon at ruderich.com (Simon Ruderich) Date: Tue Oct 9 16:40:26 2007 Subject: Prevent removal of configured files after Portfile change In-Reply-To: <0509692A-BF16-4985-B02C-29B7E418B41A@macports.org> References: <469140A9.7070504@ruderich.com> <97B5DD54-A9B7-42C8-8907-ABBA6DC8D375@macports.org> <46922E10.9040502@ruderich.com> <0509692A-BF16-4985-B02C-29B7E418B41A@macports.org> Message-ID: <46925881.7010801@ruderich.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Yves de Champlain wrote: > > you mean "port -o" (as seen in the manpage) > > yves That's working, thanks for your quick response. Stupid of me not trying it, but the manpage comment was a bit confusing to me. But I just should have tried it. Thanks for your help, Simon - -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGkliBYRX4BO+zMikRCtm8AJ9B2VTOl/Z/n/eWk46iI9GgTbFlqQCfespz LVdN7C1RpsU6VSilo5wwBD0= =HWVA -----END PGP SIGNATURE----- From simon at ruderich.com Mon Jul 9 08:51:24 2007 From: simon at ruderich.com (Simon Ruderich) Date: Tue Oct 9 16:40:26 2007 Subject: Prevent removal of configured files after Portfile change In-Reply-To: References: <469140A9.7070504@ruderich.com> <97B5DD54-A9B7-42C8-8907-ABBA6DC8D375@macports.org> <46922E10.9040502@ruderich.com> Message-ID: <4692597C.6000705@ruderich.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Emmanuel Hainry wrote: > When I have to tweak with the configure arguments or build > environment, I do that manually instead of relying on port: going > inside the build dir and trying configure, make, even make install > (with special prefix) in order to get a working process. Only after > that do I write the Portfile and try trace mode to check for > dependencies. There is no use in writing a portfile for something you > are not sure will compile... Unless if you are able to guess > everything in two tries and write patchfiles directly. > > Emmanuel I'm using this approach too, but after I got it working with configure, make, make install it sometimes doesn't work with macports instantly; there are still some additional information (for example to configure) necessary. And it speeds me up, when macports isn't removing the hole directory (but thanks to Yves I know now how to prevent this). Thanks for your help, Simon - -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGkll8YRX4BO+zMikRCu6qAJ4jv66tV6sUo/3jBFYFhVtNUMnKqQCguF/D ZE4fiDx4XoPFfbJRzkPevIU= =HIE6 -----END PGP SIGNATURE----- From mccdo at iastate.edu Mon Jul 9 13:57:48 2007 From: mccdo at iastate.edu (Doug McCorkle) Date: Tue Oct 9 16:40:26 2007 Subject: flagpoll Portfile for consideration in MacPorts Message-ID: <8E3374ED-9A54-4500-931E-B8FCB28FA071@iastate.edu> Hello, Attached is a Portfile for flagpoll https:// realityforge.vrsource.org/view/FlagPoll . Please let me know if there is anything else that needs to be done for its inclusion in MacPorts. Thanks. Doug -------------- next part -------------- A non-text attachment was scrubbed... Name: Portfile Type: application/octet-stream Size: 1056 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070709/a9d687e6/Portfile.obj -------------- next part -------------- From rhwood at mac.com Mon Jul 9 14:56:48 2007 From: rhwood at mac.com (Randall Wood) Date: Tue Oct 9 16:40:26 2007 Subject: Error updating MacPorts Message-ID: Error updating macports from 1.5.0-rc1 to 1.5.0: Getafix:~ rhwood$ sudo port selfupdate MacPorts base version 1.5 installed Error: /opt/local/bin/port: selfupdate failed: couldn't open "/opt/ local/var/macports/sources/rsync.macports.org/release/base/config/ mp_version": no such file or directory Getafix:~ rhwood$ sudo port -dv selfupdate DEBUG: Rebuilding the MacPorts base system if needed. DEBUG: Synchronizing ports tree(s) Synchronizing from rsync://rsync.macports.org/release/ports/ DEBUG: /usr/bin/rsync -rtzv --delete-after rsync://rsync.macports.org/ release/ports/ /opt/local/var/macports/sources/rsync.macports.org/ release/ports receiving file list ... done sent 74 bytes received 269017 bytes 19932.67 bytes/sec total size is 14713580 speedup is 54.68 Synchronizing from file:///Users/rhwood/Developer/MacPorts/WorkingPorts DEBUG: MacPorts base dir: /opt/local/var/macports/sources/ rsync.macports.org/release/base DEBUG: Setting user: root MacPorts base version 1.5 installed DEBUG: Updating using rsync receiving file list ... done config/ sent 73 bytes received 4957 bytes 1437.14 bytes/sec total size is 2093103 speedup is 416.12 DEBUG: couldn't open "/opt/local/var/macports/sources/ rsync.macports.org/release/base/config/mp_version": no such file or directory while executing "open [file join $mp_base_path config mp_version] r" (procedure "macports::selfupdate" line 45) invoked from within "macports::selfupdate [array get global_options]" Error: /opt/local/bin/port: selfupdate failed: couldn't open "/opt/ local/var/macports/sources/rsync.macports.org/release/base/config/ mp_version": no such file or directory Randall Wood rhwood@mac.com http://shyramblings.blogspot.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From ryandesign at macports.org Mon Jul 9 23:36:28 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:26 2007 Subject: flagpoll Portfile for consideration in MacPorts In-Reply-To: <8E3374ED-9A54-4500-931E-B8FCB28FA071@iastate.edu> References: <8E3374ED-9A54-4500-931E-B8FCB28FA071@iastate.edu> Message-ID: On Jul 9, 2007, at 15:57, Doug McCorkle wrote: > Attached is a Portfile for flagpoll https:// > realityforge.vrsource.org/view/FlagPoll . Please let me know if > there is anything else that needs to be done for its inclusion in > MacPorts. Thanks. I think you should be using the python24 or python25 portgroup. It would simplify the portfile. Also, we have a python category. Though there are ports that use a python portgroup that aren't in the python category. I don't use python software, so I'm not sure what the rules are there, just wanted to point out that there is such a category. Ports in that category should have names that begin with "py-" (for 2.4) or "py25-" (for 2.5). Perhaps a MacPorts python user can provide guidance on what needs to go in that category and what can be elsewhere. From jmpp at macports.org Mon Jul 9 23:54:04 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:26 2007 Subject: MacPorts 1.5.0 released Message-ID: <4B67483E-6A0B-4E8E-9D37-3438BDB85A63@macports.org> Evening everyone! I am glad to announce that we've finally finished the 1.5.0 edition of MacPorts, readily available through all our regular distribution means: -) binary installer for both 10.4 (Universal) and 10.3, http:// svn.macports.org/repository/macports/downloads/MacPorts-1.5.0/ -) source tarballs, both gz and bz2 formats, same location as above; -) selfupdate. Of all the features and bug fixes in the changelog quoted below, I'd like to point out two in particular: 1) The MacPorts project no longer mixes its old DarwinPorts name with the new one at any level, whether that is in chosen installation paths, file names, strings we output to the user and many more things. This implies that upon installing 1.5.0 several things in a standard MacPorts installation will silently change to new naming and installation locations, as thoroughly detailed in the Wiki page that tracked this work as it was being developed: http://trac.macports.org/ projects/macports/wiki/MacPortsRenaming. Please read it carefully before getting scared about your configuration files or other stuff being missing ;-) 2) Even though still not complete, extensive work on the generation of rpm's off MacPorts Portfiles has pushed forward our ability to generate real binary packages, improving both the building of the rpm tool itself on Mac OS X and the "rpm" MacPorts target (renamed from "rpmpackage") that creates the corresponding rpm files/packages. These packages still need to be generated by users off their own MacPorts installations ("port rpm "), and flawless functionality for each of them is still not guaranteed, unfortunately. For instance, one long standing shortcoming still with us is that rpm installed software (even if the package is generated through MacPorts) is separate from MacPorts installed software, they are still two different universes that don't talk to each other even if installed into the same /opt/local prefix. However, strong developer momentum on the packaging front raises our hope that the goal of providing fully working and ironed out binary packages will be reached eventually! So, without much further ado, enjoy MacPorts 1.5.0! Biggest thanks to all those who worked to produce this solid release, kudos! Regards,... -jmpp PS: Full 1.5.0 ChangeLog following: Release 1.5 (09-July-2007 tagged at r26818 by jmpp): - Many documentation updates and improvements, mostly thanks to Maun Suang and Brian Campbell who both started work on both improving our man pages and reviving the long forgotten MacPorts official guide, now nightly regen'd on an automated basis and hosted at a temporary location, http://geeklair.net/ macports_guide/, all thanks to Daniel J. Luke (dluke). - Improve built-in "daemondo" program logging (jberry r26537 & r26569). - rpm target now knows how to also build universal packages if requested (afb r26470). - The "rpmpackage" target was renamed to "rpm", and a new target "srpm" added that allows packaging a Portfile (and files/distfiles) up as a source package. Upgraded RPM to version 4.4.9 and changed OpenDarwin/ DarwinPorts to MacPorts. The default build location is now ${prefix}/src/macports instead of ${prefix}/src/apple (jmpp & afb in r26465, r26496, r26536, r26543). - Fixed a potential crasher in the delete command (ticket #12149, eridius r26397). - 'port delete --work' now removes $portbuiltpath instead of $workpath, effectively prunning empty dirs that up until now were left behind in the build directory (jmpp r26394). - gnustep portgroup for gnustep-make-2.0 (yves r26266). - Adding backwards compatibility glue for clients of the public (darwin|mac)ports1.0 API that use now deprecated procs naming (DarwinPorts namespace) (jmpp r26392). - Merged the dp2mp-move branch into trunk to finally move away from all DarwinPorts related strings and conventions both internally and externally, implying big changes in MacPorts pathnames with respect to user visible stuff. Read http://trac.macports.org/projects/macports/wiki/ MacPortsRenaming and http://trac.macports.org/projects/macports/log/branches/dp2mp- move/base for more full details and information (jmpp r26177). - Fix livecheck to properly de-escape livecheck.url (eridius r26041). - Add warning when it looks like PortIndex file is corrupt (eridius r26040). - Make portindex use stderr for errors (eridius r26038, ticket #11585). - Fix port variants calculation to properly account for negated variants and to detect problems between required and negated variants (ticket #11920, eridius r26036, patch by gwhitney). - Add global methods lpush, lpop, lshift, and lunshift. Works similar to lappend (in fact lpush is just lappend) and do what they sound like. Also add ldindex. Works like lindex, but deletes the element from the list. Documented in portfile.7 (eridius r26034). - Add global methods try and throw. Implemented based on the specification in TIP #89. Documented in portfile.7 (eridius r25979). - Handle encodings properly now. All Portfiles and .conf files are assumed to be utf-8, and reading them or calling portindex(1) should now work the same on all locales (ticket #11978, eridius r25975). - Add support for decoding of obscured maintainer addresses. We support two types of obscured addresses in Portfile maintainers field: (1) username ==> implies username@macports.org (2) subdomain.tld:username ==> implies username@subdomain.tld These are unobscured by port info, and by port submit during the submission process, but are left obscured in the Portfile to avoid accidental disclosure. (jberry r25795). - Update port.1 to reflect what "port dependents" really does (markd r25787, ticket #11898). - Distinguish a pseudo portname that evaluates to nothing from no arguments at all, improving behavior of 'installed', 'active', 'list', and 'search' pseudo portnames. (jberry in r25789, ticket #10674). - Bugfix startup item generation so that launchd.plists are disabled by default, as we claim they are in our documentation. (jberry r25785). - Update adduser/addgroup to use dscl instead of niutil. Also add support for realname key in addgroup (ticket #11012, eridius r25586). - Make a correction to port(1)'s determination of whether or not a port has been updated by making it compare ${version} and then $ {revision} rather than a single comparison of the compound ${version}_$ {revision}; the latter reports 2.01_2 to be newer than 2.01.01a25_0 because, at the fifth character, `_' comes after `.' in ASCII lexicographic order. (boeyms in r25310) From markd at macports.org Tue Jul 10 00:46:27 2007 From: markd at macports.org (markd@macports.org) Date: Tue Oct 9 16:40:26 2007 Subject: MacPorts 1.5.0 and binary packaging / New improved Guide In-Reply-To: <4B67483E-6A0B-4E8E-9D37-3438BDB85A63@macports.org> References: <4B67483E-6A0B-4E8E-9D37-3438BDB85A63@macports.org> Message-ID: Juan Manuel Palacios on Monday, July 9, 2007 at 11:54 PM -0800 wrote: >2) Even though still not complete, extensive work on the generation >of rpm's off MacPorts Portfiles has pushed forward our ability to >generate real binary packages, improving both the building of the rpm >tool itself on Mac OS X and the "rpm" MacPorts target (renamed from >"rpmpackage") that creates the corresponding rpm files/packages. >These packages still need to be generated by users off their own >MacPorts installations ("port rpm "), and flawless >functionality for each of them is still not guaranteed, >unfortunately. For instance, one long standing shortcoming still with >us is that rpm installed software (even if the package is generated >through MacPorts) is separate from MacPorts installed software, they >are still two different universes that don't talk to each other even >if installed into the same /opt/local prefix. However, strong >developer momentum on the packaging front raises our hope that the >goal of providing fully working and ironed out binary packages will >be reached eventually! I am progressing on the new Guide. I mispoke when I called the new Guide "minimalist", because that implies stuff will be left out. I only intended to streamline and rewrite it (some explanations were verbose and redundant) but leave no material out. I just added all the sections that I think need to be in it and I inserted the contents of "MacPorts Internals" stuff from the old guide too. Shouldn't be long now that all the data will be mined from the old guide. Not that the work is over since improvments will still be needed, but at least we can look forward to those rather than looking backwards and trying to capture what used to be. http://homepage.mac.com/duling/macports/guide.html Comments still welcome on the Guide so far. It needs some color css work and other css formatting, but I'm focusing on content and readability. I don't feel competant to write Section 7, "Packaging Ports into Binaries". Can anyone who understands the packaging process throw some text at me on this topic? Doesn't have to be much or pretty, I can rewrite it but I just something more or less technically accurate to start with. Or point me to a similar section in another package manager if that is possible. I'm just not that familiar with the whole topic and the manpage doesn't say that much. Mark From afb at macports.org Tue Jul 10 05:41:23 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Oct 9 16:40:26 2007 Subject: MacPorts 1.5.0 and binary packaging / New improved Guide In-Reply-To: References: <4B67483E-6A0B-4E8E-9D37-3438BDB85A63@macports.org> Message-ID: <9154377af13b014e6c628926633ef78b@macports.org> markd wrote: > http://homepage.mac.com/duling/macports/guide.html > > Comments still welcome on the Guide so far. It needs some color css > work > and other css formatting, but I'm focusing on content and readability. There are some common typos in it like "OS X" (Mac OS X) and "Xwindows" (X Window System) and it should probably be less Apple/Mac OS X centric (i.e. should mention explicitly that 2.1-2.5 applies to Mac OS X, and say something instead of "Apple-supplied" - like vendor-supplied, etc etc...) It would also be nice if it could mention "open source and free software", instead of just saying "open source Unix software" and not mentioning GNU ? This is IMHO also another reason why it is important to get License metadata into the ports, as it is now you'll have to dig through homepages/licenses. You can look at the old guide for some hints, it uses "third party software" and has much more info on the common heritage with the BSD Ports/