From ryandesign at macports.org Fri Feb 1 09:30:03 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri Feb 1 09:30:08 2008 Subject: [33633] trunk/dports/print/abcm2ps/Portfile In-Reply-To: <20080201151529.B2B6FEE433E@beta.macosforge.org> References: <20080201151529.B2B6FEE433E@beta.macosforge.org> Message-ID: You forgot to commit the rename of the patchfile. $ sudo port install abcm2ps ---> Fetching abcm2ps ---> Attempting to fetch patch-Makefile.in.diff from http:// svn.macports.org/repository/macports/distfiles/abcm2ps ---> Attempting to fetch patch-Makefile.in.diff from http:// svn.macports.org/repository/macports/distfiles/general/ ---> Attempting to fetch patch-Makefile.in.diff from http:// svn.macports.org/repository/macports/downloads/abcm2ps Error: Target org.macports.fetch returned: fetch failed Error: Status 1 encountered during processing. $ On Feb 1, 2008, at 09:15, mww@macports.org wrote: > Revision: 33633 > http://trac.macosforge.org/projects/macports/changeset/33633 > Author: mww@macports.org > Date: 2008-02-01 07:15:26 -0800 (Fri, 01 Feb 2008) > > Log Message: > ----------- > version 5.7.4 > > Modified Paths: > -------------- > trunk/dports/print/abcm2ps/Portfile > > Modified: trunk/dports/print/abcm2ps/Portfile > =================================================================== > --- trunk/dports/print/abcm2ps/Portfile 2008-02-01 14:24:51 UTC > (rev 33632) > +++ trunk/dports/print/abcm2ps/Portfile 2008-02-01 15:15:26 UTC > (rev 33633) > @@ -3,7 +3,7 @@ > PortSystem 1.0 > > name abcm2ps > -version 5.7.3 > +version 5.7.4 > categories print audio > platforms darwin > maintainers mww > @@ -15,8 +15,8 @@ > > homepage http://moinejf.free.fr/ > master_sites ${homepage} > -checksums sha1 f3c8c649c02d387ee1c6174cea00b5dac002ce0d > -patchfiles patch-Makefile.in > +checksums sha1 3e3cf3b5e1bb078027a37bd6e6b965c742641034 > +patchfiles patch-Makefile.in.diff > > build.target From john_owens at yahoo.com Fri Feb 1 14:55:20 2008 From: john_owens at yahoo.com (John Owens) Date: Fri Feb 1 14:55:31 2008 Subject: how to commit ... Message-ID: OK, hate to admit this, but I'm ready to make a change to a portfile and, with the permission of the port maintainer, am ready to check into svn. But I don't know how, and I can't find any docs on macports.org on how to do this. I've used svn before ... What is the server? (svn.macports.org?) What is the path (just /trunk/...)? Log in with my macports id? username or username@macports.org? Is there any way to do this without having to check out a working copy (I'd rather just change a Portfile and the Portindex locally, check it works, and then check in the Portfile back into trunk)? Good doc to have on the wiki. JDO From ryandesign at macports.org Fri Feb 1 15:25:25 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri Feb 1 15:25:25 2008 Subject: how to commit ... In-Reply-To: References: Message-ID: On Feb 1, 2008, at 16:55, John Owens wrote: > OK, hate to admit this, but I'm ready to make a > change to a portfile and, with the permission > of the port maintainer, am ready to check > into svn. But I don't know how, and I can't > find any docs on macports.org on how to do this. > I've used svn before ... > > What is the server? (svn.macports.org?) You can use either of these: http://svn.macports.org/repository/macports http://svn.macosforge.org/repository/macports > What is the path (just /trunk/...)? Ports are in /trunk/dports > Log in with my macports id? username or > username@macports.org? Your macports.org email address. > Is there any way to do this without having > to check out a working copy (I'd rather just > change a Portfile and the Portindex locally, > check it works, and then check in the Portfile > back into trunk)? You don't need to do anything to the portindex. You just need to modify the portfile, test, and when you're sure it works, commit it. You do need a working copy to commit changes to files. Personally I just changed my dports tree from an rsync update to a subversion working copy and use that. Yes, you will be checking in to trunk/ dports. (The dports don't live anywhere except in trunk, and really they belong outside of trunk, but rearranging that at this point is complicated and nobody has felt it worth the effort yet, though jmpp did bring it up at one point.) > Good doc to have on the wiki. I agree we need documentation on this. I'd prefer it in the MacPorts guide, not the wiki. Someone just needs to write it. From john_owens at yahoo.com Fri Feb 1 16:11:11 2008 From: john_owens at yahoo.com (John Owens) Date: Fri Feb 1 16:11:12 2008 Subject: how to commit ... References: Message-ID: Ryan Schmidt writes: + + Is there any way to do this without having + + to check out a working copy (I'd rather just + + change a Portfile and the Portindex locally, + + check it works, and then check in the Portfile + + back into trunk)? + + You don't need to do anything to the portindex. You just need to + modify the portfile, test, and when you're sure it works, commit it. + You do need a working copy to commit changes to files. Personally I + just changed my dports tree from an rsync update to a subversion + working copy and use that. Yes, you will be checking in to trunk/ + dports. (The dports don't live anywhere except in trunk, and really + they belong outside of trunk, but rearranging that at this point is + complicated and nobody has felt it worth the effort yet, though jmpp + did bring it up at one point.) First, can you expand on *exactly* what you do here (rsync->svn), and second, does anyone have any other methods? Good to collect methods that work. :) JDO From ryandesign at macports.org Fri Feb 1 16:29:22 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri Feb 1 16:29:22 2008 Subject: how to commit ... In-Reply-To: References: Message-ID: <8369DE50-0A5E-4BF2-B86C-7E372B68642C@macports.org> On Feb 1, 2008, at 18:11, John Owens wrote: > Ryan Schmidt writes: > > + + Is there any way to do this without having > + + to check out a working copy (I'd rather just > + + change a Portfile and the Portindex locally, > + + check it works, and then check in the Portfile > + + back into trunk)? > + > + You don't need to do anything to the portindex. You just need to > + modify the portfile, test, and when you're sure it works, commit it. > + You do need a working copy to commit changes to files. Personally I > + just changed my dports tree from an rsync update to a subversion > + working copy and use that. Yes, you will be checking in to trunk/ > + dports. (The dports don't live anywhere except in trunk, and really > + they belong outside of trunk, but rearranging that at this point is > + complicated and nobody has felt it worth the effort yet, though jmpp > + did bring it up at one point.) > > First, can you expand on *exactly* what you do here (rsync->svn), > and second, does anyone have any other methods? Good to collect > methods that work. :) In order to commit things to the repository, I need a working copy. I tend to work all over the repository, including my own several dozen ports, tickets for nomaintainer ports, cleanup involving several ports at once, even the occasional change to the documentation, web site or the base code. I checked out the entire trunk to my home directory: svn checkout http://svn.macosforge.org/repository/macports/trunk ~/ macports If you don't plan to work on anything but ports, you can just checkout trunk/dports. Then I edited /opt/local/etc/macports/sources.conf and removed the line rsync://rsync.macports.org/release/ports/ and added the line file:///Users/rschmidt/macports/dports/ Now when I "port sync" it uses my Subversion working copy instead of connecting via rsync. This means I also instantly get changes, instead of having to wait for the rsync server to synchronize itself with the repository, which it only does every 30 minutes. From jmpp at macports.org Sat Feb 2 00:31:54 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Sat Feb 2 00:30:14 2008 Subject: [33639] branches/release_1_6/base/portmgr/dmg/postflight In-Reply-To: <20080202071637.40EC6F08A9D@beta.macosforge.org> References: <20080202071637.40EC6F08A9D@beta.macosforge.org> Message-ID: On Feb 2, 2008, at 2:46 AM, jmpp@macports.org wrote: > Revision > 33639 > Author > jmpp@macports.org > Date > 2008-02-01 23:16:35 -0800 (Fri, 01 Feb 2008) > Log Message > > * Use dscl(1) to detect the default shell for the installing user, > rather than trying to infer it from the inherited environment > (which did not reflect the user's at all, as it is entirely > imposed by Installer.app when the pkg is used in real life). Thanks > to Ryan on macports-dev for the original suggestion! > > * Provide a little more information about the shell we detected. > > NOTE: I tested this edited script through a test pkg on Leopard and > it works, both when used from an account with a bash shell and > from one with a tcsh shell. If anyone cares to test on Tiger and/or > Panther, they should contact me so I can hand them the pkg, thanks! > In any case, I'm feeling confident it'll work consistently this time > round to detect the shell type, given the nature of the dscl > operation. As you can see from the diff in this commit, I used an alternate method to get the sole shell name (awk). But in any case, the all work and produce the same output, as discussed on IRC earlier today, it's only a matter of taste. I've put together a test dmg that has the latest /branches/ release_1_6/base/portmgr/dmg/postflight in it, available at the following URL: http://apollo.homeunix.net/macports/downloads/MacPorts-1.6.1.dmg Appreciate it if anyone has a chance to help me test it, per my commit log above. Tiger and Panther reports would be great! Regards,... -jmpp PS: Note that the MacPorts code in the installer is not necessarily what 1.6.1 final will be, I exported a tarball off the branch some days ago (so it's definitely not current wrt trunk and may even not be current wrt the branch itself. I'm only interested here in the behavior of the postflight script when run from within Installer.app (which is what was crippling the $SHELL evn variable detection). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080202/304ef874/attachment-0001.html From ryandesign at macports.org Sat Feb 2 08:11:47 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat Feb 2 08:11:45 2008 Subject: [33653] trunk/dports/net/psi/Portfile In-Reply-To: <20080202160143.3C0A2F1B93C@beta.macosforge.org> References: <20080202160143.3C0A2F1B93C@beta.macosforge.org> Message-ID: <325CFE97-7F6A-4D0E-884A-F1FB1C8D733A@macports.org> Looks like you didn't commit the patchfiles. $ sudo port checksum psi +plugins ---> Fetching psi ---> Attempting to fetch patch-src_about.ui from http:// svn.macports.org/repository/macports/distfiles/psi ---> Attempting to fetch patch-src_about.ui from http:// svn.macports.org/repository/macports/distfiles/general/ ---> Attempting to fetch patch-src_about.ui from http:// svn.macports.org/repository/macports/downloads/psi Error: Target org.macports.fetch returned: fetch failed Error: Status 1 encountered during processing. $ Also, the patchfile names aren't up to code. $ sudo port lint psi +plugins ---> Verifying Portfile for psi Warning: Line 4 should be a newline (after PortSystem) Warning: Patchfile patch-src_about.ui does not follow the source patch naming policy "patch-*.diff" Warning: Patchfile patch-src_psiaccount.cpp does not follow the source patch naming policy "patch-*.diff" Warning: Patchfile patch-src_pluginmanager.cpp does not follow the source patch naming policy "patch-*.diff" Warning: Patchfile patch-src_psiplugin.h does not follow the source patch naming policy "patch-*.diff" Warning: Patchfile patch-src_pluginmanager.h does not follow the source patch naming policy "patch-*.diff" Warning: Patchfile patch-configure does not follow the source patch naming policy "patch-*.diff" ---> 0 errors and 7 warnings found. $ On Feb 2, 2008, at 10:01, rowue@macports.org wrote: > Revision: 33653 > http://trac.macosforge.org/projects/macports/changeset/33653 > Author: rowue@macports.org > Date: 2008-02-02 08:01:42 -0800 (Sat, 02 Feb 2008) > > Log Message: > ----------- > Added variant bundledqca for use of bundled qca and > variant plugins for use of experimental plugin feature > > Modified Paths: > -------------- > trunk/dports/net/psi/Portfile > > Modified: trunk/dports/net/psi/Portfile > =================================================================== > --- trunk/dports/net/psi/Portfile 2008-02-02 15:42:56 UTC (rev 33652) > +++ trunk/dports/net/psi/Portfile 2008-02-02 16:01:42 UTC (rev 33653) [snip] > +variant plugins description {Build with experimental Plugin > Support} { > + > +patchfiles-append patch-src_about.ui \ > + patch-src_psiaccount.cpp \ > + patch-src_pluginmanager.cpp \ > + patch-src_psiplugin.h \ > + patch-src_pluginmanager.h \ > + patch-configure > + > +configure.args-append --enable-plugins > +} From blb at macports.org Sat Feb 2 14:49:58 2008 From: blb at macports.org (Bryan Blackburn) Date: Sat Feb 2 14:49:49 2008 Subject: macports-users list dead? Message-ID: <7A0BE1AE-11B5-4880-AADC-375C58693470@macports.org> I haven't seen any mail on macports-users since the 29th of January; also, the archives[1] appear to stop at that same day, so I don't think it's an issue with my delivery alone. Bryan [1] - From wsiegrist at apple.com Sat Feb 2 15:10:51 2008 From: wsiegrist at apple.com (William Siegrist) Date: Sat Feb 2 15:11:38 2008 Subject: macports-users list dead? In-Reply-To: <7A0BE1AE-11B5-4880-AADC-375C58693470@macports.org> References: <7A0BE1AE-11B5-4880-AADC-375C58693470@macports.org> Message-ID: <6B6026BD-EB0B-46E0-B6D9-DA5EB3407887@apple.com> I'm looking into it. Thanks for reporting it. -Bill On Feb 2, 2008, at 2:49 PM, Bryan Blackburn wrote: > I haven't seen any mail on macports-users since the 29th of January; > also, the archives[1] appear to stop at that same day, so I don't > think it's an issue with my delivery alone. > > Bryan > > [1] - > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev ---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist@apple.com 408 862 7337 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080202/addc8b6d/smime.bin From wsiegrist at apple.com Sat Feb 2 15:16:46 2008 From: wsiegrist at apple.com (William Siegrist) Date: Sat Feb 2 15:18:10 2008 Subject: macports-users has been fixed Message-ID: <8679795E-98A7-4B6A-9C52-4E2966C20D0A@apple.com> Sorry for the oversight, there was a mis-set permission on the server for macports-users. All the mail got deferred and has now been delivered. -Bill ---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist@apple.com 408 862 7337 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080202/1cc2b02a/smime.bin From raimue at macports.org Sat Feb 2 15:30:18 2008 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Sat Feb 2 15:30:06 2008 Subject: [MacPorts] #14147: port lint should warn on illegal variant names In-Reply-To: <053.4b145f8a8af98acab9f723253e3458f4@macosforge.org> References: <053.4b145f8a8af98acab9f723253e3458f4@macosforge.org> Message-ID: <47A4FD0A.5070405@macports.org> MacPorts wrote: > #14147: port lint should warn on illegal variant names > -------------------------------------+-------------------------------------- > Reporter: ryandesign@macports.org | Owner: macports-tickets@lists.macosforge.org > Type: enhancement | Status: new > Priority: Normal | Milestone: MacPorts base enhancements > Component: ports | Version: 1.7.0 > Keywords: | > -------------------------------------+-------------------------------------- > `port lint` should warn when it encounters variants whose names are not > composed entirely of legal characters. I'm not sure if the list of legal > characters for variant names has ever been defined anywhere before, but > looking through all variant names of all ports right now, I see that they > are all composed of letters A-Z and a-z, numbers 0-9, underscore and > hyphen/dash, and the hyphen/dash is the only one of those that causes > problems. (A variant with a hyphen/dash in the name cannot be selected.) > So `port lint` should warn if a variant name does not match the regular > expression `^[A-Za-z0-9_]+$` > > Related: the guide should say something about valid variant names; see > #14141. In ''proc variant'' itself are no checks at all, the first argument ("provides") is taken as the variant name (see port1.0/portutil.tcl, proc variant {args}). But in other places there are checks for validity. port1.0/portutil.tcl, handle_default_variants: if {[regexp {([-+])([-A-Za-z0-9_]+)} $v whole val variant]} { port/port.tcl, split_variants: set l [regexp -all -inline -- {([-+])([[:alpha:]_]+[\w\.]*)} $variants] If there should be no hyphens/dashes in variant names, the regex in the ticket is correct and the one in handle_default_variants is wrong. I am unsure if I understand the regex in split_variants correctly... Maybe they should be unified to a single regex for variant names which can be used in multiple places. Rainer From ryandesign at macports.org Sat Feb 2 16:15:58 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat Feb 2 16:15:57 2008 Subject: *-devel ports Message-ID: <92E586B9-4F46-47FE-9935-A7F903614C2F@macports.org> The guide needs to say something (quite a lot, actually) about *- devel ports. The only thing it currently says is: "Non-port dependencies should only be used if the application or library can be installed by multiple ports (for example stable and - devel version) or if it can't be installed with MacPorts." There's a lot of room for confusion with the *-devel ports so it needs to be properly documented. I want to file a ticket for this request, but before I do, we should make sure we know what we want the guide to say about the topic. Let me just ramble for a bit on how I think *-devel ports work and how they should be used. Maybe someone with an official hat on can respond and say where I've got it right or wrong. *-DEVEL PORTS ============= Some ports may have a development version available, which installs a pre-release version of the software, instead of a stable version. The name of such a port will end with the suffix "-devel", so for example the port php5 installs the latest released version of PHP 5 while php5-devel installs a development, alpha, beta or release candidate version. Most users will not need to use -devel ports, but if the latest stable version does not include a feature or bugfix that you need, and the latest development version does, you may want to use the -devel port instead. Warning: -devel ports by definition install software which is not necessarily of release quality and has not necessarily been exhaustively tested. Software installed by -devel ports may not work properly and should not be used in production systems. Note: MacPorts uses -devel ports for an entirely different purpose than some other package managers (e.g. Linux? FreeBSD? not sure). In those other package managers, a port foo-devel would contain the headers necessary for other software to link with foo. But in MacPorts, these headers are already part of the foo port. To create a -devel port, copy the regularly-named port and change it minimally to install the development version instead. Always keep the two ports as similar as possible. If you fix a bug, add a feature or make formatting changes in one port, don't forget to make the same changes in the other port. So that the ports can be kept similar, it's best if the regular port and the -devel port are maintained by the same person. Or, two developers can co-maintain both ports. If you would like to create and maintain a -devel version of a port which is maintained by someone else, coordinate with the other maintainer first. Invite them to co-maintain your -devel port, and ask if you can co-maintain their port. A -devel port should install software into the exact same locations as the regularly-named port. Thus, it is not possible to install both foo and foo-devel at the same time. You must pick one or the other. Sometimes a port foo-devel will install a newer version of the software than foo, and this is a reason why you might want to use the port foo-devel, to test a new version of the software before it's released. However, after the new version is released, foo will be installing a newer version of the software than foo-devel. If you have foo-devel installed, you will not be notified if and when a newer version is provided by foo. To get that newer version, you will need to uninstall foo-devel and install foo. (I don't especially like all this, but this is the way it is, so this is the way it should be documented. Changing this behavior should be the topic of a separate discussion.) No port should depend on a -devel version of a port, unless it will only work with the -devel version. Usually this will not be the case. Usually, a port will work with the current version of a port and the latest development version. A port wanting to accommodate this situation should use a different syntax for declaring the dependency. For example, php5 can use the MySQL libraries, but works fine with either mysql5 or mysql5-devel. Instead of declaring the dependency as "port:mysql5", php5 should depend on a specific file installed by both mysql5 and mysql5-devel, like this: "path:${prefix}/bin/ mysql_config5:mysql5". This says that php5 requires the file mysql_config5 to exist in the MacPorts install prefix bin directory, and if it does not exist, then install the mysql5 port. If the user wishes to use mysql5-devel instead, he simply installs mysql5-devel beforehand, then installs php5, and php5 will recognize that mysql5- devel satisfies the dependency. (I know php5 does not do this yet; this is ticket #13469.) From raimue at macports.org Sat Feb 2 16:49:44 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat Feb 2 16:49:32 2008 Subject: *-devel ports In-Reply-To: <92E586B9-4F46-47FE-9935-A7F903614C2F@macports.org> References: <92E586B9-4F46-47FE-9935-A7F903614C2F@macports.org> Message-ID: <47A50FA8.9030708@macports.org> Ryan Schmidt wrote: > No port should depend on a -devel version of a port, unless it will only > work with the -devel version. Usually this will not be the case. > Usually, a port will work with the current version of a port and the > latest development version. A port wanting to accommodate this situation > should use a different syntax for declaring the dependency. For example, > php5 can use the MySQL libraries, but works fine with either mysql5 or > mysql5-devel. Instead of declaring the dependency as "port:mysql5", php5 > should depend on a specific file installed by both mysql5 and > mysql5-devel, like this: "path:${prefix}/bin/mysql_config5:mysql5". This > says that php5 requires the file mysql_config5 to exist in the MacPorts > install prefix bin directory, and if it does not exist, then install the > mysql5 port. If the user wishes to use mysql5-devel instead, he simply > installs mysql5-devel beforehand, then installs php5, and php5 will > recognize that mysql5-devel satisfies the dependency. (I know php5 does > not do this yet; this is ticket #13469.) This is just not good behaviour. Instead of defining dependencies on single files we should find a way to eventually support multiple versions per port. With this, php5 could depend on port:mysql5 and the mysql5 port provides stable or unstable. But it should not be limitde to just a few hardcoded versions. It should be possible to provide as many versions as needed for a single port. Multiple port version could share some basics like name, homepage, description, variants and so on in a single file. In my opinion if a port provides the same files and installs the same software (but in another version) it should be the same port. Even more, we could extend the dependency syntax and allow depending on versions. Examples: port:foo@>=1.0 (depend on any greater version) port:foo@=1.1 (depend exactly on a specific version) port:foo@<2.0 (depend on an earlier version) Basically, any of <, <=, =, >=, > should be possible. It could also become possible to require specific variants with some syntax. I know, there would be a lot of base work needed for something like this to be fully usable, but I think it would be the best solution for the future to solve all the problems with -devel ports. Rainer From ryandesign at macports.org Sat Feb 2 17:08:30 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat Feb 2 17:08:27 2008 Subject: *-devel ports In-Reply-To: <47A50FA8.9030708@macports.org> References: <92E586B9-4F46-47FE-9935-A7F903614C2F@macports.org> <47A50FA8.9030708@macports.org> Message-ID: <19CDBDE4-004A-4DE3-BE2A-2276902D4A6B@macports.org> On Feb 2, 2008, at 18:49, Rainer M?ller wrote: > Ryan Schmidt wrote: > >> No port should depend on a -devel version of a port, unless it >> will only work with the -devel version. Usually this will not be >> the case. Usually, a port will work with the current version of a >> port and the latest development version. A port wanting to >> accommodate this situation should use a different syntax for >> declaring the dependency. For example, php5 can use the MySQL >> libraries, but works fine with either mysql5 or mysql5-devel. >> Instead of declaring the dependency as "port:mysql5", php5 should >> depend on a specific file installed by both mysql5 and mysql5- >> devel, like this: "path:${prefix}/bin/mysql_config5:mysql5". This >> says that php5 requires the file mysql_config5 to exist in the >> MacPorts install prefix bin directory, and if it does not exist, >> then install the mysql5 port. If the user wishes to use mysql5- >> devel instead, he simply installs mysql5-devel beforehand, then >> installs php5, and php5 will recognize that mysql5-devel satisfies >> the dependency. (I know php5 does not do this yet; this is ticket >> #13469.) > > This is just not good behaviour. Instead of defining dependencies > on single files we should find a way to eventually support multiple > versions per port. With this, php5 could depend on port:mysql5 and > the mysql5 port provides stable or unstable. But it should not be > limitde to just a few hardcoded versions. It should be possible to > provide as many versions as needed for a single port. > Multiple port version could share some basics like name, homepage, > description, variants and so on in a single file. > > In my opinion if a port provides the same files and installs the > same software (but in another version) it should be the same port. > > Even more, we could extend the dependency syntax and allow > depending on versions. > Examples: > port:foo@>=1.0 (depend on any greater version) > port:foo@=1.1 (depend exactly on a specific version) > port:foo@<2.0 (depend on an earlier version) > > Basically, any of <, <=, =, >=, > should be possible. It could also > become possible to require specific variants with some syntax. > > I know, there would be a lot of base work needed for something like > this to be fully usable, but I think it would be the best solution > for the future to solve all the problems with -devel ports. In this thread, I am not looking to solve any problems that may exist with -devel ports. Rather, I'm trying to find the right words to describe the way that -devel ports currently work and should be used, so that I can make a ticket that requests that this be added to the guide. If any of what I wrote does not accurately describe the way - devel ports work or should be used, please let me know. From afb at macports.org Sun Feb 3 03:01:49 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun Feb 3 03:01:35 2008 Subject: *-devel ports In-Reply-To: <92E586B9-4F46-47FE-9935-A7F903614C2F@macports.org> References: <92E586B9-4F46-47FE-9935-A7F903614C2F@macports.org> Message-ID: <7f03580f598e3a7a66a3a916307b73b3@macports.org> Ryan Schmidt wrote: > Note: MacPorts uses -devel ports for an entirely different purpose > than some other package managers (e.g. Linux? FreeBSD? not sure). In > those other package managers, a port foo-devel would contain the > headers necessary for other software to link with foo. The MacPorts usage of "-devel" suffix for development releases was inherited from the FreeBSD Ports collection. RPM instead uses -devel to signify development packages (headers/libraries), while DEB uses a -dev suffix similarly. See http://www.freebsd.org/ports/ (and compare with http://www.macports.org/ports.php) > But in MacPorts, these headers are already part of the foo port. This is a current shortcoming / simplification in MacPorts. Eventually it needs to support such subpackages or "SplitOffs", as they are necessary in order to make for more fine-grained binary packaging and dependency resolution. Fink uses http://www.finkproject.org/doc/packaging/reference.php? phpLang=en#splitoffs --anders From ramercer at gmail.com Sun Feb 3 17:04:55 2008 From: ramercer at gmail.com (Adam Mercer) Date: Sun Feb 3 17:04:35 2008 Subject: [33397] trunk/dports/gnome/inkscape/Portfile In-Reply-To: <20080126080446.93771C9D5FB@beta.macosforge.org> References: <20080126080446.93771C9D5FB@beta.macosforge.org> Message-ID: <799406d60802031704t225f1ad5x7f227c0ab915c9f4@mail.gmail.com> On Jan 26, 2008 3:04 AM, wrote: > Revision 33397 Author gui_dos@macports.org Date 2008-01-26 00:03:38 -0800 > (Sat, 26 Jan 2008) > Log Message Comment out the dependency on py25-numpy because > the compilation of the whole gcc42 is required at > the moment linking with g95 has been fixed so it is again the default fortran compiler for py25-numpy Cheers Adam From randall.h.wood at alexandriasoftware.com Sun Feb 3 05:06:32 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Sun Feb 3 19:23:27 2008 Subject: Not installed as an image? Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Portfile Type: application/octet-stream Size: 891 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080203/fe83a84b/Portfile-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: install.log Type: application/octet-stream Size: 352313 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080203/fe83a84b/install-0001.obj From evenson at panix.com Mon Feb 4 00:22:36 2008 From: evenson at panix.com (Mark Evenson) Date: Mon Feb 4 00:22:33 2008 Subject: Updated Portfile for 'lang/slime' attached to ticket 14136 Message-ID: <47A6CB4C.6080107@panix.com> As maintainer of the 'lang/slime' port I have created an essentially reworked Portfile attached to ticket [14136][1] which: * updates the SLIME sources to CVS HEAD of 20080203, which reflects the major refactoring into a 'contrib' subdirectory that occured in the last couple of months * now has an 'app' variant that will install with the 'emacs-app' port (thanks to Jamison Hope for the initial patch) * removed the obsolescent 'devel' variant ('emacs-devel' is no longer in the MacPorts trunk * updated style to comply with what is outlined in http://guide.macports.org/#development.practices (no tabs, 4 column indents, Emacs/vim initial modeline) * rewrote the sample '.emacs' initialization code message to conform with the new style enabling SLIME to more easily serve as the frontend to multiple Lisp (or with varying commandline options) [1]: http://trac.macosforge.org/projects/macports/ticket/14136 Could someone please commit the Portfile? Mark (who is a maintainer, but doesn't have commit rights, even though he is subscribed to the very chatty macports-change list, and is marked as the maintainer of 'lang/slime' and 'lang/nxml-mode', and wouldn't mind terribly if somebody wanted to change that situation). From ebgssth at gmail.com Mon Feb 4 04:51:56 2008 From: ebgssth at gmail.com (js) Date: Mon Feb 4 04:57:59 2008 Subject: *-devel ports In-Reply-To: <92E586B9-4F46-47FE-9935-A7F903614C2F@macports.org> References: <92E586B9-4F46-47FE-9935-A7F903614C2F@macports.org> Message-ID: What's happen after -devel port get officially released? are they removed from svn? On Feb 3, 2008 9:15 AM, Ryan Schmidt wrote: > The guide needs to say something (quite a lot, actually) about *- > devel ports. The only thing it currently says is: > > "Non-port dependencies should only be used if the application or > library can be installed by multiple ports (for example stable and - > devel version) or if it can't be installed with MacPorts." > > There's a lot of room for confusion with the *-devel ports so it > needs to be properly documented. I want to file a ticket for this > request, but before I do, we should make sure we know what we want > the guide to say about the topic. Let me just ramble for a bit on how > I think *-devel ports work and how they should be used. Maybe someone > with an official hat on can respond and say where I've got it right > or wrong. > > > *-DEVEL PORTS > ============= > > Some ports may have a development version available, which installs a > pre-release version of the software, instead of a stable version. The > name of such a port will end with the suffix "-devel", so for example > the port php5 installs the latest released version of PHP 5 while > php5-devel installs a development, alpha, beta or release candidate > version. Most users will not need to use -devel ports, but if the > latest stable version does not include a feature or bugfix that you > need, and the latest development version does, you may want to use > the -devel port instead. > > Warning: -devel ports by definition install software which is not > necessarily of release quality and has not necessarily been > exhaustively tested. Software installed by -devel ports may not work > properly and should not be used in production systems. > > Note: MacPorts uses -devel ports for an entirely different purpose > than some other package managers (e.g. Linux? FreeBSD? not sure). In > those other package managers, a port foo-devel would contain the > headers necessary for other software to link with foo. But in > MacPorts, these headers are already part of the foo port. > > To create a -devel port, copy the regularly-named port and change it > minimally to install the development version instead. Always keep the > two ports as similar as possible. If you fix a bug, add a feature or > make formatting changes in one port, don't forget to make the same > changes in the other port. > > So that the ports can be kept similar, it's best if the regular port > and the -devel port are maintained by the same person. Or, two > developers can co-maintain both ports. If you would like to create > and maintain a -devel version of a port which is maintained by > someone else, coordinate with the other maintainer first. Invite them > to co-maintain your -devel port, and ask if you can co-maintain their > port. > > A -devel port should install software into the exact same locations > as the regularly-named port. Thus, it is not possible to install both > foo and foo-devel at the same time. You must pick one or the other. > > Sometimes a port foo-devel will install a newer version of the > software than foo, and this is a reason why you might want to use the > port foo-devel, to test a new version of the software before it's > released. However, after the new version is released, foo will be > installing a newer version of the software than foo-devel. If you > have foo-devel installed, you will not be notified if and when a > newer version is provided by foo. To get that newer version, you will > need to uninstall foo-devel and install foo. (I don't especially like > all this, but this is the way it is, so this is the way it should be > documented. Changing this behavior should be the topic of a separate > discussion.) > > No port should depend on a -devel version of a port, unless it will > only work with the -devel version. Usually this will not be the case. > Usually, a port will work with the current version of a port and the > latest development version. A port wanting to accommodate this > situation should use a different syntax for declaring the dependency. > For example, php5 can use the MySQL libraries, but works fine with > either mysql5 or mysql5-devel. Instead of declaring the dependency as > "port:mysql5", php5 should depend on a specific file installed by > both mysql5 and mysql5-devel, like this: "path:${prefix}/bin/ > mysql_config5:mysql5". This says that php5 requires the file > mysql_config5 to exist in the MacPorts install prefix bin directory, > and if it does not exist, then install the mysql5 port. If the user > wishes to use mysql5-devel instead, he simply installs mysql5-devel > beforehand, then installs php5, and php5 will recognize that mysql5- > devel satisfies the dependency. (I know php5 does not do this yet; > this is ticket #13469.) > > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev > From ryandesign at macports.org Mon Feb 4 05:41:25 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Feb 4 05:41:22 2008 Subject: [33738] trunk/dports/databases/postgresql83 In-Reply-To: <20080204130826.5938BF6AC66@beta.macosforge.org> References: <20080204130826.5938BF6AC66@beta.macosforge.org> Message-ID: <81C6AF51-C8E3-4669-80EC-28809CD03970@macports.org> On Feb 4, 2008, at 07:08, mww@macports.org wrote: > -#livecheck.check regex > -#livecheck.url ${homepage} > -#livecheck.regex v(8.3.\[0-9\]+) > -livecheck.check regex > -livecheck.url http://www.postgresql.org/ftp/source/ > -livecheck.regex v(8.3RC\[2-9\]) > +livecheck.check regex > +livecheck.url ${homepage} > +livecheck.regex v(8.3.\[0-9\]+) The livecheck regex isn't really accurate... you want: livecheck.regex v(8\\.3\\.\[0-9\]+) From ryandesign at macports.org Mon Feb 4 05:52:44 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Feb 4 05:52:41 2008 Subject: *-devel ports In-Reply-To: References: <92E586B9-4F46-47FE-9935-A7F903614C2F@macports.org> Message-ID: <962BF62E-5D29-4D91-A7E1-422C5FEBEF16@macports.org> On Feb 4, 2008, at 06:51, js wrote: > What's happen after -devel port get officially released? > are they removed from svn? Some maintainers do that. I think most just leave the -devel ports around. For example, the php5-devel port is currently at version 5.2.5RC2 while the php5 port is at version 5.2.5 (the final released version). So in this case, php5 is newer than php5-devel. But once a release candidate of 5.2.6 is available, php5-devel will probably be updated, and will then be newer than php5 again. From vincent-opdarw at vinc17.org Mon Feb 4 06:56:12 2008 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Mon Feb 4 06:56:06 2008 Subject: *-devel ports In-Reply-To: <962BF62E-5D29-4D91-A7E1-422C5FEBEF16@macports.org> References: <92E586B9-4F46-47FE-9935-A7F903614C2F@macports.org> <962BF62E-5D29-4D91-A7E1-422C5FEBEF16@macports.org> Message-ID: <20080204145612.GG17147@prunille.vinc17.org> On 2008-02-04 07:52:44 -0600, Ryan Schmidt wrote: > On Feb 4, 2008, at 06:51, js wrote: >> What's happen after -devel port get officially released? >> are they removed from svn? > > Some maintainers do that. I think most just leave the -devel ports > around. I think that both choices are a bad idea, i.e. that -devel ports are a bad idea. IMHO, there should be stable ports and "latest" ports; by "latest", I mean with all the latest features (e.g. with the highest version number): in general, this is a development version, but for some periods of time, this can be (stable or not) releases, in which case the stable port and the "latest" can sometimes be the same. This is not a problem, and this avoids the user having to switch between the stable and the -devel port; and there's no point to stay with an outdated RC once the corresponding release has been done. -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From nox at macports.org Mon Feb 4 08:34:13 2008 From: nox at macports.org (N_Ox) Date: Mon Feb 4 08:34:05 2008 Subject: Variants handling: my $0.02. Message-ID: Hello there, One thing that is great about MacPorts is to be able to customise ports with variants. But there is two problems with them, I've thought about 2 new syntaxes to handle these problems. First, when a variant actually does something only when it is DISABLED, you would usually need to write: variant some_variant {} post-patch { if {![variant_isset some_variant]} { # Do something } } Why wouldn't we just write: variant -some_variant { post-patch { # Do something } } Now, what if we want to do something when the variant is enabled, and something else when it is disabled? Why won't we write that: variant some_variant { # Do something } else { # something else } Isn't that neat? These two sugar syntaxes would make the variant writing process cleaner. But maybe they could help us more... Let's say the variants which do something only when they are disabled (variant -some_variant) are always enabled by default. In this setup, `sudo port install some_port +another_variant` would install some_port @some_version+another_variant+some_variant. In the registry, we would save "some_variant another_variant" as the list of selected variants. Now, let's explicitely disable the variant: sudo port install some_port -some_variant +another_variant. In the registry, we would save "-some_variant another_variant". Then, on upgrade, we would just have to compare the name of the variant in the portfile (-some_variant) with each item of the list of selected variants to check whether or not we should enable it. No need to use default_variants. No more "Why the hell this variant is enabled when I upgrade this port?" whining. No more "no_x11" variant: variant -x11 { # no x11 } else { # x11 } But maybe all of this is just a "No more alive nerve cells in my brain." Regards, -- Anthony Ramine, the "Ports tree cleaning Maestro". From raimue at macports.org Mon Feb 4 09:13:18 2008 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Mon Feb 4 09:13:02 2008 Subject: Marking default variants (was: [MacPorts] #14178: Feature Request: show default_variants in "port variants foobar") In-Reply-To: <048.bb2e35ac771ae67b9d76bab86f526b8a@macosforge.org> References: <048.bb2e35ac771ae67b9d76bab86f526b8a@macosforge.org> Message-ID: <47A747AE.7040709@macports.org> MacPorts wrote: > #14178: Feature Request: show default_variants in "port variants foobar" > --------------------------------+------------------------------------------- > Reporter: themolok@gmail.com | Owner: macports-tickets@lists.macosforge.org > Type: enhancement | Status: new > Priority: Normal | Milestone: > Component: base | Version: 1.6.0 > Keywords: | > --------------------------------+------------------------------------------- > I tried to write a patch for it, but I failed (I never wrote a single line > of tcl, and I'm a pretty lame programmer), anyway, I think it's really > trivial for who knows the port (the tcl script) codebase. > > Now, for example, "port variants git-core" returns (note that doc is in > default_variants): > {{{ > git-core has the variants: > universal > doc: Install HTML and plaintext documentation > svn: Bi-directional subversion repository support > }}} > > I'd like to have something like: > {{{ > git-core has the variants: > universal > doc: Install HTML and plaintext documentation (default) > svn: Bi-directional subversion repository support > }}} I also thought about marking default variants some time ago, but I think this should not only be added to port variants, but also to port info. Where the latter will be more difficult, as default_variants are currently not stored in PortIndex. It would be good to e.g. mark them with a star. git-core 1.5.3.7, devel/git-core (Variants: universal, *doc, svn) And this could also be used for port variants. git-core has the variants: universal *doc: Install HTML and plaintext documentation svn: Bi-directional subversion repository support I don't like that (default) behind the description as it is not clear if it is part of the description or not. The star (or another symbol) could also be behind the variants name, that's open for discussion. That's why I put this up on macports-dev@ instead of adding a comment to the ticket. Rainer From raimue at macports.org Mon Feb 4 09:13:54 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon Feb 4 09:13:36 2008 Subject: Variants handling: my $0.02. In-Reply-To: References: Message-ID: <47A747D2.6000602@macports.org> N_Ox wrote: > These two sugar syntaxes would make the variant writing process cleaner. > But maybe they could help us more... > > Let's say the variants which do something only when they are disabled > (variant -some_variant) are always enabled by default. > In this setup, `sudo port install some_port +another_variant` would > install some_port @some_version+another_variant+some_variant. > > In the registry, we would save "some_variant another_variant" as the > list of selected variants. > > Now, let's explicitely disable the variant: sudo port install some_port > -some_variant +another_variant. > In the registry, we would save "-some_variant another_variant". Should the selection of -some_variant be user visible or just stored internal? port installed some_port 1) some_port@1.0+another_variant-some_variant 2) some_port@1.0+another_variant The main problem about default_variants in it's current implementation is that we don't store disabled variants and re-select them on upgrade... > No need to use default_variants. So how would I tell that a +variant is default? E.g. the lynx port provides support for OpenSSL (+ssl) and GNU TLS (+gnutls). They are conflicting variants, with +ssl in default_variants. But the user has the choice to install it with GNU TLS by using -ssl +gnutls. But how would I write that in the new syntax? > No more "Why the hell this variant is enabled when I upgrade this port?" > whining. > No more "no_x11" variant: > > variant -x11 { > # no x11 > } else { > # x11 > } And which of those will be the default...? You said -some_variant will be enabled by default, or did I understand that wrong? In which cases will -some_variant be enabled by defaul? If it got no else-block? I think that will end up more complex than it currently is... Also, what is the difference between these and which one is a default variant? variant foo { # do something } variant -bar { # do something } else { # do something } variant -baz { # do something } What if we add some new flag? I like the idea of variant -some_variant, but maybe we could also add a default keyword which says if this variant is going to be installed by default. Like this: variant x11 description {Install X11 support} default { # x11 } else { # no x11 } I like the overall idea to simplify the default variants handling! Rainer From ryandesign at macports.org Mon Feb 4 09:27:24 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Feb 4 09:27:21 2008 Subject: *-devel ports In-Reply-To: <20080204145612.GG17147@prunille.vinc17.org> References: <92E586B9-4F46-47FE-9935-A7F903614C2F@macports.org> <962BF62E-5D29-4D91-A7E1-422C5FEBEF16@macports.org> <20080204145612.GG17147@prunille.vinc17.org> Message-ID: <634664F9-BC97-42C7-98DA-5450F0FF27AF@macports.org> On Feb 4, 2008, at 08:56, Vincent Lefevre wrote: > On 2008-02-04 07:52:44 -0600, Ryan Schmidt wrote: > >> On Feb 4, 2008, at 06:51, js wrote: >> >>> What's happen after -devel port get officially released? >>> are they removed from svn? >> >> Some maintainers do that. I think most just leave the -devel ports >> around. > > I think that both choices are a bad idea, i.e. that -devel ports are > a bad idea. Ok, but we have them, and this thread wasn't really to debate that, but to document the current status quo. > IMHO, there should be stable ports and "latest" ports; by > "latest", I mean with all the latest features (e.g. with the highest > version number): in general, this is a development version, but for > some periods of time, this can be (stable or not) releases, in which > case the stable port and the "latest" can sometimes be the same. This > is not a problem, and this avoids the user having to switch between > the stable and the -devel port; and there's no point to stay with an > outdated RC once the corresponding release has been done. I have no objection to the idea that *-devel ports should be updated to the latest stable version, if no later development version is available. Should we make this policy? Portmgr? Anyone? Regarding the suggestion to rename all *-devel ports to *-latest, in light of the above change, the name "latest" would indeed seem to be clearer. It would also remove any potential confusion with the RPM - devel packages, which IMHO would be quite a good thing. I guess this is as good a time as any to bring up the "tin" ports: $ port search ^tin$ ^tin- tin news/tin 1.8.3 A threaded NNTP and spool based UseNet newsreader tin-devel news/tin-devel 1.7.10 A threaded NNTP and spool based UseNet newsreader tin-recent news/tin-recent 1.9.2 A Usenet newsreader $ Now, ignore the version numbers shown for a minute. Based on comments in the header of "tin-recent" (copied below), it seems to be the maintainer's intention (hey, that's you, Vincent!) that "tin" is the latest released version, "tin-devel" is the latest development version, and "tin-recent" is the more recent of the two. It looks like someone has updated tin-recent but forgotten to update tin- devel. So, to match Vincent's new proposals, "tin-devel" gets deleted and "tin-recent" gets renamed to "tin-latest", yes? # The Tin development model is based on patchsets, as indicated in # the doc/CHANGES file. There are: # * stable patches, numbered ddd (001, 002, and so on), which are # applied to the current stable branch, and in general, to the # unstable branch too (i.e. when there is one and when this makes # sense); # * unstable patches (new features), numbered Uddd (U001, U002, # and so on), which are applied to the unstable branch only. # In general, at some point in the time, there are two currently # supported branches: a stable branch (e.g. 1.6) and an unstable # branch (e.g. 1.7). At some later point (i.e. after a feature # freeze?), the development line (coming from the unstable branch) # is regarded as stable; this leads to a new stable release (e.g. # 1.8.0) and a new stable branch (e.g. 1.8). At this point, the # old stable branch (e.g. 1.6) is abandonned. Then the new stable # branch (1.8) gets stable patches as usual (fixes, translation # updates...), leading to new stable releases (e.g. 1.8.1), which # correspond to the latest unstable release (e.g. 1.7.10) + bug # fixes. As soon as the first unstable patch (U001) needs to be # applied, a new unstable branch (e.g. 1.9) is created (split from # the current stable branch). # Portfile update policy: Follow the development line as shown on # , preferring unstable versions # to stable ones when there is a split, i.e. stay on the right. # The goal of this tin-recent port (as opposed to tin and tin-devel) # is to have the highest upstream version (regarded as either stable # or unstable), i.e. with the latest features, using a single port, # thus benefiting from some port management features, such as those # provided by "port outdated" and "port upgrade". # For instance, if ports are updated as soon as tin versions are # released: # tin tin-devel tin-recent # 1.6.2 1.7.9 1.7.9 # 1.6.2 1.7.10 1.7.10 # 1.8.0 1.7.10 1.8.0 # 1.8.1 1.7.10 1.8.1 # 1.8.1 1.9.0 1.9.0 # 1.8.1 1.9.1 1.9.1 # 1.8.2 1.9.1 1.9.1 # 1.8.3 1.9.2 1.9.2 # where: # 1.7.9 = 1.7.8 + patches U040 to U045. # 1.7.10 = 1.7.9 + patches U046 to U052. # 1.8.0 = 1.7.10 + patches U053 to U056. # 1.8.1 = 1.8.0 + patches 001 to 006. # 1.9.0 = 1.8.1 + patches 007, 008 and U001. # 1.9.1 = 1.9.0 + patches 009 and U002. # 1.8.2 = 1.8.1 + patches 007 to 011. # 1.8.3 = 1.8.2 + patches 012 to 018. # 1.9.2 = 1.9.1 + patches 010 to 018 and U003 to U006. # Said otherwise: # 1.8.1 = 1.8.0 + patches 001 to 006. # 1.9.0 = 1.8.0 + patches 001 to 008 and U001. # 1.9.1 = 1.8.0 + patches 001 to 009 and U001 to U002. # 1.8.2 = 1.8.0 + patches 001 to 011. # 1.8.3 = 1.8.0 + patches 001 to 018. # 1.9.2 = 1.8.0 + patches 001 to 018 and U001 to U006. From ryandesign at macports.org Mon Feb 4 09:32:31 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Feb 4 09:32:24 2008 Subject: Variants handling: my $0.02. In-Reply-To: <47A747D2.6000602@macports.org> References: <47A747D2.6000602@macports.org> Message-ID: <2433CC45-ABA0-4653-BC45-EE0E4F450639@macports.org> On Feb 4, 2008, at 11:13, Rainer M?ller wrote: > So how would I tell that a +variant is default? E.g. the lynx port > provides support for OpenSSL (+ssl) and GNU TLS (+gnutls). They are > conflicting variants, with +ssl in default_variants. But the user > has the choice to install it with GNU TLS by using -ssl +gnutls. Having to specify "-ssl +gnutls" is stupid. The way I see it, "ssl" and "gnutls" are two radio buttons. To select the radio button you want, you shouldn't also have to manually deselect the radio button you don't want. It should be automatic. Fixed the lynx port so it behaves this way, in r33752. (No new portfile syntax needed. :)) From raimue at macports.org Mon Feb 4 09:46:20 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon Feb 4 09:46:03 2008 Subject: Variants handling: my $0.02. In-Reply-To: <2433CC45-ABA0-4653-BC45-EE0E4F450639@macports.org> References: <47A747D2.6000602@macports.org> <2433CC45-ABA0-4653-BC45-EE0E4F450639@macports.org> Message-ID: <47A74F6C.30909@macports.org> Ryan Schmidt wrote: > Having to specify "-ssl +gnutls" is stupid. The way I see it, "ssl" and > "gnutls" are two radio buttons. To select the radio button you want, you > shouldn't also have to manually deselect the radio button you don't > want. It should be automatic. Fixed the lynx port so it behaves this > way, in r33752. (No new portfile syntax needed. :)) Well, I just wanted to say how it is done until now. Indeed, your fix is a good thing as it also fixes the issues with upgrading. Anyways, I was just talking about how we would write this "radio button choice" in a new syntax where default_variants will be gone. Rainer From ryandesign at macports.org Mon Feb 4 10:08:06 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Feb 4 10:08:02 2008 Subject: Variants handling: my $0.02. In-Reply-To: <47A74F6C.30909@macports.org> References: <47A747D2.6000602@macports.org> <2433CC45-ABA0-4653-BC45-EE0E4F450639@macports.org> <47A74F6C.30909@macports.org> Message-ID: On Feb 4, 2008, at 11:46, Rainer M?ller wrote: > Ryan Schmidt wrote: > >> Having to specify "-ssl +gnutls" is stupid. The way I see it, >> "ssl" and "gnutls" are two radio buttons. To select the radio >> button you want, you shouldn't also have to manually deselect the >> radio button you don't want. It should be automatic. Fixed the >> lynx port so it behaves this way, in r33752. (No new portfile >> syntax needed. :)) > > Well, I just wanted to say how it is done until now. Indeed, your > fix is a good thing as it also fixes the issues with upgrading. > > Anyways, I was just talking about how we would write this "radio > button choice" in a new syntax where default_variants will be gone. default_variants functionality should not be removed. It is necessary. When there are two or more conflicting options, one of which must be selected, it is more intuitive for the user if these are both expressed as variants, one of which is enabled by default. See lynx, minivmac, pdftk, etc. From ryandesign at macports.org Mon Feb 4 10:09:31 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Feb 4 10:09:28 2008 Subject: Marking default variants (was: [MacPorts] #14178: Feature Request: show default_variants in "port variants foobar") In-Reply-To: <47A747AE.7040709@macports.org> References: <048.bb2e35ac771ae67b9d76bab86f526b8a@macosforge.org> <47A747AE.7040709@macports.org> Message-ID: On Feb 4, 2008, at 11:13, Rainer M?ller wrote: > MacPorts wrote: > >> #14178: Feature Request: show default_variants in "port variants >> foobar" >> -------------------------------- >> +------------------------------------------- >> Reporter: themolok@gmail.com | Owner: macports- >> tickets@lists.macosforge.org >> Type: enhancement | Status: >> new Priority: >> Normal | >> Milestone: Component: >> base | Version: >> 1.6.0 >> Keywords: | -------------------------------- >> +------------------------------------------- >> I tried to write a patch for it, but I failed (I never wrote a >> single line >> of tcl, and I'm a pretty lame programmer), anyway, I think it's >> really >> trivial for who knows the port (the tcl script) codebase. >> Now, for example, "port variants git-core" returns (note that doc >> is in >> default_variants): >> {{{ >> git-core has the variants: >> universal >> doc: Install HTML and plaintext documentation >> svn: Bi-directional subversion repository support >> }}} >> I'd like to have something like: >> {{{ >> git-core has the variants: >> universal >> doc: Install HTML and plaintext documentation (default) >> svn: Bi-directional subversion repository support >> }}} > > I also thought about marking default variants some time ago, but I > think this should not only be added to port variants, but also to > port info. Where the latter will be more difficult, as > default_variants are currently not stored in PortIndex. > > It would be good to e.g. mark them with a star. > git-core 1.5.3.7, devel/git-core (Variants: universal, *doc, svn) > > And this could also be used for port variants. > git-core has the variants: > universal > *doc: Install HTML and plaintext documentation > svn: Bi-directional subversion repository support > > I don't like that (default) behind the description as it is not > clear if it is part of the description or not. I have been adding "(default)" to the ends of descriptions of all variants which are enabled by default. I think it's very clear -- much clearer than an asterisk. > The star (or another symbol) could also be behind the variants > name, that's open for discussion. That's why I put this up on > macports-dev@ instead of adding a comment to the ticket. From raimue at macports.org Mon Feb 4 10:39:06 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon Feb 4 10:38:51 2008 Subject: Marking default variants In-Reply-To: References: <048.bb2e35ac771ae67b9d76bab86f526b8a@macosforge.org> <47A747AE.7040709@macports.org> Message-ID: <47A75BCA.60003@macports.org> Ryan Schmidt wrote: > I have been adding "(default)" to the ends of descriptions of all > variants which are enabled by default. I think it's very clear -- much > clearer than an asterisk. It is not possible to put "(default)" behind each variant in port info, do you agree on that? And if we choose a mark it should be consistent. Rainer From ryandesign at macports.org Mon Feb 4 11:09:09 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Feb 4 11:09:03 2008 Subject: [33724] trunk/base/src In-Reply-To: <20080204082918.9DC5CF63E86@beta.macosforge.org> References: <20080204082918.9DC5CF63E86@beta.macosforge.org> Message-ID: On Feb 4, 2008, at 02:29, afb@macports.org wrote: > Modified: trunk/base/src/port1.0/portconfigure.tcl > =================================================================== > --- trunk/base/src/port1.0/portconfigure.tcl 2008-02-04 03:30:08 > UTC (rev 33723) > +++ trunk/base/src/port1.0/portconfigure.tcl 2008-02-04 08:29:16 > UTC (rev 33724) > @@ -102,14 +102,9 @@ > default configure.pkg_config {} > default configure.pkg_config_path {} > > -# Universal options & default values. > -set target "10.4" > -set sysroot "/Developer/SDKs/MacOSX10.4u.sdk" > -set universal_archs {ppc i386} > - > options configure.universal_target configure.universal_sysroot > configure.universal_archs configure.universal_args > configure.universal_cflags configure.universal_cppflags > configure.universal_cxxflags configure.universal_ldflags > -default configure.universal_target {${target}} > -default configure.universal_sysroot {${sysroot}} > +default configure.universal_target {${universal_target}} > +default configure.universal_sysroot {${universal_sysroot}} > default configure.universal_archs {${universal_archs}} > default configure.universal_args > {[configure_get_universal_args]} > default configure.universal_cflags > {[configure_get_universal_cflags]} This breaks those ports that use ${sysroot}. Currently that's cairo, libiconv and xrender. $ sudo port install cairo +universal Error: Unable to execute port: can't read "sysroot": no such variable $ Maybe ${sysroot} should be retained until ${universal_sysroot} is in a released version of MacPorts and these ports are updated to use it? From nox at macports.org Mon Feb 4 11:23:45 2008 From: nox at macports.org (N_Ox) Date: Mon Feb 4 11:23:32 2008 Subject: Variants handling: my $0.02. In-Reply-To: <47A747D2.6000602@macports.org> References: <47A747D2.6000602@macports.org> Message-ID: Le 4 f?vr. 08 ? 18:13, Rainer M?ller a ?crit : > N_Ox wrote: >> These two sugar syntaxes would make the variant writing process >> cleaner. >> But maybe they could help us more... >> Let's say the variants which do something only when they are >> disabled (variant -some_variant) are always enabled by default. >> In this setup, `sudo port install some_port +another_variant` >> would install some_port @some_version+another_variant+some_variant. >> In the registry, we would save "some_variant another_variant" as >> the list of selected variants. >> Now, let's explicitely disable the variant: sudo port install >> some_port -some_variant +another_variant. >> In the registry, we would save "-some_variant another_variant". > > Should the selection of -some_variant be user visible or just > stored internal? > port installed some_port > 1) some_port@1.0+another_variant-some_variant > 2) some_port@1.0+another_variant Shown to the user > The main problem about default_variants in it's current > implementation is that we don't store disabled variants and re- > select them on upgrade... AFAIK, default_variants is just a procedure that append any argument to the list of enabled variants in the registry. This syntax remove the need to use default_variants. >> No need to use default_variants. > > So how would I tell that a +variant is default? E.g. the lynx port > provides support for OpenSSL (+ssl) and GNU TLS (+gnutls). They are > conflicting variants, with +ssl in default_variants. But the user > has the choice to install it with GNU TLS by using -ssl +gnutls. > > But how would I write that in the new syntax? > >> No more "Why the hell this variant is enabled when I upgrade this >> port?" whining. >> No more "no_x11" variant: >> variant -x11 { >> # no x11 >> } else { >> # x11 >> } > > And which of those will be the default...? You said -some_variant > will be enabled by default, or did I understand that wrong? In > which cases will -some_variant be enabled by defaul? If it got no > else-block? > I think that will end up more complex than it currently is... Not complex, at least that's not what I think. The algorithm would be: foreach {name} ${variants} { # Foreach variant defined in the portfile if {[lindex ${selected_variants} ${name}] > -1} { # If this variant is selected. eval_variant ${name} # The first block. } elseif {[variant_has_else_block ${name}]} { eval_else_variant ${name} # The else block } } If a -variant hasn't been SELECTED (through the command line), it is ENABLED, it did NOT show up in `port installed` and the else block will be evaluated. If a (+)variant hasn't been SELECTED (through the command line), it is DISABLED, it did NOT show up in `port installed` and the else block will be evaluated. So the behaviour is in fact the very same for both of them. > Also, what is the difference between these and which one is a > default variant? > > variant foo { > # do something > } A normal variant: port install -> @... (nothing evaluated) port install +foo -> @...+foo (first block evaluated) port install -foo -> @... (nothing evaluated) > variant -bar { > # do something > } else { > # do something > } A negative variant which does something else when it's not enabled: port install -> @... (else block evaluated) port install +bar -> @... (else block evaluated) port install -bar -> @...-bar (first block evaluated) > variant -baz { > # do something > } A negative variant: port install -> @... (nothing evaluated) port install +baz -> @... (nothing evaluated) port install -baz -> @...-baz (first block evaluated) > What if we add some new flag? I like the idea of variant - > some_variant, but maybe we could also add a default keyword which > says if this variant is going to be installed by default. > > Like this: > variant x11 description {Install X11 support} default { > # x11 > } else { > # no x11 > } Sure. The -variant syntax just sounds more intuitive to me, but one could say I'm strange. > I like the overall idea to simplify the default variants handling! > > Rainer -- Anthony Ramine, the "Ports tree cleaning Maestro". From nox at macports.org Mon Feb 4 11:25:46 2008 From: nox at macports.org (N_Ox) Date: Mon Feb 4 11:25:32 2008 Subject: Variants handling: my $0.02. In-Reply-To: <2433CC45-ABA0-4653-BC45-EE0E4F450639@macports.org> References: <47A747D2.6000602@macports.org> <2433CC45-ABA0-4653-BC45-EE0E4F450639@macports.org> Message-ID: Le 4 f?vr. 08 ? 18:32, Ryan Schmidt a ?crit : > On Feb 4, 2008, at 11:13, Rainer M?ller wrote: > >> So how would I tell that a +variant is default? E.g. the lynx port >> provides support for OpenSSL (+ssl) and GNU TLS (+gnutls). They >> are conflicting variants, with +ssl in default_variants. But the >> user has the choice to install it with GNU TLS by using -ssl +gnutls. > > > Having to specify "-ssl +gnutls" is stupid. The way I see it, "ssl" > and "gnutls" are two radio buttons. To select the radio button you > want, you shouldn't also have to manually deselect the radio button > you don't want. It should be automatic. Fixed the lynx port so it > behaves this way, in r33752. (No new portfile syntax needed. :)) > I had another idea for this one sometimes ago: variant_group cypher { choice ssl { ... } choice gnutls { ... } } We could have attributes for the group like "unique" and "required" to say we need one and only one choice in the group. Regards, -- Anthony Ramine, the "Ports tree cleaning Maestro". From jkh at apple.com Mon Feb 4 11:46:35 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Mon Feb 4 11:47:50 2008 Subject: Variants handling: my $0.02. In-Reply-To: References: <47A747D2.6000602@macports.org> Message-ID: <2401B902-B27F-4C5F-B313-917FD05E5DDE@apple.com> On Feb 4, 2008, at 11:23 AM, N_Ox wrote: > [ ... description of new variant syntax ...] First, let me just say how happy I am to see people revisiting the topic of variants and how to better express them. I think variants are one of the more powerful features of MacPorts (that no other port systems, to my knowledge, share), but also the most likely to cause confusion and mayhem if misapplied across the collection (I think Landon went through periods of both pride and remorse over variants for just this reason). Second, given that the "platform" procedure also feeds directly into variants, I hope that cleaning up variants will include cleaning up the platform syntax and general mechanism. More specifically, as I pointed out a couple of weeks ago, we're starting to see a lot of duplicated code across platform clauses because it's not possible to have wildcards in platform clauses or even just be able to do platform includes, e.g.: platform darwin 8 i386 { platform darwin 7; # include the generic platform code for darwin 7 ... code specific to darwin 8/i386 here ... } Given how frequently the platform clauses are being used, and the fact that they're only going to get more prolific as further releases of MacOSX come out, I'd say cleaning them up is at least as important as cleaning up variants (which, again, they just use at the back-end anyway). - Jordan > > Le 4 f?vr. 08 ? 18:13, Rainer M?ller a ?crit : > >> N_Ox wrote: >>> These two sugar syntaxes would make the variant writing process >>> cleaner. >>> But maybe they could help us more... >>> Let's say the variants which do something only when they are >>> disabled (variant -some_variant) are always enabled by default. >>> In this setup, `sudo port install some_port +another_variant` >>> would install some_port @some_version+another_variant+some_variant. >>> In the registry, we would save "some_variant another_variant" as >>> the list of selected variants. >>> Now, let's explicitely disable the variant: sudo port install >>> some_port -some_variant +another_variant. >>> In the registry, we would save "-some_variant another_variant". >> >> Should the selection of -some_variant be user visible or just >> stored internal? >> port installed some_port >> 1) some_port@1.0+another_variant-some_variant >> 2) some_port@1.0+another_variant > > Shown to the user > >> The main problem about default_variants in it's current >> implementation is that we don't store disabled variants and re- >> select them on upgrade... > > AFAIK, default_variants is just a procedure that append any argument > to the list of enabled variants in the registry. > This syntax remove the need to use default_variants. > >>> No need to use default_variants. >> >> So how would I tell that a +variant is default? E.g. the lynx port >> provides support for OpenSSL (+ssl) and GNU TLS (+gnutls). They are >> conflicting variants, with +ssl in default_variants. But the user >> has the choice to install it with GNU TLS by using -ssl +gnutls. >> >> But how would I write that in the new syntax? >> >>> No more "Why the hell this variant is enabled when I upgrade this >>> port?" whining. >>> No more "no_x11" variant: >>> variant -x11 { >>> # no x11 >>> } else { >>> # x11 >>> } >> >> And which of those will be the default...? You said -some_variant >> will be enabled by default, or did I understand that wrong? In >> which cases will -some_variant be enabled by defaul? If it got no >> else-block? >> I think that will end up more complex than it currently is... > > Not complex, at least that's not what I think. > The algorithm would be: > > foreach {name} ${variants} { > # Foreach variant defined in the portfile > > if {[lindex ${selected_variants} ${name}] > -1} { > # If this variant is selected. > eval_variant ${name} # The first block. > } elseif {[variant_has_else_block ${name}]} { > eval_else_variant ${name} # The else block > } > } > > If a -variant hasn't been SELECTED (through the command line), it is > ENABLED, it did NOT show up in `port installed` and the else block > will be evaluated. > If a (+)variant hasn't been SELECTED (through the command line), it > is DISABLED, it did NOT show up in `port installed` and the else > block will be evaluated. > > So the behaviour is in fact the very same for both of them. > > >> Also, what is the difference between these and which one is a >> default variant? >> >> variant foo { >> # do something >> } > > A normal variant: > port install -> @... (nothing evaluated) > port install +foo -> @...+foo (first block evaluated) > port install -foo -> @... (nothing evaluated) > >> variant -bar { >> # do something >> } else { >> # do something >> } > > A negative variant which does something else when it's not enabled: > port install -> @... (else block evaluated) > port install +bar -> @... (else block evaluated) > port install -bar -> @...-bar (first block evaluated) > >> variant -baz { >> # do something >> } > > A negative variant: > port install -> @... (nothing evaluated) > port install +baz -> @... (nothing evaluated) > port install -baz -> @...-baz (first block evaluated) > >> What if we add some new flag? I like the idea of variant - >> some_variant, but maybe we could also add a default keyword which >> says if this variant is going to be installed by default. >> >> Like this: >> variant x11 description {Install X11 support} default { >> # x11 >> } else { >> # no x11 >> } > > Sure. The -variant syntax just sounds more intuitive to me, but one > could say I'm strange. > >> I like the overall idea to simplify the default variants handling! >> >> Rainer > > -- > Anthony Ramine, the "Ports tree cleaning Maestro". > > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev From afb at macports.org Mon Feb 4 12:51:09 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon Feb 4 12:51:12 2008 Subject: [33724] trunk/base/src In-Reply-To: References: <20080204082918.9DC5CF63E86@beta.macosforge.org> Message-ID: <2f857e5877281c6870fe6ea38ecf8ea7@macports.org> Ryan Schmidt wrote: >> -# Universal options & default values. >> -set target "10.4" >> -set sysroot "/Developer/SDKs/MacOSX10.4u.sdk" >> -set universal_archs {ppc i386} > This breaks those ports that use ${sysroot}. Currently that's cairo, > libiconv and xrender. > > $ sudo port install cairo +universal > Error: Unable to execute port: can't read "sysroot": no such variable > $ > > Maybe ${sysroot} should be retained until ${universal_sysroot} is in a > released version of MacPorts and these ports are updated to use it? Reverted it back in r33764. --anders From vincent-opdarw at vinc17.org Mon Feb 4 13:35:22 2008 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Mon Feb 4 13:35:08 2008 Subject: *-devel ports In-Reply-To: <634664F9-BC97-42C7-98DA-5450F0FF27AF@macports.org> References: <92E586B9-4F46-47FE-9935-A7F903614C2F@macports.org> <962BF62E-5D29-4D91-A7E1-422C5FEBEF16@macports.org> <20080204145612.GG17147@prunille.vinc17.org> <634664F9-BC97-42C7-98DA-5450F0FF27AF@macports.org> Message-ID: <20080204213522.GJ17147@prunille.vinc17.org> On 2008-02-04 11:27:24 -0600, Ryan Schmidt wrote: > Regarding the suggestion to rename all *-devel ports to *-latest, in > light of the above change, the name "latest" would indeed seem to be > clearer. It would also remove any potential confusion with the RPM - > devel packages, which IMHO would be quite a good thing. I think this would be a good idea. > I guess this is as good a time as any to bring up the "tin" ports: > > $ port search ^tin$ ^tin- > tin news/tin 1.8.3 A threaded > NNTP and spool based UseNet newsreader > tin-devel news/tin-devel 1.7.10 A threaded > NNTP and spool based UseNet newsreader > tin-recent news/tin-recent 1.9.2 A Usenet > newsreader > $ > > Now, ignore the version numbers shown for a minute. Based on comments in > the header of "tin-recent" (copied below), it seems to be the > maintainer's intention (hey, that's you, Vincent!) that "tin" is the > latest released version, "tin-devel" is the latest development version, > and "tin-recent" is the more recent of the two. It looks like someone has > updated tin-recent but forgotten to update tin-devel. So, to match AFAIK, tin-devel is no longer maintained (and perhaps no longer used). > Vincent's new proposals, "tin-devel" gets deleted and "tin-recent" gets > renamed to "tin-latest", yes? +1 for this new policy. -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From raimue at macports.org Mon Feb 4 14:45:20 2008 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Mon Feb 4 14:45:08 2008 Subject: [33768] trunk/dports/devel In-Reply-To: <20080204214106.33B92F7EDD9@beta.macosforge.org> References: <20080204214106.33B92F7EDD9@beta.macosforge.org> Message-ID: <47A79580.6050809@macports.org> brett@macports.org wrote: > Revision: 33768 > http://trac.macosforge.org/projects/macports/changeset/33768 > Author: brett@macports.org > Date: 2008-02-04 13:40:14 -0800 (Mon, 04 Feb 2008) > > Log Message: > ----------- > initial libmemcached port > > Added Paths: > ----------- > trunk/dports/devel/libmemcached/ > trunk/dports/devel/libmemcached/Portfile > > Added: trunk/dports/devel/libmemcached/Portfile > =================================================================== > --- trunk/dports/devel/libmemcached/Portfile (rev 0) > +++ trunk/dports/devel/libmemcached/Portfile 2008-02-04 21:40:14 UTC (rev 33768) > @@ -0,0 +1,17 @@ > +# $Id$ > + > +PortSystem 1.0 > +name libmemcached > +version 0.15 > +description libmemcached is a C and C++ client library to the memcached server > +long_description libmemcached is a C and C++ client library for memcached. \ > + It has been designed to be light on memory usage, thread safe, \ > + and provide full access to server side methods. > +maintainers brett@macports.org > +categories devel > +platforms darwin > +homepage http://tangent.org/552/libmemcached.html > +master_sites http://download.tangent.org/ > +checksums sha1 b54a0cf6551627541d258d83f14228337e379bab > +configure.pre_args --prefix=${prefix} \ > + --mandir=${prefix}/share/man Please run `port lint' on newly added ports before committing them. This port does not match our current guidelines. ---> Verifying Portfile for libmemcached Warning: Line 4 should be a newline (after PortSystem) Warning: Line 12 has trailing whitespace before newline Warning: Line 17 has trailing whitespace before newline ---> 0 errors and 3 warnings found. Additionally, is there a difference to the already existing libmemcache port? Is that superseeded by libmemcached? Rainer From ryandesign at macports.org Mon Feb 4 19:37:13 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Feb 4 19:37:07 2008 Subject: [33768] trunk/dports/devel In-Reply-To: <20080204214106.33B92F7EDD9@beta.macosforge.org> References: <20080204214106.33B92F7EDD9@beta.macosforge.org> Message-ID: <9B1DCFFA-67C5-4AC2-90F9-6476768A552E@macports.org> On Feb 4, 2008, at 15:41, brett@macports.org wrote: > +configure.pre_args --prefix=${prefix} \ > + --mandir=${prefix}/share/man Why not like this? configure.args --mandir=${prefix}/share/man From blair at orcaware.com Mon Feb 4 22:52:15 2008 From: blair at orcaware.com (Blair Zajac) Date: Mon Feb 4 22:51:57 2008 Subject: Problems compiling perl5.8 on 10.5 Message-ID: <47A8079F.9040307@orcaware.com> Is anybody else having problems compiling perl5.8 on 10.5? I'm getting a bunch of warnings like this: make[1]: `lib/re.pm' is up to date. cd lib/unicore && DYLD_LIBRARY_PATH=/opt/local-development/var/macports/build/_opt_local-development_var_macports_sources_rsync.macports.org_release_ports_lang_perl5.8/work/perl-5.8.8 ../../miniperl -I../../lib mktables -w Can't locate File/Glob.pm in @INC (@INC contains: ../../lib /opt/local-development/lib/perl5/5.8.8/darwin-thread-multi-2level /opt/local-development/lib/perl5/5.8.8 /opt/local-development/lib/perl5/site_perl/5.8.8/darwin-thread-multi-2level /opt/local-development/lib/perl5/site_perl/5.8.8 /opt/local-development/lib/perl5/site_perl /opt/local-development/lib/perl5/vendor_perl/5.8.8/darwin-thread-multi-2level /opt/local-development/lib/perl5/vendor_perl/5.8.8 /opt/local-development/lib/perl5/vendor_perl .) at mktables line 2111. BEGIN failed--compilation aborted at mktables line 2111. To get around this, I did a custom patch by comparing 5.8.8 with the extraction using this command: $ tar xvfj perl-5.8.8.tar.bz2 $ rsync -Pavz rsync://public.activestate.com/perl-5.8.x/ 5.8.x/ $ cd 5.8.x $ diff -ruN ../5.8.8 . > ../patch.txt This generates a 3 Mbyte patch but it seems to work. Regards, Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies Subversion training, consulting and support http://www.orcaware.com/svn/ From jmpp at macports.org Mon Feb 4 23:02:39 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Mon Feb 4 23:00:48 2008 Subject: Problems compiling perl5.8 on 10.5 In-Reply-To: <47A8079F.9040307@orcaware.com> References: <47A8079F.9040307@orcaware.com> Message-ID: <6DFC08CC-6C5F-4BCF-AD93-05E5148179E0@macports.org> On Feb 5, 2008, at 2:22 AM, Blair Zajac wrote: > Is anybody else having problems compiling perl5.8 on 10.5? I'm > getting a bunch of warnings like this: > > make[1]: `lib/re.pm' is up to date. > cd lib/unicore && DYLD_LIBRARY_PATH=/opt/local-development/var/ > macports/build/_opt_local- > development_var_macports_sources_rsync > .macports.org_release_ports_lang_perl5.8/work/perl-5.8.8 ../../ > miniperl -I../../lib mktables -w > Can't locate File/Glob.pm in @INC (@INC contains: ../../lib /opt/ > local-development/lib/perl5/5.8.8/darwin-thread-multi-2level /opt/ > local-development/lib/perl5/5.8.8 /opt/local-development/lib/perl5/ > site_perl/5.8.8/darwin-thread-multi-2level /opt/local-development/ > lib/perl5/site_perl/5.8.8 /opt/local-development/lib/perl5/ > site_perl /opt/local-development/lib/perl5/vendor_perl/5.8.8/darwin- > thread-multi-2level /opt/local-development/lib/perl5/vendor_perl/ > 5.8.8 /opt/local-development/lib/perl5/vendor_perl .) at mktables > line 2111. > BEGIN failed--compilation aborted at mktables line 2111. I don't recall the warnings, but I did get this particular failure when building perl5.8 with the shared variant (which only does "configure.args-append -Duseshrplib" in the Portfile). I never looked into the problem though, as perl5.8 built just fine without that variant (even including +threads). Regards,... -jmpp > > > To get around this, I did a custom patch by comparing 5.8.8 with the > extraction using this command: > > $ tar xvfj perl-5.8.8.tar.bz2 > $ rsync -Pavz rsync://public.activestate.com/perl-5.8.x/ 5.8.x/ > $ cd 5.8.x > $ diff -ruN ../5.8.8 . > ../patch.txt > > This generates a 3 Mbyte patch but it seems to work. > > Regards, > Blair > > -- > Blair Zajac, Ph.D. > CTO, OrcaWare Technologies > > Subversion training, consulting and support > http://www.orcaware.com/svn/ > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev From billitch at gmail.com Tue Feb 5 04:46:15 2008 From: billitch at gmail.com (Thomas de Grivel) Date: Tue Feb 5 04:45:54 2008 Subject: Variants handling: my $0.02. In-Reply-To: References: <47A747D2.6000602@macports.org> Message-ID: <4ec7f0880802050446k7f72880fg17fbafc6aa9a1a3@mail.gmail.com> 2008/2/4, N_Ox : > > Le 4 f?vr. 08 ? 18:13, Rainer M?ller a ?crit : > > > N_Ox wrote: > >> These two sugar syntaxes would make the variant writing process > >> cleaner. > >> But maybe they could help us more... > >> Let's say the variants which do something only when they are > >> disabled (variant -some_variant) are always enabled by default. > >> In this setup, `sudo port install some_port +another_variant` > >> would install some_port @some_version+another_variant+some_variant. > >> In the registry, we would save "some_variant another_variant" as > >> the list of selected variants. > >> Now, let's explicitely disable the variant: sudo port install > >> some_port -some_variant +another_variant. > >> In the registry, we would save "-some_variant another_variant". > > > > Should the selection of -some_variant be user visible or just > > stored internal? > > port installed some_port > > 1) some_port@1.0+another_variant-some_variant > > 2) some_port@1.0+another_variant > > Shown to the user > > > The main problem about default_variants in it's current > > implementation is that we don't store disabled variants and re- > > select them on upgrade... > > AFAIK, default_variants is just a procedure that append any argument > to the list of enabled variants in the registry. > This syntax remove the need to use default_variants. > > >> No need to use default_variants. > > > > So how would I tell that a +variant is default? E.g. the lynx port > > provides support for OpenSSL (+ssl) and GNU TLS (+gnutls). They are > > conflicting variants, with +ssl in default_variants. But the user > > has the choice to install it with GNU TLS by using -ssl +gnutls. > > > > But how would I write that in the new syntax? > > > >> No more "Why the hell this variant is enabled when I upgrade this > >> port?" whining. > >> No more "no_x11" variant: > >> variant -x11 { > >> # no x11 > >> } else { > >> # x11 > >> } > > > > And which of those will be the default...? You said -some_variant > > will be enabled by default, or did I understand that wrong? In > > which cases will -some_variant be enabled by defaul? If it got no > > else-block? > > I think that will end up more complex than it currently is... > > Not complex, at least that's not what I think. > The algorithm would be: > > foreach {name} ${variants} { > # Foreach variant defined in the portfile > > if {[lindex ${selected_variants} ${name}] > -1} { > # If this variant is selected. > eval_variant ${name} # The first block. > } elseif {[variant_has_else_block ${name}]} { > eval_else_variant ${name} # The else block > } > } > > If a -variant hasn't been SELECTED (through the command line), it is > ENABLED, it did NOT show up in `port installed` and the else block > will be evaluated. > If a (+)variant hasn't been SELECTED (through the command line), it > is DISABLED, it did NOT show up in `port installed` and the else > block will be evaluated. > > So the behaviour is in fact the very same for both of them. > > > > Also, what is the difference between these and which one is a > > default variant? > > > > variant foo { > > # do something > > } > > A normal variant: > port install -> @... (nothing evaluated) > port install +foo -> @...+foo (first block evaluated) > port install -foo -> @... (nothing evaluated) > > > variant -bar { > > # do something > > } else { > > # do something > > } > > A negative variant which does something else when it's not enabled: > port install -> @... (else block evaluated) > port install +bar -> @... (else block evaluated) > port install -bar -> @...-bar (first block evaluated) > > > variant -baz { > > # do something > > } > > A negative variant: > port install -> @... (nothing evaluated) > port install +baz -> @... (nothing evaluated) > port install -baz -> @...-baz (first block evaluated) > > > What if we add some new flag? I like the idea of variant - > > some_variant, but maybe we could also add a default keyword which > > says if this variant is going to be installed by default. > > > > Like this: > > variant x11 description {Install X11 support} default { > > # x11 > > } else { > > # no x11 > > } > > Sure. The -variant syntax just sounds more intuitive to me, but one > could say I'm strange. > > > I like the overall idea to simplify the default variants handling! I like it. If there is some kind of poll here, I'm in =) -- Thomas de Grivel From billitch at gmail.com Tue Feb 5 04:57:30 2008 From: billitch at gmail.com (Thomas de Grivel) Date: Tue Feb 5 04:57:10 2008 Subject: *-devel ports In-Reply-To: <20080204213522.GJ17147@prunille.vinc17.org> References: <92E586B9-4F46-47FE-9935-A7F903614C2F@macports.org> <962BF62E-5D29-4D91-A7E1-422C5FEBEF16@macports.org> <20080204145612.GG17147@prunille.vinc17.org> <634664F9-BC97-42C7-98DA-5450F0FF27AF@macports.org> <20080204213522.GJ17147@prunille.vinc17.org> Message-ID: <4ec7f0880802050457n2a73b229tef5f4fcc89c0b8b@mail.gmail.com> 2008/2/4, Vincent Lefevre : > On 2008-02-04 11:27:24 -0600, Ryan Schmidt wrote: > > Regarding the suggestion to rename all *-devel ports to *-latest, in > > light of the above change, the name "latest" would indeed seem to be > > clearer. It would also remove any potential confusion with the RPM - > > devel packages, which IMHO would be quite a good thing. > > I think this would be a good idea. > > > I guess this is as good a time as any to bring up the "tin" ports: > > > > $ port search ^tin$ ^tin- > > tin news/tin 1.8.3 A threaded > > NNTP and spool based UseNet newsreader > > tin-devel news/tin-devel 1.7.10 A threaded > > NNTP and spool based UseNet newsreader > > tin-recent news/tin-recent 1.9.2 A Usenet > > newsreader > > $ > > > > Now, ignore the version numbers shown for a minute. Based on comments in > > the header of "tin-recent" (copied below), it seems to be the > > maintainer's intention (hey, that's you, Vincent!) that "tin" is the > > latest released version, "tin-devel" is the latest development version, > > and "tin-recent" is the more recent of the two. It looks like someone has > > updated tin-recent but forgotten to update tin-devel. So, to match > > AFAIK, tin-devel is no longer maintained (and perhaps no longer used). > > > Vincent's new proposals, "tin-devel" gets deleted and "tin-recent" gets > > renamed to "tin-latest", yes? > > +1 for this new policy. Then we would have to warn new users about -latest not being so stable because intuitively I would like the latest version to be installed but what retains me the the previous one is that "it just works". For the sake of stability I would have -unstable marked clearly, so that the users dont expect too much magic with -latest. -- Thomas de Grivel From ebgssth at gmail.com Tue Feb 5 05:24:15 2008 From: ebgssth at gmail.com (js) Date: Tue Feb 5 05:23:53 2008 Subject: *-devel ports In-Reply-To: <4ec7f0880802050457n2a73b229tef5f4fcc89c0b8b@mail.gmail.com> References: <92E586B9-4F46-47FE-9935-A7F903614C2F@macports.org> <962BF62E-5D29-4D91-A7E1-422C5FEBEF16@macports.org> <20080204145612.GG17147@prunille.vinc17.org> <634664F9-BC97-42C7-98DA-5450F0FF27AF@macports.org> <20080204213522.GJ17147@prunille.vinc17.org> <4ec7f0880802050457n2a73b229tef5f4fcc89c0b8b@mail.gmail.com> Message-ID: I think -devel is better. For one thing, it's more intuitive. Second, this naming convension is already used in FreeBSD so at least BSD users prefers -devel one. By the way, I think MacPorts is not for everyone, I mean, it's mostly for developer or kinds of techies, right? So IMHO providing an easy access to the latest, greatest software is more important thant prevent users from using might-be-unstable-software. Bad idea? On Feb 5, 2008 9:57 PM, Thomas de Grivel wrote: > 2008/2/4, Vincent Lefevre : > > On 2008-02-04 11:27:24 -0600, Ryan Schmidt wrote: > > > Regarding the suggestion to rename all *-devel ports to *-latest, in > > > light of the above change, the name "latest" would indeed seem to be > > > clearer. It would also remove any potential confusion with the RPM - > > > devel packages, which IMHO would be quite a good thing. > > > > I think this would be a good idea. > > > > > I guess this is as good a time as any to bring up the "tin" ports: > > > > > > $ port search ^tin$ ^tin- > > > tin news/tin 1.8.3 A threaded > > > NNTP and spool based UseNet newsreader > > > tin-devel news/tin-devel 1.7.10 A threaded > > > NNTP and spool based UseNet newsreader > > > tin-recent news/tin-recent 1.9.2 A Usenet > > > newsreader > > > $ > > > > > > Now, ignore the version numbers shown for a minute. Based on comments in > > > the header of "tin-recent" (copied below), it seems to be the > > > maintainer's intention (hey, that's you, Vincent!) that "tin" is the > > > latest released version, "tin-devel" is the latest development version, > > > and "tin-recent" is the more recent of the two. It looks like someone has > > > updated tin-recent but forgotten to update tin-devel. So, to match > > > > AFAIK, tin-devel is no longer maintained (and perhaps no longer used). > > > > > Vincent's new proposals, "tin-devel" gets deleted and "tin-recent" gets > > > renamed to "tin-latest", yes? > > > > +1 for this new policy. > > Then we would have to warn new users about -latest not being so stable > because intuitively I would like the latest version to be installed > but what retains me the the previous one is that "it just works". For > the sake of stability I would have -unstable marked clearly, so that > the users dont expect too much magic with -latest. > > -- > Thomas de Grivel > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev > From ramercer at gmail.com Tue Feb 5 06:17:50 2008 From: ramercer at gmail.com (Adam Mercer) Date: Tue Feb 5 06:17:41 2008 Subject: [33794] trunk/dports/shells/eash/Portfile In-Reply-To: <20080205134409.B228AFA98FB@beta.macosforge.org> References: <20080205134409.B228AFA98FB@beta.macosforge.org> Message-ID: <799406d60802050617k557507fbhb9054acc121e8f34@mail.gmail.com> On Feb 5, 2008 8:44 AM, wrote: > Revision 33794 Author brett@macports.org Date 2008-02-05 05:42:44 -0800 > (Tue, 05 Feb 2008) > Log Message no longer available > > Removed Paths > > trunk/dports/shells/eash/Portfile Any reason why you haven't removed the trunk/dports/shells/eash directory as well? Cheers Adam From raimue at macports.org Tue Feb 5 06:26:30 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue Feb 5 06:26:28 2008 Subject: Variants handling: my $0.02. In-Reply-To: <4ec7f0880802050446k7f72880fg17fbafc6aa9a1a3@mail.gmail.com> References: <47A747D2.6000602@macports.org> <4ec7f0880802050446k7f72880fg17fbafc6aa9a1a3@mail.gmail.com> Message-ID: <47A87216.1000008@macports.org> Thomas de Grivel wrote: > I like it. If there is some kind of poll here, I'm in =) Hm, I don't think we found final options for a voting yet, do we? Rainer From vincent-opdarw at vinc17.org Tue Feb 5 06:38:34 2008 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Tue Feb 5 06:38:19 2008 Subject: *-devel ports In-Reply-To: <4ec7f0880802050457n2a73b229tef5f4fcc89c0b8b@mail.gmail.com> References: <92E586B9-4F46-47FE-9935-A7F903614C2F@macports.org> <962BF62E-5D29-4D91-A7E1-422C5FEBEF16@macports.org> <20080204145612.GG17147@prunille.vinc17.org> <634664F9-BC97-42C7-98DA-5450F0FF27AF@macports.org> <20080204213522.GJ17147@prunille.vinc17.org> <4ec7f0880802050457n2a73b229tef5f4fcc89c0b8b@mail.gmail.com> Message-ID: <20080205143834.GM17147@prunille.vinc17.org> On 2008-02-05 13:57:30 +0100, Thomas de Grivel wrote: > Then we would have to warn new users about -latest not being so stable > because intuitively I would like the latest version to be installed > but what retains me the the previous one is that "it just works". For > the sake of stability I would have -unstable marked clearly, so that > the users dont expect too much magic with -latest. On the other hand, the development version is sometimes less buggy than the stable version. This is the case of mutt, zsh and lynx (for which there have been recommendations to use the development versions). -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From blair at orcaware.com Tue Feb 5 09:26:36 2008 From: blair at orcaware.com (Blair Zajac) Date: Tue Feb 5 09:26:18 2008 Subject: Why compile Java ports and commons-logging Message-ID: <47A89C4C.8080504@orcaware.com> Hi James, I've noticed that many of the Java ports you've worked on compile the Jar files newly. Is there any reason to do this? I like the fact that using the supplied jar files from a distribution are guaranteed to work. The reason I am asking is because with the upgrade to junit 4.4, commons-logging doesn't compile. compile.tests: [javac] Compiling 30 source files to /opt/local-development/var/macports/build/_opt_local-development_var_macports_sources_rsync.macports.org_release_ports_java_commons-logging/work/commons-logging-1.1-src/target/tests [javac] /opt/local-development/var/macports/build/_opt_local-development_var_macports_sources_rsync.macports.org_release_ports_java_commons-logging/work/commons-logging-1.1-src/src/test/org/apache/commons/logging/AbstractLogTest.java:20: package junit.framework does not exist [javac] import junit.framework.TestCase; Additionally, with the upgrade to Spring 2.5.x, one needs JDK 6 to compile it, so for that port, I had to disable compilation and just use the supplied jar's, which I'm happy to do. The only reason I see to compile a Java port is if you are patching the source code. Regards, Blair From blair at orcaware.com Tue Feb 5 09:29:26 2008 From: blair at orcaware.com (Blair Zajac) Date: Tue Feb 5 09:29:03 2008 Subject: Problems compiling perl5.8 on 10.5 In-Reply-To: <6DFC08CC-6C5F-4BCF-AD93-05E5148179E0@macports.org> References: <47A8079F.9040307@orcaware.com> <6DFC08CC-6C5F-4BCF-AD93-05E5148179E0@macports.org> Message-ID: <47A89CF6.8020405@orcaware.com> Juan Manuel Palacios wrote: > > On Feb 5, 2008, at 2:22 AM, Blair Zajac wrote: > >> Is anybody else having problems compiling perl5.8 on 10.5? I'm >> getting a bunch of warnings like this: >> >> make[1]: `lib/re.pm' is up to date. >> cd lib/unicore && >> DYLD_LIBRARY_PATH=/opt/local-development/var/macports/build/_opt_local-development_var_macports_sources_rsync.macports.org_release_ports_lang_perl5.8/work/perl-5.8.8 >> ../../miniperl -I../../lib mktables -w >> Can't locate File/Glob.pm in @INC (@INC contains: ../../lib >> /opt/local-development/lib/perl5/5.8.8/darwin-thread-multi-2level >> /opt/local-development/lib/perl5/5.8.8 >> /opt/local-development/lib/perl5/site_perl/5.8.8/darwin-thread-multi-2level >> /opt/local-development/lib/perl5/site_perl/5.8.8 >> /opt/local-development/lib/perl5/site_perl >> /opt/local-development/lib/perl5/vendor_perl/5.8.8/darwin-thread-multi-2level >> /opt/local-development/lib/perl5/vendor_perl/5.8.8 >> /opt/local-development/lib/perl5/vendor_perl .) at mktables line 2111. >> BEGIN failed--compilation aborted at mktables line 2111. > > > I don't recall the warnings, but I did get this particular failure > when building perl5.8 with the shared variant (which only does > "configure.args-append -Duseshrplib" in the Portfile). I never looked > into the problem though, as perl5.8 built just fine without that variant > (even including +threads). > > Regards,... > > > -jmpp Ahh thanks, that's good to know. However, Apple's 5.8.8 seems to have both defined: $ /usr/bin/perl -V|grep config_args config_args='-ds -e -Dprefix=/usr -Dccflags=-g -pipe -Dldflags=-Dman3ext=3pm -Duseithreads -Duseshrplib' So there must be some patch that gets this working. Is there a URL where Apple keeps its source code of open source packages? We could merge all their patches into our 5.8.8. Regards, Blair From ryandesign at macports.org Tue Feb 5 09:29:37 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Feb 5 09:29:31 2008 Subject: [33798] trunk/dports/mail In-Reply-To: <20080205143850.E0F24FAB297@beta.macosforge.org> References: <20080205143850.E0F24FAB297@beta.macosforge.org> Message-ID: <83C1E8EB-B645-4246-85B7-6D555F47A990@macports.org> On Feb 5, 2008, at 08:38, simon@macports.org wrote: > Revision: 33798 > http://trac.macosforge.org/projects/macports/changeset/33798 > Author: simon@macports.org > Date: 2008-02-05 06:38:46 -0800 (Tue, 05 Feb 2008) > > Log Message: > ----------- > mail/uagen: New port. Since it doesn't seem to install any compiled software, I think it needs a "universal_variant no" bit. From ryandesign at macports.org Tue Feb 5 09:34:39 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Feb 5 09:34:31 2008 Subject: [33790] trunk/dports/devel/cut/Portfile In-Reply-To: <20080205134030.88C55FA9670@beta.macosforge.org> References: <20080205134030.88C55FA9670@beta.macosforge.org> Message-ID: <5DA948DF-6A0E-46E6-B7AB-5FBE6E71D3EA@macports.org> On Feb 5, 2008, at 07:40, brett@macports.org wrote: > Revision: 33790 > http://trac.macosforge.org/projects/macports/changeset/33790 > Author: brett@macports.org > Date: 2008-02-05 05:40:09 -0800 (Tue, 05 Feb 2008) > > Log Message: > ----------- > linted > > Modified Paths: > -------------- > trunk/dports/devel/cut/Portfile > > Modified: trunk/dports/devel/cut/Portfile > =================================================================== > --- trunk/dports/devel/cut/Portfile 2008-02-05 13:28:15 UTC (rev > 33789) > +++ trunk/dports/devel/cut/Portfile 2008-02-05 13:40:09 UTC (rev > 33790) > @@ -1,12 +1,11 @@ > -# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: > nil; \ > -# c-basic-offset: 4 -*- > vim:fenc=utf-8:filetype=tcl:et:sw=4:ts=4:sts=4 > # $Id$ [snip] Actually, we are trying to *add* modelines to portfiles, not remove them, though I wish we would standardize on a single modeline and not just whatever someone feels like using. "port lint" in MacPorts 1.6.0 is broken in its check for modelines. This was fixed in trunk already: http://trac.macosforge.org/projects/macports/ticket/13496 From ryandesign at macports.org Tue Feb 5 09:38:08 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Feb 5 09:38:03 2008 Subject: [33797] trunk/dports/sysutils/beanstalkd/files/patch-Makefile.diff In-Reply-To: <20080205142318.E4309FAB298@beta.macosforge.org> References: <20080205142318.E4309FAB298@beta.macosforge.org> Message-ID: You added this as a new file. You should have used "svn cp" to copy it from patch-Makefile in r33533 so as to preserve the history and also to save space in the repository. On Feb 5, 2008, at 08:23, brett@macports.org wrote: > Revision: 33797 > http://trac.macosforge.org/projects/macports/changeset/33797 > Author: brett@macports.org > Date: 2008-02-05 06:22:21 -0800 (Tue, 05 Feb 2008) > > Log Message: > ----------- > update filename > > Added Paths: > ----------- > trunk/dports/sysutils/beanstalkd/files/patch-Makefile.diff > > Added: trunk/dports/sysutils/beanstalkd/files/patch-Makefile.diff > =================================================================== > --- trunk/dports/sysutils/beanstalkd/files/patch- > Makefile.diff (rev 0) > +++ trunk/dports/sysutils/beanstalkd/files/patch-Makefile.diff > 2008-02-05 14:22:21 UTC (rev 33797) > @@ -0,0 +1,21 @@ > +diff -u -r beanstalkd-0.6-orig/Makefile beanstalkd-0.6/Makefile > +--- beanstalkd-0.6-orig/Makefile 2008-01-02 21:16:41.000000000 -0500 > ++++ beanstalkd-0.6/Makefile 2008-01-18 10:48:25.000000000 -0500 > +@@ -1,12 +1,14 @@ > + program := beanstalkd > +-export CFLAGS := $(LDFLAGS) -Wall -Werror > +-export LDFLAGS := $(LDFLAGS) -levent > ++export CPPFLAGS := $(CPPFLAGS) -I__PREFIX__/include > ++export CFLAGS := $(CFLAGS) -Wall -Werror -I__PREFIX__/include > ++export LDFLAGS := $(LDFLAGS) -L__PREFIX__/lib -levent > + > + sources := $(shell ls *.c | fgrep -v $(program)) > + objects := $(sources:.c=.o) > + tests := $(sources:%=tests/test_%) > + > +-all: export CFLAGS := $(CFLAGS) -O2 > ++all: export CFLAGS := $(CFLAGS) -O2 -I__PREFIX__/include > ++all: export LDFLAGS := $(LDFLAGS) -L__PREFIX__/lib -levent > + all: $(program) > + > + debug: export CFLAGS := $(CFLAGS) -g -pg -DDEBUG From afb at macports.org Tue Feb 5 09:40:57 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Feb 5 09:40:35 2008 Subject: Why compile Java ports and commons-logging In-Reply-To: <47A89C4C.8080504@orcaware.com> References: <47A89C4C.8080504@orcaware.com> Message-ID: <3ecb8645933678b42fbb621053cc4059@macports.org> Blair Zajac wrote: > Additionally, with the upgrade to Spring 2.5.x, one needs JDK 6 to > compile it, so for that port, I had to disable compilation and just > use the supplied jar's, which I'm happy to do. > > The only reason I see to compile a Java port is if you are patching > the source code. Isn't running the supplied jar just like running the supplied binary ? Seems more like a question of binary blob versus open source to me... Then again, a working binary might be better than a broken source :-) (depending on who you ask, other projects like JPackage* recompile all) --anders * see http://www.jpackage.org/jpprequest.php From ryandesign at macports.org Tue Feb 5 09:42:20 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Feb 5 09:42:12 2008 Subject: [33800] trunk/dports/devel/flex/Portfile In-Reply-To: <20080205144258.864B1FAB4F0@beta.macosforge.org> References: <20080205144258.864B1FAB4F0@beta.macosforge.org> Message-ID: <23475904-9553-4F3D-8192-2B834A442BE3@macports.org> On Feb 5, 2008, at 08:42, mww@macports.org wrote: > @@ -25,3 +26,6 @@ > test.run yes > test.target check > > +post-destroot { > + system "cd ${destroot}${prefix}/bin && ln -s flex flex++" > +} Why use system? Why not use the built-in ln command? post-destroot { ln -s flex ${destroot}${prefix}/bin/flex++ } From jmpp at macports.org Tue Feb 5 09:47:42 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Feb 5 09:46:04 2008 Subject: Problems compiling perl5.8 on 10.5 In-Reply-To: <47A89CF6.8020405@orcaware.com> References: <47A8079F.9040307@orcaware.com> <6DFC08CC-6C5F-4BCF-AD93-05E5148179E0@macports.org> <47A89CF6.8020405@orcaware.com> Message-ID: On Feb 5, 2008, at 12:59 PM, Blair Zajac wrote: > Juan Manuel Palacios wrote: >> On Feb 5, 2008, at 2:22 AM, Blair Zajac wrote: >>> Is anybody else having problems compiling perl5.8 on 10.5? I'm >>> getting a bunch of warnings like this: >>> >>> make[1]: `lib/re.pm' is up to date. >>> cd lib/unicore && DYLD_LIBRARY_PATH=/opt/local-development/var/ >>> macports/build/_opt_local- >>> development_var_macports_sources_rsync >>> .macports.org_release_ports_lang_perl5.8/work/perl-5.8.8 ../../ >>> miniperl -I../../lib mktables -w >>> Can't locate File/Glob.pm in @INC (@INC contains: ../../lib /opt/ >>> local-development/lib/perl5/5.8.8/darwin-thread-multi-2level /opt/ >>> local-development/lib/perl5/5.8.8 /opt/local-development/lib/perl5/ >>> site_perl/5.8.8/darwin-thread-multi-2level /opt/local-development/ >>> lib/perl5/site_perl/5.8.8 /opt/local-development/lib/perl5/ >>> site_perl /opt/local-development/lib/perl5/vendor_perl/5.8.8/ >>> darwin-thread-multi-2level /opt/local-development/lib/perl5/ >>> vendor_perl/5.8.8 /opt/local-development/lib/perl5/vendor_perl .) >>> at mktables line 2111. >>> BEGIN failed--compilation aborted at mktables line 2111. >> I don't recall the warnings, but I did get this particular >> failure when building perl5.8 with the shared variant (which only >> does "configure.args-append -Duseshrplib" in the Portfile). I never >> looked into the problem though, as perl5.8 built just fine without >> that variant (even including +threads). >> Regards,... >> -jmpp > > Ahh thanks, that's good to know. However, Apple's 5.8.8 seems to > have both defined: > > $ /usr/bin/perl -V|grep config_args > config_args='-ds -e -Dprefix=/usr -Dccflags=-g -pipe -Dldflags=- > Dman3ext=3pm -Duseithreads -Duseshrplib' > > So there must be some patch that gets this working. Is there a URL > where Apple keeps its source code of open source packages? We could > merge all their patches into our 5.8.8. The link to Leopard's perl5.8 is this: http://www.opensource.apple.com/darwinsource/10.5/perl-51/ Even though it says 10.5, it's the same for 10.5.1 as that particular project was unchanged in the update. I tried looking around for an obvious hint to a relevant patch we could use, but didn't find it.... / me fears diffing the two source trees! Regards,... -jmpp > > > Regards, > Blair From brett at macports.org Tue Feb 5 09:54:57 2008 From: brett at macports.org (Brett Eisenberg) Date: Tue Feb 5 09:54:41 2008 Subject: [33790] trunk/dports/devel/cut/Portfile In-Reply-To: <5DA948DF-6A0E-46E6-B7AB-5FBE6E71D3EA@macports.org> References: <20080205134030.88C55FA9670@beta.macosforge.org> <5DA948DF-6A0E-46E6-B7AB-5FBE6E71D3EA@macports.org> Message-ID: <91F4AB9C-D6D9-43F9-B1BB-9F8940C42A78@macports.org> That's what I thought, from the guide, but went with what lint told me at the time :( Happy to add them back in once someone decides on a standard. b On Feb 5, 2008, at 12:34 PM, Ryan Schmidt wrote: > > On Feb 5, 2008, at 07:40, brett@macports.org wrote: > >> Revision: 33790 >> http://trac.macosforge.org/projects/macports/changeset/33790 >> Author: brett@macports.org >> Date: 2008-02-05 05:40:09 -0800 (Tue, 05 Feb 2008) >> >> Log Message: >> ----------- >> linted >> >> Modified Paths: >> -------------- >> trunk/dports/devel/cut/Portfile >> >> Modified: trunk/dports/devel/cut/Portfile >> =================================================================== >> --- trunk/dports/devel/cut/Portfile 2008-02-05 13:28:15 UTC (rev >> 33789) >> +++ trunk/dports/devel/cut/Portfile 2008-02-05 13:40:09 UTC (rev >> 33790) >> @@ -1,12 +1,11 @@ >> -# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: >> nil; \ >> -# c-basic-offset: 4 -*- >> vim:fenc=utf-8:filetype=tcl:et:sw=4:ts=4:sts=4 >> # $Id$ > > [snip] > > Actually, we are trying to *add* modelines to portfiles, not remove > them, though I wish we would standardize on a single modeline and > not just whatever someone feels like using. > > > "port lint" in MacPorts 1.6.0 is broken in its check for modelines. > This was fixed in trunk already: > > http://trac.macosforge.org/projects/macports/ticket/13496 > > > > > > !DSPAM:47a8a27a618281433542597! > From blair at orcaware.com Tue Feb 5 11:13:53 2008 From: blair at orcaware.com (Blair Zajac) Date: Tue Feb 5 11:13:29 2008 Subject: Why compile Java ports and commons-logging In-Reply-To: <3ecb8645933678b42fbb621053cc4059@macports.org> References: <47A89C4C.8080504@orcaware.com> <3ecb8645933678b42fbb621053cc4059@macports.org> Message-ID: <47A8B571.5070209@orcaware.com> Anders F Bj?rklund wrote: > Blair Zajac wrote: > >> Additionally, with the upgrade to Spring 2.5.x, one needs JDK 6 to >> compile it, so for that port, I had to disable compilation and just >> use the supplied jar's, which I'm happy to do. >> >> The only reason I see to compile a Java port is if you are patching >> the source code. > > Isn't running the supplied jar just like running the supplied binary ? > Seems more like a question of binary blob versus open source to me... > > Then again, a working binary might be better than a broken source :-) > (depending on who you ask, other projects like JPackage* recompile all) > > --anders > > * see http://www.jpackage.org/jpprequest.php I don't think the comparison with binary packages is entirely fair. Jar files fall in between source packages and complete binary ones. You can relocate a jar file without it breaking, but you can't relocate a binary package with dylibs, say if you want to move /opt/local into /Users/blair/my-macports. You have to recompile. There's also too many customizations people like to do with source releases, look at all our variants. You don't find many variants in Java packages. And I think saying "open source" is just mixing different concepts in this discussion. Right now compiling Java packages is more of a pain than it needs to be. This is the second package I've had to patch. Spring doesn't compile at all on 10.x unless you want to install JDK 6 which isn't officially released. Now commons-logging doesn't compile since it doesn't work with the new junit. Blair From jmpp at macports.org Tue Feb 5 11:39:10 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Feb 5 11:37:31 2008 Subject: [33790] trunk/dports/devel/cut/Portfile In-Reply-To: <5DA948DF-6A0E-46E6-B7AB-5FBE6E71D3EA@macports.org> References: <20080205134030.88C55FA9670@beta.macosforge.org> <5DA948DF-6A0E-46E6-B7AB-5FBE6E71D3EA@macports.org> Message-ID: <21CC11F6-9507-4606-80E9-AA011DDED95B@macports.org> On Feb 5, 2008, at 1:04 PM, Ryan Schmidt wrote: > > On Feb 5, 2008, at 07:40, brett@macports.org wrote: > >> Revision: 33790 >> http://trac.macosforge.org/projects/macports/changeset/33790 >> Author: brett@macports.org >> Date: 2008-02-05 05:40:09 -0800 (Tue, 05 Feb 2008) >> >> Log Message: >> ----------- >> linted >> >> Modified Paths: >> -------------- >> trunk/dports/devel/cut/Portfile >> >> Modified: trunk/dports/devel/cut/Portfile >> =================================================================== >> --- trunk/dports/devel/cut/Portfile 2008-02-05 13:28:15 UTC (rev >> 33789) >> +++ trunk/dports/devel/cut/Portfile 2008-02-05 13:40:09 UTC (rev >> 33790) >> @@ -1,12 +1,11 @@ >> -# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: >> nil; \ >> -# c-basic-offset: 4 -*- >> vim:fenc=utf-8:filetype=tcl:et:sw=4:ts=4:sts=4 >> # $Id$ > > [snip] > > Actually, we are trying to *add* modelines to portfiles, not remove > them, though I wish we would standardize on a single modeline and > not just whatever someone feels like using. Modelines are required for base source files (because the belong to all of us) but only suggested for Portfiles (because, in a way, they belong more to the corresponding port maintainers). But that put aside, there's definitely a standard for modelines, documented in base/ HACKING. More specifically, the modeline for Tcl files reads: -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c- basic-offset: 4 -*- vim:fenc=utf-8:filetype=tcl:et:sw=4:ts=4:sts=4 Which encompasses both [x]emacs and vi[m]. If that does not suit in any way a particular maintainer, I think its fair to allow him/her to choose the modeline that best fits his/her needs (with an inclination to the proposed standard for openmaintainer and no maintainer ports, of course) Regards,... -jmpp > > > > "port lint" in MacPorts 1.6.0 is broken in its check for modelines. > This was fixed in trunk already: > > http://trac.macosforge.org/projects/macports/ticket/13496 > > > > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev From afb at macports.org Tue Feb 5 13:35:35 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Feb 5 13:35:28 2008 Subject: Why compile Java ports and commons-logging In-Reply-To: <47A8B571.5070209@orcaware.com> References: <47A89C4C.8080504@orcaware.com> <3ecb8645933678b42fbb621053cc4059@macports.org> <47A8B571.5070209@orcaware.com> Message-ID: <1715780f79b4caebe5b0b4e73b327a85@macports.org> Blair Zajac wrote: >>> The only reason I see to compile a Java port is if you are patching >>> the source code. >> Isn't running the supplied jar just like running the supplied binary ? >> Seems more like a question of binary blob versus open source to me... > > I don't think the comparison with binary packages is entirely fair. > Jar files fall in between source packages and complete binary ones. > You can relocate a jar file without it breaking, but you can't > relocate a binary package with dylibs, say if you want to move > /opt/local into /Users/blair/my-macports. You have to recompile. > There's also too many customizations people like to do with source > releases, look at all our variants. You don't find many variants in > Java packages. But just because they're relocatable and not many want to customize, doesn't make them not binary ? We are talking about regular .jar files with .class code here, right - and not .zip cousins with .java source, or something ? > And I think saying "open source" is just mixing different concepts in > this discussion. I might have misunderstood the original suggestion, I thought it said something like "why bother compiling the source when using the binary works better" ? Didn't mean to introduce a difference concept... --anders From simon at ruderich.com Tue Feb 5 12:50:13 2008 From: simon at ruderich.com (Simon Ruderich) Date: Tue Feb 5 14:48:24 2008 Subject: [33798] trunk/dports/mail In-Reply-To: <83C1E8EB-B645-4246-85B7-6D555F47A990@macports.org> References: <20080205143850.E0F24FAB297@beta.macosforge.org> <83C1E8EB-B645-4246-85B7-6D555F47A990@macports.org> Message-ID: <20080205204945.GA3384@ruderich.com> On Tue, Feb 05, 2008 at 11:29:37AM -0600, Ryan Schmidt wrote: > Since it doesn't seem to install any compiled software, I think it needs a > "universal_variant no" bit. Thanks for your hint. I just added it. Simon -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080205/84684110/attachment.bin From raimue at macports.org Tue Feb 5 15:21:02 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue Feb 5 15:20:39 2008 Subject: [33798] trunk/dports/mail In-Reply-To: <20080205204945.GA3384@ruderich.com> References: <20080205143850.E0F24FAB297@beta.macosforge.org> <83C1E8EB-B645-4246-85B7-6D555F47A990@macports.org> <20080205204945.GA3384@ruderich.com> Message-ID: <47A8EF5E.7000004@macports.org> Simon Ruderich wrote: > On Tue, Feb 05, 2008 at 11:29:37AM -0600, Ryan Schmidt wrote: >> Since it doesn't seem to install any compiled software, I think it needs a >> "universal_variant no" bit. > > Thanks for your hint. I just added it. As this software is just a perl script and requires no extra steps for other architectures shouldn't it considered to be already universal? Which would be: default_variants +universal variant universal {} Rainer From ryandesign at macports.org Tue Feb 5 18:42:36 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Feb 5 18:42:26 2008 Subject: [33798] trunk/dports/mail In-Reply-To: <47A8EF5E.7000004@macports.org> References: <20080205143850.E0F24FAB297@beta.macosforge.org> <83C1E8EB-B645-4246-85B7-6D555F47A990@macports.org> <20080205204945.GA3384@ruderich.com> <47A8EF5E.7000004@macports.org> Message-ID: <47C16ABF-3C62-4F64-8BFD-CF3DCAE825D2@macports.org> On Feb 5, 2008, at 17:21, Rainer M?ller wrote: > Simon Ruderich wrote: > >> On Tue, Feb 05, 2008 at 11:29:37AM -0600, Ryan Schmidt wrote: >> >>> Since it doesn't seem to install any compiled software, I think >>> it needs a "universal_variant no" bit. >> >> Thanks for your hint. I just added it. > > As this software is just a perl script and requires no extra steps > for other architectures shouldn't it considered to be already > universal? > > Which would be: > default_variants +universal > variant universal {} I would say no. I would say "universal_variant no" is currently appropriate for software that is architecture-agnostic, like this perl script. Though I've never been really happy with "universal_variant no". It's not a Boolean situation. See my earlier message: http://lists.macosforge.org/pipermail/macports-dev/2007-June/001868.html In it, I suggest that "universal_variant" should be replaced with "universal.method" and have several possible values. Actually I don't care so much if it's renamed, but I do care that we support these options: "autoconf" (like "universal_variant yes" today) "lipo" (automated multiple building and merging with lipo [1]) "none" (like "universal_variant no" today) "implicit" (software is already universal and can't be built non- universal) "unknown" (default; same as "autoconf" (if "use_configure yes") or "lipo" (if "use_configure no") but prints a warning that this is untested) I now revise my suggestion in that "none" should be further divided into these two options: "unnecessary" (port is arch-agnostic) "impossible" (port fails when built universal) These names may not be great; suggestions for other names for these options welcomed. For example "lipo" might be better called "merge". [1] I also suggested this in an earlier message: http://lists.macosforge.org/pipermail/macports-dev/2007-April/ 001319.html From n.oxyde at gmail.com Tue Feb 5 23:04:49 2008 From: n.oxyde at gmail.com (N_Ox) Date: Tue Feb 5 23:04:25 2008 Subject: [33798] trunk/dports/mail In-Reply-To: <47C16ABF-3C62-4F64-8BFD-CF3DCAE825D2@macports.org> References: <20080205143850.E0F24FAB297@beta.macosforge.org> <83C1E8EB-B645-4246-85B7-6D555F47A990@macports.org> <20080205204945.GA3384@ruderich.com> <47A8EF5E.7000004@macports.org> <47C16ABF-3C62-4F64-8BFD-CF3DCAE825D2@macports.org> Message-ID: <46C5FD74-82C3-4815-ACE3-C39C6BD87F00@gmail.com> Le 6 f?vr. 08 ? 03:42, Ryan Schmidt a ?crit : > > On Feb 5, 2008, at 17:21, Rainer M?ller wrote: > >> Simon Ruderich wrote: >> >>> On Tue, Feb 05, 2008 at 11:29:37AM -0600, Ryan Schmidt wrote: >>> >>>> Since it doesn't seem to install any compiled software, I think >>>> it needs a "universal_variant no" bit. >>> >>> Thanks for your hint. I just added it. >> >> As this software is just a perl script and requires no extra steps >> for other architectures shouldn't it considered to be already >> universal? >> >> Which would be: >> default_variants +universal >> variant universal {} > > > I would say no. I would say "universal_variant no" is currently > appropriate for software that is architecture-agnostic, like this > perl script. > > > Though I've never been really happy with "universal_variant no". > It's not a Boolean situation. See my earlier message: > > http://lists.macosforge.org/pipermail/macports-dev/2007-June/ > 001868.html > > In it, I suggest that "universal_variant" should be replaced with > "universal.method" and have several possible values. Actually I > don't care so much if it's renamed, but I do care that we support > these options: > > "autoconf" (like "universal_variant yes" today) > "lipo" (automated multiple building and merging with lipo [1]) > "none" (like "universal_variant no" today) > "implicit" (software is already universal and can't be built non- > universal) > "unknown" (default; same as "autoconf" (if "use_configure yes") or > "lipo" (if "use_configure no") but prints a warning that this is > untested) > > I now revise my suggestion in that "none" should be further divided > into these two options: > > "unnecessary" (port is arch-agnostic) > "impossible" (port fails when built universal) > > These names may not be great; suggestions for other names for these > options welcomed. For example "lipo" might be better called "merge". > > > [1] I also suggested this in an earlier message: > > http://lists.macosforge.org/pipermail/macports-dev/2007-April/ > 001319.html > I like this. -- Anthony Ramine, the "Ports tree cleaning Maestro". From afb at macports.org Tue Feb 5 23:32:28 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Feb 5 23:32:05 2008 Subject: [33798] trunk/dports/mail In-Reply-To: <47C16ABF-3C62-4F64-8BFD-CF3DCAE825D2@macports.org> References: <20080205143850.E0F24FAB297@beta.macosforge.org> <83