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> <83C1E8EB-B645-4246-85B7-6D555F47A990@macports.org> <20080205204945.GA3384@ruderich.com> <47A8EF5E.7000004@macports.org> <47C16ABF-3C62-4F64-8BFD-CF3DCAE825D2@macports.org> Message-ID: Ryan Schmidt wrote: >> 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. Technically +universal would be 2 (or 4) architectures, while this is for 0 (zero) architectures. That's why it is called "noarch" in some other packaging systems* (that call the universal "fat") Having this "don't need compile" metadata in the Portfile is good, just that "universal" isn't it: http://trac.macports.org/projects/macports/ticket/12206 But it could be joined to a single variable, like Ryan is suggesting, as they do affect eachother ? (if it doesn't have a machine architecture then it doesn't need to have a +universal variant either) --anders * that would be RPM (.noarch.rpm), while another name is used in DEB (.all.deb) difference being how many it is built for, versus how many that it applies to From landonf at macports.org Wed Feb 6 11:45:36 2008 From: landonf at macports.org (Landon Fuller) Date: Wed Feb 6 11:45:23 2008 Subject: Fwd: [MacPorts Lint] Portfile Lint Errors for: dpkg References: <20080206131947.3CAAE28082@relay13.apple.com> Message-ID: <2E442036-A7C7-4841-A19B-6A298948ACBF@macports.org> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080206/7e6ed4f0/PGP.bin From ryandesign at macports.org Wed Feb 6 13:23:09 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Feb 6 13:22:58 2008 Subject: [MacPorts Lint] Portfile Lint Errors for: dpkg In-Reply-To: <2E442036-A7C7-4841-A19B-6A298948ACBF@macports.org> References: <20080206131947.3CAAE28082@relay13.apple.com> <2E442036-A7C7-4841-A19B-6A298948ACBF@macports.org> Message-ID: There is no detriment that I can discern by naming patchfiles "patch- *.diff" as port lint recommends. There is a detriment by not following this convention which has been discussed at length before on the list. This warning has been in port lint for quite some time already. It's just now been made an automated email. On Feb 6, 2008, at 13:45, Landon Fuller wrote: > So I just received the following automated e-mail. While I think > automated portlint is great, I'm wondering why we need a new > ".diff" Official Policy just to appease certain people's editors. > > Begin forwarded message: > >> From: noreply@macports.org >> Date: February 6, 2008 05:17:47 PST >> To: landonf@macports.org >> Subject: [MacPorts Lint] Portfile Lint Errors for: dpkg >> >> Portfile: dpkg >> >> >> Errors: Warning: Line 4 should be a newline (after PortSystem) >> Warning: Line 33 has trailing whitespace before newline >> Warning: Patchfile patch-config.h.in does not follow the source >> patch naming policy "patch-*.diff" >> Warning: Patchfile patch-configure does not follow the source >> patch naming policy "patch-*.diff" >> Warning: Patchfile patch-configure.in does not follow the source >> patch naming policy "patch-*.diff" >> Warning: Patchfile patch-lib_utils.c does not follow the source >> patch naming policy "patch-*.diff" >> Warning: Patchfile patch-lib_tarfn.c does not follow the source >> patch naming policy "patch-*.diff" >> Warning: Patchfile patch-main_remove.c does not follow the source >> patch naming policy "patch-*.diff" >> Warning: Patchfile patch-utils_Makefile.in does not follow the >> source patch naming policy "patch-*.diff" >> Warning: Patchfile patch-main_archives.c does not follow the >> source patch naming policy "patch-*.diff" >> Warning: Patchfile patch-archtable does not follow the source >> patch naming policy "patch-*.diff" >> Warning: Patchfile patch-include_parsedump.h does not follow the >> source patch naming policy "patch-*.diff" >> Warning: Patchfile patch-utils_start-stop-daemon.c does not follow >> the source patch naming policy "patch-*.diff" >> Warning: Patchfile bsd/patch-main_help.c does not follow the >> source patch naming policy "patch-*.diff" >> >> >> > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev From landonf at macports.org Wed Feb 6 13:33:45 2008 From: landonf at macports.org (Landon Fuller) Date: Wed Feb 6 13:33:23 2008 Subject: [MacPorts Lint] Portfile Lint Errors for: dpkg In-Reply-To: References: <20080206131947.3CAAE28082@relay13.apple.com> <2E442036-A7C7-4841-A19B-6A298948ACBF@macports.org> Message-ID: <85E69020-3ED0-4F6E-A5A5-4270191AD391@macports.org> On Feb 6, 2008, at 13:23, Ryan Schmidt wrote: > There is no detriment that I can discern by naming patchfiles > "patch-*.diff" as port lint recommends. There is a detriment by not > following this convention which has been discussed at length before > on the list. There is a detriment. The patchfiles aren't syntax hilighted as C, and instead are hilighted as a patch file. This is purely a matter of personal preference, which is a bad reason to dictate policy. > This warning has been in port lint for quite some time already. > It's just now been made an automated email. Yes, and getting an e-mail about something I don't think is a problem is frustrating. -landonf -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080206/b760a97b/PGP.bin From billitch at gmail.com Wed Feb 6 20:21:38 2008 From: billitch at gmail.com (Thomas de Grivel) Date: Wed Feb 6 20:21:07 2008 Subject: *-devel ports In-Reply-To: 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: <4ec7f0880802062021y6f042068s3aca09294ecde9ad@mail.gmail.com> 2008/2/5, js : > 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. > > 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? Of course, I did not mean to prevent anyone from doing anything ! Just make it the default if not proven unstable, or mark it as unstable (or devel) if it is. I agree with you that the latest version must be available by default, just what do you do when it is broken or breaks other ports or break the system ? Hey, I dont just hack programs, I also use them sometimes ^^; By the way, I'm a kind of a techie but I also often run into end-users who end up having macports installed by me because open source should be for everyone and I just wish they use it on their own and do not bug me (or you !) about it every time they install/upgrade something. Maybe we lack resources or feel like hackers but I'm sure we should definitely not deliberately make things unintuitive / uneasy. Vincent Lefevre wrote: > 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). Is there a reason for keeping an older version non-devel even when the -devel version is more stable ? Why not upgrade the default to the -devel version in this case ? My point of view is : have the latest version as the default, unless it is quite broken in some way, in this case make it a -devel version. Anyway, -devel should mean "for developers" right ? -- Thomas de Grivel (ps: replying above previous messages is totally unreadable, and don't quote the sigs ;) From ryandesign at macports.org Wed Feb 6 20:58:56 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Feb 6 20:58:42 2008 Subject: *-devel ports In-Reply-To: <4ec7f0880802062021y6f042068s3aca09294ecde9ad@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> <4ec7f0880802062021y6f042068s3aca09294ecde9ad@mail.gmail.com> Message-ID: <9BB53729-CC4C-4016-AF58-4DF57F2A59D1@macports.org> On Feb 6, 2008, at 22:21, Thomas de Grivel wrote: > 2008/2/5, js: > >> 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). Well then tin-devel should be removed and tin-recent should be renamed to tin-devel, for consistency with other ports. >>>>> 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 No problem. That's what the guide is for, isn't it? >>> 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. >> >> I think -devel is better. >> For one thing, it's more intuitive. It was proposed that -devel ports should be updated to the latest stable version, if the latest stable version is newer than the latest development version. If we act on this proposal, then "-latest" is more intuitive than "-devel". >> 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? > > Of course, I did not mean to prevent anyone from doing anything ! Just > make it the default if not proven unstable, or mark it as unstable (or > devel) if it is. I agree with you that the latest version must be > available by default, just what do you do when it is broken or breaks > other ports or break the system ? Hey, I dont just hack programs, I > also use them sometimes ^^; > > By the way, I'm a kind of a techie but I also often run into end-users > who end up having macports installed by me because open source should > be for everyone and I just wish they use it on their own and do not > bug me (or you !) about it every time they install/upgrade something. > Maybe we lack resources or feel like hackers but I'm sure we should > definitely not deliberately make things unintuitive / uneasy. MacPorts currently is a bit complicated for casual users. A goal is to improve this. Therefore, we shouldn't now do anything that would make it more difficult for casual users. Not saying that any of these proposals do. Just, keep in mind: even though most of us here now are techies, the reason we're here is not just to use MacPorts but also to improve it to the point that non-techies will feel just as comfortable with it. > Vincent Lefevre wrote: > >> 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). > > Is there a reason for keeping an older version non-devel even when the > -devel version is more stable ? Why not upgrade the default to the > -devel version in this case ? My point of view is : have the latest > version as the default, unless it is quite broken in some way, in this > case make it a -devel version. It's not really the place of a MacPorts port maintainer to second- guess the developer of the software regarding what version is stable enough for a user to use. Some of our non-devel ports do install development versions because the latest releases don't work at all or are years out of date, say. But generally this should not be the case. If you think the latest stable release of a program is not suitable, then you should push the developers to make a new release that is. > Anyway, -devel should mean "for developers" right ? "-devel" does not mean "for developers". It means it is a development version, for anyone who feels they need this rather than the latest stable version. From ryandesign at macports.org Wed Feb 6 21:21:44 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Feb 6 21:21:32 2008 Subject: Marking default variants In-Reply-To: <47A75BCA.60003@macports.org> References: <048.bb2e35ac771ae67b9d76bab86f526b8a@macosforge.org> <47A747AE.7040709@macports.org> <47A75BCA.60003@macports.org> Message-ID: On Feb 4, 2008, at 12:39, Rainer M?ller wrote: > 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. I personally am being consistent in using "(default)" at the end of variant descriptions, when there are a group of conflicting variants (e.g. radio buttons). That is, if I remember to put anything at all, that's what I put. I may have forgotten to put it in some of my ports. I agree it would be better if MacPorts base would figure this out and mark it for us. Then I could remove this from the portfiles. From ryandesign at macports.org Wed Feb 6 22:52:17 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Feb 6 22:52:03 2008 Subject: [MacPorts Lint] Portfile Lint Errors for: dpkg In-Reply-To: <85E69020-3ED0-4F6E-A5A5-4270191AD391@macports.org> References: <20080206131947.3CAAE28082@relay13.apple.com> <2E442036-A7C7-4841-A19B-6A298948ACBF@macports.org> <85E69020-3ED0-4F6E-A5A5-4270191AD391@macports.org> Message-ID: On Feb 6, 2008, at 15:33, Landon Fuller wrote: > On Feb 6, 2008, at 13:23, Ryan Schmidt wrote: > >> There is no detriment that I can discern by naming patchfiles >> "patch-*.diff" as port lint recommends. There is a detriment by >> not following this convention which has been discussed at length >> before on the list. > > There is a detriment. The patchfiles aren't syntax hilighted as C, > and instead are hilighted as a patch file. This is purely a matter > of personal preference, which is a bad reason to dictate policy. But that's just it. It is an error to highlight a diff file as if it were a C file. A diff file is *not* a C file! A C compiler will not compile it. And a C syntax highlighter will not necessarily be able to syntax highlight it correctly. Your own dpkg port gives us a great example in patch-main_archives.c. The patch has three blocks. The last line of context in the second block is the first line of a multiline comment. The last line of the multiline comment is not shown, therefore the C syntax highlighter thinks the entire rest of the file is part of the comment. See: http://www.ryandesign.com/tmp/patch-main_archives.c.png I've given this rationale before, two months ago: http://lists.macosforge.org/pipermail/macports-dev/2007-December/ 003823.html And two months before that: http://lists.macosforge.org/pipermail/macports-dev/2007-October/ 003139.html I guess I'm repeating myself but I don't know what else to do. I feel like I've made all the relevant arguments already. >> This warning has been in port lint for quite some time already. >> It's just now been made an automated email. > > Yes, and getting an e-mail about something I don't think is a > problem is frustrating. Then I guess we need to decide whether it is or is not a problem, and if it isn't, then get rid of the port lint check for this. But I still think it is a problem, for all the reasons I've stated today and earlier, and that port lint should warn. From afb at macports.org Thu Feb 7 01:30:15 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu Feb 7 01:29:47 2008 Subject: universal flags and configuration Message-ID: <7521F750-CE56-4899-BDB6-C96223B14D51@macports.org> I've added some configure. flags for +universal variants, and also to the macports.conf file for providing defaults. They are: - universal_target # for setting macosx_deployment_target and configure target Default: 10.4 - universal_sysroot # the SDK "sysroot" to use, normally for the -isysroot flag Default: /Developer/SDKs/MacOSX10.4u.sdk - universal_archs # machine architectures to use, can be more than just one Default: ppc i386 There are some workarounds for known shortcomings/bugs, such as setting -mmacosx-version-min instead of macosx_deployment_target when the variable don't want to take effect, or adding -syslibroot on PowerPC so that it doesn't forget to use the Intel versions... The additions means that it will now cross-compile when necessary, and that +universal target is meant to generate similar binaries*. By changing the values, it's possible to build for the Leopard SDK and even the Panther SDK (cross-compiling to a previous OS version) Currently these do _not_ affect the MacPorts os. variables, though. These use the currently running operating system, and nothing else (i.e. they aren't affected by changing these universal variables) So it would still say "+darwin_9" and "+i386", even for Panther SDK. However, if you do set the universal_target to a certain version then it will pass matching configure flags to autoconf/automake. For instance, when using the default MacOSX10.4u.sdk, it'll use: configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 It still only works for ports using configure and not hardcoding architecture into generated files (like endianness for instance), and there still needs to be an implementation that will build twice (once for each arch) and then merge the results together. Also left to do is to wire the above settings into Xcode group, by using appropriate parameters to the xcodebuild(1) command... (variables like SYSROOT and ARCHS should be straightforward, and I think the remaining one is MACOSX_DEPLOYMENT_TARGET ?) Thoughts? --anders * this default is a change from MacPorts 1.6.0, that used 10.5 SDK on Leopard and 10.4u SDK on Tiger (but is the same as in 1.5/1.4) From ebgssth at gmail.com Thu Feb 7 05:08:57 2008 From: ebgssth at gmail.com (js) Date: Thu Feb 7 05:08:27 2008 Subject: *-devel ports In-Reply-To: <9BB53729-CC4C-4016-AF58-4DF57F2A59D1@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> <20080204213522.GJ17147@prunille.vinc17.org> <4ec7f0880802050457n2a73b229tef5f4fcc89c0b8b@mail.gmail.com> <4ec7f0880802062021y6f042068s3aca09294ecde9ad@mail.gmail.com> <9BB53729-CC4C-4016-AF58-4DF57F2A59D1@macports.org> Message-ID: On Feb 7, 2008 1:58 PM, Ryan Schmidt wrote: > >> I think -devel is better. > >> For one thing, it's more intuitive. > > It was proposed that -devel ports should be updated to the latest > stable version, if the latest stable version is newer than the latest > development version. If we act on this proposal, then "-latest" is > more intuitive than "-devel". I agree with you, but I think that the situation that devel-ver < stable-ver is very rare. I've never seen it. (By newer, you means the version number is greater, right?) So I don't agree with that proposal. -devel = development is more frequently used so, at least for me, -devel is more natural and intuitive. Actually, I prefer simple name like mysql51 or python30 instead of mysql5-devel or python30-devel, but I found this naming convension is not popular ;) From vincent-opdarw at vinc17.org Thu Feb 7 05:29:20 2008 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Thu Feb 7 05:28:48 2008 Subject: *-devel ports In-Reply-To: <9BB53729-CC4C-4016-AF58-4DF57F2A59D1@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> <20080204213522.GJ17147@prunille.vinc17.org> <4ec7f0880802050457n2a73b229tef5f4fcc89c0b8b@mail.gmail.com> <4ec7f0880802062021y6f042068s3aca09294ecde9ad@mail.gmail.com> <9BB53729-CC4C-4016-AF58-4DF57F2A59D1@macports.org> Message-ID: <20080207132920.GL17147@prunille.vinc17.org> On 2008-02-06 22:58:56 -0600, Ryan Schmidt wrote: > It's not really the place of a MacPorts port maintainer to second-guess > the developer of the software regarding what version is stable enough for > a user to use. The following may be useful to decide: * read the development mailing-list; * see what other distributions do; * look at the date of the latest stable release. For instance, Debian/stable has: * mutt 1.5.13 (the 1.4 stable version was released in May 2002, and there have been a few security fixes since, and I don't even think that all security fixes have been applied to 1.4). * zsh 4.3.2 (the 4.2.0 stable version was released in March 2004, with a few bug fixes since, but no UTF-8 support, while this would be quite important, in particular under Mac OS X, as HFS+ stores filenames in UTF-8). Note that even though Debian distributes a development version of zsh, it also has zsh-beta, which more or less corresponds to the HEAD (and can be installed in parallel). > Some of our non-devel ports do install development versions because > the latest releases don't work at all or are years out of date, say. > But generally this should not be the case. If you think the latest > stable release of a program is not suitable, then you should push > the developers to make a new release that is. I don't think that MacPorts users have enough power. -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From ebgssth at gmail.com Thu Feb 7 05:37:31 2008 From: ebgssth at gmail.com (js) Date: Thu Feb 7 05:37:08 2008 Subject: *-devel ports In-Reply-To: <20080207132920.GL17147@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> <4ec7f0880802050457n2a73b229tef5f4fcc89c0b8b@mail.gmail.com> <4ec7f0880802062021y6f042068s3aca09294ecde9ad@mail.gmail.com> <9BB53729-CC4C-4016-AF58-4DF57F2A59D1@macports.org> <20080207132920.GL17147@prunille.vinc17.org> Message-ID: > > Some of our non-devel ports do install development versions because > > the latest releases don't work at all or are years out of date, say. > > But generally this should not be the case. If you think the latest > > stable release of a program is not suitable, then you should push > > the developers to make a new release that is. > > I don't think that MacPorts users have enough power. Out of date ports means no one uses it. If someone really want it, he/she'll do something about it. From vincent-opdarw at vinc17.org Thu Feb 7 05:50:03 2008 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Thu Feb 7 05:49:33 2008 Subject: *-devel ports In-Reply-To: References: <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> <4ec7f0880802062021y6f042068s3aca09294ecde9ad@mail.gmail.com> <9BB53729-CC4C-4016-AF58-4DF57F2A59D1@macports.org> Message-ID: <20080207135003.GM17147@prunille.vinc17.org> On 2008-02-07 22:08:57 +0900, js wrote: > I agree with you, > but I think that the situation that devel-ver < stable-ver is very > rare. I've never seen it. (By newer, you means the version number is > greater, right?) It happens for tin almost each time a new stable version is released (because it is released before new development work starts). The same thing seems to happen with zsh: http://zsh.dotsrc.org/News/ 4.2.0 (stable) was released on 2004-03-19, a 4.3 (unstable) series was announced on 2005-02-08, and the first 4.3-based version (4.3.1) was released on 2006-02-28. So, for almost two years, the latest version (in term of features and bug fixes) was a stable release! -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From vincent-opdarw at vinc17.org Thu Feb 7 05:52:47 2008 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Thu Feb 7 05:52:15 2008 Subject: *-devel ports In-Reply-To: <20080207135003.GM17147@prunille.vinc17.org> References: <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> <4ec7f0880802062021y6f042068s3aca09294ecde9ad@mail.gmail.com> <9BB53729-CC4C-4016-AF58-4DF57F2A59D1@macports.org> <20080207135003.GM17147@prunille.vinc17.org> Message-ID: <20080207135247.GA11249@prunille.vinc17.org> On 2008-02-07 14:50:03 +0100, Vincent Lefevre wrote: > It happens for tin almost each time a new stable version is released > (because it is released before new development work starts). [...] Here I meant a new stable branch (not just a bug-fix stable version), i.e. a new version of the form x.y.0 with y even. -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From ebgssth at gmail.com Thu Feb 7 06:00:14 2008 From: ebgssth at gmail.com (js) Date: Thu Feb 7 05:59:44 2008 Subject: *-devel ports In-Reply-To: <20080207135003.GM17147@prunille.vinc17.org> References: <20080204145612.GG17147@prunille.vinc17.org> <634664F9-BC97-42C7-98DA-5450F0FF27AF@macports.org> <20080204213522.GJ17147@prunille.vinc17.org> <4ec7f0880802050457n2a73b229tef5f4fcc89c0b8b@mail.gmail.com> <4ec7f0880802062021y6f042068s3aca09294ecde9ad@mail.gmail.com> <9BB53729-CC4C-4016-AF58-4DF57F2A59D1@macports.org> <20080207135003.GM17147@prunille.vinc17.org> Message-ID: If the developer call it as stable and the other's development, Let' follow it. Anyone who like to use newer can easily choose -devel one. On Feb 7, 2008 10:50 PM, Vincent Lefevre wrote: > On 2008-02-07 22:08:57 +0900, js wrote: > > I agree with you, > > but I think that the situation that devel-ver < stable-ver is very > > rare. I've never seen it. (By newer, you means the version number is > > greater, right?) > > It happens for tin almost each time a new stable version is released > (because it is released before new development work starts). The same > thing seems to happen with zsh: > > http://zsh.dotsrc.org/News/ > > 4.2.0 (stable) was released on 2004-03-19, a 4.3 (unstable) series was > announced on 2005-02-08, and the first 4.3-based version (4.3.1) was > released on 2006-02-28. So, for almost two years, the latest version > (in term of features and bug fixes) was a stable release! > > -- > Vincent Lef?vre - Web: > 100% accessible validated (X)HTML - Blog: > Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) > _______________________________________________ > > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev > From milosh at macports.org Thu Feb 7 06:03:25 2008 From: milosh at macports.org (Emmanuel Hainry) Date: Thu Feb 7 06:02:46 2008 Subject: *-devel ports In-Reply-To: References: <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> <4ec7f0880802062021y6f042068s3aca09294ecde9ad@mail.gmail.com> <9BB53729-CC4C-4016-AF58-4DF57F2A59D1@macports.org> Message-ID: <20080207140325.GA9514@weetamoe.loria.fr> Citando js : > On Feb 7, 2008 1:58 PM, Ryan Schmidt wrote: > > >> I think -devel is better. > > >> For one thing, it's more intuitive. > > > > It was proposed that -devel ports should be updated to the latest > > stable version, if the latest stable version is newer than the latest > > development version. If we act on this proposal, then "-latest" is > > more intuitive than "-devel". > > I agree with you, > but I think that the situation that devel-ver < stable-ver is very rare. > I've never seen it. (By newer, you means the version number is greater, right?) > So I don't agree with that proposal. > -devel = development is more frequently used > so, at least for me, -devel is more natural and intuitive. > > Actually, I prefer simple name like > mysql51 or python30 instead of mysql5-devel or python30-devel, but I > found this naming convension is not popular ;) The problem with such names is that to decide which port to install you have to search the project website to know which version is the most suitable for you. Seeing that there are 5 different postgresql port (7, 80, 81, 82, 83) makes me quite puzzled, which one is considered stable? Is the oldest deprecated and only there for backwards compatibility or is it the stable version and all 8x are more or less cutting edge and presumably broken. Is there an even is unstable, odd is stable convention? The irssi, irssi-devel case on the other hand is quite clear, if you want stable, go for irssi, if you need latest features, go for -devel. zsh and mutt are however bad examples as the considered stable version is too old lacks many features (and probably security). I therefore prefer the -devel naming, but would like to have some not tagged stable but proved enough ports to become the stable version (it is up to the maintainer to decide if it should be upgraded or not in the end). Emmanuel From ebgssth at gmail.com Thu Feb 7 06:20:06 2008 From: ebgssth at gmail.com (js) Date: Thu Feb 7 06:19:34 2008 Subject: *-devel ports In-Reply-To: <20080207140325.GA9514@weetamoe.loria.fr> References: <20080204145612.GG17147@prunille.vinc17.org> <634664F9-BC97-42C7-98DA-5450F0FF27AF@macports.org> <20080204213522.GJ17147@prunille.vinc17.org> <4ec7f0880802050457n2a73b229tef5f4fcc89c0b8b@mail.gmail.com> <4ec7f0880802062021y6f042068s3aca09294ecde9ad@mail.gmail.com> <9BB53729-CC4C-4016-AF58-4DF57F2A59D1@macports.org> <20080207140325.GA9514@weetamoe.loria.fr> Message-ID: Naming convention in Debian/GNU Linux solves your problem. Take python for example. They provides a meta package named "python", which requires the stable python (2.4 or 2.5?). That's nice. However, I think achieving it in MacPorts would be quite difficult... On Feb 7, 2008 11:03 PM, Emmanuel Hainry wrote: > Citando js : > > > On Feb 7, 2008 1:58 PM, Ryan Schmidt wrote: > > > >> I think -devel is better. > > > >> For one thing, it's more intuitive. > > > > > > It was proposed that -devel ports should be updated to the latest > > > stable version, if the latest stable version is newer than the latest > > > development version. If we act on this proposal, then "-latest" is > > > more intuitive than "-devel". > > > > I agree with you, > > but I think that the situation that devel-ver < stable-ver is very rare. > > I've never seen it. (By newer, you means the version number is greater, right?) > > So I don't agree with that proposal. > > -devel = development is more frequently used > > so, at least for me, -devel is more natural and intuitive. > > > > Actually, I prefer simple name like > > mysql51 or python30 instead of mysql5-devel or python30-devel, but I > > found this naming convension is not popular ;) > > The problem with such names is that to decide which port to install you > have to search the project website to know which version is the most > suitable for you. Seeing that there are 5 different postgresql port (7, > 80, 81, 82, 83) makes me quite puzzled, which one is considered stable? > Is the oldest deprecated and only there for backwards compatibility or > is it the stable version and all 8x are more or less cutting edge and > presumably broken. Is there an even is unstable, odd is stable > convention? > > The irssi, irssi-devel case on the other hand is quite clear, if you > want stable, go for irssi, if you need latest features, go for -devel. > > zsh and mutt are however bad examples as the considered stable version > is too old lacks many features (and probably security). > > I therefore prefer the -devel naming, but would like to have some not > tagged stable but proved enough ports to become the stable version (it > is up to the maintainer to decide if it should be upgraded or not in the > end). > > Emmanuel > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev > From billitch at gmail.com Thu Feb 7 06:21:41 2008 From: billitch at gmail.com (Thomas de Grivel) Date: Thu Feb 7 06:21:09 2008 Subject: *-devel ports In-Reply-To: <4ec7f0880802070621t9f4acb9j778cdb17cb3e02ef@mail.gmail.com> References: <20080204213522.GJ17147@prunille.vinc17.org> <4ec7f0880802050457n2a73b229tef5f4fcc89c0b8b@mail.gmail.com> <4ec7f0880802062021y6f042068s3aca09294ecde9ad@mail.gmail.com> <9BB53729-CC4C-4016-AF58-4DF57F2A59D1@macports.org> <20080207135003.GM17147@prunille.vinc17.org> <4ec7f0880802070621t9f4acb9j778cdb17cb3e02ef@mail.gmail.com> Message-ID: <4ec7f0880802070621v7e6cf07cu66f7c025c4c08859@mail.gmail.com> 2008/2/7, js : > If the developer call it as stable and the other's development, > Let' follow it. > Anyone who like to use newer can easily choose -devel one. I think we all agree on this (we dont have time to test stability, ffs). 2008/2/7, Ryan Schmidt : >It was proposed that -devel ports should be updated to the latest >stable version, if the latest stable version is newer than the latest >development version. If we act on this proposal, then "-latest" is >more intuitive than "-devel". Ok I see the point. In other terms it is a pointer to a stable or -devel version of the same port, like a virtual package depending on the right one ? I also cannot avoid comparing with Gentoo : they use multiple 'ebuild' files (the converse of a portfile) to reflect the different versions of a package. That done they can mark each version as stable/unstable and allow to install different versions when they have different 'slots' (like for gtk-1 and gtk-2 : they consider it is the same "port" but with a different slot so both can be installed). I dont suggest to rip it off them but that is another existing solution to this problem. Well multiple versions is another larger issue I don't mean to bring here. -- Thomas de Grivel From dluke at geeklair.net Thu Feb 7 06:47:45 2008 From: dluke at geeklair.net (Daniel J. Luke) Date: Thu Feb 7 06:47:22 2008 Subject: *-devel ports In-Reply-To: <20080207140325.GA9514@weetamoe.loria.fr> References: <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> <4ec7f0880802062021y6f042068s3aca09294ecde9ad@mail.gmail.com> <9BB53729-CC4C-4016-AF58-4DF57F2A59D1@macports.org> <20080207140325.GA9514@weetamoe.loria.fr> Message-ID: <905407BF-7D4D-4B8A-ABE6-9F3FC42E7614@geeklair.net> On Feb 7, 2008, at 9:03 AM, Emmanuel Hainry wrote: > Seeing that there are 5 different postgresql port (7, > 80, 81, 82, 83) makes me quite puzzled, which one is considered > stable? Each postgres version in macports has an on-disk format that is incompatible with the next (newer) release. Since macports tries to have only the 'stable' (release) versions of software (unless they're clearly marked as otherwise) the newest one is probably what you want. Postgres has to do this as if there was just a postgres port and a user upgraded from say postgres7 to postgres8, they would be unable to use their existing database and since they probably uninstalled the old postgres when upgrading to the new one, also unable to easily recover. (our upgrade process starting out as a clever hack that would just uninstall the old software and install the new software, doesn't provide hooks to let the portfile author attempt to automatically convert from the old postgres to the new one) -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080207/75451acb/PGP-0001.bin From vincent-opdarw at vinc17.org Thu Feb 7 07:09:51 2008 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Thu Feb 7 07:09:21 2008 Subject: *-devel ports In-Reply-To: References: <20080204145612.GG17147@prunille.vinc17.org> <634664F9-BC97-42C7-98DA-5450F0FF27AF@macports.org> <20080204213522.GJ17147@prunille.vinc17.org> <4ec7f0880802050457n2a73b229tef5f4fcc89c0b8b@mail.gmail.com> <4ec7f0880802062021y6f042068s3aca09294ecde9ad@mail.gmail.com> <9BB53729-CC4C-4016-AF58-4DF57F2A59D1@macports.org> <20080207135003.GM17147@prunille.vinc17.org> Message-ID: <20080207150951.GQ17147@prunille.vinc17.org> On 2008-02-07 23:00:14 +0900, js wrote: > If the developer call it as stable and the other's development, > Let' follow it. > Anyone who like to use newer can easily choose -devel one. However this may be confusing for the end user, as depending on the developers, "unstable" doesn't always mean the same thing. For some of them, it means untested / probably buggy; for others it means changing, but not necessarily more buggy than stable releases (and sometimes even known to be less buggy). -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From vincent-opdarw at vinc17.org Thu Feb 7 07:10:50 2008 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Thu Feb 7 07:10:17 2008 Subject: *-devel ports In-Reply-To: <4ec7f0880802070621v7e6cf07cu66f7c025c4c08859@mail.gmail.com> References: <20080204213522.GJ17147@prunille.vinc17.org> <4ec7f0880802050457n2a73b229tef5f4fcc89c0b8b@mail.gmail.com> <4ec7f0880802062021y6f042068s3aca09294ecde9ad@mail.gmail.com> <9BB53729-CC4C-4016-AF58-4DF57F2A59D1@macports.org> <20080207135003.GM17147@prunille.vinc17.org> <4ec7f0880802070621t9f4acb9j778cdb17cb3e02ef@mail.gmail.com> <4ec7f0880802070621v7e6cf07cu66f7c025c4c08859@mail.gmail.com> Message-ID: <20080207151050.GR17147@prunille.vinc17.org> On 2008-02-07 15:21:41 +0100, Thomas de Grivel wrote: > 2008/2/7, Ryan Schmidt : > >It was proposed that -devel ports should be updated to the latest > >stable version, if the latest stable version is newer than the latest > >development version. If we act on this proposal, then "-latest" is > >more intuitive than "-devel". > > Ok I see the point. In other terms it is a pointer to a stable or > -devel version of the same port, like a virtual package depending on > the right one ? Yes, more or less. -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From vincent-opdarw at vinc17.org Thu Feb 7 07:17:34 2008 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Thu Feb 7 07:17:04 2008 Subject: *-devel ports In-Reply-To: <905407BF-7D4D-4B8A-ABE6-9F3FC42E7614@geeklair.net> References: <20080204145612.GG17147@prunille.vinc17.org> <634664F9-BC97-42C7-98DA-5450F0FF27AF@macports.org> <20080204213522.GJ17147@prunille.vinc17.org> <4ec7f0880802050457n2a73b229tef5f4fcc89c0b8b@mail.gmail.com> <4ec7f0880802062021y6f042068s3aca09294ecde9ad@mail.gmail.com> <9BB53729-CC4C-4016-AF58-4DF57F2A59D1@macports.org> <20080207140325.GA9514@weetamoe.loria.fr> <905407BF-7D4D-4B8A-ABE6-9F3FC42E7614@geeklair.net> Message-ID: <20080207151734.GS17147@prunille.vinc17.org> On 2008-02-07 09:47:45 -0500, Daniel J. Luke wrote: > On Feb 7, 2008, at 9:03 AM, Emmanuel Hainry wrote: >> Seeing that there are 5 different postgresql port (7, >> 80, 81, 82, 83) makes me quite puzzled, which one is considered >> stable? > > Each postgres version in macports has an on-disk format that is > incompatible with the next (newer) release. BTW, there's a similar problem with unison. Should I commit my unison-2.13 port[*] (based on the old unison port)? (I'm not sure the port name follows the right convention if there's one.) [*] http://trac.macosforge.org/projects/macports/ticket/14172 -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From ryandesign at macports.org Thu Feb 7 12:00:36 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Feb 7 12:02:31 2008 Subject: *-devel ports In-Reply-To: <20080207151050.GR17147@prunille.vinc17.org> References: <20080204213522.GJ17147@prunille.vinc17.org> <4ec7f0880802050457n2a73b229tef5f4fcc89c0b8b@mail.gmail.com> <4ec7f0880802062021y6f042068s3aca09294ecde9ad@mail.gmail.com> <9BB53729-CC4C-4016-AF58-4DF57F2A59D1@macports.org> <20080207135003.GM17147@prunille.vinc17.org> <4ec7f0880802070621t9f4acb9j778cdb17cb3e02ef@mail.gmail.com> <4ec7f0880802070621v7e6cf07cu66f7c025c4c08859@mail.gmail.com> <20080207151050.GR17147@prunille.vinc17.org> Message-ID: <5DFCC37F-3A93-4986-B57A-82A19E797A40@macports.org> On Feb 7, 2008, at 09:10, Vincent Lefevre wrote: > On 2008-02-07 15:21:41 +0100, Thomas de Grivel wrote: > >> 2008/2/7, Ryan Schmidt: >> >>> It was proposed that -devel ports should be updated to the latest >>> stable version, if the latest stable version is newer than the >>> latest >>> development version. If we act on this proposal, then "-latest" is >>> more intuitive than "-devel". >> >> Ok I see the point. In other terms it is a pointer to a stable or >> -devel version of the same port, like a virtual package depending on >> the right one ? > > Yes, more or less. Actually no, I was not intending for there to be any virtual packages. Let's do an example. The way it is now, "mysql5" is the latest released version of MySQL (5.0.51) and "mysql5-devel" is the latest development version (5.1.22-rc). Let us now assume for the sake of this example that the next version of MySQL that is released is 5.1.25 and it is considered a released version. To follow our current practices, "mysql5" will be updated to 5.1.25 and "mysql5-devel" will not be updated and will remain at 5.1.22-rc, until a development version of MySQL 5.2 is released. Or maybe it will switch to version 6.0 at that point. The proposal is that when the hypothetical stable version 5.1.25 is released, "mysql5" will be updated to 5.1.25, and "mysql5-devel" will also be updated to 5.1.25. Both ports will then be identical until the next development release. From ryandesign at macports.org Thu Feb 7 12:10:52 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Feb 7 12:10:42 2008 Subject: *-devel ports In-Reply-To: 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> <4ec7f0880802062021y6f042068s3aca09294ecde9ad@mail.gmail.com> <9BB53729-CC4C-4016-AF58-4DF57F2A59D1@macports.org> Message-ID: On Feb 7, 2008, at 07:08, js wrote: > On Feb 7, 2008 1:58 PM, Ryan Schmidt wrote: > >>>> I think -devel is better. >>>> For one thing, it's more intuitive. >> >> It was proposed that -devel ports should be updated to the latest >> stable version, if the latest stable version is newer than the latest >> development version. If we act on this proposal, then "-latest" is >> more intuitive than "-devel". > > I agree with you, > but I think that the situation that devel-ver < stable-ver is very > rare. > I've never seen it. (By newer, you means the version number is > greater, right?) Then let me acquaint you with our ports tree: boehmgc (7.0) is newer than boehmgc-devel (6.3alpha6) php5 (5.2.5) is newer than php5-devel (5.2.5RC2) swi-prolog (5.6.50) is newer than swi-prolog-devel (5.5.36) sylpheed (2.2.3) is newer than sylpheed-devel (2.2.0beta7) tin (1.8.3) is newer than tin-devel (1.7.10) wxWidgets (2.8.7) is newer than wxWidgets-devel (2.8.6-rc1) yap (5.0.1) is newer than yap-devel (4.5.6) zeroinstall-injector (0.31) is newer than zeroinstall-injector-devel (0.30) Some ports are already updating the -devel port to the same version as the regular port: Etoile (0.1.9) and Etoile-devel (0.1.9) mpd (0.13.1) and mpd-devel (0.13.1) From ryandesign at macports.org Thu Feb 7 16:16:02 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Feb 7 16:16:42 2008 Subject: universal flags and configuration In-Reply-To: <7521F750-CE56-4899-BDB6-C96223B14D51@macports.org> References: <7521F750-CE56-4899-BDB6-C96223B14D51@macports.org> Message-ID: On Feb 7, 2008, at 03:30, Anders F Bj?rklund wrote: > I've added some configure. flags for +universal variants, > and also to the macports.conf file for providing defaults. > > They are: > > - universal_target > # for setting macosx_deployment_target and configure target > Default: 10.4 > > - universal_sysroot > # the SDK "sysroot" to use, normally for the -isysroot flag > Default: /Developer/SDKs/MacOSX10.4u.sdk > > - universal_archs > # machine architectures to use, can be more than just one > Default: ppc i386 > > > There are some workarounds for known shortcomings/bugs, such as > setting -mmacosx-version-min instead of macosx_deployment_target > when the variable don't want to take effect, The documentation I've read says to use MACOSX_DEPLOYMENT_TARGET environment variable. When is this -mmacosx-version-min applicable instead? > or adding -syslibroot > on PowerPC so that it doesn't forget to use the Intel versions... Apple documentation on building universal binaries from configure- based software used to mention -syslibroot but this was removed quite some time ago. When is it still applicable? > The additions means that it will now cross-compile when necessary, As I understand it, cross-compiling is compiling for a platform other than the one on which the compiler is running. Haven't we already been doing that when building universal binaries? > and that +universal target is meant to generate similar binaries*. > By changing the values, it's possible to build for the Leopard SDK > and even the Panther SDK (cross-compiling to a previous OS version) > > Currently these do _not_ affect the MacPorts os. variables, though. > These use the currently running operating system, and nothing else > (i.e. they aren't affected by changing these universal variables) > So it would still say "+darwin_9" and "+i386", even for Panther SDK. > > However, if you do set the universal_target to a certain version > then it will pass matching configure flags to autoconf/automake. > For instance, when using the default MacOSX10.4u.sdk, it'll use: > configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 What problem does setting --host and --target solve? Because for me it's causing a problem, namely that glib2 doesn't build universal anymore. I traced this failure back to r33483 in which you added the --host and --target switches. With trunk r33482 (without those switches), glib2 builds universal. With trunk r33483 (with them), it does not. Possibly suspicious output from glib2's ./configure at the beginning: configure: WARNING: If you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used. Definitely suspicious output from glib2's ./configure: checking whether to use assembler code for atomic operations... i486 With r33482 it says: checking whether to use assembler code for atomic operations... none Definitely suspicious output from glib2's make at the end: /usr/bin/gcc-4.0 -DHAVE_CONFIG_H -I. -I. -I.. -I.. -DG_LOG_DOMAIN= \"GLib\" -DG_DISABLE_CAST_CHECKS -DG_DISABLE_DEPRECATED - DGLIB_COMPILATION -DPCRE_STATIC -I/opt/local/include -isysroot / Developer/SDKs/MacOSX10.4u.sdk -D_REENTRANT -O2 -funroll-loops - fstrict-aliasing -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc - arch i386 -Wall -c gatomic.c -fno-common -DPIC -o .libs/gatomic.o gatomic.c: In function 'g_atomic_int_compare_and_exchange': gatomic.c:66: error: impossible constraint in 'asm' lipo: can't figure out the architecture type of: /var/tmp//ccmwc7KI.out make[4]: *** [gatomic.lo] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 From raimue at macports.org Thu Feb 7 16:42:39 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu Feb 7 16:42:09 2008 Subject: universal flags and configuration In-Reply-To: References: <7521F750-CE56-4899-BDB6-C96223B14D51@macports.org> Message-ID: <47ABA57F.6070704@macports.org> Ryan Schmidt wrote: >> There are some workarounds for known shortcomings/bugs, such as >> setting -mmacosx-version-min instead of macosx_deployment_target >> when the variable don't want to take effect, > > The documentation I've read says to use MACOSX_DEPLOYMENT_TARGET > environment variable. When is this -mmacosx-version-min applicable instead? As far as I know, it is possible to either use MACOSX_DEPLOYMENT_TARGET as env var or directly pass -mmacosx-version-min to gcc. But the latter takes preference over the former. Rainer From ryandesign at macports.org Thu Feb 7 18:20:41 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Feb 7 18:42:26 2008 Subject: Trac and Subversion down? Message-ID: Trac has been very slow lately, but right now it's not responding at all: The operation timed out when attempting to contact trac.macosforge.org. The requested site did not respond to a connection request and Camino has stopped waiting for a reply. and neither is Subversion: gnucash $ svn log svn: PROPFIND request failed on '/repository/macports/trunk/dports/ gnome/gnucash' svn: PROPFIND of '/repository/macports/trunk/dports/gnome/gnucash': could not connect to server (http://svn.macosforge.org) gnucash $ From wsiegrist at apple.com Thu Feb 7 18:44:49 2008 From: wsiegrist at apple.com (William Siegrist) Date: Thu Feb 7 18:46:23 2008 Subject: Trac and Subversion down? In-Reply-To: References: Message-ID: <01B58F95-1690-41E8-971E-6886603A1EE5@apple.com> Sorry, emergency maintenance. Its all back now, let me know if you still have trouble. The short notice was due to the general slowness you mentioned. I'll be doing some more stuff over the next few days too to try and help. -Bill On Feb 7, 2008, at 6:20 PM, Ryan Schmidt wrote: > Trac has been very slow lately, but right now it's not responding at > all: > > The operation timed out when attempting to contact > trac.macosforge.org. > The requested site did not respond to a connection request and > Camino has stopped waiting for a reply. > > and neither is Subversion: > > gnucash $ svn log > svn: PROPFIND request failed on '/repository/macports/trunk/dports/ > gnome/gnucash' > svn: PROPFIND of '/repository/macports/trunk/dports/gnome/gnucash': > could not connect to server (http://svn.macosforge.org) > gnucash $ > > ---- 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/20080207/65b7ee4c/smime.bin From ryandesign at macports.org Thu Feb 7 19:12:08 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Feb 7 19:12:30 2008 Subject: Trac and Subversion down? In-Reply-To: <01B58F95-1690-41E8-971E-6886603A1EE5@apple.com> References: <01B58F95-1690-41E8-971E-6886603A1EE5@apple.com> Message-ID: <61B4441B-A697-4B8D-8230-BF38525AD263@macports.org> Super, thanks! It seems to be back up for now. On Feb 7, 2008, at 20:44, William Siegrist wrote: > Sorry, emergency maintenance. Its all back now, let me know if you > still have trouble. The short notice was due to the general > slowness you mentioned. I'll be doing some more stuff over the > next few days too to try and help. > > On Feb 7, 2008, at 6:20 PM, Ryan Schmidt wrote: > >> Trac has been very slow lately, but right now it's not responding >> at all: >> >> The operation timed out when attempting to contact >> trac.macosforge.org. >> The requested site did not respond to a connection request and >> Camino has stopped waiting for a reply. >> >> and neither is Subversion: >> >> gnucash $ svn log >> svn: PROPFIND request failed on '/repository/macports/trunk/dports/ >> gnome/gnucash' >> svn: PROPFIND of '/repository/macports/trunk/dports/gnome/ >> gnucash': could not connect to server (http://svn.macosforge.org) >> gnucash $ From ryandesign at macports.org Thu Feb 7 19:48:23 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Feb 7 19:48:46 2008 Subject: [33938] trunk/base/src/macports1.0/macports.tcl In-Reply-To: <20080208033458.4F72C1046DD5@beta.macosforge.org> References: <20080208033458.4F72C1046DD5@beta.macosforge.org> Message-ID: <1AEE4534-AE1B-4A45-8361-78376AA44AD0@macports.org> On Feb 7, 2008, at 21:34, raimue@macports.org wrote: > Revision: 33938 > http://trac.macosforge.org/projects/macports/changeset/33938 > Author: raimue@macports.org > Date: 2008-02-07 19:34:55 -0800 (Thu, 07 Feb 2008) > > Log Message: > ----------- > macports1.0/macports.tcl: > Add --prepend option to selfupdate, which will check if an update > is necessary. > I had to rearrange some things in order to present nice output. What is being prepended to what? Or did you mean "pretend"? From raimue at macports.org Thu Feb 7 19:54:49 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu Feb 7 19:54:53 2008 Subject: [33938] trunk/base/src/macports1.0/macports.tcl In-Reply-To: <1AEE4534-AE1B-4A45-8361-78376AA44AD0@macports.org> References: <20080208033458.4F72C1046DD5@beta.macosforge.org> <1AEE4534-AE1B-4A45-8361-78376AA44AD0@macports.org> Message-ID: <47ABD289.70903@macports.org> Ryan Schmidt wrote: > What is being prepended to what? Or did you mean "pretend"? Ouch. Of course I meant that! Somehow I got it wrong and didn't notice it at all. Sorry... Thanks, I am going to fix this. Rainer From billitch at gmail.com Thu Feb 7 23:16:30 2008 From: billitch at gmail.com (Thomas de Grivel) Date: Thu Feb 7 23:16:33 2008 Subject: *-devel ports In-Reply-To: <4ec7f0880802072315k122ff460ja1bf00db95b407f5@mail.gmail.com> References: <20080204213522.GJ17147@prunille.vinc17.org> <9BB53729-CC4C-4016-AF58-4DF57F2A59D1@macports.org> <20080207135003.GM17147@prunille.vinc17.org> <4ec7f0880802070621t9f4acb9j778cdb17cb3e02ef@mail.gmail.com> <4ec7f0880802070621v7e6cf07cu66f7c025c4c08859@mail.gmail.com> <20080207151050.GR17147@prunille.vinc17.org> <5DFCC37F-3A93-4986-B57A-82A19E797A40@macports.org> <4ec7f0880802072315k122ff460ja1bf00db95b407f5@mail.gmail.com> Message-ID: <4ec7f0880802072316p3cd83412i65788fc195d5203d@mail.gmail.com> 2008/2/7, Ryan Schmidt : > > On Feb 7, 2008, at 09:10, Vincent Lefevre wrote: > > > On 2008-02-07 15:21:41 +0100, Thomas de Grivel wrote: > > > >> 2008/2/7, Ryan Schmidt: > >> > >>> It was proposed that -devel ports should be updated to the latest > >>> stable version, if the latest stable version is newer than the > >>> latest > >>> development version. If we act on this proposal, then "-latest" is > >>> more intuitive than "-devel". > >> > >> Ok I see the point. In other terms it is a pointer to a stable or > >> -devel version of the same port, like a virtual package depending on > >> the right one ? > > > > Yes, more or less. > > Actually no, I was not intending for there to be any virtual packages. > > Let's do an example. The way it is now, "mysql5" is the latest > released version of MySQL (5.0.51) and "mysql5-devel" is the latest > development version (5.1.22-rc). Let us now assume for the sake of > this example that the next version of MySQL that is released is > 5.1.25 and it is considered a released version. To follow our current > practices, "mysql5" will be updated to 5.1.25 and "mysql5-devel" will > not be updated and will remain at 5.1.22-rc, until a development > version of MySQL 5.2 is released. Or maybe it will switch to version > 6.0 at that point. > > The proposal is that when the hypothetical stable version 5.1.25 is > released, "mysql5" will be updated to 5.1.25, and "mysql5-devel" will > also be updated to 5.1.25. Both ports will then be identical until > the next development release. Put this way indeed it really sounds right. Sorry if I misunderstood the other explanations. -- Thomas de Grivel From afb at macports.org Fri Feb 8 01:39:14 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Fri Feb 8 01:39:27 2008 Subject: universal flags and configuration In-Reply-To: References: <7521F750-CE56-4899-BDB6-C96223B14D51@macports.org> Message-ID: <81D7D278-3925-4040-9719-D156458F42C9@macports.org> Ryan Schmidt wrote: >> There are some workarounds for known shortcomings/bugs, such as >> setting -mmacosx-version-min instead of macosx_deployment_target >> when the variable don't want to take effect, > > The documentation I've read says to use MACOSX_DEPLOYMENT_TARGET > environment variable. When is this -mmacosx-version-min applicable > instead? MACOSX_DEPLOYMENT_TARGET is deprecated (but still working), it's just that I had a problem with MacPorts onot setting the environment variables probably so I went for overkill and included the parameter explicitly on Leopard to avoid linker problems with crt1.10.5.o. They both do the same thing, so if the variable had just been set OK then setting the parameter for gcc wouldn't have been needed... >> or adding -syslibroot >> on PowerPC so that it doesn't forget to use the Intel versions... > > Apple documentation on building universal binaries from configure- > based software used to mention -syslibroot but this was removed > quite some time ago. When is it still applicable? It doesn't apply when building on Intel, since there it can load the system libraries without problems. It does apply sometimes on PowerPC, when it doesn't get the -isysroot flag alright, as it will try to use system libraries and fail to link because those libraries are missing the i386 architecture. Including this parameter explicitly made sure that it linked with the libs from the SDK - not system. >> The additions means that it will now cross-compile when necessary, > > As I understand it, cross-compiling is compiling for a platform > other than the one on which the compiler is running. Haven't we > already been doing that when building universal binaries? Sortof, but not all the flags were pointing in the same direction... That was "hidden" by setting the SDK version to the same as the system, since then it would always match up - even if using the wrong one... (i.e. if using 10.4u SDK on 10.4 OS and 10.5 SDK on 10.5 OS, then it doesn't matter if some values are gotten from the system instead of sdk) Besides, by setting all flags you can build for PowerPC on Intel say. Like compile Panther/PPC binaries from your Leopard/x86 installation ? >> However, if you do set the universal_target to a certain version >> then it will pass matching configure flags to autoconf/automake. >> For instance, when using the default MacOSX10.4u.sdk, it'll use: >> configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 > > What problem does setting --host and --target solve? Because for me > it's causing a problem, namely that glib2 doesn't build universal > anymore. I traced this failure back to r33483 in which you added > the --host and --target switches. With trunk r33482 (without those > switches), glib2 builds universal. With trunk r33483 (with them), > it does not. Oops, the port I tested with didn't have any such arch-specific code... Fixed now, in r33947. It will probably still do the wrong thing, though. > Possibly suspicious output from glib2's ./configure at the beginning: > > configure: WARNING: If you wanted to set the --build type, don't > use --host. > If a cross compiler is detected then cross compile mode will be > used. This is OK, as maybe we *wanted* to do a cross-compile. > Definitely suspicious output from glib2's ./configure: > > checking whether to use assembler code for atomic operations... i486 This is actually a problem when building universal. Setting arch stuff at configure time is bound to break later on, when building for the other. i.e. here it says "use i486", and then it'll try to use that with ppc. Usually such ports will need to be configured/built twice, and merged. > Definitely suspicious output from glib2's make at the end: > > /usr/bin/gcc-4.0 -DHAVE_CONFIG_H -I. -I. -I.. -I.. -DG_LOG_DOMAIN= > \"GLib\" -DG_DISABLE_CAST_CHECKS -DG_DISABLE_DEPRECATED - > DGLIB_COMPILATION -DPCRE_STATIC -I/opt/local/include -isysroot / > Developer/SDKs/MacOSX10.4u.sdk -D_REENTRANT -O2 -funroll-loops - > fstrict-aliasing -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch > ppc -arch i386 -Wall -c gatomic.c -fno-common -DPIC -o .libs/ > gatomic.o > gatomic.c: In function 'g_atomic_int_compare_and_exchange': > gatomic.c:66: error: impossible constraint in 'asm' > lipo: can't figure out the architecture type of: /var/tmp// > ccmwc7KI.out > make[4]: *** [gatomic.lo] Error 1 > make[3]: *** [all-recursive] Error 1 > make[2]: *** [all] Error 2 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 This is not suspicious, it is plain wrong :-) Or at least it broke. It was trying to build x86 asm for ppc, which doesn't really fly... Should be back to previous behaviour with the above change to trunk. (i.e. not passing any --host and --build when building fat binaries) --anders PS. It might be a bit overengineered to just build "Universal Binaries". But now it should also work for cross-compiling, and building twice. From ebgssth at gmail.com Fri Feb 8 03:48:05 2008 From: ebgssth at gmail.com (js) Date: Fri Feb 8 03:48:11 2008 Subject: *-devel ports In-Reply-To: References: <92E586B9-4F46-47FE-9935-A7F903614C2F@macports.org> <20080204145612.GG17147@prunille.vinc17.org> <634664F9-BC97-42C7-98DA-5450F0FF27AF@macports.org> <20080204213522.GJ17147@prunille.vinc17.org> <4ec7f0880802050457n2a73b229tef5f4fcc89c0b8b@mail.gmail.com> <4ec7f0880802062021y6f042068s3aca09294ecde9ad@mail.gmail.com> <9BB53729-CC4C-4016-AF58-4DF57F2A59D1@macports.org> Message-ID: > Then let me acquaint you with our ports tree: > > boehmgc (7.0) is newer than boehmgc-devel (6.3alpha6) > php5 (5.2.5) is newer than php5-devel (5.2.5RC2) > swi-prolog (5.6.50) is newer than swi-prolog-devel (5.5.36) > sylpheed (2.2.3) is newer than sylpheed-devel (2.2.0beta7) > tin (1.8.3) is newer than tin-devel (1.7.10) > wxWidgets (2.8.7) is newer than wxWidgets-devel (2.8.6-rc1) > yap (5.0.1) is newer than yap-devel (4.5.6) > zeroinstall-injector (0.31) is newer than zeroinstall-injector-devel > (0.30) > > Some ports are already updating the -devel port to the same version > as the regular port: > > Etoile (0.1.9) and Etoile-devel (0.1.9) > mpd (0.13.1) and mpd-devel (0.13.1) There's newer boehmgc (7.1), newer php (5.2-dev and 5.3) and so on. So if someone wants "real" devel ports, it will be. From afb at macports.org Fri Feb 8 08:03:52 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Fri Feb 8 08:03:58 2008 Subject: *-devel ports In-Reply-To: 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> <4ec7f0880802062021y6f042068s3aca09294ecde9ad@mail.gmail.com> <9BB53729-CC4C-4016-AF58-4DF57F2A59D1@macports.org> Message-ID: <63330389-D558-46C6-8940-93C2845C15BC@macports.org> Ryan Schmidt wrote: > Then let me acquaint you with our ports tree: ... > zeroinstall-injector (0.31) is newer than zeroinstall-injector- > devel (0.30) This port (zeroinstall-injector-devel) built from tip-of-trunk with some experimental configuration (shared cache between users and with full i18n). However, upstream moved to GIT instead of SVN and MacPorts doesn't support that as easily and the code patches weren't updated to the latest version... Rather than delete the code, it was left as-was with the older release. Maybe it could be continued and updated later, maybe it should be deleted. Either way, it doesn't install the exact same thing as the non-devel port. So it's just not the version number that differed between the two ports. --anders From ryandesign at macports.org Fri Feb 8 10:10:02 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri Feb 8 10:10:35 2008 Subject: [33954] trunk/dports/lang/sbcl In-Reply-To: <20080208162230.454F8107757B@beta.macosforge.org> References: <20080208162230.454F8107757B@beta.macosforge.org> Message-ID: On Feb 8, 2008, at 10:22, waqar@macports.org wrote: > Revision: 33954 > http://trac.macosforge.org/projects/macports/changeset/33954 > Author: waqar@macports.org > Date: 2008-02-08 08:22:20 -0800 (Fri, 08 Feb 2008) > > Log Message: > ----------- > Fixed to appease the lint. [snip] > Modified: trunk/dports/lang/sbcl/Portfile > =================================================================== > --- trunk/dports/lang/sbcl/Portfile 2008-02-08 15:27:53 UTC (rev > 33953) > +++ trunk/dports/lang/sbcl/Portfile 2008-02-08 16:22:20 UTC (rev > 33954) > @@ -1,9 +1,11 @@ > # $Id$ > > PortSystem 1.0 > + > name sbcl > version 1.0.14 > set bootversion 0.9.16 > +revision 1 > categories lang > maintainers gwright@macports.org waqar@macports.org > platforms darwin Why "revision 1"? I thought you just changed patchfile names and fixed whitespace and such. The installed product should not have changed. From raimue at macports.org Fri Feb 8 16:25:47 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri Feb 8 16:25:53 2008 Subject: New port config could make MacPorts' setup much easier Message-ID: <47ACF30B.5070804@macports.org> Hi, I am thinking about a new port config target, which could make setting up MacPorts much easier. Currently, the appropriate variables for PATH, MANPATH and DISPLAY are determined in the postflight script. If we would move that into a port config target (or port setup, the name is open for discussion), the manual setup process would become easier. To get the env vars needed for your system, you would type: port config --envvars which would output: export PATH=/opt/local/bin:/opt/local/sbin:$PATH export MANPATH=/opt/local/share/man:$MANPATH But to support multiple shells, this could be extended to also allow port config --envvars --tcsh which would output: setenv PATH /opt/local/bin:/opt/local/sbin/:$PATH setenv MANPATH /opt/local/share/man:$MANPATH So the default should be auto-guessing which shell to use (current $SHELL). There could be support for a lot of shells people are using. The env vars which would be exported will be depending on the system this runs on, e.g.: Leopard: PATH and MANPATH Tiger/Panther: PATH, MANPATH and DISPLAY Another switch, port config --profile could output the profile file of the current running shell. This would be .tcshrc for tcsh, .bash_profile for bash, .zshrc for zsh and maybe others, too. So after all setting up MacPorts could become just this line: /opt/local/bin/port config --envvars >> \ $(/opt/local/bin/port config --profile) Or a command /opt/local/port config --setup could do it all automatically. The main purpose would be that we are moving this away from the dmg installer and into base itself. So even if the installer postflight script fails in future again, there would be an easy option to setup MacPorts. Additionally this could also be useful for users installing from source. As the postflight script is broken in the 1.6.0 dmg, we have seen a lot of people on IRC and the users mailing list looking for help how to get MacPorts running. Telling them "set up your PATH manually" sounds too complicated for some users and they might quit using MacPorts at all. What do you think about such an option? Rainer From afb at macports.org Sat Feb 9 03:16:06 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sat Feb 9 03:16:17 2008 Subject: New port config could make MacPorts' setup much easier In-Reply-To: <47ACF30B.5070804@macports.org> References: <47ACF30B.5070804@macports.org> Message-ID: Rainer M?ller wrote: > I am thinking about a new port config target, which could make setting > up MacPorts much easier. Currently, the appropriate variables for > PATH, > MANPATH and DISPLAY are determined in the postflight script. If we > would > move that into a port config target (or port setup, the name is > open for > discussion), the manual setup process would become easier. You probably want those to read /opt/local/bin/port then, if the purpose of the command would be to make it find port(1) in the first place ? :-) Q: Does DISPLAY have to be fixed by MacPorts, just because Apple missed it ? (I'm already setting stuff like $JAVA_HOME, $DISPLAY and $EDITOR outside...) But I'm in the minority that don't want my $PATH automatically set up for me either, unless/until I explicitly enable the use of MacPorts by adding it. > The main purpose would be that we are moving this away from the dmg > installer and into base itself. So even if the installer postflight > script fails in future again, there would be an easy option to > setup MacPorts. Additionally this could also be useful for users > installing from source. Or there could be a simple script that you could source from your profile, maybe it could be called something like "init.sh" or "init.csh" ? (hint, hint*) Then the profile hacking could be limited to 1 line sourcing this script ? If the postflight fails, then it would also be easier to add it manually... It also makes it easier to only "enable" MacPorts when you actually want to. Like if you want to be able to run _both_ MacPorts and Fink, and others too. > As the postflight script is broken in the 1.6.0 dmg, we have seen a > lot of people on IRC and the users mailing list looking for help > how to get MacPorts running. Telling them "set up your PATH > manually" sounds too complicated for some users and they might quit > using MacPorts at all. The guide probably needs to have an optional section describing how to set up your shell profile and how to sync ports, in case the automatic procedure fails ? Theoretically you might want to get your ports tree in some other fashion too, like running off the archive or updating through subversion or using a portpkg... So breaking the installation down into those three distinctive steps might help with the understanding ? (1. install base, 2. setup profile, 3. port selfupdate) --anders * yes, just like http://www.finkproject.org/doc/users-guide/ install.php#setup From raimue at macports.org Sat Feb 9 04:44:42 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat Feb 9 04:44:47 2008 Subject: New port config could make MacPorts' setup much easier In-Reply-To: References: <47ACF30B.5070804@macports.org> Message-ID: <47ADA03A.4000909@macports.org> Anders F Bj?rklund wrote: > Rainer M?ller wrote: > >> I am thinking about a new port config target, which could make setting >> up MacPorts much easier. Currently, the appropriate variables for PATH, >> MANPATH and DISPLAY are determined in the postflight script. If we would >> move that into a port config target (or port setup, the name is open for >> discussion), the manual setup process would become easier. > > You probably want those to read /opt/local/bin/port then, if the purpose > of the command would be to make it find port(1) in the first place ? :-) Of course. I just wrote "port config" for easier reading. > Q: Does DISPLAY have to be fixed by MacPorts, just because Apple missed > it ? > (I'm already setting stuff like $JAVA_HOME, $DISPLAY and $EDITOR > outside...) No, we do not have to fix it, but it would be nice for newbies. Experienced users could of course tweak these settings. I am also setting EDITOR myself, but that is a personal preference. DISPLAY has to be set for all users to the same value (:0.0), so we could fix it for them. > Or there could be a simple script that you could source from your profile, > maybe it could be called something like "init.sh" or "init.csh" ? (hint, > hint*) This sounds like a good solution, too. I am mainly just asking for a fallback if postflight failed, as we currently have none. > Then the profile hacking could be limited to 1 line sourcing this script ? > If the postflight fails, then it would also be easier to add it manually... One line would be ok. Currently it requires you to understand what PATH, MANPATH and DISPLAY actually do. And you have to decide which one of them you have to set. > It also makes it easier to only "enable" MacPorts when you actually want > to. > Like if you want to be able to run _both_ MacPorts and Fink, and others > too. Hm, I don't think it is a good idea to run MacPorts and Fink together... Many configure scripts just check for /opt/local or /sw for libraries and you will end up with a mixture of cross linked binaries. > The guide probably needs to have an optional section describing how to > set up > your shell profile and how to sync ports, in case the automatic > procedure fails ? There is http://guide.macports.org/#installing.shell But that's not a good explanation currently. At all it was not even clear for users I helped that they had to edit a file. > Theoretically you might want to get your ports tree in some other > fashion too, > like running off the archive or updating through subversion or using a > portpkg... > > So breaking the installation down into those three distinctive steps > might help > with the understanding ? (1. install base, 2. setup profile, 3. port > selfupdate) This sounds like a good idea. But I have to admit that I have no knowledge about docbook at all. I would be glad helping out making better documentation steps, but someone else would have to lead it. I agree that my proposal could also be just written to a static file, as the env vars are not going to change after install. Therefore I step back from port config and vote for a shell script and better documentation for setup. Rainer From ram at macports.org Sat Feb 9 08:24:10 2008 From: ram at macports.org (Adam Mercer) Date: Sat Feb 9 08:24:08 2008 Subject: New port config could make MacPorts' setup much easier In-Reply-To: <47ADA03A.4000909@macports.org> References: <47ACF30B.5070804@macports.org> <47ADA03A.4000909@macports.org> Message-ID: <799406d60802090824x44202368maf06828d842172d2@mail.gmail.com> On Feb 9, 2008 7:44 AM, Rainer M?ller wrote: > > Q: Does DISPLAY have to be fixed by MacPorts, just because Apple missed > > it ? > > (I'm already setting stuff like $JAVA_HOME, $DISPLAY and $EDITOR > > outside...) > > No, we do not have to fix it, but it would be nice for newbies. > Experienced users could of course tweak these settings. I am also > setting EDITOR myself, but that is a personal preference. DISPLAY has to > be set for all users to the same value (:0.0), so we could fix it for them. DISPLAY should not be set for Leopard, otherwise X won't work correctly. Cheers Adam From raimue at macports.org Sat Feb 9 08:31:25 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat Feb 9 08:31:34 2008 Subject: New port config could make MacPorts' setup much easier In-Reply-To: <799406d60802090824x44202368maf06828d842172d2@mail.gmail.com> References: <47ACF30B.5070804@macports.org> <47ADA03A.4000909@macports.org> <799406d60802090824x44202368maf06828d842172d2@mail.gmail.com> Message-ID: <47ADD55D.1010108@macports.org> Adam Mercer wrote: > DISPLAY should not be set for Leopard, otherwise X won't work correctly. Yes, I was talking about DISPLAY on Tiger/Panther only. Therefore a init.sh/init.csh written by the installation should only contain env vars applicable to the current Mac OS X version. Rainer From ryandesign at macports.org Sat Feb 9 11:14:43 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat Feb 9 11:15:12 2008 Subject: [33981] trunk/dports/net/transmission-x11/Portfile In-Reply-To: <20080209190513.97DA410B13D0@beta.macosforge.org> References: <20080209190513.97DA410B13D0@beta.macosforge.org> Message-ID: <33A4235A-CA7F-45CE-84DD-B396CEF33464@macports.org> For future changes, could I ask you to do whitespace changes in a separate commit please? Otherwise it's hard to see what functional changes were made in a revision. Thanks. On Feb 9, 2008, at 13:05, gui_dos@macports.org wrote: > Revision: 33981 > http://trac.macosforge.org/projects/macports/changeset/33981 > Author: gui_dos@macports.org > Date: 2008-02-09 11:05:12 -0800 (Sat, 09 Feb 2008) > > Log Message: > ----------- > transmission-x11: > * Update to 1.05 > * Stripped the double \n in the long_description wich > introduced a pair of brackets when evaluated, confusing > the activation phase > * Added dependency on OpenSSL > * Avoid building Cocoa and wxWidgets' versions > > Modified Paths: > -------------- > trunk/dports/net/transmission-x11/Portfile > > Modified: trunk/dports/net/transmission-x11/Portfile > =================================================================== > --- trunk/dports/net/transmission-x11/Portfile 2008-02-09 17:52:05 > UTC (rev 33980) > +++ trunk/dports/net/transmission-x11/Portfile 2008-02-09 19:05:12 > UTC (rev 33981) > @@ -1,26 +1,29 @@ > # $Id$ > > -PortSystem 1.0 > +PortSystem 1.0 > > -name transmission-x11 > -version 1.03 > -revision 1 > -categories net gnome x11 > -maintainers nomaintainer > -description Lightweight BitTorrent client > -long_description Transmission is a free, lightweight BitTorrent > client. \ > - It features a simple, intuitive interface on top of an \ > - efficient, cross-platform back-end. Transmission is open \ > - source (MIT license) and runs on Mac OS X (Cocoa interface), \ > - Linux/NetBSD/FreeBSD/OpenBSD (GTK+ interface) and BeOS \ > - (native interface). \n\n\ > - This is the GTK+ version. > -homepage http://www.transmissionbt.com/ > +name transmission-x11 > +version 1.05 > +categories net gnome x11 > +maintainers nomaintainer > +description Lightweight BitTorrent client > +long_description Transmission is a free, lightweight BitTorrent > client. \ > + It features a simple, intuitive interface on top > of an \ > + efficient, cross-platform back-end. Transmission > is open \ > + source (MIT license) and runs on Mac OS X (Cocoa > interface), \ > + Linux/NetBSD/FreeBSD/OpenBSD (GTK+ interface) and > BeOS \ > + (native interface). This is the GTK+ version. > +homepage http://www.transmissionbt.com/ > +distname transmission-${version} > +master_sites http://download.m0k.org/transmission/files/ > +checksums md5 3baf5be0d4fe2a0e0e0e43b7b0fe5dcb > +use_bzip2 yes > +platforms darwin freebsd > +depends_lib port:gettext port:gtk port:openssl > > -master_sites http://download.m0k.org/transmission/files/ > -checksums md5 f9189da1352483aed9f6736498443de3 > -use_bzip2 yes > - > -platforms darwin freebsd > - > -depends_lib port:gettext port:gtk > +configure.args --without-wx > +# Force avoiding the Cocoa build > +post-extract { > + reinplace "s|macosx/Makefile| |g" ${worksrcpath}/configure > + reinplace "s|macosx||g" ${worksrcpath}/Makefile.in > +} From ryandesign at macports.org Sat Feb 9 11:17:50 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat Feb 9 11:18:14 2008 Subject: [33980] trunk/dports/devel In-Reply-To: <20080209175206.F1D2910AED63@beta.macosforge.org> References: <20080209175206.F1D2910AED63@beta.macosforge.org> Message-ID: <1A385B5C-488F-4E95-98CB-0FE77A4537C1@macports.org> On Feb 9, 2008, at 11:52, brett@macports.org wrote: > including the modeline as instructed on the -dev list, despite it > not passing lint FYI: This incorrect lint warning has already been corrected in MacPorts trunk. From ryandesign at macports.org Sat Feb 9 17:18:54 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat Feb 9 17:19:11 2008 Subject: [33998] trunk/dports/net/pidgin/Portfile In-Reply-To: <20080210011441.B14FC10C0E4B@beta.macosforge.org> References: <20080210011441.B14FC10C0E4B@beta.macosforge.org> Message-ID: <11FEB96F-93DD-4B99-8A0A-13D2069D8A9B@macports.org> On Feb 9, 2008, at 19:14, reiffert@macports.org wrote: > Revision: 33998 > http://trac.macosforge.org/projects/macports/changeset/33998 > Author: reiffert@macports.org > Date: 2008-02-09 17:14:41 -0800 (Sat, 09 Feb 2008) > > Log Message: > ----------- > Fixing lint error > > Modified Paths: > -------------- > trunk/dports/net/pidgin/Portfile > > Modified: trunk/dports/net/pidgin/Portfile > =================================================================== > --- trunk/dports/net/pidgin/Portfile 2008-02-10 01:13:26 UTC (rev > 33997) > +++ trunk/dports/net/pidgin/Portfile 2008-02-10 01:14:41 UTC (rev > 33998) > @@ -16,7 +16,7 @@ > also supports other IM protocols, including Yahoo!, \ > MSN, ICQ, Jabber, Napster, IRC, and Zephyr via included \ > plugins. > - > +platforms macosx > master_sites sourceforge > > checksums md5 0a593c2c343d5b854bd2cd2be7542f40 \ > @@ -35,7 +35,8 @@ > --with-nss-includes=${prefix}/include/nss \ > --with-nspr-libs=${prefix}/lib \ > --with-nspr-includes=${prefix}/include/nspr \ > - --enable-nss > + --enable-nss --disable-consoleui \ > + --disable-screensaver > > variant no_x11 description {Build port without-x} { > configure.args-append --without-x You didn't just fix lint errors; you also added configure.args. Does this change what gets installed by the port? If so, the revision should also be bumped. From rsync at reifferscheid.org Sun Feb 10 00:52:50 2008 From: rsync at reifferscheid.org (Thomas Reifferscheid) Date: Sun Feb 10 00:52:03 2008 Subject: trunk Message-ID: <47AEBB62.3020103@reifferscheid.org> Why didnt http://svn.macports.org/repository/macports/trunk/dports/devel/nspr/Portfile make it into the rsync repository? Kind regards Thomas From wsiegrist at apple.com Sun Feb 10 01:40:41 2008 From: wsiegrist at apple.com (William Siegrist) Date: Sun Feb 10 01:42:05 2008 Subject: trunk In-Reply-To: <47AEBB62.3020103@reifferscheid.org> References: <47AEBB62.3020103@reifferscheid.org> Message-ID: <8883C1E3-515B-41AC-A86B-9EB2C08E3A2D@apple.com> I broke the automatic rsync update. I'll have it going again in a moment. -Bill On Feb 10, 2008, at 12:52 AM, Thomas Reifferscheid wrote: > Why didnt http://svn.macports.org/repository/macports/trunk/dports/devel/nspr/Portfile > make it into the rsync repository? > > Kind regards > Thomas > _______________________________________________ > 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/20080210/9d6b77ec/smime.bin From wsiegrist at apple.com Sun Feb 10 02:00:01 2008 From: wsiegrist at apple.com (William Siegrist) Date: Sun Feb 10 02:01:24 2008 Subject: trunk In-Reply-To: <8883C1E3-515B-41AC-A86B-9EB2C08E3A2D@apple.com> References: <47AEBB62.3020103@reifferscheid.org> <8883C1E3-515B-41AC-A86B-9EB2C08E3A2D@apple.com> Message-ID: <3D7299A5-378D-42E5-BD88-8AC3F568E07B@apple.com> Should be fixed now. -Bill On Feb 10, 2008, at 1:40 AM, William Siegrist wrote: > I broke the automatic rsync update. I'll have it going again in a > moment. > > -Bill > > > > On Feb 10, 2008, at 12:52 AM, Thomas Reifferscheid wrote: >> Why didnt http://svn.macports.org/repository/macports/trunk/dports/devel/nspr/Portfile >> make it into the rsync repository? >> >> Kind regards >> Thomas >> _______________________________________________ >> 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 > > > > > > _______________________________________________ > 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/20080210/140f6dbe/smime.bin From dbruce at tampabay.rr.com Sun Feb 10 04:41:44 2008 From: dbruce at tampabay.rr.com (David Bruce) Date: Sun Feb 10 04:38:27 2008 Subject: I want to contribute ports for tuxmath and tuxtype (eventually) Message-ID: <200802100741.44794.dbruce@tampabay.rr.com> Hi, I'm the current lead programmer/maintainer for two educational kids games, "Tux, Of Math Command" (basic math drill) and "Tux Typing" (learning to type). Both are GPL free software with autotools-based builds, and all of the needed libs (SDL and friends, gettext) are already in MacPorts. I'm new to the Mac. Tuxmath builds and installs correctly with "./configure; make; sudo make install" and runs fine on our new Leopard Intel iMac. I initially found your project while trying to figure out a straightforward way to get universal builds of the needed libs onto my system - I'm in the process of learning to make a universal package. The first snag is that my program depends on SDL_image, and thus on smpeg, whose universal build currently fails, but I see there is already a bug on this from just a couple of days ago: http://trac.macosforge.org/projects/macports/ticket/14174 It seems to me that what I should *really* do is to learn about your ports system, get my program set up for it and contribute it to MacPorts. (fwiw, I understand that tuxmath is in the FreeBSD ports collection, although I am not involved with it - I assume studying the FreeBSD port of my project would be a good starting point?) Also, is this list just for development of the port infrastructure itself, or is it also the place for help with individual ports by "client" programmers like me? Cheers, -- David Bruce From jkh at apple.com Sun Feb 10 10:24:23 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Sun Feb 10 10:26:02 2008 Subject: I want to contribute ports for tuxmath and tuxtype (eventually) In-Reply-To: <200802100741.44794.dbruce@tampabay.rr.com> References: <200802100741.44794.dbruce@tampabay.rr.com> Message-ID: <53B89199-FA63-4687-AEE6-D849D20166EB@apple.com> On Feb 10, 2008, at 4:41 AM, David Bruce wrote: > It seems to me that what I should *really* do is to learn about your > ports > system, get my program set up for it and contribute it to MacPorts. I think you'd find no disagreement on this point! > (fwiw, I understand that tuxmath is in the FreeBSD ports collection, > although > I am not involved with it - I assume studying the FreeBSD port of my > project > would be a good starting point?) Sure - a lot of folks refer to other ports collections as a good way of getting a rough idea of what the dependencies are, where to fetch the bits, etc. You could certainly do a lot worse. > Also, is this list just for development of the port infrastructure > itself, or > is it also the place for help with individual ports by "client" > programmers > like me? Both! Welcome. - Jordan From ryandesign at macports.org Sun Feb 10 12:45:09 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun Feb 10 12:45:23 2008 Subject: I want to contribute ports for tuxmath and tuxtype (eventually) In-Reply-To: <53B89199-FA63-4687-AEE6-D849D20166EB@apple.com> References: <200802100741.44794.dbruce@tampabay.rr.com> <53B89199-FA63-4687-AEE6-D849D20166EB@apple.com> Message-ID: On Feb 10, 2008, at 12:24, Jordan K. Hubbard wrote: > On Feb 10, 2008, at 4:41 AM, David Bruce wrote: > >> (fwiw, I understand that tuxmath is in the FreeBSD ports >> collection, although >> I am not involved with it - I assume studying the FreeBSD port of >> my project >> would be a good starting point?) > > Sure - a lot of folks refer to other ports collections as a good > way of getting a rough idea of what the dependencies are, where to > fetch the bits, etc. You could certainly do a lot worse. I don't know a thing about FreeBSD ports, so my suggestion would be to start by reading the guide: http://guide.macports.org/ And look at the source of the existing portfiles, to see how things are done. There are thousands to choose from. From rsync at reifferscheid.org Sun Feb 10 14:38:03 2008 From: rsync at reifferscheid.org (Thomas Reifferscheid) Date: Sun Feb 10 14:37:15 2008 Subject: variant cascade Message-ID: <47AF7CCB.7020609@reifferscheid.org> Will "port install tea +foo" build the port coffee +bar? Portfile tea: depends_lib port:coffee variant foo requires bar { } variant bar { } ====================== Portfile coffee: variant bar { } Kind regards Thomas From raimue at macports.org Sun Feb 10 16:29:21 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun Feb 10 16:29:16 2008 Subject: [Fwd: [MacPorts Lint] Portfile Lint Errors for: vim] Message-ID: <47AF96E1.3050807@macports.org> Hi Bill, I got this error message below. Is there something broken? Or is there anything in my port which could cause such an error? I also got the same error for vim-app. This was sent out after commit r34037. Rainer -------- Original Message -------- Subject: [MacPorts Lint] Portfile Lint Errors for: vim Date: Sun, 10 Feb 2008 16:12:58 -0800 From: noreply@macports.org To: raimue@macports.org, Portfile: vim Errors: can't read "portvariants": no such variable From ebgssth at gmail.com Sun Feb 10 17:11:36 2008 From: ebgssth at gmail.com (js) Date: Sun Feb 10 17:11:28 2008 Subject: *-devel ports In-Reply-To: <63330389-D558-46C6-8940-93C2845C15BC@macports.org> References: <92E586B9-4F46-47FE-9935-A7F903614C2F@macports.org> <634664F9-BC97-42C7-98DA-5450F0FF27AF@macports.org> <20080204213522.GJ17147@prunille.vinc17.org> <4ec7f0880802050457n2a73b229tef5f4fcc89c0b8b@mail.gmail.com> <4ec7f0880802062021y6f042068s3aca09294ecde9ad@mail.gmail.com> <9BB53729-CC4C-4016-AF58-4DF57F2A59D1@macports.org> <63330389-D558-46C6-8940-93C2845C15BC@macports.org> Message-ID: So, have we reached the conclusion on this? From markd at macports.org Sun Feb 10 19:14:49 2008 From: markd at macports.org (markd@macports.org) Date: Sun Feb 10 19:14:29 2008 Subject: want to contribute ports for tuxmath and tuxtype =?iso-8859-1?q?=A0=A0=A0=A0=A0=A0=A0_=28eventually=29?= Message-ID: >I'm the current lead programmer/maintainer for two educational kids >games, "Tux, Of Math Command" (basic math drill) and "Tux Typing" >(learning >to type).? Both are GPL free software with autotools-based builds, and >all of >the needed libs (SDL and friends, gettext) are already in MacPorts. > >I'm new to the Mac.? Tuxmath builds and installs correctly with >"./configure; >make; sudo make install" and runs fine on our new Leopard Intel iMac.? I >initially found your project while trying to figure out a straightforward >way >to get universal builds of the needed libs onto my system - I'm in the >process of learning to make a universal package. > >The first snag is that my program depends on SDL_image, and thus on smpeg, >whose universal build currently fails, but I see there is already a bug on >this from just a couple of days ago: > >[ >https://owa016.msoutlookonline.net/owa/redir.aspx?C=8ce54085a83c4de9bc3bbce7aecbd6dd&URL=http%3a%2f%2ftrac.macosforge.org%2fprojects%2fmacports%2fticket%2f14174 >]http://trac.macosforge.org/projects/macports/ticket/14174 > >It seems to me that what I should *really* do is to learn about your ports >system, get my program set up for it and contribute it to MacPorts. > >(fwiw, I understand that tuxmath is in the FreeBSD ports collection, >although >I am not involved with it - I assume studying the FreeBSD port of my >project >would be a good starting point?) > >Also, is this list just for development of the port infrastructure >itself, or >is it also the place for help with individual ports by "client" >programmers >like me? Hi David, Welcome to the Mac and MacPorts communities! I frequently look at FreeBSD ports before making a port to try to see if there are any challenges I may not be aware of, though it is always possible there will be challenges unique to OS X or MacPorts. The biggest problem you find with porting to MacPorts that doesn't bother FreeBSD porters is when when developers don't properly support the DESTDIR variable. MacPorts needs for that to work to have a legitimate port because MacPorts install to an intermediate location before it gets copied into place in the filesystem. For apps in this condition, I sometimes find OpenBSD has had to solve this problem too, so I check out their patches for DESTDIR support and sometimes use them as is, though I always make sure to send patches I make like that upstream since the apps really should be fixed at the source. Just looking at the FreeBSD port for tuxmath, I see no patches at all. That is a very good sign, especially since the FreeBSD folks seem to be sort of patch happy; many for reasons I can not figure out. So that one (didn't look at the other) should be a very trivial matter to port. See the guide (still in progress) and be sure to ask questions. http://guide.macports.org/ Mark From markd at macports.org Sun Feb 10 23:42:00 2008 From: markd at macports.org (markd@macports.org) Date: Sun Feb 10 23:41:45 2008 Subject: rsync not picking up latest commits Message-ID: It appears that rsync is not picking up the commits from svn since a few days ago. Mark From wsiegrist at apple.com Mon Feb 11 00:20:52 2008 From: wsiegrist at apple.com (William Siegrist) Date: Mon Feb 11 00:22:11 2008 Subject: rsync not picking up latest commits In-Reply-To: References: Message-ID: <90A9D42A-AEC2-4B8E-A349-1D0DDCC5BE35@apple.com> I see the latest commit (to ethereal). It did get stuck about a day ago for maybe 12 hours but I fixed it already. Do you have a specific example I can look into? -Bill On Feb 10, 2008, at 11:42 PM, markd@macports.org wrote: > It appears that rsync is not picking up the commits from svn since a > few > days ago. > > Mark > > _______________________________________________ > 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/20080211/99c89185/smime.bin From wsiegrist at apple.com Mon Feb 11 00:24:49 2008 From: wsiegrist at apple.com (William Siegrist) Date: Mon Feb 11 00:25:39 2008 Subject: [Fwd: [MacPorts Lint] Portfile Lint Errors for: vim] In-Reply-To: <47AF96E1.3050807@macports.org> References: <47AF96E1.3050807@macports.org> Message-ID: <1FECBD50-8E8E-428D-8FDB-CE127609E12F@apple.com> I actually get 147 warnings now instead of what you got in the email... As far as I know, the linting is working. I dont maintain the lint code, I just maintain the server-side process for making those emails exactly from the output of "port lint". You should get the same errors locally with "port lint" before committing. If you see a discrepancy, definitely forward me the output the server gave you and the output you get locally. -Bill On Feb 10, 2008, at 4:29 PM, Rainer M?ller wrote: > Hi Bill, > > I got this error message below. Is there something broken? Or is > there anything in my port which could cause such an error? I also > got the same error for vim-app. This was sent out after commit r34037. > > Rainer > > -------- Original Message -------- > Subject: [MacPorts Lint] Portfile Lint Errors for: vim > Date: Sun, 10 Feb 2008 16:12:58 -0800 > From: noreply@macports.org > To: raimue@macports.org, > > Portfile: vim > > > Errors: can't read "portvariants": no such variable > > > ---- 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/20080211/1140069c/smime-0001.bin From Emil.Lundberg at bmc.uu.se Mon Feb 11 04:23:40 2008 From: Emil.Lundberg at bmc.uu.se (Emil Lundberg) Date: Mon Feb 11 04:23:31 2008 Subject: 64-bit versions of some ports In-Reply-To: <20080130234614.6F4BB19C73F@lists.macosforge.org> References: <20080130234614.6F4BB19C73F@lists.macosforge.org> Message-ID: >> From the previous discussion, I remember that we (or rather mww) >> started by changing the +universal variant to build all 4 versions (2 >> architectures each of 32-bit and 64-bit) but this was problematic >> because many ports failed to build out of the box as 64-bit, and >> there >> was no clear upgrade path for those who already had 2-architecture >> universal variants installed, and it was said that 64-bit versions of >> most ports don't make sense anyway (aren't faster, or possibly are >> even slower). But it seems like we want to be able to do this for >> selected ports. > > Most of the ports that failed were using Carbon, or otherwise old... > (old Carbon GUI does not support 64-bit, only Cocoa GUI does that) Thanks for revisiting this. There is a real need to be able to compile, by default, for the native architecture of your machine. There is also a real need to preseve backwards compatibility. A modest proposal (based on posts and discussions old and new) that might please everyone: * Keep the "universal" variant for building architecture-fat binaries (only). * Add a new "fat" variant for building bit-fat binaries (only). * Activate the "fat" variant by default on all library-class ports. * Add an config option to set the default bit-ness ("always 32-bit" or "native") for all builds. Some of it may well be in there already; I haven't been able to locate it in the docs though, e.g. where does "universal_archs" apply...? > I reverted +universal back to meaning "10.4u SDK for ppc/i386 arch", > and then made them into parameters for overriding locally if desired. So is it possible, using the current MacPorts 1.6.0, to build bit-fat/ quad-fat binaries, and if so, how is this accomplished (feel free to bring this onto the users-list)? thx, /Emil From Emil.Lundberg at bmc.uu.se Mon Feb 11 04:52:26 2008 From: Emil.Lundberg at bmc.uu.se (Emil Lundberg) Date: Mon Feb 11 04:52:19 2008 Subject: 64-bit versions of some ports In-Reply-To: <20080130234614.6F4BB19C73F@lists.macosforge.org> References: <20080130234614.6F4BB19C73F@lists.macosforge.org> Message-ID: <5D5F76D5-480B-420A-A296-1E74D16EDD2B@bmc.uu.se> >> Suppose we say we want to define a new variant called +64bit. Let's >> figure out what we want that to do. Are we asking for a way to >> build a >> 64-bit local-architecture binary instead of a 32-bit >> local-architecture binary (e.g. x86_64 only)? or in addition to a >> 32-bit local-architecture binary by installing both into separate >> paths (e.g. ${prefix}/lib and ${prefix}/lib64 -- I don't think >> this is >> the Mac way)? or in addition to a 32-bit local-architecture binary by >> making a single fat binary (e.g. i386 and x86_64 in one file)? >> What if >> the user selects +universal in addition to +64bit? How will we handle >> that? > > I have experimented with adding two new "variants" (or configure > options): > +m32 > +m64 > These corresponded with the GCC settings with the same name: -m32 and > -m64. Sorry, I guess I should have answered this rather than devising my own proposal... :-) My take on these matters should be evident from that post, however. Oh, and fat binaries/libraries are definitely the Mac way. No separate directories if they can be at all avoided. /Emil From markd at macports.org Mon Feb 11 08:43:45 2008 From: markd at macports.org (markd@macports.org) Date: Mon Feb 11 08:43:32 2008 Subject: false alarm / was: rsync not picking up latest commits Message-ID: >Message: 7 >Date: Mon, 11 Feb 2008 00:20:52 -0800 >From: William Siegrist >Subject: Re: rsync not picking up latest commits >To: markd@macports.org >Cc: macports-dev@lists.macosforge.org >Message-ID: <90A9D42A-AEC2-4B8E-A349-1D0DDCC5BE35@apple.com> >Content-Type: text/plain; charset="us-ascii" > >I see the latest commit (to ethereal). It did get stuck about a day >ago for maybe 12 hours but I fixed it already. Do you have a specific >example I can look into? > Hi Bill, Sorry, I seem to have been mistaken. I thought I made a commit that I see I didn't. Sorry about the false alarm. And thanks for all your hard work for our project lately. Mark From wsiegrist at apple.com Mon Feb 11 09:26:27 2008 From: wsiegrist at apple.com (William Siegrist) Date: Mon Feb 11 09:27:47 2008 Subject: false alarm / was: rsync not picking up latest commits In-Reply-To: References: Message-ID: No problem, I'm here to take care of these things and make sure your services are up 24/7. Don't hesitate to ping me with any problems. -Bill On Feb 11, 2008, at 8:43 AM, markd@macports.org wrote: >> Message: 7 >> Date: Mon, 11 Feb 2008 00:20:52 -0800 >> From: William Siegrist >> Subject: Re: rsync not picking up latest commits >> To: markd@macports.org >> Cc: macports-dev@lists.macosforge.org >> Message-ID: <90A9D42A-AEC2-4B8E-A349-1D0DDCC5BE35@apple.com> >> Content-Type: text/plain; charset="us-ascii" >> >> I see the latest commit (to ethereal). It did get stuck about a day >> ago for maybe 12 hours but I fixed it already. Do you have a specific >> example I can look into? >> > Hi Bill, > > Sorry, I seem to have been mistaken. I thought I made a commit that > I see > I didn't. Sorry about the false alarm. And thanks for all your > hard work > for our project lately. > > Mark > ---- 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/20080211/1705d025/smime.bin From raimue at macports.org Mon Feb 11 09:39:45 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon Feb 11 09:39:38 2008 Subject: [Fwd: [MacPorts Lint] Portfile Lint Errors for: vim] In-Reply-To: <1FECBD50-8E8E-428D-8FDB-CE127609E12F@apple.com> References: <47AF96E1.3050807@macports.org> <1FECBD50-8E8E-428D-8FDB-CE127609E12F@apple.com> Message-ID: <47B08861.2010107@macports.org> William Siegrist wrote: > I actually get 147 warnings now instead of what you got in the > email... As far as I know, the linting is working. I dont maintain the > lint code, I just maintain the server-side process for making those > emails exactly from the output of "port lint". You should get the same > errors locally with "port lint" before committing. If you see a > discrepancy, definitely forward me the output the server gave you and > the output you get locally. Yes, locally I also get these 147 warnings and they are "unfixable" (the patches will be downloaded and therefore can't be named differently). But the port lint post-commit hook sent me this error message only. Rainer From ryandesign at macports.org Mon Feb 11 11:25:51 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Feb 11 11:26:01 2008 Subject: [34061] trunk/dports/tex/bibutils/Portfile In-Reply-To: <20080211185336.099121136D57@beta.macosforge.org> References: <20080211185336.099121136D57@beta.macosforge.org> Message-ID: On Feb 11, 2008, at 12:53, jochen@macports.org wrote: > Revision: 34061 > http://trac.macosforge.org/projects/macports/changeset/34061 > Author: jochen@macports.org > Date: 2008-02-11 10:53:36 -0800 (Mon, 11 Feb 2008) > > Log Message: > ----------- > lint port, > move Emacs' Local Variables to end of file It would be better to leave the modeline at the top of the file like it was. "lint" in 1.6.0 is complaining about this, but this complaint has already been removed from MacPorts trunk. > Modified Paths: > -------------- > trunk/dports/tex/bibutils/Portfile > > Modified: trunk/dports/tex/bibutils/Portfile > =================================================================== > --- trunk/dports/tex/bibutils/Portfile 2008-02-11 18:43:48 UTC (rev > 34060) > +++ trunk/dports/tex/bibutils/Portfile 2008-02-11 18:53:36 UTC (rev > 34061) > @@ -1,7 +1,7 @@ > -# -*- coding: utf-8; mode: tcl; c-basic-offset: 4; tab-width: 4; > indent-tabs-mode: nil -*- vim:et:sw=4:ts=4:sts=4 > # $Id$ > > PortSystem 1.0 > + > name bibutils > version 3.40 > categories tex > @@ -25,3 +25,13 @@ > rmd160 6d6666119669a400716c99ee7c46922de4f54954 > > configure.pre_args --install-dir ${destroot}${prefix}/bin > + > + > +# Local Variables: > +# coding: utf-8 > +# mode: tcl > +# c-basic-offset: 4 > +# indent-tabs-mode: nil > +# tab-width: 4 > +# truncate-lines: t > +# End: From jochen at fhi-berlin.mpg.de Mon Feb 11 11:45:23 2008 From: jochen at fhi-berlin.mpg.de (=?ISO-8859-1?Q?Jochen_K=FCpper?=) Date: Mon Feb 11 11:45:29 2008 Subject: [34062] trunk/dports/tex/bibutils/Portfile In-Reply-To: <20080211192746.CE2041137C27@beta.macosforge.org> References: <20080211192746.CE2041137C27@beta.macosforge.org> Message-ID: <965289C4-1638-45BD-9B60-C649A1BEEA0A@fhi-berlin.mpg.de> On 11.02.2008, at 20:27, ryandesign@macports.org wrote: > bibutils: fix doubled slash in homepage URL introduced in r34060 > Modified Paths > ? trunk/dports/tex/bibutils/Portfile > Diff > Modified: trunk/dports/tex/bibutils/Portfile (34061 => 34062) > --- trunk/dports/tex/bibutils/Portfile 2008-02-11 18:53:36 UTC (rev > 34061) > +++ trunk/dports/tex/bibutils/Portfile 2008-02-11 19:27:46 UTC (rev > 34062) > @@ -17,7 +17,7 @@ > filters. > > master_sites http://www.scripps.edu/~cdputnam/software/bibutils/ > -homepage ${master_sites}/bibutils.html > +homepage ${master_sites}bibutils.html > distname bibutils_${version} > extract.suffix _src.tgz > checksums md5 090abe5d3e9869912fc6a70aac89a315 Where actually is the problem with the double slash? I find my committed version (including the slash) *much* easier to read! Greetings, Jochen -- Einigkeit und Recht und Freiheit http://www.Jochen-Kuepper.de Libert?, ?galit?, Fraternit? GnuPG key: CC1B0B4D Sex, drugs and rock-n-roll -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080211/3e6e621b/PGP-0001.bin From jochen at fhi-berlin.mpg.de Mon Feb 11 11:47:24 2008 From: jochen at fhi-berlin.mpg.de (=?ISO-8859-1?Q?Jochen_K=FCpper?=) Date: Mon Feb 11 11:47:18 2008 Subject: [34061] trunk/dports/tex/bibutils/Portfile In-Reply-To: References: <20080211185336.099121136D57@beta.macosforge.org> Message-ID: <7A02A865-39E1-4484-9820-2C85FDC4F5CD@fhi-berlin.mpg.de> On 11.02.2008, at 20:25, Ryan Schmidt wrote: > On Feb 11, 2008, at 12:53, jochen@macports.org wrote: > >> Revision: 34061 >> http://trac.macosforge.org/projects/macports/changeset/34061 >> Author: jochen@macports.org >> Date: 2008-02-11 10:53:36 -0800 (Mon, 11 Feb 2008) >> >> Log Message: >> ----------- >> lint port, >> move Emacs' Local Variables to end of file > > It would be better to leave the modeline at the top of the file like > it was. Why? Okay, the vim tuff might need to go back there, but generally an Emacs Local Variables section at the end of the file is way easier to read and understand than collapsing everything into the first line... > "lint" in 1.6.0 is complaining about this, but this complaint has > already been removed from MacPorts trunk. Okay, thanks for the info. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080211/221a17ea/PGP.bin From wsiegrist at apple.com Mon Feb 11 12:08:42 2008 From: wsiegrist at apple.com (William Siegrist) Date: Mon Feb 11 12:10:02 2008 Subject: [Fwd: [MacPorts Lint] Portfile Lint Errors for: vim] In-Reply-To: <47B08861.2010107@macports.org> References: <47AF96E1.3050807@macports.org> <1FECBD50-8E8E-428D-8FDB-CE127609E12F@apple.com> <47B08861.2010107@macports.org> Message-ID: <5FE8B618-5200-4C58-9F20-BDEBCD08EF42@apple.com> I found it. It turns out I was grabbing the port's dir non- recursively, so those extra files/* were not getting included and thats what that cryptic error meant. -Bill On Feb 11, 2008, at 9:39 AM, Rainer M?ller wrote: > William Siegrist wrote: >> I actually get 147 warnings now instead of what you got in the >> email... As far as I know, the linting is working. I dont maintain >> the lint code, I just maintain the server-side process for making >> those emails exactly from the output of "port lint". You should >> get the same errors locally with "port lint" before committing. If >> you see a discrepancy, definitely forward me the output the server >> gave you and the output you get locally. > > Yes, locally I also get these 147 warnings and they are > "unfixable" (the patches will be downloaded and therefore can't be > named differently). But the port lint post-commit hook sent me this > error message only. > > Rainer > ---- 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/20080211/36795c48/smime.bin From ryandesign at macports.org Mon Feb 11 13:05:09 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Feb 11 13:05:25 2008 Subject: [34061] trunk/dports/tex/bibutils/Portfile In-Reply-To: <7A02A865-39E1-4484-9820-2C85FDC4F5CD@fhi-berlin.mpg.de> References: <20080211185336.099121136D57@beta.macosforge.org> <7A02A865-39E1-4484-9820-2C85FDC4F5CD@fhi-berlin.mpg.de> Message-ID: On Feb 11, 2008, at 13:47, Jochen K?pper wrote: > On 11.02.2008, at 20:25, Ryan Schmidt wrote: > >> On Feb 11, 2008, at 12:53, jochen@macports.org wrote: >> >>> Revision: 34061 >>> http://trac.macosforge.org/projects/macports/changeset/ >>> 34061 >>> Author: jochen@macports.org >>> Date: 2008-02-11 10:53:36 -0800 (Mon, 11 Feb 2008) >>> >>> Log Message: >>> ----------- >>> lint port, >>> move Emacs' Local Variables to end of file >> >> It would be better to leave the modeline at the top of the file >> like it was. > > Why? > Okay, the vim tuff might need to go back there, but generally an > Emacs Local Variables section at the end of the file is way easier > to read and understand than collapsing everything into the first > line... Because that's what was decided on some time ago and that's what it says in the Guide: http://guide.macports.org/#development.practices.portstyle If you want to change that guideline, go ahead and bring it up for discussion. >> "lint" in 1.6.0 is complaining about this, but this complaint has >> already been removed from MacPorts trunk. > > Okay, thanks for the info. From ryandesign at macports.org Mon Feb 11 13:10:33 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Feb 11 13:10:44 2008 Subject: [Fwd: [MacPorts Lint] Portfile Lint Errors for: vim] In-Reply-To: <47B08861.2010107@macports.org> References: <47AF96E1.3050807@macports.org> <1FECBD50-8E8E-428D-8FDB-CE127609E12F@apple.com> <47B08861.2010107@macports.org> Message-ID: <082CEBEF-6561-41C4-B116-132452A98DAE@macports.org> On Feb 11, 2008, at 11:39, Rainer M?ller wrote: > William Siegrist wrote: > >> I actually get 147 warnings now instead of what you got in the >> email... As far as I know, the linting is working. I dont maintain >> the lint code, I just maintain the server-side process for making >> those emails exactly from the output of "port lint". You should >> get the same errors locally with "port lint" before committing. >> If you see a discrepancy, definitely forward me the output the >> server gave you and the output you get locally. > > Yes, locally I also get these 147 warnings and they are > "unfixable" (the patches will be downloaded and therefore can't be > named differently). But the port lint post-commit hook sent me this > error message only. The "unfixable" warnings about the names of downloaded patchfiles are not supposed to be fixed -- the "port lint" warning is erroneous (as you know). It would be great if someone could fix this bug: http://trac.macosforge.org/projects/macports/ticket/13615 And while they're there, do this as well: http://trac.macosforge.org/projects/macports/ticket/13825 From jochen at fhi-berlin.mpg.de Mon Feb 11 13:25:15 2008 From: jochen at fhi-berlin.mpg.de (=?ISO-8859-1?Q?Jochen_K=FCpper?=) Date: Mon Feb 11 13:25:19 2008 Subject: [34061] trunk/dports/tex/bibutils/Portfile In-Reply-To: References: <20080211185336.099121136D57@beta.macosforge.org> <7A02A865-39E1-4484-9820-2C85FDC4F5CD@fhi-berlin.mpg.de> Message-ID: Hi Ryan, > Because that's what was decided on some time ago and that's what it > says in the Guide: > > http://guide.macports.org/#development.practices.portstyle okay, good enough;) However, I hope it is okay to change the modeline to # -*- coding: utf-8; mode: tcl; tab-width: 4; truncate-lines: t; indent-tabs-mode: nil; c-basic-offset: 4 -*- vim:fenc=utf-8:filetype=tcl:et:sw=4:ts=4:sts=4 The truncate-lines makes sure long lines -- i.e. this modeline -- don't look too bad... Sch?ne Gr??e, Jochen -- Einigkeit und Recht und Freiheit http://www.Jochen-Kuepper.de Libert?, ?galit?, Fraternit? GnuPG key: CC1B0B4D Sex, drugs and rock-n-roll -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080211/fa50b7e7/PGP.bin From ryandesign at macports.org Mon Feb 11 13:34:48 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Feb 11 13:35:02 2008 Subject: [34062] trunk/dports/tex/bibutils/Portfile In-Reply-To: <965289C4-1638-45BD-9B60-C649A1BEEA0A@fhi-berlin.mpg.de> References: <20080211192746.CE2041137C27@beta.macosforge.org> <965289C4-1638-45BD-9B60-C649A1BEEA0A@fhi-berlin.mpg.de> Message-ID: On Feb 11, 2008, at 13:45, Jochen K?pper wrote: > On 11.02.2008, at 20:27, ryandesign@macports.org wrote: > >> bibutils: fix doubled slash in homepage URL introduced in r34060 >> Modified Paths >> ? trunk/dports/tex/bibutils/Portfile >> Diff >> Modified: trunk/dports/tex/bibutils/Portfile (34061 => 34062) >> --- trunk/dports/tex/bibutils/Portfile 2008-02-11 18:53:36 UTC >> (rev 34061) >> +++ trunk/dports/tex/bibutils/Portfile 2008-02-11 19:27:46 UTC >> (rev 34062) >> @@ -17,7 +17,7 @@ >> filters. >> >> master_sites http://www.scripps.edu/~cdputnam/software/ >> bibutils/ >> -homepage ${master_sites}/bibutils.html >> +homepage ${master_sites}bibutils.html > > Where actually is the problem with the double slash? I find my > committed version (including the slash) *much* easier to read! The URL of our Trac installation is not: http://trac.macports.org///projects/////macports/ That URL does not work. The correct URL is: http://trac.macports.org/projects/macports/ Similarly, the URL of the bibutils homepage is not: http://www.scripps.edu/~cdputnam/software/bibutils//bibutils.html Although that URL does work, that's probably not the URL we should be advertising (via e.g. "port info"). The correct URL is: http://www.scripps.edu/~cdputnam/software/bibutils/bibutils.html There is an RFC (sorry I forget the number, but it's the one about how a URL is put together) which states that the path component of a URL can't have two slashes next to one another. So either MacPorts base or the portfile itself should take care to construct correct valid URLs without doubled slashes in the path component. Currently MacPorts base has no code to strip out doubled slashes from the path component, so portfiles themselves should do this. In a previous discussion of this topic I believe Markus Weissmann also said that he found it easier to read with the extra slash in the portfile, and favored the solution where MacPorts base would strip the doubled slashes from the path component of homepage, livecheck.url and all master_sites. But I don't see why we should introduce this kind of magic. Why should MacPorts base second-guess the portfile author? Also, someone reading such a portfile might then be confused. Where did the extra slash go? Bottom line: we should either modify MacPorts base to remove doubled slashes from the path component of URLs, or we should add a port lint warning for such URLs. I'm in favor of a port lint warning. From ryandesign at macports.org Mon Feb 11 13:39:23 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Feb 11 13:39:33 2008 Subject: 64-bit versions of some ports In-Reply-To: References: <20080130234614.6F4BB19C73F@lists.macosforge.org> Message-ID: <630333F6-2D7A-4B4C-9410-CDE96BF7018B@macports.org> On Feb 11, 2008, at 06:23, Emil Lundberg wrote: >>> From the previous discussion, I remember that we (or rather mww) >>> started by changing the +universal variant to build all 4 >>> versions (2 >>> architectures each of 32-bit and 64-bit) but this was problematic >>> because many ports failed to build out of the box as 64-bit, and >>> there >>> was no clear upgrade path for those who already had 2-architecture >>> universal variants installed, and it was said that 64-bit >>> versions of >>> most ports don't make sense anyway (aren't faster, or possibly are >>> even slower). But it seems like we want to be able to do this for >>> selected ports. >> >> Most of the ports that failed were using Carbon, or otherwise old... >> (old Carbon GUI does not support 64-bit, only Cocoa GUI does that) > > Thanks for revisiting this. There is a real need to be able to > compile, by default, for the native architecture of your machine. > There is also a real need to preseve backwards compatibility. A > modest proposal (based on posts and discussions old and new) that > might please everyone: > > * Keep the "universal" variant for building architecture-fat > binaries (only). > * Add a new "fat" variant for building bit-fat binaries (only). > * Activate the "fat" variant by default on all library-class ports. What are "library-class ports"? What I mean is: what criteria would you use (what portfile variables, for example) to classify a port as a library-class port? > * Add an config option to set the default bit-ness ("always 32-bit" > or "native") for all builds. > > Some of it may well be in there already; I haven't been able to > locate it in the docs though, e.g. where does "universal_archs" > apply...? > > >> I reverted +universal back to meaning "10.4u SDK for ppc/i386 arch", >> and then made them into parameters for overriding locally if desired. > > So is it possible, using the current MacPorts 1.6.0, to build bit- > fat/quad-fat binaries, and if so, how is this accomplished (feel > free to bring this onto the users-list)? That comment applied to trunk only. 1.6.0 does not have the universal_archs variable, and has always built only the two 32-bit architectures. MacPorts in trunk has universal_archs, which was for a time set to all 4 architectures, but that didn't work well and then was changed to use only the 2 again. Someone using MacPorts trunk could set universal_archs to a different set of architectures to include in a universal build, but I would not expect any portfile author to have tested with anything other than the default "ppc i386" architecture set. From dbruce at tampabay.rr.com Mon Feb 11 15:38:57 2008 From: dbruce at tampabay.rr.com (David Bruce) Date: Mon Feb 11 15:35:19 2008 Subject: tuxmath Portfile Message-ID: <200802111838.57404.dbruce@tampabay.rr.com> Hi, After some study of the guide (as well as several existing Portfiles), I've taken my first stab at writing a Portfile for tuxmath and submitted it as trac ticket #14279. How can I start testing it to see what needs to be fixed? Tuxmath uses automake, so I am fairly sure it supports DESTDIR already. Thanks, and pardon my noob-hood with regard to MacPorts. -- David Bruce From dbruce at tampabay.rr.com Mon Feb 11 15:51:41 2008 From: dbruce at tampabay.rr.com (David Bruce) Date: Mon Feb 11 15:48:03 2008 Subject: sorry about mult trac tickets Message-ID: <200802111851.41635.dbruce@tampabay.rr.com> Sorry - I seem to have created five tickets, judging from the mails I just got. The first four were my attempts with Konqueror on my Linux box, which seemed to fail to recognize my id/pw. The last one was using FireFox on Linux, which worked smoothly. Not sure where the problem lies. -- David Bruce From markd at macports.org Mon Feb 11 15:51:12 2008 From: markd at macports.org (markd@macports.org) Date: Mon Feb 11 15:50:49 2008 Subject: Troubleshooting crashing perl app Message-ID: I am trying to troubleshoot this problem: http://www.mail-archive.com/nfdump-discuss@lists.sourceforge.net/msg00162.html I am trying to run nfsen, which starts up nfcapd and it crashes and lists the parent process as "perl". The poster in the nfsen conference says he finally compiled and installed non-port version of perl and that solved it, but I don't know how or what options he used. I tried MacPorts perl 5.8 and 5.10 and also tried +threads and +shared variants to no avail. Can anyone give a wild guess as to what might be the problem or how I might troubleshoot this? Mark ------------------------------------------------------------ Path: /opt/local/bin/nfcapd Identifier: nfcapd Version: ??? (???) Code Type: X86 (Native) Parent Process: perl [3536] Date/Time: 2008-02-11 11:47:23.120 -0800 OS Version: Mac OS X 10.5.1 (9B18) Report Version: 6 Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000008 Crashed Thread: 0 Thread 0 Crashed: 0 libSystem.B.dylib 0x905a6f00 strncpy + 112 1 nfcapd 0x00001896 start + 54 From raimue at macports.org Mon Feb 11 15:55:28 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon Feb 11 15:55:16 2008 Subject: sorry about mult trac tickets In-Reply-To: <200802111851.41635.dbruce@tampabay.rr.com> References: <200802111851.41635.dbruce@tampabay.rr.com> Message-ID: <47B0E070.4030806@macports.org> David Bruce wrote: > Sorry - I seem to have created five tickets, judging from the mails I just > got. The first four were my attempts with Konqueror on my Linux box, which > seemed to fail to recognize my id/pw. The last one was using FireFox on > Linux, which worked smoothly. Not sure where the problem lies. I just marked them as duplicate. Rainer From raimue at macports.org Mon Feb 11 17:41:47 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon Feb 11 17:41:35 2008 Subject: [Fwd: [MacPorts Lint] Portfile Lint Errors for: vim] In-Reply-To: <082CEBEF-6561-41C4-B116-132452A98DAE@macports.org> References: <47AF96E1.3050807@macports.org> <1FECBD50-8E8E-428D-8FDB-CE127609E12F@apple.com> <47B08861.2010107@macports.org> <082CEBEF-6561-41C4-B116-132452A98DAE@macports.org> Message-ID: <47B0F95B.5000004@macports.org> Ryan Schmidt wrote: > The "unfixable" warnings about the names of downloaded patchfiles are > not supposed to be fixed -- the "port lint" warning is erroneous (as > you know). It would be great if someone could fix this bug: > > http://trac.macosforge.org/projects/macports/ticket/13615 I committed a check if the file exists locally in files/: http://trac.macosforge.org/projects/macports/changeset/34082 > And while they're there, do this as well: > > http://trac.macosforge.org/projects/macports/ticket/13825 I have no idea how to fix this. Before lint is run, the normal Portfile evaluation takes place which happens platform dependent. It wouldn't be a solution just to add all variants and platforms, because they might be conflicting which could influence linting IMHO. Rainer From ryandesign at macports.org Mon Feb 11 23:22:45 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Feb 11 23:22:53 2008 Subject: [Fwd: [MacPorts Lint] Portfile Lint Errors for: vim] In-Reply-To: <47B0F95B.5000004@macports.org> References: <47AF96E1.3050807@macports.org> <1FECBD50-8E8E-428D-8FDB-CE127609E12F@apple.com> <47B08861.2010107@macports.org> <082CEBEF-6561-41C4-B116-132452A98DAE@macports.org> <47B0F95B.5000004@macports.org> Message-ID: <3EC45465-0208-4340-9200-400A1CD42DA9@macports.org> On Feb 11, 2008, at 19:41, Rainer M?ller wrote: > Ryan Schmidt wrote: > >> The "unfixable" warnings about the names of downloaded patchfiles >> are not supposed to be fixed -- the "port lint" warning is >> erroneous (as you know). It would be great if someone could fix >> this bug: >> http://trac.macosforge.org/projects/macports/ticket/13615 > > I committed a check if the file exists locally in files/: > http://trac.macosforge.org/projects/macports/changeset/34082 > >> And while they're there, do this as well: >> http://trac.macosforge.org/projects/macports/ticket/13825 > > I have no idea how to fix this. Before lint is run, the normal > Portfile evaluation takes place which happens platform dependent. > It wouldn't be a solution just to add all variants and platforms, > because they might be conflicting which could influence linting IMHO. Yeah, that's a trickier problem. Thanks for fixing 13615 though! From ryandesign at macports.org Mon Feb 11 23:56:11 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Feb 11 23:56:17 2008 Subject: Improvements for automated port lint Message-ID: Thanks to William Siegrist for setting up the automated port lint and email following each commit! Now here's some thoughts about some problems and how they could be dealt with. * I'm worried what will happen when someone does a batch cleanup operation affecting dozens or hundreds of portfiles in a single commit. (We've had this situation in r33441, r30218, r28561, r22478, r19376, etc.) I don't want this to fire off dozens or hundreds of lint emails. A thought here is that if a single commit affects, say, more than 5 portfiles, no lint report is run and no emails are sent. Or, just one email could be sent to the committer, letting them know why lint was not run. * The subject line of the lint emails reads "[MacPorts Lint] Portfile Lint Errors for: ". Not all information returned by lint is an error though; some of it is just warnings. There's also a lot of words up front there in the subject that I don't need. I would change the subject to "[] lint report" * Possibly obsoleting both of the above observations, what would people think about appending the port lint report to the diff email that's already generated and sent to macports-changes? I'm not sure if this is the best idea, or even possible with the diff email script we use, but the idea occurred to me so I thought I'd see what others think. From wsiegrist at apple.com Tue Feb 12 00:24:58 2008 From: wsiegrist at apple.com (William Siegrist) Date: Tue Feb 12 00:26:13 2008 Subject: Improvements for automated port lint In-Reply-To: References: Message-ID: <90313E05-F7E5-4432-B9A0-806F11D7361D@apple.com> I can work on the first two points sometime this week probably. The script is in the repo also, so I'll take patches of course if someone wants something specific/quicker. On the 3rd point, the email/diff script is a 3rd-party perl module, so this would be more work. This does bring up the point I asked before (though maybe just to the MP management), do we want lint emails to go to one of the mailing lists instead of just the maintainers? -Bill On Feb 11, 2008, at 11:56 PM, Ryan Schmidt wrote: > Thanks to William Siegrist for setting up the automated port lint > and email following each commit! Now here's some thoughts about some > problems and how they could be dealt with. > > * I'm worried what will happen when someone does a batch cleanup > operation affecting dozens or hundreds of portfiles in a single > commit. (We've had this situation in r33441, r30218, r28561, r22478, > r19376, etc.) I don't want this to fire off dozens or hundreds of > lint emails. A thought here is that if a single commit affects, say, > more than 5 portfiles, no lint report is run and no emails are sent. > Or, just one email could be sent to the committer, letting them know > why lint was not run. > > * The subject line of the lint emails reads "[MacPorts Lint] > Portfile Lint Errors for: ". Not all information returned by > lint is an error though; some of it is just warnings. There's also a > lot of words up front there in the subject that I don't need. I > would change the subject to "[] lint report" > > * Possibly obsoleting both of the above observations, what would > people think about appending the port lint report to the diff email > that's already generated and sent to macports-changes? I'm not sure > if this is the best idea, or even possible with the diff email > script we use, but the idea occurred to me so I thought I'd see what > others think. > > _______________________________________________ > 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/20080212/a98139df/smime-0001.bin From ryandesign at macports.org Tue Feb 12 00:59:35 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Feb 12 00:59:42 2008 Subject: Improvements for automated port lint In-Reply-To: <90313E05-F7E5-4432-B9A0-806F11D7361D@apple.com> References: <90313E05-F7E5-4432-B9A0-806F11D7361D@apple.com> Message-ID: <40BB6BE2-E7DF-4057-AC2F-E5A175F059CB@macports.org> On Feb 12, 2008, at 02:24, William Siegrist wrote: > On Feb 11, 2008, at 11:56 PM, Ryan Schmidt wrote: > >> Thanks to William Siegrist for setting up the automated port lint >> and email following each commit! Now here's some thoughts about >> some problems and how they could be dealt with. >> >> * I'm worried what will happen when someone does a batch cleanup >> operation affecting dozens or hundreds of portfiles in a single >> commit. (We've had this situation in r33441, r30218, r28561, >> r22478, r19376, etc.) I don't want this to fire off dozens or >> hundreds of lint emails. A thought here is that if a single commit >> affects, say, more than 5 portfiles, no lint report is run and no >> emails are sent. Or, just one email could be sent to the >> committer, letting them know why lint was not run. >> >> * The subject line of the lint emails reads "[MacPorts Lint] >> Portfile Lint Errors for: ". Not all information returned by >> lint is an error though; some of it is just warnings. There's also >> a lot of words up front there in the subject that I don't need. I >> would change the subject to "[] lint report" >> >> * Possibly obsoleting both of the above observations, what would >> people think about appending the port lint report to the diff >> email that's already generated and sent to macports-changes? I'm >> not sure if this is the best idea, or even possible with the diff >> email script we use, but the idea occurred to me so I thought I'd >> see what others think. > > I can work on the first two points sometime this week probably. The > script is in the repo also, so I'll take patches of course if > someone wants something specific/quicker. Attached should be a patch for my point #2 above. I didn't test it but it seems simple enough. > On the 3rd point, the email/diff script is a 3rd-party perl module, > so this would be more work. We're using svnnotify. I see from "svnnotify --help" that it has an option "--footer" to specify the text of a footer to append to the email. Maybe that would work? > This does bring up the point I asked before (though maybe just to > the MP management), do we want lint emails to go to one of the > mailing lists instead of just the maintainers? I remember you sending me that question, and me not responding; sorry! I initially thought we shouldn't spam any of the mailing lists. Appending the lint report to the existing diff mail, though, might make sense. Then again, it might not, since the warnings and errors reported by lint may or may not have resulted from that commit. Also, it's possible (maybe even likely) that the maintainer is not subscribed to macports-changes and thus wouldn't see the lint report. However, if the maintainer doesn't care enough to be on macports-changes, maybe they don't care to see the lint reports either. Maybe it's primarily the committer who should see the lint report, and all committers are hopefully subscribed to macports-changes. -------------- next part -------------- A non-text attachment was scrubbed... Name: portfile_lint.pl.diff Type: application/octet-stream Size: 1143 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080212/33b5c27a/portfile_lint.pl.obj From Emil.Lundberg at bmc.uu.se Tue Feb 12 01:17:09 2008 From: Emil.Lundberg at bmc.uu.se (Emil Lundberg) Date: Tue Feb 12 01:16:57 2008 Subject: 64-bit versions of some ports In-Reply-To: <630333F6-2D7A-4B4C-9410-CDE96BF7018B@macports.org> References: <20080130234614.6F4BB19C73F@lists.macosforge.org> <630333F6-2D7A-4B4C-9410-CDE96BF7018B@macports.org> Message-ID: <8F89793D-E8F1-49BC-BC9D-0D32C6A35A62@bmc.uu.se> 11 feb 2008 kl. 22.39 skrev Ryan Schmidt: > > On Feb 11, 2008, at 06:23, Emil Lundberg wrote: > >>>> From the previous discussion, I remember that we (or rather mww) >>>> started by changing the +universal variant to build all 4 >>>> versions (2 >>>> architectures each of 32-bit and 64-bit) but this was problematic >>>> because many ports failed to build out of the box as 64-bit, and >>>> there >>>> was no clear upgrade path for those who already had 2-architecture >>>> universal variants installed, and it was said that 64-bit >>>> versions of >>>> most ports don't make sense anyway (aren't faster, or possibly are >>>> even slower). But it seems like we want to be able to do this for >>>> selected ports. >>> >>> Most of the ports that failed were using Carbon, or otherwise old... >>> (old Carbon GUI does not support 64-bit, only Cocoa GUI does that) >> >> Thanks for revisiting this. There is a real need to be able to >> compile, by default, for the native architecture of your machine. >> There is also a real need to preseve backwards compatibility. A >> modest proposal (based on posts and discussions old and new) that >> might please everyone: >> >> * Keep the "universal" variant for building architecture-fat >> binaries (only). >> * Add a new "fat" variant for building bit-fat binaries (only). >> * Activate the "fat" variant by default on all library-class ports. > > What are "library-class ports"? What I mean is: what criteria would > you use (what portfile variables, for example) to classify a port > as a library-class port? A good question indeed; I was hoping you guys could answer that! :-) I think it would need to be determined by the maintainer of the individual port. Many ports are both applications in themselves but also libraries (R, mysql, openssl), so the line is not so clear-cut. My view is that _any_ port that builds shared libraries should (ultimately) compile as bit-fat by default on 64-bit (at least on intel, ppc folks may beg to differ). Perhaps a category ("library", "64bit") could be added to signify this? Or a platform, but that just sounds wrong. But, to get things going, how about simply adding a standard variant "64bit" that, just like "universal", is always available (right?). The daring could then add it to variants.conf, and those who (like myself) take an active interest in 64-bit could try ports out, file bug reports etc. afb had a suggestion on how to handle this in a decently port-neutral I believe. Those on 32-bit machines, etc, would obviously not bother using it unless they wanted to build fat binaries for some reason. Downside is that a variant that might not be tested appears as an option. So how is universal handled? Is it always expected to work if it is available? Can it be disabled for the ports that for some reason don't support it? Can one specify "-universal" for a single port at build time? >> * Add an config option to set the default bit-ness ("always 32- >> bit" or "native") for all builds. >> >> Some of it may well be in there already; I haven't been able to >> locate it in the docs though, e.g. where does "universal_archs" >> apply...? >> >> >>> I reverted +universal back to meaning "10.4u SDK for ppc/i386 arch", >>> and then made them into parameters for overriding locally if >>> desired. >> >> So is it possible, using the current MacPorts 1.6.0, to build bit- >> fat/quad-fat binaries, and if so, how is this accomplished (feel >> free to bring this onto the users-list)? > > That comment applied to trunk only. 1.6.0 does not have the > universal_archs variable, and has always built only the two 32-bit > architectures. MacPorts in trunk has universal_archs, which was for > a time set to all 4 architectures, but that didn't work well and > then was changed to use only the 2 again. Someone using MacPorts > trunk could set universal_archs to a different set of architectures > to include in a universal build, but I would not expect any > portfile author to have tested with anything other than the default > "ppc i386" architecture set. Right. I do feel, however, that architecture and bit-ness need to be handled separately. Architechture-fat binaries, I presume, are built to increase usability on several machines (for binary distribution in some form), while bit-fat binaries are commonly built for use on the _same_ machine, e.g. to provide both 32- and 64-bit version of libraries. I can try trunk on a demo setup, using universal_arch="ppc ppc64". How, exactly, do I use this variable? /Emil From raimue at macports.org Tue Feb 12 18:50:27 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue Feb 12 18:50:13 2008 Subject: Installation Documentation Message-ID: <47B25AF3.5040000@macports.org> Hi, Currently we have two tutorials how to install MacPorts: One at http://trac.macosforge.org/projects/macports/wiki/InstallingMacPorts and another one in the guide at http://guide.macports.org/#installing It is obviously difficult to keep them at sync. For example the wiki entry does not cover Leopard at all and still says that you should set DISPLAY. I think they should be unified into one place. Rainer From jmpp at macports.org Tue Feb 12 22:51:58 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Feb 12 22:49:35 2008 Subject: Installation Documentation In-Reply-To: <47B25AF3.5040000@macports.org> References: <47B25AF3.5040000@macports.org> Message-ID: <2A64A13A-39EE-4106-9BC7-900D87FD4F3D@macports.org> On Feb 12, 2008, at 10:20 PM, Rainer M?ller wrote: > Hi, > > Currently we have two tutorials how to install MacPorts: > One at > http://trac.macosforge.org/projects/macports/wiki/InstallingMacPorts > and another one in the guide at > http://guide.macports.org/#installing > > It is obviously difficult to keep them at sync. For example the wiki > entry does not cover Leopard at all and still says that you should > set DISPLAY. I think they should be unified into one place. The only reason why some of those wiki docs exist is because until very recently we didn't have any form of organized and *truly* official documentation after the move to Mac OS Forge, so gaps had to be filled one way or another. We now have our shiny and proud guide, which covers on official grounds (most of) that documentation and, officially of course, deprecates the corresponding wiki docs. The only reason why I still haven't moved to delete them is that I haven't had the chance to go over them and check that the guide doesn't miss out on any of the information they might have. It is my intention to turn the wiki mostly into a "How-To"-sort-of source of information, e.g. with tutorials on stuff like setting up MAMP, GNOME and what-not, or more live stuff like the FAQ, problems hotlist and others, but not an "official" source of documentation on MacPorts setup and usage. I tried a couple of times to recruit a small task force to do this job but unfortunately failed to get much traction.... and then my daily schedule in the last few weeks went totally berserk and left me without much spare time. So if anyone reading this is interested in helping with this task, then please do raise your hand! > > > Rainer Regards,... -jmpp From ebgssth at gmail.com Wed Feb 13 04:53:51 2008 From: ebgssth at gmail.com (js) Date: Wed Feb 13 04:53:47 2008 Subject: Fwd: Trac ticket that need your attension: py25-mysql In-Reply-To: References: Message-ID: Forgot to send this to macports-dev... forwarding. ---------- Forwarded message ---------- From: js Date: Feb 13, 2008 9:52 PM Subject: Trac ticket that need your attension: py25-mysql To: stechert@macports.org, ryandesign@macports.org Maintainers, This is the reminder for the ticket which hasn't received no response from maintainers more than 72 hours. http://trac.macosforge.org/projects/macports/ticket/13410 Please take a look and commit the patch if everything's file From ebgssth at gmail.com Wed Feb 13 04:57:37 2008 From: ebgssth at gmail.com (js) Date: Wed Feb 13 04:57:34 2008 Subject: Trac ticket that need your attension: py-mako, py25-mako 0.1.10 Message-ID: Maintainer, This is the reminder for the ticket which hasn't received no response from maintainers more than 72 hours. http://trac.macosforge.org/projects/macports/ticket/14255 Please take a look and commit the patch if everything's file From ebgssth at gmail.com Wed Feb 13 05:02:18 2008 From: ebgssth at gmail.com (js) Date: Wed Feb 13 05:02:26 2008 Subject: Trac ticket that need your attension: py-mako, py25-mako 0.1.10, pylons 0.9.6.1 and ports pylons depends Message-ID: And pylons 0.9.6.1 and the too. http://trac.macosforge.org/projects/macports/ticket/14235 On 2/13/08, js wrote: > Maintainer, > > This is the reminder for the ticket which hasn't received no response > from maintainers more than 72 hours. > http://trac.macosforge.org/projects/macports/ticket/14255 > > Please take a look and commit the patch if everything's file > From ebgssth at gmail.com Wed Feb 13 05:33:12 2008 From: ebgssth at gmail.com (js) Date: Wed Feb 13 05:33:10 2008 Subject: why is my port no being added? In-Reply-To: <5cbbe4ae0802130527s680dc646vb7a6dc8dff3eeeee@mail.gmail.com> References: <5cbbe4ae0802130527s680dc646vb7a6dc8dff3eeeee@mail.gmail.com> Message-ID: Might be better to send this to macports-dev. On 2/13/08, Florian Ebeling wrote: > Hi, > > I submitted a Portfile for a new port a couple of weeks ago, but > nothing happend. > > http://trac.macports.org/projects/macports/ticket/13779 > > Is there anything wrong with it? I think I remember that adding them > via a ticket > was the way suggested. > > Florian > > > > > -- > Florian Ebeling > florian.ebeling@gmail.com > _______________________________________________ > macports-users mailing list > macports-users@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-users > From raimue at macports.org Wed Feb 13 06:15:37 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed Feb 13 06:15:38 2008 Subject: why is my port no being added? In-Reply-To: References: <5cbbe4ae0802130527s680dc646vb7a6dc8dff3eeeee@mail.gmail.com> Message-ID: <47B2FB89.8070902@macports.org> js wrote: > Might be better to send this to macports-dev. > > On 2/13/08, Florian Ebeling wrote: >> Hi, >> >> I submitted a Portfile for a new port a couple of weeks ago, but >> nothing happend. Sometimes everyone is busy and nobody notices new ports. >> http://trac.macports.org/projects/macports/ticket/13779 >> >> Is there anything wrong with it? I think I remember that adding them >> via a ticket >> was the way suggested. You did it right. Comitted in r34108. Rainer From mww at macports.org Wed Feb 13 10:27:06 2008 From: mww at macports.org (Markus Weissmann) Date: Wed Feb 13 10:27:03 2008 Subject: [34110] trunk/dports/mail/archivemail/Portfile In-Reply-To: <20080213171616.324FB11A4B40@beta.macosforge.org> References: <20080213171616.324FB11A4B40@beta.macosforge.org> Message-ID: <52F1579A-327E-43F5-A444-004BB575CDA0@macports.org> I havent tried, but this looks totally like a case for the Python group code; also you should just rely on a concrete version of Python as the path to the "real" python executable gets hardcoded in the "archivemail" python program ($prefix/Library/Frameworks/Python.framework/Versions/ 2.4/Resources/Python.app/Contents/MacOS/Python for Python 2.4..) cheers, -Markus On 13 Feb 2008, at 18:16, simon@macports.org wrote: > Revision34110Authorsimon@macports.orgDate2008-02-13 09:16:14 -0800 > (Wed, 13 Feb 2008)Log Message > mail/archivemail: Updated to version 0.7.2. Also removed unnecessary > compression of man page. > Modified Paths > ? trunk/dports/mail/archivemail/Portfile > Diff > Modified: trunk/dports/mail/archivemail/Portfile (34109 => 34110) > --- trunk/dports/mail/archivemail/Portfile 2008-02-13 16:57:22 UTC > (rev 34109) > +++ trunk/dports/mail/archivemail/Portfile 2008-02-13 17:16:14 UTC > (rev 34110) > @@ -3,7 +3,7 @@ > PortSystem 1.0 > > name archivemail > -version 0.7.0 > +version 0.7.2 > categories mail python > platforms darwin > maintainers nomaintainer > @@ -16,20 +16,30 @@ > > homepage http://archivemail.sourceforge.net > master_sites sourceforge > -checksums sha1 fcba04b7ae748d54b8ebcbecb0aad08c4f58e927 > +checksums md5 e444424688e6ec063e829176e4eb62e2 \ > + sha1 0ff9b8991b04f09cf9536c45b6f9e05d2427a459 \ > + rmd160 da85dff5114100d76f8f5ac19172d8a557801455 > > depends_lib bin:python:python24 > > use_configure no > build {} > > -destroot.cmd ${prefix}/bin/python setup.py install > +# I don't know a better way so it works even if python_select is not > +# installed. If there is please tell me (simon@macports.org) or > just change > +# it. > +if {[file exists ${prefix}/bin/python]} { > + set python python > +} else { > + set python python2.4 > +} > + > +destroot.cmd ${prefix}/bin/${python} setup.py install > destroot.destdir --prefix=${prefix} \ > --root=${destroot} \ > --install-data=${prefix}/share > post-destroot { > - system "gzip -9 ${destroot}${prefix}/share/man/man1/archivemail. > 1" > - xinstall -m 755 -d ${destroot}${prefix}/share/doc/${name} > + xinstall -d ${destroot}${prefix}/share/doc/${name} > xinstall -W ${worksrcpath} CHANGELOG FAQ README TODO \ > ${destroot}${prefix}/share/doc/${name} > } > _______________________________________________ > macports-changes mailing list > macports-changes@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-changes -- Dipl. Inf. (FH) Markus W. Weissmann http://www.mweissmann.de/ From ryandesign at macports.org Wed Feb 13 13:07:39 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Feb 13 13:07:38 2008 Subject: [34108] trunk/dports/math In-Reply-To: <20080213141140.7FEAD119DECD@beta.macosforge.org> References: <20080213141140.7FEAD119DECD@beta.macosforge.org> Message-ID: <65760FEA-A48B-4A64-8BA4-7F3E759FD346@macports.org> On Feb 13, 2008, at 08:11, raimue@macports.org wrote: > Revision: 34108 > http://trac.macosforge.org/projects/macports/changeset/34108 > Author: raimue@macports.org > Date: 2008-02-13 06:11:37 -0800 (Wed, 13 Feb 2008) > > Log Message: > ----------- > math/libsvm: > New Port submitted by Florian Ebeling, closes #13779 See my follow-up ticket for some concerns: http://trac.macosforge.org/projects/macports/ticket/14310 From florian.ebeling at gmail.com Wed Feb 13 14:40:45 2008 From: florian.ebeling at gmail.com (Florian Ebeling) Date: Wed Feb 13 14:40:38 2008 Subject: [34108] trunk/dports/math In-Reply-To: <65760FEA-A48B-4A64-8BA4-7F3E759FD346@macports.org> References: <20080213141140.7FEAD119DECD@beta.macosforge.org> <65760FEA-A48B-4A64-8BA4-7F3E759FD346@macports.org> Message-ID: <5cbbe4ae0802131440t2d9f2fadr6b4c64855f4c3d46@mail.gmail.com> > See my follow-up ticket for some concerns: > > http://trac.macosforge.org/projects/macports/ticket/14310 All reasonable it seems. I dont have commit rights. Please feel free to add these changes. From wsiegrist at apple.com Wed Feb 13 18:59:51 2008 From: wsiegrist at apple.com (William Siegrist) Date: Wed Feb 13 19:01:14 2008 Subject: Improvements for automated port lint In-Reply-To: <40BB6BE2-E7DF-4057-AC2F-E5A175F059CB@macports.org> References: <90313E05-F7E5-4432-B9A0-806F11D7361D@apple.com> <40BB6BE2-E7DF-4057-AC2F-E5A175F059CB@macports.org> Message-ID: <122F541E-269D-4FAF-95AC-7E053605B0E4@apple.com> On Feb 12, 2008, at 12:59 AM, Ryan Schmidt wrote: > > On Feb 12, 2008, at 02:24, William Siegrist wrote: > >> On Feb 11, 2008, at 11:56 PM, Ryan Schmidt wrote: >> >>> Thanks to William Siegrist for setting up the automated port lint >>> and email following each commit! Now here's some thoughts about >>> some problems and how they could be dealt with. >>> >>> * Possibly obsoleting both of the above observations, what would >>> people think about appending the port lint report to the diff >>> email that's already generated and sent to macports-changes? I'm >>> not sure if this is the best idea, or even possible with the diff >>> email script we use, but the idea occurred to me so I thought I'd >>> see what others think. >> >> I can work on the first two points sometime this week probably. The >> script is in the repo also, so I'll take patches of course if >> someone wants something specific/quicker. > > Attached should be a patch for my point #2 above. I didn't test it > but it seems simple enough. > Thanks. The subject line is fixed. > >> On the 3rd point, the email/diff script is a 3rd-party perl module, >> so this would be more work. > > We're using svnnotify. I see from "svnnotify --help" that it has an > option "--footer" to specify the text of a footer to append to the > email. Maybe that would work? > Good idea with --footer. There is still the problem is getting two independent post-commit processes to share data, but at least its all at the hook level and not in svnnotify internals. The way hooks are laid out for Mac OS Forge makes this tricky, so I'll try to work out a solution on the server. > >> This does bring up the point I asked before (though maybe just to >> the MP management), do we want lint emails to go to one of the >> mailing lists instead of just the maintainers? > > I remember you sending me that question, and me not responding; > sorry! I initially thought we shouldn't spam any of the mailing > lists. Appending the lint report to the existing diff mail, though, > might make sense. Then again, it might not, since the warnings and > errors reported by lint may or may not have resulted from that > commit. Also, it's possible (maybe even likely) that the maintainer > is not subscribed to macports-changes and thus wouldn't see the lint > report. However, if the maintainer doesn't care enough to be on > macports-changes, maybe they don't care to see the lint reports > either. Maybe it's primarily the committer who should see the lint > report, and all committers are hopefully subscribed to macports- > changes. This reminds me... Right now the email goes to the _maintainers_, not the committer. There are cases where the committer is not a maintainer, right? We should probably add in the committer when they arent also a maintainer? -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/20080213/9f19f3b7/smime.bin From ryandesign at macports.org Wed Feb 13 19:15:04 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Feb 13 19:15:03 2008 Subject: Improvements for automated port lint In-Reply-To: <122F541E-269D-4FAF-95AC-7E053605B0E4@apple.com> References: <90313E05-F7E5-4432-B9A0-806F11D7361D@apple.com> <40BB6BE2-E7DF-4057-AC2F-E5A175F059CB@macports.org> <122F541E-269D-4FAF-95AC-7E053605B0E4@apple.com> Message-ID: <09383E35-97DC-419B-83D3-9E8B110FC62D@macports.org> On Feb 13, 2008, at 20:59, William Siegrist wrote: > On Feb 12, 2008, at 12:59 AM, Ryan Schmidt wrote: > >> On Feb 12, 2008, at 02:24, William Siegrist wrote: >> >>> On Feb 11, 2008, at 11:56 PM, Ryan Schmidt wrote: >>> >>>> Thanks to William Siegrist for setting up the automated port >>>> lint and email following each commit! Now here's some thoughts >>>> about some problems and how they could be dealt with. >>>> >>>> * Possibly obsoleting both of the above observations, what would >>>> people think about appending the port lint report to the diff >>>> email that's already generated and sent to macports-changes? I'm >>>> not sure if this is the best idea, or even possible with the >>>> diff email script we use, but the idea occurred to me so I >>>> thought I'd see what others think. >>> >>> I can work on the first two points sometime this week probably. >>> The script is in the repo also, so I'll take patches of course if >>> someone wants something specific/quicker. >> >> Attached should be a patch for my point #2 above. I didn't test it >> but it seems simple enough. > > Thanks. The subject line is fixed. Thank you! >>> On the 3rd point, the email/diff script is a 3rd-party perl >>> module, so this would be more work. >> >> We're using svnnotify. I see from "svnnotify --help" that it has >> an option "--footer" to specify the text of a footer to append to >> the email. Maybe that would work? > > Good idea with --footer. There is still the problem is getting two > independent post-commit processes to share data, but at least its > all at the hook level and not in svnnotify internals. The way > hooks are laid out for Mac OS Forge makes this tricky, so I'll try > to work out a solution on the server. I don't know about your infrastructure, but it would seem that you would run lint for each affected portfile, get its output all together, and then pass it to the --footer switch when you call svnnotify. >>> This does bring up the point I asked before (though maybe just to >>> the MP management), do we want lint emails to go to one of the >>> mailing lists instead of just the maintainers? >> >> I remember you sending me that question, and me not responding; >> sorry! I initially thought we shouldn't spam any of the mailing >> lists. Appending the lint report to the existing diff mail, >> though, might make sense. Then again, it might not, since the >> warnings and errors reported by lint may or may not have resulted >> from that commit. Also, it's possible (maybe even likely) that the >> maintainer is not subscribed to macports-changes and thus wouldn't >> see the lint report. However, if the maintainer doesn't care >> enough to be on macports-changes, maybe they don't care to see the >> lint reports either. Maybe it's primarily the committer who should >> see the lint report, and all committers are hopefully subscribed >> to macports-changes. > > This reminds me... Right now the email goes to the _maintainers_, > not the committer. There are cases where the committer is not a > maintainer, right? We should probably add in the committer when > they arent also a maintainer? Right, sending it to the committer too was part of my initial suggestion, and I just realized when looking at the code for the first time that it doesn't do that. But if we change to appending the lint report to the changes email, then this point is moot since the changes email just goes to the changes list. From ebgssth at gmail.com Fri Feb 15 05:01:44 2008 From: ebgssth at gmail.com (js) Date: Fri, 15 Feb 2008 22:01:44 +0900 Subject: The ticket that need your attention: py25-feedparser Message-ID: The maintainer didn't answer the ticket within 72 hours. (According to MacPorts Guide, a maintainer's supposed to apply patches within 72 hours) Here's the ticket: http://trac.macosforge.org/projects/macports/ticket/14265 Please take a look at this and commit the patch. Thanks. From markd at macports.org Fri Feb 15 11:51:56 2008 From: markd at macports.org (markd at macports.org) Date: Fri, 15 Feb 2008 11:51:56 -0800 Subject: linking for dummies Message-ID: I have an app where "-lgcc_s.10.5 -lgcc -lSystem" is getting appended at the end of the stuff getting linked, and I can't figure out where this is coming from. It appears to me that gcc is doing it on its own. Instead of the linker item "-lrrd" normally appearing at the end, instead I see it in the middle like this: "-lrrd -lgcc_s.10.5 -lgcc -lSystem" and I'm told that is a problem. But I can't for the life of me see the Makefile doing anything that would cause this. Does anyone know how this extra stuff gets added on, or how to make "-lrrd" go on the end of the linker line? Mark From peter at pogma.com Fri Feb 15 13:11:02 2008 From: peter at pogma.com (Peter O'Gorman) Date: Fri, 15 Feb 2008 15:11:02 -0600 Subject: linking for dummies In-Reply-To: References: Message-ID: <47B5FFE6.40104@pogma.com> markd at macports.org wrote: > I have an app where > > "-lgcc_s.10.5 -lgcc -lSystem" > > is getting appended at the end of the stuff getting linked, and I can't > figure out where this is coming from. It appears to me that gcc is doing > it on its own. Instead of the linker item "-lrrd" normally appearing at > the end, instead I see it in the middle like this: > > "-lrrd -lgcc_s.10.5 -lgcc -lSystem" > > and I'm told that is a problem. But I can't for the life of me see the > Makefile doing anything that would cause this. Does anyone know how this > extra stuff gets added on, or how to make "-lrrd" go on the end of the > linker line? The compiler appends these, you do not normally want it not to. Are you seeing errors because of this? Peter -- Peter O'Gorman http://pogma.com From ebgssth at gmail.com Fri Feb 15 13:18:21 2008 From: ebgssth at gmail.com (js) Date: Sat, 16 Feb 2008 06:18:21 +0900 Subject: Trac ticket that need your attention: py25-mysql Message-ID: Sorry to disturb, but another reminder. > Maintainers, > > This is the reminder for the ticket which hasn't received no response > from maintainers more than 72 hours. > http://trac.macosforge.org/projects/macports/ticket/13410 > > Please take a look and commit the patch if everything's fine > From ebgssth at gmail.com Fri Feb 15 13:32:26 2008 From: ebgssth at gmail.com (js) Date: Sat, 16 Feb 2008 06:32:26 +0900 Subject: 72 hours are not enough for maintainers? Message-ID: Hi, MacPorts Guide says "The maintainer should apply the patches and close the ticket within 72 hours." "If the maintainer does not respond within 72 hours, you or another committer may review the patches and update the port." But actually this is not always the case. So I started to consider 72 hours restriction is not realistic so this part of guideline should be modified to be more practical. Any comments? From blair at orcaware.com Fri Feb 15 14:15:25 2008 From: blair at orcaware.com (Blair Zajac) Date: Fri, 15 Feb 2008 14:15:25 -0800 Subject: 72 hours are not enough for maintainers? In-Reply-To: References: Message-ID: <47B60EFD.30406@orcaware.com> js wrote: > Hi, > > MacPorts Guide says > > "The maintainer should apply the patches and close the ticket within 72 hours." > "If the maintainer does not respond within 72 hours, you or another > committer may review the patches and update the port." > > But actually this is not always the case. > So I started to consider 72 hours restriction is not realistic so this > part of guideline should be modified to be more practical. > > Any comments? Depends upon what side of the coin you are on. Sometimes I want to get a fix in for another port and waiting 3 days seems like forever. Other times I miss an email for an update on my port, but I don't typically mind somebody else fixing it. I can always change the fix after it goes in and increment the revision. So three days seems like a reasonable middle-ground. Blair -- Blair Zajac, Ph.D. http://www.orcaware.com/svn/ From markd at macports.org Fri Feb 15 15:40:44 2008 From: markd at macports.org (markd at macports.org) Date: Fri, 15 Feb 2008 15:40:44 -0800 Subject: linking for dummies Message-ID: >> I have an app where >> >> "-lgcc_s.10.5 -lgcc -lSystem" >> >> is getting appended at the end of the stuff getting linked, and I can't >> figure out where this is coming from.? It appears to me that gcc is >doing >> it on its own.?? Instead of the linker item "-lrrd" normally appearing >at >> the end, instead I see it in the middle like this: >> >> "-lrrd -lgcc_s.10.5 -lgcc -lSystem" >> >> and I'm told that is a problem.? But I can't for the life of me see the >> Makefile doing anything that would cause this.? Does anyone know how >this >> extra stuff gets added on, or how to make "-lrrd" go on the end of the >> linker line? > >The compiler appends these, you do not normally want it not to. Are you >?seeing errors because of this? Thanks for the reply. It appears that the problem was not the addition of "-lgcc_s.10.5 -lgcc -lSystem" (only seen in verbose gcc mode), but the inclusion of the "-lrrd". I've never tried verbose mode before so it was unfamiliar to me. For some reason the "-lrrd" was unncessary. I'm following up with the developer to see if a source fix is in order. BTW, is there a way to turn on gcc verbose mode with a MacPorts flag? Mark From ryandesign at macports.org Fri Feb 15 16:25:07 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 15 Feb 2008 18:25:07 -0600 Subject: Trac ticket that need your attention: py25-mysql In-Reply-To: References: Message-ID: Fixed now. On Feb 15, 2008, at 15:18, js wrote: > Sorry to disturb, but another reminder. > >> Maintainers, >> >> This is the reminder for the ticket which hasn't received no >> response >> from maintainers more than 72 hours. >> http://trac.macosforge.org/projects/macports/ticket/13410 >> >> Please take a look and commit the patch if everything's fine From raimue at macports.org Fri Feb 15 18:01:55 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 16 Feb 2008 03:01:55 +0100 Subject: Updating macports.conf Message-ID: <47B64413.7050407@macports.org> Hello, Currently on selfupdate macports.conf is not updated in any way if it already existed. This "hides" new options from long time users. An up-to-date macports.conf provides a good overview over all options and contains short documentation lines. I have two proposals how this could be changed to make it more easy for users to follow HOWTOs and/or tutorials. 1) Add macports.conf.dist Place a file named macports.conf.dist right beside macports.conf. It would be the same file as the install process would have generated if no macports.conf file exists. Then the user can copy & paste new options over to macports.conf. Advantages: * Easy to implement Disadvantages: * User still has to do it him/herself. 2) Parse macports.conf and regenerate it Parse the existing macports.conf and rewrite it completely. This takes takes all options already present and writes a new macports.conf (by also keeping a backup). Advantages: * macports.conf is always up-to-date * Does not require work by user Disadvantages: * More work to implement this. * Users will loose their formatting or comments, if they customized it. Any comments on this appreciated. Rainer From ernest.prabhakar at gmail.com Fri Feb 15 18:04:46 2008 From: ernest.prabhakar at gmail.com (Ernest Prabhakar) Date: Fri, 15 Feb 2008 18:04:46 -0800 Subject: Updating macports.conf In-Reply-To: <47B64413.7050407@macports.org> References: <47B64413.7050407@macports.org> Message-ID: Hi Rainer, On Feb 15, 2008, at 6:01 PM, Rainer M?ller wrote: > Currently on selfupdate macports.conf is not updated in any way if it > already existed. This "hides" new options from long time users. > An up-to-date macports.conf provides a good overview over all options > and contains short documentation lines. How about make the default behavior of selfupdate to move the old macports.conf and replace it if it has NOT been modified since the last time? -- Ernie P. From ebgssth at gmail.com Fri Feb 15 19:16:14 2008 From: ebgssth at gmail.com (js) Date: Sat, 16 Feb 2008 12:16:14 +0900 Subject: Let's avoid using md5 as checksum Message-ID: Hi, As you know, MD5 has serious flaws (http://en.wikipedia.org/wiki/MD5) So recently I don't use it and even remove it when I found it in the checksum part of portfile. I thought dropping use of md5 in portfile would be nice. Any thought? From ryandesign at macports.org Fri Feb 15 19:21:43 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 15 Feb 2008 21:21:43 -0600 Subject: Let's avoid using md5 as checksum In-Reply-To: References: Message-ID: On Feb 15, 2008, at 21:16, js wrote: > As you know, MD5 has serious flaws (http://en.wikipedia.org/wiki/MD5) > So recently I don't use it and even remove it when I found it in the > checksum part of portfile. > I thought dropping use of md5 in portfile would be nice. > > Any thought? Disagree. Three types of checksums (md5, sha1, rmd160) in a portfile are stronger than just two. I would agree that ports should not use md5 alone, but I would also say that ports should not use sha1 or rmd160 alone. Ports should use all three checksum types. port lint should warn if a portfile uses just a single type of checksum for a file. From raimue at macports.org Fri Feb 15 19:36:12 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 16 Feb 2008 04:36:12 +0100 Subject: Let's avoid using md5 as checksum In-Reply-To: References: Message-ID: <47B65A2C.5060904@macports.org> js wrote: > As you know, MD5 has serious flaws (http://en.wikipedia.org/wiki/MD5) > So recently I don't use it and even remove it when I found it in the > checksum part of portfile. > I thought dropping use of md5 in portfile would be nice. > > Any thought? I don't think these flaws are strong enough to discourage use of MD5 as a hashsum for file verification yet. Rainer From opendarwin.org at darkart.com Fri Feb 15 19:48:39 2008 From: opendarwin.org at darkart.com (Eric Hall) Date: Sat, 16 Feb 2008 03:48:39 +0000 Subject: Let's avoid using md5 as checksum In-Reply-To: <47B65A2C.5060904@macports.org> References: <47B65A2C.5060904@macports.org> Message-ID: <20080216034839.GE94215@darkart.com> On Sat, Feb 16, 2008 at 04:36:12AM +0100, Rainer M?ller wrote: > js wrote: > > As you know, MD5 has serious flaws (http://en.wikipedia.org/wiki/MD5) > > So recently I don't use it and even remove it when I found it in the > > checksum part of portfile. > > I thought dropping use of md5 in portfile would be nice. > > > > Any thought? > > I don't think these flaws are strong enough to discourage use of MD5 as > a hashsum for file verification yet. > Leave in MD5, add one of the others as needed. Note that the (currently known) flaws in MD5 involve generating specific files ahead of time, not finding a matching MD5 for an existing file. Which brings us to: How well do maintainers verify that the distfile they download and checksum is "valid"? Sure, it unpacks and builds (well, we sure hope so), but do they know that the authors of the distfile put together that distfile? I suspect this is a weaker point that MD5 alone is. -eric From bwaters at nrao.edu Fri Feb 15 19:48:41 2008 From: bwaters at nrao.edu (Boyd Waters) Date: Fri, 15 Feb 2008 20:48:41 -0700 Subject: Let's avoid using md5 as checksum In-Reply-To: References: Message-ID: <390A7AAF-34EB-4F12-B7C1-2058D3ED20F4@nrao.edu> On Feb 15, 2008, at 8:21 PM, Ryan Schmidt wrote: > I would agree that ports should not use md5 alone, but I would also > say that ports should not use sha1 or rmd160 alone. Ports should use > all three checksum types. > > port lint should warn if a portfile uses just a single type of > checksum for a file. I'm a bit surprised at this. Technically three sorts of checksum is very strong, but what are we concerned about here? I don't think that the problem is malicious code injection. You can examine the source code if you care to do so.. I think that the checksums provide an easy way to determine that the correct source distributions have been downloaded. Often downloads are corrupted. Some distributions do not use version numbers on the file name; the checksum tells you that you have the correct bits. MD5 is sufficient for verifying a successful download of a source tarball. MD5 may not be sufficient to prevent evil hackers from adding malicious elements to the source code, but in practice this is not going to happen: the attacker must transform the code into something that still compiles, performs their nefarious deeds, and has a given MD5 hash. I'd love to see a demonstration of that! That said, I use rmd160 and sha1 for my ports, so who's being paranoid here? :-) - boyd Boyd Waters Scientific Programmer (and failed MacPorts developer) National Radio Astronomy Observatory Socorro, New Mexico From opendarwin.org at darkart.com Fri Feb 15 20:01:41 2008 From: opendarwin.org at darkart.com (Eric Hall) Date: Sat, 16 Feb 2008 04:01:41 +0000 Subject: Let's avoid using md5 as checksum In-Reply-To: <390A7AAF-34EB-4F12-B7C1-2058D3ED20F4@nrao.edu> References: <390A7AAF-34EB-4F12-B7C1-2058D3ED20F4@nrao.edu> Message-ID: <20080216040141.GF94215@darkart.com> On Fri, Feb 15, 2008 at 08:48:41PM -0700, Boyd Waters wrote: > [snip] > > MD5 is sufficient for verifying a successful download of a source > tarball. I believe there are attacks against MD5 that make it insufficient to verify that the "right" distfile was downloaded. > > MD5 may not be sufficient to prevent evil hackers from adding > malicious elements to the source code, but in practice this is not > going to happen: the attacker must transform the code into something > that still compiles, performs their nefarious deeds, and has a given > MD5 hash. I'd love to see a demonstration of that! Do you remember the PDF example from several years back? IIRC, the attack was based on a PDF containing one of two blobs that MD5 to the same value. By testing for which one is present, a different representation of the PDF is displayed. This sort of attack is very easy to imagine in a big blob of code. Is it likely? Probably not. Are there other game-over equivalences involved (attacker is the distfile author, or has compromised the distfile server so can (either way) push out a shiny-new version with exploits baked in)? Yuppers. > > That said, I use rmd160 and sha1 for my ports, so who's being paranoid > here? :-) > All of us. :) -eric From raimue at macports.org Fri Feb 15 20:02:54 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 16 Feb 2008 05:02:54 +0100 Subject: Let's avoid using md5 as checksum In-Reply-To: References: Message-ID: <47B6606E.7010007@macports.org> Ryan Schmidt wrote: > Disagree. Three types of checksums (md5, sha1, rmd160) in a portfile > are stronger than just two. > > I would agree that ports should not use md5 alone, but I would also > say that ports should not use sha1 or rmd160 alone. Ports should use > all three checksum types. If we would do it correctly, we should only use hashes published by the authors of the software. Although many don't provide any, this would be the only way to be sure the file is the correct one. If a port maintainer creates the hashes, who ensures that he got the right file and not a compromised one? But if no checksums are provided upstream, Portfile authors will of course have to generate hashes themself. We could also add other hashes, basically everything libcrypto provides as we are linking to it anyways. > port lint should warn if a portfile uses just a single type of > checksum for a file. Maybe this is desired as the original authors only released one checksum type? But sure we could encourage addition of other checksums this way. In conclusion, as long as we do not take care if the Portfile itself was transferred secure, we do not have any security by using checksums for fetches. So checksums just prevent anybody from accidentally using a corrupted file. Rainer From peter at pogma.com Fri Feb 15 20:13:15 2008 From: peter at pogma.com (Peter O'Gorman) Date: Fri, 15 Feb 2008 22:13:15 -0600 Subject: linking for dummies In-Reply-To: References: Message-ID: <47B662DB.6000705@pogma.com> markd at macports.org wrote: > Thanks for the reply. It appears that the problem was not the addition of > "-lgcc_s.10.5 -lgcc -lSystem" (only seen in verbose gcc mode), but the > inclusion of the "-lrrd". I've never tried verbose mode before so it was > unfamiliar to me. For some reason the "-lrrd" was unncessary. I'm > following up with the developer to see if a source fix is in order. What is the error that you are getting? An extraneous library on the link line is not usually a big issue. > > BTW, is there a way to turn on gcc verbose mode with a MacPorts flag? You shouldn't need to. Peter -- Peter O'Gorman http://pogma.com From ebgssth at gmail.com Fri Feb 15 20:14:25 2008 From: ebgssth at gmail.com (js) Date: Sat, 16 Feb 2008 13:14:25 +0900 Subject: Let's avoid using md5 as checksum In-Reply-To: References: Message-ID: > Disagree. Three types of checksums (md5, sha1, rmd160) in a portfile > are stronger than just two. > I would agree that ports should not use md5 alone, but I would also > say that ports should not use sha1 or rmd160 alone. Ports should use > all three checksum types. When we have sha1 and rmd160 using md5 as a checksum is meaningless. What do you mean by "stronger"? > port lint should warn if a portfile uses just a single type of > checksum for a file. That's nice! From jkh at apple.com Fri Feb 15 20:26:14 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Fri, 15 Feb 2008 20:26:14 -0800 Subject: Updating macports.conf In-Reply-To: <47B64413.7050407@macports.org> References: <47B64413.7050407@macports.org> Message-ID: <86AB9772-B806-4CDB-9F79-FD86A392AC67@apple.com> On Feb 15, 2008, at 6:01 PM, Rainer M?ller wrote: > Currently on selfupdate macports.conf is not updated in any way if it > already existed. This "hides" new options from long time users. Yep. Very common problem with configuration files! > An up-to-date macports.conf provides a good overview over all options > and contains short documentation lines. > [ ... ] > 1) Add macports.conf.dist Yes, at a minimum, you need an updated reference config file available at all times, though I dislike the .dist approach. If it's just a passive reference, then you need to either write a merge utility (like FreeBSD's "mergemaster") or dump the entire problem of merging in the user's lap, neither solution bringing much happiness. A better approach is FreeBSD's /etc/defaults - a set of shadow files you keep up to date, making the primary configuration file an override. You can still get stale data lingering in the user configuration file, keeping an option on or off when the default has changed, but sometimes that's a feature. This is, in any case, how I'd handle this one. Always install a macports.conf.default and add some logic to load the two in order (macports.conf should, in fact, be optional). - Jordan > > Place a file named macports.conf.dist right beside macports.conf. > It > would be the same file as the install process would have > generated if > no macports.conf file exists. Then the user can copy & paste new > options over to macports.conf. > > Advantages: * Easy to implement > Disadvantages: * User still has to do it him/herself. > > 2) Parse macports.conf and regenerate it > Parse the existing macports.conf and rewrite it completely. This > takes takes all options already present and writes a new > macports.conf (by also keeping a backup). > > Advantages: * macports.conf is always up-to-date > * Does not require work by user > Disadvantages: * More work to implement this. > * Users will loose their formatting or comments, if > they customized it. > > Any comments on this appreciated. > > Rainer > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From ryandesign at macports.org Fri Feb 15 20:39:36 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 15 Feb 2008 22:39:36 -0600 Subject: Updating macports.conf In-Reply-To: <86AB9772-B806-4CDB-9F79-FD86A392AC67@apple.com> References: <47B64413.7050407@macports.org> <86AB9772-B806-4CDB-9F79-FD86A392AC67@apple.com> Message-ID: <2314B5DB-FE12-4F70-984E-E7EB887D281F@macports.org> On Feb 15, 2008, at 22:26, Jordan K. Hubbard wrote: > On Feb 15, 2008, at 6:01 PM, Rainer M?ller wrote: > >> Currently on selfupdate macports.conf is not updated in any way if it >> already existed. This "hides" new options from long time users. > > Yep. Very common problem with configuration files! > >> An up-to-date macports.conf provides a good overview over all options >> and contains short documentation lines. >> [ ... ] >> 1) Add macports.conf.dist > > Yes, at a minimum, you need an updated reference config file available > at all times, though I dislike the .dist approach. If it's just a > passive reference, then you need to either write a merge utility (like > FreeBSD's "mergemaster") or dump the entire problem of merging in the > user's lap, neither solution bringing much happiness. A better > approach is FreeBSD's /etc/defaults - a set of shadow files you keep > up to date, making the primary configuration file an override. You > can still get stale data lingering in the user configuration file, > keeping an option on or off when the default has changed, but > sometimes that's a feature. > > This is, in any case, how I'd handle this one. Always install a > macports.conf.default and add some logic to load the two in order > (macports.conf should, in fact, be optional). Great, and after we solve this, we'll do the same for all the software one could install using MacPorts, right? :-D From jkh at apple.com Fri Feb 15 20:44:17 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Fri, 15 Feb 2008 20:44:17 -0800 Subject: Let's avoid using md5 as checksum In-Reply-To: <47B6606E.7010007@macports.org> References: <47B6606E.7010007@macports.org> Message-ID: Given all the other unfinished or unstarted work in MacPorts which needs to happen just to get the collection halfway reliable, it seems to me that arguing over the safety of a commonly used checksum is little more than a distraction and represents time that could be devoted to more important pursuits, like cleaning up the variant code, or getting a distributed unit testing setup going, or ... - Jordan From ryandesign at macports.org Fri Feb 15 20:48:41 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 15 Feb 2008 22:48:41 -0600 Subject: Let's avoid using md5 as checksum In-Reply-To: References: Message-ID: <0DD1957D-DAA9-4BA7-80BD-1FDF55DC8147@macports.org> On Feb 15, 2008, at 22:14, js wrote: >> Disagree. Three types of checksums (md5, sha1, rmd160) in a portfile >> are stronger than just two. >> I would agree that ports should not use md5 alone, but I would also >> say that ports should not use sha1 or rmd160 alone. Ports should use >> all three checksum types. > > When we have sha1 and rmd160 using md5 as a checksum is meaningless. > What do you mean by "stronger"? We have checksums to ensure that the file the user downloaded is the same file that the maintainer originally used when making the port. If md5 were so weak that an attacker could create a new archive that had the same md5 sum as the original file, and they could somehow upload this to the developer's server and replace their original file with this new one, and the portfile only used md5 checksums for verifying the downloaded file, then we would have a problem. But md5 is not this weak, so this attack is not possible. It is possible for a malicious software author to specially construct two archives with different contents but which have the same md5 sum. So this is a (vaguely) realistic situation that the weakness of md5 would enable to occur. You might say we should therefore use sha1 or rmd160 instead. But what if a similar problem is discovered in sha1 or rmd160? Even if flaws exist in all three checksum algorithms that enable differing files to have the same checksum, it is virtually impossible for such a flaw to affect more than one checksum algorithm at a time. That is, take two different files A and B which have been constructed so that their md5 sums are the same. I will eat my hat if they also have the same sha1 sums or the same rmd160 sums. Therefore, use more than one checksum and the weakness of any individual algorithm becomes unimportant. From jkh at apple.com Fri Feb 15 20:48:14 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Fri, 15 Feb 2008 20:48:14 -0800 Subject: Updating macports.conf In-Reply-To: <2314B5DB-FE12-4F70-984E-E7EB887D281F@macports.org> References: <47B64413.7050407@macports.org> <86AB9772-B806-4CDB-9F79-FD86A392AC67@apple.com> <2314B5DB-FE12-4F70-984E-E7EB887D281F@macports.org> Message-ID: On Feb 15, 2008, at 8:39 PM, Ryan Schmidt wrote: >> This is, in any case, how I'd handle this one. Always install a >> macports.conf.default and add some logic to load the two in order >> (macports.conf should, in fact, be optional). > > Great, and after we solve this, we'll do the same for all the > software one could install using MacPorts, right? :-D Sure, absolutely, we'll get right on that. Let's start with just one configuration file though, shall we? :-) - Jordan From raimue at macports.org Fri Feb 15 20:50:49 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 16 Feb 2008 05:50:49 +0100 Subject: Updating macports.conf In-Reply-To: <86AB9772-B806-4CDB-9F79-FD86A392AC67@apple.com> References: <47B64413.7050407@macports.org> <86AB9772-B806-4CDB-9F79-FD86A392AC67@apple.com> Message-ID: <47B66BA9.6040808@macports.org> Jordan K. Hubbard wrote: >> An up-to-date macports.conf provides a good overview over all options >> and contains short documentation lines. >> [ ... ] >> 1) Add macports.conf.dist > > Yes, at a minimum, you need an updated reference config file available > at all times, though I dislike the .dist approach. If it's just a > passive reference, then you need to either write a merge utility (like > FreeBSD's "mergemaster") or dump the entire problem of merging in the > user's lap, neither solution bringing much happiness. Ok, the file would not necessarily be called like this. It could also go into share/doc/macports or anywhere else. And yes, the merging is the big disadvantage of this approach. > A better > approach is FreeBSD's /etc/defaults - a set of shadow files you keep > up to date, making the primary configuration file an override. You > can still get stale data lingering in the user configuration file, > keeping an option on or off when the default has changed, but > sometimes that's a feature. > > This is, in any case, how I'd handle this one. Always install a > macports.conf.default and add some logic to load the two in order > (macports.conf should, in fact, be optional). This sounds like a good solution. Although it does not make the documentation lines visible to the user. Rainer From ebgssth at gmail.com Fri Feb 15 21:29:51 2008 From: ebgssth at gmail.com (js) Date: Sat, 16 Feb 2008 14:29:51 +0900 Subject: Let's avoid using md5 as checksum In-Reply-To: <0DD1957D-DAA9-4BA7-80BD-1FDF55DC8147@macports.org> References: <0DD1957D-DAA9-4BA7-80BD-1FDF55DC8147@macports.org> Message-ID: > You might say we should therefore use sha1 or rmd160 instead. But > what if a similar problem is discovered in sha1 or rmd160? MD5 already has one, others are not. > Even if flaws exist in all three checksum algorithms that enable > differing files to have the same checksum, it is virtually impossible > for such a flaw to affect more than one checksum algorithm at a time. > That is, take two different files A and B which have been constructed > so that their md5 sums are the same. I will eat my hat if they also > have the same sha1 sums or the same rmd160 sums. > > Therefore, use more than one checksum and the weakness of any > individual algorithm becomes unimportant. That's make sense. Anyway, the thing is, not dropping MD5 as a checksum but encourage ports author to write more secure Portfile. For this porpose, I like your idea that warns portfile author when checksum is not secure enough. From ryandesign at macports.org Fri Feb 15 21:36:44 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 15 Feb 2008 23:36:44 -0600 Subject: Let's avoid using md5 as checksum In-Reply-To: References: <0DD1957D-DAA9-4BA7-80BD-1FDF55DC8147@macports.org> Message-ID: <19B4284F-9FF7-4461-8015-E5B36C31613A@macports.org> On Feb 15, 2008, at 23:29, js wrote: >> You might say we should therefore use sha1 or rmd160 instead. But >> what if a similar problem is discovered in sha1 or rmd160? > > MD5 already has one, others are not. > >> Even if flaws exist in all three checksum algorithms that enable >> differing files to have the same checksum, it is virtually impossible >> for such a flaw to affect more than one checksum algorithm at a time. >> That is, take two different files A and B which have been constructed >> so that their md5 sums are the same. I will eat my hat if they also >> have the same sha1 sums or the same rmd160 sums. >> >> Therefore, use more than one checksum and the weakness of any >> individual algorithm becomes unimportant. > > That's make sense. > Anyway, the thing is, not dropping MD5 as a checksum but encourage > ports author to write more secure Portfile. > For this porpose, I like your idea that warns portfile author when > checksum is not secure enough. Of course, this won't make Rainer happy. :-) http://trac.macosforge.org/projects/macports/browser/trunk/dports/ editors/vim/files/patchlist?rev=34037 Look at all them pretty md5s... From markd at macports.org Fri Feb 15 21:43:53 2008 From: markd at macports.org (markd at macports.org) Date: Fri, 15 Feb 2008 21:43:53 -0800 Subject: linking for dummies Message-ID: >> Thanks for the reply.? It appears that the problem was not the addition >of >>? "-lgcc_s.10.5 -lgcc -lSystem" (only seen in verbose gcc mode), but the >> inclusion of the "-lrrd".? I've never tried verbose mode before so it >was >> unfamiliar to me.? For some reason the "-lrrd" was unncessary.? I'm >> following up with the developer to see if a source fix is in order. > >What is the error that you are getting? An extraneous library on the >link line is not usually a big issue. > >> >> BTW, is there a way to turn on gcc verbose mode with a MacPorts flag? > >You shouldn't need to. Actually, the error was not a compile error but a runtime error in the app after install. I really don't know why the extra library was causing the problem. Maybe the developer will be able to explain. Mark From ebgssth at gmail.com Fri Feb 15 21:48:07 2008 From: ebgssth at gmail.com (js) Date: Sat, 16 Feb 2008 14:48:07 +0900 Subject: Let's avoid using md5 as checksum In-Reply-To: <19B4284F-9FF7-4461-8015-E5B36C31613A@macports.org> References: <0DD1957D-DAA9-4BA7-80BD-1FDF55DC8147@macports.org> <19B4284F-9FF7-4461-8015-E5B36C31613A@macports.org> Message-ID: NP, author has free to ignore the warning message ;) On Feb 16, 2008 2:36 PM, Ryan Schmidt wrote: > > > On Feb 15, 2008, at 23:29, js wrote: > > >> You might say we should therefore use sha1 or rmd160 instead. But > >> what if a similar problem is discovered in sha1 or rmd160? > > > > MD5 already has one, others are not. > > > >> Even if flaws exist in all three checksum algorithms that enable > >> differing files to have the same checksum, it is virtually impossible > >> for such a flaw to affect more than one checksum algorithm at a time. > >> That is, take two different files A and B which have been constructed > >> so that their md5 sums are the same. I will eat my hat if they also > >> have the same sha1 sums or the same rmd160 sums. > >> > >> Therefore, use more than one checksum and the weakness of any > >> individual algorithm becomes unimportant. > > > > That's make sense. > > Anyway, the thing is, not dropping MD5 as a checksum but encourage > > ports author to write more secure Portfile. > > For this porpose, I like your idea that warns portfile author when > > checksum is not secure enough. > > Of course, this won't make Rainer happy. :-) > > http://trac.macosforge.org/projects/macports/browser/trunk/dports/ > editors/vim/files/patchlist?rev=34037 > > Look at all them pretty md5s... > > From wsimpson at macports.org Fri Feb 15 23:49:27 2008 From: wsimpson at macports.org (William Allen Simpson) Date: Sat, 16 Feb 2008 02:49:27 -0500 Subject: Let's avoid using md5 as checksum In-Reply-To: <20080216040141.GF94215@darkart.com> References: <390A7AAF-34EB-4F12-B7C1-2058D3ED20F4@nrao.edu> <20080216040141.GF94215@darkart.com> Message-ID: <1054b09b0802152349w10e017b2jcdc4b3a184eaf051@mail.gmail.com> On 2/15/08, Eric Hall wrote: > I believe there are attacks against MD5 that make it insufficient > to verify that the "right" distfile was downloaded. > You believe incorrectly. All known attacks require that the generator of the tarball is compromised. That is, there are no preimage or second preimage attacks. As Yet, nobody has successfully completed any of my MD4 or MD5 challenges, announced on the cryptography and NIST hash lists.... > Do you remember the PDF example from several years back? Yes. A parlor trick. Irrelevant to using MD5 as designed. > Are there other game-over equivalences involved (attacker is the distfile > author, or has compromised the distfile server so can (either way) > push out a shiny-new version with exploits baked in)? Yuppers. > And that is the only relevant issue. Something that a hash cannot solve. As long as we ONLY use hashes generated by the distfile author, located on the distfile site, and NEVER generate our own, we'll be fine. From blair at orcaware.com Fri Feb 15 23:55:12 2008 From: blair at orcaware.com (Blair Zajac) Date: Fri, 15 Feb 2008 23:55:12 -0800 Subject: Let's avoid using md5 as checksum In-Reply-To: <1054b09b0802152349w10e017b2jcdc4b3a184eaf051@mail.gmail.com> References: <390A7AAF-34EB-4F12-B7C1-2058D3ED20F4@nrao.edu> <20080216040141.GF94215@darkart.com> <1054b09b0802152349w10e017b2jcdc4b3a184eaf051@mail.gmail.com> Message-ID: <47B696E0.7060107@orcaware.com> William Allen Simpson wrote: > On 2/15/08, Eric Hall wrote: > And that is the only relevant issue. Something that a hash cannot solve. > > As long as we ONLY use hashes generated by the distfile author, located > on the distfile site, and NEVER generate our own, we'll be fine. We should be fine if they PGP sign the file and then we get the hashes from that? Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies Subversion training, consulting and support http://www.orcaware.com/svn/ From ryandesign at macports.org Fri Feb 15 23:57:42 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 16 Feb 2008 01:57:42 -0600 Subject: Let's avoid using md5 as checksum In-Reply-To: <1054b09b0802152349w10e017b2jcdc4b3a184eaf051@mail.gmail.com> References: <390A7AAF-34EB-4F12-B7C1-2058D3ED20F4@nrao.edu> <20080216040141.GF94215@darkart.com> <1054b09b0802152349w10e017b2jcdc4b3a184eaf051@mail.gmail.com> Message-ID: On Feb 16, 2008, at 01:49, William Allen Simpson wrote: > On 2/15/08, Eric Hall wrote: > >> I believe there are attacks against MD5 that make it insufficient >> to verify that the "right" distfile was downloaded. > > You believe incorrectly. All known attacks require that the generator > of the tarball is compromised. That is, there are no preimage or > second > preimage attacks. > > As Yet, nobody has successfully completed any of my MD4 or MD5 > challenges, announced on the cryptography and NIST hash lists.... > >> Do you remember the PDF example from several years back? > > Yes. A parlor trick. Irrelevant to using MD5 as designed. > >> Are there other game-over equivalences involved (attacker is the >> distfile >> author, or has compromised the distfile server so can (either way) >> push out a shiny-new version with exploits baked in)? Yuppers. > > And that is the only relevant issue. Something that a hash cannot > solve. > > As long as we ONLY use hashes generated by the distfile author, > located > on the distfile site, and NEVER generate our own, we'll be fine. But we don't do that. At least, I'm constantly generating my own checksums for my portfiles. The developers of most of my ports do not provide checksums. From wsimpson at macports.org Sat Feb 16 00:11:23 2008 From: wsimpson at macports.org (William Allen Simpson) Date: Sat, 16 Feb 2008 03:11:23 -0500 Subject: Let's avoid using md5 as checksum In-Reply-To: References: <390A7AAF-34EB-4F12-B7C1-2058D3ED20F4@nrao.edu> <20080216040141.GF94215@darkart.com> <1054b09b0802152349w10e017b2jcdc4b3a184eaf051@mail.gmail.com> Message-ID: <1054b09b0802160011r4c7e597bq56433c2a61d93443@mail.gmail.com> On Feb 16, 2008 2:57 AM, Ryan Schmidt wrote: > On Feb 16, 2008, at 01:49, William Allen Simpson wrote: > > As long as we ONLY use hashes generated by the distfile author, > > located on the distfile site, and NEVER generate our own, we'll be fine. > > But we don't do that. At least, I'm constantly generating my own > checksums for my portfiles. The developers of most of my ports do not > provide checksums. > Trust is not transitive. If you download a file, and generate your own hash, that really defeats the whole purpose of tarball verification. Then, it doesn't matter what checksum is used, or its cryptographic strength, as you have no way of indicating who generated that hash. From kvv at apple.com Sat Feb 16 01:20:45 2008 From: kvv at apple.com (Kevin Van Vechten) Date: Sat, 16 Feb 2008 01:20:45 -0800 Subject: Let's avoid using md5 as checksum In-Reply-To: <1054b09b0802160011r4c7e597bq56433c2a61d93443@mail.gmail.com> References: <390A7AAF-34EB-4F12-B7C1-2058D3ED20F4@nrao.edu> <20080216040141.GF94215@darkart.com> <1054b09b0802152349w10e017b2jcdc4b3a184eaf051@mail.gmail.com> <1054b09b0802160011r4c7e597bq56433c2a61d93443@mail.gmail.com> Message-ID: This is really a non-issue. The intent of the MD5 in the Portfile is easily identify when a source archive was corrupted during download, or when a 404 file was obtained instead of a source archive. It's not about security, it's about providing a checksum for data -- and to that effect MD5 will always be preferable to CRC32. Few projects are distributed with signatures, and even if they were I doubt anyone really audits the code they compile and execute. If you're really concerned about security, you need to invest in a whole lot more infrastructure and process than simply changing digest algorithms. - Kevin On Feb 16, 2008, at 12:11 AM, William Allen Simpson wrote: > On Feb 16, 2008 2:57 AM, Ryan Schmidt wrote: >> On Feb 16, 2008, at 01:49, William Allen Simpson wrote: >>> As long as we ONLY use hashes generated by the distfile author, >>> located on the distfile site, and NEVER generate our own, we'll be >>> fine. >> >> But we don't do that. At least, I'm constantly generating my own >> checksums for my portfiles. The developers of most of my ports do not >> provide checksums. >> > Trust is not transitive. > > If you download a file, and generate your own hash, that really > defeats > the whole purpose of tarball verification. Then, it doesn't matter > what > checksum is used, or its cryptographic strength, as you have no way of > indicating who generated that hash. From dbruce at tampabay.rr.com Sat Feb 16 03:41:10 2008 From: dbruce at tampabay.rr.com (David Bruce) Date: Sat, 16 Feb 2008 06:41:10 -0500 Subject: Let's avoid using md5 as checksum In-Reply-To: References: <1054b09b0802160011r4c7e597bq56433c2a61d93443@mail.gmail.com> Message-ID: <200802160641.10318.dbruce@tampabay.rr.com> Hi, I'm the upstream maintainer of tuxmath, and I also want to add it to MacPorts and become the port maintainer for it. So, regarding checksums, I take it that it would be best (from the point of view of MacPorts, and probably anyone else who cares to verify that they are getting unaltered source) to generate all three hashes and provide them at the tuxmath download site? I'm just learning, but it seems the port process involves three things: 1. writing a working Portfile. 2. adapting the source, if needed, to get it to build properly under the port system. Since I'll be both port maintainer and upstream, I don't think this will need to involve patches. 3. making the download site play nicely with MacPorts, which could be things like providing the three checksums and making it possible for ports to check if a new version has been released. I submitted a trac ticket with the first draft Portfile (#14279), and it still seems to be in limbo. Is there something else I'm supposed to be doing? I really would like to contribute to this project. Thanks, -- David Bruce From raimue at macports.org Sat Feb 16 05:29:29 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 16 Feb 2008 14:29:29 +0100 Subject: Let's avoid using md5 as checksum In-Reply-To: <19B4284F-9FF7-4461-8015-E5B36C31613A@macports.org> References: <0DD1957D-DAA9-4BA7-80BD-1FDF55DC8147@macports.org> <19B4284F-9FF7-4461-8015-E5B36C31613A@macports.org> Message-ID: <47B6E539.8050301@macports.org> Ryan Schmidt wrote: > Of course, this won't make Rainer happy. :-) > > http://trac.macosforge.org/projects/macports/browser/trunk/dports/ > editors/vim/files/patchlist?rev=34037 > > Look at all them pretty md5s... These md5s are released upstream [1] and I just use them. Of course I now could also generate additional sha1 and rmd160 checksums. But for what purpose? The upstream authors consider md5 to be safe enough for verification of the patch files. Rainer [1] ftp://ftp.vim.org/pub/vim/patches/7.1/MD5SUMS From ebgssth at gmail.com Sat Feb 16 05:47:03 2008 From: ebgssth at gmail.com (js) Date: Sat, 16 Feb 2008 22:47:03 +0900 Subject: Fwd: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't In-Reply-To: <056.59f733d9934ac6e311002f4555f790ca@macosforge.org> References: <047.9fe0e7798e644f83e5bea8fec8b4d764@macosforge.org> <056.59f733d9934ac6e311002f4555f790ca@macosforge.org> Message-ID: # Moving from Trac ticket #14342 > No, py25-foo can have different dependencies than py-foo. I don't know > what you wanted to tell us with this. I meant if we would change python24 to drop some standard modules like the current python25 port does, py-foo and py25-foo's dependencies would be the same. Not sure this is 100% same but almost the same I assume. > And there is no problem that we have more py-* ports than py25-* ports. We > just add what people request. If nobody needs a port, but it is in the > tree, it is just more work for maintainers. So if you need some port, ask > for it. No problem, but Python project now recommend users to use python2.5, not 2.4. Providing a lot of ports to python25 users would encourage users to use python2.5. Some people don't bother to write reports even if they want. I like to add more py25- ports to make python25 looks more *atrractive*. Forwarded Conversation Subject: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't ------------------------ From: MacPorts Reply-To: noreply at macosforge.org To: ebgssth at gmail.com, macports-tickets at lists.macosforge.org Cc: mww at macports.org Date: Sat, Feb 16, 2008 at 11:51 AM #14342: python25 drops modules by default, but python25 doesn't -------------------------------+-------------------------------------------- Reporter: ebgssth at gmail.com | Owner: macports-tickets at lists.macosforge.org Type: enhancement | Status: new Priority: Normal | Milestone: Port Enhancements Component: ports | Version: 1.6.0 Keywords: python | -------------------------------+-------------------------------------------- Python2.5 disables common modules by default, but python2.4 doesn't. See dports/lang/python25/files/patch-setup.py {{{ # This global variable is used to hold the list of modules to be disabled. -disabled_module_list = [] +disabled_module_list = ["zlib","_hashlib","_ssl","_bsddb","_sqlite3","_tkinter","bz2","gdbm","readline","_curses","_curses_panel"] }}} IMHO, all python pors should be as similar as they can be. -- Ticket URL: MacPorts Ports system for Mac OS -------- From: MacPorts Reply-To: noreply at macosforge.org To: ebgssth at gmail.com, macports-tickets at lists.macosforge.org Cc: mww at macports.org Date: Sat, Feb 16, 2008 at 11:52 AM #14342: python25 drops modules by default, but python25 doesn't --------------------------------+------------------------------------------- Reporter: ebgssth at gmail.com | Owner: macports-tickets at lists.macosforge.org Type: enhancement | Status: new Priority: Normal | Milestone: Port Enhancements Component: ports | Version: 1.6.0 Resolution: | Keywords: python --------------------------------+------------------------------------------- Comment (by ebgssth at gmail.com): If there's a reason, please make it clear by leaving comments about that on the patch file. -- Ticket URL: [Quoted text hidden] -------- From: MacPorts Reply-To: noreply at macosforge.org To: ebgssth at gmail.com, macports-tickets at lists.macosforge.org Cc: mww at macports.org Date: Sat, Feb 16, 2008 at 12:02 PM #14342: python25 drops modules by default, but python25 doesn't --------------------------------+------------------------------------------- Reporter: ebgssth at gmail.com | Owner: macports-tickets at lists.macosforge.org Type: enhancement | Status: new Priority: Normal | Milestone: Port Enhancements Component: ports | Version: 1.6.0 Resolution: | Keywords: python --------------------------------+------------------------------------------- Comment (by raimue at macports.org): These are provided as seperate ports. For example py25-hashlib, py25-zlib and others. I don't know what the advantage of that was, but we already had that discussion once. Portfile writers should include correct dependencies. -- Ticket URL: [Quoted text hidden] -------- From: MacPorts Reply-To: noreply at macosforge.org To: ebgssth at gmail.com, macports-tickets at lists.macosforge.org Cc: mww at macports.org Date: Sat, Feb 16, 2008 at 12:18 PM #14342: python25 drops modules by default, but python25 doesn't --------------------------------+------------------------------------------- Reporter: ebgssth at gmail.com | Owner: macports-tickets at lists.macosforge.org Type: enhancement | Status: new Priority: Normal | Milestone: Port Enhancements Component: ports | Version: 1.6.0 Resolution: | Keywords: python --------------------------------+------------------------------------------- Comment (by ebgssth at gmail.com): I think that's OK, but the thing is python24 doesn't drop these modules. It's a weird... -- Ticket URL: [Quoted text hidden] -------- From: MacPorts Reply-To: noreply at macosforge.org To: ebgssth at gmail.com, macports-tickets at lists.macosforge.org Cc: mww at macports.org Date: Sat, Feb 16, 2008 at 12:44 PM #14342: python25 drops modules by default, but python25 doesn't --------------------------------+------------------------------------------- Reporter: ebgssth at gmail.com | Owner: macports-tickets at lists.macosforge.org Type: enhancement | Status: new Priority: Normal | Milestone: Port Enhancements Component: ports | Version: 1.6.0 Resolution: | Keywords: python --------------------------------+------------------------------------------- Comment (by raimue at macports.org): If we were going to change this, it would require to change dependencies in nearly all py-* ports. -- Ticket URL: [Quoted text hidden] -------- From: MacPorts Reply-To: noreply at macosforge.org To: ebgssth at gmail.com, macports-tickets at lists.macosforge.org Cc: mww at macports.org Date: Sat, Feb 16, 2008 at 1:59 PM #14342: python25 drops modules by default, but python25 doesn't --------------------------------+------------------------------------------- Reporter: ebgssth at gmail.com | Owner: macports-tickets at lists.macosforge.org Type: enhancement | Status: new Priority: Normal | Milestone: Port Enhancements Component: ports | Version: 1.6.0 Resolution: | Keywords: python --------------------------------+------------------------------------------- Comment (by ebgssth at gmail.com): Replying to [comment:4 raimue at macports.org]: > If we were going to change this, it would require to change dependencies in nearly all py-* ports. Yes, we probably have to check py-ports that was not in py25 ports {{{ $ port list |egrep -i '^py-' | cut -d" " -f1 | sort -u > py24 $ port list |egrep -i '^py25-' | cut -d" " -f1 | sed 's/^py25/py/' | sort -u > py25 $ wc -l py2[45] 338 py24 109 py25 447 total $ comm -2 -3 py24 py25 > py24-only $ wc -l py24-only 259 py24-only }}} How about create py25- ports of all 259 py24 only ports? To create py25-ports, we need to know the port need zlib or hashlib, which helps identify this py24 ports should be fixed. -- Ticket URL: [Quoted text hidden] -------- From: MacPorts Reply-To: noreply at macosforge.org To: ebgssth at gmail.com, macports-tickets at lists.macosforge.org Cc: mww at macports.org Date: Sat, Feb 16, 2008 at 6:27 PM #14342: python25 drops modules by default, but python25 doesn't --------------------------------+------------------------------------------- Reporter: ebgssth at gmail.com | Owner: macports-tickets at lists.macosforge.org Type: enhancement | Status: new Priority: Normal | Milestone: Port Enhancements Component: ports | Version: 1.6.0 Resolution: | Keywords: python --------------------------------+------------------------------------------- Comment (by ebgssth at gmail.com): From a different point of view, that MacPorts has lots more python2.4 ports than python2.5's seems weird to me. (Python 2.5 is the current stable, Python 2.4 series will be no longer released anymore) Should I open another ticket about this problem? -- Ticket URL: [Quoted text hidden] -------- From: MacPorts Reply-To: noreply at macosforge.org To: ebgssth at gmail.com, macports-tickets at lists.macosforge.org Cc: mww at macports.org Date: Sat, Feb 16, 2008 at 9:33 PM #14342: python25 drops modules by default, but python25 doesn't --------------------------------+------------------------------------------- Reporter: ebgssth at gmail.com | Owner: macports-tickets at lists.macosforge.org Type: enhancement | Status: new Priority: Normal | Milestone: Port Enhancements Component: ports | Version: 1.6.0 Resolution: | Keywords: python --------------------------------+------------------------------------------- Comment (by raimue at macports.org): Replying to [comment:5 ebgssth at gmail.com]: > Yes, we probably have to check py-ports that was not in py25 ports No, py25-foo can have different dependencies than py-foo. I don't know what you wanted to tell us with this. And there is no problem that we have more py-* ports than py25-* ports. We just add what people request. If nobody needs a port, but it is in the tree, it is just more work for maintainers. So if you need some port, ask for it. PS: This kind of discussion would have been better on the mailing list. -- Ticket URL: [Quoted text hidden] -------- From ebgssth at gmail.com Sat Feb 16 05:55:19 2008 From: ebgssth at gmail.com (js) Date: Sat, 16 Feb 2008 22:55:19 +0900 Subject: 72 hours are not enough for maintainers? In-Reply-To: <47B60EFD.30406@orcaware.com> References: <47B60EFD.30406@orcaware.com> Message-ID: Hi Blair, If Maintainers think so, that's fine with me. I just guessed 72 hours are not practical to accept for maintainers. On 2/16/08, Blair Zajac wrote: > js wrote: > > Hi, > > > > MacPorts Guide says > > > > "The maintainer should apply the patches and close the ticket within 72 hours." > > "If the maintainer does not respond within 72 hours, you or another > > committer may review the patches and update the port." > > > > But actually this is not always the case. > > So I started to consider 72 hours restriction is not realistic so this > > part of guideline should be modified to be more practical. > > > > Any comments? > > Depends upon what side of the coin you are on. Sometimes I want to get a fix in > for another port and waiting 3 days seems like forever. Other times I miss an > email for an update on my port, but I don't typically mind somebody else fixing > it. I can always change the fix after it goes in and increment the revision. > > So three days seems like a reasonable middle-ground. > > Blair > > -- > Blair Zajac, Ph.D. > http://www.orcaware.com/svn/ > From jmpp at macports.org Sat Feb 16 12:56:32 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Sat, 16 Feb 2008 16:26:32 -0430 Subject: Splitting the guide Message-ID: <9CB07731-AF8B-4382-A929-A768718A030D@macports.org> Hey guys! The guide is advancing so nicely that I'm afraid we've hit the point when it's maybe becoming a tad too large for a single page, wouldn't y'all think? Every time I have to load a section of the guide a have a moment of hesitation in fear of loading such a large document! At this point in time, wouldn't it be better to have a single html page per chapter? Just my thoughts,... -jmpp From markd at macports.org Sat Feb 16 14:46:33 2008 From: markd at macports.org (markd at macports.org) Date: Sat, 16 Feb 2008 14:46:33 -0800 Subject: Splitting the guide Message-ID: > Hey guys! > > The guide is advancing so nicely that I'm afraid we've hit the >point >when it's maybe becoming a tad too large for a single page, wouldn't >y'all think? > > Every time I have to load a section of the guide a have a moment >of >hesitation in fear of loading such a large document! At this point in >time, wouldn't it be better to have a single html page per chapter? > > Just my thoughts,... > > >-jmpp Juan, Well I agree it is really too big, but on the other hand we hated to split it and have cumbersome "forward" and "back" buttons. Also it makes searching easier in one page, but then I suppose indexing might solve that. But then maybe a page for each chapter wouldn't be too bad. I guess we should experiment and see how it looks and drives. Mark From raimue at macports.org Sat Feb 16 16:32:09 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 17 Feb 2008 01:32:09 +0100 Subject: Splitting the guide In-Reply-To: References: Message-ID: <47B78089.1020505@macports.org> markd at macports.org wrote: > Well I agree it is really too big, but on the other hand we hated to split > it and have cumbersome "forward" and "back" buttons. Also it makes > searching easier in one page, but then I suppose indexing might solve > that. But then maybe a page for each chapter wouldn't be too bad. I > guess we should experiment and see how it looks and drives. It would be nice to have at least the chapters on seperate pages. Also, many other projects offer both versions. A single page HTML version and multiple pages HTML version. Wouldn't be much work, just generating them both with different stylesheets would take longer... But as we are talking about the guide, I might also bring up another issue with the current presentation. I find it difficult to link to specific headlines. Could the headlines made clickable with a link target on themself? Or maybe some marker item on mouse-move like trac does? At the moment I always look into the source to find out how the anchor was named which is a little bit annoying. Consider this as a nice-to-have issue ;-) I already looked into the generation scripts for this, but it seems to use a xslt stylesheet provided completely by docbook, so I don't know if I would have to file my request there... Rainer From vincent-opdarw at vinc17.org Sat Feb 16 17:18:27 2008 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Sun, 17 Feb 2008 02:18:27 +0100 Subject: unison and protocol breakage Message-ID: <20080217011826.GP619@prunille.vinc17.org> The unison port has recently been upgraded from 2.13 to 2.27. The problem is that the protocol has changed between these versions, and unison 2.13 can't talk to unison 2.27: http://trac.macosforge.org/projects/macports/ticket/14172 The only solution that can work in every case (because users may need to do synchronization with machines that only have 2.13 and machines that only have 2.27) is to install the two binaries: unison-2.13 and unison-2.27 (note: when executing the remote unison binary, unison can automatically add its main version number thanks to the addversionno option). So, I think that the best solution is to have a port for the old version unison 2.13 (BTW, this is what Debian does for the 2.9 version and will probably do for the 2.13 version), which installs only the unison-2.13 binary (alternatively, there could be a variant that installs a "unison" binary too for those who don't need unison 2.27). In this case, what should the name of the port be? unison-2.13? unison2.13? -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From ebgssth at gmail.com Sat Feb 16 17:36:08 2008 From: ebgssth at gmail.com (js) Date: Sun, 17 Feb 2008 10:36:08 +0900 Subject: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't In-Reply-To: References: <047.9fe0e7798e644f83e5bea8fec8b4d764@macosforge.org> <056.59f733d9934ac6e311002f4555f790ca@macosforge.org> Message-ID: Just out of curiosity, could you tell me why default python25 drops those modoles? From ryandesign at macports.org Sat Feb 16 17:43:29 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 16 Feb 2008 19:43:29 -0600 Subject: tuxmath Portfile In-Reply-To: <200802111838.57404.dbruce@tampabay.rr.com> References: <200802111838.57404.dbruce@tampabay.rr.com> Message-ID: <57E3739C-7F28-4A5F-BCDC-BF9742686B0F@macports.org> On Feb 11, 2008, at 17:38, David Bruce wrote: > After some study of the guide (as well as several existing > Portfiles), I've > taken my first stab at writing a Portfile for tuxmath and submitted > it as > trac ticket #14279. How can I start testing it to see what needs > to be > fixed? > > Tuxmath uses automake, so I am fairly sure it supports DESTDIR > already. > > Thanks, and pardon my noob-hood with regard to MacPorts. It looks like Rainer will take care of it. To test a Portfile, put it in any directory on your hard disk, "cd" to that directory in the Terminal, and type "sudo port install". And see if it works. From ryandesign at macports.org Sat Feb 16 17:44:09 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 16 Feb 2008 19:44:09 -0600 Subject: Let's avoid using md5 as checksum In-Reply-To: <200802160641.10318.dbruce@tampabay.rr.com> References: <1054b09b0802160011r4c7e597bq56433c2a61d93443@mail.gmail.com> <200802160641.10318.dbruce@tampabay.rr.com> Message-ID: <3A096A15-6E11-4C92-986D-D2418485B872@macports.org> On Feb 16, 2008, at 05:41, David Bruce wrote: > I'm the upstream maintainer of tuxmath, and I also want to add it > to MacPorts > and become the port maintainer for it. So, regarding checksums, I > take it > that it would be best (from the point of view of MacPorts, and > probably > anyone else who cares to verify that they are getting unaltered > source) to > generate all three hashes and provide them at the tuxmath download > site? > > I'm just learning, but it seems the port process involves three > things: > 1. writing a working Portfile. > 2. adapting the source, if needed, to get it to build properly > under the port > system. Since I'll be both port maintainer and upstream, I don't > think this > will need to involve patches. > 3. making the download site play nicely with MacPorts, which could > be things > like providing the three checksums and making it possible for ports > to check > if a new version has been released. > > I submitted a trac ticket with the first draft Portfile (#14279), > and it still > seems to be in limbo. Is there something else I'm supposed to be > doing? I > really would like to contribute to this project. Rainer has commented on your ticket so once you review those changes I imagine he'll commit it. I saw your earlier message but did not have time to deal with it. Sometimes we're just short on time and tickets get forgotten. From raimue at macports.org Sat Feb 16 17:56:21 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 17 Feb 2008 02:56:21 +0100 Subject: Committing new port submissions (was: Re: Let's avoid using md5 as checksum) In-Reply-To: <3A096A15-6E11-4C92-986D-D2418485B872@macports.org> References: <1054b09b0802160011r4c7e597bq56433c2a61d93443@mail.gmail.com> <200802160641.10318.dbruce@tampabay.rr.com> <3A096A15-6E11-4C92-986D-D2418485B872@macports.org> Message-ID: <47B79445.9010402@macports.org> Ryan Schmidt wrote: > Rainer has commented on your ticket so once you review those changes > I imagine he'll commit it. Yes, that was my intention :-) > I saw your earlier message but did not have time to deal with it. > Sometimes we're just short on time and tickets get forgotten. That's often the problem... Sometimes I see a new open ticket in Port Submission and if I am personally interested in this software I might commit it right away after testing. But on other submissions if I have no time I just mark the mail as read and forget about it... I would suggest, if nobody comments or takes action on your port submission after a few days, just ping the macports-dev list. Rainer From ebgssth at gmail.com Sun Feb 17 01:17:57 2008 From: ebgssth at gmail.com (js) Date: Sun, 17 Feb 2008 18:17:57 +0900 Subject: Proposal: reminder to the assignee when a ticket is unchanged more than 3 days Message-ID: I'm not sure whether Trac has this capability or not, but I think having reminder would prevent maintainers from missing their jobs. The reminder would be sent to maintainers when - the status of the ticket remains new more than 3 days - the ticket has a patch to review but not answered more than 3 days (How is this possible?) - etc. Any comments? From afb at macports.org Sun Feb 17 01:18:28 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun, 17 Feb 2008 10:18:28 +0100 Subject: Let's avoid using md5 as checksum In-Reply-To: References: <47B6606E.7010007@macports.org> Message-ID: <86450BC9-3AB4-4E74-89A6-5DDD7C7CD636@macports.org> Jordan K. Hubbard wrote: > Given all the other unfinished or unstarted work in MacPorts which > needs to happen just to get the collection halfway reliable, it seems > to me that arguing over the safety of a commonly used checksum is > little more than a distraction and represents time that could be > devoted to more important pursuits, like cleaning up the variant code, > or getting a distributed unit testing setup going, or ... I guess now with all the whitespace converted and the extra modelines added and all the patchfiles renamed, we need some new distraction... Or we could paint it mauve ? --anders From afb at macports.org Sun Feb 17 01:23:11 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun, 17 Feb 2008 10:23:11 +0100 Subject: Updating macports.conf In-Reply-To: <2314B5DB-FE12-4F70-984E-E7EB887D281F@macports.org> References: <47B64413.7050407@macports.org> <86AB9772-B806-4CDB-9F79-FD86A392AC67@apple.com> <2314B5DB-FE12-4F70-984E-E7EB887D281F@macports.org> Message-ID: <516783DC-F7AB-4E35-BD41-01609890BCAF@macports.org> >> This is, in any case, how I'd handle this one. Always install a >> macports.conf.default and add some logic to load the two in order >> (macports.conf should, in fact, be optional). > > Great, and after we solve this, we'll do the same for all the > software one could install using MacPorts, right? :-D Sure, why not - other package systems do it already... ? http://trac.macports.org/projects/macports/ticket/12797 http://trac.macports.org/projects/macports/ticket/2365 --anders From eridius at macports.org Sun Feb 17 05:36:37 2008 From: eridius at macports.org (Kevin Ballard) Date: Sun, 17 Feb 2008 08:36:37 -0500 Subject: unison and protocol breakage In-Reply-To: <20080217011826.GP619@prunille.vinc17.org> References: <20080217011826.GP619@prunille.vinc17.org> Message-ID: No, the solution here is to not do anything. Anybody using 2.13 needs to upgrade if they want to work with 2.27. We are not in the business of providing old port versions, and we *should not* be. If you're using debian/stable, just install unison 2.27 yourself. IIRC the default location is $HOME/bin, so you don't need to do *any* work to install it besides download the source and build it. Presumably you have ocaml installed already. -Kevin Ballard On Feb 16, 2008, at 8:18 PM, Vincent Lefevre wrote: > The unison port has recently been upgraded from 2.13 to 2.27. The > problem is that the protocol has changed between these versions, > and unison 2.13 can't talk to unison 2.27: > > http://trac.macosforge.org/projects/macports/ticket/14172 > > The only solution that can work in every case (because users may need > to do synchronization with machines that only have 2.13 and machines > that only have 2.27) is to install the two binaries: unison-2.13 and > unison-2.27 (note: when executing the remote unison binary, unison can > automatically add its main version number thanks to the addversionno > option). So, I think that the best solution is to have a port for the > old version unison 2.13 (BTW, this is what Debian does for the 2.9 > version and will probably do for the 2.13 version), which installs > only > the unison-2.13 binary (alternatively, there could be a variant that > installs a "unison" binary too for those who don't need unison 2.27). > In this case, what should the name of the port be? unison-2.13? > unison2.13? > > -- > Vincent Lef?vre - Web: > 100% accessible validated (X)HTML - Blog: blog/> > Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS- > Lyon) > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev -- Kevin Ballard http://kevin.sb.org eridius at macports.org http://www.tildesoft.com From eridius at macports.org Sun Feb 17 05:38:50 2008 From: eridius at macports.org (Kevin Ballard) Date: Sun, 17 Feb 2008 08:38:50 -0500 Subject: variant cascade In-Reply-To: <47AF7CCB.7020609@reifferscheid.org> References: <47AF7CCB.7020609@reifferscheid.org> Message-ID: <27F7B13E-D0D2-48FC-B639-77EFBDD44887@macports.org> I don't believe so, but this is undocumented. However, I don't think it should either. Here's a setup where it will cause confusion: http://pastie.textmate.org/153371 There's no requirement that dependencies are processed in order, and just looking at the 'tea' Portfile in my example, there would be no way of knowing that 'milk' will get built with +bar. This should be documented, sure, but I don't think it should be changed. However, I do think this is another example of how our dependency engine fails. -Kevin Ballard On Feb 10, 2008, at 5:38 PM, Thomas Reifferscheid wrote: > Will "port install tea +foo" build the port coffee +bar? > > > Portfile tea: > > depends_lib port:coffee > > variant foo requires bar { > } > variant bar { > } > > ====================== > > Portfile coffee: > > variant bar { > } > > > Kind regards > Thomas > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev -- Kevin Ballard http://kevin.sb.org eridius at macports.org http://www.tildesoft.com From pguyot at kallisys.net Sun Feb 17 06:08:51 2008 From: pguyot at kallisys.net (Paul Guyot) Date: Sun, 17 Feb 2008 15:08:51 +0100 Subject: unison and protocol breakage In-Reply-To: References: <20080217011826.GP619@prunille.vinc17.org> Message-ID: <8554AC16-8E45-445B-B466-4D49F15A7F09@kallisys.net> I'd say the good strategy is to have the ubiquitous version. At some point I synchronized the version of unison with the version available with FreeBSD ports because it's what I used on the other end. On the other hand, debian/stable is lagging so much that they probably should not be considered as a reference. Paul Le 17 f?vr. 08 ? 14:36, Kevin Ballard a ?crit : > No, the solution here is to not do anything. Anybody using 2.13 needs > to upgrade if they want to work with 2.27. We are not in the business > of providing old port versions, and we *should not* be. > > If you're using debian/stable, just install unison 2.27 yourself. IIRC > the default location is $HOME/bin, so you don't need to do *any* work > to install it besides download the source and build it. Presumably you > have ocaml installed already. > > -Kevin Ballard > > On Feb 16, 2008, at 8:18 PM, Vincent Lefevre wrote: > >> The unison port has recently been upgraded from 2.13 to 2.27. The >> problem is that the protocol has changed between these versions, >> and unison 2.13 can't talk to unison 2.27: >> >> http://trac.macosforge.org/projects/macports/ticket/14172 >> >> The only solution that can work in every case (because users may need >> to do synchronization with machines that only have 2.13 and machines >> that only have 2.27) is to install the two binaries: unison-2.13 and >> unison-2.27 (note: when executing the remote unison binary, unison >> can >> automatically add its main version number thanks to the addversionno >> option). So, I think that the best solution is to have a port for the >> old version unison 2.13 (BTW, this is what Debian does for the 2.9 >> version and will probably do for the 2.13 version), which installs >> only >> the unison-2.13 binary (alternatively, there could be a variant that >> installs a "unison" binary too for those who don't need unison 2.27). >> In this case, what should the name of the port be? unison-2.13? >> unison2.13? >> >> -- >> Vincent Lef?vre - Web: >> 100% accessible validated (X)HTML - Blog: > blog/> >> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS- >> Lyon) >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > -- > Kevin Ballard > http://kevin.sb.org > eridius at macports.org > http://www.tildesoft.com > > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev -- http://paul-guyot.com/ From eridius at macports.org Sun Feb 17 06:15:47 2008 From: eridius at macports.org (Kevin Ballard) Date: Sun, 17 Feb 2008 09:15:47 -0500 Subject: unison and protocol breakage In-Reply-To: <8554AC16-8E45-445B-B466-4D49F15A7F09@kallisys.net> References: <20080217011826.GP619@prunille.vinc17.org> <8554AC16-8E45-445B-B466-4D49F15A7F09@kallisys.net> Message-ID: Right now we're providing the official, released, stable version. That's what we should provide. -Kevin Ballard On Feb 17, 2008, at 9:08 AM, Paul Guyot wrote: > I'd say the good strategy is to have the ubiquitous version. At some > point I synchronized the version of unison with the version > available with FreeBSD ports because it's what I used on the other > end. On the other hand, debian/stable is lagging so much that they > probably should not be considered as a reference. > > Paul > > Le 17 f?vr. 08 ? 14:36, Kevin Ballard a ?crit : > >> No, the solution here is to not do anything. Anybody using 2.13 needs >> to upgrade if they want to work with 2.27. We are not in the business >> of providing old port versions, and we *should not* be. >> >> If you're using debian/stable, just install unison 2.27 yourself. >> IIRC >> the default location is $HOME/bin, so you don't need to do *any* work >> to install it besides download the source and build it. Presumably >> you >> have ocaml installed already. >> >> -Kevin Ballard >> >> On Feb 16, 2008, at 8:18 PM, Vincent Lefevre wrote: >> >>> The unison port has recently been upgraded from 2.13 to 2.27. The >>> problem is that the protocol has changed between these versions, >>> and unison 2.13 can't talk to unison 2.27: >>> >>> http://trac.macosforge.org/projects/macports/ticket/14172 >>> >>> The only solution that can work in every case (because users may >>> need >>> to do synchronization with machines that only have 2.13 and machines >>> that only have 2.27) is to install the two binaries: unison-2.13 and >>> unison-2.27 (note: when executing the remote unison binary, unison >>> can >>> automatically add its main version number thanks to the addversionno >>> option). So, I think that the best solution is to have a port for >>> the >>> old version unison 2.13 (BTW, this is what Debian does for the 2.9 >>> version and will probably do for the 2.13 version), which installs >>> only >>> the unison-2.13 binary (alternatively, there could be a variant that >>> installs a "unison" binary too for those who don't need unison >>> 2.27). >>> In this case, what should the name of the port be? unison-2.13? >>> unison2.13? >>> >>> -- >>> Vincent Lef?vre - Web: >>> 100% accessible validated (X)HTML - Blog: >> blog/> >>> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS- >>> Lyon) >>> _______________________________________________ >>> macports-dev mailing list >>> macports-dev at lists.macosforge.org >>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev >> >> -- >> Kevin Ballard >> http://kevin.sb.org >> eridius at macports.org >> http://www.tildesoft.com >> >> >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > -- > http://paul-guyot.com/ > > > -- Kevin Ballard http://kevin.sb.org eridius at macports.org http://www.tildesoft.com From vincent-opdarw at vinc17.org Sun Feb 17 06:25:15 2008 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Sun, 17 Feb 2008 15:25:15 +0100 Subject: unison and protocol breakage In-Reply-To: References: <20080217011826.GP619@prunille.vinc17.org> Message-ID: <20080217142515.GS619@prunille.vinc17.org> On 2008-02-17 08:36:37 -0500, Kevin Ballard wrote: > No, the solution here is to not do anything. Anybody using 2.13 needs to > upgrade if they want to work with 2.27. We are not in the business of > providing old port versions, and we *should not* be. So, what about these old db, qt and automake ports? > If you're using debian/stable, just install unison 2.27 yourself. That's too much work (too many machines). I now have my local unison-2.13 port. -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From evenson at panix.com Sun Feb 17 06:44:11 2008 From: evenson at panix.com (Mark Evenson) Date: Sun, 17 Feb 2008 15:44:11 +0100 Subject: Re-requesting commit for 'lang/slime' 14136 Message-ID: I maintain 'lang/slime' but do not have commit rights. Could someone please review the [Portfile attached to ticket 14136][1], and either provide feedback or commit it? Extensive commentary on the changes has been attached to this ticket. [1]: http://trac.macosforge.org/projects/macports/ticket/14136 Thanks, Mark -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." From vincent-opdarw at vinc17.org Sun Feb 17 17:28:35 2008 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Mon, 18 Feb 2008 02:28:35 +0100 Subject: unison and protocol breakage In-Reply-To: References: <20080217011826.GP619@prunille.vinc17.org> <8554AC16-8E45-445B-B466-4D49F15A7F09@kallisys.net> Message-ID: <20080218012835.GW619@prunille.vinc17.org> On 2008-02-17 09:15:47 -0500, Kevin Ballard wrote: > Right now we're providing the official, released, stable version. That's > what we should provide. I agree that it should be provided. What I was requesting is that 2.13 be provided as well (but 2.27 would still be the default). And I don't think one can blame Debian or administrators of machines that have 2.13 only, in particular because 2.27 was released as stable on January 21: http://tech.groups.yahoo.com/group/unison-announce/message/51 i.e. less than a month ago. If you still think that 2.13 is outdated and must not be provided for this reason, then I propose to remove any software that is more than one-month old. -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From evenson.not.org at gmail.com Sun Feb 17 04:16:17 2008 From: evenson.not.org at gmail.com (Mark Evenson) Date: Sun, 17 Feb 2008 13:16:17 +0100 Subject: Can some kind committer please promote/comment on "emacs compiling on Leopard" ticket #13492 Message-ID: <47B82591.90706@gmail.com> The ticket for [Emacs build broken under Leopard][1] has been open for a month, complete with a patch and verified solution. Could kind soul please either commit this patch or respond with feedback as to what needs to be done? [1]: http://trac.macosforge.org/projects/macports/ticket/13942 From ryandesign at macports.org Mon Feb 18 00:04:39 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 18 Feb 2008 02:04:39 -0600 Subject: [34202] trunk/dports/databases/mysql5-devel/Portfile In-Reply-To: <20080217142430.5B7831290FF7@beta.macosforge.org> References: <20080217142430.5B7831290FF7@beta.macosforge.org> Message-ID: <96DE3ED9-24AB-4311-8196-2F4E7DE49B49@macports.org> On Feb 17, 2008, at 08:24, jwa at macports.org wrote: > Revision: 34202 > http://trac.macosforge.org/projects/macports/changeset/34202 > Author: jwa at macports.org > Date: 2008-02-17 06:24:27 -0800 (Sun, 17 Feb 2008) > > Log Message: > ----------- > lint clean trailing whitespace The whitespace on those lines was intentional and desired by me. Lint's warning in this case was erroneous, an error I have already corrected in trunk. From ryandesign at macports.org Mon Feb 18 01:34:24 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 18 Feb 2008 03:34:24 -0600 Subject: unison and protocol breakage In-Reply-To: <20080218012835.GW619@prunille.vinc17.org> References: <20080217011826.GP619@prunille.vinc17.org> <8554AC16-8E45-445B-B466-4D49F15A7F09@kallisys.net> <20080218012835.GW619@prunille.vinc17.org> Message-ID: On Feb 17, 2008, at 19:28, Vincent Lefevre wrote: > On 2008-02-17 09:15:47 -0500, Kevin Ballard wrote: > >> Right now we're providing the official, released, stable version. >> That's >> what we should provide. > > I agree that it should be provided. What I was requesting is that > 2.13 be provided as well (but 2.27 would still be the default). And > I don't think one can blame Debian or administrators of machines > that have 2.13 only, in particular because 2.27 was released as > stable on January 21: > > http://tech.groups.yahoo.com/group/unison-announce/message/51 > > i.e. less than a month ago. If you still think that 2.13 is outdated > and must not be provided for this reason, then I propose to remove > any software that is more than one-month old. Vincent, I'm sure you were proposing that to illustrate how ludicrous it would be. I'm sure we currently have many many ports that install software that's outdated by more than a month. On Feb 17, 2008, at 07:36, Kevin Ballard wrote: > No, the solution here is to not do anything. Anybody using 2.13 needs > to upgrade if they want to work with 2.27. We are not in the business > of providing old port versions, and we *should not* be. Kevin, I think we are in fact in the business of providing old port versions too. Where the newer version of the software is incompatible in some way with the older version of the software, it's reasonable to have two portfiles, if there is still demand for the older version. We already have this for several software packages. Consider php5 and php4; apache2, apache20 and apache; apr and apr0; mysql5, mysql4 and mysql3; postgresql83, postgresql82, postgresql81, postgresql80 and postgresql7; db46, db45, db44, db43, db42, db41 and db3. From ryandesign at macports.org Mon Feb 18 01:38:03 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 18 Feb 2008 03:38:03 -0600 Subject: Proposal: reminder to the assignee when a ticket is unchanged more than 3 days In-Reply-To: References: Message-ID: On Feb 17, 2008, at 03:17, js wrote: > I'm not sure whether Trac has this capability or not, > but I think having reminder would prevent maintainers from > missing their jobs. > > The reminder would be sent to maintainers when > - the status of the ticket remains new more than 3 days > - the ticket has a patch to review but not answered more than 3 days > (How is this possible?) > - etc. > > Any comments? I really don't need more automated MacPorts mail about tickets at this point. If someone cares about one of my open tickets, they should add a comment or email me about it. And if nobody comments or emails me, then it might not be so important that I resolve the ticket immediately. From ryandesign at macports.org Mon Feb 18 01:48:00 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 18 Feb 2008 03:48:00 -0600 Subject: [34218] trunk/dports/lang In-Reply-To: <20080218091344.7F0AE12AF382@beta.macosforge.org> References: <20080218091344.7F0AE12AF382@beta.macosforge.org> Message-ID: <2CB32F21-AFB9-4DC8-A65B-6206E3E2D14A@macports.org> On Feb 18, 2008, at 03:13, erickt at macports.org wrote: > Revision: 34218 [snip here and several places below] > Added: trunk/dports/lang/llvm-gcc42/Portfile > +patchfiles patch-gcc_Makefile.in Patchfile names should end with ".diff"; see output of "port lint" > +post-destroot { > + cd ${destroot}${prefix} Please don't use the "cd" command. It does not exist in MacPorts trunk and will not exist in MacPorts 1.7.0 and later. > +platform darwin { > + post-extract { > + system "rm -rf ${workpath}/llvm-gcc${major}-${version}.source/ > libstdc++-v3" Wouldn't "file delete ..." have been sufficient in place of "system 'rm -rf ...'"? > +platform powerpc { > + set triple powerpc-apple-darwin8 > + > + configure.env-append TRIPLE=${triple} > + configure.post_args --build=${triple} --host=${triple} --target= > ${triple} > +} > + > +platform x86 { There is no such thing as "platform x86". If you want to target Intel machines, use "platform i386". > + set triple i686-apple-darwin8 > + > + configure.env-append TRIPLE=${triple} \ > + TARGETOPTIONS="--with-arch=nocona --with- > tune=generic" > + configure.post_args --build=${triple} --host=${triple} --target= > ${triple} > +} You may in fact want to use "platform darwin powerpc" and "platform darwin i386" since a triple including "apple" is probably only appropriate on darwin. In fact you may also want to factor out common code. Like this (untested): set triple apple-darwin8 platform darwin powerpc { set triple powerpc-${triple} } platform darwin i386 { set triple i686-${triple} configure.env-append TARGETOPTIONS="--with-arch=nocona --with- tune=generic" } platform darwin { pre-configure { configure.env-append TRIPLE=${triple} configure.post_args --build=${triple} --host=${triple} --target=$ {triple} } } Is a triple including "darwin8" appropriate on darwin 7 or darwin 9? (I don't know; I'm just asking.) From ebgssth at gmail.com Mon Feb 18 04:51:57 2008 From: ebgssth at gmail.com (js) Date: Mon, 18 Feb 2008 21:51:57 +0900 Subject: Proposal: reminder to the assignee when a ticket is unchanged more than 3 days In-Reply-To: References: Message-ID: >From reporter's view point, sending reminders is boring job. So I thought I would be better to automate it. Actually, I frequently found tickets which seem no one working on. (Maybe MacPorts project have not enough maintainers?) That means I have to write reminders again and again. Besides, I don't have permission to change Assigned to field of a Trac ticket. Maintainers probably don't see ticket not assigned to them. If I could assign maintainers to my tickets, I might help the situation. On 2/18/08, Ryan Schmidt wrote: > > On Feb 17, 2008, at 03:17, js wrote: > > > I'm not sure whether Trac has this capability or not, > > but I think having reminder would prevent maintainers from > > missing their jobs. > > > > The reminder would be sent to maintainers when > > - the status of the ticket remains new more than 3 days > > - the ticket has a patch to review but not answered more than 3 days > > (How is this possible?) > > - etc. > > > > Any comments? > > I really don't need more automated MacPorts mail about tickets at > this point. If someone cares about one of my open tickets, they > should add a comment or email me about it. And if nobody comments or > emails me, then it might not be so important that I resolve the > ticket immediately. > > From afb at macports.org Mon Feb 18 04:51:17 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 18 Feb 2008 13:51:17 +0100 Subject: [34218] trunk/dports/lang In-Reply-To: <2CB32F21-AFB9-4DC8-A65B-6206E3E2D14A@macports.org> References: <20080218091344.7F0AE12AF382@beta.macosforge.org> <2CB32F21-AFB9-4DC8-A65B-6206E3E2D14A@macports.org> Message-ID: Ryan Schmidt wrote: > Is a triple including "darwin8" appropriate on darwin 7 or darwin 9? > (I don't know; I'm just asking.) Nope. --anders From eridius at macports.org Mon Feb 18 05:48:36 2008 From: eridius at macports.org (Kevin Ballard) Date: Mon, 18 Feb 2008 08:48:36 -0500 Subject: unison and protocol breakage In-Reply-To: References: <20080217011826.GP619@prunille.vinc17.org> <8554AC16-8E45-445B-B466-4D49F15A7F09@kallisys.net> <20080218012835.GW619@prunille.vinc17.org> Message-ID: <03FD876A-27A1-4287-8B09-44C780B8FBB7@macports.org> On Feb 18, 2008, at 4:34 AM, Ryan Schmidt wrote: > On Feb 17, 2008, at 07:36, Kevin Ballard wrote: > >> No, the solution here is to not do anything. Anybody using 2.13 needs >> to upgrade if they want to work with 2.27. We are not in the business >> of providing old port versions, and we *should not* be. > > Kevin, I think we are in fact in the business of providing old port > versions too. Where the newer version of the software is > incompatible in some way with the older version of the software, > it's reasonable to have two portfiles, if there is still demand for > the older version. We already have this for several software > packages. Consider php5 and php4; apache2, apache20 and apache; apr > and apr0; mysql5, mysql4 and mysql3; postgresql83, postgresql82, > postgresql81, postgresql80 and postgresql7; db46, db45, db44, db43, > db42, db41 and db3. That's a bit different - those are specific versions as required by other ports (at least, if they aren't then why the hell do we still have Portfiles for them?). Unison is not required by other ports, and if it were these other ports wouldn't require a specific version. Therefore, we shouldn't be providing old ports because we don't have to maintain them for dependencies. If the majority of committers want to say "lets provide unison 2.13", I will disagree, but I will not stop you. Note: It really is fairly trivial to install unison by hand once you have OCaml installed. If you have a debian machine that doesn't provide unison 2.27, just install it manually! Seriously! It's easier than trying to get Unison 2.13 into MacPorts. -Kevin Ballard -- Kevin Ballard http://kevin.sb.org eridius at macports.org http://www.tildesoft.com From ebgssth at gmail.com Mon Feb 18 07:54:46 2008 From: ebgssth at gmail.com (js) Date: Tue, 19 Feb 2008 00:54:46 +0900 Subject: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't In-Reply-To: References: <047.9fe0e7798e644f83e5bea8fec8b4d764@macosforge.org> <056.59f733d9934ac6e311002f4555f790ca@macosforge.org> Message-ID: There seems to be few people who is interested in this issue :( I really love to fix this for consistency. If somebody asked, I'd do create py25-ports which already exist for python24. python25 should be more used than python24. The more modules python25 has, the more people likely to use python25 I assume.. From raimue at macports.org Mon Feb 18 08:27:43 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 18 Feb 2008 17:27:43 +0100 Subject: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't In-Reply-To: References: <047.9fe0e7798e644f83e5bea8fec8b4d764@macosforge.org> <056.59f733d9934ac6e311002f4555f790ca@macosforge.org> Message-ID: <47B9B1FF.7080105@macports.org> js wrote: > Just out of curiosity, could you tell me why default python25 drops > those modoles? I really don't know it, Markus will know more about it. Rainer From mww at macports.org Mon Feb 18 08:53:58 2008 From: mww at macports.org (Markus Weissmann) Date: Mon, 18 Feb 2008 17:53:58 +0100 Subject: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't In-Reply-To: <47B9B1FF.7080105@macports.org> References: <047.9fe0e7798e644f83e5bea8fec8b4d764@macosforge.org> <056.59f733d9934ac6e311002f4555f790ca@macosforge.org> <47B9B1FF.7080105@macports.org> Message-ID: <6B342869-BC6E-48D4-960A-254D89BE16AC@macports.org> On 18 Feb 2008, at 17:27, Rainer M?ller wrote: > js wrote: >> Just out of curiosity, could you tell me why default python25 drops >> those modoles? > > I really don't know it, Markus will know more about it. > does not compute: "python25 drops but python25 doesn't" -- contradiction detected. ;) If the question was why python25 does not build all auxiliary modules [1] like _sqlite3 etc.: For people who don't need e.g. tk-support, building all those dependencies is unnecessary. We had this discussion of which modules would be cool to include by default and which not to already. Conclusion was that either we rename python25 to python25-core and make a "virtual" port python25 that requires all modules+python25-core OR to make a python25-all (or whatever) port that collects all "cool" modules by dependency. The former sucks because we would need to change a lot of dependencies and the latter never made it into the repository because nobody cared enough. If someone is keen on getting the former to work: Please fix all dependencies!!! (And please also make this consistent for 2.4 and 3.0) Regards, -Markus [1] http://trac.macports.org/projects/macports/wiki/FAQ#WhycantIimportfooinPython2.5 -- Dipl. Inf. (FH) Markus W. Weissmann http://www.macports.org/ http://www.mweissmann.de/ From blair at orcaware.com Mon Feb 18 09:57:42 2008 From: blair at orcaware.com (Blair Zajac) Date: Mon, 18 Feb 2008 09:57:42 -0800 Subject: master_sites not required if fetch.type is svn Message-ID: <02A02FDF-A425-48C2-93FC-52D348F6708C@orcaware.com> Hi, I'm getting this lint warning: Error: Missing required variable: master_sites on a port using fetch.type svn. Is master_sites really required? Should lint not warn if fetch.type is svn or cvs? Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies Subversion training, consulting and support http://www.orcaware.com/svn/ From afb at macports.org Mon Feb 18 10:32:00 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 18 Feb 2008 19:32:00 +0100 Subject: master_sites not required if fetch.type is svn In-Reply-To: <02A02FDF-A425-48C2-93FC-52D348F6708C@orcaware.com> References: <02A02FDF-A425-48C2-93FC-52D348F6708C@orcaware.com> Message-ID: <30113527-6489-4C60-82E9-D75BD443E906@macports.org> Blair Zajac wrote: > I'm getting this lint warning: > > Error: Missing required variable: master_sites > > on a port using fetch.type svn. Is master_sites really required? > Should lint not warn if fetch.type is svn or cvs? You are probably right, lint shouldn't warn if fetch.type is something other than "standard"... At least the var isn't used, even if "Required". --anders From ryandesign at macports.org Mon Feb 18 14:56:14 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 18 Feb 2008 16:56:14 -0600 Subject: master_sites not required if fetch.type is svn In-Reply-To: <30113527-6489-4C60-82E9-D75BD443E906@macports.org> References: <02A02FDF-A425-48C2-93FC-52D348F6708C@orcaware.com> <30113527-6489-4C60-82E9-D75BD443E906@macports.org> Message-ID: <14AD0893-27A3-4E3C-9C5C-FA16D2DCFB27@macports.org> On Feb 18, 2008, at 12:32, Anders F Bj?rklund wrote: > Blair Zajac wrote: > >> I'm getting this lint warning: >> >> Error: Missing required variable: master_sites >> >> on a port using fetch.type svn. Is master_sites really required? >> Should lint not warn if fetch.type is svn or cvs? > > You are probably right, lint shouldn't warn if > fetch.type is something other than "standard"... > > At least the var isn't used, even if "Required". Yeah, I think lint is wrong here. I filed a ticket: http://trac.macosforge.org/projects/macports/ticket/14377 From ryandesign at macports.org Mon Feb 18 15:39:57 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 18 Feb 2008 17:39:57 -0600 Subject: unison and protocol breakage In-Reply-To: <03FD876A-27A1-4287-8B09-44C780B8FBB7@macports.org> References: <20080217011826.GP619@prunille.vinc17.org> <8554AC16-8E45-445B-B466-4D49F15A7F09@kallisys.net> <20080218012835.GW619@prunille.vinc17.org> <03FD876A-27A1-4287-8B09-44C780B8FBB7@macports.org> Message-ID: <88A65EB3-C94E-498A-932E-2A269EF648F3@macports.org> On Feb 18, 2008, at 07:48, Kevin Ballard wrote: > On Feb 18, 2008, at 4:34 AM, Ryan Schmidt wrote: > >> On Feb 17, 2008, at 07:36, Kevin Ballard wrote: >> >>> No, the solution here is to not do anything. Anybody using 2.13 >>> needs >>> to upgrade if they want to work with 2.27. We are not in the >>> business >>> of providing old port versions, and we *should not* be. >> >> Kevin, I think we are in fact in the business of providing old port >> versions too. Where the newer version of the software is >> incompatible in some way with the older version of the software, >> it's reasonable to have two portfiles, if there is still demand for >> the older version. We already have this for several software >> packages. Consider php5 and php4; apache2, apache20 and apache; apr >> and apr0; mysql5, mysql4 and mysql3; postgresql83, postgresql82, >> postgresql81, postgresql80 and postgresql7; db46, db45, db44, db43, >> db42, db41 and db3. > > That's a bit different - those are specific versions as required by > other ports (at least, if they aren't then why the hell do we still > have Portfiles for them?). Unison is not required by other ports, and > if it were these other ports wouldn't require a specific version. > Therefore, we shouldn't be providing old ports because we don't have > to maintain them for dependencies. [snip] I wouldn't say it's only about dependencies. For example: php4 contains some functionality that was dropped or changed in php5, so some sites that work with php4 do not work with php5 without some changes. A developer of such a site might reasonably want to install php4 using MacPorts to continue developing his site. apache20 exists for the reason explained at length in the Portfile: to support the use of third-party binary modules compiled for Apache 2.0, which would not work in Apache 2.2 without recompilation. The several postgresql ports exist, as I understand it, because the database format is binary-incompatible between releases, requiring the user to perform a manual migration. It was thought that breaking a user's database just because they ran "sudo port upgrade outdated" was rude. So, in all these cases, we are concerned with the MacPorts user who wants to continue using the old version of the software, because the newer version works incompatibly. It doesn't matter if other ports depend on these older versions. > Note: It really is fairly trivial to install unison by hand once you > have OCaml installed. If you have a debian machine that doesn't > provide unison 2.27, just install it manually! Seriously! It's easier > than trying to get Unison 2.13 into MacPorts. I would still agree it's better to install the latest software on the other machine, rather than get the older software into MacPorts. From ryandesign at macports.org Mon Feb 18 15:41:52 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 18 Feb 2008 17:41:52 -0600 Subject: Proposal: reminder to the assignee when a ticket is unchanged more than 3 days In-Reply-To: References: Message-ID: <405768FA-8864-4FA0-96EC-6BA7F37517ED@macports.org> On Feb 18, 2008, at 06:51, js wrote: > From reporter's view point, sending reminders is boring job. > So I thought I would be better to automate it. > Actually, I frequently found tickets which seem no one working on. > (Maybe MacPorts project have not enough maintainers?) Bingo. We need more maintainers. > That means I have to write reminders again and again. > > Besides, I don't have permission to change Assigned to field of a > Trac ticket. > Maintainers probably don't see ticket not assigned to them. Correct. Adding the maintainer to the Cc line would also work in a pinch. > If I could assign maintainers to my tickets, I might help the > situation. I would love it if anyone could assign tickets. But we don't have Trac set up like that. From raimue at macports.org Mon Feb 18 16:04:37 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue, 19 Feb 2008 01:04:37 +0100 Subject: New HOWTO section in the wiki Message-ID: <47BA1D15.9050907@macports.org> Hi, I started a new HOWTO section in the wiki [1]. These HOWTOs should cover tutorials and tips how specific things can be done using MacPorts. This is meant to be an addition to the guide and should not contain topics already covered by the guide. It is a place editable by everyone to share tips and tricks. So far I just added two HOWTOs to demonstrate how they should look like. If you have a good idea what such a HOWTO could cover, feel free to add it to the list. And if you even want to help by writing a HOWTO/tutorial yourself in order to make using MacPorts easier, there is a template which you can use as a start. So far I added two HOWTOs, one explaining how to use ccache and another how parallel building can be enabled. Of course you are free to edit them e.g. to add further information. Also, there is a list what could also be written. Even if you don't have time to write a HOWTO yourself, please make your mind what else could be useful and add it to that list. Rainer [1] http://trac.macosforge.org/projects/macports/wiki/howto From ryandesign at macports.org Mon Feb 18 16:10:02 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 18 Feb 2008 18:10:02 -0600 Subject: 4500 ports! (was: [34234] trunk/dports/PortIndex) In-Reply-To: <20080218204942.0C49B12C3B10@beta.macosforge.org> References: <20080218204942.0C49B12C3B10@beta.macosforge.org> Message-ID: On Feb 18, 2008, at 14:49, dluke at macports.org wrote: > Revision: 34234 > http://trac.macosforge.org/projects/macports/changeset/34234 > Author: dluke at macports.org > Date: 2008-02-18 12:49:41 -0800 (Mon, 18 Feb 2008) > > Log Message: > ----------- > > Total number of ports parsed: 4500 > Ports successfully parsed: 4500 MILESTONE! :) From dluke at geeklair.net Mon Feb 18 16:41:35 2008 From: dluke at geeklair.net (Daniel J. Luke) Date: Mon, 18 Feb 2008 19:41:35 -0500 Subject: unison and protocol breakage In-Reply-To: <88A65EB3-C94E-498A-932E-2A269EF648F3@macports.org> References: <20080217011826.GP619@prunille.vinc17.org> <8554AC16-8E45-445B-B466-4D49F15A7F09@kallisys.net> <20080218012835.GW619@prunille.vinc17.org> <03FD876A-27A1-4287-8B09-44C780B8FBB7@macports.org> <88A65EB3-C94E-498A-932E-2A269EF648F3@macports.org> Message-ID: On Feb 18, 2008, at 6:39 PM, Ryan Schmidt wrote: > php4 contains some functionality that was dropped or changed in php5, > so some sites that work with php4 do not work with php5 without some > changes. A developer of such a site might reasonably want to install > php4 using MacPorts to continue developing his site. both php4 and php5 are currently actively supported release versions of php, as well. > The several postgresql ports exist, as I understand it, because the > database format is binary-incompatible between releases, requiring > the user to perform a manual migration. It was thought that breaking > a user's database just because they ran "sudo port upgrade outdated" > was rude. postgresql.org also lists 7.4.19, 8.0.15, 8.1.11, 8.2.6, and 8.3.0 under 'Latest Releases' (all are currently supported versions) >> Note: It really is fairly trivial to install unison by hand once you >> have OCaml installed. If you have a debian machine that doesn't >> provide unison 2.27, just install it manually! Seriously! It's easier >> than trying to get Unison 2.13 into MacPorts. > > I would still agree it's better to install the latest software on the > other machine, rather than get the older software into MacPorts. True, but I don't see why we care if someone wants to be responsible for maintaining a port for an older version for one reason or another (we can always remove it if/when it becomes unmaintained). -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080218/4bc9fc49/attachment.bin From ebgssth at gmail.com Tue Feb 19 04:56:14 2008 From: ebgssth at gmail.com (js) Date: Tue, 19 Feb 2008 21:56:14 +0900 Subject: Proposal: reminder to the assignee when a ticket is unchanged more than 3 days In-Reply-To: <405768FA-8864-4FA0-96EC-6BA7F37517ED@macports.org> References: <405768FA-8864-4FA0-96EC-6BA7F37517ED@macports.org> Message-ID: > > Besides, I don't have permission to change Assigned to field of a > > Trac ticket. > > Maintainers probably don't see ticket not assigned to them. > > Correct. Adding the maintainer to the Cc line would also work in a > pinch. Just a email is easy to miss, I guess. > > If I could assign maintainers to my tickets, I might help the > > situation. > > I would love it if anyone could assign tickets. But we don't have > Trac set up like that. Who is the administrator? Just give non-maintainers TICKET_CHGPROP permission so that we can assign ticket to maintainers. From wsiegrist at apple.com Tue Feb 19 07:25:18 2008 From: wsiegrist at apple.com (William Siegrist) Date: Tue, 19 Feb 2008 07:25:18 -0800 Subject: Proposal: reminder to the assignee when a ticket is unchanged more than 3 days In-Reply-To: References: <405768FA-8864-4FA0-96EC-6BA7F37517ED@macports.org> Message-ID: <9B514911-A2BD-4FEC-B129-696ED632D49B@apple.com> We've gone over the Trac permissions before. They are set the way they are on purpose. You should be able to find a ticket or two to comment on if you want to continue the debate. -Bill On Feb 19, 2008, at 4:56 AM, js wrote: >>> Besides, I don't have permission to change Assigned to field of a >>> Trac ticket. >>> Maintainers probably don't see ticket not assigned to them. >> >> Correct. Adding the maintainer to the Cc line would also work in a >> pinch. > > Just a email is easy to miss, I guess. > >>> If I could assign maintainers to my tickets, I might help the >>> situation. >> >> I would love it if anyone could assign tickets. But we don't have >> Trac set up like that. > > Who is the administrator? > Just give non-maintainers TICKET_CHGPROP permission > so that we can assign ticket to maintainers. > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev ---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist at 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/20080219/cc2f589e/attachment.bin From ebgssth at gmail.com Tue Feb 19 07:31:33 2008 From: ebgssth at gmail.com (js) Date: Wed, 20 Feb 2008 00:31:33 +0900 Subject: Proposal: reminder to the assignee when a ticket is unchanged more than 3 days In-Reply-To: <9B514911-A2BD-4FEC-B129-696ED632D49B@apple.com> References: <405768FA-8864-4FA0-96EC-6BA7F37517ED@macports.org> <9B514911-A2BD-4FEC-B129-696ED632D49B@apple.com> Message-ID: Hi William, searched keyword "Trac permission" but not found any. Could you give me some pointers? On Feb 20, 2008 12:25 AM, William Siegrist wrote: > We've gone over the Trac permissions before. They are set the way they > are on purpose. You should be able to find a ticket or two to comment > on if you want to continue the debate. > > -Bill > > > > > On Feb 19, 2008, at 4:56 AM, js wrote: > >>> Besides, I don't have permission to change Assigned to field of a > >>> Trac ticket. > >>> Maintainers probably don't see ticket not assigned to them. > >> > >> Correct. Adding the maintainer to the Cc line would also work in a > >> pinch. > > > > Just a email is easy to miss, I guess. > > > >>> If I could assign maintainers to my tickets, I might help the > >>> situation. > >> > >> I would love it if anyone could assign tickets. But we don't have > >> Trac set up like that. > > > > Who is the administrator? > > Just give non-maintainers TICKET_CHGPROP permission > > so that we can assign ticket to maintainers. > > _______________________________________________ > > macports-dev mailing list > > macports-dev at lists.macosforge.org > > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > > > > ---- > William Siegrist > Software Support Engineer > Mac OS Forge > http://macosforge.org/ > wsiegrist at apple.com > 408 862 7337 > > > > > > From derek at chocolate-fish.com Tue Feb 19 13:04:06 2008 From: derek at chocolate-fish.com (Derek Harland) Date: Wed, 20 Feb 2008 10:04:06 +1300 Subject: Can tickets 14259, 14260, 14261, 14316 be committed? In-Reply-To: References: Message-ID: <1ECB2517-AB31-4041-AECC-3E09126A920F@chocolate-fish.com> Hi I have a few tickets waiting for commit 14259 Upgrade of py-logilab-common 14260 New port: py-logilab-astng 14261 Upgrade of py-lint 14316 Upgrade of py-epydoc Would someone be able to commit them for me? des. From bwaters at nrao.edu Tue Feb 19 18:03:02 2008 From: bwaters at nrao.edu (Boyd Waters) Date: Tue, 19 Feb 2008 19:03:02 -0700 Subject: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't In-Reply-To: <6B342869-BC6E-48D4-960A-254D89BE16AC@macports.org> References: <047.9fe0e7798e644f83e5bea8fec8b4d764@macosforge.org> <056.59f733d9934ac6e311002f4555f790ca@macosforge.org> <47B9B1FF.7080105@macports.org> <6B342869-BC6E-48D4-960A-254D89BE16AC@macports.org> Message-ID: On Feb 18, 2008, at 9:53 AM, Markus Weissmann wrote: > For people who don't need e.g. tk-support, > building all those dependencies is unnecessary. Yes! And for those who are banging on a 64-bit Python, we can't touch anything that uses a Carbon API. Like Tk. Has anyone successfully built a 64-bit version of Python 2.5.1 on Macintosh? - boyd Boyd Waters National Radio Astronomy Observaotory New Mexico, USA, Earth From jmpp at macports.org Tue Feb 19 23:18:53 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Wed, 20 Feb 2008 02:48:53 -0430 Subject: [34249] trunk/dports/lang In-Reply-To: <20080219120805.79D7812E01CA@beta.macosforge.org> References: <20080219120805.79D7812E01CA@beta.macosforge.org> Message-ID: <982C1C1B-0AB6-48EE-A896-C51477C7408A@macports.org> Hey Anders! It turns out there's already a tcl-dox port in textproc/tcl-dox, and the clash is causing a conflict regening the ports.php db. Can you please try merging both into a single port? Regards,... -jmpp On Feb 19, 2008, at 7:38 AM, afb at macports.org wrote: > Revision > 34249 > Author > afb at macports.org > Date > 2008-02-19 04:08:02 -0800 (Tue, 19 Feb 2008) > Log Message > > add tcl-dox, as alternative to tcldoc > Added Paths > > trunk/dports/lang/tcl-dox/ > trunk/dports/lang/tcl-dox/Portfile > Diff > > Added: trunk/dports/lang/tcl-dox/Portfile (0 => 34249) > --- trunk/dports/lang/tcl-dox/Portfile (rev 0) > +++ trunk/dports/lang/tcl-dox/Portfile 2008-02-19 12:08:02 UTC (rev > 34249) > @@ -0,0 +1,26 @@ > +# $Id$ > + > +PortSystem 1.0 > + > +name tcl-dox > +version 0.7 > +categories lang > +maintainers afb at macports.org openmaintainer > +description Tcl filter for Doxygen > +long_description \ > + This is a filter that you can use with Doxygen for documenting TCL > source code. > +homepage http://therowes.net/~greg/software/ > +platforms darwin > +master_sites ${homepage}/tcl-doxygen-filter/ > +checksums md5 5806f566e51b69ff1cb8c92b86a7e8d5 \ > + sha1 e7aa17354d56a5147293eac30adc7a7c4c7d011d > + > +depends_run port:doxygen > +depends_build bin:flex:flex > + > +use_configure no > +build.dir ${worksrcpath}/src > + > +destroot { > + xinstall -m 755 ${worksrcpath}/src/tcl-dox ${destroot}$ > {prefix}/bin > +} > Property changes on: trunk/dports/lang/tcl-dox/Portfile > ___________________________________________________________________ > Name: svn:keywords > + Id > Name: svn:eol-style > + native > _______________________________________________ > macports-changes mailing list > macports-changes at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080220/6312a6b0/attachment-0001.html From afb at macports.org Wed Feb 20 00:03:56 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Wed, 20 Feb 2008 09:03:56 +0100 Subject: [34249] trunk/dports/lang In-Reply-To: <982C1C1B-0AB6-48EE-A896-C51477C7408A@macports.org> References: <20080219120805.79D7812E01CA@beta.macosforge.org> <982C1C1B-0AB6-48EE-A896-C51477C7408A@macports.org> Message-ID: Juan Manuel Palacios wrote: > It turns out there's already a tcl-dox port in textproc/tcl-dox, > and the clash is causing a conflict regening the ports.php db. Can > you please try merging both into a single port? Right you are, must have missed that port for some reason... :-| Fixed, r34270. --anders From ryandesign at macports.org Wed Feb 20 03:56:34 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 20 Feb 2008 05:56:34 -0600 Subject: ld: cycle in dylib re-exports with /usr/X11R6/lib/libGL.dylib Message-ID: <6BEAAE82-7943-4542-8AA5-8A5B51C69268@macports.org> The Apple Developer Technical Q&A on this problem http://developer.apple.com/qa/qa2007/qa1567.html says the fix is to add this to LDFLAGS: -dylib_file FILE:FILE where "FILE" is "/System/Library/Frameworks/OpenGL.framework/Versions/ A/Libraries/libGL.dylib" These ports do it this way: djvulibre, enblend, fox, fxscintilla, gst- plugins-bad, py25-gtkglext, xforms However we have some ports that instead add this to LDFLAGS: -Wl,-dylib_file,FILE:FILE These ports do it this way: aqbanking, geomview, glut, gtkglarea2, gvemod-cplxview, gvemod-crayola, gvemod-labeler, gvemod-ndview, gvemod-xforms-example, gvemodules-xforms, gwyddion, koffice, maniview, orrery, scribus What's the difference? Which one is better and why? If neither is better, why aren't we always doing it the Apple-recommended way? From afb at macports.org Wed Feb 20 04:04:59 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Wed, 20 Feb 2008 13:04:59 +0100 Subject: ld: cycle in dylib re-exports with /usr/X11R6/lib/libGL.dylib In-Reply-To: <6BEAAE82-7943-4542-8AA5-8A5B51C69268@macports.org> References: <6BEAAE82-7943-4542-8AA5-8A5B51C69268@macports.org> Message-ID: <3A531682-462D-474D-832D-89CD46E61DBF@macports.org> Ryan Schmidt wrote: > What's the difference? Which one is better and why? If neither is > better, why aren't we always doing it the Apple-recommended way? It's the same thing, just that sometimes it won't recognize "unknown" linker flags so you wrap them in the -Wl param... Same goes with for instance "-Wl,-framework,Carbon" and so on. Does it really matter if one says tomato and the other tomato ? --anders From ryandesign at macports.org Wed Feb 20 04:07:39 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 20 Feb 2008 06:07:39 -0600 Subject: ld: cycle in dylib re-exports with /usr/X11R6/lib/libGL.dylib In-Reply-To: <3A531682-462D-474D-832D-89CD46E61DBF@macports.org> References: <6BEAAE82-7943-4542-8AA5-8A5B51C69268@macports.org> <3A531682-462D-474D-832D-89CD46E61DBF@macports.org> Message-ID: <63AC6E8A-C3E4-4452-A186-D50FFB45E180@macports.org> On Feb 20, 2008, at 06:04, Anders F Bj?rklund wrote: > Ryan Schmidt wrote: > >> What's the difference? Which one is better and why? If neither is >> better, why aren't we always doing it the Apple-recommended way? > > It's the same thing, just that sometimes it won't recognize > "unknown" linker flags so you wrap them in the -Wl param... > > Same goes with for instance "-Wl,-framework,Carbon" and so on. > Does it really matter if one says tomato and the other tomato ? Nope, I just wanted to understand the problem, and I don't have Leopard so I can't test it myself, and the Apple article made no mention whatsoever of the -Wl variant. Thanks for the explanation. I'll submit feedback to Apple to ask them to add it to the article. From ebgssth at gmail.com Wed Feb 20 06:48:08 2008 From: ebgssth at gmail.com (js) Date: Wed, 20 Feb 2008 23:48:08 +0900 Subject: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't In-Reply-To: <6B342869-BC6E-48D4-960A-254D89BE16AC@macports.org> References: <047.9fe0e7798e644f83e5bea8fec8b4d764@macosforge.org> <056.59f733d9934ac6e311002f4555f790ca@macosforge.org> <47B9B1FF.7080105@macports.org> <6B342869-BC6E-48D4-960A-254D89BE16AC@macports.org> Message-ID: Hi Markus, > does not compute: "python25 drops but python25 doesn't" -- > contradiction detected. ;) Oops! That's typo. My question was why python2.4 and 2.5 is different. > If the question was why python25 does not build all auxiliary modules > [1] like _sqlite3 etc.: For people who don't need e.g. tk-support, > building all those dependencies is unnecessary. > We had this discussion of which modules would be cool to include by > default and which not to already. Conclusion was that either we rename > python25 to python25-core and make a "virtual" port python25 that > requires all modules+python25-core OR to make a python25-all (or > whatever) port that collects all "cool" modules by dependency. The > former sucks because we would need to change a lot of dependencies and > the latter never made it into the repository because nobody cared > enough. If someone is keen on getting the former to work: Please fix > all dependencies!!! (And please also make this consistent for 2.4 and > 3.0) Thanks for thorough explanation. That makes sense. The reason why I started this discussion is that I want to make python24 to be python25-like port. What if I created patches for this, Would you accept that changes? As for python25's design you brought up, I prefer the former, which apparently not your favorite :) The former reminds me of Debian/GNU Linux's "python" package. The python package is a dependency package which depends on "default python", python2.4 and python-minimal. Any chance making this changes? To be honest, I also want to change py- prefix ports to py24- but this plan is rejected recently... From mww at macports.org Wed Feb 20 07:18:08 2008 From: mww at macports.org (Markus Weissmann) Date: Wed, 20 Feb 2008 16:18:08 +0100 Subject: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't In-Reply-To: References: <047.9fe0e7798e644f83e5bea8fec8b4d764@macosforge.org> <056.59f733d9934ac6e311002f4555f790ca@macosforge.org> <47B9B1FF.7080105@macports.org> <6B342869-BC6E-48D4-960A-254D89BE16AC@macports.org> Message-ID: On 20 Feb 2008, at 15:48, js wrote: > Hi Markus, > >> does not compute: "python25 drops but python25 doesn't" -- >> contradiction detected. ;) > > Oops! That's typo. > My question was why python2.4 and 2.5 is different. > >> If the question was why python25 does not build all auxiliary modules >> [1] like _sqlite3 etc.: For people who don't need e.g. tk-support, >> building all those dependencies is unnecessary. >> We had this discussion of which modules would be cool to include by >> default and which not to already. Conclusion was that either we >> rename >> python25 to python25-core and make a "virtual" port python25 that >> requires all modules+python25-core OR to make a python25-all (or >> whatever) port that collects all "cool" modules by dependency. The >> former sucks because we would need to change a lot of dependencies >> and >> the latter never made it into the repository because nobody cared >> enough. If someone is keen on getting the former to work: Please fix >> all dependencies!!! (And please also make this consistent for 2.4 and >> 3.0) > > Thanks for thorough explanation. That makes sense. > The reason why I started this discussion is that > I want to make python24 to be python25-like port. > What if I created patches for this, > Would you accept that changes? > well, what else do you want to change? There already are py-bsddb, py- readline, .. which provide modules not build by default (by the python24 port). > As for python25's design you brought up, I prefer the former, > which apparently not your favorite :) > The former reminds me of Debian/GNU Linux's "python" package. > The python package is a dependency package which depends on > "default python", python2.4 and python-minimal. > Any chance making this changes? > If you _really_ don't bother which python you end up with (and it doesn't matter if that changes), then you can use the "python_select: port to do just that. It basically provides symlinks to the real executables which you can change by calling python_select(1). Attention: If your port makes note of the exact location of you python executable, this might create an implicit dependency (which will cause breakage if you uninstall the "wrong" python) > To be honest, I also want to change py- prefix ports to py24- > but this plan is rejected recently... Rejected? Most probably due to the amount of work on both the project and the users' side. I think this would be cool, but if someone tackles this: Do a single commit on _all_ renamed ports and ports that depend on those AND write a mail to macports-users@ AND put something on the FAQ how to handle potential breakage. Regards, -Markus -- Dipl. Inf. (FH) Markus W. Weissmann http://www.macports.org/ http://www.mweissmann.de/ From ebgssth at gmail.com Wed Feb 20 07:39:21 2008 From: ebgssth at gmail.com (js) Date: Thu, 21 Feb 2008 00:39:21 +0900 Subject: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't In-Reply-To: References: <047.9fe0e7798e644f83e5bea8fec8b4d764@macosforge.org> <056.59f733d9934ac6e311002f4555f790ca@macosforge.org> <47B9B1FF.7080105@macports.org> <6B342869-BC6E-48D4-960A-254D89BE16AC@macports.org> Message-ID: > > Thanks for thorough explanation. That makes sense. > > The reason why I started this discussion is that > > I want to make python24 to be python25-like port. > > What if I created patches for this, > > Would you accept that changes? > > > > well, what else do you want to change? There already are py-bsddb, py- > readline, .. which provide modules not build by default (by the > python24 port). I'd like to drop modules from python24 the same way python25 do currently. This would help writing Portfile for python2[45] easier. > If you _really_ don't bother which python you end up with (and it > doesn't matter if that changes), then you can use the "python_select: > port to do just that. > It basically provides symlinks to the real executables which you can > change by calling python_select(1). > Attention: If your port makes note of the exact location of you python > executable, this might create an implicit dependency (which will cause > breakage if you uninstall the "wrong" python) No, I don't want default python on MacPorts. Explicit python24 and python25 would be clearer. just wanted to say python-minimal + py25-* ports would be nice. > > To be honest, I also want to change py- prefix ports to py24- > > but this plan is rejected recently... > > Rejected? Most probably due to the amount of work on both the project > and the users' side. > I think this would be cool, but if someone tackles this: Do a single > commit on _all_ renamed ports and ports that depend on those AND write > a mail to macports-users@ AND put something on the FAQ how to handle > potential breakage. If I prepared patches for this, would you bother to review/accept them? From randall.h.wood at alexandriasoftware.com Thu Feb 21 02:55:32 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Thu, 21 Feb 2008 05:55:32 -0500 Subject: 72 hours are not enough for maintainers? In-Reply-To: References: <47B60EFD.30406@orcaware.com> Message-ID: I would prefer a week, as I often may not get a chance to look at anything in MacPorts except on weekends. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080221/1852a471/attachment.html From rsync at reifferscheid.org Thu Feb 21 02:57:56 2008 From: rsync at reifferscheid.org (Thomas Reifferscheid) Date: Thu, 21 Feb 2008 11:57:56 +0100 Subject: 72 hours are not enough for maintainers? In-Reply-To: References: <47B60EFD.30406@orcaware.com> Message-ID: <47BD5934.6080007@reifferscheid.org> Me too. Sometimes I try to have some time with my family on weekends, so maybe two weeks will be better. If "js" starts using a realname when writing emails, I'd probably offer him maintainer rights, so he can help us fixing tickets. Kind regards Thomas Randall Wood wrote: > I would prefer a week, as I often may not get a chance to look at > anything in MacPorts except on weekends. From jkh at apple.com Thu Feb 21 08:52:34 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Thu, 21 Feb 2008 08:52:34 -0800 Subject: 72 hours are not enough for maintainers? In-Reply-To: <47BD5934.6080007@reifferscheid.org> References: <47B60EFD.30406@orcaware.com> <47BD5934.6080007@reifferscheid.org> Message-ID: <1328BCFB-CDFD-47B1-830A-66374AECD3F1@apple.com> I think this really begins to stretch the notion of "maintainer". He wants a week, you want two weeks, some other maintainers will probably say they want a month, before long you have a lot of ports being held hostage behind long-lived locks for no reason other than the fact that people want the ability to claim sole maintainership of ports AND take long vacations. I'm not saying that volunteers should not be allowed to take a few weeks off when they want to - they're volunteers and should be able to take any amount of time off - I'm saying that taking time off and having hard locks in the ports collection are not concepts that work well in combination. Any successful project either has a dedicated team of volunteers checking their queues at least 2 or 3 times a week with hard locks, or it has more relaxed volunteers and soft locks that time out relatively quickly. We have subversion, changes can always be reviewed and backed out if necessary, and it's far better to err on the side of not frustrating people who want to contribute. This lesson has been learned repeatedly in other open source projects. I think 72 hours is a very reasonable time out period. If you're that attached to your ports, chances are very good that you'll be checking your trac queue more often than this anyway, and if you're not that attached to them, then why be concerned if someone else makes changes? - Jordan On Feb 21, 2008, at 2:57 AM, Thomas Reifferscheid wrote: > Me too. Sometimes I try to have some time with my family on > weekends, so > maybe > two weeks will be better. > > If "js" starts using a realname when writing emails, I'd probably > offer > him maintainer rights, > so he can help us fixing tickets. > > Kind regards > Thomas > > Randall Wood wrote: >> I would prefer a week, as I often may not get a chance to look at >> anything in MacPorts except on weekends. > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From opendarwin.org at darkart.com Thu Feb 21 09:31:44 2008 From: opendarwin.org at darkart.com (Eric Hall) Date: Thu, 21 Feb 2008 17:31:44 +0000 Subject: 72 hours are not enough for maintainers? In-Reply-To: <1328BCFB-CDFD-47B1-830A-66374AECD3F1@apple.com> References: <47B60EFD.30406@orcaware.com> <47BD5934.6080007@reifferscheid.org> <1328BCFB-CDFD-47B1-830A-66374AECD3F1@apple.com> Message-ID: <20080221173144.GM94215@darkart.com> On Thu, Feb 21, 2008 at 08:52:34AM -0800, Jordan K. Hubbard wrote: > I think this really begins to stretch the notion of "maintainer". He > wants a week, you want two weeks, some other maintainers will probably > say they want a month, before long you have a lot of ports being held > hostage behind long-lived locks for no reason other than the fact that > people want the ability to claim sole maintainership of ports AND take > long vacations. > > I'm not saying that volunteers should not be allowed to take a few > weeks off when they want to - they're volunteers and should be able to > take any amount of time off - I'm saying that taking time off and > having hard locks in the ports collection are not concepts that work > well in combination. Any successful project either has a dedicated > team of volunteers checking their queues at least 2 or 3 times a week > with hard locks, or it has more relaxed volunteers and soft locks that > time out relatively quickly. We have subversion, changes can always > be reviewed and backed out if necessary, and it's far better to err on > the side of not frustrating people who want to contribute. This > lesson has been learned repeatedly in other open source projects. > > I think 72 hours is a very reasonable time out period. If you're that > attached to your ports, chances are very good that you'll be checking > your trac queue more often than this anyway, and if you're not that > attached to them, then why be concerned if someone else makes changes? > I agree - 72 hours is a decent window of time. I just used this for a few updates I wanted in, and for one of the changes I was able to converse with the maintainer and got a "go ahead, I'm way too busy right now" as well. I'd like to see an improvement in maintainer notification, some way for trac to grok the maintainers of a port a ticket is filed against and send them an email without having a human properly assign the ticket or fill in the CC: field. I have no idea if there are even hooks in trac to make that possible.... -eric From raimue at macports.org Thu Feb 21 09:38:02 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 21 Feb 2008 18:38:02 +0100 Subject: 72 hours are not enough for maintainers? In-Reply-To: <1328BCFB-CDFD-47B1-830A-66374AECD3F1@apple.com> References: <47B60EFD.30406@orcaware.com> <47BD5934.6080007@reifferscheid.org> <1328BCFB-CDFD-47B1-830A-66374AECD3F1@apple.com> Message-ID: <47BDB6FA.7050300@macports.org> Jordan K. Hubbard wrote: > I think 72 hours is a very reasonable time out period. If you're that > attached to your ports, chances are very good that you'll be checking > your trac queue more often than this anyway, and if you're not that > attached to them, then why be concerned if someone else makes changes? I think 72 hours is good. And if you go on vacation and can't maintain your ports for some time, there is always the possibility to announce that on macports-dev at . So either someone else can take care of the regarding tickets/ports or to get some extra time on tickets in order to fix them when he/she gets back. Rainer From raimue at macports.org Thu Feb 21 11:03:42 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 21 Feb 2008 20:03:42 +0100 Subject: "sudo: port: command not found" on OS X Tiger In-Reply-To: <759848.89234.qm@web65409.mail.ac4.yahoo.com> References: <759848.89234.qm@web65409.mail.ac4.yahoo.com> Message-ID: <47BDCB0E.2020408@macports.org> Please, always include the mailing list in your replies. Use `Reply All' instead of `Reply'. Brent Austin wrote: > I have: > /bin:/sbin:/usr/bin:/usr/sbin:/opt/local/bin > I'm not seeing X11R6 in there even though I know it' s installed. It may not be in there on Tiger by default. I am not sure. Rainer From ryandesign at macports.org Thu Feb 21 21:07:04 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 21 Feb 2008 23:07:04 -0600 Subject: "sudo: port: command not found" on OS X Tiger In-Reply-To: <47BDCB0E.2020408@macports.org> References: <759848.89234.qm@web65409.mail.ac4.yahoo.com> <47BDCB0E.2020408@macports.org> Message-ID: On Feb 21, 2008, at 13:03, Rainer M?ller wrote: > Brent Austin wrote: > >> I have: >> /bin:/sbin:/usr/bin:/usr/sbin:/opt/local/bin >> I'm not seeing X11R6 in there even though I know it' s installed. > > It may not be in there on Tiger by default. I am not sure. I'm not sure what this thread was about, but I can confirm that /usr/ X11R6/bin is not in the PATH by default on Tiger. From ryandesign at macports.org Thu Feb 21 21:12:12 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 21 Feb 2008 23:12:12 -0600 Subject: 72 hours are not enough for maintainers? In-Reply-To: <20080221173144.GM94215@darkart.com> References: <47B60EFD.30406@orcaware.com> <47BD5934.6080007@reifferscheid.org> <1328BCFB-CDFD-47B1-830A-66374AECD3F1@apple.com> <20080221173144.GM94215@darkart.com> Message-ID: On Feb 21, 2008, at 11:31, Eric Hall wrote: > I'd like to see an improvement in maintainer notification, > some way for trac to grok the maintainers of a port a ticket is filed > against and send them an email without having a human properly assign > the ticket or fill in the CC: field. I have no idea if there are even > hooks in trac to make that possible.... I suggested that before too, but then jmpp pointed out that we don't capture the information "what port is this ticket for?" anywhere in the ticket. We don't have a field for that. Many people put the affected port name somewhere in the ticket title, but many don't, and those that do don't always put it in a consistent place. I don't know if we can reliably just try to find any portname in the ticket title. Also, many reporters report problems against the port they're trying to install, rather than against the dependency which actually failed. From ryandesign at macports.org Thu Feb 21 22:52:54 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 22 Feb 2008 00:52:54 -0600 Subject: [34326] trunk/dports In-Reply-To: <20080221163738.AF399136E7A4@beta.macosforge.org> References: <20080221163738.AF399136E7A4@beta.macosforge.org> Message-ID: <03B61128-67F4-411B-ADDD-6C2201D4E3AA@macports.org> On Feb 21, 2008, at 10:37, jmr at macports.org wrote: > Revision: 34326 > http://trac.macosforge.org/projects/macports/changeset/34326 > Author: jmr at macports.org > Date: 2008-02-21 08:37:37 -0800 (Thu, 21 Feb 2008) > > Log Message: > ----------- > pgp: correct issues detected by port lint > > Modified Paths: > -------------- > trunk/dports/security/pgp/Portfile > > Added Paths: > ----------- > trunk/dports/security/pgp/ > trunk/dports/security/pgp/files/patch-pgpFullLicense.c.diff > > Removed Paths: > ------------- > trunk/dports/mail/pgp5/ > trunk/dports/security/pgp/files/pgpFullLicense.c-patch > > Copied: trunk/dports/security/pgp (from rev 34310, trunk/dports/ > mail/pgp5) Thanks for doing all these commits lately! Something I wanted to point out though: You should have used "svn mv" to rename pgpFullLicense.c-patch to patch-pgpFullLicense.c.diff. It looks like you just added it anew. Look the revision history now in the repository: http://trac.macosforge.org/projects/macports/log/trunk/dports/ security/pgp/files/patch-pgpFullLicense.c.diff?rev=34326 See, it looks like the file just came into existence in r34326. But it didn't. It had a previous history that should have been preserved: http://trac.macosforge.org/projects/macports/log/trunk/dports/mail/ pgp5/files/pgpFullLicense.c-patch?rev=21488 From randall.h.wood at alexandriasoftware.com Fri Feb 22 01:32:19 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Fri, 22 Feb 2008 04:32:19 -0500 Subject: Proposal for daily list of new tickets Message-ID: Openoffice.org publishes a daily email of new tickets to, not only its developers mailing lists, but to its blogging systems as well. Is there any reason we should not (or can not) have trac provide a daily email into the macports-dev list of new tickets? I have subscribed to the tickets list (and quickly unsubscribed once it got working) but it was way too much email to handle, but maybe a daily digest listing new tickets would help? -- Randall Wood randall.h.wood at alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From ryandesign at macports.org Fri Feb 22 02:30:43 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 22 Feb 2008 04:30:43 -0600 Subject: Proposal for daily list of new tickets In-Reply-To: References: Message-ID: <09C7B342-8A7F-4CE5-81D7-71E10578EB0D@macports.org> On Feb 22, 2008, at 03:32, Randall Wood wrote: > Openoffice.org publishes a daily email of new tickets to, not only its > developers mailing lists, but to its blogging systems as well. Is > there any reason we should not (or can not) have trac provide a daily > email into the macports-dev list of new tickets? > > I have subscribed to the tickets list (and quickly unsubscribed once > it got working) but it was way too much email to handle, but maybe a > daily digest listing new tickets would help? I wouldn't want such a report mailed here to macports-dev; I have enough to read here already. I don't subscribe to macports-tickets either. I look at this URL when I have time, to see what new unassigned tickets there are: https://trac.macports.org/projects/macports/query? status=new&status=assigned&status=reopened&owner=macports-tickets% 40lists.macosforge.org&order=id&desc=1 Anyone else can of course do that too. From lutz.horn at fastmail.fm Fri Feb 22 02:32:06 2008 From: lutz.horn at fastmail.fm (Lutz Horn) Date: Fri, 22 Feb 2008 11:32:06 +0100 Subject: Proposal for daily list of new tickets In-Reply-To: References: Message-ID: <1203676326.11615.1238312035@webmail.messagingengine.com> Hi Randall, On Fri, 22 Feb 2008 04:32:19 -0500, "Randall Wood" said: > Openoffice.org publishes a daily email of new tickets to, not only its > developers mailing lists, but to its blogging systems as well. You can subscribe to a configurable RSS feed of the Trac timeline at http://trac.macports.org/projects/macports/timeline/projects/macports/timeline?ticket=on&changeset=on&max=50&daysback=90&format=rss I find this very useful. Regards Lutz From jmr at macports.org Fri Feb 22 02:33:29 2008 From: jmr at macports.org (Joshua Root) Date: Fri, 22 Feb 2008 21:33:29 +1100 Subject: [34326] trunk/dports In-Reply-To: <03B61128-67F4-411B-ADDD-6C2201D4E3AA@macports.org> References: <20080221163738.AF399136E7A4@beta.macosforge.org> <03B61128-67F4-411B-ADDD-6C2201D4E3AA@macports.org> Message-ID: <47BEA4F9.3080600@macports.org> Ryan Schmidt wrote: > You should have used "svn mv" to rename pgpFullLicense.c-patch to > patch-pgpFullLicense.c.diff. It looks like you just added it anew. Look > the revision history now in the repository: > > http://trac.macosforge.org/projects/macports/log/trunk/dports/security/pgp/files/patch-pgpFullLicense.c.diff?rev=34326 > > > See, it looks like the file just came into existence in r34326. But it > didn't. It had a previous history that should have been preserved: > > http://trac.macosforge.org/projects/macports/log/trunk/dports/mail/pgp5/files/pgpFullLicense.c-patch?rev=21488 Sorry about that. The command I used was 'svn mv mail/pgp5 security/pgp', which seems to have worked as expected for the portfile but not the patch. - Josh From jmr at macports.org Fri Feb 22 02:45:21 2008 From: jmr at macports.org (Joshua Root) Date: Fri, 22 Feb 2008 21:45:21 +1100 Subject: [34326] trunk/dports In-Reply-To: <47BEA4F9.3080600@macports.org> References: <20080221163738.AF399136E7A4@beta.macosforge.org> <03B61128-67F4-411B-ADDD-6C2201D4E3AA@macports.org> <47BEA4F9.3080600@macports.org> Message-ID: <47BEA7C1.1050303@macports.org> Joshua Root wrote: > Ryan Schmidt wrote: >> You should have used "svn mv" to rename pgpFullLicense.c-patch to >> patch-pgpFullLicense.c.diff. It looks like you just added it anew. >> Look the revision history now in the repository: >> >> http://trac.macosforge.org/projects/macports/log/trunk/dports/security/pgp/files/patch-pgpFullLicense.c.diff?rev=34326 >> >> >> See, it looks like the file just came into existence in r34326. But it >> didn't. It had a previous history that should have been preserved: >> >> http://trac.macosforge.org/projects/macports/log/trunk/dports/mail/pgp5/files/pgpFullLicense.c-patch?rev=21488 > > > Sorry about that. The command I used was 'svn mv mail/pgp5 > security/pgp', which seems to have worked as expected for the portfile > but not the patch. And I just realised that the above explanation is incomplete... I did 'svn mv mail/pgp5 security/pgp' followed by 'svn mv security/pgp/files/pgpFullLicense.c-patch security/pgp/files/patch-pgpFullLicense.c.diff'. The latter is what doesn't seem to have done the expected thing. - Josh From ryandesign at macports.org Fri Feb 22 02:57:29 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 22 Feb 2008 04:57:29 -0600 Subject: [34326] trunk/dports In-Reply-To: <47BEA4F9.3080600@macports.org> References: <20080221163738.AF399136E7A4@beta.macosforge.org> <03B61128-67F4-411B-ADDD-6C2201D4E3AA@macports.org> <47BEA4F9.3080600@macports.org> Message-ID: <1F2B2E14-6720-4A36-8F89-07B113525B99@macports.org> On Feb 22, 2008, at 04:33, Joshua Root wrote: > Ryan Schmidt wrote: > >> You should have used "svn mv" to rename pgpFullLicense.c-patch to >> patch-pgpFullLicense.c.diff. It looks like you just added it anew. >> Look >> the revision history now in the repository: >> >> http://trac.macosforge.org/projects/macports/log/trunk/dports/ >> security/pgp/files/patch-pgpFullLicense.c.diff?rev=34326 >> >> >> See, it looks like the file just came into existence in r34326. >> But it >> didn't. It had a previous history that should have been preserved: >> >> http://trac.macosforge.org/projects/macports/log/trunk/dports/mail/ >> pgp5/files/pgpFullLicense.c-patch?rev=21488 > > Sorry about that. The command I used was 'svn mv mail/pgp5 > pgp', which seems to have worked as expected for the portfile > but not the patch. Presumably you meant svn mv mail/pgp5 security/pgp That wouldn't however have renamed the patchfile, which you also did somehow, to fix the naming error reported by lint. The problem is that it's tricky in Subversion to rename both a directory and a file in it in a single step. You can't just do two "svn mv" operations like this: svn mv mail/pgp5 security/pgp svn mv security/pgp/files/{pgpFullLicense.c-patch,patch- pgpFullLicense.c.diff} because Subversion complains: svn: Cannot copy or move 'security/pgp/files/pgpFullLicense.c-patch': it's not in the repository yet; try committing first It can be done, but you would need to recreate the directory structure yourself and then move the individual files only once each, like this: svn mkdir security/pgp svn mv mail/pgp5/Portfile pgp svn mkdir security/pgp/files svn mv mail/pgp5/files/pgpFullLicense.c-patch security/pgp/files/ patch-pgpFullLicense.c.diff svn rm mail/pgp5 svn ci mail/pgp5 security/pgp I reconnected the history in r34361, like this: cd security/pgp/files svn rm patch-pgpFullLicense.c.diff svn cp -r 34325 http://svn.macosforge.org/repository/macports/trunk/ dports/mail/pgp5/files/pgpFullLicense.c-patch patch- pgpFullLicense.c.diff From jmr at macports.org Fri Feb 22 03:22:32 2008 From: jmr at macports.org (Joshua Root) Date: Fri, 22 Feb 2008 22:22:32 +1100 Subject: [34326] trunk/dports In-Reply-To: <1F2B2E14-6720-4A36-8F89-07B113525B99@macports.org> References: <20080221163738.AF399136E7A4@beta.macosforge.org> <03B61128-67F4-411B-ADDD-6C2201D4E3AA@macports.org> <47BEA4F9.3080600@macports.org> <1F2B2E14-6720-4A36-8F89-07B113525B99@macports.org> Message-ID: <47BEB078.5090207@macports.org> Ryan Schmidt wrote: > > On Feb 22, 2008, at 04:33, Joshua Root wrote: > >> Ryan Schmidt wrote: >> >>> You should have used "svn mv" to rename pgpFullLicense.c-patch to >>> patch-pgpFullLicense.c.diff. It looks like you just added it anew. Look >>> the revision history now in the repository: >>> >>> http://trac.macosforge.org/projects/macports/log/trunk/dports/security/pgp/files/patch-pgpFullLicense.c.diff?rev=34326 >>> >>> >>> >>> See, it looks like the file just came into existence in r34326. But it >>> didn't. It had a previous history that should have been preserved: >>> >>> http://trac.macosforge.org/projects/macports/log/trunk/dports/mail/pgp5/files/pgpFullLicense.c-patch?rev=21488 >>> >> >> Sorry about that. The command I used was 'svn mv mail/pgp5 >> pgp', which seems to have worked as expected for the portfile >> but not the patch. > > Presumably you meant > > svn mv mail/pgp5 security/pgp Weird, I just checked and that's what the message said when I sent it. It must have been mangled somehow on its way to you. > The problem is that it's tricky in Subversion to rename both a directory > and a file in it in a single step. You can't just do two "svn mv" > operations like this: OK. I remember now that's what I tried to do. Probably easiest just to do it with 2 commits in future. > I reconnected the history in r34361, like this: > > cd security/pgp/files > svn rm patch-pgpFullLicense.c.diff > svn cp -r 34325 > http://svn.macosforge.org/repository/macports/trunk/dports/mail/pgp5/files/pgpFullLicense.c-patch > patch-pgpFullLicense.c.diff Neat trick. :-) Thanks for cleaning up after me. Cheers, Josh From afb at macports.org Fri Feb 22 03:25:34 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Fri, 22 Feb 2008 12:25:34 +0100 Subject: universal flags and configuration In-Reply-To: <7521F750-CE56-4899-BDB6-C96223B14D51@macports.org> References: <7521F750-CE56-4899-BDB6-C96223B14D51@macports.org> Message-ID: Previously, I wrote: > - universal_target > # for setting macosx_deployment_target and configure target > Default: 10.4 > > - universal_sysroot > # the SDK "sysroot" to use, normally for the -isysroot flag > Default: /Developer/SDKs/MacOSX10.4u.sdk > > - universal_archs > # machine architectures to use, can be more than just one > Default: ppc i386 > The additions means that it will now cross-compile when necessary, > and that +universal target is meant to generate similar binaries*. ... > * this default is a change from MacPorts 1.6.0, that used 10.5 SDK > on Leopard and 10.4u SDK on Tiger (but is the same as in 1.5/1.4) I changed the above defaults back to the same as on MacPorts 1.6.0, except that it is now configured at compiletime (in macports.conf). So it will now again use /Developer/SDKs/MacOSX10.5.sdk on Leopard, and /Developer/SDKs/MacOSX10.4u.sdk on Tiger and avoid cross-compile. This implicitly also fixes the issues were the wrong MDT was being passed to GCC, even if it now passes an extra -mmacosx-version-min As before, cross-compiling is not going to be supported this way since the variants (like +darwin_8 and +i386) will all be wrong. Merge support still needs to be added for +universal to work OK, but I'm not going to continue that Summer-of-Code 2007 project... However, changing the Xcode group to support the above settings should be pretty straightforward so that will go in soonishly. --anders From ebgssth at gmail.com Fri Feb 22 05:18:28 2008 From: ebgssth at gmail.com (js) Date: Fri, 22 Feb 2008 22:18:28 +0900 Subject: 72 hours are not enough for maintainers? In-Reply-To: References: <47B60EFD.30406@orcaware.com> <47BD5934.6080007@reifferscheid.org> <1328BCFB-CDFD-47B1-830A-66374AECD3F1@apple.com> <20080221173144.GM94215@darkart.com> Message-ID: I suggest giving non-maintainers the permission to change "Assigned to" field. Once tickets are properly assigned, all you have to do is to look at "My tickets". In addition to that, How abount sending reminder to macports-dev when there're tickets unchanged more than a few weeks? Trac's backend is RDBMS so checking ticket state should be easy. On 2/22/08, Ryan Schmidt wrote: > On Feb 21, 2008, at 11:31, Eric Hall wrote: > > > I'd like to see an improvement in maintainer notification, > > some way for trac to grok the maintainers of a port a ticket is filed > > against and send them an email without having a human properly assign > > the ticket or fill in the CC: field. I have no idea if there are even > > hooks in trac to make that possible.... > > > I suggested that before too, but then jmpp pointed out that we don't > capture the information "what port is this ticket for?" anywhere in > the ticket. We don't have a field for that. Many people put the > affected port name somewhere in the ticket title, but many don't, and > those that do don't always put it in a consistent place. I don't know > if we can reliably just try to find any portname in the ticket title. > Also, many reporters report problems against the port they're trying > to install, rather than against the dependency which actually failed. > > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > From ryandesign at macports.org Fri Feb 22 05:22:02 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 22 Feb 2008 07:22:02 -0600 Subject: 72 hours are not enough for maintainers? In-Reply-To: References: <47B60EFD.30406@orcaware.com> <47BD5934.6080007@reifferscheid.org> <1328BCFB-CDFD-47B1-830A-66374AECD3F1@apple.com> <20080221173144.GM94215@darkart.com> Message-ID: On Feb 22, 2008, at 07:18, js wrote: > On 2/22/08, Ryan Schmidt wrote: > >> On Feb 21, 2008, at 11:31, Eric Hall wrote: >> >>> I'd like to see an improvement in maintainer notification, >>> some way for trac to grok the maintainers of a port a ticket is >>> filed >>> against and send them an email without having a human properly >>> assign >>> the ticket or fill in the CC: field. I have no idea if there are >>> even >>> hooks in trac to make that possible.... >> >> I suggested that before too, but then jmpp pointed out that we don't >> capture the information "what port is this ticket for?" anywhere in >> the ticket. We don't have a field for that. Many people put the >> affected port name somewhere in the ticket title, but many don't, >> and >> those that do don't always put it in a consistent place. I don't >> know >> if we can reliably just try to find any portname in the ticket >> title. >> Also, many reporters report problems against the port they're trying >> to install, rather than against the dependency which actually >> failed. > > I suggest giving non-maintainers the permission to change "Assigned > to" field. It seems to me like that would be a good idea too. But I'm not sure what all the implications of that would be. > Once tickets are properly assigned, all you have to do is to look at > "My tickets". Assuming reporters assign tickets correctly, sure. > In addition to that, How abount sending reminder to macports-dev > when there're tickets unchanged more than a few weeks? > Trac's backend is RDBMS so checking ticket state should be easy. I know I have old tickets. Some need planning, some are waiting for upstream fixes, some are not very important but are still open because they're still unresolved. I don't need lots of emails nagging me about these. I have enough of an email problem as it is. Also, macports-dev is not a place to send automated emails; it's a place for discussing the development of MacPorts. For automated mails we have other lists, like macports-changes and macports-tickets. From ebgssth at gmail.com Fri Feb 22 05:58:08 2008 From: ebgssth at gmail.com (js) Date: Fri, 22 Feb 2008 22:58:08 +0900 Subject: 72 hours are not enough for maintainers? In-Reply-To: References: <47B60EFD.30406@orcaware.com> <47BD5934.6080007@reifferscheid.org> <1328BCFB-CDFD-47B1-830A-66374AECD3F1@apple.com> <20080221173144.GM94215@darkart.com> Message-ID: > > I suggest giving non-maintainers the permission to change "Assigned > > to" field. > > It seems to me like that would be a good idea too. But I'm not sure > what all the implications of that would be. According to Trac doc[1], if I had TICKET_CHGPROP, I could modify ticket properties except description field, cc field add/remove. Who cares if I wrongly change priority, components or version etc. [1]http://trac.edgewall.org/wiki/TracPermissions > > Once tickets are properly assigned, all you have to do is to look at > > "My tickets". > > Assuming reporters assign tickets correctly, sure. That might encourage reporters to open ticket carefully, I hope. > > In addition to that, How abount sending reminder to macports-dev > > when there're tickets unchanged more than a few weeks? > > Trac's backend is RDBMS so checking ticket state should be easy. > > I know I have old tickets. Some need planning, some are waiting for > upstream fixes, some are not very important but are still open > because they're still unresolved. I don't need lots of emails nagging > me about these. I have enough of an email problem as it is. Also, > macports-dev is not a place to send automated emails; it's a place > for discussing the development of MacPorts. For automated mails we > have other lists, like macports-changes and macports-tickets. Just add a update on those tickets. Reporters would be happy to see their ticket updated. And you are right. macports-tickets would be better. From ryandesign at macports.org Fri Feb 22 07:03:30 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 22 Feb 2008 09:03:30 -0600 Subject: [34313] trunk/base/src In-Reply-To: <20080221122254.4FB18136079A@beta.macosforge.org> References: <20080221122254.4FB18136079A@beta.macosforge.org> Message-ID: <0312FF9E-1A56-4A3E-B71A-C3F58074ADAF@macports.org> On Feb 21, 2008, at 06:22, afb at macports.org wrote: > Revision: 34313 > http://trac.macosforge.org/projects/macports/changeset/34313 > Author: afb at macports.org > Date: 2008-02-21 04:22:53 -0800 (Thu, 21 Feb 2008) > > Log Message: > ----------- > move back to using 10.5 SDK on Leopard to avoid cross-compiling Why was this changed again? From ryandesign at macports.org Fri Feb 22 07:15:14 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 22 Feb 2008 09:15:14 -0600 Subject: universal flags and configuration In-Reply-To: References: <7521F750-CE56-4899-BDB6-C96223B14D51@macports.org> Message-ID: <94B700CC-7CE6-4B39-9E51-50FEDFCF8BBA@macports.org> On Feb 22, 2008, at 05:25, Anders F Bj?rklund wrote: > Previously, I wrote: > >> - universal_target >> # for setting macosx_deployment_target and configure target >> Default: 10.4 >> >> - universal_sysroot >> # the SDK "sysroot" to use, normally for the -isysroot flag >> Default: /Developer/SDKs/MacOSX10.4u.sdk >> >> - universal_archs >> # machine architectures to use, can be more than just one >> Default: ppc i386 > >> The additions means that it will now cross-compile when necessary, >> and that +universal target is meant to generate similar binaries*. > ... >> * this default is a change from MacPorts 1.6.0, that used 10.5 SDK >> on Leopard and 10.4u SDK on Tiger (but is the same as in 1.5/1.4) > > I changed the above defaults back to the same as on MacPorts 1.6.0, > except that it is now configured at compiletime (in macports.conf). > > So it will now again use /Developer/SDKs/MacOSX10.5.sdk on Leopard, > and /Developer/SDKs/MacOSX10.4u.sdk on Tiger and avoid cross-compile. > > > This implicitly also fixes the issues were the wrong MDT was being > passed to GCC, even if it now passes an extra -mmacosx-version-min > > As before, cross-compiling is not going to be supported this way > since the variants (like +darwin_8 and +i386) will all be wrong. I don't really understand why this was changed yet again. I renew my objection, which is that a port built with +universal on Leopard won't work on Tiger (but the same port built with +universal on Tiger will work on Leopard). Doesn't this defeat part of the purpose of universal? > Merge support still needs to be added for +universal to work OK, > but I'm not going to continue that Summer-of-Code 2007 project... mww has already rewritten the summer-of-code merge.rb script into the merge tcl function which is already in trunk. > However, changing the Xcode group to support the above settings > should be pretty straightforward so that will go in soonishly. From afb at macports.org Fri Feb 22 07:46:46 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Fri, 22 Feb 2008 16:46:46 +0100 Subject: universal flags and configuration In-Reply-To: <94B700CC-7CE6-4B39-9E51-50FEDFCF8BBA@macports.org> References: <7521F750-CE56-4899-BDB6-C96223B14D51@macports.org> <94B700CC-7CE6-4B39-9E51-50FEDFCF8BBA@macports.org> Message-ID: Ryan Schmidt wrote: >> I changed the above defaults back to the same as on MacPorts 1.6.0, >> except that it is now configured at compiletime (in macports.conf). >> >> So it will now again use /Developer/SDKs/MacOSX10.5.sdk on Leopard, >> and /Developer/SDKs/MacOSX10.4u.sdk on Tiger and avoid cross-compile. >> >> >> This implicitly also fixes the issues were the wrong MDT was being >> passed to GCC, even if it now passes an extra -mmacosx-version-min >> >> As before, cross-compiling is not going to be supported this way >> since the variants (like +darwin_8 and +i386) will all be wrong. > > I don't really understand why this was changed yet again. I renew > my objection, which is that a port built with +universal on Leopard > won't work on Tiger (but the same port built with +universal on > Tiger will work on Leopard). Doesn't this defeat part of the > purpose of universal? It all depends on what your definition of "universal" is... Is it something that will "work universally", or is it a more narrow definition of "both PowerPC and Intel" arch ? I just reverted it back to the second of those definitions. A non-universal port built on Leopard won't work on Tiger either, so this makes them more similar to regular ports. Anyway, the definitions of MDT/SDK/archs are now configs instead of hardcoded so user can change them if they want ? --anders From ryandesign at macports.org Fri Feb 22 10:32:57 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 22 Feb 2008 12:32:57 -0600 Subject: [34368] trunk/dports/games/tuxmath/Portfile In-Reply-To: <20080222165032.4DC2A13B56B4@beta.macosforge.org> References: <20080222165032.4DC2A13B56B4@beta.macosforge.org> Message-ID: <76CD7BB8-0C2C-42D4-A449-99A013270AEC@macports.org> You need to bump the port revision too so everyone gets that change. On Feb 22, 2008, at 10:50, raimue at macports.org wrote: > Revision: 34368 > http://trac.macosforge.org/projects/macports/changeset/34368 > Author: raimue at macports.org > Date: 2008-02-22 08:50:30 -0800 (Fri, 22 Feb 2008) > > Log Message: > ----------- > games/tuxmath: > Applying patch from maintainer, closes #14440 [snip] > +platform darwin { > + post-destroot { > + xinstall -m 755 -d ${destroot}/Applications/MacPorts/ > TuxMath.app/Contents/MacOS > + ln -s ${prefix}/bin/tuxmath ${destroot}/Applications/ > MacPorts/TuxMath.app/Contents/MacOS/TuxMath > + } > +} From raimue at macports.org Fri Feb 22 13:48:35 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri, 22 Feb 2008 22:48:35 +0100 Subject: [34368] trunk/dports/games/tuxmath/Portfile In-Reply-To: <76CD7BB8-0C2C-42D4-A449-99A013270AEC@macports.org> References: <20080222165032.4DC2A13B56B4@beta.macosforge.org> <76CD7BB8-0C2C-42D4-A449-99A013270AEC@macports.org> Message-ID: <47BF4333.80602@macports.org> Ryan Schmidt wrote: > You need to bump the port revision too so everyone gets that change. I thought about that, but was uncertain if just this addition justifies a revision increment. Rainer From ryandesign at macports.org Fri Feb 22 15:53:19 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 22 Feb 2008 17:53:19 -0600 Subject: [34368] trunk/dports/games/tuxmath/Portfile In-Reply-To: <47BF4333.80602@macports.org> References: <20080222165032.4DC2A13B56B4@beta.macosforge.org> <76CD7BB8-0C2C-42D4-A449-99A013270AEC@macports.org> <47BF4333.80602@macports.org> Message-ID: On Feb 22, 2008, at 15:48, Rainer M?ller wrote: > Ryan Schmidt wrote: > >> You need to bump the port revision too so everyone gets that change. > > I thought about that, but was uncertain if just this addition > justifies a revision increment. If a different set of files ends up on the user's machine, the revision must be incremented. Otherwise some users with tuxmath 1.6.1_0 have one set of files and other users with 1.6.1_0 have a different set of files. That's not reliable; that's not reproducible. I incremented the port revision in r34385. From raimue at macports.org Fri Feb 22 18:07:54 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 23 Feb 2008 03:07:54 +0100 Subject: [34368] trunk/dports/games/tuxmath/Portfile In-Reply-To: References: <20080222165032.4DC2A13B56B4@beta.macosforge.org> <76CD7BB8-0C2C-42D4-A449-99A013270AEC@macports.org> <47BF4333.80602@macports.org> Message-ID: <47BF7FFA.6060004@macports.org> Ryan Schmidt wrote: > If a different set of files ends up on the user's machine, the > revision must be incremented. Otherwise some users with tuxmath > 1.6.1_0 have one set of files and other users with 1.6.1_0 have a > different set of files. That's not reliable; that's not reproducible. > I incremented the port revision in r34385. True story. Thanks for your constant review of the commits! Rainer From raimue at macports.org Fri Feb 22 19:11:47 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 23 Feb 2008 04:11:47 +0100 Subject: MacPorts caching of distfiles [was Re: ntfs-3g 1.1120 source missing] In-Reply-To: <1A3478EC-45B1-4AA6-9141-880E61A07F39@apple.com> References: <6352d4ea0802211840y64fc460aoaa653fa1dfb6cfad@mail.gmail.com> <6352d4ea0802221123j18d4146h8b299f39fac10369@mail.gmail.com> <73ED446F-4577-437C-AE65-56B3D5D3899B@macports.org> <2AFC2157-A71E-4BA6-9C0E-00EEC697EF06@apple.com> <1A3478EC-45B1-4AA6-9141-880E61A07F39@apple.com> Message-ID: <47BF8EF3.4040804@macports.org> William Siegrist wrote: > I already made the offer to portmgr a while back, so they know. I > think there needs to be some added API to macports in order to make > the engineering a little cleaner server-side, but there hasnt been > much discussion yet. So if anyone wants to take the lead on behalf of > MacPorts, I'll help/support whatever we come up with for accomplishing > the mirroring. One of these things would be how we would push files on the mirror? If we keep master_sites we could use something like `port fetch all' in a cronjob or in a post-commit hook. But that will have the problem that it currently port fetch will not remove old distfiles. So this would need improvement. Alternatively committers would have to upload there files manually which would be more work for them and also more error-prone. And I think we should move this discussion to macports-dev at . Rainer From wsiegrist at apple.com Fri Feb 22 20:08:29 2008 From: wsiegrist at apple.com (William Siegrist) Date: Fri, 22 Feb 2008 20:08:29 -0800 Subject: MacPorts caching of distfiles [was Re: ntfs-3g 1.1120 source missing] In-Reply-To: <47BF8EF3.4040804@macports.org> References: <6352d4ea0802211840y64fc460aoaa653fa1dfb6cfad@mail.gmail.com> <6352d4ea0802221123j18d4146h8b299f39fac10369@mail.gmail.com> <73ED446F-4577-437C-AE65-56B3D5D3899B@macports.org> <2AFC2157-A71E-4BA6-9C0E-00EEC697EF06@apple.com> <1A3478EC-45B1-4AA6-9141-880E61A07F39@apple.com> <47BF8EF3.4040804@macports.org> Message-ID: <1D834EBD-2515-4102-82FE-5313FF93C850@apple.com> The server would grab distfiles during post-commit I imagine (assuming the checksums get changed, patchfiles added, etc). So similar to the way we handle linting of Portfiles during post-commit, we would check for these changes. I just dont want to implement some hack of parsing Portfiles manually, so I'd like a way to ask "port what-changed". That would be done in a tmp directory with 2 copies of the Portfile (the server handles gathering these) from revs HEAD-1 and HEAD. The "what- changed" operation should print URLs and checksums for the server to retrieve. I can take it from there. Not sure how easy that is given the current API; thats the part I was hoping someone familiar with the MP Tcl code could assist with. -Bill On Feb 22, 2008, at 7:11 PM, Rainer M?ller wrote: > William Siegrist wrote: >> I already made the offer to portmgr a while back, so they know. I >> think there needs to be some added API to macports in order to >> make the engineering a little cleaner server-side, but there hasnt >> been much discussion yet. So if anyone wants to take the lead on >> behalf of MacPorts, I'll help/support whatever we come up with for >> accomplishing the mirroring. > > One of these things would be how we would push files on the mirror? > If we keep master_sites we could use something like `port fetch all' > in a cronjob or in a post-commit hook. But that will have the > problem that it currently port fetch will not remove old distfiles. > So this would need improvement. > Alternatively committers would have to upload there files manually > which would be more work for them and also more error-prone. > > And I think we should move this discussion to macports-dev at . > > Rainer ---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist at 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/20080222/f432ad6e/attachment-0001.bin From jkh at apple.com Fri Feb 22 21:00:59 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Fri, 22 Feb 2008 21:00:59 -0800 Subject: MacPorts caching of distfiles [was Re: ntfs-3g 1.1120 source missing] In-Reply-To: <47BF8EF3.4040804@macports.org> References: <6352d4ea0802211840y64fc460aoaa653fa1dfb6cfad@mail.gmail.com> <6352d4ea0802221123j18d4146h8b299f39fac10369@mail.gmail.com> <73ED446F-4577-437C-AE65-56B3D5D3899B@macports.org> <2AFC2157-A71E-4BA6-9C0E-00EEC697EF06@apple.com> <1A3478EC-45B1-4AA6-9141-880E61A07F39@apple.com> <47BF8EF3.4040804@macports.org> Message-ID: <9418C4F2-FD58-469B-A1E2-58EC5A22D9EE@apple.com> On Feb 22, 2008, at 7:11 PM, Rainer M?ller wrote: > One of these things would be how we would push files on the mirror? > If we keep master_sites we could use something like `port fetch all' > in a cronjob or in a post-commit hook. But that will have the > problem that it currently port fetch will not remove old distfiles. > So this would need improvement. > Alternatively committers would have to upload there files manually > which would be more work for them and also more error-prone. 1. I think doing a "port fetch all" is just fine - it will skip the fetch step for ports which already have their distfiles in place (we can even add a little extra logic to stick them somewhere other than in ${prefix}/var/macports/distfiles for the mirroring case) and doesn't involve a lot of extra work on our part. The only thing we'll need to make sure of is that our timeout logic is genuinely robust since we don't want a single hanging fetch to scrog the entire mirror run, ditto for our failed fetch logic - we don't want partial distfiles to get left lying around, but both of those are things we should have working well anyway. 2. I see no need to delete stale distfiles. People will have older versions of the ports (not everyone keeps macports constantly up to date) and we still need to cache old distfiles for old ports (it's also useful for checking older versions of a port out of svn and still being able to use them, say if a new version has completely failed to work in an unexpected way). We have the disk space - there's no pressing need to garbage collect the distfiles with any urgency. - Jordan From jkh at apple.com Fri Feb 22 21:02:16 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Fri, 22 Feb 2008 21:02:16 -0800 Subject: MacPorts caching of distfiles [was Re: ntfs-3g 1.1120 source missing] In-Reply-To: <1D834EBD-2515-4102-82FE-5313FF93C850@apple.com> References: <6352d4ea0802211840y64fc460aoaa653fa1dfb6cfad@mail.gmail.com> <6352d4ea0802221123j18d4146h8b299f39fac10369@mail.gmail.com> <73ED446F-4577-437C-AE65-56B3D5D3899B@macports.org> <2AFC2157-A71E-4BA6-9C0E-00EEC697EF06@apple.com> <1A3478EC-45B1-4AA6-9141-880E61A07F39@apple.com> <47BF8EF3.4040804@macports.org> <1D834EBD-2515-4102-82FE-5313FF93C850@apple.com> Message-ID: On Feb 22, 2008, at 8:08 PM, William Siegrist wrote: > The server would grab distfiles during post-commit I imagine > (assuming the checksums get changed, patchfiles added, etc). So > similar to the way we handle linting of Portfiles during post- > commit, we would check for these changes. It could be done that way, but I think it's overkill to try and add hooks for when ports are added when we can simply fetch in batch mode once a night or so. As I noted in my previous posting, support for that already exists. - Jordan From ebgssth at gmail.com Fri Feb 22 21:07:21 2008 From: ebgssth at gmail.com (js) Date: Sat, 23 Feb 2008 14:07:21 +0900 Subject: Warnings when I visit http://www.macports.org/ in Safari v.1.3.2 Message-ID: Hi, when I viist http://www.macports.org/ with Safari v.1.3.2, I always see the warnings saying This page contains the following errors: error on line 41 at column 459: Entity 'nbsp' not defined error on line 92 at column 45: Entity 'ldquo' not defined error on line 113 at column 211: Entity 'ldquo' not defined error on line 125 at column 319: Entity 'ldquo' not defined Below is a rendering of the page up to the first error. The page was itself apparently rendered well. Is this a problem no a bit old Safari? (seems safari process the document as xml?) In my opinion, if MacPorts is still supporting OS S 10.3, the main page should be ready for Safari v.1.3.2, the latest Safari for OS X 10.3. Any comments or suggestions? From raimue at macports.org Fri Feb 22 21:31:02 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 23 Feb 2008 06:31:02 +0100 Subject: Portfile modification date checks vs. Portfile revisions Message-ID: <47BFAF96.1010405@macports.org> Hi, currently, we enforce that every change has to increment the revision, in order to force a rebuild by the user. But in fact, the current base code also checks the last modified date of the Portfile to see if it was changed since installation. See sample with a non-existing port `empty': ---8<---snip---8<--- $ touch Portfile $ port install [...] ---> Installing empty 1_0 ---> Activating empty 1_0 ---> Cleaning empty $ port install Skipping org.macports.activate (empty ) since this port is already active ---> Cleaning empty $ touch Portfile $ port install [...] ---> Installing empty 1_0 Error: Target org.macports.install returned: Registry error: empty @1_0 already registered as installed. Please uninstall it first. Error: Status 1 encountered during processing. --->8---snap--->8--- So it clearly rebuilds just because the modification date of the Portfile itself changed (it also issues a message in debug mode, but I did not want to post a whole debug log). And you will notice this first *after* compiling, which could be a long time for some ports. It already happened to me: I typed `port install' just to see a message after fetching and compiling that actually I already had that exact same port/version/revision/variant installed. So I am asking if this is still needed at all. I would rather see `port install' telling me that this port is already installed and I would have to use `port upgrade` to get a newer version. Also, currently it only works for the exact combination of port/version/revision/variants, if it differs it will install anyway. This could be extended to check if it is installed at all no matter which version or which variants are selected. And install can of course be forced with -f. I suppose this was introduced for Portfile developers, so that it always runs the target if the Portfile is newer, but that is not comfortable or users in my opinion. What do you think? How should this work? Rainer From wsiegrist at apple.com Fri Feb 22 21:34:32 2008 From: wsiegrist at apple.com (William Siegrist) Date: Fri, 22 Feb 2008 21:34:32 -0800 Subject: MacPorts caching of distfiles [was Re: ntfs-3g 1.1120 source missing] In-Reply-To: References: <6352d4ea0802211840y64fc460aoaa653fa1dfb6cfad@mail.gmail.com> <6352d4ea0802221123j18d4146h8b299f39fac10369@mail.gmail.com> <73ED446F-4577-437C-AE65-56B3D5D3899B@macports.org> <2AFC2157-A71E-4BA6-9C0E-00EEC697EF06@apple.com> <1A3478EC-45B1-4AA6-9141-880E61A07F39@apple.com> <47BF8EF3.4040804@macports.org> <1D834EBD-2515-4102-82FE-5313FF93C850@apple.com> Message-ID: <001FB3D7-0F93-407B-8474-4FD0F4635867@apple.com> On Feb 22, 2008, at 9:02 PM, Jordan K. Hubbard wrote: > > On Feb 22, 2008, at 8:08 PM, William Siegrist wrote: > >> The server would grab distfiles during post-commit I imagine >> (assuming the checksums get changed, patchfiles added, etc). So >> similar to the way we handle linting of Portfiles during post- >> commit, we would check for these changes. > > It could be done that way, but I think it's overkill to try and add > hooks for when ports are added when we can simply fetch in batch > mode once a night or so. As I noted in my previous posting, support > for that already exists. > > - Jordan > We dont really see any dips in server load, so waiting until night (or any time in particular) doesnt buy us anything. I'm assuming you still agree with only fetching distfiles when they change, and we already have all the work done for this sort of post-commit job, so batching them just delays their availability. -Bill ---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist at 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/20080222/a328f8ff/attachment.bin From jkh at apple.com Fri Feb 22 21:55:22 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Fri, 22 Feb 2008 21:55:22 -0800 Subject: MacPorts caching of distfiles [was Re: ntfs-3g 1.1120 source missing] In-Reply-To: <001FB3D7-0F93-407B-8474-4FD0F4635867@apple.com> References: <6352d4ea0802211840y64fc460aoaa653fa1dfb6cfad@mail.gmail.com> <6352d4ea0802221123j18d4146h8b299f39fac10369@mail.gmail.com> <73ED446F-4577-437C-AE65-56B3D5D3899B@macports.org> <2AFC2157-A71E-4BA6-9C0E-00EEC697EF06@apple.com> <1A3478EC-45B1-4AA6-9141-880E61A07F39@apple.com> <47BF8EF3.4040804@macports.org> <1D834EBD-2515-4102-82FE-5313FF93C850@apple.com> <001FB3D7-0F93-407B-8474-4FD0F4635867@apple.com> Message-ID: <3E67C4F9-C335-4FAA-A4D7-BEE535043E70@apple.com> On Feb 22, 2008, at 9:34 PM, William Siegrist wrote: > We dont really see any dips in server load, so waiting until night > (or any time in particular) doesnt buy us anything. I'm assuming > you still agree with only fetching distfiles when they change, and > we already have all the work done for this sort of post-commit job, > so batching them just delays their availability. If you're already happy with the infrastructure required in MacPorts to make distfile fetching work, I withdraw my suggestion. The goal wasn't to reduce load on the server, the goal was to use existing mechanisms and require minimal changes to macports given the relative paucity of "base hackers" the project currently suffers from. - Jordan From afb at macports.org Fri Feb 22 23:51:06 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sat, 23 Feb 2008 08:51:06 +0100 Subject: MacPorts caching of distfiles [was Re: ntfs-3g 1.1120 source missing] In-Reply-To: <9418C4F2-FD58-469B-A1E2-58EC5A22D9EE@apple.com> References: <6352d4ea0802211840y64fc460aoaa653fa1dfb6cfad@mail.gmail.com> <6352d4ea0802221123j18d4146h8b299f39fac10369@mail.gmail.com> <73ED446F-4577-437C-AE65-56B3D5D3899B@macports.org> <2AFC2157-A71E-4BA6-9C0E-00EEC697EF06@apple.com> <1A3478EC-45B1-4AA6-9141-880E61A07F39@apple.com> <47BF8EF3.4040804@macports.org> <9418C4F2-FD58-469B-A1E2-58EC5A22D9EE@apple.com> Message-ID: <6B1FA0E4-BF32-4DDC-AB73-25143FD27C25@macports.org> Jordan K. Hubbard wrote: > On Feb 22, 2008, at 7:11 PM, Rainer M?ller wrote: > >> One of these things would be how we would push files on the mirror? >> If we keep master_sites we could use something like `port fetch all' >> in a cronjob or in a post-commit hook. But that will have the >> problem that it currently port fetch will not remove old distfiles. >> So this would need improvement. >> Alternatively committers would have to upload there files manually >> which would be more work for them and also more error-prone. > > 1. I think doing a "port fetch all" is just fine - it will skip the > fetch step for ports which already have their distfiles in place (we > can even add a little extra logic to stick them somewhere other than > in ${prefix}/var/macports/distfiles for the mirroring case) and > doesn't involve a lot of extra work on our part. The only thing we'll > need to make sure of is that our timeout logic is genuinely robust > since we don't want a single hanging fetch to scrog the entire mirror > run, ditto for our failed fetch logic - we don't want partial > distfiles to get left lying around, but both of those are things we > should have working well anyway. Before fetching all the files, it would probably nice to fix the timestamps so that they correctly reflect the upstream distfile ? http://trac.macports.org/projects/macports/ticket/12629 The --remote-time feature is added, but disabled due to the old and buggy version of libcurl that is present in Tiger... --anders From randall.h.wood at alexandriasoftware.com Sat Feb 23 03:44:57 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Sat, 23 Feb 2008 06:44:57 -0500 Subject: firefox-x11 fetch stalls Message-ID: The fetch phase for firefox-x11 is stalling on me. Is anyone else having this issue? -- Randall Wood randall.h.wood at alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From ryandesign at macports.org Sat Feb 23 03:46:37 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 23 Feb 2008 05:46:37 -0600 Subject: Portfile modification date checks vs. Portfile revisions In-Reply-To: <47BFAF96.1010405@macports.org> References: <47BFAF96.1010405@macports.org> Message-ID: On Feb 22, 2008, at 23:31, Rainer M?ller wrote: > currently, we enforce that every change has to increment the revision, > in order to force a rebuild by the user. But in fact, the current base > code also checks the last modified date of the Portfile to see if > it was > changed since installation. > > See sample with a non-existing port `empty': > ---8<---snip---8<--- > $ touch Portfile > $ port install > [...] > ---> Installing empty 1_0 > ---> Activating empty 1_0 > ---> Cleaning empty > $ port install > Skipping org.macports.activate (empty ) since this port is already > active > ---> Cleaning empty > $ touch Portfile > $ port install > [...] > ---> Installing empty 1_0 > Error: Target org.macports.install returned: Registry error: empty > @1_0 > already registered as installed. Please uninstall it first. > Error: Status 1 encountered during processing. > --->8---snap--->8--- > > So it clearly rebuilds just because the modification date of the > Portfile itself changed (it also issues a message in debug mode, but I > did not want to post a whole debug log). And you will notice this > first > *after* compiling, which could be a long time for some ports. > > It already happened to me: I typed `port install' just to see a > message after fetching and compiling that actually I already had that > exact same port/version/revision/variant installed. > So I am asking if this is still needed at all. I would rather see > `port > install' telling me that this port is already installed and I would > have > to use `port upgrade` to get a newer version. > Also, currently it only works for the exact combination of > port/version/revision/variants, if it differs it will install anyway. > This could be extended to check if it is installed at all no matter > which version or which variants are selected. And install can of > course > be forced with -f. > > I suppose this was introduced for Portfile developers, so that it > always > runs the target if the Portfile is newer, but that is not > comfortable or > users in my opinion. > > What do you think? How should this work? Isn't it fine the way it works now? It's that way, I think, so that, if you already have foo installed, but now you want foo +bar, you can "sudo port install foo +bar", and it'll fetch and configure and build and destroot and install, however long that takes, and then it'll print the message that foo is already installed. Then you can "sudo port deactivate foo" and "sudo port activate foo +bar" and within a few seconds have the port swapped out. From ryandesign at macports.org Sat Feb 23 03:47:53 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 23 Feb 2008 05:47:53 -0600 Subject: Warnings when I visit http://www.macports.org/ in Safari v.1.3.2 In-Reply-To: References: Message-ID: <05C24679-CA5A-40C4-BB37-350E401AE7F0@macports.org> Sounds like a bug. Though it may surprise some people to learn it, "nbsp" etc. are not valid entities in XML. Please file a ticket in our issue tracker so we can correct this. On Feb 22, 2008, at 23:07, js wrote: > Hi, > > when I viist http://www.macports.org/ with Safari v.1.3.2, > I always see the warnings saying > > > This page contains the following errors: > error on line 41 at column 459: Entity 'nbsp' not defined > error on line 92 at column 45: Entity 'ldquo' not defined > error on line 113 at column 211: Entity 'ldquo' not defined > error on line 125 at column 319: Entity 'ldquo' not defined > > Below is a rendering of the page up to the first error. > > > The page was itself apparently rendered well. > > Is this a problem no a bit old Safari? (seems safari process the > document as xml?) > > In my opinion, if MacPorts is still supporting OS S 10.3, > the main page should be ready for Safari v.1.3.2, the latest Safari > for OS X 10.3. > > Any comments or suggestions? From raimue at macports.org Sat Feb 23 04:35:20 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 23 Feb 2008 13:35:20 +0100 Subject: Portfile modification date checks vs. Portfile revisions In-Reply-To: References: <47BFAF96.1010405@macports.org> Message-ID: <47C01308.1060404@macports.org> Ryan Schmidt wrote: > Isn't it fine the way it works now? It's that way, I think, so that, > if you already have foo installed, but now you want foo +bar, you can > "sudo port install foo +bar", and it'll fetch and configure and build > and destroot and install, however long that takes, and then it'll > print the message that foo is already installed. Then you can "sudo > port deactivate foo" and "sudo port activate foo +bar" and within a > few seconds have the port swapped out. But if I already got foo, I don't want to wait for `port install foo' take a long time just to tell me that I already got it. Maybe my request was not clearly phrased. If the Portfile modification date is newer than the installation date, "port install foo" will always begin to fetch and build, although you can't install the exact same port/version/revision/variant twice. Installing will just not succeed. And the time spent on building this was most probably wasted. By the way, if I want a port with additional variants, I use `port -unf upgrade foo +bar'. Rainer From ebgssth at gmail.com Sat Feb 23 05:02:27 2008 From: ebgssth at gmail.com (js) Date: Sat, 23 Feb 2008 22:02:27 +0900 Subject: Warnings when I visit http://www.macports.org/ in Safari v.1.3.2 In-Reply-To: <05C24679-CA5A-40C4-BB37-350E401AE7F0@macports.org> References: <05C24679-CA5A-40C4-BB37-350E401AE7F0@macports.org> Message-ID: Done http://trac.macosforge.org/projects/macports/ticket/14455 On Sat, Feb 23, 2008 at 8:47 PM, Ryan Schmidt wrote: > Sounds like a bug. Though it may surprise some people to learn it, > "nbsp" etc. are not valid entities in XML. Please file a ticket in > our issue tracker so we can correct this. > > > > > On Feb 22, 2008, at 23:07, js wrote: > > > Hi, > > > > when I viist http://www.macports.org/ with Safari v.1.3.2, > > I always see the warnings saying > > > > > > This page contains the following errors: > > error on line 41 at column 459: Entity 'nbsp' not defined > > error on line 92 at column 45: Entity 'ldquo' not defined > > error on line 113 at column 211: Entity 'ldquo' not defined > > error on line 125 at column 319: Entity 'ldquo' not defined > > > > Below is a rendering of the page up to the first error. > > > > > > The page was itself apparently rendered well. > > > > Is this a problem no a bit old Safari? (seems safari process the > > document as xml?) > > > > In my opinion, if MacPorts is still supporting OS S 10.3, > > the main page should be ready for Safari v.1.3.2, the latest Safari > > for OS X 10.3. > > > > Any comments or suggestions? > From rsync at reifferscheid.org Sat Feb 23 05:03:57 2008 From: rsync at reifferscheid.org (Thomas Reifferscheid) Date: Sat, 23 Feb 2008 14:03:57 +0100 Subject: svn commit broken: Internal Server Error Message-ID: <47C019BD.1080102@reifferscheid.org> Hi, g4:~/macports-trunk/dports/www/w3m thomas$ svn --username=reiffert at macports.org -m "* Add variant no_x11, for people who have gdk compiled with +quartz" commit svn: Commit failed (details follow): svn: MKACTIVITY of '/repository/macports/!svn/act/302581ba-5f0f-40e9-be13-91eb85e90a04': 500 Internal Server Error (https://svn.macports.org) g4:~/macports-trunk/dports/www/w3m thomas$ Kind regards Thomas From ryandesign at macports.org Sat Feb 23 05:18:07 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 23 Feb 2008 07:18:07 -0600 Subject: Portfile modification date checks vs. Portfile revisions In-Reply-To: <47C01308.1060404@macports.org> References: <47BFAF96.1010405@macports.org> <47C01308.1060404@macports.org> Message-ID: On Feb 23, 2008, at 06:35, Rainer M?ller wrote: > Ryan Schmidt wrote: > >> Isn't it fine the way it works now? It's that way, I think, so >> that, if you already have foo installed, but now you want foo >> +bar, you can "sudo port install foo +bar", and it'll fetch and >> configure and build and destroot and install, however long that >> takes, and then it'll print the message that foo is already >> installed. Then you can "sudo port deactivate foo" and "sudo port >> activate foo +bar" and within a few seconds have the port swapped >> out. > > But if I already got foo, I don't want to wait for `port install foo' > take a long time just to tell me that I already got it. > > Maybe my request was not clearly phrased. If the Portfile > modification date is newer than the installation date, "port > install foo" will always begin to fetch and build, although you > can't install the exact same port/version/revision/variant twice. > Installing will just not succeed. And the time spent on building > this was most probably wasted. Not wasted. Just deactivate the one you got and then activate the new one. > By the way, if I want a port with additional variants, I use `port - > unf upgrade foo +bar'. I didn't know that worked. From raimue at macports.org Sat Feb 23 05:21:51 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 23 Feb 2008 14:21:51 +0100 Subject: Portfile modification date checks vs. Portfile revisions In-Reply-To: References: <47BFAF96.1010405@macports.org> <47C01308.1060404@macports.org> Message-ID: <47C01DEF.1010401@macports.org> Ryan Schmidt wrote: > Not wasted. Just deactivate the one you got and then activate the new > one. Not possible. Install *failed*. You can't install the exact same version/revision/variants twice. Rainer From ryandesign at macports.org Sat Feb 23 05:24:14 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 23 Feb 2008 07:24:14 -0600 Subject: Portfile modification date checks vs. Portfile revisions In-Reply-To: <47C01DEF.1010401@macports.org> References: <47BFAF96.1010405@macports.org> <47C01308.1060404@macports.org> <47C01DEF.1010401@macports.org> Message-ID: <54310EA6-74E1-4ABE-8FDD-2EABAB37ECF8@macports.org> On Feb 23, 2008, at 07:21, Rainer M?ller wrote: > Ryan Schmidt wrote: > >> Not wasted. Just deactivate the one you got and then activate the >> new one. > > Not possible. Install *failed*. You can't install the exact same > version/revision/variants twice. Oh. Um, yes. I see that now. Just ignore me while I go get some tea... maybe that will wake me up. From wsiegrist at apple.com Sat Feb 23 07:25:42 2008 From: wsiegrist at apple.com (William Siegrist) Date: Sat, 23 Feb 2008 07:25:42 -0800 Subject: svn commit broken: Internal Server Error In-Reply-To: <47C019BD.1080102@reifferscheid.org> References: <47C019BD.1080102@reifferscheid.org> Message-ID: <98238366-1509-4D90-9DFA-E3180CD00737@apple.com> The problem apparently went away, I'm not sure what was causing it yet. If you're still having trouble please let me know. -Bill On Feb 23, 2008, at 5:03 AM, Thomas Reifferscheid wrote: > Hi, > > > g4:~/macports-trunk/dports/www/w3m thomas$ svn > --username=reiffert at macports.org -m "* Add variant no_x11, for people > who have gdk compiled with +quartz" commit > svn: Commit failed (details follow): > svn: MKACTIVITY of > '/repository/macports/!svn/act/302581ba-5f0f-40e9-be13-91eb85e90a04': > 500 Internal Server Error (https://svn.macports.org) > g4:~/macports-trunk/dports/www/w3m thomas$ > > > Kind regards > Thomas > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev ---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist at 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/20080223/5cccdfa5/attachment.bin From wsiegrist at apple.com Sat Feb 23 08:05:51 2008 From: wsiegrist at apple.com (William Siegrist) Date: Sat, 23 Feb 2008 08:05:51 -0800 Subject: MacPorts caching of distfiles [was Re: ntfs-3g 1.1120 source missing] In-Reply-To: <3E67C4F9-C335-4FAA-A4D7-BEE535043E70@apple.com> References: <6352d4ea0802211840y64fc460aoaa653fa1dfb6cfad@mail.gmail.com> <6352d4ea0802221123j18d4146h8b299f39fac10369@mail.gmail.com> <73ED446F-4577-437C-AE65-56B3D5D3899B@macports.org> <2AFC2157-A71E-4BA6-9C0E-00EEC697EF06@apple.com> <1A3478EC-45B1-4AA6-9141-880E61A07F39@apple.com> <47BF8EF3.4040804@macports.org> <1D834EBD-2515-4102-82FE-5313FF93C850@apple.com> <001FB3D7-0F93-407B-8474-4FD0F4635867@apple.com> <3E67C4F9-C335-4FAA-A4D7-BEE535043E70@apple.com> Message-ID: <3AA7B26F-F19B-4753-865F-6D4018F2775F@apple.com> I didnt mean to add any unnecessary work for MP. My main point was that per-commit versus daily is the same work for me. I dont have any hard stats, but I suppose most Portfile changes result in some sort of distfile change (most are version bumps?), so we can probably just make it work with a "port fetch". We already go through the trouble of pulling aside a fresh copy of the Portfile during post-commit for linting, so we can just add in the fetch at that point. So whats left? I think you'll want a special hostname for these? Maybe http://distfiles.macports.org/ //? -Bill On Feb 22, 2008, at 9:55 PM, Jordan K. Hubbard wrote: > > On Feb 22, 2008, at 9:34 PM, William Siegrist wrote: > >> We dont really see any dips in server load, so waiting until night >> (or any time in particular) doesnt buy us anything. I'm assuming >> you still agree with only fetching distfiles when they change, and >> we already have all the work done for this sort of post-commit job, >> so batching them just delays their availability. > > If you're already happy with the infrastructure required in MacPorts > to make distfile fetching work, I withdraw my suggestion. The goal > wasn't to reduce load on the server, the goal was to use existing > mechanisms and require minimal changes to macports given the > relative paucity of "base hackers" the project currently suffers from. > > - Jordan > ---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist at 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/20080223/4226f6e9/attachment.bin From wsiegrist at apple.com Sat Feb 23 08:09:08 2008 From: wsiegrist at apple.com (William Siegrist) Date: Sat, 23 Feb 2008 08:09:08 -0800 Subject: MacPorts caching of distfiles [was Re: ntfs-3g 1.1120 source missing] In-Reply-To: <6B1FA0E4-BF32-4DDC-AB73-25143FD27C25@macports.org> References: <6352d4ea0802211840y64fc460aoaa653fa1dfb6cfad@mail.gmail.com> <6352d4ea0802221123j18d4146h8b299f39fac10369@mail.gmail.com> <73ED446F-4577-437C-AE65-56B3D5D3899B@macports.org> <2AFC2157-A71E-4BA6-9C0E-00EEC697EF06@apple.com> <1A3478EC-45B1-4AA6-9141-880E61A07F39@apple.com> <47BF8EF3.4040804@macports.org> <9418C4F2-FD58-469B-A1E2-58EC5A22D9EE@apple.com> <6B1FA0E4-BF32-4DDC-AB73-25143FD27C25@macports.org> Message-ID: The servers are running Tiger, but have curl installed via MP, so this shouldnt be a problem unless /usr/bin is hardcoded for this? Or am I missing the issue? -Bill On Feb 22, 2008, at 11:51 PM, Anders F Bj?rklund wrote: > Jordan K. Hubbard wrote: > >> On Feb 22, 2008, at 7:11 PM, Rainer M?ller wrote: >> >>> One of these things would be how we would push files on the mirror? >>> If we keep master_sites we could use something like `port fetch all' >>> in a cronjob or in a post-commit hook. But that will have the >>> problem that it currently port fetch will not remove old distfiles. >>> So this would need improvement. >>> Alternatively committers would have to upload there files manually >>> which would be more work for them and also more error-prone. >> >> 1. I think doing a "port fetch all" is just fine - it will skip the >> fetch step for ports which already have their distfiles in place (we >> can even add a little extra logic to stick them somewhere other than >> in ${prefix}/var/macports/distfiles for the mirroring case) and >> doesn't involve a lot of extra work on our part. The only thing >> we'll >> need to make sure of is that our timeout logic is genuinely robust >> since we don't want a single hanging fetch to scrog the entire mirror >> run, ditto for our failed fetch logic - we don't want partial >> distfiles to get left lying around, but both of those are things we >> should have working well anyway. > > Before fetching all the files, it would probably nice to fix the > timestamps so that they correctly reflect the upstream distfile ? > > http://trac.macports.org/projects/macports/ticket/12629 > > The --remote-time feature is added, but disabled due to the > old and buggy version of libcurl that is present in Tiger... > > --anders > > _______________________________________________ > macports-users mailing list > macports-users at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-users ---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist at 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/20080223/2394b963/attachment.bin From ryandesign at macports.org Sat Feb 23 08:26:33 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 23 Feb 2008 10:26:33 -0600 Subject: MacPorts caching of distfiles [was Re: ntfs-3g 1.1120 source missing] In-Reply-To: References: <6352d4ea0802211840y64fc460aoaa653fa1dfb6cfad@mail.gmail.com> <6352d4ea0802221123j18d4146h8b299f39fac10369@mail.gmail.com> <73ED446F-4577-437C-AE65-56B3D5D3899B@macports.org> <2AFC2157-A71E-4BA6-9C0E-00EEC697EF06@apple.com> <1A3478EC-45B1-4AA6-9141-880E61A07F39@apple.com> <47BF8EF3.4040804@macports.org> <9418C4F2-FD58-469B-A1E2-58EC5A22D9EE@apple.com> <6B1FA0E4-BF32-4DDC-AB73-25143FD27C25@macports.org> Message-ID: <459A811D-97E9-44B0-9D20-67C9EBA0B039@macports.org> On Feb 23, 2008, at 10:09, William Siegrist wrote: > On Feb 22, 2008, at 11:51 PM, Anders F Bj?rklund wrote: > >> Before fetching all the files, it would probably nice to fix the >> timestamps so that they correctly reflect the upstream distfile ? >> >> http://trac.macports.org/projects/macports/ticket/12629 >> >> The --remote-time feature is added, but disabled due to the >> old and buggy version of libcurl that is present in Tiger... > > The servers are running Tiger, but have curl installed via MP, so > this shouldnt be a problem unless /usr/bin is hardcoded for this? > Or am I missing the issue? /usr/bin is not hardcoded for this, but the feature is disabled because it will cause fetches to fail from FTP sites if running on Tiger and if MacPorts curl is not installed. From ryandesign at macports.org Sat Feb 23 08:29:12 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 23 Feb 2008 10:29:12 -0600 Subject: MacPorts caching of distfiles In-Reply-To: <3AA7B26F-F19B-4753-865F-6D4018F2775F@apple.com> References: <6352d4ea0802211840y64fc460aoaa653fa1dfb6cfad@mail.gmail.com> <6352d4ea0802221123j18d4146h8b299f39fac10369@mail.gmail.com> <73ED446F-4577-437C-AE65-56B3D5D3899B@macports.org> <2AFC2157-A71E-4BA6-9C0E-00EEC697EF06@apple.com> <1A3478EC-45B1-4AA6-9141-880E61A07F39@apple.com> <47BF8EF3.4040804@macports.org> <1D834EBD-2515-4102-82FE-5313FF93C850@apple.com> <001FB3D7-0F93-407B-8474-4FD0F4635867@apple.com> <3E67C4F9-C335-4FAA-A4D7-BEE535043E70@apple.com> <3AA7B26F-F19B-4753-865F-6D4018F2775F@apple.com> Message-ID: <7682B66D-465A-4A38-8D44-8A7BC1392E15@macports.org> On Feb 23, 2008, at 10:05, William Siegrist wrote: > I didnt mean to add any unnecessary work for MP. My main point was > that per-commit versus daily is the same work for me. I dont have > any hard stats, but I suppose most Portfile changes result in some > sort of distfile change (most are version bumps?), so we can > probably just make it work with a "port fetch". We already go > through the trouble of pulling aside a fresh copy of the Portfile > during post-commit for linting, so we can just add in the fetch at > that point. > > So whats left? I think you'll want a special hostname for these? > Maybe http://distfiles.macports.org///? Is this going to be a distfiles backup in case the original site goes away? Or is this going to be a primary fetch location, before the original master_sites? I assume the former, since we wouldn't want to stop using the lovely global distributed server network that for example sourceforge provides, would we? What, if anything, will we do with MacPorts-hosted distfiles that we currently have in the repository? The repository has never been a great place for distfiles to live IMHO. From jkh at apple.com Sat Feb 23 10:22:05 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Sat, 23 Feb 2008 10:22:05 -0800 Subject: MacPorts caching of distfiles [was Re: ntfs-3g 1.1120 source missing] In-Reply-To: <6B1FA0E4-BF32-4DDC-AB73-25143FD27C25@macports.org> References: <6352d4ea0802211840y64fc460aoaa653fa1dfb6cfad@mail.gmail.com> <6352d4ea0802221123j18d4146h8b299f39fac10369@mail.gmail.com> <73ED446F-4577-437C-AE65-56B3D5D3899B@macports.org> <2AFC2157-A71E-4BA6-9C0E-00EEC697EF06@apple.com> <1A3478EC-45B1-4AA6-9141-880E61A07F39@apple.com> <47BF8EF3.4040804@macports.org> <9418C4F2-FD58-469B-A1E2-58EC5A22D9EE@apple.com> <6B1FA0E4-BF32-4DDC-AB73-25143FD27C25@macports.org> Message-ID: <8DEA409C-08D7-44AA-9114-40440B42C01E@apple.com> On Feb 22, 2008, at 11:51 PM, Anders F Bj?rklund wrote: > Before fetching all the files, it would probably nice to fix the > timestamps so that they correctly reflect the upstream distfile ? I guess I'm missing something. Why is this important? Distfiles are essentially opaque to the MacPorts user, so what would be the point of going to extra trouble to sync a timestamp from some remote server (which might not even have the correct time - I've seen some pretty wacky timestamps out there on the net)? - Jordan From ryandesign at macports.org Sat Feb 23 12:14:08 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 23 Feb 2008 14:14:08 -0600 Subject: [34415] trunk/dports/aqua In-Reply-To: <20080223185925.9E6AC13EE348@beta.macosforge.org> References: <20080223185925.9E6AC13EE348@beta.macosforge.org> Message-ID: On Feb 23, 2008, at 12:59, jmr at macports.org wrote: > Revision: 34415 > http://trac.macosforge.org/projects/macports/changeset/34415 > Author: jmr at macports.org > Date: 2008-02-23 10:59:25 -0800 (Sat, 23 Feb 2008) > > Log Message: > ----------- > New port: Shiira2 > Closes #12580. [snip] > Added: trunk/dports/aqua/Shiira2/Portfile [snip] See my comments in ticket 12580, relating to the use of the "cd" and "exit" commands and some other issues. From jkh at apple.com Sat Feb 23 16:09:08 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Sat, 23 Feb 2008 16:09:08 -0800 Subject: MacPorts caching of distfiles In-Reply-To: <7682B66D-465A-4A38-8D44-8A7BC1392E15@macports.org> References: <6352d4ea0802211840y64fc460aoaa653fa1dfb6cfad@mail.gmail.com> <6352d4ea0802221123j18d4146h8b299f39fac10369@mail.gmail.com> <73ED446F-4577-437C-AE65-56B3D5D3899B@macports.org> <2AFC2157-A71E-4BA6-9C0E-00EEC697EF06@apple.com> <1A3478EC-45B1-4AA6-9141-880E61A07F39@apple.com> <47BF8EF3.4040804@macports.org> <1D834EBD-2515-4102-82FE-5313FF93C850@apple.com> <001FB3D7-0F93-407B-8474-4FD0F4635867@apple.com> <3E67C4F9-C335-4FAA-A4D7-BEE535043E70@apple.com> <3AA7B26F-F19B-4753-865F-6D4018F2775F@apple.com> <7682B66D-465A-4A38-8D44-8A7BC1392E15@macports.org> Message-ID: On Feb 23, 2008, at 8:29 AM, Ryan Schmidt wrote: > > On Feb 23, 2008, at 10:05, William Siegrist wrote: > >> I didnt mean to add any unnecessary work for MP. My main point was >> that per-commit versus daily is the same work for me. I dont have >> any hard stats, but I suppose most Portfile changes result in some >> sort of distfile change (most are version bumps?), so we can >> probably just make it work with a "port fetch". We already go >> through the trouble of pulling aside a fresh copy of the Portfile >> during post-commit for linting, so we can just add in the fetch at >> that point. >> >> So whats left? I think you'll want a special hostname for these? >> Maybe http://distfiles.macports.org///? > > > Is this going to be a distfiles backup in case the original site > goes away? Or is this going to be a primary fetch location, before > the original master_sites? I assume the former, since we wouldn't > want to stop using the lovely global distributed server network that > for example sourceforge provides, would we? "Depends." For the sourceforge case, I can see merit to the argument that it should be last in the search path. For almost everything else, however, there's merit to the argument that it should be first since few other individual distribution points can compare to Apple's mighty multi-gigabit bandwidth and peering points. Looking at the percentages, we see: $ find dports/ -name Portfile|xargs egrep master_sites[[:space:]] +sourceforge|wc 891 1822 51961 891 ports out of 4500. I'd say that's a strong argument for it being a primary fetch location. > What, if anything, will we do with MacPorts-hosted distfiles that we > currently have in the repository? The repository has never been a > great place for distfiles to live IMHO. Agreed. I see no reason they couldn't also be hosted in the same way. - Jordan From ryandesign at macports.org Sat Feb 23 17:20:06 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 23 Feb 2008 19:20:06 -0600 Subject: MacPorts caching of distfiles In-Reply-To: References: <6352d4ea0802211840y64fc460aoaa653fa1dfb6cfad@mail.gmail.com> <6352d4ea0802221123j18d4146h8b299f39fac10369@mail.gmail.com> <73ED446F-4577-437C-AE65-56B3D5D3899B@macports.org> <2AFC2157-A71E-4BA6-9C0E-00EEC697EF06@apple.com> <1A3478EC-45B1-4AA6-9141-880E61A07F39@apple.com> <47BF8EF3.4040804@macports.org> <1D834EBD-2515-4102-82FE-5313FF93C850@apple.com> <001FB3D7-0F93-407B-8474-4FD0F4635867@apple.com> <3E67C4F9-C335-4FAA-A4D7-BEE535043E70@apple.com> <3AA7B26F-F19B-4753-865F-6D4018F2775F@apple.com> <7682B66D-465A-4A38-8D44-8A7BC1392E15@macports.org> Message-ID: On Feb 23, 2008, at 18:09, Jordan K. Hubbard wrote: > On Feb 23, 2008, at 8:29 AM, Ryan Schmidt wrote: > >> Is this going to be a distfiles backup in case the original site >> goes away? Or is this going to be a primary fetch location, before >> the original master_sites? I assume the former, since we wouldn't >> want to stop using the lovely global distributed server network >> that for example sourceforge provides, would we? > > "Depends." For the sourceforge case, I can see merit to the > argument that it should be last in the search path. For almost > everything else, however, there's merit to the argument that it > should be first since few other individual distribution points can > compare to Apple's mighty multi-gigabit bandwidth and peering points. > > Looking at the percentages, we see: > > $ find dports/ -name Portfile|xargs egrep master_sites[[:space:]] > +sourceforge|wc > 891 1822 51961 > > 891 ports out of 4500. I'd say that's a strong argument for it > being a primary fetch location. There are many fetchgroups, but sourceforge is the only one I know that automatically does location-aware server selection. So I might agree. It might also solve these issues: There's a group of mirrors for apache software, but MacPorts is currently downloading everything directly from www.apache.org which is a no-no; see: http://lists.macosforge.org/pipermail/macports-dev/2008-January/ 004113.html Paul Beard has previously noted that software from the gnome group always gets downloaded from France because that's the first server in the gnome fetchgroup, but this is inefficient if one is not also in France; see: http://lists.macosforge.org/pipermail/macports-users/2007-April/ 002722.html and: http://lists.macosforge.org/pipermail/macports-users/2007-September/ 005596.html >> What, if anything, will we do with MacPorts-hosted distfiles that >> we currently have in the repository? The repository has never been >> a great place for distfiles to live IMHO. > > Agreed. I see no reason they couldn't also be hosted in the same way. The distfiles that are in our repository are there because they're not anywhere else. One reason is that the files used to be somewhere else (e.g. on the master site) but then they were removed because they were old, or they moved to a different URL, or the server died, or the domain name expired, or something. These cases will be handled by what's been proposed in this thread, since MacPorts will fetch the files onto its distfile mirror the instant the port is committed. If a server moves or files are renamed and so forth, the port author won't discover it until trying to update the port to a new version. But I suppose that's ok. Stuff continues to work for the end user, which is better than what we have now when projects' download locations change. What about distfiles which are already missing today? How do we get those into the distfiles mirror? Do we have to add them to the repository, so that they can be fetched from somewhere during the post-commit, and then remove them from the repository later? That's wasteful of repository space. I guess committers can put it on their own webspace temporarily, put that URL in the port's master_sites, commit it so the post-commit fetches it, then remove it from the master_sites and commit again. But that's messy. There should be a way to get a distfile directly onto the mirror, for those cases where it's supposed to act as master, not mirror. What about the distfiles currently in the repository? Is there a migration strategy for removing them? Or do we not care about the disk space occupied by those distfiles in the repository? I guess since the disk space won't be reclaimed unless we do a dump and filter and load of the repository, and since that is a big pain to do involving possibly lengthy downtime, we probably won't care enough about the disk space. What about distfiles that are stealth-upgraded? For example, I updated the ImageMagick port to 6.3.8-9 on 2008-02-18 and a day later a modified version of the 6.3.8-9 distfile appeared on the download site. A user reported the checksum error to me and I found that a few lines of the sourcecode had been changed in the new distfile, so I updated the port revision and the checksums and committed it and closed the ticket. If there had been a MacPorts distfile mirror first in line providing the original distfile to the user, this situation would never have been discovered, and MacPorts users would never get the modified distfile, which seems like a bad thing. The author of the software obviously updated the distfile for a reason and wants users to have that new version. The post-commit hook would have to do not only the fetch but also the checksum phase. If the checksums don't match, then clean --all (i.e. remove the (possibly old) distfile) and fetch and checksum again. If it now checksums properly, great: the distfile was old and has now been updated. If it still doesn't match then the author's checksums are wrong and and we run clean --all again (to remove the bad distfile from the mirror) and send an automated email to the maintainer or committer or something. This takes care of the issue of the old outdated distfile remaining on the mirror after the port maintainer finds out about the stealth-upgrade and updates the portfile. It does not however solve the problem of how the maintainer would discover the stealth-upgrade in the first place. And it negates one of the benefits of the mirror listed earlier: that older distfiles should remain available for users who haven't updated their ports tree or who deliberately are trying out an older version. This latter problem even more greatly affects ports whose distfile names do not contain the version number. By my rough grep estimate, we have over 125 ports in this situation. Port authors will discover a new version is available via the livecheck mechanism or via email notification from the project's announce list, one would hope, but once the update is committed, the old distfile won't be in the mirror anymore, if it has the same name as the new file. I believe I saw that the FreeBSD mirrors put distfiles into a directory whose name is the md5 checksum of that file. If we managed to do that somehow that might solve the problems. The proposed solution does not cache / mirror distfiles which are added as a result of selecting a variant or platform. Consider the +doc variant of many ports which causes additional documentation files to be downloaded, but there are other use cases as well; just grep for "distfiles-append" in the portfiles and you'll get an idea. There are ports that need to download different bootstrapping code based on platform, ports that download extra code only needed for the extra functionality enabled in a variant, etc. The fetch phase honors variants too, so we could get the list of variants with "port variants" and run the fetch phase once for each variant (in addition to a run without any variants). e.g. for smlnj we would end up running: port fetch smlnj port fetch smlnj +universal port fetch smlnj +powerpc port fetch smlnj +i386 In this port, all but +universal would end up fetching extra files. We would need to anticipate that selecting some variants will cause an error message and a nonzero return code, since it is common practice to display an error message and exit with a nonzero return code in the pre-fetch phase if we want to prevent the port from installing. For example, py-psyco does this if not running on an Intel Mac. We would want to ignore these errors in the post-commit hook. There's an additional problem of ports that error out based on platform and don't do so in a platform selector (so there's no variant we could select to overcome it). For example, the wine port exits in pre-fetch if you're not running on an Intel Mac, since wine needs an Intel processor. You may tell me this is fine because the Mac OS Forge server runs on Intel, but then you have the same problem with the oracle-instantclient port, which exits if you're not running on PowerPC, since the oracle instantclient currently needs a PowerPC. From afb at macports.org Sun Feb 24 08:04:14 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun, 24 Feb 2008 17:04:14 +0100 Subject: MacPorts caching of distfiles [was Re: ntfs-3g 1.1120 source missing] In-Reply-To: <8DEA409C-08D7-44AA-9114-40440B42C01E@apple.com> References: <6352d4ea0802211840y64fc460aoaa653fa1dfb6cfad@mail.gmail.com> <6352d4ea0802221123j18d4146h8b299f39fac10369@mail.gmail.com> <73ED446F-4577-437C-AE65-56B3D5D3899B@macports.org> <2AFC2157-A71E-4BA6-9C0E-00EEC697EF06@apple.com> <1A3478EC-45B1-4AA6-9141-880E61A07F39@apple.com> <47BF8EF3.4040804@macports.org> <9418C4F2-FD58-469B-A1E2-58EC5A22D9EE@apple.com> <6B1FA0E4-BF32-4DDC-AB73-25143FD27C25@macports.org> <8DEA409C-08D7-44AA-9114-40440B42C01E@apple.com> Message-ID: <9659DFCE-4013-4958-BCB8-9A7331F1621D@macports.org> Jordan K. Hubbard wrote: >> Before fetching all the files, it would probably nice to fix the >> timestamps so that they correctly reflect the upstream distfile ? > > I guess I'm missing something. Why is this important? Distfiles > are essentially opaque to the MacPorts user, so what would be the > point of going to extra trouble to sync a timestamp from some > remote server (which might not even have the correct time - I've > seen some pretty wacky timestamps out there on the net)? It's more important that the checksum matches, but I think it is nice to keep the timestamp. Of course, then you have broken systems such as SVN which doesn't even *add* a timestamp... (making for instance the MacPorts tarballs look like they were last modified today instead) But actual modification times are of course also inside the tarball, so it's not crucial. --anders From dgou at mac.com Sun Feb 24 09:29:16 2008 From: dgou at mac.com (Douglas Philips) Date: Sun, 24 Feb 2008 12:29:16 -0500 Subject: python 2.5 not playing well with others... Message-ID: <123B66A4-8038-41C0-9709-927E66ADF99E@mac.com> this morning I did a port -d selfupdate and then port outdated which revealed new versions of a number of python 2.5 things. When I tried to update python25, this is what I got: (and this error probably prevented all the other py25- upgrades from succeeding... --Doug ---> Fetching python25 ---> Attempting to fetch Python-2.5.2.tar.bz2 from http:// www.python.org//ftp/python/2.5.2/ ---> Verifying checksum(s) for python25 ---> Extracting python25 ---> Applying patches to python25 ---> Configuring python25 ---> Building python25 with target all ---> Staging python25 into destroot ---> Deactivating python25 2.5.1_4+darwin_8 ---> Installing python25 2.5.2_0+darwin_8 ---> Activating python25 2.5.2_0+darwin_8 Error: Target org.macports.activate returned: Image error: /opt/local/ etc/select/python/python25 is being used by the active python_select port. Please deactivate this port first, or use the -f flag to force the activation. ---> Activating python25 2.5.2_0+darwin_8 Error: Activating python25 2.5.2_0 failed: Image error: /opt/local/ etc/select/python/python25 is being used by the active python_select port. Please deactivate this port first, or use the -f flag to force the activation. From raimue at macports.org Sun Feb 24 11:57:14 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 24 Feb 2008 20:57:14 +0100 Subject: python 2.5 not playing well with others... In-Reply-To: <123B66A4-8038-41C0-9709-927E66ADF99E@mac.com> References: <123B66A4-8038-41C0-9709-927E66ADF99E@mac.com> Message-ID: <47C1CC1A.6020101@macports.org> Douglas Philips wrote: > this morning I did a port -d selfupdate and then port outdated which > revealed new versions of a number of python 2.5 things. When I tried > to update python25, this is what I got: (and this error probably > prevented all the other py25- upgrades from succeeding... Reinstall python_select, sudo port -unf upgrade python_select Then activate python25, sudo port activate python25 The python25 select file was moved from the python_select port to the python25 port itself. But since python25 does not depend on python_select, port upgrade outdated could have done this in the wrong order. Rainer From rsync at reifferscheid.org Sun Feb 24 13:25:36 2008 From: rsync at reifferscheid.org (Thomas Reifferscheid) Date: Sun, 24 Feb 2008 22:25:36 +0100 Subject: #macports CIA Message-ID: <47C1E0D0.9090906@reifferscheid.org> Who is maintaining the CIA bot on #macports? Can we install a summary-report for new trac tickets for some time (lets say for a week) and remove it when it's getting on our nerves... It's currently reporting svn revisions and I like to have new tickets in the form eg.: Ticket #14467: aircrack-ng 0.9.3 is out Thanks. Kind regards Thomas From raimue at macports.org Sun Feb 24 17:12:18 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 25 Feb 2008 02:12:18 +0100 Subject: #macports CIA In-Reply-To: <47C1E0D0.9090906@reifferscheid.org> References: <47C1E0D0.9090906@reifferscheid.org> Message-ID: <47C215F2.4010200@macports.org> Thomas Reifferscheid wrote: > Who is maintaining the CIA bot on #macports? As already said on IRC, it is operated by http://cia.vc > Can we install a summary-report for new trac tickets for some > time (lets say for a week) and remove it when it's getting on our nerves... > > It's currently reporting svn revisions and I like to have new tickets in > the form eg.: > > Ticket #14467: aircrack-ng 0.9.3 is out > > Thanks. It works as follows: The subversion repository contains a post-commit hook which reports every commit to cia.vc right after it has been done. To accomplish the same thing for new tickets, we would need a) support by cia.vc for that b) some Trac plugin which takes action upon new tickets I don't think it will be quick and easy to convince cia.vc to provide a new service like announcing tickets. But of course we could trying to ask for something like that! But if we are not successful there we could still use mpbot for that or set up a new bot (for the sake of an easier /ignore if someone dislikes it ;-)). Rainer From jkh at apple.com Sun Feb 24 19:21:35 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Sun, 24 Feb 2008 19:21:35 -0800 Subject: MacPorts caching of distfiles [was Re: ntfs-3g 1.1120 source missing] In-Reply-To: <3AA7B26F-F19B-4753-865F-6D4018F2775F@apple.com> References: <6352d4ea0802211840y64fc460aoaa653fa1dfb6cfad@mail.gmail.com> <6352d4ea0802221123j18d4146h8b299f39fac10369@mail.gmail.com> <73ED446F-4577-437C-AE65-56B3D5D3899B@macports.org> <2AFC2157-A71E-4BA6-9C0E-00EEC697EF06@apple.com> <1A3478EC-45B1-4AA6-9141-880E61A07F39@apple.com> <47BF8EF3.4040804@macports.org> <1D834EBD-2515-4102-82FE-5313FF93C850@apple.com> <001FB3D7-0F93-407B-8474-4FD0F4635867@apple.com> <3E67C4F9-C335-4FAA-A4D7-BEE535043E70@apple.com> <3AA7B26F-F19B-4753-865F-6D4018F2775F@apple.com> Message-ID: <56880928-47D1-4573-9665-3F7D6FA86EB6@apple.com> On Feb 23, 2008, at 8:05 AM, William Siegrist wrote: > So whats left? I think you'll want a special hostname for these? > Maybe http://distfiles.macports.org///? I'm not sure what value adds. / would seem more than reasonable, and a completely flat namespace even more so since it then becomes very easy to add to the search path for all ports. - Jordan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080224/10c03345/attachment.html From raimue at macports.org Sun Feb 24 19:46:50 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 25 Feb 2008 04:46:50 +0100 Subject: MacPorts caching of distfiles [was Re: ntfs-3g 1.1120 source missing] In-Reply-To: <56880928-47D1-4573-9665-3F7D6FA86EB6@apple.com> References: <6352d4ea0802211840y64fc460aoaa653fa1dfb6cfad@mail.gmail.com> <6352d4ea0802221123j18d4146h8b299f39fac10369@mail.gmail.com> <73ED446F-4577-437C-AE65-56B3D5D3899B@macports.org> <2AFC2157-A71E-4BA6-9C0E-00EEC697EF06@apple.com> <1A3478EC-45B1-4AA6-9141-880E61A07F39@apple.com> <47BF8EF3.4040804@macports.org> <1D834EBD-2515-4102-82FE-5313FF93C850@apple.com> <001FB3D7-0F93-407B-8474-4FD0F4635867@apple.com> <3E67C4F9-C335-4FAA-A4D7-BEE535043E70@apple.com> <3AA7B26F-F19B-4753-865F-6D4018F2775F@apple.com> <56880928-47D1-4573-9665-3F7D6FA86EB6@apple.com> Message-ID: <47C23A2A.5090101@macports.org> Jordan K. Hubbard wrote: > > On Feb 23, 2008, at 8:05 AM, William Siegrist wrote: > >> So whats left? I think you'll want a special hostname for these? >> Maybe http://distfiles.macports.org///? > > I'm not sure what value adds. / would seem more > than reasonable, and a completely flat namespace even more so since it > then becomes very easy to add to the search path for all ports. All distfiles in one single directory? I am against that at all! would be category, I think. But some ports also use the same distfiles by specifying distname (e.g. vim and vim-app). So maybe it would be better to use the distname of the regarding port to avoid mirroring files multiple times. Although that takes away the category information. I even do not like the fact that /opt/local/var/macports/distfiles is not categorized. But the whole categories handling in MacPorts is a bit broken; that's another topic... And it would be no problem to prepend URL with an advanced scheme to the master_sites list (or even add it at the end if the sourceforge mirror group is present, as said earlier). I think it would be just a bit more work to do it for ports using tagged mirrors also, but surely not impossible. Rainer From jkh at apple.com Sun Feb 24 21:06:05 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Sun, 24 Feb 2008 21:06:05 -0800 Subject: MacPorts caching of distfiles [was Re: ntfs-3g 1.1120 source missing] In-Reply-To: <47C23A2A.5090101@macports.org> References: <6352d4ea0802211840y64fc460aoaa653fa1dfb6cfad@mail.gmail.com> <6352d4ea0802221123j18d4146h8b299f39fac10369@mail.gmail.com> <73ED446F-4577-437C-AE65-56B3D5D3899B@macports.org> <2AFC2157-A71E-4BA6-9C0E-00EEC697EF06@apple.com> <1A3478EC-45B1-4AA6-9141-880E61A07F39@apple.com> <47BF8EF3.4040804@macports.org> <1D834EBD-2515-4102-82FE-5313FF93C850@apple.com> <001FB3D7-0F93-407B-8474-4FD0F4635867@apple.com> <3E67C4F9-C335-4FAA-A4D7-BEE535043E70@apple.com> <3AA7B26F-F19B-4753-865F-6D4018F2775F@apple.com> <56880928-47D1-4573-9665-3F7D6FA86EB6@apple.com> <47C23A2A.5090101@macports.org> Message-ID: On Feb 24, 2008, at 7:46 PM, Rainer M?ller wrote: > Jordan K. Hubbard wrote: >> On Feb 23, 2008, at 8:05 AM, William Siegrist wrote: >>> So whats left? I think you'll want a special hostname for these? >>> Maybe http://distfiles.macports.org///? >> I'm not sure what value adds. / would seem >> more than reasonable, and a completely flat namespace even more so >> since it then becomes very easy to add to the search path for all >> ports. > > All distfiles in one single directory? I am against that at all! Why? Collisions? If so, please name the collisions in question, because I cannot find any. If you add indirection to this then you lose the ability to have a global URL path that points to a mirror (either that or you need to add extra logic to the MacPorts fetch code). > would be category, I think. But some ports also use the same > distfiles by specifying distname (e.g. vim and vim-app). So maybe it > would be better to use the distname of the regarding port to avoid > mirroring files multiple times. Or you could just use a flat namespace... :-) > Although that takes away the category information. I even do not > like the fact that /opt/local/var/macports/distfiles is not > categorized. But the whole categories handling in MacPorts is a bit > broken; that's another topic... I fail to understand this stubborn insistence on date stamp and group information for files which are simply not meant to be user visible. There is no group information you need to see on the distfile mirror because you won't be managing the distfile mirror. > And it would be no problem to prepend URL with an advanced scheme to > the master_sites list (or even add it at the end if the sourceforge > mirror group is present, as said earlier). I think it would be just > a bit more work to do it for ports using tagged mirrors also, but > surely not impossible. This is over-engineering at its finest. - Jordan From wsiegrist at apple.com Sun Feb 24 21:12:23 2008 From: wsiegrist at apple.com (William Siegrist) Date: Sun, 24 Feb 2008 21:12:23 -0800 Subject: MacPorts caching of distfiles [was Re: ntfs-3g 1.1120 source missing] In-Reply-To: <56880928-47D1-4573-9665-3F7D6FA86EB6@apple.com> References: <6352d4ea0802211840y64fc460aoaa653fa1dfb6cfad@mail.gmail.com> <6352d4ea0802221123j18d4146h8b299f39fac10369@mail.gmail.com> <73ED446F-4577-437C-AE65-56B3D5D3899B@macports.org> <2AFC2157-A71E-4BA6-9C0E-00EEC697EF06@apple.com> <1A3478EC-45B1-4AA6-9141-880E61A07F39@apple.com> <47BF8EF3.4040804@macports.org> <1D834EBD-2515-4102-82FE-5313FF93C850@apple.com> <001FB3D7-0F93-407B-8474-4FD0F4635867@apple.com> <3E67C4F9-C335-4FAA-A4D7-BEE535043E70@apple.com> <3AA7B26F-F19B-4753-865F-6D4018F2775F@apple.com> <56880928-47D1-4573-9665-3F7D6FA86EB6@apple.com> Message-ID: <5102DF12-283C-4F32-A7CF-58389B61C69B@apple.com> It would match the layout of the ports in the svn repo and make the tree a little more manageable for human consumption. I could see providing Apache indexes for the tree so people could browser and grab distfiles manually. But mainly my suggestion was based on matching svn. -Bill On Feb 24, 2008, at 7:21 PM, Jordan K. Hubbard wrote: > > On Feb 23, 2008, at 8:05 AM, William Siegrist wrote: > >> So whats left? I think you'll want a special hostname for these? >> Maybe http://distfiles.macports.org///? > > I'm not sure what value adds. / would seem more > than reasonable, and a completely flat namespace even more so since > it then becomes very easy to add to the search path for all ports. > > - Jordan > ---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist at 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/20080224/fa016bf5/attachment-0001.bin From raimue at macports.org Sun Feb 24 21:29:08 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 25 Feb 2008 06:29:08 +0100 Subject: MacPorts caching of distfiles [was Re: ntfs-3g 1.1120 source missing] In-Reply-To: References: <6352d4ea0802211840y64fc460aoaa653fa1dfb6cfad@mail.gmail.com> <6352d4ea0802221123j18d4146h8b299f39fac10369@mail.gmail.com> <73ED446F-4577-437C-AE65-56B3D5D3899B@macports.org> <2AFC2157-A71E-4BA6-9C0E-00EEC697EF06@apple.com> <1A3478EC-45B1-4AA6-9141-880E61A07F39@apple.com> <47BF8EF3.4040804@macports.org> <1D834EBD-2515-4102-82FE-5313FF93C850@apple.com> <001FB3D7-0F93-407B-8474-4FD0F4635867@apple.com> <3E67C4F9-C335-4FAA-A4D7-BEE535043E70@apple.com> <3AA7B26F-F19B-4753-865F-6D4018F2775F@apple.com> <56880928-47D1-4573-9665-3F7D6FA86EB6@apple.com> <47C23A2A.5090101@macports.org> Message-ID: <47C25224.8000904@macports.org> Jordan K. Hubbard wrote: >> All distfiles in one single directory? I am against that at all! > > Why? Collisions? If so, please name the collisions in question, > because I cannot find any. Maybe not yet, but maybe they will come in later? Why not be collisions aware? > If you add indirection to this then you lose the ability to have a > global URL path that points to a mirror (either that or you need to > add extra logic to the MacPorts fetch code). Why are you against adding more logic to the fetch code? >> would be category, I think. But some ports also use the same >> distfiles by specifying distname (e.g. vim and vim-app). So maybe it >> would be better to use the distname of the regarding port to avoid >> mirroring files multiple times. > > Or you could just use a flat namespace... :-) And have one big cluttered directory without any links which file belongs to which port? With the distname approach, it adapts the layout of /opt/local/var/macports/distfiles where distfiles are currently stored locally. > I fail to understand this stubborn insistence on date stamp and group > information for files which are simply not meant to be user visible. > There is no group information you need to see on the distfile mirror > because you won't be managing the distfile mirror. But maybe I want to see what files are on a mirror for some specific port without having to look through a list of all distfiles ever referenced by any port. >> And it would be no problem to prepend URL with an advanced scheme to >> the master_sites list (or even add it at the end if the sourceforge >> mirror group is present, as said earlier). I think it would be just >> a bit more work to do it for ports using tagged mirrors also, but >> surely not impossible. > > This is over-engineering at its finest. Please explain why? It would give us the possibility to prefer some mirror lists (e.g. sourceforge) which already got a world wide location aware mirror network. It would not be good to throw that away and use the one single mirror (in case even overseas) instead. Rainer From jmpp at macports.org Sun Feb 24 23:09:44 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Mon, 25 Feb 2008 02:39:44 -0430 Subject: #macports CIA In-Reply-To: <47C215F2.4010200@macports.org> References: <47C1E0D0.9090906@reifferscheid.org> <47C215F2.4010200@macports.org> Message-ID: On Feb 24, 2008, at 8:42 PM, Rainer M?ller wrote: > Thomas Reifferscheid wrote: >> Who is maintaining the CIA bot on #macports? > > As already said on IRC, it is operated by http://cia.vc > >> Can we install a summary-report for new trac tickets for some >> time (lets say for a week) and remove it when it's getting on our >> nerves... >> >> It's currently reporting svn revisions and I like to have new >> tickets in >> the form eg.: >> >> Ticket #14467: aircrack-ng 0.9.3 is out >> >> Thanks. > > It works as follows: The subversion repository contains a post-commit > hook which reports every commit to cia.vc right after it has been > done. > > To accomplish the same thing for new tickets, we would need > a) support by cia.vc for that Not necessarily. We could certainly put together a local bot that feeds off Trac's RSS timeline and posts some kind of summary to the channel. The sources to mpbot are in svn, if I'm not mistaken (base/ portmgr/bots/port.rb?), so maybe we could even be built this functionality into it. In any case, I'm sure there wouldn't be any need to go through CIA to accomplish this. > > b) some Trac plugin which takes action upon new tickets RSS ;-) Regards,... -jmpp From rsync at reifferscheid.org Sun Feb 24 23:18:45 2008 From: rsync at reifferscheid.org (Thomas Reifferscheid) Date: Mon, 25 Feb 2008 08:18:45 +0100 Subject: #macports CIA In-Reply-To: References: <47C1E0D0.9090906@reifferscheid.org> <47C215F2.4010200@macports.org> Message-ID: <47C26BD5.7060503@reifferscheid.org> Shouldnt changeset=off keep category from appearing here? How to *only* transfer category newticket? http://trac.macports.org/projects/macports/timeline?wiki=off&milestone=off&ticket=on&changeset=off&max=50&daysback=1&format=rss RSS means polling the state frequently and parsing the differences, but what about an event based "Hey mpbot, there's a new ticket"? How would we trigger mpbot securely and without listening on additional ports etc? Juan Manuel Palacios wrote: > > Not necessarily. We could certainly put together a local bot that > feeds off Trac's RSS timeline and posts some kind of summary to the > channel. The sources to mpbot are in svn, if I'm not mistaken > (base/portmgr/bots/port.rb?), so maybe we could even be built this > functionality into it. From jmpp at macports.org Sun Feb 24 23:46:34 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Mon, 25 Feb 2008 03:16:34 -0430 Subject: Warnings when I visit http://www.macports.org/ in Safari v.1.3.2 In-Reply-To: <05C24679-CA5A-40C4-BB37-350E401AE7F0@macports.org> References: <05C24679-CA5A-40C4-BB37-350E401AE7F0@macports.org> Message-ID: On Feb 23, 2008, at 7:17 AM, Ryan Schmidt wrote: > Sounds like a bug. Though it may surprise some people to learn it, > "nbsp" etc. are not valid entities in XML. Please file a ticket in > our issue tracker so we can correct this. > If I'm not mistaken, they are in XHTML, as added by the DTD's: http://www.w3.org/TR/xhtml-modularization/dtd_module_defs.html#a_module_XHTML_Latin_1_Character_Entities (again, if I'm not mistaken, that document applies to XHTML 1.1, which is what I used for the website) But, of course, I could be reading that wrong, since you know much more about the subject than me ;-) In any case, would using the unicode code points fix the problems? Regards,... -jmpp > > On Feb 22, 2008, at 23:07, js wrote: > >> Hi, >> >> when I viist http://www.macports.org/ with Safari v.1.3.2, >> I always see the warnings saying >> >> >> This page contains the following errors: >> error on line 41 at column 459: Entity 'nbsp' not defined >> error on line 92 at column 45: Entity 'ldquo' not defined >> error on line 113 at column 211: Entity 'ldquo' not defined >> error on line 125 at column 319: Entity 'ldquo' not defined >> >> Below is a rendering of the page up to the first error. >> >> >> The page was itself apparently rendered well. >> >> Is this a problem no a bit old Safari? (seems safari process the >> document as xml?) >> >> In my opinion, if MacPorts is still supporting OS S 10.3, >> the main page should be ready for Safari v.1.3.2, the latest Safari >> for OS X 10.3. >> >> Any comments or suggestions? > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From afb at macports.org Sun Feb 24 23:49:05 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 25 Feb 2008 08:49:05 +0100 Subject: MacPorts caching of distfiles [was Re: ntfs-3g 1.1120 source missing] In-Reply-To: References: <6352d4ea0802211840y64fc460aoaa653fa1dfb6cfad@mail.gmail.com> <6352d4ea0802221123j18d4146h8b299f39fac10369@mail.gmail.com> <73ED446F-4577-437C-AE65-56B3D5D3899B@macports.org> <2AFC2157-A71E-4BA6-9C0E-00EEC697EF06@apple.com> <1A3478EC-45B1-4AA6-9141-880E61A07F39@apple.com> <47BF8EF3.4040804@macports.org> <1D834EBD-2515-4102-82FE-5313FF93C850@apple.com> <001FB3D7-0F93-407B-8474-4FD0F4635867@apple.com> <3E67C4F9-C335-4FAA-A4D7-BEE535043E70@apple.com> <3AA7B26F-F19B-4753-865F-6D4018F2775F@apple.com> <56880928-47D1-4573-9665-3F7D6FA86EB6@apple.com> <47C23A2A.5090101@macports.org> Message-ID: <550D1AD2-7555-4772-9532-10F65FD07F1F@macports.org> Jordan K. Hubbard wrote: > I fail to understand this stubborn insistence on date stamp and group > information for files which are simply not meant to be user visible. > There is no group information you need to see on the distfile mirror > because you won't be managing the distfile mirror. I worked around the issue on Tiger now, so the --remote-time option is now available there too - if wanted, it goes into portfetch.tcl Me, I don't really care whether the distfiles mirror dumps all files in one directory or not, but thought to mirror distfiles directory was the easiest option and also most straight-forward to implement. (works for http://svn.macports.org/repository/macports/distfiles/ ?) But if it's easier to implement and set up a distfiles mirror without using remotetime and subdirectories, then by all means ignore either. :-) --anders From ebgssth at gmail.com Mon Feb 25 06:00:06 2008 From: ebgssth at gmail.com (js) Date: Mon, 25 Feb 2008 23:00:06 +0900 Subject: Proposal for daily list of new tickets In-Reply-To: References: Message-ID: You can rely on RSS for that matter. One thing I want to have is weekly summary report of macports-dev, macports-list. Although this would need editors to write it up, very attractive for me. On 2/22/08, Randall Wood wrote: > Openoffice.org publishes a daily email of new tickets to, not only its > developers mailing lists, but to its blogging systems as well. Is > there any reason we should not (or can not) have trac provide a daily > email into the macports-dev list of new tickets? > > I have subscribed to the tickets list (and quickly unsubscribed once > it got working) but it was way too much email to handle, but maybe a > daily digest listing new tickets would help? > > -- > Randall Wood > randall.h.wood at alexandriasoftware.com > > "The rules are simple: The ball is round. The game lasts 90 minutes. > All the rest is just philosophy." > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > From wsiegrist at apple.com Mon Feb 25 09:58:47 2008 From: wsiegrist at apple.com (William Siegrist) Date: Mon, 25 Feb 2008 09:58:47 -0800 Subject: MacPorts caching of distfiles In-Reply-To: References: <6352d4ea0802211840y64fc460aoaa653fa1dfb6cfad@mail.gmail.com> <6352d4ea0802221123j18d4146h8b299f39fac10369@mail.gmail.com> <73ED446F-4577-437C-AE65-56B3D5D3899B@macports.org> <2AFC2157-A71E-4BA6-9C0E-00EEC697EF06@apple.com> <1A3478EC-45B1-4AA6-9141-880E61A07F39@apple.com> <47BF8EF3.4040804@macports.org> <1D834EBD-2515-4102-82FE-5313FF93C850@apple.com> <001FB3D7-0F93-407B-8474-4FD0F4635867@apple.com> <3E67C4F9-C335-4FAA-A4D7-BEE535043E70@apple.com> <3AA7B26F-F19B-4753-865F-6D4018F2775F@apple.com> <7682B66D-465A-4A38-8D44-8A7BC1392E15@macports.org> Message-ID: On Feb 23, 2008, at 5:20 PM, Ryan Schmidt wrote: > What about distfiles which are already missing today? How do we get > those into the distfiles mirror? Do we have to add them to the > repository, so that they can be fetched from somewhere during the > post-commit, and then remove them from the repository later? That's > wasteful of repository space. I guess committers can put it on their > own webspace temporarily, put that URL in the port's master_sites, > commit it so the post-commit fetches it, then remove it from the > master_sites and commit again. But that's messy. There should be a > way to get a distfile directly onto the mirror, for those cases > where it's supposed to act as master, not mirror. The initial load can be handled manually by me. No need for committing or using other web hosting. If there turns out to be frequent need for manually adding files, we can always come up with a simple upload form. > > What about the distfiles currently in the repository? Is there a > migration strategy for removing them? Or do we not care about the > disk space occupied by those distfiles in the repository? I guess > since the disk space won't be reclaimed unless we do a dump and > filter and load of the repository, and since that is a big pain to > do involving possibly lengthy downtime, we probably won't care > enough about the disk space. > I dont think the disk space is worth the trouble. The MP repo is only a small percentage of our total disk usage. > > What about distfiles that are stealth-upgraded? For example, I > updated the ImageMagick port to 6.3.8-9 on 2008-02-18 and a day > later a modified version of the 6.3.8-9 distfile appeared on the > download site. A user reported the checksum error to me and I found > that a few lines of the sourcecode had been changed in the new > distfile, so I updated the port revision and the checksums and > committed it and closed the ticket. If there had been a MacPorts > distfile mirror first in line providing the original distfile to the > user, this situation would never have been discovered, and MacPorts > users would never get the modified distfile, which seems like a bad > thing. The author of the software obviously updated the distfile for > a reason and wants users to have that new version. > I'd hope the author would bump the version in most cases, but maybe livecheck or distcheck can be extended to do checksums of the actual distfiles as a way to test for changes? > The post-commit hook would have to do not only the fetch but also > the checksum phase. If the checksums don't match, then clean --all > (i.e. remove the (possibly old) distfile) and fetch and checksum > again. If it now checksums properly, great: the distfile was old and > has now been updated. If it still doesn't match then the author's > checksums are wrong and and we run clean --all again (to remove the > bad distfile from the mirror) and send an automated email to the > maintainer or committer or something. This takes care of the issue > of the old outdated distfile remaining on the mirror after the port > maintainer finds out about the stealth-upgrade and updates the > portfile. It does not however solve the problem of how the > maintainer would discover the stealth-upgrade in the first place. > And it negates one of the benefits of the mirror listed earlier: > that older distfiles should remain available for users who haven't > updated their ports tree or who deliberately are trying out an older > version. > > This latter problem even more greatly affects ports whose distfile > names do not contain the version number. By my rough grep estimate, > we have over 125 ports in this situation. Port authors will discover > a new version is available via the livecheck mechanism or via email > notification from the project's announce list, one would hope, but > once the update is committed, the old distfile won't be in the > mirror anymore, if it has the same name as the new file. > > I believe I saw that the FreeBSD mirrors put distfiles into a > directory whose name is the md5 checksum of that file. If we managed > to do that somehow that might solve the problems. > This goes back to Jordan's suggestion of keeping the namespace flat. Adding the indirection of MD5 for the minority of ports that need it might be overkill? Maybe keep the current files around in a flatter space and bury the historical files down in MD5 or Portfile-versioned directories? This also seems complicated, but maybe its a reasonable compromise? > > The proposed solution does not cache / mirror distfiles which are > added as a result of selecting a variant or platform. Consider the > +doc variant of many ports which causes additional documentation > files to be downloaded, but there are other use cases as well; just > grep for "distfiles-append" in the portfiles and you'll get an idea. > There are ports that need to download different bootstrapping code > based on platform, ports that download extra code only needed for > the extra functionality enabled in a variant, etc. > > The fetch phase honors variants too, so we could get the list of > variants with "port variants" and run the fetch phase once for each > variant (in addition to a run without any variants). e.g. for smlnj > we would end up running: > > port fetch smlnj > port fetch smlnj +universal > port fetch smlnj +powerpc > port fetch smlnj +i386 > > In this port, all but +universal would end up fetching extra files. > > We would need to anticipate that selecting some variants will cause > an error message and a nonzero return code, since it is common > practice to display an error message and exit with a nonzero return > code in the pre-fetch phase if we want to prevent the port from > installing. For example, py-psyco does this if not running on an > Intel Mac. We would want to ignore these errors in the post-commit > hook. > > There's an additional problem of ports that error out based on > platform and don't do so in a platform selector (so there's no > variant we could select to overcome it). For example, the wine port > exits in pre-fetch if you're not running on an Intel Mac, since wine > needs an Intel processor. You may tell me this is fine because the > Mac OS Forge server runs on Intel, but then you have the same > problem with the oracle-instantclient port, which exits if you're > not running on PowerPC, since the oracle instantclient currently > needs a PowerPC. > > This sort of thing is why I wanted a special phase. There seems to be a lot of baggage in using fetch (platforms, variants, moving the files into a different namespace). I thought it would be easier to just add a phase that could parse a Portfile and figure out all possible distfiles and their checksums. If the multiple "port fetch" route is in fact easier, than I'll just need someone to work with to make sure the server catches all of these cases. (And yes, they are Intel, so something needs to be figured out for the PPC-only ports). -Bill ---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist at 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/20080225/8eabf539/attachment-0001.bin From jkh at apple.com Mon Feb 25 12:27:42 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Mon, 25 Feb 2008 12:27:42 -0800 Subject: MacPorts caching of distfiles [was Re: ntfs-3g 1.1120 source missing] In-Reply-To: <47C25224.8000904@macports.org> References: <6352d4ea0802211840y64fc460aoaa653fa1dfb6cfad@mail.gmail.com> <6352d4ea0802221123j18d4146h8b299f39fac10369@mail.gmail.com> <73ED446F-4577-437C-AE65-56B3D5D3899B@macports.org> <2AFC2157-A71E-4BA6-9C0E-00EEC697EF06@apple.com> <1A3478EC-45B1-4AA6-9141-880E61A07F39@apple.com> <47BF8EF3.4040804@macports.org> <1D834EBD-2515-4102-82FE-5313FF93C850@apple.com> <001FB3D7-0F93-407B-8474-4FD0F4635867@apple.com> <3E67C4F9-C335-4FAA-A4D7-BEE535043E70@apple.com> <3AA7B26F-F19B-4753-865F-6D4018F2775F@apple.com> <56880928-47D1-4573-9665-3F7D6FA86EB6@apple.com> <47C23A2A.5090101@macports.org> <47C25224.8000904@macports.org> Message-ID: <20D1C989-7CF9-4702-990F-E4D105C3125C@apple.com> On Feb 24, 2008, at 9:29 PM, Rainer M?ller wrote: > Jordan K. Hubbard wrote: >>> All distfiles in one single directory? I am against that at all! >> Why? Collisions? If so, please name the collisions in question, >> because I cannot find any. > > Maybe not yet, but maybe they will come in later? Why not be > collisions aware? Because given the $portname-$portversion naming of 99% of the distfiles (and the unique names of the 1% that are left), I just don't see collisions as a problem. I don't see it as a problem with the FreeBSD ports collection either, and they're almost 3X bigger than we are. >> If you add indirection to this then you lose the ability to have a >> global URL path that points to a mirror (either that or you need >> to add extra logic to the MacPorts fetch code). > > Why are you against adding more logic to the fetch code? Because it's always "someone" who gets to add it and that someone hasn't volunteered yet. If you're volunteering, then I withdraw most of my objection. > And have one big cluttered directory without any links which file > belongs to which port? With the distname approach, it adapts the > layout of /opt/local/var/macports/distfiles where distfiles are > currently stored locally. I guess this just doesn't bother me as much as it evidently bothers you. I like the notion of a single URL which points to all the distfiles. Again, however, if you're volunteering to do the work in MacPorts then you're supporting your proposal in the only way that really counts and I'm happy to withdraw my objection. - Jordan From raimue at macports.org Mon Feb 25 13:34:39 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 25 Feb 2008 22:34:39 +0100 Subject: MacPorts caching of distfiles [was Re: ntfs-3g 1.1120 source missing] In-Reply-To: <20D1C989-7CF9-4702-990F-E4D105C3125C@apple.com> References: <6352d4ea0802211840y64fc460aoaa653fa1dfb6cfad@mail.gmail.com> <6352d4ea0802221123j18d4146h8b299f39fac10369@mail.gmail.com> <73ED446F-4577-437C-AE65-56B3D5D3899B@macports.org> <2AFC2157-A71E-4BA6-9C0E-00EEC697EF06@apple.com> <1A3478EC-45B1-4AA6-9141-880E61A07F39@apple.com> <47BF8EF3.4040804@macports.org> <1D834EBD-2515-4102-82FE-5313FF93C850@apple.com> <001FB3D7-0F93-407B-8474-4FD0F4635867@apple.com> <3E67C4F9-C335-4FAA-A4D7-BEE535043E70@apple.com> <3AA7B26F-F19B-4753-865F-6D4018F2775F@apple.com> <56880928-47D1-4573-9665-3F7D6FA86EB6@apple.com> <47C23A2A.5090101@macports.org> <47C25224.8000904@macports.org> <20D1C989-7CF9-4702-990F-E4D105C3125C@apple.com> Message-ID: <47C3346F.9070201@macports.org> Jordan K. Hubbard wrote: > Because given the $portname-$portversion naming of 99% of the > distfiles (and the unique names of the 1% that are left), I just don't > see collisions as a problem. I don't see it as a problem with the > FreeBSD ports collection either, and they're almost 3X bigger than we > are. I didn't know they are using such a flat namespace. >> Why are you against adding more logic to the fetch code? > > Because it's always "someone" who gets to add it and that someone > hasn't volunteered yet. If you're volunteering, then I withdraw most > of my objection. > [...] > I guess this just doesn't bother me as much as it evidently bothers > you. I like the notion of a single URL which points to all the > distfiles. Again, however, if you're volunteering to do the work in > MacPorts then you're supporting your proposal in the only way that > really counts and I'm happy to withdraw my objection. I didn't want to volunteer until we got to a conclusion. But of course I would volunteer to improve our fetch code to include this http://distfiles.macports.org// scheme. The fetch code is not the difficult part for this, the hard part is to get the fetching done for every platform/variant. Rainer From landonf at macports.org Mon Feb 25 15:11:11 2008 From: landonf at macports.org (Landon Fuller) Date: Mon, 25 Feb 2008 15:11:11 -0800 Subject: MacPorts caching of distfiles [was Re: ntfs-3g 1.1120 source missing] In-Reply-To: <47C3346F.9070201@macports.org> References: <6352d4ea0802211840y64fc460aoaa653fa1dfb6cfad@mail.gmail.com> <6352d4ea0802221123j18d4146h8b299f39fac10369@mail.gmail.com> <73ED446F-4577-437C-AE65-56B3D5D3899B@macports.org> <2AFC2157-A71E-4BA6-9C0E-00EEC697EF06@apple.com> <1A3478EC-45B1-4AA6-9141-880E61A07F39@apple.com> <47BF8EF3.4040804@macports.org> <1D834EBD-2515-4102-82FE-5313FF93C850@apple.com> <001FB3D7-0F93-407B-8474-4FD0F4635867@apple.com> <3E67C4F9-C335-4FAA-A4D7-BEE535043E70@apple.com> <3AA7B26F-F19B-4753-865F-6D4018F2775F@apple.com> <56880928-47D1-4573-9665-3F7D6FA86EB6@apple.com> <47C23A2A.5090101@macports.org> <47C25224.8000904@macports.org> <20D1C989-7CF9-4702-990F-E4D105C3125C@apple.com> <47C3346F.9070201@macports.org> Message-ID: On Feb 25, 2008, at 1:34 PM, Rainer M?ller wrote: > > I didn't know they are using such a flat namespace. They're not -- When there are distfile collisions (and there are), they use DIST_SUBDIR to partition a particular port's distfiles. MacPorts by default simply places all distfiles in a port-specific subdirectory, since only port names are required to not conflict. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080225/2680581d/attachment.bin From ebgssth at gmail.com Tue Feb 26 06:29:50 2008 From: ebgssth at gmail.com (js) Date: Tue, 26 Feb 2008 23:29:50 +0900 Subject: Warnings when I visit http://www.macports.org/ in Safari v.1.3.2 In-Reply-To: References: <05C24679-CA5A-40C4-BB37-350E401AE7F0@macports.org> Message-ID: The problem is Safari 1.3 is processing the page as an XML document, even though, just as you pointed out, it's really a XHTML. The server seems returning the right HTTP header, "Content-Type: application/xhtml+xml; charset=utf-8", so I think it's actually a Safari's problem. Converting the entities with its applicable characters or numeric entities would fix this problem. On 2/25/08, Juan Manuel Palacios wrote: > > On Feb 23, 2008, at 7:17 AM, Ryan Schmidt wrote: > > > Sounds like a bug. Though it may surprise some people to learn it, > > "nbsp" etc. are not valid entities in XML. Please file a ticket in > > our issue tracker so we can correct this. > > > > > > If I'm not mistaken, they are in XHTML, as added by the DTD's: > > http://www.w3.org/TR/xhtml-modularization/dtd_module_defs.html#a_module_XHTML_Latin_1_Character_Entities > (again, if I'm not mistaken, that document applies to XHTML 1.1, which > is what I used for the website) > > But, of course, I could be reading that wrong, since you know much > more about the subject than me ;-) In any case, would using the > unicode code points fix the problems? > > Regards,... > > > -jmpp > > > > > > > On Feb 22, 2008, at 23:07, js wrote: > > > >> Hi, > >> > >> when I viist http://www.macports.org/ with Safari v.1.3.2, > >> I always see the warnings saying > >> > >> > >> This page contains the following errors: > >> error on line 41 at column 459: Entity 'nbsp' not defined > >> error on line 92 at column 45: Entity 'ldquo' not defined > >> error on line 113 at column 211: Entity 'ldquo' not defined > >> error on line 125 at column 319: Entity 'ldquo' not defined > >> > >> Below is a rendering of the page up to the first error. > >> > >> > >> The page was itself apparently rendered well. > >> > >> Is this a problem no a bit old Safari? (seems safari process the > >> document as xml?) > >> > >> In my opinion, if MacPorts is still supporting OS S 10.3, > >> the main page should be ready for Safari v.1.3.2, the latest Safari > >> for OS X 10.3. > >> > >> Any comments or suggestions? > > > _______________________________________________ > > macports-dev mailing list > > macports-dev at lists.macosforge.org > > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > From raimue at macports.org Tue Feb 26 08:10:57 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue, 26 Feb 2008 17:10:57 +0100 Subject: Warnings when I visit http://www.macports.org/ in Safari v.1.3.2 In-Reply-To: References: <05C24679-CA5A-40C4-BB37-350E401AE7F0@macports.org> Message-ID: <47C43A11.50706@macports.org> js wrote: > The problem is Safari 1.3 is processing the page as an XML document, > even though, just as you pointed out, it's really a XHTML. > The server seems returning the right HTTP header, > "Content-Type: application/xhtml+xml; charset=utf-8", > so I think it's actually a Safari's problem. This may be related to http://trac.macosforge.org/projects/macports/ticket/14062 Rainer From ebgssth at gmail.com Tue Feb 26 09:03:47 2008 From: ebgssth at gmail.com (js) Date: Wed, 27 Feb 2008 02:03:47 +0900 Subject: Warnings when I visit http://www.macports.org/ in Safari v.1.3.2 In-Reply-To: <47C43A11.50706@macports.org> References: <05C24679-CA5A-40C4-BB37-350E401AE7F0@macports.org> <47C43A11.50706@macports.org> Message-ID: http://www.456bereastreet.com/archive/200410/safari_and_xhtml/ On Wed, Feb 27, 2008 at 1:10 AM, Rainer M?ller wrote: > js wrote: > > The problem is Safari 1.3 is processing the page as an XML document, > > even though, just as you pointed out, it's really a XHTML. > > The server seems returning the right HTTP header, > > "Content-Type: application/xhtml+xml; charset=utf-8", > > so I think it's actually a Safari's problem. > > This may be related to > http://trac.macosforge.org/projects/macports/ticket/14062 > > Rainer > From derek at chocolate-fish.com Tue Feb 26 12:46:45 2008 From: derek at chocolate-fish.com (Derek Harland) Date: Wed, 27 Feb 2008 09:46:45 +1300 Subject: Tickets awaiting commit: 14259, 14260, 14261, 14316 In-Reply-To: References: Message-ID: <40B714F9-D5E3-4959-9758-4C35DEFDB846@chocolate-fish.com> Is there any hope of someone committing these tickets? They all relate to python and are new ports or upgrades to ports that are currently nomaintainer. I don't have a commit bit or I would do it myself instead of bothering you guys! derek. From ryandesign at macports.org Tue Feb 26 16:21:56 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 26 Feb 2008 18:21:56 -0600 Subject: Warnings when I visit http://www.macports.org/ in Safari v.1.3.2 In-Reply-To: References: <05C24679-CA5A-40C4-BB37-350E401AE7F0@macports.org> <47C43A11.50706@macports.org> Message-ID: <0FDCDD14-EBD2-4443-9964-781FFBB033B1@macports.org> On Feb 26, 2008, at 11:03, js wrote: > On Wed, Feb 27, 2008 at 1:10 AM, Rainer M?ller wrote: > >> js wrote: >> >>> On 2/25/08, Juan Manuel Palacios wrote: >>> >>>> On Feb 23, 2008, at 7:17 AM, Ryan Schmidt wrote: >>>> >>>>> Sounds like a bug. Though it may surprise some people to learn it, >>>>> "nbsp" etc. are not valid entities in XML. Please file a ticket in >>>>> our issue tracker so we can correct this. >>>> >>>> If I'm not mistaken, they are in XHTML, as added by the >>>> DTD's: >>>> >>>> http://www.w3.org/TR/xhtml-modularization/ >>>> dtd_module_defs.html#a_module_XHTML_Latin_1_Character_Entities >>>> (again, if I'm not mistaken, that document applies to XHTML >>>> 1.1, which >>>> is what I used for the website) >>>> >>>> But, of course, I could be reading that wrong, since you >>>> know much >>>> more about the subject than me ;-) In any case, would using the >>>> unicode code points fix the problems? >>> >>> The problem is Safari 1.3 is processing the page as an XML document, >>> even though, just as you pointed out, it's really a XHTML. >>> The server seems returning the right HTTP header, >>> "Content-Type: application/xhtml+xml; charset=utf-8", >>> so I think it's actually a Safari's problem. >> >> This may be related to >> http://trac.macosforge.org/projects/macports/ticket/14062 > > http://www.456bereastreet.com/archive/200410/safari_and_xhtml/ Sorry, Juan Manuel; you're right, I was thinking of XML, where those entities aren't defined. Looks like they are defined in XHTML, but Safari 1.x has a bug. I am moving this week, but next week I will have access to a Power Mac G3 on which I can install Panther and try to tackle this, if nobody else has by then. From ryandesign at macports.org Tue Feb 26 19:29:03 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 26 Feb 2008 21:29:03 -0600 Subject: MacPorts caching of distfiles [was Re: ntfs-3g 1.1120 source missing] In-Reply-To: <47C3346F.9070201@macports.org> References: <6352d4ea0802211840y64fc460aoaa653fa1dfb6cfad@mail.gmail.com> <6352d4ea0802221123j18d4146h8b299f39fac10369@mail.gmail.com> <73ED446F-4577-437C-AE65-56B3D5D3899B@macports.org> <2AFC2157-A71E-4BA6-9C0E-00EEC697EF06@apple.com> <1A3478EC-45B1-4AA6-9141-880E61A07F39@apple.com> <47BF8EF3.4040804@macports.org> <1D834EBD-2515-4102-82FE-5313FF93C850@apple.com> <001FB3D7-0F93-407B-8474-4FD0F4635867@apple.com> <3E67C4F9-C335-4FAA-A4D7-BEE535043E70@apple.com> <3AA7B26F-F19B-4753-865F-6D4018F2775F@apple.com> <56880928-47D1-4573-9665-3F7D6FA86EB6@apple.com> <47C23A2A.5090101@macports.org> <47C25224.8000904@macports.org> <20D1C989-7CF9-4702-990F-E4D105C3125C@apple.com> <47C3346F.9070201@macports.org> Message-ID: <7DF4911F-D646-4ECC-A6B8-13D588EF466E@macports.org> On Feb 25, 2008, at 15:34, Rainer M?ller wrote: > Jordan K. Hubbard wrote: > >> Because given the $portname-$portversion naming of 99% of the >> distfiles (and the unique names of the 1% that are left), I just >> don't >> see collisions as a problem. I don't see it as a problem with the >> FreeBSD ports collection either, and they're almost 3X bigger than we >> are. > > I didn't know they are using such a flat namespace. I've looked for old distfiles on such mirrors before, and it's a PITA to browse directories of thousands of distfiles, especially when that server is on the other side of the world on apparently a 28.8 modem connection and it takes 42 minutes to download just the HTML index. >>> Why are you against adding more logic to the fetch code? >> >> Because it's always "someone" who gets to add it and that someone >> hasn't volunteered yet. If you're volunteering, then I withdraw >> most >> of my objection. >> > [...] >> I guess this just doesn't bother me as much as it evidently bothers >> you. I like the notion of a single URL which points to all the >> distfiles. Again, however, if you're volunteering to do the work in >> MacPorts then you're supporting your proposal in the only way that >> really counts and I'm happy to withdraw my objection. > > I didn't want to volunteer until we got to a conclusion. But of > course I > would volunteer to improve our fetch code to include this > http://distfiles.macports.org// scheme. I would be in favor of having the URL space of distfiles.macports.org match the distfiles directory exactly. That would be http://distfiles.macports.org// It should not be difficult to modify the fetch phase to download files from such a URL. This would accommodate all distname collisions that the port author has made accommodation for in the portfile, which could be sufficient. This also makes it very easy to set up http://distfiles.macports.org/ -- just point it at the server's distfiles directory and you're done. > The fetch code is not the difficult part for this, the hard part is to > get the fetching done for every platform/variant. Fetching for every platform and variant is fairly straightforward as I explained in my lengthy earlier email on macports-dev (which is where this conversation should again be exclusively taking place). Simply fetch once for the port itself, then fetch again for each variant reported by "port variants", e.g.: port fetch smlnj port fetch smlnj +universal port fetch smlnj +powerpc port fetch smlnj +i386 What I'm not sure yet how to solve is the portfiles that fetch different files based on something other than a platform or variant selector. From dbruce at tampabay.rr.com Wed Feb 27 10:42:50 2008 From: dbruce at tampabay.rr.com (David Bruce) Date: Wed, 27 Feb 2008 13:42:50 -0500 Subject: Question regarding lib dependencies, esp gettext Message-ID: <200802271342.50331.dbruce@tampabay.rr.com> Hi, I recently contributed a port for tuxmath. It uses gettext and iconv for i18n, as well as SDL and friends. The currently listed dependencies are as follows: depends_lib port:libsdl \ port:libsdl_image \ port:libsdl_mixer \ port:libsdl_ttf \ port:gettext I'm wondering if I need to list gettext - it is not needed for "./configure; make; make install" for my package. Gettext is needed to run a "make dist" on tuxmath, but that isn't part of the MacPorts install process, so I don't think gettext is needed as either a "depends_lib" or "depends_build". At runtime, tuxmath does need both gettext and iconv, but they seem to be included with Leopard itself. However, I can't say for sure if they were present before I installed XCode. I take it that Portfiles do not need to list standard system libraries as dependencies - do gettext and iconv fall into this category? If so, I plan to just eliminate gettext from my list of dependencies. Thanks, -- David Bruce From ryandesign at macports.org Wed Feb 27 11:16:02 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 27 Feb 2008 13:16:02 -0600 Subject: Question regarding lib dependencies, esp gettext In-Reply-To: <200802271342.50331.dbruce@tampabay.rr.com> References: <200802271342.50331.dbruce@tampabay.rr.com> Message-ID: <99912C96-A7FA-4424-B273-065B5B74B642@macports.org> On Feb 27, 2008, at 12:42, David Bruce wrote: > I recently contributed a port for tuxmath. It uses gettext and > iconv for > i18n, as well as SDL and friends. The currently listed > dependencies are as > follows: > > depends_lib port:libsdl \ > port:libsdl_image \ > port:libsdl_mixer \ > port:libsdl_ttf \ > port:gettext > > I'm wondering if I need to list gettext - it is not needed for "./ > configure; > make; make install" for my package. Gettext is needed to run a > "make dist" > on tuxmath, but that isn't part of the MacPorts install process, so > I don't > think gettext is needed as either a "depends_lib" or "depends_build". > > At runtime, tuxmath does need both gettext and iconv, but they seem > to be > included with Leopard itself. However, I can't say for sure if > they were > present before I installed XCode. > > I take it that Portfiles do not need to list standard system > libraries as > dependencies - do gettext and iconv fall into this category? If > so, I plan > to just eliminate gettext from my list of dependencies. It is MacPorts policy to use its own software, not system software, wherever possible. See the FAQ: http://trac.macosforge.org/projects/macports/wiki/ FAQ#WhyisMacPortsusingitsownlibraries I just installed tuxmath 1.6.1_1 and it does indeed link with gettext and libiconv as libraries: $ otool -L /opt/local/bin/tuxmath /opt/local/bin/tuxmath: /opt/local/lib/libintl.8.dylib (compatibility version 9.0.0, current version 9.2.0) /opt/local/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.9) /System/Library/Frameworks/CoreFoundation.framework/Versions/ A/CoreFoundation (compatibility version 150.0.0, current version 368.32.0) /opt/local/lib/libSDL-1.2.0.dylib (compatibility version 12.0.0, current version 12.2.0) /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 11.0.0) /opt/local/lib/libSDL_image-1.2.0.dylib (compatibility version 2.0.0, current version 2.5.0) /opt/local/lib/libSDL_mixer-1.2.0.dylib (compatibility version 3.0.0, current version 3.6.0) /opt/local/lib/libSDL_ttf-2.0.0.dylib (compatibility version 7.0.0, current version 7.3.0) $ (You see libiconv.2.dylib, and gettext is libintl.8.dylib.) Therefore both port:libiconv and port:gettext should be listed as library dependencies of tuxmath. (Though gettext itself depends on libiconv, so you only need to list libiconv as a dependency of tuxmath if tuxmath uses libiconv independently of gettext. I'm not sure how to determine whether this is the case, other than asking the tuxmath developers or delving into the tuxmath source code.) From dbruce at tampabay.rr.com Wed Feb 27 11:46:06 2008 From: dbruce at tampabay.rr.com (David Bruce) Date: Wed, 27 Feb 2008 14:46:06 -0500 Subject: Question regarding lib dependencies, esp gettext In-Reply-To: <99912C96-A7FA-4424-B273-065B5B74B642@macports.org> References: <200802271342.50331.dbruce@tampabay.rr.com> <99912C96-A7FA-4424-B273-065B5B74B642@macports.org> Message-ID: <200802271446.06886.dbruce@tampabay.rr.com> Hi Ryan, On Wednesday 27 February 2008 02:16:02 pm Ryan Schmidt wrote: > It is MacPorts policy to use its own software, not system software, > wherever possible. See the FAQ: > > http://trac.macosforge.org/projects/macports/wiki/ > FAQ#WhyisMacPortsusingitsownlibraries > Therefore both port:libiconv and port:gettext should be listed as > library dependencies of tuxmath. Thanks - so port:gettext will stay. > (Though gettext itself depends on > libiconv, so you only need to list libiconv as a dependency of > tuxmath if tuxmath uses libiconv independently of gettext. I'm not > sure how to determine whether this is the case, other than asking the > tuxmath developers or delving into the tuxmath source code.) That's easy, seeing as how I am also the upstream developer ;) Tuxmath does not currently directly call any function from libiconv, but may in the future, so I'll add port:libiconv to be safe. Thanks, -- David Bruce From ram at macports.org Wed Feb 27 11:41:30 2008 From: ram at macports.org (Adam Mercer) Date: Wed, 27 Feb 2008 14:41:30 -0500 Subject: livecheck not finding latest version Message-ID: <799406d60802271141q5d209bd8y70bb47b26e8808c9@mail.gmail.com> Hi I'm trying to get livecheck working for all my ports and am running into a strange problem for bzr-rebase. I have the following in the Portfile: livecheck.check regex livecheck.url ${master_sites} livecheck.regex ${name}-(\[0-9\]+\.\[0-9\]+).tar.gz the specified ${master_sites} points to the download location (http://samba.org/~jelmer/bzr) whenever I run livecheck I get the following displayed [ram at skymoo bzr-rebase]$ sudo port livecheck bzr-rebase seems to have been updated (port version: 0.3, new version: 0.2) [ram at skymoo bzr-rebase]$ Any ideas why livecheck is saying that 0.2 is newer than the ports 0.3, and how I can fix this? Is there a problem with my regular expression? Cheers Adam From afb at macports.org Wed Feb 27 11:55:08 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Wed, 27 Feb 2008 20:55:08 +0100 Subject: livecheck not finding latest version In-Reply-To: <799406d60802271141q5d209bd8y70bb47b26e8808c9@mail.gmail.com> References: <799406d60802271141q5d209bd8y70bb47b26e8808c9@mail.gmail.com> Message-ID: <8D34450C-DB62-40DD-A9D4-D006C936BFFC@macports.org> Adam Mercer wrote: > Any ideas why livecheck is saying that 0.2 is newer than the ports > 0.3, and how I can fix this? Is there a problem with my regular > expression? That's probably because livecheck doesn't check to see if the new version is actually *newer*, it only checks if it changed... if {$updated_version != ${livecheck.version}} { set updated 1 } else { set updated 0 } Most likely, that's a bug and it should use the regular compare. (much like the display functions that weren't sorting correctly) --anders From raimue at macports.org Wed Feb 27 12:19:41 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 27 Feb 2008 21:19:41 +0100 Subject: livecheck not finding latest version In-Reply-To: <8D34450C-DB62-40DD-A9D4-D006C936BFFC@macports.org> References: <799406d60802271141q5d209bd8y70bb47b26e8808c9@mail.gmail.com> <8D34450C-DB62-40DD-A9D4-D006C936BFFC@macports.org> Message-ID: <47C5C5DD.4000607@macports.org> Anders F Bj?rklund wrote: > That's probably because livecheck doesn't check to see if the > new version is actually *newer*, it only checks if it changed... > > if {$updated_version != ${livecheck.version}} { > set updated 1 > } else { > set updated 0 > } > > Most likely, that's a bug and it should use the regular compare. > (much like the display functions that weren't sorting correctly) That was a bug I already fixed in trunk in r34331. It checked for the first match on the site only, now it extracts all matches and takes the highest version (using rpm-vercomp). Rainer From ryandesign at macports.org Wed Feb 27 13:35:54 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 27 Feb 2008 15:35:54 -0600 Subject: [34530] trunk/dports/net/apan/Portfile In-Reply-To: <20080227185224.26820143B835@beta.macosforge.org> References: <20080227185224.26820143B835@beta.macosforge.org> Message-ID: <4F30B13C-9FDE-4FE7-AA7B-EDDEB8ED30D4@macports.org> On Feb 27, 2008, at 12:52, reiffert at macports.org wrote: > Log Message: > ----------- > lint happy [snip] > -maintainers julien.touche at touche.fr.st > -description apan plugin for nagios > +maintainers openmaintainer > +description apan plugin for nagios Did you also intend to remove Julien Touche as maintainer? If so, it should say "nomaintainer" and not "openmaintainer". From rsync at reifferscheid.org Wed Feb 27 13:39:00 2008 From: rsync at reifferscheid.org (Thomas Reifferscheid) Date: Wed, 27 Feb 2008 22:39:00 +0100 Subject: [34530] trunk/dports/net/apan/Portfile In-Reply-To: <4F30B13C-9FDE-4FE7-AA7B-EDDEB8ED30D4@macports.org> References: <20080227185224.26820143B835@beta.macosforge.org> <4F30B13C-9FDE-4FE7-AA7B-EDDEB8ED30D4@macports.org> Message-ID: <47C5D874.8000500@reifferscheid.org> As the ticket is several years old, I dont want to proove Julien Touche still existing. I change it to nomaintainer then. Ryan Schmidt wrote: [...] > Did you also intend to remove Julien Touche as maintainer? If so, it > should say "nomaintainer" and not "openmaintainer". > > From ram at macports.org Wed Feb 27 13:47:09 2008 From: ram at macports.org (Adam Mercer) Date: Wed, 27 Feb 2008 16:47:09 -0500 Subject: livecheck not finding latest version In-Reply-To: <47C5C5DD.4000607@macports.org> References: <799406d60802271141q5d209bd8y70bb47b26e8808c9@mail.gmail.com> <8D34450C-DB62-40DD-A9D4-D006C936BFFC@macports.org> <47C5C5DD.4000607@macports.org> Message-ID: <799406d60802271347q2fb72757xc9fac38d3b554a8a@mail.gmail.com> On Wed, Feb 27, 2008 at 3:19 PM, Rainer M?ller wrote: > That was a bug I already fixed in trunk in r34331. > > It checked for the first match on the site only, now it extracts all > matches and takes the highest version (using rpm-vercomp). Thanks, it works as expected using base from trunk. Cheers Adam From ryandesign at macports.org Wed Feb 27 14:01:58 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 27 Feb 2008 16:01:58 -0600 Subject: [34530] trunk/dports/net/apan/Portfile In-Reply-To: <47C5D837.3070608@macports.org> References: <20080227185224.26820143B835@beta.macosforge.org> <4F30B13C-9FDE-4FE7-AA7B-EDDEB8ED30D4@macports.org> <47C5D837.3070608@macports.org> Message-ID: Then you should clear his address from all the ports he maintains. On Feb 27, 2008, at 15:37, Thomas Reifferscheid wrote: > As the ticket is several years old, I dont want to proove Julien > Touche > still existing. I change it to nomaintainer then. > > > Ryan Schmidt wrote: > >> Did you also intend to remove Julien Touche as maintainer? If so, >> it should say "nomaintainer" and not "openmaintainer". From ryandesign at macports.org Wed Feb 27 14:05:46 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 27 Feb 2008 16:05:46 -0600 Subject: [34538] trunk/base/src/port1.0/portmain.tcl In-Reply-To: <20080227215141.81CB1143C56F@beta.macosforge.org> References: <20080227215141.81CB1143C56F@beta.macosforge.org> Message-ID: <1B73E275-77BE-4F45-8BAE-D34D8C7C8E04@macports.org> On Feb 27, 2008, at 15:51, afb at macports.org wrote: > +set macosx_version {} > +if {$os_platform == "darwin"} { > + # This will probably break when Apple changes versioning > + set macosx_version [expr 10.0 + ($os_major - 4) / 10.0] > +} I expect "sw_vers -productVersion" would always work... From afb at macports.org Wed Feb 27 14:18:39 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Wed, 27 Feb 2008 23:18:39 +0100 Subject: [34538] trunk/base/src/port1.0/portmain.tcl In-Reply-To: <1B73E275-77BE-4F45-8BAE-D34D8C7C8E04@macports.org> References: <20080227215141.81CB1143C56F@beta.macosforge.org> <1B73E275-77BE-4F45-8BAE-D34D8C7C8E04@macports.org> Message-ID: <7585D546-4D51-43F8-BB94-3F230E87AE9B@macports.org> Ryan Schmidt wrote: >> +set macosx_version {} >> +if {$os_platform == "darwin"} { >> + # This will probably break when Apple changes versioning >> + set macosx_version [expr 10.0 + ($os_major - 4) / 10.0] >> +} > > I expect "sw_vers -productVersion" would always work... Yeah, but after getting bashed for using system() calls I didn't really want to fork a call to it on each run ? --anders From raimue at macports.org Wed Feb 27 19:31:56 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 28 Feb 2008 04:31:56 +0100 Subject: livecheck not finding latest version In-Reply-To: <8D34450C-DB62-40DD-A9D4-D006C936BFFC@macports.org> References: <799406d60802271141q5d209bd8y70bb47b26e8808c9@mail.gmail.com> <8D34450C-DB62-40DD-A9D4-D006C936BFFC@macports.org> Message-ID: <47C62B2C.7020901@macports.org> Anders F Bj?rklund wrote: > That's probably because livecheck doesn't check to see if the > new version is actually *newer*, it only checks if it changed... > > if {$updated_version != ${livecheck.version}} { > set updated 1 > } else { > set updated 0 > } We could also use rpm-vercomp here, but you would never notice if the site being checked is not updated anymore (happens e.g. with freshmeat). So if the port version is newer than the version livecheck finds, we should at least issue a warning that livecheck needs to be tweaked. Rainer From ryandesign at macports.org Wed Feb 27 22:28:10 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 28 Feb 2008 00:28:10 -0600 Subject: [34521] trunk/dports/www/libwww/files In-Reply-To: <20080227130826.5195B143A984@beta.macosforge.org> References: <20080227130826.5195B143A984@beta.macosforge.org> Message-ID: On Feb 27, 2008, at 07:08, reiffert at macports.org wrote: > Revision: 34521 > http://trac.macosforge.org/projects/macports/changeset/34521 > Author: reiffert at macports.org > Date: 2008-02-27 05:08:25 -0800 (Wed, 27 Feb 2008) > > Log Message: > ----------- > Additional file to #12851 > > Added Paths: > ----------- > trunk/dports/www/libwww/files/patch-configure.diff > > Removed Paths: > ------------- > trunk/dports/www/libwww/files/patch-configure So you renamed patch-configure to patch-configure.diff (which fixes the lint warning, so thanks) and then made additional changes to the file... it would have been better to use "svn mv patch-configure patch-configure.diff" to rename the file, and then make the changes to patch-configure.diff, and then commit, in order to preserve the file's history. As it is now, patch-configure.diff springs into existence at revision 34521, which is misleading because in fact the patch originally appeared in r778, and someone looking at the patchfile today might well want to know when and why it was originally added. From ryandesign at macports.org Wed Feb 27 22:31:07 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 28 Feb 2008 00:31:07 -0600 Subject: [34499] trunk/dports/devel/bzr/Portfile In-Reply-To: <20080227032432.B49E71439272@beta.macosforge.org> References: <20080227032432.B49E71439272@beta.macosforge.org> Message-ID: <940A51D2-B405-45FA-AE59-16ACA7AE0DE0@macports.org> On Feb 26, 2008, at 21:24, ram at macports.org wrote: > +livecheck.check regex > +livecheck.url ${homepage} > +livecheck.regex "Bazaar (\[0-9\]+\.\[0-9\]+) was released" Note that "\." in a tcl string expressed in double quotes is translated by tcl to "." so if you really want the regex engine to see "\." you need to either write "\\." inside the double-quoted string, or use curly brackets as your regex string encloser and then don't use backslashes in front of special tcl characters. Either > livecheck.regex "Bazaar (\[0-9\]+\\.\[0-9\]+) was released" or > livecheck.regex {Bazaar ([0-9]+\.[0-9]+) was released} would be correct. From ebgssth at gmail.com Thu Feb 28 07:01:51 2008 From: ebgssth at gmail.com (js) Date: Fri, 29 Feb 2008 00:01:51 +0900 Subject: New HOWTO section in the wiki In-Reply-To: <47BA1D15.9050907@macports.org> References: <47BA1D15.9050907@macports.org> Message-ID: Nice. HOWTOs I'd like to see there are - How to upgrate outdated ports most effectively (port upgrade -fun ?) - How to uninstall MacPorts completely - How to start writing Portfile On Tue, Feb 19, 2008 at 9:04 AM, Rainer M?ller wrote: > Hi, > > I started a new HOWTO section in the wiki [1]. These HOWTOs should cover > tutorials and tips how specific things can be done using MacPorts. This > is meant to be an addition to the guide and should not contain topics > already covered by the guide. It is a place editable by everyone to > share tips and tricks. > > So far I just added two HOWTOs to demonstrate how they should look like. > If you have a good idea what such a HOWTO could cover, feel free to add > it to the list. And if you even want to help by writing a HOWTO/tutorial > yourself in order to make using MacPorts easier, there is a template > which you can use as a start. > > So far I added two HOWTOs, one explaining how to use ccache and another > how parallel building can be enabled. Of course you are free to edit > them e.g. to add further information. > > Also, there is a list what could also be written. Even if you don't have > time to write a HOWTO yourself, please make your mind what else could be > useful and add it to that list. > > Rainer > > [1] http://trac.macosforge.org/projects/macports/wiki/howto > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > From ram at macports.org Thu Feb 28 09:39:18 2008 From: ram at macports.org (Adam Mercer) Date: Thu, 28 Feb 2008 12:39:18 -0500 Subject: [34499] trunk/dports/devel/bzr/Portfile In-Reply-To: <940A51D2-B405-45FA-AE59-16ACA7AE0DE0@macports.org> References: <20080227032432.B49E71439272@beta.macosforge.org> <940A51D2-B405-45FA-AE59-16ACA7AE0DE0@macports.org> Message-ID: <799406d60802280939t63374b39w1f166c58a0409c4a@mail.gmail.com> On Thu, Feb 28, 2008 at 1:31 AM, Ryan Schmidt wrote: > On Feb 26, 2008, at 21:24, ram at macports.org wrote: > > > +livecheck.check regex > > +livecheck.url ${homepage} > > +livecheck.regex "Bazaar (\[0-9\]+\.\[0-9\]+) was released" > > Note that "\." in a tcl string expressed in double quotes is > translated by tcl to "." so if you really want the regex engine to > see "\." you need to either write "\\." inside the double-quoted > string, or use curly brackets as your regex string encloser and then > don't use backslashes in front of special tcl characters. > > Either > > > livecheck.regex "Bazaar (\[0-9\]+\\.\[0-9\]+) was released" > > or > > > livecheck.regex {Bazaar ([0-9]+\.[0-9]+) was released} > > would be correct. Thanks Ryan, thats very helpful. I always have problems with regular expressions. Cheers Adam From markd at macports.org Thu Feb 28 11:13:09 2008 From: markd at macports.org (markd at macports.org) Date: Thu, 28 Feb 2008 11:13:09 -0800 Subject: user instructions - was ... mysql5 + php5 + apache2 Message-ID: >> > The problem is that if you do miss these messages, then you can't >> > easily resurrect them other than installing the whole lot again. >> >> >> True-ish. Well really you only need to deactivate and active the port >> again, since ports print such messages in the post-activate phase. >> But users don't know that. You could also read the portfile source >> code, but that's not really a clean solution either. Any suggestions >> for how we could improve this situation? > >How about including some instructions like this in ports and >install it in /opt/local/share/someplace? > >README.macports or something like that. It would be cool if the ui_msgs could be spit out using a port command, say 'port foo msg' or some such. I use user_msg in Portfiles for extensive documentation, a Howto really, on configuring some ports. For example: http://trac.macports.org/projects/macports/browser/trunk/dports/net/nedi/Portfile Though not many do this, it can be a HUGE timesaver for users. But since comparatively few ports have extensive ui_msg's, perhaps it isn't worth the effort. And it would be a low priority for the MP coders since there are other more foundational things to do. And I think evaluating variables might present some problems too. I usually use 'port ed foo' to look at the ui_msg's in another window. Mark From wsiegrist at apple.com Thu Feb 28 13:17:44 2008 From: wsiegrist at apple.com (William Siegrist) Date: Thu, 28 Feb 2008 13:17:44 -0800 Subject: pgpool & pgpool-II Message-ID: <22FEF5C3-96AE-4CBE-8EC4-D4181EE246B1@apple.com> mww, the pgpool maintainer, is busy, so I'm sending this out for broader discussion... There is a port for pgpool, but there has been a rewrite of that project into what is being called pgpool-II. They create some of the same binaries, but since one is a rewrite of the other, should they be kept as separate ports? I believe pgpool-II has all of the features of pgpool and supersedes it, but maybe someone still wants pgpool around. I would like to use pgpool-II of course. I have a rudimentary Portfile which works for pgpool-II. So should I also come up with a patch for pgpool to separate out the binary directories so the two ports dont overwrite each other (similar to how postgresql is kept separate)? Or should I make a patch for pgpool's port which treats pgpool-II as the latest/current version and keep them as 1 port? -Bill ---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist at 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/20080228/1b1c3edc/attachment.bin From ryandesign at macports.org Thu Feb 28 20:57:39 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 28 Feb 2008 22:57:39 -0600 Subject: [34595] trunk/dports/math/gunits/Portfile In-Reply-To: <20080229013526.833A0144606C@beta.macosforge.org> References: <20080229013526.833A0144606C@beta.macosforge.org> Message-ID: On Feb 28, 2008, at 19:35, jmr at macports.org wrote: > +configure.cflags -I${prefix}/include > +configure.ldflags -I${prefix}/lib > configure.args --program-prefix=g \ > - --mandir=\\\${prefix}/share/man \ > - --infodir=\\\${prefix}/share/info > + --mandir=${prefix}/share/man \ > + --infodir=${prefix}/share/info This change caused two issues which I've described in the ticket: http://trac.macosforge.org/projects/macports/ticket/13441 From lutz.horn at fastmail.fm Thu Feb 28 23:52:16 2008 From: lutz.horn at fastmail.fm (Lutz Horn) Date: Fri, 29 Feb 2008 08:52:16 +0100 Subject: Syntax of Portifle keyword "ruby.setup" Message-ID: <1204271536.32204.1239776083@webmail.messagingengine.com> Hi all, I'd like to improve some of the Ruby related ports (ruby/rb-*). Since many Ruby tools and libraries are distributed as RubyGems (http://www.rubygems.org/) and fetched from the repository at RubyForge (http://rubyforge.org/), special Porfile keywords do apply. One keyword I find in man Portfiles is ruby.setup, an example being rb-sqlite3 (http://trac.macports.org/projects/macports/browser/trunk/dports/ruby/rb-sqlite3/Portfile): ruby.setup {sqlite3 sqlite3-ruby} 1.2.1 setup.rb \ {README LICENSE ChangeLog api doc} \ rubyforge:17096 Parts of this I understand: 1.2.1 is the current version of the sqlite3 gem, 17096 the file ID at RubyForge. What I don't understand and don't find in the MacPorts Guide is the meaning of the parts in curly braces. Can anybody point me to an explanation? In addition to this general problem I wonder about the Portfile for rb-rubygems (http://trac.macports.org/projects/macports/browser/trunk/dports/ruby/rb-rubygems/Portfile): ruby.setup rubygems 0.9.4 setup.rb {README doc examples gemspecs} \ rubyforge:20989 The file at RubyForge is an update gem that looks like it can be used to update an existing installtion of RubyGems to a newer version. This seems like a chicken and egg problem to me: how is it possible to use an update for a package manager (rubygems) if that package manager isn't already installed? Thanks for any input Lutz -- GnuPG Key: 1024D/6EBDA359 1999-09-20 Key fingerprint = 438D 31FC 9300 CED0 1CDE A19D CD0F 9CA2 6EBD A359 http://dev-random.dnsalias.net/0x6EBDA35.asc http://pgp.cs.uu.nl/stats/6EBDA359.html From ebgssth at gmail.com Fri Feb 29 03:36:18 2008 From: ebgssth at gmail.com (js) Date: Fri, 29 Feb 2008 20:36:18 +0900 Subject: How should MacPorts show users instruction messages (was: user instructions - was ... mysql5 + php5 + apache2) Message-ID: I don't think this is not worth the effort. if there were a way to provide instrictions, it would encourages developer to write more messages I suppose. On 2/29/08, markd at macports.org wrote: > >> > The problem is that if you do miss these messages, then you can't > >> > easily resurrect them other than installing the whole lot again. > >> > >> > >> True-ish. Well really you only need to deactivate and active the port > >> again, since ports print such messages in the post-activate phase. > >> But users don't know that. You could also read the portfile source > >> code, but that's not really a clean solution either. Any suggestions > >> for how we could improve this situation? > > > >How about including some instructions like this in ports and > >install it in /opt/local/share/someplace? > > > >README.macports or something like that. > > It would be cool if the ui_msgs could be spit out using a port command, > say 'port foo msg' or some such. I use user_msg in Portfiles for > extensive documentation, a Howto really, on configuring some ports. For > example: > http://trac.macports.org/projects/macports/browser/trunk/dports/net/nedi/Portfile > > Though not many do this, it can be a HUGE timesaver for users. But since > comparatively few ports have extensive ui_msg's, perhaps it isn't worth > the effort. And it would be a low priority for the MP coders since there > are other more foundational things to do. And I think evaluating > variables might present some problems too. I usually use 'port ed foo' to > look at the ui_msg's in another window. > > Mark > > From ebgssth at gmail.com Fri Feb 29 04:45:09 2008 From: ebgssth at gmail.com (js) Date: Fri, 29 Feb 2008 21:45:09 +0900 Subject: Trac ticket that need your attension Message-ID: The folllowing tickets has been unchanged more than 3 days. Please review/commit them. ipython http://trac.macosforge.org/projects/macports/ticket/14360 twisted http://trac.macosforge.org/projects/macports/ticket/14375 python_select http://trac.macosforge.org/projects/macports/ticket/14452 sqlalchemy http://trac.macosforge.org/projects/macports/ticket/14464 pypy http://trac.macosforge.org/projects/macports/ticket/14356 sqlalchemy-migrate http://trac.macosforge.org/projects/macports/ticket/14357 daemon http://trac.macosforge.org/projects/macports/ticket/14372 setuptools http://trac.macosforge.org/projects/macports/ticket/14341 py-yaml http://trac.macosforge.org/projects/macports/ticket/14373 From raimue at macports.org Fri Feb 29 05:34:33 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri, 29 Feb 2008 14:34:33 +0100 Subject: How should MacPorts show users instruction messages (was: user instructions - was ... mysql5 + php5 + apache2) In-Reply-To: References: Message-ID: <47C809E9.3030407@macports.org> js wrote: > I don't think this is not worth the effort. > if there were a way to provide instrictions, it would encourages > developer to write more messages I suppose. One option would be to simply hold back any message until all ports installed and output them afterwards. So all messages would be at the end of the log. Or, use some new target like print_message {}, but which would need to be stored in the registry after installation to be always available in the state as it was on install. For this rather long nedi help, I would prefer to put them into some file like /opt/local/share/doc/nedi/INSTALL.macports and just print a message that there is additional help in this file. Rainer From reiffert at macports.org Fri Feb 29 06:57:35 2008 From: reiffert at macports.org (Thomas Reifferscheid) Date: Fri, 29 Feb 2008 15:57:35 +0100 Subject: Macports open tickets Message-ID: <47C81D5F.9060109@macports.org> As some of you might allready know, there are some graphs showing the macports open tickets over time. You find the graphs here: http://student.physik.uni-mainz.de/~reiffert/macports/ Feel free to comment or improve. You'll find all the details on that site. Kind regards Thomas From ebgssth at gmail.com Fri Feb 29 07:08:10 2008 From: ebgssth at gmail.com (js) Date: Sat, 1 Mar 2008 00:08:10 +0900 Subject: How should MacPorts show users instruction messages (was: user instructions - was ... mysql5 + php5 + apache2) In-Reply-To: <47C809E9.3030407@macports.org> References: <47C809E9.3030407@macports.org> Message-ID: +1 On 2/29/08, Rainer M?ller wrote: > js wrote: > > I don't think this is not worth the effort. > > if there were a way to provide instrictions, it would encourages > > developer to write more messages I suppose. > > > One option would be to simply hold back any message until all ports > installed and output them afterwards. So all messages would be at the > end of the log. > > Or, use some new target like print_message {}, but which would need to > be stored in the registry after installation to be always available in > the state as it was on install. > > For this rather long nedi help, I would prefer to put them into some > file like /opt/local/share/doc/nedi/INSTALL.macports and just print a > message that there is additional help in this file. > > > Rainer > From ebgssth at gmail.com Fri Feb 29 07:20:54 2008 From: ebgssth at gmail.com (js) Date: Sat, 1 Mar 2008 00:20:54 +0900 Subject: py-twistedweb2 and py25-twisted-web2 uses different name convension Message-ID: Hi, I noticed that twisted for python2.4 and 2.5 uses different name convension. I opened new ticket http://trac.macosforge.org/projects/macports/ticket/14375 Shouldn' they use the same convension? From raimue at macports.org Fri Feb 29 07:24:09 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri, 29 Feb 2008 16:24:09 +0100 Subject: How should MacPorts show users instruction messages In-Reply-To: References: <47C809E9.3030407@macports.org> Message-ID: <47C82399.7000309@macports.org> js wrote: > +1 +1 for what? I just mentioned two possibilities how to solve this and we did not even gather additional ideas. This is not the time for voting yet. If you meant one particular idea, please use inline-replying to make that clear. Rainer From ebgssth at gmail.com Fri Feb 29 07:56:09 2008 From: ebgssth at gmail.com (js) Date: Sat, 1 Mar 2008 00:56:09 +0900 Subject: How should MacPorts show users instruction messages In-Reply-To: <47C82399.7000309@macports.org> References: <47C809E9.3030407@macports.org> <47C82399.7000309@macports.org> Message-ID: > For this rather long nedi help, I would prefer to put them into some > file like /opt/local/share/doc/nedi/INSTALL.macports and just print a > message that there is additional help in this file. I like this idea. On 3/1/08, Rainer M?ller wrote: > js wrote: > > +1 > > +1 for what? I just mentioned two possibilities how to solve this and we > did not even gather additional ideas. This is not the time for voting yet. > > If you meant one particular idea, please use inline-replying to make > that clear. > > > Rainer > From markd at macports.org Fri Feb 29 08:01:25 2008 From: markd at macports.org (markd at macports.org) Date: Fri, 29 Feb 2008 08:01:25 -0800 Subject: =?ISO-8859-1?Q?user=A0=A0=A0_?= instructions - was ... mysql5 + php5 + apache2 Message-ID: >> I don't think this is not worth the effort. >> if there were a way to provide instrictions, it would encourages >> developer to write more messages I suppose. Sure, but analogous to port developers making patches that they don't try to send to upstream developers is a problem, making our own docs has some pitfalls too since sometimes we are doing what the developers should have (when it isn't stuff that is MacPorts specific). And I'm a little more pessimistic that creating a infrastructure will spur people to write more hints and docs because it takes time, patience, and they need to be updated once created. But I'm in no way opposed to doing anything that helps; I probably do more doc writing than any other port author. I'm all for anything doc related that helps that we can agree on as long as it is efficient and sustainable. > >One option would be to simply hold back any message until all ports >installed and output them afterwards. So all messages would be at the >end of the log. > >Or, use some new target like print_message {}, but which would need to >be stored in the registry after installation to be always available in >the state as it was on install. I like these types of things. > >For this rather long nedi help, I would prefer to put them into some >file like /opt/local/share/doc/nedi/INSTALL.macports and just print a >message that there is additional help in this file. Yes, but if you want variables evaluated within the instructions, and I do, then you end up doing reinplace on keywords so you add another file to ${files} and require more coding and probably some errors in the process. So now you've got to debug the instructional phase. I prefer it either as it is (ui_msg) or by adding a command that would crank out and evaluate the ui_msg section on the fly after a port is installed. Mark From ryandesign at macports.org Fri Feb 29 12:28:34 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 29 Feb 2008 14:28:34 -0600 Subject: py-twistedweb2 and py25-twisted-web2 uses different name convension In-Reply-To: References: Message-ID: On Feb 29, 2008, at 09:20, js wrote: > I noticed that twisted for python2.4 and 2.5 uses different name > convension. > I opened new ticket http://trac.macosforge.org/projects/macports/ > ticket/14375 > > Shouldn' they use the same convension? Sure, it would make sense for the common parts of the port name to be the same. From eridius at macports.org Fri Feb 29 12:33:05 2008 From: eridius at macports.org (Kevin Ballard) Date: Fri, 29 Feb 2008 15:33:05 -0500 Subject: py-twistedweb2 and py25-twisted-web2 uses different name convension In-Reply-To: References: Message-ID: <1578ADF8-7075-4E12-8B26-7EF3931628CB@macports.org> The problem is this breaks the upgrade path. Anybody with py25-twisted- web2 will lose the ability to update their port if it gets renamed to py25-twistedweb2. They'll have to discover this problem on their own and uninstall py25-twisted-web2 and install py25-twistedweb2. The only workaround I can think of for this is to push a dummy update for py25-twisted-web2 that errors out on fetch with a message saying to uninstall and reinstall py25-twistedweb2, but that's ugly and unfriendly. -Kevin Ballard On Feb 29, 2008, at 3:28 PM, Ryan Schmidt wrote: > > On Feb 29, 2008, at 09:20, js wrote: > >> I noticed that twisted for python2.4 and 2.5 uses different name >> convension. >> I opened new ticket http://trac.macosforge.org/projects/macports/ticket/14375 >> >> Shouldn' they use the same convension? > > Sure, it would make sense for the common parts of the port name to > be the same. > > -- Kevin Ballard http://kevin.sb.org eridius at macports.org http://www.tildesoft.com From ryandesign at macports.org Fri Feb 29 13:07:06 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 29 Feb 2008 15:07:06 -0600 Subject: py-twistedweb2 and py25-twisted-web2 uses different name convension In-Reply-To: <1578ADF8-7075-4E12-8B26-7EF3931628CB@macports.org> References: <1578ADF8-7075-4E12-8B26-7EF3931628CB@macports.org> Message-ID: <081DE1AD-319D-4D10-BC09-EF36773A594F@macports.org> On Feb 29, 2008, at 14:33, Kevin Ballard wrote: > On Feb 29, 2008, at 3:28 PM, Ryan Schmidt wrote: > >> On Feb 29, 2008, at 09:20, js wrote: >> >>> I noticed that twisted for python2.4 and 2.5 uses different name >>> convension. >>> I opened new ticket http://trac.macosforge.org/projects/macports/ >>> ticket/14375 >>> >>> Shouldn' they use the same convension? >> >> Sure, it would make sense for the common parts of the port name to >> be the same. > > The problem is this breaks the upgrade path. Anybody with py25- > twisted- > web2 will lose the ability to update their port if it gets renamed to > py25-twistedweb2. They'll have to discover this problem on their own > and uninstall py25-twisted-web2 and install py25-twistedweb2. > > The only workaround I can think of for this is to push a dummy update > for py25-twisted-web2 that errors out on fetch with a message saying > to uninstall and reinstall py25-twistedweb2, but that's ugly and > unfriendly. Still wish we had the "superseded_by" feature in MacPorts base so it would be easier to rename a port: http://lists.macosforge.org/pipermail/macports-dev/2007-July/002219.html http://lists.macosforge.org/pipermail/macports-dev/2007-December/ 003767.html From jberry at macports.org Fri Feb 29 15:48:56 2008 From: jberry at macports.org (James Berry) Date: Fri, 29 Feb 2008 15:48:56 -0800 Subject: Google SoC 2008 Message-ID: <6F6895E0-FCFF-4272-AC84-AF172AE1F806@macports.org> I'm writing to attempt to gauge interest in whether and how MacPorts should participate in Google Summer of Code (GSoC) for 2008. See http://code.google.com/soc/2008/ . You might be inclined to address any of the following questions: - Do you feel MacPorts should participate in GSoC 2008? - Are there particular MacPorts projects you'd like to suggest? - Are you willing to be a GSoC mentor? - Would you be interested, as a student, in participating in a GSoC project for MacPorts? GSoC pays students a wage for the summer to work on open source projects, and also a stipend to the project for each student project. If interested, we need to move very quickly. As the Google GSoC FAQ says: "We'll begin accepting applications from open source mentoring organizations on Monday, March 3, 2008; we'll stop accepting organization applications on Wednesday, March 12th." Your feedback is welcome James From markd at macports.org Fri Feb 29 22:24:25 2008 From: markd at macports.org (markd at macports.org) Date: Fri, 29 Feb 2008 22:24:25 -0800 Subject: question about adding distfiles to svn Message-ID: I need to add a port to distfiles in the svn repo, but how do I do it without checking out the whole distfiles/ directory? Mark From blair at orcaware.com Fri Feb 29 22:49:24 2008 From: blair at orcaware.com (Blair Zajac) Date: Fri, 29 Feb 2008 22:49:24 -0800 Subject: question about adding distfiles to svn In-Reply-To: References: Message-ID: <47C8FC74.4030802@orcaware.com> markd at macports.org wrote: > I need to add a port to distfiles in the svn repo, but how do I do it > without checking out the whole distfiles/ directory? > > Mark Use $ svn co -N URL and you'll have an empty directory. Delete this wc after you're done with it, they're not completely supported until 1.5 Regards, Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies Subversion training, consulting and support http://www.orcaware.com/svn/ From raimue at macports.org Fri Feb 29 22:57:29 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 01 Mar 2008 07:57:29 +0100 Subject: question about adding distfiles to svn In-Reply-To: References: Message-ID: <47C8FE59.1090101@macports.org> markd at macports.org wrote: > I need to add a port to distfiles in the svn repo, but how do I do it > without checking out the whole distfiles/ directory? svn import $PATH $URL But this way you can only add one file at a time. Rainer