From afb at macports.org Thu Nov 1 03:57:31 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu Nov 1 03:56:59 2007 Subject: Leopard Major Bug Taxonomy Message-ID: <376b97141168f2a91cf6e29a4fe99559@macports.org> These two issues are causing several ports to fail: 1) the "opengl library" bug (e.g. #12997, #13075) => ld: cycle in dylib re-exports with /usr/X11/lib/libGL.dylib See http://wiki.finkproject.org/index.php/Fink:Packaging: Preparing_for_10.5#OpenGL_Bug for instance 2) the "extern inline" bug (e.g. #13006, 13094) => ld: duplicate symbol _g_bit_nth_lsf in foo.o and bar.o See http://bugzilla.gnome.org/show_bug.cgi?id=315437 and http://gcc.gnu.org/onlinedocs/gcc/Inline.html Hopefully the root cause will be fixed by Apple in for instance Mac OS X 10.5.1 and Xcode 3.0.1... Meanwhile various ports are trying some various workarounds around these issues, in order to run. --anders From rhwood at mac.com Thu Nov 1 12:56:10 2007 From: rhwood at mac.com (Randall Wood) Date: Thu Nov 1 12:55:30 2007 Subject: [30641] trunk/dports/www/squirrelmail/Portfile In-Reply-To: <20071101174553.2D35890F46B@cvs.opensource.apple.com> References: <20071101174553.2D35890F46B@cvs.opensource.apple.com> Message-ID: Per a recent discussion on this list, php is not an invalid category, despite whatever lint says. On 1 Nov 2007, at 13:45, source_changes@macosforge.org wrote: > Revision 30641 Author markd@macports.org Date 2007-11-01 10:45:52 > -0700 (Thu, 01 Nov 2007) Log MessageRemove invalid > category.Modified Paths > trunk/dports/www/squirrelmail/Portfile > Diff > Modified: trunk/dports/www/squirrelmail/Portfile (30640 => > 30641)--- trunk/dports/www/squirrelmail/Portfile 2007-11-01 > 17:43:19 UTC (rev 30640) +++ trunk/dports/www/squirrelmail/Portfile > 2007-11-01 17:45:52 UTC (rev 30641) @@ -4,7 +4,7 @@ name > squirrelmail version 1.4.10a -categories www mail php +categories > www mail maintainers nomaintainer description A webmail system > which accesses mail over IMAP > _______________________________________________ > macports-changes mailing list > macports-changes@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-changes Randall Wood rhwood@mac.com http://shyramblings.blogspot.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From ryandesign at macports.org Thu Nov 1 14:01:34 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Nov 1 14:03:21 2007 Subject: [30641] trunk/dports/www/squirrelmail/Portfile In-Reply-To: References: <20071101174553.2D35890F46B@cvs.opensource.apple.com> Message-ID: <1C120DC0-67D1-4012-815E-CC7735960FB4@macports.org> Right. So let's fix lint. What is the fix? My proposal was that lint should only check that the first listed category matches the directory the port is in. Is that acceptable? On Nov 1, 2007, at 14:56, Randall Wood wrote: > Per a recent discussion on this list, php is not an invalid > category, despite whatever lint says. > > On 1 Nov 2007, at 13:45, source_changes@macosforge.org wrote: > >> Revision: 30641 >> http://trac.macosforge.org/projects/macports/changeset/ >> 30641 >> Author: markd@macports.org >> Date: 2007-11-01 10:45:52 -0700 (Thu, 01 Nov 2007) >> >> Log Message: >> ----------- >> Remove invalid category. >> >> Modified Paths: >> -------------- >> trunk/dports/www/squirrelmail/Portfile >> >> Modified: trunk/dports/www/squirrelmail/Portfile >> =================================================================== >> --- trunk/dports/www/squirrelmail/Portfile 2007-11-01 17:43:19 UTC >> (rev 30640) >> +++ trunk/dports/www/squirrelmail/Portfile 2007-11-01 17:45:52 UTC >> (rev 30641) >> @@ -4,7 +4,7 @@ >> >> name squirrelmail >> version 1.4.10a >> -categories www mail php >> +categories www mail >> maintainers nomaintainer >> >> description A webmail system which accesses mail over IMAP From markd at macports.org Thu Nov 1 14:12:10 2007 From: markd at macports.org (markd@macports.org) Date: Thu Nov 1 14:10:48 2007 Subject: [30641] trunk/dports/www/squirrelmail/Portfile In-Reply-To: <1C120DC0-67D1-4012-815E-CC7735960FB4@macports.org> References: <1C120DC0-67D1-4012-815E-CC7735960FB4@macports.org> Message-ID: Ryan Schmidt writes: >Right. So let's fix lint. What is the fix? My proposal was that lint >should only check that the first listed category matches the >directory the port is in. Is that acceptable? Amen. Lint should be updated. Also, I reverted the change so the php virtual category is restored on squirrelmail. Mark From afb at macports.org Thu Nov 1 14:15:52 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu Nov 1 14:15:09 2007 Subject: [30641] trunk/dports/www/squirrelmail/Portfile In-Reply-To: <1C120DC0-67D1-4012-815E-CC7735960FB4@macports.org> References: <20071101174553.2D35890F46B@cvs.opensource.apple.com> <1C120DC0-67D1-4012-815E-CC7735960FB4@macports.org> Message-ID: <571c08400e03d6fcd5b8e0d5ef100884@macports.org> Ryan Schmidt wrote: > On Nov 1, 2007, at 14:56, Randall Wood wrote: > >> Per a recent discussion on this list, php is not an invalid category, >> despite whatever lint says. > Right. So let's fix lint. What is the fix? My proposal was that lint > should only check that the first listed category matches the directory > the port is in. Is that acceptable? Yes, the current category check in "lint" is broken. => It should only check the first/primary category. It's on my TODO, but if someone wants to fix it then by all means go straight ahead and do so... --anders From n.oxyde at gmail.com Fri Nov 2 05:31:26 2007 From: n.oxyde at gmail.com (N_Ox) Date: Fri Nov 2 05:30:42 2007 Subject: [30584] trunk/dports/databases/FreeTDS/Portfile In-Reply-To: <20071031203619.EF16A90CB3A@cvs.opensource.apple.com> References: <20071031203619.EF16A90CB3A@cvs.opensource.apple.com> Message-ID: Le 31 oct. 07 ? 21:36, source_changes@macosforge.org a ?crit : > Revision30584 > Author afb@macports.org > Date 2007-10-31 13:36:19 -0700 (Wed, 31 Oct 2007) > Log Messageglibtool fix for leopard (#13059) > Modified Paths > trunk/dports/databases/FreeTDS/Portfile > Diff Why repeat in each platform block the patchfiles list? Why is the versioned docdir renamed to a unversioned one? Regards, -- Anthony Ramine, the "Ports tree cleaning Maestro". From afb at macports.org Fri Nov 2 08:38:31 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Fri Nov 2 08:37:44 2007 Subject: [30584] trunk/dports/databases/FreeTDS/Portfile In-Reply-To: References: <20071031203619.EF16A90CB3A@cvs.opensource.apple.com> Message-ID: <7bcae46892d5f0716271d069a39446a4@macports.org> N_Ox wrote: >> Revision30584 >> Author afb@macports.org >> Date 2007-10-31 13:36:19 -0700 (Wed, 31 Oct 2007) >> Log Messageglibtool fix for leopard (#13059) >> Modified Paths >> trunk/dports/databases/FreeTDS/Portfile >> Diff > > Why repeat in each platform block the patchfiles list? > Why is the versioned docdir renamed to a unversioned one? No idea, sorry. (feel free to claim ownership and clean it up) --anders From bwaters at nrao.edu Fri Nov 2 14:05:55 2007 From: bwaters at nrao.edu (Boyd Waters) Date: Fri Nov 2 14:05:25 2007 Subject: [Pythonmac-SIG] Round 2 with Leopard+Python In-Reply-To: References: <6ce0ac130711020916pf348e27xc5543dbd49f5fce0@mail.gmail.com> <93611872-5B47-4791-A731-C62446E7160B@nrao.edu> Message-ID: <1C0061DC-C15E-4AE8-8D17-451C3A9ECA62@nrao.edu> FYI: On Leopard, "sudo" filters environment variables, including PYTHONPATH. I have not tested this with MacPorts yet; I've been running MacPorts as a "normal" user without sudo. Will this matter for MacPorts? > Running "sudo -V" as root shows sudo's settings; part of that is > environment variables that it will not pass on or that it will > check for dangerous content. On Nov 2, 2007, at 2:59 PM, Boyd Waters wrote: > One work-around is to add this line to /etc/sudoers: > > Defaults env_keep += "PYTHONPATH" > > > > But that would involve editing a file in /etc as root. > Straightforward enough, but likely to get overwritten and what if > the user screws this up? > > > So Plan B - > > what if you added something in a .pth file in /Library/Python/2.5/ > site-packages that re-orders the sys.path? > > Wouldn't that always work? > > > > > On Nov 2, 2007, at 2:49 PM, Boyd Waters wrote: > >> >> On Nov 2, 2007, at 10:16 AM, Brian Granger wrote: >> >>> First, if you have set PYTHONPATH to point >>> sys.path at the site-packages in /Library, this setting will be lost >>> when you do: >>> >>> sudo python setup.py install >> >> >> Ouch, another good one... >> >> This is almost certainly not a bug, but rather a security feature. >> >>> The administrator can add a line to the sudoers file: >>> >>> Defaults env_reset >>> >>> that will reset the environment to only contain the variables >>> HOME, LOGNAME, >>> PATH, SHELL, TERM, and USER, preventing this attack. >> >> >> > From ramercer at gmail.com Fri Nov 2 15:20:23 2007 From: ramercer at gmail.com (Adam Mercer) Date: Fri Nov 2 15:19:34 2007 Subject: #13080 update devel/bazaar-ng to use python25 portgroup Message-ID: <799406d60711021520w3eacd82n93c33de0cde109c4@mail.gmail.com> Hi Can someone with commit access please take a look at ticket #13080 [1] which updates the bazaar-ng port to use the python25 portgroup? Cheers Adam [1] From ryandesign at macports.org Sun Nov 4 01:04:46 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun Nov 4 01:03:55 2007 Subject: [30677] trunk/dports/security/authforce In-Reply-To: <20071103203815.252E39146F4@cvs.opensource.apple.com> References: <20071103203815.252E39146F4@cvs.opensource.apple.com> Message-ID: <8B1050E2-1A8B-42F4-902E-D2206E2ECE61@macports.org> On Nov 3, 2007, at 15:38, source_changes@macosforge.org wrote: > --- trunk/dports/security/authforce/Portfile 2007-11-03 20:15:07 > UTC (rev 30676) > +++ trunk/dports/security/authforce/Portfile 2007-11-03 20:38:14 > UTC (rev 30677) > @@ -22,6 +22,9 @@ > configure.args --mandir=${prefix}/share/man --infodir=${prefix}/ > share/info > configure.cppflags-append "-L${prefix}/lib" > configure.cflags-append "-no-cpp-precomp -flat_namespace - > undefined suppress -lintl -L${prefix}/lib" > + > +patchfiles patch-http.c > + FYI: The patchfile should be named "patch-http.c.diff". "port lint" has some other recommendations for this portfile as well: $ sudo port lint Password: ---> Verifying Portfile for authforce Warning: Line 2 should be a newline (after RCS tag) Warning: Line 3 should be a newline (after PortSystem) Warning: Line 16 has trailing whitespace before newline Warning: Line 24 has trailing whitespace before newline Warning: Line 32 has trailing whitespace before newline Warning: Patchfile patch-http.c does not follow the source patch naming policy "patch-*.diff" ---> 0 errors and 6 warnings found. $ From afb at macports.org Sun Nov 4 01:22:51 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun Nov 4 01:21:58 2007 Subject: [30677] trunk/dports/security/authforce In-Reply-To: <8B1050E2-1A8B-42F4-902E-D2206E2ECE61@macports.org> References: <20071103203815.252E39146F4@cvs.opensource.apple.com> <8B1050E2-1A8B-42F4-902E-D2206E2ECE61@macports.org> Message-ID: <0648e8fb33533b36d6d92b770f6476b2@macports.org> Ryan Schmidt wrote: >> + >> +patchfiles patch-http.c >> + > > FYI: The patchfile should be named "patch-http.c.diff". "port lint" > has some other recommendations for this portfile as well: Is there any kind of consensus for making BSD-style patch naming illegal in Portfiles ? --anders From afb at macports.org Sun Nov 4 02:30:39 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun Nov 4 02:29:45 2007 Subject: /Library/Frameworks violates layout Message-ID: <8ac9cb6d60087db0bb8f8802c8f132e3@macports.org> Or actually it doesn't trigger a warning, but it should... Frameworks _should_ go into ${prefix}/Library/Frameworks instead, just like the various Pythons do at the moment. Tcl and Applications might require "workarounds"* due to bugs/shortcomings in other software, but not Frameworks ? However, this does require that the -F flag is passed - just like the -I and -L flags are being passed already: (I have a patch for GCC 3.3.x, should it ever be needed, GCC 4.x.y has framework support, at least for the params) CPPFLAGS += -F${prefix}/Library/Frameworks LDFLAGS += -F${prefix}/Library/Frameworks # the Xcode setting is FRAMEWORK_SEARCH_PATHS Prime violators are the libsdl*-framework ports, and also (indirectly) everything that uses them as well... Installing into /Library/Frameworks isn't any more "OK" than installing into /usr/local/include,/usr/local/lib ! Could this tree policy be changed for MacPorts 1.6.0 ? --anders * Preferrably the current /Library/Tcl/macports1.0 and /Applications/MacPorts would be symlinks to ${prefix}. But that doesn't work apparently, due to shortcomings in AppKit and Cocoa when using with Services/Xcode ? From sbranzo at gmail.com Sun Nov 4 06:00:26 2007 From: sbranzo at gmail.com (Sbranzo) Date: Sun Nov 4 05:59:35 2007 Subject: slrn-devel pre0.9.9-30 Message-ID: <20071104140026.GA16164@sbranzo.camunia> Hi, I wrote a portfile for slrn pre0.9.9-30, which is the latest develpment release of slrn. The sources tarball used is taken from a checkout of the snv server. I don't have the commit bit on the macports svn, and I don't know which is the right way of dealing with this sort of things. If a developer can be so kind to help me, I'll send him the tarball and the portfile so he can place them upstream. Thanks, Gufo From simon at ruderich.com Sun Nov 4 09:51:18 2007 From: simon at ruderich.com (Simon Ruderich) Date: Sun Nov 4 10:05:59 2007 Subject: Buildfarm try In-Reply-To: <82084CFB-6FF7-45B3-8236-7908FEB8795C@macports.org> References: <20071014220005.GA6544@ruderich.com> <20071017211737.GA14672@ruderich.com> <82084CFB-6FF7-45B3-8236-7908FEB8795C@macports.org> Message-ID: <20071104175118.GA864@ruderich.com> On Wed, Oct 17, 2007 at 02:48:43PM -0700, James Berry wrote: > I'd like to point out that mpwa, as deployed at http://db.macports.org has > schema support for most of what is required for this, including problem > reports and build output/logs from ports. > > James Hi, first I want to apologize for my late response. I was on vacation and busy again. Sorry. I just looked at it and it looks good. But I couldn't find any support for a buildfarm. Is this only hidden in the code? If so it would be nice if there could be svn access so we can look at it and use it. The rest looks really good. Thanks, 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: 186 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20071104/f970457a/attachment.bin From simon at ruderich.com Sun Nov 4 09:51:44 2007 From: simon at ruderich.com (Simon Ruderich) Date: Sun Nov 4 10:07:03 2007 Subject: Buildfarm try In-Reply-To: <2614990C-B29D-4451-9333-0D26AF870EDB@macports.org> References: <20071014220005.GA6544@ruderich.com> <2EE6A095-5D61-4F1F-B3B2-DCCDEB379904@macports.org> <20071017205317.GA14581@ruderich.com> <2614990C-B29D-4451-9333-0D26AF870EDB@macports.org> Message-ID: <20071104175144.GB864@ruderich.com> Hi, first I want to say sorry for my late reply. I was on vacation and busy. Sorry. On Wed, Oct 17, 2007 at 04:45:55PM -0500, Ryan Schmidt wrote: > > Well, build.html currently lists failures in this order: > > ArpSpyX > gnustep-base > DesktopManager > gnustep-base > gnustep-base > GNUMail-Aqua > HandBrake > gnustep-base > ID3 > gnustep-base > qt3-mac > NotificationWatcher > gnustep-base > > You see my confusion. Yes, this is weird. Don't know how this happened. Maybe a problem with my (stupid) parser. > MacPorts uses curl to download. Curl has options that can be used to > consider the download failed if the download speed drops below some > threshold for some period of time. If MacPorts is not currently using this > option, perhaps it should. It would alleviate this problem. Here's how it's > done on the command line (from "man curl"): > > [snip] It would be super if someone with knowledge of the port base could check this. I'm sorry but I can't read the macports source. > Some ports do take a very long time, and some ports have very many > dependencies. To start with, maybe it would be good to limit your build farm > to ports that don't have so many dependencies (including indirect > dependencies). Just so it doesn't take forever, and so that we start > learning about the easier-to-fix failures. Yes, that should be done in our next attempt. But I think we should wait with a new (and hopeful) better try until the new logging system is integrated. That should make many things easier. Thanks, 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: 186 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20071104/d5cf8ce0/attachment.bin From simon at ruderich.com Sun Nov 4 09:53:05 2007 From: simon at ruderich.com (Simon Ruderich) Date: Sun Nov 4 10:07:13 2007 Subject: Buildfarm try In-Reply-To: <5ebf6c19a0c51ea9913d6397d91325ec@macports.org> References: <20071014220005.GA6544@ruderich.com> <2EE6A095-5D61-4F1F-B3B2-DCCDEB379904@macports.org> <20071017205317.GA14581@ruderich.com> <5ebf6c19a0c51ea9913d6397d91325ec@macports.org> Message-ID: <20071104175305.GC864@ruderich.com> On Thu, Oct 18, 2007 at 08:21:55AM +0200, Anders F Bj?rklund wrote: > Simon Ruderich wrote: > > You will find some scripts that help with building ports "in order" > and reusing results from previous builds in the portmgr section... > > http://trac.macports.org/projects/macports/browser/trunk/base/portmgr/packaging > > They recreate the entire chroot rather than `port uninstall installed` > and of course they haven't been updated since DarwinPorts and 10.2/6.0. > > --anders This sounds good. But if they weren't updated some with some knowledge of the port base should check if they still work properly. I'm sorry, but my knowledge of Tcl and macports source is still about zero. Thanks for your help, 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: 186 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20071104/54d8399f/attachment.bin From simon at ruderich.com Sun Nov 4 09:53:29 2007 From: simon at ruderich.com (Simon Ruderich) Date: Sun Nov 4 10:07:44 2007 Subject: Buildfarm try In-Reply-To: <1FD46275-CA97-4F8D-97D0-FC22C2BE3296@macports.org> References: <20071014220005.GA6544@ruderich.com> <2EE6A095-5D61-4F1F-B3B2-DCCDEB379904@macports.org> <3AA3C591-87C9-4F2F-9E92-C4BE57853ED3@macports.org> <20071017214059.GB14672@ruderich.com> <967aa4bfdf5a6c8eeab6dd3b945cd133@macports.org> <1FD46275-CA97-4F8D-97D0-FC22C2BE3296@macports.org> Message-ID: <20071104175328.GD864@ruderich.com> On Thu, Oct 18, 2007 at 01:27:07AM -0500, Ryan Schmidt wrote: > > Right. I don't know Ruby or Python and am not planning on learning them at > this point. Would be unfortunate to introduce yet another language one has > to learn to contribute to MacPorts. IMHO PHP would be ok, since we already > use that for the web site. But my opinion may be influenced by the fact that > I already know PHP very well and already use it for web sites and > command-line scripts. But Tcl would also be a good choice given the rest of > the project's source. Even if I don't know any Tcl (yet) I also think it's the best way as it's already used by macports. If it would be possible to directly integrate it into the macports base, so that every client can just run a buildfarm then it would be perfect. But even a second application is fine. The server could be implemented in PHP and distribute the builds to the clients. So nobody does work multiple times. With this it would also possible for everyone to help the macports project with just donating some of his/her cpu cycles to build/test some applications. What do you think? 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: 186 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20071104/42cd5f5d/attachment-0001.bin From pguyot at kallisys.net Sun Nov 4 10:20:11 2007 From: pguyot at kallisys.net (Paul Guyot) Date: Sun Nov 4 10:19:18 2007 Subject: Buildfarm try In-Reply-To: <20071104175118.GA864@ruderich.com> References: <20071014220005.GA6544@ruderich.com> <20071017211737.GA14672@ruderich.com> <82084CFB-6FF7-45B3-8236-7908FEB8795C@macports.org> <20071104175118.GA864@ruderich.com> Message-ID: <137D5F75-9018-4C36-A045-11C2299D3BE9@kallisys.net> Le 4 nov. 07 ? 18:51, Simon Ruderich a ?crit : > On Wed, Oct 17, 2007 at 02:48:43PM -0700, James Berry wrote: >> I'd like to point out that mpwa, as deployed at http:// >> db.macports.org has >> schema support for most of what is required for this, including >> problem >> reports and build output/logs from ports. >> >> James > > Hi, > > first I want to apologize for my late response. I was on vacation > and busy > again. Sorry. > > I just looked at it and it looks good. But I couldn't find any > support for a > buildfarm. Is this only hidden in the code? If so it would be nice > if there > could be svn access so we can look at it and use it. The rest looks > really > good. > > Thanks, > Simon I vaguely recall seeing that thread, but I was too busy to reply then. We have a very nice support for building ports in a controlled environment called "virtual chroot" as it was implemented by Eugene as part of his GSoC internship. The code is there in svn. You need to configure your macports installation with --with-trace-sdk=... to specify which cross SDK to use for building ports, and then you need to use -t to enable the trace mode (which is called trace mode for historical reasons). I believe all we need is a script handling all that and building ports one after the other... Paul -- http://paul-guyot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: =?ISO-8859-1?Q?Ceci_est_une_signature_=E9lectronique_PGP?= Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20071104/3be5cafa/PGP.bin From ryandesign at macports.org Sun Nov 4 13:41:34 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun Nov 4 13:40:41 2007 Subject: [30677] trunk/dports/security/authforce In-Reply-To: <0648e8fb33533b36d6d92b770f6476b2@macports.org> References: <20071103203815.252E39146F4@cvs.opensource.apple.com> <8B1050E2-1A8B-42F4-902E-D2206E2ECE61@macports.org> <0648e8fb33533b36d6d92b770f6476b2@macports.org> Message-ID: <2BC90B67-9F10-40FF-8C73-0B3CF94ED33E@macports.org> On Nov 4, 2007, at 03:22, Anders F Bj?rklund wrote: > Ryan Schmidt wrote: > >>> + >>> +patchfiles patch-http.c >>> + >> >> FYI: The patchfile should be named "patch-http.c.diff". "port >> lint" has some other recommendations for this portfile as well: > > Is there any kind of consensus for making BSD-style patch naming > illegal in Portfiles ? By "BSD-style patch naming" I assume you mean omitting ".diff" from the end of the name? I did bring this up before; here is the thread: http://lists.macosforge.org/pipermail/macports-dev/2007-October/ 003139.html In follow-ups, nox and jmpp agreed that using ".diff" at the end of the filename is a good idea. Therefore, "port lint" recommends this. The new guide has not yet been updated recommend using ".diff" at the end of patchfile names, and the examples there still don't. The guide should be updated. From ryandesign at macports.org Sun Nov 4 13:42:48 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun Nov 4 13:41:53 2007 Subject: [30677] trunk/dports/security/authforce In-Reply-To: <9FAE1A8D-C5FD-44E6-9F1D-85B68F5D6CAD@macports.org> References: <20071103203815.252E39146F4@cvs.opensource.apple.com> <8B1050E2-1A8B-42F4-902E-D2206E2ECE61@macports.org> <9FAE1A8D-C5FD-44E6-9F1D-85B68F5D6CAD@macports.org> Message-ID: On Nov 4, 2007, at 03:31, Mark Grimes wrote: > On Nov 4, 2007, at 1:04 AM, Ryan Schmidt wrote: > >> On Nov 3, 2007, at 15:38, source_changes@macosforge.org wrote: >> >>> --- trunk/dports/security/authforce/Portfile 2007-11-03 20:15:07 >>> UTC (rev 30676) >>> +++ trunk/dports/security/authforce/Portfile 2007-11-03 20:38:14 >>> UTC (rev 30677) >>> @@ -22,6 +22,9 @@ >>> configure.args --mandir=${prefix}/share/man --infodir=${prefix}/ >>> share/info >>> configure.cppflags-append "-L${prefix}/lib" >>> configure.cflags-append "-no-cpp-precomp -flat_namespace - >>> undefined suppress -lintl -L${prefix}/lib" >>> + >>> +patchfiles patch-http.c >>> + >> >> >> FYI: The patchfile should be named "patch-http.c.diff". "port >> lint" has some other recommendations for this portfile as well: >> >> >> $ sudo port lint >> Password: >> ---> Verifying Portfile for authforce >> Warning: Line 2 should be a newline (after RCS tag) >> Warning: Line 3 should be a newline (after PortSystem) >> Warning: Line 16 has trailing whitespace before newline >> Warning: Line 24 has trailing whitespace before newline >> Warning: Line 32 has trailing whitespace before newline >> Warning: Patchfile patch-http.c does not follow the source patch >> naming policy "patch-*.diff" >> ---> 0 errors and 6 warnings found. >> $ > > Aside from the strange "mandated" naming conventions, port lint is > suggesting (as warnings) that diff -p -u is insufficient, which I > find a little disturbing. Is there an alternative set of diff flags > that will make lint happy? I don't really understand. What is strange about the naming conventions? And what do you mean "diff -p -u is insufficient"? What does diff have to do with lint? From ryandesign at macports.org Sun Nov 4 14:04:43 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun Nov 4 14:03:48 2007 Subject: #13080 update devel/bazaar-ng to use python25 portgroup In-Reply-To: <799406d60711021520w3eacd82n93c33de0cde109c4@mail.gmail.com> References: <799406d60711021520w3eacd82n93c33de0cde109c4@mail.gmail.com> Message-ID: On Nov 2, 2007, at 17:20, Adam Mercer wrote: > Can someone with commit access please take a look at ticket #13080 [1] > which updates the bazaar-ng port to use the python25 portgroup? Done! From afb at macports.org Sun Nov 4 14:29:31 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun Nov 4 14:28:36 2007 Subject: [30677] trunk/dports/security/authforce In-Reply-To: <2BC90B67-9F10-40FF-8C73-0B3CF94ED33E@macports.org> References: <20071103203815.252E39146F4@cvs.opensource.apple.com> <8B1050E2-1A8B-42F4-902E-D2206E2ECE61@macports.org> <0648e8fb33533b36d6d92b770f6476b2@macports.org> <2BC90B67-9F10-40FF-8C73-0B3CF94ED33E@macports.org> Message-ID: Ryan Schmidt wrote: > In follow-ups, nox and jmpp agreed that using ".diff" at the end of > the filename is a good idea. Therefore, "port lint" recommends this. Right, and in follow-ups I didn't... But it's not _that_ important to me, as I'm really not used to either tradition but have normally been using -p1 patches instead in RPM. (named something like foo-1.2.3-bar.patch) So if it is now required, then so be it I suppose. :-P --anders From ryandesign at macports.org Sun Nov 4 15:07:12 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun Nov 4 15:06:18 2007 Subject: [30677] trunk/dports/security/authforce In-Reply-To: References: <20071103203815.252E39146F4@cvs.opensource.apple.com> <8B1050E2-1A8B-42F4-902E-D2206E2ECE61@macports.org> <9FAE1A8D-C5FD-44E6-9F1D-85B68F5D6CAD@macports.org> Message-ID: On Nov 4, 2007, at 16:54, Mark Grimes wrote: > On Nov 4, 2007, at 13:42, Ryan Schmidt wrote: > >> On Nov 4, 2007, at 03:31, Mark Grimes wrote: >> >>> On Nov 4, 2007, at 1:04 AM, Ryan Schmidt wrote: >>> >>>> On Nov 3, 2007, at 15:38, source_changes@macosforge.org wrote: >>>> >>>>> --- trunk/dports/security/authforce/Portfile 2007-11-03 >>>>> 20:15:07 UTC (rev 30676) >>>>> +++ trunk/dports/security/authforce/Portfile 2007-11-03 >>>>> 20:38:14 UTC (rev 30677) >>>>> @@ -22,6 +22,9 @@ >>>>> configure.args --mandir=${prefix}/share/man --infodir=$ >>>>> {prefix}/share/info >>>>> configure.cppflags-append "-L${prefix}/lib" >>>>> configure.cflags-append "-no-cpp-precomp -flat_namespace - >>>>> undefined suppress -lintl -L${prefix}/lib" >>>>> + >>>>> +patchfiles patch-http.c >>>>> + >>>> >>>> >>>> FYI: The patchfile should be named "patch-http.c.diff". "port >>>> lint" has some other recommendations for this portfile as well: >>>> >>>> >>>> $ sudo port lint >>>> Password: >>>> ---> Verifying Portfile for authforce >>>> Warning: Line 2 should be a newline (after RCS tag) >>>> Warning: Line 3 should be a newline (after PortSystem) >>>> Warning: Line 16 has trailing whitespace before newline >>>> Warning: Line 24 has trailing whitespace before newline >>>> Warning: Line 32 has trailing whitespace before newline >>>> Warning: Patchfile patch-http.c does not follow the source patch >>>> naming policy "patch-*.diff" >>>> ---> 0 errors and 6 warnings found. >>>> $ >>> >>> Aside from the strange "mandated" naming conventions, port lint >>> is suggesting (as warnings) that diff -p -u is insufficient, >>> which I find a little disturbing. Is there an alternative set of >>> diff flags that will make lint happy? >> >> I don't really understand. What is strange about the naming >> conventions? And what do you mean "diff -p -u is insufficient"? >> What does diff have to do with lint? > > You said lint had other suggestions aside from the .diff and I'm > saying this patch is made with diff -p -u so I am assuming all > these suggestions (lint warnings) can be dismissed. Ah, I see. The port has no maintainer. I thought maybe you were its maintainer; I didn't look closely enough. In any case, I wanted to point out to you the patchfile naming situation, and rather than just state it, I wanted to show you (and others) how you can learn of this yourself (by using "port lint" before committing). In this case "port lint" also showed other errors unrelated to the changes you made, and if you were the maintainer, you might want to take care of those too. But since the port has no maintainer I went ahead and made the whitespace changes in r30700. From n.oxyde at gmail.com Sun Nov 4 15:56:36 2007 From: n.oxyde at gmail.com (N_Ox) Date: Sun Nov 4 15:55:45 2007 Subject: /Library/Frameworks violates layout In-Reply-To: <8ac9cb6d60087db0bb8f8802c8f132e3@macports.org> References: <8ac9cb6d60087db0bb8f8802c8f132e3@macports.org> Message-ID: <8D07B83C-B3CB-4DE1-9F5E-520B3A000B5C@gmail.com> Le 4 nov. 07 ? 11:30, Anders F Bj?rklund a ?crit : > Or actually it doesn't trigger a warning, but it should... > > Frameworks _should_ go into ${prefix}/Library/Frameworks > instead, just like the various Pythons do at the moment. > Tcl and Applications might require "workarounds"* due to > bugs/shortcomings in other software, but not Frameworks ? > > However, this does require that the -F flag is passed - > just like the -I and -L flags are being passed already: > (I have a patch for GCC 3.3.x, should it ever be needed, > GCC 4.x.y has framework support, at least for the params) > > CPPFLAGS += -F${prefix}/Library/Frameworks > LDFLAGS += -F${prefix}/Library/Frameworks > > # the Xcode setting is > FRAMEWORK_SEARCH_PATHS > > Prime violators are the libsdl*-framework ports, and > also (indirectly) everything that uses them as well... > Installing into /Library/Frameworks isn't any more "OK" > than installing into /usr/local/include,/usr/local/lib ! > > Could this tree policy be changed for MacPorts 1.6.0 ? > --anders I'd love that! Installing into /Library/Frameworks feels just plain wrong. > * Preferrably the current /Library/Tcl/macports1.0 and > /Applications/MacPorts would be symlinks to ${prefix}. > But that doesn't work apparently, due to shortcomings > in AppKit and Cocoa when using with Services/Xcode ? > As you know, ${prefix}/share/tcl/macports1.0 would be okay, we just need to add this path to the port executable, see http://trac.macports.org/projects/macports/ticket/12943 -- Anthony Ramine, the "Ports tree cleaning Maestro". From christian at wilde-welt.de Mon Nov 5 06:28:17 2007 From: christian at wilde-welt.de (Christian Aust) Date: Mon Nov 5 06:27:16 2007 Subject: #13046: Please check and commit that patch Message-ID: <5AE31EC8-3E72-48F9-B56C-4BD88DF1268A@wilde-welt.de> Hi all, #13046 is a pretty annoying, although minor bug with MacPort's OpenSSH port. There's a patch available, but appearantly there's nobody working on it right now. (It has been assigned to jmpp@macports.org) Can somebody please have a look at it and commit the patch if appropriate? Kind regards, Christian -- Christian Aust mailto:christian@wilde-welt.de icq: 84500990 - AIM, MSN, GTalk: datenimperator skype:datenimperator From mww at macports.org Mon Nov 5 06:36:54 2007 From: mww at macports.org (Weissmann Markus) Date: Mon Nov 5 06:35:38 2007 Subject: Speed up build phase with "make -j" In-Reply-To: <20071031153501.GO17687@prunille.vinc17.org> References: <0eeabef57edf99c07398efbb32a1c070@macports.org> <20071030125229.GM12605@prunille.vinc17.org> <02B9B2F4-77AA-4348-8876-220CC18468F6@macports.org> <20071031041354.GB17687@prunille.vinc17.org> <20071031113653.GH17687@prunille.vinc17.org> <8EA79CB4-D0FF-4A3F-96D4-6FB7605777CA@macports.org> <8abfb8d166c3e04e8d9f338a1c038fa2@macports.org> <8fe8a5a89927685254bedb182f289f01@macports.org> <20071031153501.GO17687@prunille.vinc17.org> Message-ID: <4F5F0842-3BB5-497B-8952-85B46198BC62@macports.org> On 31.10.2007, at 16:35, Vincent Lefevre wrote: > On 2007-10-31 15:57:56 +0100, Markus Weissmann wrote: >> So the discussion has narrowed to: >> 1.) disabled by default on an "per-installation" option: >> Can be toggled system-wide (with default "off"); ports have to >> actively >> deny a parallel build attempt; >> >> 2.) disabled by default on a per-port option >> Can be toggled system-wide (with default ?); ports have to >> actively declare >> to be build-able in parallel; > > Portfiles should be able to say that they support a parallel build and > that they don't support a parallel build, i.e. you have 3 > possibilities: > "yes" (which can later be changed to "no" if someone finds that it > doesn't work on some particular machine), "no" (that could be changed > to "yes" once the bug has been fixed upstream), and "don't know". > I've just added an option use_parallel_build [yes|no] to trunk; if it is set to "yes", "-j N" is added if the number of desired parallel processes is configured in port.conf (nothing changed here). The options defaults to "no", so no ports will break when we release v1.6. -Markus --- Markus W. Weissmann http://www.mweissmann.de/ From ryandesign at macports.org Mon Nov 5 07:35:52 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Nov 5 07:34:55 2007 Subject: #13046: Please check and commit that patch In-Reply-To: <5AE31EC8-3E72-48F9-B56C-4BD88DF1268A@wilde-welt.de> References: <5AE31EC8-3E72-48F9-B56C-4BD88DF1268A@wilde-welt.de> Message-ID: <15A85D32-AFF0-4A72-A92D-88CA6FD55429@macports.org> On Nov 5, 2007, at 08:28, Christian Aust wrote: > #13046 is a pretty annoying, although minor bug with MacPort's > OpenSSH port. There's a patch available, but appearantly there's > nobody working on it right now. (It has been assigned to > jmpp@macports.org) > > Can somebody please have a look at it and commit the patch if > appropriate? Kind regards, But the bug was only filed 6 days ago, and was not Cc'd to jmpp, so he probably never saw it. I'm adding him (and you) to the Cc list now. Of course, I'm not sure why it's assigned to jmpp, since the port has no maintainer.... From christian at wilde-welt.de Mon Nov 5 07:43:17 2007 From: christian at wilde-welt.de (Christian Aust) Date: Mon Nov 5 07:42:15 2007 Subject: #13046: Please check and commit that patch In-Reply-To: <15A85D32-AFF0-4A72-A92D-88CA6FD55429@macports.org> References: <5AE31EC8-3E72-48F9-B56C-4BD88DF1268A@wilde-welt.de> <15A85D32-AFF0-4A72-A92D-88CA6FD55429@macports.org> Message-ID: Am 05.11.2007 um 16:35 schrieb Ryan Schmidt: > On Nov 5, 2007, at 08:28, Christian Aust wrote: > >> #13046 is a pretty annoying, although minor bug with MacPort's >> OpenSSH port. There's a patch available, but appearantly there's >> nobody working on it right now. (It has been assigned to jmpp@macports.org >> ) >> >> Can somebody please have a look at it and commit the patch if >> appropriate? Kind regards, > > But the bug was only filed 6 days ago, and was not Cc'd to jmpp, so > he probably never saw it. I'm adding him (and you) to the Cc list > now. Of course, I'm not sure why it's assigned to jmpp, since the > port has no maintainer.... Thanks, Ryan. I've got mail from Stephen Purcell (macports@sanityinc.com) regarding that assignment: > I was the guy who filed this patch ticket, and perhaps I shouldn't > have assigned it to jmpp@macports.orgjust because he was the last > person to modify the openssh port. It's possible he's too busy to > work on MacPorts, so perhaps you'd like to post to the mailing list > and ask about it. There are a bunch of other committers, one of > whom is probably willing to commit the fix. Maybe that can help to clear things up. Regards, Christian -- Christian Aust mailto:christian@wilde-welt.de icq: 84500990 - AIM, MSN, GTalk: datenimperator skype:datenimperator From markd at macports.org Mon Nov 5 10:52:36 2007 From: markd at macports.org (markd@macports.org) Date: Mon Nov 5 10:51:18 2007 Subject: [30721] use_parallel_build / portfile-phase.7.xml In-Reply-To: <20071105180113.05DC5917F31@cvs.opensource.apple.com> References: <20071105180113.05DC5917F31@cvs.opensource.apple.com> Message-ID: macports-dev@lists.macosforge.org writes: >Revision >[ http://trac.macosforge.org/projects/macports/changeset/30721 ]30721 >Author >mww@macports.org >Date >2007-11-05 10:01:13 -0800 (Mon, 05 Nov 2007) > >Log Message > >use_bzip2 default to 'no'; >document 'use_parallel_build'; > > >Modified Paths > > [ >fcp://@bubbs.biola.edu,%235000280/Mailbox/%23233592931#trunkdocnewmanxmlportfilephase7xml >]trunk/doc-new/man/xml/portfile-phase.7.xml Hi Markus, Thanks again for your diligent work to keep the docs up-to-date. It is much appreciated. One question about "use_parallel_build". Do you think that keyword relates to a phase, or should it be considered a "global keyword"? I thought perhaps "global", or do you consider it specifically related to the build phase? I thought parallelism applied more generally to the port overall. But if that were true, I suppose the name would be "use_parallel_install" or some such, so if you could comment on that it might clarify it. If I had followed the recent thread I suppose I would know this, but I didn't. I also have to say that I struggled to come up with an organizing principle for keywords, and I'm not entirely sure that separating them into "global" (those relating to the port as a whole and not primarily related to a phase) and "phase" (those relating to a particular phase) is the best way. Perhaps there is a better way, but I haven't hit upon it yet. So I just wanted to ask if you think given that distinction, if portfile-phase is the best place for use_parallel_build. And if you have an opinion on whether that distinction is adequate or not, I'd welcome your comments on that as well. Mark From markd at macports.org Mon Nov 5 11:30:16 2007 From: markd at macports.org (markd@macports.org) Date: Mon Nov 5 11:28:56 2007 Subject: [30721] use_parallel_build / portfile-phase.7.xml In-Reply-To: <20071105180113.05DC5917F31@cvs.opensource.apple.com> References: <20071105180113.05DC5917F31@cvs.opensource.apple.com> Message-ID: Mark Duling writes: >One question about "use_parallel_build". Do you think that keyword >relates to a phase, or should it be considered a "global keyword"? I >thought perhaps "global", or do you consider it specifically related to >the build phase? I thought parallelism applied more generally to the >port overall. But if that were true, I suppose the name would be >"use_parallel_install" or some such, so if you could comment on that it >might clarify it. If I had followed the recent thread I suppose I would >know this, but I didn't. > >I also have to say that I struggled to come up with an organizing >principle for keywords, and I'm not entirely sure that separating them >into "global" (those relating to the port as a whole and not primarily >related to a phase) and "phase" (those relating to a particular phase) is >the best way. Perhaps there is a better way, but I haven't hit upon it >yet. So I just wanted to ask if you think given that distinction, if >portfile-phase is the best place for use_parallel_build. And if you have >an opinion on whether that distinction is adequate or not, I'd welcome >your comments on that as well. Okay, I looked at the thread and I see that "use_parallel_build" does indeed relate specifically to the build phase. I should have done that before sending the email. Sorry. I gotta stop trying to think in the morning without caffeine. :) Perhaps I was influenced by my recollections that some ports stop installing outside of the build phase until another port is finished installing. At least I think I've seen this. If that is so and a ports hangs at activate or another phase until another port completes, it seems like parallel building still wouldn't get parallel installs. Mark From dluke at geeklair.net Mon Nov 5 11:32:38 2007 From: dluke at geeklair.net (Daniel J. Luke) Date: Mon Nov 5 11:31:36 2007 Subject: [30721] use_parallel_build / portfile-phase.7.xml In-Reply-To: References: <20071105180113.05DC5917F31@cvs.opensource.apple.com> Message-ID: <6F06624F-A058-453C-9E8C-8F2A9EA38B49@geeklair.net> On Nov 5, 2007, at 2:30 PM, markd@macports.org wrote: > Perhaps I was influenced by my recollections that some ports stop > installing outside of the build phase until another port is finished > installing. At least I think I've seen this. you have. > If that is so and a ports > hangs at activate or another phase until another port completes, it > seems > like parallel building still wouldn't get parallel installs. This option is not really related to that behavior. It just allows a port to say that it can be built with make -j (which can speed up builds on multi-core or multi-cpu systems). -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20071105/aa73340d/PGP.bin From markd at macports.org Mon Nov 5 11:51:33 2007 From: markd at macports.org (markd@macports.org) Date: Mon Nov 5 11:50:43 2007 Subject: [30721] use_parallel_build / portfile-phase.7.xml In-Reply-To: <6F06624F-A058-453C-9E8C-8F2A9EA38B49@geeklair.net> References: <20071105180113.05DC5917F31@cvs.opensource.apple.com> <6F06624F-A058-453C-9E8C-8F2A9EA38B49@geeklair.net> Message-ID: "Daniel J. Luke" writes: >> Perhaps I was influenced by my recollections that some ports stop >> installing outside of the build phase until another port is finished >> installing. At least I think I've seen this. > >you have. > >> If that is so and a ports >> hangs at activate or another phase until another port completes, it >> seems >> like parallel building still wouldn't get parallel installs. > > >This option is not really related to that behavior. > >It just allows a port to say that it can be built with make -j (which >can speed up builds on multi-core or multi-cpu systems). Ah I see, I changed the description slightly to make it mor clear. Thanks! Unfortunately, my editor wrapped a bunch of lines so the commit was messy. Mark From jmpp at macports.org Mon Nov 5 13:16:36 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Mon Nov 5 13:12:41 2007 Subject: 1.6 release? Message-ID: <7B78B63A-CC2D-4F60-94B0-92368AA8F5A8@macports.org> Hey everyone! It's very pleasing to see the amount of work that has gone into base since our last release, but the negative side of that is that our current code delta between trunk and the last release branch is huge. Therefore I propose we make a 1.6 release with a new release branch from scratch, cut off from trunk ToT. For that to happen, it would be nice to have some input on the current state of trunk: -) does any developer in particular plan to include new features/ improvements in the near future? If so, do these entail any obvious instability we should account for? *) Markus, anything else we should look forward to in your recent slew of build stage related improvements? -) on the other hand, is there anything in particular anyone would like to see *NOT* released to the public just yet? *) Eugene, how "finished" would you call your work on trace mode improvements? Other than bugs that you may fix as they are reported, do you plan any major changes to the core of your work? *) Chris, what are your plans to switch us to the new registry? I haven't seen you committing any new code for this, so I don't have much of an idea of its state. Can you please fill us in? That put aside, I'm guessing we don't have to worry much about registry2.0 since, from what I gather, it's effectively "turned off" in our sources, right? -) documentation people, can we count on rewritten man pages to go with 1.6? How far off is the new guide? I appreciate not only input on these points raised above, but also on the overall state of trunk, in order to properly plan the 1.6 release and a test & stabilization cycle. One special treat I'm planning to couple with this new release is our revamped website, finally! So don't be shy to provide all feedback that you have on that too, most welcomed! (you'll always find it at http://apollo.homeunix.net/macports) It's mostly complete in functionality (which I've been coordinating with Mac OS Forge admin for proper deployment) and content, only lacking now the main index.php page which I still haven't been able to get to. Do step up if you care to help in completing that final bit ;-) Regards and thanks for your attention and help! -jmpp From mww at macports.org Mon Nov 5 14:04:08 2007 From: mww at macports.org (Weissmann Markus) Date: Mon Nov 5 14:02:55 2007 Subject: [30721] use_parallel_build / portfile-phase.7.xml In-Reply-To: <6F06624F-A058-453C-9E8C-8F2A9EA38B49@geeklair.net> References: <20071105180113.05DC5917F31@cvs.opensource.apple.com> <6F06624F-A058-453C-9E8C-8F2A9EA38B49@geeklair.net> Message-ID: <0BAAA7BA-9B45-4448-B027-E12198744843@macports.org> I've just added a way to automatically set the number of build jobs (if desired): If the number of build jobs is set to "0" (in the config file), the number of jobs is set to the number of cores. This works only on Mac OS X (and FreeBSD -- though untested). -Markus On 05.11.2007, at 20:32, Daniel J. Luke wrote: > On Nov 5, 2007, at 2:30 PM, markd@macports.org wrote: >> Perhaps I was influenced by my recollections that some ports stop >> installing outside of the build phase until another port is finished >> installing. At least I think I've seen this. > > you have. > >> If that is so and a ports >> hangs at activate or another phase until another port completes, >> it seems >> like parallel building still wouldn't get parallel installs. > > > This option is not really related to that behavior. > > It just allows a port to say that it can be built with make -j > (which can speed up builds on multi-core or multi-cpu systems). > -- > Daniel J. Luke > +========================================================+ > | *---------------- dluke@geeklair.net ----------------* | > | *-------------- http://www.geeklair.net -------------* | > +========================================================+ > | Opinions expressed are mine and do not necessarily | > | reflect the opinions of my employer. | > +========================================================+ > > > --- Markus W. Weissmann http://www.mweissmann.de/ From jmpp at macports.org Mon Nov 5 22:05:27 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Mon Nov 5 22:01:37 2007 Subject: /Library/Frameworks violates layout In-Reply-To: <8ac9cb6d60087db0bb8f8802c8f132e3@macports.org> References: <8ac9cb6d60087db0bb8f8802c8f132e3@macports.org> Message-ID: <287DEE27-5557-4456-B4E2-16A6E5C1D4E1@macports.org> So, do we have an agreement on this? Any objections to turning on warnings against /Library/Frameworks in the upcoming MacPorts 1.6? I support to move to discourage writing to that directory, gcc's -F flag should allow any application needing a framework to look for it under prefix, just as Anders makes it clean in his message. Any reason why we *shouldn't* move our frameworks into prefix? And as for macports1.0, we can still rely on configure's --with- tclpackage flag to place it inside prefix in customized installations. Regards,... -jmpp On Nov 4, 2007, at 6:30 AM, Anders F Bj?rklund wrote: > Or actually it doesn't trigger a warning, but it should... > > Frameworks _should_ go into ${prefix}/Library/Frameworks > instead, just like the various Pythons do at the moment. > Tcl and Applications might require "workarounds"* due to > bugs/shortcomings in other software, but not Frameworks ? > > However, this does require that the -F flag is passed - > just like the -I and -L flags are being passed already: > (I have a patch for GCC 3.3.x, should it ever be needed, > GCC 4.x.y has framework support, at least for the params) > > CPPFLAGS += -F${prefix}/Library/Frameworks > LDFLAGS += -F${prefix}/Library/Frameworks > > # the Xcode setting is > FRAMEWORK_SEARCH_PATHS > > Prime violators are the libsdl*-framework ports, and > also (indirectly) everything that uses them as well... > Installing into /Library/Frameworks isn't any more "OK" > than installing into /usr/local/include,/usr/local/lib ! > > Could this tree policy be changed for MacPorts 1.6.0 ? > --anders > > > * Preferrably the current /Library/Tcl/macports1.0 and > /Applications/MacPorts would be symlinks to ${prefix}. > But that doesn't work apparently, due to shortcomings > in AppKit and Cocoa when using with Services/Xcode ? > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev From jmpp at macports.org Mon Nov 5 22:13:43 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Mon Nov 5 22:09:32 2007 Subject: [30677] trunk/dports/security/authforce In-Reply-To: References: <20071103203815.252E39146F4@cvs.opensource.apple.com> <8B1050E2-1A8B-42F4-902E-D2206E2ECE61@macports.org> <0648e8fb33533b36d6d92b770f6476b2@macports.org> <2BC90B67-9F10-40FF-8C73-0B3CF94ED33E@macports.org> Message-ID: <9950F2F6-B8BB-4F1F-BB20-34B767B316F7@macports.org> On Nov 4, 2007, at 6:29 PM, Anders F Bj?rklund wrote: > Ryan Schmidt wrote: > >> In follow-ups, nox and jmpp agreed that using ".diff" at the end >> of the filename is a good idea. Therefore, "port lint" recommends >> this. > > Right, and in follow-ups I didn't... But it's not _that_ important > to me, as I'm really not used to either tradition but have normally > been using -p1 patches instead in RPM. (named something like > foo-1.2.3-bar.patch) So if it is now required, then so be it I > suppose. :-P It's not required, but rather advised ;-) The "patch" message is already conveyed by the "patch-*" part in the suggested file name, and the .diff extension helps some editors handle the file better. Overall, it's a simple thing that does not warrant too much bikeshed, though consistency is a good thing. Regards,... -jmpp From markd at macports.org Mon Nov 5 23:48:34 2007 From: markd at macports.org (markd@macports.org) Date: Mon Nov 5 23:47:12 2007 Subject: 1.6 release? In-Reply-To: <7B78B63A-CC2D-4F60-94B0-92368AA8F5A8@macports.org> References: <7B78B63A-CC2D-4F60-94B0-92368AA8F5A8@macports.org> Message-ID: Juan Manuel Palacios writes: >-) documentation people, can we count on rewritten man pages to go >with 1.6? How far off is the new guide? I think it will be awhile before the man pages and guide are done, but work is ongoing I think both are probably now as useful and complete as the old ones, and they are organized such that they can continue smoothly to completion. Markus Weissman is to be commended for significant contributions in the last week. Right now my main goal is surpassing the old docs so I can forget about them. I think that goal is fairly close. Maybe within a few weeks? > Mark From rhwood at mac.com Tue Nov 6 02:05:36 2007 From: rhwood at mac.com (Randall Wood) Date: Tue Nov 6 02:04:34 2007 Subject: /Library/Frameworks violates layout In-Reply-To: <287DEE27-5557-4456-B4E2-16A6E5C1D4E1@macports.org> References: <8ac9cb6d60087db0bb8f8802c8f132e3@macports.org> <287DEE27-5557-4456-B4E2-16A6E5C1D4E1@macports.org> Message-ID: On 6 Nov 2007, at 01:05, Juan Manuel Palacios wrote: > > So, do we have an agreement on this? Any objections to turning on > warnings against /Library/Frameworks in the upcoming MacPorts 1.6? > I support to move to discourage writing to that directory, gcc's -F > flag should allow any application needing a framework to look for > it under prefix, just as Anders makes it clean in his message. Any > reason why we *shouldn't* move our frameworks into prefix? There are no reasons other than esthetics (I would prefer something like /Library/MacPorts/Frameworks, but like I said, thats merely an cosmetic concern). Go for it. > And as for macports1.0, we can still rely on configure's --with- > tclpackage flag to place it inside prefix in customized installations. > > Regards,... > > -jmpp > > > On Nov 4, 2007, at 6:30 AM, Anders F Bj?rklund wrote: > >> Or actually it doesn't trigger a warning, but it should... >> >> Frameworks _should_ go into ${prefix}/Library/Frameworks >> instead, just like the various Pythons do at the moment. >> Tcl and Applications might require "workarounds"* due to >> bugs/shortcomings in other software, but not Frameworks ? >> >> However, this does require that the -F flag is passed - >> just like the -I and -L flags are being passed already: >> (I have a patch for GCC 3.3.x, should it ever be needed, >> GCC 4.x.y has framework support, at least for the params) >> >> CPPFLAGS += -F${prefix}/Library/Frameworks >> LDFLAGS += -F${prefix}/Library/Frameworks >> >> # the Xcode setting is >> FRAMEWORK_SEARCH_PATHS >> >> Prime violators are the libsdl*-framework ports, and >> also (indirectly) everything that uses them as well... >> Installing into /Library/Frameworks isn't any more "OK" >> than installing into /usr/local/include,/usr/local/lib ! >> >> Could this tree policy be changed for MacPorts 1.6.0 ? >> --anders >> >> >> * Preferrably the current /Library/Tcl/macports1.0 and >> /Applications/MacPorts would be symlinks to ${prefix}. >> But that doesn't work apparently, due to shortcomings >> in AppKit and Cocoa when using with Services/Xcode ? >> >> _______________________________________________ >> macports-dev mailing list >> macports-dev@lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo/macports-dev > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev Randall Wood rhwood@mac.com http://shyramblings.blogspot.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From mww at macports.org Tue Nov 6 03:38:29 2007 From: mww at macports.org (Weissmann Markus) Date: Tue Nov 6 03:37:08 2007 Subject: 1.6 release? In-Reply-To: <7B78B63A-CC2D-4F60-94B0-92368AA8F5A8@macports.org> References: <7B78B63A-CC2D-4F60-94B0-92368AA8F5A8@macports.org> Message-ID: On 05.11.2007, at 22:16, Juan Manuel Palacios wrote: > Hey everyone! > > It's very pleasing to see the amount of work that has gone into > base since our last release, but the negative side of that is that > our current code delta between trunk and the last release branch is > huge. Therefore I propose we make a 1.6 release with a new release > branch from scratch, cut off from trunk ToT. > > For that to happen, it would be nice to have some input on the > current state of trunk: > > -) does any developer in particular plan to include new features/ > improvements in the near future? If so, do these entail any obvious > instability we should account for? > *) Markus, anything else we should look forward to in your recent > slew of build stage related improvements? > Nothing too spectacular: The most significant additions in configure/ build are Anders' parallel build jobs and a bunch of configure- options for more comfortable access to often-used environment variables. This all has been done very conservative: The configure-options code is very straight and the parallel build jobs are off by default. We could switch the default to auto in a later release so the number of parallel build threads is oriented at the number of cores of the build machine, but not for 1.6. -Markus --- Markus W. Weissmann http://www.mweissmann.de/ From afb at macports.org Tue Nov 6 03:45:45 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Nov 6 04:37:33 2007 Subject: /Library/Frameworks violates layout In-Reply-To: References: <8ac9cb6d60087db0bb8f8802c8f132e3@macports.org> <287DEE27-5557-4456-B4E2-16A6E5C1D4E1@macports.org> Message-ID: <883c4314c9cd4a582a83b34d155ac1a2@macports.org> Randall Wood wrote: >> So, do we have an agreement on this? Any objections to turning on >> warnings against /Library/Frameworks in the upcoming MacPorts 1.6? I >> support to move to discourage writing to that directory, gcc's -F >> flag should allow any application needing a framework to look for it >> under prefix, just as Anders makes it clean in his message. Any >> reason why we *shouldn't* move our frameworks into prefix? > > There are no reasons other than esthetics (I would prefer something > like /Library/MacPorts/Frameworks, but like I said, thats merely an > cosmetic concern). Go for it. The main question here is whether we should add the prefix framework path to the default search, so that it is picked up automatically by ports trying to use the frameworks (just like -I and -L are adding the prefix search paths already)... ? /Library/MacPorts/Frameworks has the worst of both worlds, it still clutters /Library (outside of prefix) but is not in the default framework search path either (so you still need to add something to GCC / Xcode in order for them to find it properly) I'm not sure how much besides libsdl*-framework uses /Library, but probably some Xcode apps ? --anders From afb at macports.org Tue Nov 6 04:38:38 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Nov 6 04:37:35 2007 Subject: 1.6 release? In-Reply-To: <7B78B63A-CC2D-4F60-94B0-92368AA8F5A8@macports.org> References: <7B78B63A-CC2D-4F60-94B0-92368AA8F5A8@macports.org> Message-ID: Juan Manuel Palacios wrote: > -) does any developer in particular plan to include new > features/improvements in the near future? If so, do these entail any > obvious instability we should account for? The "mpkg" target is left to update to PackageMaker, and rpm/python/yum/smart/etc will be updated to RPM 4.5 and Python 2.5 at some point (currently using RPM 4.4 and Python 2.4) http://trac.macports.org/projects/macports/ticket/12329 (smart) http://trac.macports.org/projects/macports/ticket/13049 (mpkg) But the FreeBSD and Fedora support is pretty much done (except for documentation), so it's mostly ports left to do on my account (doing the aforementioned ones, and Xfce desktop) http://trac.macports.org/projects/macports/ticket/12749 (xfce) http://trac.macports.org/projects/macports/ticket/12439 (docs) "port lint" (which is still a tad broken) and build.jobs/build.nice/configure.ccache/configure.distcc are the biggest additions to MacPorts 1.6 that I have done (as well as some feature improvements like LZMA and XAR). The most user-visible features will be the new website and the new guide, though. Unless the new interface (GUI) and new packages (RPM) are ready to go in time for the 1.6.0 release, which I'm somewhat doubting whether it's even reasonable and realistic. And they could just as well go in a "MacPorts 2.0" ? For ports, the biggest update seems to be: - Python 2.4 => Python 2.5 - RPM 4.4.9 => RPM 4.5.0 - Mozilla 1.7 => Seamonkey - Xfce 4.2.4 => Xfce 4.4.1 As well as better Leopard/BSD/GNU support. --anders From sbranzo at gmail.com Tue Nov 6 05:09:15 2007 From: sbranzo at gmail.com (Sbranzo) Date: Tue Nov 6 05:08:13 2007 Subject: Trac problems and slrn-devel upgrade Message-ID: <20071106130915.GA5897@sbranzo.chinatown> Hi, I tried to file this on trac, but after pushing "preview and submit changes" the connection hangs and the ticket fails to be uploaded. I'm the maintainer of the slrn-devel package but I don't have the commit bit. Can someone please upgrade this for me? I'm not also used to upload sources tarball on macports, and the tarball attached is derived from a svn export of the development branch of slrn, so I don't know where to place it and change the portfile to reflect the location. Portfile is attached, and I'll send the archive ( 1.5 Mb) to the one who'll upload them. Thanks, Gufo -------------- next part -------------- PortSystem 1.0 name slrn-devel set betaversion 0.9.9pre set svnversion 43 version ${betaversion}-${svnversion} categories news net platforms darwin maintainers sbranzo@gmail.com homepage http://slrn.sourceforge.net/ description A powerful console-based newsreader long_description slrn is an easy to use but powerful NNTP/spool based \ newsreader. It is highly customizable, supports \ scoring, free key bindings, and can be extended using \ the SLang macro language. master_sites http://ftp.debian.org/debian/pool/main/s/slrn/ distname slrn-${betaversion}-${svnversion} checksums sha1 67f93dda0f8242477774fb46b6337d5d21a5d137 \ md5 0d48e077197b23fb1b096b790fa99d0a use_bzip2 no depends_lib port:slang2 \ port:libiconv configure.args --with-libiconv-prefix=${prefix} \ --mandir=${prefix}/share/man \ --with-slang-library=${prefix}/lib \ --with-slang-includes=${prefix}/include # adds slrnpull variant pull { configure.args-append --with-slrnpull } # ssl variant variant ssl { configure.args-append --with-ssl=${prefix} \ --with-ssl-includes=${prefix}/include/openssl depends_lib-append port:openssl } From libc.mail at gmail.com Tue Nov 6 05:24:12 2007 From: libc.mail at gmail.com (Eugene Pimenov) Date: Tue Nov 6 05:23:11 2007 Subject: 1.6 release? In-Reply-To: <7B78B63A-CC2D-4F60-94B0-92368AA8F5A8@macports.org> References: <7B78B63A-CC2D-4F60-94B0-92368AA8F5A8@macports.org> Message-ID: <7F25C5D0-1FD3-414F-81C6-61243A4DFA78@gmail.com> 06.11.2007, ? 0:16, Juan Manuel Palacios ???????(?): > > *) Eugene, how "finished" would you call your work on trace mode > improvements? Other than bugs that you may fix as they are reported, > do you plan any major changes to the core of your work? > I'm not planing major changes. I build every port with it, and seems it work good (for me, of course). > Regards and thanks for your attention and help! > > > -jmpp > From mww at macports.org Tue Nov 6 06:28:14 2007 From: mww at macports.org (Weissmann Markus) Date: Tue Nov 6 06:26:58 2007 Subject: Trac problems and slrn-devel upgrade In-Reply-To: <20071106130915.GA5897@sbranzo.chinatown> References: <20071106130915.GA5897@sbranzo.chinatown> Message-ID: <78BCFC45-C137-4924-9922-D84F17238184@macports.org> Hi, would it be possible to supply a diff? The attached files has practically nothing in common with the Portfile in trunk: $ slrn-devel> diff -u Portfile slrn-devel.portfile | wc -l 92 $ slrn-devel> wc -l * 50 Portfile 43 slrn-devel.portfile 93 total -Markus On 06.11.2007, at 14:09, Sbranzo wrote: > Hi, > I tried to file this on trac, but after pushing "preview and submit > changes" the connection hangs and the ticket fails to be uploaded. > > I'm the maintainer of the slrn-devel package but I don't have the > commit bit. Can > someone please upgrade this for me? > I'm not also used to upload sources tarball on macports, and the > tarball > attached is derived from a svn export of the development branch of > slrn, > so I don't know where to place it and change the portfile to > reflect the > location. > > Portfile is attached, and I'll send the archive ( 1.5 Mb) to the one > who'll upload them. > > Thanks, > Gufo devel.portfile>_______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev --- Markus W. Weissmann http://www.mweissmann.de/ From sbranzo at gmail.com Tue Nov 6 06:41:00 2007 From: sbranzo at gmail.com (Sbranzo) Date: Tue Nov 6 06:39:58 2007 Subject: Trac problems and slrn-devel upgrade In-Reply-To: <78BCFC45-C137-4924-9922-D84F17238184@macports.org> References: <20071106130915.GA5897@sbranzo.chinatown> <78BCFC45-C137-4924-9922-D84F17238184@macports.org> Message-ID: <20071106144100.GA22967@sbranzo.chinatown> On 06/11/07 15:28, Weissmann Markus wrote: > Hi, > > would it be possible to supply a diff? The attached files has practically > nothing in common with the Portfile in trunk: > $ slrn-devel> diff -u Portfile slrn-devel.portfile | wc -l > 92 > $ slrn-devel> wc -l * > 50 Portfile > 43 slrn-devel.portfile > 93 total The portfile is derived from the current one. I don't know why does diff thinks there's nothing in common between those 2 files, and it doesn't seems an issue of whitespaces...BTW slrn changed a little, it doesn't rely upon autocnf anymore and I changed from the archive taken from debian unstable to a snv checkout of the sorces. Gufo From jmpp at macports.org Tue Nov 6 06:59:51 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Nov 6 06:55:31 2007 Subject: /Library/Frameworks violates layout In-Reply-To: <883c4314c9cd4a582a83b34d155ac1a2@macports.org> References: <8ac9cb6d60087db0bb8f8802c8f132e3@macports.org> <287DEE27-5557-4456-B4E2-16A6E5C1D4E1@macports.org> <883c4314c9cd4a582a83b34d155ac1a2@macports.org> Message-ID: <12C963B9-414D-49DC-96F9-8C1F72711624@macports.org> On Nov 6, 2007, at 7:45 AM, Anders F Bj?rklund wrote: > Randall Wood wrote: > >>> So, do we have an agreement on this? Any objections to turning >>> on warnings against /Library/Frameworks in the upcoming MacPorts >>> 1.6? I support to move to discourage writing to that directory, >>> gcc's -F flag should allow any application needing a framework to >>> look for it under prefix, just as Anders makes it clean in his >>> message. Any reason why we *shouldn't* move our frameworks into >>> prefix? >> >> There are no reasons other than esthetics (I would prefer >> something like /Library/MacPorts/Frameworks, but like I said, >> thats merely an cosmetic concern). Go for it. > > The main question here is whether we should add the prefix > framework path to the default search, so that it is picked up > automatically by ports trying to use the frameworks (just like -I > and -L are adding the prefix search paths already)... ? I guess we can figure that out as we move forward with the change. If we see a bunch of -F flags leaking into our Portfiles maybe we can think of a set of suitable defaults in base that will spare us the -I & -L dance for frameworks. > > /Library/MacPorts/Frameworks has the worst of both worlds, it still > clutters /Library (outside of prefix) but is not in the default > framework search path either (so you still need to add something to > GCC / Xcode in order for them to find it properly) Other than adding gcc flags to base/Portfiles, what really would worry me is breaking anything by moving frameworks into our prefix. That being sorted out, I'd say there's good consensus to move them. Regards,... -jmpp From n.oxyde at gmail.com Tue Nov 6 07:01:04 2007 From: n.oxyde at gmail.com (N_Ox) Date: Tue Nov 6 07:00:05 2007 Subject: /Library/Frameworks violates layout In-Reply-To: <287DEE27-5557-4456-B4E2-16A6E5C1D4E1@macports.org> References: <8ac9cb6d60087db0bb8f8802c8f132e3@macports.org> <287DEE27-5557-4456-B4E2-16A6E5C1D4E1@macports.org> Message-ID: Le 6 nov. 07 ? 07:05, Juan Manuel Palacios a ?crit : > > So, do we have an agreement on this? Any objections to turning on > warnings against /Library/Frameworks in the upcoming MacPorts 1.6? > I support to move to discourage writing to that directory, gcc's -F > flag should allow any application needing a framework to look for > it under prefix, just as Anders makes it clean in his message. Any > reason why we *shouldn't* move our frameworks into prefix? > > And as for macports1.0, we can still rely on configure's --with- > tclpackage flag to place it inside prefix in customized installations. > > Regards,... > > > -jmpp > > Does --with-tclpackage add some tcl code to the beginning of the port executable to add the path to ${auto_path}? -- Anthony Ramine, the "Ports tree cleaning Maestro". From denys_tkachov at mail.ru Tue Nov 6 07:39:12 2007 From: denys_tkachov at mail.ru (Denis Tkachov) Date: Tue Nov 6 07:38:04 2007 Subject: excel data import on Mac OS X Message-ID: <13609260.post@talk.nabble.com> I am looking for a way to import data from excel on Mac OS X. Development platform - c++ (xcode). Can anybody point me to the way how it may by done on Mac OS? Any help is appreciated. Best regards, Denis -- View this message in context: http://www.nabble.com/excel-data-import-on-Mac-OS-X-tf4758841.html#a13609260 Sent from the MacPorts - Developer mailing list archive at Nabble.com. From afb at macports.org Tue Nov 6 07:42:57 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Nov 6 07:41:59 2007 Subject: 1.6 release? In-Reply-To: <7F25C5D0-1FD3-414F-81C6-61243A4DFA78@gmail.com> References: <7B78B63A-CC2D-4F60-94B0-92368AA8F5A8@macports.org> <7F25C5D0-1FD3-414F-81C6-61243A4DFA78@gmail.com> Message-ID: <54bcf81c235791a1bb5028d58c9c94c5@macports.org> Eugene Pimenov wrote: >> *) Eugene, how "finished" would you call your work on trace mode >> improvements? Other than bugs that you may fix as they are reported, >> do you plan any major changes to the core of your work? > > I'm not planing major changes. I build every port with it, and seems > it work good (for me, of course). Trace mode has a slight annoyance when working with ccache, http://trac.macports.org/projects/macports/ticket/12218 Steps to reproduce: install/enable ccache, build something Would be nice if the rejected patch could be accepted... ? --anders From kw at codebykevin.com Tue Nov 6 07:45:25 2007 From: kw at codebykevin.com (Kevin Walzer) Date: Tue Nov 6 07:44:25 2007 Subject: excel data import on Mac OS X In-Reply-To: <13609260.post@talk.nabble.com> References: <13609260.post@talk.nabble.com> Message-ID: <47308C15.2070909@codebykevin.com> Denis Tkachov wrote: > I am looking for a way to import data from excel on Mac OS X. > Development platform - c++ (xcode). > Can anybody point me to the way how it may by done on Mac OS? > Any help is appreciated. > > Best regards, > Denis This is really OT for this list... You can get at Excel data via AppleScript. I'd Google for "AppleScript Excel" and see what turns up. -- Kevin Walzer Code by Kevin http://www.codebykevin.com From jmpp at macports.org Tue Nov 6 08:51:42 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Nov 6 08:47:24 2007 Subject: /Library/Frameworks violates layout In-Reply-To: References: <8ac9cb6d60087db0bb8f8802c8f132e3@macports.org> <287DEE27-5557-4456-B4E2-16A6E5C1D4E1@macports.org> Message-ID: <83C9280A-F156-46D0-9BC0-1E974DC61292@macports.org> On Nov 6, 2007, at 11:01 AM, N_Ox wrote: > > Le 6 nov. 07 ? 07:05, Juan Manuel Palacios a ?crit : > >> >> So, do we have an agreement on this? Any objections to turning on >> warnings against /Library/Frameworks in the upcoming MacPorts 1.6? >> I support to move to discourage writing to that directory, gcc's - >> F flag should allow any application needing a framework to look >> for it under prefix, just as Anders makes it clean in his message. >> Any reason why we *shouldn't* move our frameworks into prefix? >> >> And as for macports1.0, we can still rely on configure's --with- >> tclpackage flag to place it inside prefix in customized >> installations. >> >> Regards,... >> >> >> -jmpp >> >> > > Does --with-tclpackage add some tcl code to the beginning of the > port executable to add the path to ${auto_path}? Code is added to the port executable, yes, but only in the form of: ---------- (from trunk/base/src/port/Makefile) ---------- edit = sed \ -e 's,@TCLSH\@,$(TCLSH),g' \ -e 's,@TCL_PACKAGE_DIR\@,$(TCL_PACKAGE_DIR),g' ---------- ($(TCL_PACKAGE_DIR) being received from autoconf through --with- tclpackage) ---------- So that: ---------- (from trunk/base/src/port/port.tcl) catch {source \ [file join "@TCL_PACKAGE_DIR@" macports1.0 macports_fastload.tcl]} package require macports The result is that the port executable is able to load the macports1.0 package, wherever it's put by autoconf (/Library/Tcl being the default). But I don't know about ${auto_path}, I don't think anything about the tcl package is added to it; why are you interested in that? -jmpp From jmpp at macports.org Tue Nov 6 09:25:19 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Nov 6 09:21:00 2007 Subject: 1.6 release? In-Reply-To: References: <7B78B63A-CC2D-4F60-94B0-92368AA8F5A8@macports.org> Message-ID: On Nov 6, 2007, at 3:48 AM, markd@macports.org wrote: > Juan Manuel Palacios writes: >> -) documentation people, can we count on rewritten man pages to go >> with 1.6? How far off is the new guide? > > I think it will be awhile before the man pages and guide are done, but > work is ongoing I think both are probably now as useful and > complete as > the old ones, and they are organized such that they can continue > smoothly > to completion. Markus Weissman is to be commended for significant > contributions in the last week. Right now my main goal is > surpassing the > old docs so I can forget about them. I think that goal is fairly > close. > Maybe within a few weeks? Great to see all the advances, kudos! Overall, you think we should ship 1.6 with the old man pages still in place or will the new ones be able to replace them, even if not 100% finished? Also, how are you planning to generate their troff incarnations out of the xml sources? We do need to offer something when a user types "man port" ;-) Regards,... -jmpp From jmpp at macports.org Tue Nov 6 09:32:41 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Nov 6 09:28:22 2007 Subject: 1.6 release? In-Reply-To: References: <7B78B63A-CC2D-4F60-94B0-92368AA8F5A8@macports.org> Message-ID: On Nov 6, 2007, at 7:38 AM, Weissmann Markus wrote: > On 05.11.2007, at 22:16, Juan Manuel Palacios wrote: > >> Hey everyone! >> >> It's very pleasing to see the amount of work that has gone into >> base since our last release, but the negative side of that is that >> our current code delta between trunk and the last release branch >> is huge. Therefore I propose we make a 1.6 release with a new >> release branch from scratch, cut off from trunk ToT. >> >> For that to happen, it would be nice to have some input on the >> current state of trunk: >> >> -) does any developer in particular plan to include new features/ >> improvements in the near future? If so, do these entail any >> obvious instability we should account for? >> *) Markus, anything else we should look forward to in your >> recent slew of build stage related improvements? >> > > Nothing too spectacular: The most significant additions in > configure/build are Anders' parallel build jobs and a bunch of > configure-options for more comfortable access to often-used > environment variables. ACK! Anymore you can foresee you'll be adding soon? It'd be great to package them all in a single release, so that maintainers can start using them in their Portfiles ASAP. > This all has been done very conservative: The configure-options > code is very straight and the parallel build jobs are off by > default. We could switch the default to auto in a later release so > the number of parallel build threads is oriented at the number of > cores of the build machine, but not for 1.6. Maybe 2.0, once we have automated runs going and can conduct massive tests on big groups of ports ;-) > > > -Markus > Regards,... -jmpp From jmpp at macports.org Tue Nov 6 09:50:30 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Nov 6 09:46:12 2007 Subject: 1.6 release? In-Reply-To: References: <7B78B63A-CC2D-4F60-94B0-92368AA8F5A8@macports.org> Message-ID: On Nov 6, 2007, at 8:38 AM, Anders F Bj?rklund wrote: > Juan Manuel Palacios wrote: > >> -) does any developer in particular plan to include new features/ >> improvements in the near future? If so, do these entail any >> obvious instability we should account for? > > The "mpkg" target is left to update to PackageMaker, Can I wait for this before branching...? ;-) > and rpm/python/yum/smart/etc will be updated to RPM 4.5 and Python > 2.5 at some point (currently using RPM 4.4 and Python 2.4) Well, if you're referring to individual ports, those updates can go in at any time. Or do you plan to do anything in base with them? > > "port lint" (which is still a tad broken) How broken? Anything too big that might prompt you to keep it from shipping? Or is it just lacking some polishing that we could wait for? > and build.jobs/build.nice/configure.ccache/configure.distcc are the > biggest additions to MacPorts 1.6 that I have done (as well as some > feature improvements like LZMA and XAR). Every pleased with all the work you've done so far and for having brought you in! Keep it up, kudos! > Unless the new interface (GUI) and new packages (RPM) are ready to > go in time for the 1.6.0 release, which I'm somewhat doubting > whether it's even reasonable and realistic. And they could just as > well go in a "MacPorts 2.0" ? /me starts writing the 2.0 ChangeLog ;-) From markd at macports.org Tue Nov 6 09:58:03 2007 From: markd at macports.org (markd@macports.org) Date: Tue Nov 6 09:56:39 2007 Subject: 1.6 release? In-Reply-To: References: Message-ID: Juan Manuel Palacios writes: > Overall, you think we should ship 1.6 with the old man pages still >in place or will the new ones be able to replace them, even if not >100% finished? You know I forgot that I still have port.1 and macports.conf.5 still to go. And I'm going to be out of town for two weeks this month and then the holidays are here. So I'd say we should go with the old man pages for 1.6, contrary to what I implied in the last message. That said, we're still not far off with man pages and I'd say they could be included in head definitely by end of January and then in the next release after that. It is possible that I could get a lot done in the next two weeks and change all that, but I could not promise. Right now the man pages are holding up the new guide so everything depends on that. If we ship 1.6 with the old man pages, it would be a shame because the new ones have a lot of updated information that the old ones don't. But if the code and doc schedules don't match there isn't much we can do about it I guess. > Also, how are you planning to generate their troff >incarnations out of the xml sources? We do need to offer something >when a user types "man port" ;-) Simon wrote a new doc-new/Makefile so now you just do "make man" and that's it. After completing the man pages port.1 will still be there with all the rest, except I think perhaps portstyle.7's content might be trimmed and merged into one of the portfile man pages. It seems like it may be unnecessary to me, but I haven't looked that close yet. Mark From jmpp at macports.org Tue Nov 6 10:05:45 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Nov 6 10:01:22 2007 Subject: 1.6 release? In-Reply-To: <54bcf81c235791a1bb5028d58c9c94c5@macports.org> References: <7B78B63A-CC2D-4F60-94B0-92368AA8F5A8@macports.org> <7F25C5D0-1FD3-414F-81C6-61243A4DFA78@gmail.com> <54bcf81c235791a1bb5028d58c9c94c5@macports.org> Message-ID: <9D9660AC-C61A-4695-A000-ADF224DFADAA@macports.org> On Nov 6, 2007, at 11:42 AM, Anders F Bj?rklund wrote: > Eugene Pimenov wrote: > >>> *) Eugene, how "finished" would you call your work on trace mode >>> improvements? Other than bugs that you may fix as they are >>> reported, do you plan any major changes to the core of your work? >> >> I'm not planing major changes. I build every port with it, and >> seems it work good (for me, of course). Great to know that "the new & improved trace mode" is basically complete and ready to ship, shinny entry in the ChangeLog! ;-) > > Trace mode has a slight annoyance when working with ccache, > http://trac.macports.org/projects/macports/ticket/12218 > > Steps to reproduce: install/enable ccache, build something > Would be nice if the rejected patch could be accepted... ? What's your opinion about this, Eugene...? I see you didn't comment in the ticket. > > --anders > -jmpp From jmpp at macports.org Tue Nov 6 10:35:36 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Nov 6 10:31:31 2007 Subject: 1.6 release? In-Reply-To: References: Message-ID: On Nov 6, 2007, at 1:58 PM, markd@macports.org wrote: > Juan Manuel Palacios writes: >> Overall, you think we should ship 1.6 with the old man pages still >> in place or will the new ones be able to replace them, even if not >> 100% finished? > > You know I forgot that I still have port.1 and macports.conf.5 > still to > go. And I'm going to be out of town for two weeks this month and > then the > holidays are here. So I'd say we should go with the old man pages for > 1.6, contrary to what I implied in the last message. That said, we're > still not far off with man pages and I'd say they could be included in > head definitely by end of January and then in the next release > after that. > It is possible that I could get a lot done in the next two weeks and > change all that, but I could not promise. Right now the man pages are > holding up the new guide so everything depends on that. OK, no worries about that, have them ready when you can and let us know of your progress, when we'll be able to swap out all of the old and clean the slate with the new. In the mean time we'll do 1.6 with the usual trunk/base/doc/* files. > > If we ship 1.6 with the old man pages, it would be a shame because > the new > ones have a lot of updated information that the old ones don't. > But if > the code and doc schedules don't match there isn't much we can do > about it > I guess. Not too worry.... this only assures us our first surprise for 1.7 ;-) > >> Also, how are you planning to generate their troff >> incarnations out of the xml sources? We do need to offer something >> when a user types "man port" ;-) > > Simon wrote a new doc-new/Makefile so now you just do "make man" and > that's it. After completing the man pages port.1 will still be > there with > all the rest, except I think perhaps portstyle.7's content might be > trimmed and merged into one of the portfile man pages. It seems > like it > may be unnecessary to me, but I haven't looked that close yet. Content organization put aside, we have to figure a way to tie "make man" in the doc-new dir with our make system in trunk/base, so that the regular "./configure && make && make install" dance (called either when installing from source of while selfupdating) gets a set of shiny new pages.... or are you thinking of regen'ing them manually in trunk/doc-new and copying them over to trunk/base/doc/ when you think it's OK to "cut a release" for them? > > Mark Regards,... -jmpp From jmpp at macports.org Tue Nov 6 10:39:46 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Nov 6 10:35:23 2007 Subject: Pallet...? Message-ID: <5A4A9C10-4EE5-4A0C-AD7D-3D8C60B385F0@macports.org> Hello Ryan! I think this question is long overdue, and in a way I would like to apologize for apparently having ignored your seemingly interesting work on Pallet thus far! But trust me, I haven't ;-) So, mind filling us in on what you're doing with Pallet? What's the scope of your project? Tying into the existing MacPorts API to provide a Cocoa front end...? Or are you all the way out there rewriting us entirely? ;-) How's Pallet shaping up? Do you have any demonstrations? roadmap? ETA? Very interested in finding out more about your work, tell us all about it! Regards,.... -jmpp From ryandesign at macports.org Tue Nov 6 10:58:16 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Nov 6 10:57:14 2007 Subject: [30750] trunk/www/includes/common.inc In-Reply-To: <20071106051808.2877A91A3EA@cvs.opensource.apple.com> References: <20071106051808.2877A91A3EA@cvs.opensource.apple.com> Message-ID: <30D5B41D-A5A4-492D-B4AA-C76E20E3B322@macports.org> On Nov 5, 2007, at 23:18, source_changes@macosforge.org wrote: > Revision: 30750 > http://trac.macosforge.org/projects/macports/changeset/30750 > Author: jmpp@macports.org > Date: 2007-11-05 21:18:07 -0800 (Mon, 05 Nov 2007) > > Log Message: > ----------- > > Add a long-ago-suggested-by-Ryan header() to field to includes/ > common.inc to force serving of all our webpages as application/xhtml > +xml documents I did? Gosh, I'm forgetful. > (Ryan, any reason why you orginally suggested "'(...) charset=' . > $encoding" rather than plain "'(...) charset=$encoding'"?) My personal PHP code style is to avoid putting variables inside double-quoted strings. In fact I try to avoid double-quoted strings in general, favoring single-quoted strings where possible. But feel free to use whatever style gives you the most joy. :) > Modified Paths: > -------------- > trunk/www/includes/common.inc > > Modified: trunk/www/includes/common.inc > =================================================================== > --- trunk/www/includes/common.inc 2007-11-06 05:11:45 UTC (rev 30749) > +++ trunk/www/includes/common.inc 2007-11-06 05:18:07 UTC (rev 30750) > @@ -43,6 +43,7 @@ > # Page header > function print_header($title, $encoding) { > global $MPWEB; > + header("Content-Type: application/xhtml+xml; charset=$encoding"); > echo "\n"; > ?> > www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> From jmpp at macports.org Tue Nov 6 11:08:58 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Nov 6 11:04:33 2007 Subject: [30750] trunk/www/includes/common.inc In-Reply-To: <30D5B41D-A5A4-492D-B4AA-C76E20E3B322@macports.org> References: <20071106051808.2877A91A3EA@cvs.opensource.apple.com> <30D5B41D-A5A4-492D-B4AA-C76E20E3B322@macports.org> Message-ID: <339A5E75-37FA-4398-A226-028449C4A603@macports.org> On Nov 6, 2007, at 2:58 PM, Ryan Schmidt wrote: > >> (Ryan, any reason why you orginally suggested "'(...) charset=' . >> $encoding" rather than plain "'(...) charset=$encoding'"?) > > My personal PHP code style is to avoid putting variables inside > double-quoted strings. In fact I try to avoid double-quoted strings > in general, favoring single-quoted strings where possible. But feel > free to use whatever style gives you the most joy. :) I see. The current state of trunk/www (except for legacy/ and localized/, which we're not using) is a mixture of single and double quoted strings; if you have a chance, could you please cd into that dir and straighten the mess out? You are a much more PHP experienced programmer than I am, hands down, so I'll happily follow your advice (I did try to standardize on single quotes a while ago, but left some double ones behind where they probably don't need to exist). Regards,... -jmpp From n.oxyde at gmail.com Tue Nov 6 11:15:04 2007 From: n.oxyde at gmail.com (N_Ox) Date: Tue Nov 6 11:14:04 2007 Subject: /Library/Frameworks violates layout In-Reply-To: <83C9280A-F156-46D0-9BC0-1E974DC61292@macports.org> References: <8ac9cb6d60087db0bb8f8802c8f132e3@macports.org> <287DEE27-5557-4456-B4E2-16A6E5C1D4E1@macports.org> <83C9280A-F156-46D0-9BC0-1E974DC61292@macports.org> Message-ID: Le 6 nov. 07 ? 17:51, Juan Manuel Palacios a ?crit : > > On Nov 6, 2007, at 11:01 AM, N_Ox wrote: > >> >> Le 6 nov. 07 ? 07:05, Juan Manuel Palacios a ?crit : >> >>> >> >> Does --with-tclpackage add some tcl code to the beginning of the >> port executable to add the path to ${auto_path}? > > > Code is added to the port executable, yes, but only in the form of: > > ---------- > (from trunk/base/src/port/Makefile) > ---------- > edit = sed \ > -e 's,@TCLSH\@,$(TCLSH),g' \ > -e 's,@TCL_PACKAGE_DIR\@,$(TCL_PACKAGE_DIR),g' > ---------- > ($(TCL_PACKAGE_DIR) being received from autoconf through --with- > tclpackage) > ---------- > > So that: > > ---------- > (from trunk/base/src/port/port.tcl) > catch {source \ > [file join "@TCL_PACKAGE_DIR@" macports1.0 macports_fastload.tcl]} > package require macports > > > The result is that the port executable is able to load the > macports1.0 package, wherever it's put by autoconf (/Library/Tcl > being the default). But I don't know about ${auto_path}, I don't > think anything about the tcl package is added to it; why are you > interested in that? > > > -jmpp > Oh, I didn't know macports_fastload.tcl, I was talking about $ {auto_path} because that's what I used to find macports1.0 package into ${prefix} in the patch I've submitted: http://trac.macports.org/ projects/macports/ticket/12943 -- Anthony Ramine, the "Ports tree cleaning Maestro". From ryandesign at macports.org Tue Nov 6 11:26:49 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Nov 6 11:25:48 2007 Subject: 1.6 release? In-Reply-To: References: <7B78B63A-CC2D-4F60-94B0-92368AA8F5A8@macports.org> Message-ID: <40643576-BCC4-426E-9DE5-10E84C16CE12@macports.org> On Nov 6, 2007, at 11:50, Juan Manuel Palacios wrote: > On Nov 6, 2007, at 8:38 AM, Anders F Bj?rklund wrote: > >> "port lint" (which is still a tad broken) > > How broken? Anything too big that might prompt you to keep it from > shipping? Or is it just lacking some polishing that we could wait for? Its category checker is overzealous. For example if you "sudo port lint phpmyadmin" you get "Error: Unknown category: php". True, there is no top-level category directory called "php", but we decided that extra "virtual" categories aren't really a problem, so long as the "main" (first) category listed in the portfile is in fact the category directory the port is in. So this should be fixed before releasing 1.6. Otherwise people see the output of port lint and go removing all sorts of allegedly invalid categories when they shouldn't necessarily be doing that. From ryandesign at macports.org Tue Nov 6 11:41:16 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Nov 6 11:40:14 2007 Subject: 1.6 release? In-Reply-To: <7B78B63A-CC2D-4F60-94B0-92368AA8F5A8@macports.org> References: <7B78B63A-CC2D-4F60-94B0-92368AA8F5A8@macports.org> Message-ID: <96FB06DD-4044-41C1-9CDE-D3157484FE26@macports.org> On Nov 5, 2007, at 15:16, Juan Manuel Palacios wrote: > It's very pleasing to see the amount of work that has gone into > base since our last release, but the negative side of that is that > our current code delta between trunk and the last release branch is > huge. Therefore I propose we make a 1.6 release with a new release > branch from scratch, cut off from trunk ToT. > -) on the other hand, is there anything in particular anyone would > like to see *NOT* released to the public just yet? I could think of one controversial change in trunk: the removal of the "cd" command. I estimate[1] that we have 339 ports (about 8% of our 4353 ports) that still use the "cd" command. These ports break without the "cd" command. If I have some time I'll see if I can fix up some of the nomaintainer ones; others should do the same if possible. If we find that we're close to the date when we want to release 1.6 and we still have many ports using "cd", we should delay removing the "cd" feature. [1] cd /path/to/dports grep "[[:space:]]cd[[:space:]]" */*/Portfile \ | grep -v "system[[:space:]]" \ | sed s%/Portfile.*%% \ | uniq \ | wc -l From markd at macports.org Tue Nov 6 12:05:47 2007 From: markd at macports.org (markd@macports.org) Date: Tue Nov 6 12:04:24 2007 Subject: 1.6 release? In-Reply-To: References: Message-ID: Juan Manuel Palacios writes: > Content organization put aside, we have to figure a way to tie "make >man" in the doc-new dir with our make system in trunk/base, so that 1) >the regular "./configure && make && make install" dance (called >either when installing from source of while selfupdating) gets a set >of shiny new pages.... 2) >or are you thinking of regen'ing them manually >in trunk/doc-new and copying them over to trunk/base/doc/ when you >think it's OK to "cut a release" for them? I would think option 1 would be best, unless there is a consensus otherwise. I'm cc'ing doc team on this. I'd prefer "live" docs with head as now. I haven't thought about what Makefile changes would be necessary, and since the other doc team members are better programmers, I probably wouldn't be the one to do it anyway. Mark From ramercer at gmail.com Tue Nov 6 13:26:47 2007 From: ramercer at gmail.com (Adam Mercer) Date: Tue Nov 6 13:25:39 2007 Subject: BUG: devel/bazaar-ng, py25-zlib missing from dependencies (ticket #13176) Message-ID: <799406d60711061326y16c9b21co98b7f3f50e252d79@mail.gmail.com> Hi Can someone with commit access please take a look at ticket #13176 [1] which add py25-zlib as a dependency to the bazaar-ng port? Cheers Adam [1] http://trac.macports.org/projects/macports/ticket/13176 From simon at ruderich.com Tue Nov 6 16:36:31 2007 From: simon at ruderich.com (Simon Ruderich) Date: Tue Nov 6 16:40:49 2007 Subject: 1.6 release? In-Reply-To: References: Message-ID: <20071107003630.GA24274@ruderich.com> On Tue, Nov 06, 2007 at 12:05:47PM -0800, markd@macports.org wrote: > Juan Manuel Palacios writes: > > Content organization put aside, we have to figure a way to tie "make > >man" in the doc-new dir with our make system in trunk/base, so that > > 1) > >the regular "./configure && make && make install" dance (called > >either when installing from source of while selfupdating) gets a set > >of shiny new pages.... > > 2) > >or are you thinking of regen'ing them manually > >in trunk/doc-new and copying them over to trunk/base/doc/ when you > >think it's OK to "cut a release" for them? > > I would think option 1 would be best, unless there is a consensus > otherwise. I'm cc'ing doc team on this. I'd prefer "live" docs with head > as now. I haven't thought about what Makefile changes would be necessary, > and since the other doc team members are better programmers, I probably > wouldn't be the one to do it anyway. > > Mark Hi, I also think 1) is the best way. But there is one problem: To make sure everybody gets the documentation when checking out a copy from svn we either have to move the documentation in the base/doc directory or use svn:externals so it gets downloaded. And as not everybody has a docbook installation on their computer the man pages should be generated before each release and included in the source tarballs. But we have to be "careful" no one modifies the man pages as they are then automatically generated and so any change will be overwritten. Maybe the easiest way is copy the man pages manually before each release. We could add a target to the Makefile of the documentation to move the generated man pages to a given directory, which could be useful for developers to simplify the update process for them. What do you think is the best way to achieve this? Thanks, 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: 186 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20071107/c146e797/attachment-0001.bin From ryandesign at macports.org Tue Nov 6 20:09:06 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Nov 6 20:08:03 2007 Subject: BUG: devel/bazaar-ng, py25-zlib missing from dependencies (ticket #13176) In-Reply-To: <799406d60711061326y16c9b21co98b7f3f50e252d79@mail.gmail.com> References: <799406d60711061326y16c9b21co98b7f3f50e252d79@mail.gmail.com> Message-ID: <8976686C-9F5B-46DC-B4C6-15EAE802F82A@macports.org> On Nov 6, 2007, at 15:26, Adam Mercer wrote: > Can someone with commit access please take a look at ticket #13176 [1] > which add py25-zlib as a dependency to the bazaar-ng port? Committed! Thanks. From boeyms at macports.org Tue Nov 6 21:02:03 2007 From: boeyms at macports.org (Boey Maun Suang) Date: Tue Nov 6 21:00:59 2007 Subject: 1.6 release? In-Reply-To: References: Message-ID: Hi everyone, On 07/11/2007, at 04:58, markd@macports.org wrote: > You know I forgot that I still have port.1 and macports.conf.5 > still to > go. And I'm going to be out of town for two weeks this month and > then the > holidays are here. Sorry that I haven't been as active as I'd like, but if Mark and the rest of you trust me not to screw them up too badly, I think I should be able to rework port(1) and macports.conf(5) in the next fortnight or so (or possibly sooner, if you want it more urgently). Things have been a rather down for me for most of this year, but it's finally starting to come good and I now have free time and, more importantly, am in a fit state to use it. Incidentally, what sort of things were you looking for on the main page, Juan? Kind regards, Maun Suang -- Boey Maun Suang (Boey is my surname) Email: boeyms at macports dot org From rhwood at mac.com Wed Nov 7 07:23:15 2007 From: rhwood at mac.com (Randall Wood) Date: Wed Nov 7 07:22:05 2007 Subject: Pallet...? In-Reply-To: <5A4A9C10-4EE5-4A0C-AD7D-3D8C60B385F0@macports.org> References: <5A4A9C10-4EE5-4A0C-AD7D-3D8C60B385F0@macports.org> Message-ID: On Tuesday, November 06, 2007, at 01:36PM, "Juan Manuel Palacios" wrote: > > Hello Ryan! I'm not aware that Ryan has done any work on Pallet either. That said, if he wants to, he's welcome to. > I think this question is long overdue, and in a way I would like to >apologize for apparently having ignored your seemingly interesting >work on Pallet thus far! But trust me, I haven't ;-) Right now, development on Pallet is mostly stopped. Development on a Cocoa Framework wrapped around the MacPorts API is proceeding, albeit slowly, as I have maybe a couple of hours a week that I can devote to it, and am learning to read Tcl in the process. The MacPorts Framework (https://svn.macosforge.org/projects/macports/browser/users/rhwood/MacPorts.Framework or port MacPorts_Framework) has the following major issues: 1) It does not adequately pass notifications or respond to passed notifications (if an MPPort object's state changes it needs to send a notification so that any other MPPort objects for that same port can sync states - note this is a system wide requirement, not just a single task requirement) 2) It does not throw exceptions when things do not go quite right. Part of this problem is laziness on my part, part of it is inconsistencies in the MacPorts API (different functions return failure/error states differently) 3) The framework remains API incomplete 4) Creating an MPPort object is very expensive 5) The entire thing is basically undocumented - if anyone wants to headerdoc this framework, I'll work with you to figure out what's going on in the code. > So, mind filling us in on what you're doing with Pallet? What's the >scope of your project? Tying into the existing MacPorts API to >provide a Cocoa front end...? Or are you all the way out there >rewriting us entirely? ;-) I'm tying into the MacPorts API, although if I can get significant performance improvements by not using the API, I might rewrite in Cocoa. (For example, until I began using MPPort objects that each made a call against the MacPorts API when initialized, a pure Cocoa method to read the PortIndex was noticeably faster than using the MacPorts API--however it turns out that I lost all those advantages when I wrote the MPPort objects. I'm thinking of rewriting them to make any and all calls against the API lazily (i.e.: only when absolutely required), but I am also aware that the MPIndex needs to figure out the URI to the portfile for an MPPort and pass that in. > How's Pallet shaping up? Do you have any demonstrations? roadmap? ETA? I think that Pallet builds from the port Pallet, but as you can see there is a problem with the UI gumming itself up that I can't figure out. I have not really been working on it other than ripping out parts that have been superseded by using methods from the Framework. > Very interested in finding out more about your work, tell us all >about it! I am very close (planning on starting this weekend) on rewriting the MacPorts Notifier (its distributed via MacPorts) to use the Framework for syncing and then for upgrading ports and once I am satisfied that the Framework is usable in a real-world scenario, in getting it officially into the project and versioning and bundling it for distribution. Maybe I should just document all this on Trac... -- Randall Wood rhwood@mac.com "The ball is round. The game lasts ninety minutes. The rest is theory..." From ryandesign at macports.org Wed Nov 7 07:26:15 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Nov 7 07:25:10 2007 Subject: Pallet...? In-Reply-To: References: <5A4A9C10-4EE5-4A0C-AD7D-3D8C60B385F0@macports.org> Message-ID: On Nov 7, 2007, at 09:23, Randall Wood wrote: > On Tuesday, November 06, 2007, at 01:36PM, Juan Manuel Palacios wrote: > >> Hello Ryan! > > I'm not aware that Ryan has done any work on Pallet either. That > said, if he wants to, he's welcome to. I wasn't aware of that either. ;-P From simon at ruderich.com Wed Nov 7 10:17:40 2007 From: simon at ruderich.com (Simon Ruderich) Date: Wed Nov 7 10:19:15 2007 Subject: Ghemical port and Glut problems Message-ID: <20071107181740.GA28190@ruderich.com> Hi, I tried to create a port for Ghemical [1] and had some problems. After some tries I got it working, but only by patching Glut. The problem is that Glut tries to include GL/gl.h and GL/glu.h which don't exist. So I had to change them to OpenGl/gl.h and OpenGL/glu.h. I also had to change the includes in the Ghemical source code to OpenGl. As Glut has no maintainers I'm not sure if I can change this in the normal port or if this would cause serious problems. Or am I missing something? Thanks for your help, Simon [1]: http://www.bioinformatics.org/ghemical/ghemical/index.html -- + 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: 186 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20071107/673ac9cd/attachment.bin From jmpp at macports.org Wed Nov 7 10:34:01 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Wed Nov 7 10:29:39 2007 Subject: Pallet...? In-Reply-To: References: <5A4A9C10-4EE5-4A0C-AD7D-3D8C60B385F0@macports.org> Message-ID: On Nov 7, 2007, at 11:23 AM, Randall Wood wrote: > On Tuesday, November 06, 2007, at 01:36PM, "Juan Manuel Palacios" > wrote: >> >> Hello Ryan! > > I'm not aware that Ryan has done any work on Pallet either. That > said, if he wants to, he's welcome to. I'm so sorry *Randall*! I'd just finished sending a message to Ryan at that time and when I started writing yours his name slipped out my fingers... only a few characters difference ;-) ---snip--- > I'm tying into the MacPorts API, although if I can get significant > performance improvements by not using the API, I might rewrite in > Cocoa. (For example, until I began using MPPort objects that each > made a call against the MacPorts API when initialized, a pure Cocoa > method to read the PortIndex was noticeably faster than using the > MacPorts API--however it turns out that I lost all those advantages > when I wrote the MPPort objects. I'm thinking of rewriting them to > make any and all calls against the API lazily (i.e.: only when > absolutely required), but I am also aware that the MPIndex needs to > figure out the URI to the portfile for an MPPort and pass that in. Rewriting MacPorts in any language up to any extent is a major, long term endeavor that would naturally spark off a lot of brainstorming around it: -) first and foremost, what language?? (/me phears the holly wars!) -) once that's settled, do we start from scratch with a new design or, on the other hand, try to re-implement the existing one in the new language? -) barring that, how would our new APIs look like? -) and last in this very short list (which could easily be expanded), but certainly by no means least, what do we do to *NOT* loose all the work already invested in our Portfiles? Now, I'm not trying to discourage you in any way.... in fact, I'm more than sure many here would put together a party if we embark on a rewriting endeavor (probably even including me ;-) -- and, in fact, when Landon once considered it, Cocoa was a very strong option -- I am instead asking you to please be most open about it if you are indeed considering a full rewrite of base, as otherwise a solitary effort may result in massive waste of time and resources. ---snip--- > > I am very close (planning on starting this weekend) on rewriting > the MacPorts Notifier (its distributed via MacPorts) to use the > Framework for syncing and then for upgrading ports and once I am > satisfied that the Framework is usable in a real-world scenario, in > getting it officially into the project and versioning and bundling > it for distribution. If your framework does stand up to the test of a real world application we could of course brainstorm over distributing it as a Cocoa glue for Mac OS X native GUIs for MacPorts. I believe that would be a very interesting project to explore! Can you please let us know of your progress when you reach any milestones? > > Maybe I should just document all this on Trac... That would be sweet! > > -- > Randall Wood > rhwood@mac.com Kudos for the hard work and energy devoted to the project! Regards,... -jmpp PS: And sorry again for the Randall/Ryan confusion ;-) From sbranzo at gmail.com Wed Nov 7 12:34:35 2007 From: sbranzo at gmail.com (Sbranzo) Date: Wed Nov 7 12:33:31 2007 Subject: Trac problems and slrn-devel upgrade In-Reply-To: <78BCFC45-C137-4924-9922-D84F17238184@macports.org> References: <20071106130915.GA5897@sbranzo.chinatown> <78BCFC45-C137-4924-9922-D84F17238184@macports.org> Message-ID: <20071107203435.GA606@sbranzo.chinatown> On 06/11/07 15:28, Weissmann Markus wrote: > would it be possible to supply a diff? The attached files has practically > nothing in common with the Portfile in trunk: > $ slrn-devel> diff -u Portfile slrn-devel.portfile | wc -l > 92 > $ slrn-devel> wc -l * > 50 Portfile > 43 slrn-devel.portfile > 93 total Hi, thanks to Olaf Foellinger we have a smaller patch :-). The only thing left is the master_sites directive because I don't know where the sources'll be stored. Gufo -------------- next part -------------- --- Portfile 2007-11-07 20:57:56.000000000 +0100 +++ Portfile.new 2007-11-07 20:57:43.000000000 +0100 @@ -1,10 +1,8 @@ -# $Id: Portfile 24142 2007-04-17 10:28:26Z ryandesign@macports.org $ - PortSystem 1.0 name slrn-devel -set betaversion 0.9.8.1pl2 -set cvsversion 20070125 -version ${betaversion}-${cvsversion} +set betaversion 0.9.9pre +set svnversion 43 +version ${betaversion}-${svnversion} categories news net platforms darwin maintainers sbranzo@gmail.com @@ -17,26 +15,19 @@ the SLang macro language. master_sites http://ftp.debian.org/debian/pool/main/s/slrn/ -distname slrn_${betaversion}~cvs${cvsversion}.orig -worksrcdir slrn-${betaversion}~cvs${cvsversion} -checksums sha1 6154f18f059c707d281a0627c7186cbe376729a4 +distname slrn-${betaversion}-${svnversion} +checksums sha1 67f93dda0f8242477774fb46b6337d5d21a5d137 \ + md5 0d48e077197b23fb1b096b790fa99d0a use_bzip2 no depends_lib port:slang2 \ port:libiconv -# Works for tiger (automake-1.6) -pre-configure { - cd ${worksrcpath}/autoconf - foreach f {config.guess config.sub depcomp install-sh missing} { - delete ${f} - file link ${f} /usr/share/automake-1.6/${f} - } -} - configure.args --with-libiconv-prefix=${prefix} \ --mandir=${prefix}/share/man + --with-slang-library=${prefix}/lib \ + --with-slang-includes=${prefix}/include # adds slrnpull variant pull { configure.args-append --with-slrnpull } From mww at macports.org Wed Nov 7 12:41:50 2007 From: mww at macports.org (Weissmann Markus) Date: Wed Nov 7 12:40:22 2007 Subject: Trac problems and slrn-devel upgrade In-Reply-To: <20071107203435.GA606@sbranzo.chinatown> References: <20071106130915.GA5897@sbranzo.chinatown> <78BCFC45-C137-4924-9922-D84F17238184@macports.org> <20071107203435.GA606@sbranzo.chinatown> Message-ID: <9180B7E6-9800-4761-BB53-B8692E3E73A2@macports.org> On 07.11.2007, at 21:34, Sbranzo wrote: > On 06/11/07 15:28, Weissmann Markus wrote: >> would it be possible to supply a diff? The attached files has >> practically >> nothing in common with the Portfile in trunk: >> $ slrn-devel> diff -u Portfile slrn-devel.portfile | wc -l >> 92 >> $ slrn-devel> wc -l * >> 50 Portfile >> 43 slrn-devel.portfile >> 93 total > > Hi, > thanks to Olaf Foellinger we have a smaller patch :-). > The only thing left is the master_sites directive because I don't know > where the sources'll be stored. > Thats nice -- if you'll hand me the distfile, I'll put it on the MacPorts-Server! -Markus --- Markus W. Weissmann http://www.mweissmann.de/ From markd at macports.org Wed Nov 7 18:29:17 2007 From: markd at macports.org (markd@macports.org) Date: Wed Nov 7 18:27:48 2007 Subject: [30735] trunk/doc-new/man/xml/portfile-phase.7.xml In-Reply-To: References: <20071105193624.B9093918287@cvs.opensource.apple.com> Message-ID: "Daniel J. Luke" writes: >The -j is actually a make option. > >The make manpage describes it like this: > -j [jobs], --jobs[=jobs] > Specifies the number of jobs (commands) to run >simultaneously. If > there is more than one -j option, the last one is >effective. If > the -j option is given without an argument, make will >not limit > the number of jobs that can run simultaneously. > >I believe the idea is that the user can specify the number of >simultaneous jobs they want, and if a port has this flag it will pass >the appropriate -j N (where N is the number of jobs) to make. At some >point, macports will probably be updated to detect a good default >value for N (that the user could override), but I don't believe that >there's code for that yet. Weissmann Markus writes: >I've just added a way to automatically set the number of build jobs >(if desired): >If the number of build jobs is set to "0" (in the config file), the >number of jobs is set to the number of cores. > >This works only on Mac OS X (and FreeBSD -- though untested). I pasted the raw text from my latest doc update on "use_parallel_build". Is this accurate? use_parallel_build This keyword is for specifying whether or not it is safe for a port to use multiple cpus or multiple cores in parallel during its build phase. This keyword passes the -j [jobs] option to make, where jobs is obtained from the variable buildmakejobs in macports.conf. This variable may also be set to 0 so the number of jobs is set to the number of cores detected during the build phase. Mark From ryandesign at macports.org Wed Nov 7 23:41:53 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Nov 7 23:40:44 2007 Subject: [30830] trunk/dports/devel/dialog/Portfile In-Reply-To: <20071108072021.92DFA937A5A@cvs.opensource.apple.com> References: <20071108072021.92DFA937A5A@cvs.opensource.apple.com> Message-ID: <618FC269-5A6E-4E43-9D1D-8D3636B10324@macports.org> On Nov 8, 2007, at 01:20, source_changes@macosforge.org wrote: > Revision: 30830 > http://trac.macosforge.org/projects/macports/changeset/30830 > Author: jwa@macports.org > Date: 2007-11-07 23:20:19 -0800 (Wed, 07 Nov 2007) > > Log Message: > ----------- > adding variant utf8 per request in ticket #13118, ncursesw > dependency is not needed as already provided by ncurses Is there a reason why you're not just enabling this all the time? Why is it a variant? > Modified Paths: > -------------- > trunk/dports/devel/dialog/Portfile > > Modified: trunk/dports/devel/dialog/Portfile > =================================================================== > --- trunk/dports/devel/dialog/Portfile 2007-11-08 06:40:34 UTC (rev > 30829) > +++ trunk/dports/devel/dialog/Portfile 2007-11-08 07:20:19 UTC (rev > 30830) > @@ -6,7 +6,6 @@ > epoch 20071028 > categories devel > maintainers jwa > -#maintainers jyrki.wahlstedt@hut.fi > > description A utility to create nice user interfaces to shell > scripts, \ > or other scripting languages, such as perl. > @@ -66,5 +65,9 @@ > configure.compiler gcc-4.0 > } > > +variant utf8 { > + configure.args-append --with-ncursesw > +} > + > livecheck.check moddate > livecheck.url ${homepage}CHANGES From adamore at email.it Wed Nov 7 23:48:45 2007 From: adamore at email.it (Andrea D'Amore) Date: Wed Nov 7 23:47:33 2007 Subject: bochs updated Message-ID: <539BF866-380A-47C8-BEB6-54F72E35D95C@email.it> Hi, I've just filed ticket 13194 with the bochs Portfile for 2.3.5, pls have a look. Bye Andrea From jwa at macports.org Wed Nov 7 23:55:37 2007 From: jwa at macports.org (Jyrki Wahlstedt) Date: Wed Nov 7 23:54:24 2007 Subject: [30830] trunk/dports/devel/dialog/Portfile In-Reply-To: <618FC269-5A6E-4E43-9D1D-8D3636B10324@macports.org> References: <20071108072021.92DFA937A5A@cvs.opensource.apple.com> <618FC269-5A6E-4E43-9D1D-8D3636B10324@macports.org> Message-ID: On 8.11.2007, at 9.41, Ryan Schmidt wrote: > Is there a reason why you're not just enabling this all the time? > Why is it a variant? Well, that was the request. Maybe this could be lifted to be default in the next revision? ! ! Jyrki Wahlstedt ! http://www.wahlstedt.fi/jyrki/ ! ! Our life is no dream; but it ought to become one and perhaps will. ! PGP key ID: 0x139CC386 fingerprint: F355 B46F 026C B8C1 89C0 A780 6366 EFD9 139C C386 From adamore at email.it Wed Nov 7 23:55:48 2007 From: adamore at email.it (Andrea D'Amore) Date: Wed Nov 7 23:54:36 2007 Subject: Two small ports, fdupes packddir Message-ID: <1FD1E503-D26C-4780-BCC0-F83F6558F045@email.it> Hello, I've filed two tickets about two small utilities that have no dependencies, tickets numbers are 13109 and 13133. It's my first attempt at writing a Portfile from scratch so pls have a look at them. Bye Andrea From ryandesign at macports.org Thu Nov 8 00:10:55 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Nov 8 00:09:46 2007 Subject: bochs updated In-Reply-To: <539BF866-380A-47C8-BEB6-54F72E35D95C@email.it> References: <539BF866-380A-47C8-BEB6-54F72E35D95C@email.it> Message-ID: On Nov 8, 2007, at 01:48, Andrea D'Amore wrote: > Hi, I've just filed ticket 13194 projects/macports/ticket/13194> > with the bochs Portfile for 2.3.5, pls have a look. I committed your update. Thanks! From markd at macports.org Thu Nov 8 00:20:14 2007 From: markd at macports.org (markd@macports.org) Date: Thu Nov 8 00:18:49 2007 Subject: 1.6 release? In-Reply-To: References: Message-ID: Boey Maun Suang writes: >Sorry that I haven't been as active as I'd like, but if Mark and the >rest of you trust me not to screw them up too badly, I think I should >be able to rework port(1) and macports.conf(5) in the next fortnight >or so (or possibly sooner, if you want it more urgently). Things >have been a rather down for me for most of this year, but it's >finally starting to come good and I now have free time and, more >importantly, am in a fit state to use it. Hello Maun Suang, Of course we trust you! Any help you find time for would always be appreciated. I don't think there is any urgency unless someone feels the urge to get done before 1.6. I feel some urgency just to get it done for my own sake, but I'm probably going to have to pause for a little while anyway. I still have these pages to go: port.1 macports.conf.5 portfile-tcl Let us know if you have any questions about what we've done so far. Nothing is written in stone so if you see room for changes or improvement, please feel free to speak up. Mark From rhwood at mac.com Wed Nov 7 17:54:16 2007 From: rhwood at mac.com (Randall Wood) Date: Thu Nov 8 01:19:33 2007 Subject: Pallet...? In-Reply-To: References: <5A4A9C10-4EE5-4A0C-AD7D-3D8C60B385F0@macports.org> Message-ID: <9D8FCF73-BAFE-4843-9557-C8A3B50EB922@mac.com> On 7 Nov 2007, at 13:34, Juan Manuel Palacios wrote: > > On Nov 7, 2007, at 11:23 AM, Randall Wood wrote: > >> On Tuesday, November 06, 2007, at 01:36PM, "Juan Manuel Palacios" >> wrote: [snip] >> I'm tying into the MacPorts API, although if I can get significant >> performance improvements by not using the API, I might rewrite in >> Cocoa. (For example, until I began using MPPort objects that each >> made a call against the MacPorts API when initialized, a pure >> Cocoa method to read the PortIndex was noticeably faster than >> using the MacPorts API--however it turns out that I lost all those >> advantages when I wrote the MPPort objects. I'm thinking of >> rewriting them to make any and all calls against the API lazily >> (i.e.: only when absolutely required), but I am also aware that >> the MPIndex needs to figure out the URI to the portfile for an >> MPPort and pass that in. > > > Rewriting MacPorts in any language up to any extent is a major, > long term endeavor that would naturally spark off a lot of > brainstorming around it: The only process that I am (re)writing is getting a list of all ports (return [mportsearch]) since it is reportedly significantly faster to parse all of a user's PortIndex files into an NSDictionary than to use the MacPorts Tcl API to do so. > -) first and foremost, what language?? (/me phears the holly wars!) The Framework is being written to support Cocoa/Objective C GUI programs on Mac OS X, so its in Cocoa/Objective C. Although in a private email, someone did ask if I knew of a Python API for MacPorts. > -) once that's settled, do we start from scratch with a new design > or, on the other hand, try to re-implement the existing one in the > new language? I am a firm believer in object orientation, so my Framework does not provide a function-to-function mapping of the Tcl API as sometimes it just hasn't made sense to do things that way in an object oriented Framework. > -) barring that, how would our new APIs look like? > -) and last in this very short list (which could easily be > expanded), but certainly by no means least, what do we do to *NOT* > loose all the work already invested in our Portfiles? > > Now, I'm not trying to discourage you in any way.... in fact, I'm > more than sure many here would put together a party if we embark on > a rewriting endeavor (probably even including me ;-) -- and, in > fact, when Landon once considered it, Cocoa was a very strong > option -- I am instead asking you to please be most open about it > if you are indeed considering a full rewrite of base, as otherwise > a solitary effort may result in massive waste of time and resources. I don't want the work either. > ---snip--- > >> I am very close (planning on starting this weekend) on rewriting >> the MacPorts Notifier (its distributed via MacPorts) to use the >> Framework for syncing and then for upgrading ports and once I am >> satisfied that the Framework is usable in a real-world scenario, >> in getting it officially into the project and versioning and >> bundling it for distribution. > > If your framework does stand up to the test of a real world > application we could of course brainstorm over distributing it as a > Cocoa glue for Mac OS X native GUIs for MacPorts. I believe that > would be a very interesting project to explore! Can you please let > us know of your progress when you reach any milestones? My only real concern is how do we ensure that we can push the GUI through our systems? Every single GUI that I've seen mentioned on the lists is closed and we can't redistribute through MacPorts (or worse the GUI uses some other mechanism to self update). >> Maybe I should just document all this on Trac... > > That would be sweet! > >> >> -- >> Randall Wood >> rhwood@mac.com > > > Kudos for the hard work and energy devoted to the project! > Regards,... > > > -jmpp > > PS: And sorry again for the Randall/Ryan confusion ;-) > Randall Wood rhwood@mac.com http://shyramblings.blogspot.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From ryandesign at macports.org Thu Nov 8 01:24:50 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Nov 8 01:23: