From jmpp at macports.org Sat Sep 1 01:12:14 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:35 2007 Subject: Duplicate port: stgit Message-ID: <01E6E10E-0452-4C52-BD2C-11D02EC02181@macports.org> Hey Simon! Very glad to see you're already working hard as a member of the team, keep those new ports coming in ;-) However, one issue I must raise to your attention is your r28450 commit, in which you added the python/stgit port. It happens that this port already existed in the tree as devel/stgit, and having duplicates creates some problems we want to avoid. Could you please look into merging your recent addition with the former? Thanks and kudos for your great work! Regards,... -jmpp From ryandesign at macports.org Sat Sep 1 01:35:25 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:35 2007 Subject: daemondo defeats purpose of launchd? Message-ID: I have this problem: the lighttpd web server on my MacBook Pro unexpectedly dies rather frequently (much more frequently than it did on my PowerBook). When this happens, the daemondo process is still there, and I have to use launchctl to unload and then load the lighttpd plist to get the server running again. The point of launchd is that it notices when processes unexpectedly quit, and restarts them automatically so close to no downtime is observed. But launchd is monitoring daemondo, which does not exit, so launchd does not restart anything. And daemondo doesn't seem to have the same process-death-noticing feature so daemondo is not automatically restarting the failed lighttpd. Comments? From mww at macports.org Sat Sep 1 04:20:27 2007 From: mww at macports.org (Weissmann Markus) Date: Tue Oct 9 16:40:35 2007 Subject: [28325] trunk/dports/graphics/wxWidgets-devel/Portfile In-Reply-To: <4E8DDB2E-0AB0-4311-AE7A-CCAD2FD30C72@gmail.com> References: <20070828101842.B312975393A@cvs.opensource.apple.com> <8AC7C222-67AA-4913-90F3-237884375E9B@macports.org> <4E8DDB2E-0AB0-4311-AE7A-CCAD2FD30C72@gmail.com> Message-ID: <01EA8DDA-16E4-415A-B4F4-ED701A3E747C@macports.org> On 31.08.2007, at 16:21, N_Ox wrote: > Le 30 ao?t 07 ? 19:40, Anders F Bj?rklund a ?crit : > >> Ryan Schmidt wrote: >> >>> Why do we keep repeating these lines in so many portfiles? Why >>> isn't "configure.compiler gcc-4.0" the default on darwin 8, and >>> similarly, "configure.compiler gcc-3.3" the default on darwin 7? >> >> +1 >> >> If nothing else, it keeps those pesky "+darwin_8" variants alive. :-( >> >> --anders >> > > I don't even understand why there is a default compiler hard > written in ports. > gcc-4 is the default on Tiger, users who change this behaviour > surely know some things may break. > The problem is that a user can use 'gcc_select' and you have no idea what 'gcc' .. executes on 10.4; if you know that your port is happy with any of the two, dont use a platform statement. If you dont want or dont can (e. g. on x86) to test your port with both compilers, state explicitly which one you know it compiles with. I have no idea what will happen to every single port if we tell port to automatically select a compiler if none is requested explicitly (though we can have a try). Regards, -Markus --- Markus W. Weissmann http://www.mweissmann.de/ http://www.macports.org/ From mww at macports.org Sat Sep 1 06:07:05 2007 From: mww at macports.org (Weissmann Markus) Date: Tue Oct 9 16:40:35 2007 Subject: Default compiler suite (was Re:[28325] trunk/dports/graphics/wxWidgets-devel/Portfile) In-Reply-To: <01EA8DDA-16E4-415A-B4F4-ED701A3E747C@macports.org> References: <20070828101842.B312975393A@cvs.opensource.apple.com> <8AC7C222-67AA-4913-90F3-237884375E9B@macports.org> <4E8DDB2E-0AB0-4311-AE7A-CCAD2FD30C72@gmail.com> <01EA8DDA-16E4-415A-B4F4-ED701A3E747C@macports.org> Message-ID: On 01.09.2007, at 13:20, Weissmann Markus wrote: > On 31.08.2007, at 16:21, N_Ox wrote: > >> Le 30 ao?t 07 ? 19:40, Anders F Bj?rklund a ?crit : >> >>> Ryan Schmidt wrote: >>> >>>> Why do we keep repeating these lines in so many portfiles? Why >>>> isn't "configure.compiler gcc-4.0" the default on darwin 8, and >>>> similarly, "configure.compiler gcc-3.3" the default on darwin 7? >>> >>> +1 >>> >>> If nothing else, it keeps those pesky "+darwin_8" variants >>> alive. :-( >>> >>> --anders >>> >> >> I don't even understand why there is a default compiler hard >> written in ports. >> gcc-4 is the default on Tiger, users who change this behaviour >> surely know some things may break. >> > > The problem is that a user can use 'gcc_select' and you have no > idea what 'gcc' .. executes on 10.4; if you know that your port is > happy with any of the two, dont use a platform statement. If you > dont want or dont can (e. g. on x86) to test your port with both > compilers, state explicitly which one you know it compiles with. > I have no idea what will happen to every single port if we tell > port to automatically select a compiler if none is requested > explicitly (though we can have a try). > 'portconfigure.tcl' from trunk will chose a default for darwin 7/8/9 (gcc3.3/4.0/4.0). Please test it! Just replacing /opt/local/share/ macports/Tcl/port1.0/portconfigure.tcl with http://svn.macports.org/ repository/macports/trunk/base/src/port1.0/portconfigure.tcl manually should do the trick. This version also fixes a bug that when using configure.compiler every user-added compiler selection (e.g. 'configure.cc /bin/true') was overwritten. -Markus --- Markus W. Weissmann http://www.mweissmann.de/ --- Markus W. Weissmann http://www.mweissmann.de/ From simon at ruderich.com Sat Sep 1 06:01:12 2007 From: simon at ruderich.com (Simon Ruderich) Date: Tue Oct 9 16:40:35 2007 Subject: Duplicate port: stgit In-Reply-To: <01E6E10E-0452-4C52-BD2C-11D02EC02181@macports.org> References: <01E6E10E-0452-4C52-BD2C-11D02EC02181@macports.org> Message-ID: <46D96298.7060405@ruderich.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Juan Manuel Palacios wrote: > > Hey Simon! > > Very glad to see you're already working hard as a member of the > team, keep those new ports coming in ;-) > > However, one issue I must raise to your attention is your r28450 > commit, in which you added the python/stgit port. It happens that this > port already existed in the tree as devel/stgit, and having duplicates > creates some problems we want to avoid. Could you please look into > merging your recent addition with the former? I'm sorry for this. I missed it completely. I removed my port in python/stgit and added a small part (depends_run) to the existing port in devel/stgit. Thanks for the hint. > Thanks and kudos for your great work! Regards,... I'm glad I can finally help macports ;-) > -jmpp Simon - -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFG2WKXYRX4BO+zMikRCt2aAKDHrGvGbxgGJnpg/v4FzrJpyuMY0ACgqzkC s/IwYszVI0Q8WTPRd8xGoyM= =HJGn -----END PGP SIGNATURE----- From sfiera at macports.org Sat Sep 1 09:47:32 2007 From: sfiera at macports.org (Chris Pickel) Date: Tue Oct 9 16:40:35 2007 Subject: daemondo defeats purpose of launchd? In-Reply-To: References: Message-ID: On 01 Sep, 2007, at 4:35, Ryan Schmidt wrote: > I have this problem: the lighttpd web server on my MacBook Pro > unexpectedly dies rather frequently (much more frequently than it > did on my PowerBook). When this happens, the daemondo process is > still there, and I have to use launchctl to unload and then load > the lighttpd plist to get the server running again. > > The point of launchd is that it notices when processes unexpectedly > quit, and restarts them automatically so close to no downtime is > observed. But launchd is monitoring daemondo, which does not exit, > so launchd does not restart anything. And daemondo doesn't seem to > have the same process-death-noticing feature so daemondo is not > automatically restarting the failed lighttpd. Agreed. I try to avoid daemondo when possible. When it isn't possible, daemondo is an indispensable tool, but it turns out that for most cases, it's possible to avoid it. I've written many launchd scripts on my own, several of which I've put online [1]. It's possible to make launchd scripts similar to these in MacPorts via startupitem.executable, but currently, the startupitem.* commands in MacPorts do not support setting the "User" key. For lighttpd, that's not necessary; it starts as root so it can listen on the privileged port 80, then drops privileges. For mysql, though, it's pretty important. There's also no support for inetd, which I use for rsyncd and cups- lpd--but these are not things I expect MacPorts to install scripts for anyway. Chris [1] http://xml.sfiera.net/ -------------- 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/20070901/bc4a0754/PGP.bin From chiara.sandionigi at mac.com Sat Sep 1 10:05:14 2007 From: chiara.sandionigi at mac.com (Chiara Sandionigi) Date: Tue Oct 9 16:40:35 2007 Subject: Binutils installation problem In-Reply-To: References: <327271D8-9642-4E28-AD56-869B6CF36B90@mac.com> <7756872d369728944d04d6b96e4b0ec4@macports.org> Message-ID: On 01/set/07, at 01:26, Ryan Schmidt wrote: > > On Aug 31, 2007, at 09:48, Anders F Bj?rklund wrote: > >> On Aug 31, 2007, at 09:41, Chiara Sandionigi wrote: >> >>> On Aug 30, 2007, at 12:46, Anders F Bj?rklund wrote: >>> >>>> Chiara Sandionigi wrote: >>>> >>>>> I need to install GNU Binutils but I get the following error >>>>> during >>>>> installation >>>>> >>>>> cc: unrecognized option '-no-cpp-precomp' >>>> >>>> This flag shouldn't be needed for Panther and beyond (gcc-3.3+) >>>> >>>> However, my Apple GCC compiler still seems to recognize it. >>>> What platform are you trying to build the binutils port on ? >>> >>> I work on a MacBook with Mac OS X 10.4 and with gcc 4.2.1 >> >> Ah, OK... The Portfile is probably not set up to handle the >> FSF GCC but assumes you are using the Apple GCC (/usr/bin/gcc). >> If you have such a non-standard gcc in your path, then you'll >> probably run into port problems with more than just binutils ? >> >> I suggest moving GCC 4.2.1 out of the default paths at least. >> But the port should probably not add -cpp-precomp for new GCC, >> and it will fail with the FSF GCC (including other platforms). >> Not sure how to do it in Tcl, but could be done with "system". > > I have submitted a ticket: > > http://trac.macosforge.org/projects/macports/ticket/12584 Now I'm using Apple GCC 4.0.1, but I have another error cc1: error: unrecognized command line option "-Wc++-compat" From landonf at macports.org Sat Sep 1 10:45:57 2007 From: landonf at macports.org (Landon Fuller) Date: Tue Oct 9 16:40:35 2007 Subject: Default compiler suite (was Re:[28325] trunk/dports/graphics/wxWidgets-devel/Portfile) In-Reply-To: References: <20070828101842.B312975393A@cvs.opensource.apple.com> <8AC7C222-67AA-4913-90F3-237884375E9B@macports.org> <4E8DDB2E-0AB0-4311-AE7A-CCAD2FD30C72@gmail.com> <01EA8DDA-16E4-415A-B4F4-ED701A3E747C@macports.org> Message-ID: <0EA02FB8-8E65-4F80-B82A-E2DB5A2BE137@macports.org> On Sep 1, 2007, at 6:07 AM, Weissmann Markus wrote: > 'portconfigure.tcl' from trunk will chose a default for darwin > 7/8/9 (gcc3.3/4.0/4.0). Please test it! Just replacing /opt/local/ > share/macports/Tcl/port1.0/portconfigure.tcl with http:// > svn.macports.org/repository/macports/trunk/base/src/port1.0/ > portconfigure.tcl manually should do the trick. > > This version also fixes a bug that when using configure.compiler > every user-added compiler selection (e.g. 'configure.cc /bin/true') > was overwritten. This is going to break ports that require a different compiler, but specify the compiler using configure.env, or arguments to configure via configure.args. It's a shame that there are no auto-builds, as we don't know what will break. At the very least, would you be opposed to a new flag that enables (or disables) this behavior? -landonf -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070901/f85351ad/PGP.bin From markd at macports.org Sat Sep 1 10:57:10 2007 From: markd at macports.org (markd@macports.org) Date: Tue Oct 9 16:40:35 2007 Subject: daemondo defeats purpose of launchd? In-Reply-To: References: Message-ID: Chris Pickel writes: >There's also no support for inetd, which I use for rsyncd and cups- >lpd--but these are not things I expect MacPorts to install scripts >for anyway. inetd support wouldn't be hard; I hacked together support for it in this ticket: https://svn.macosforge.org/projects/macports/ticket/11824 But it still needs a little refinement for detecting the presence of the keyword combinations. But as far as I know, when you specify the keywords as it expects it does work. Mark From ryandesign at macports.org Sat Sep 1 13:45:54 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:35 2007 Subject: [28325] trunk/dports/graphics/wxWidgets-devel/Portfile In-Reply-To: <01EA8DDA-16E4-415A-B4F4-ED701A3E747C@macports.org> References: <20070828101842.B312975393A@cvs.opensource.apple.com> <8AC7C222-67AA-4913-90F3-237884375E9B@macports.org> <4E8DDB2E-0AB0-4311-AE7A-CCAD2FD30C72@gmail.com> <01EA8DDA-16E4-415A-B4F4-ED701A3E747C@macports.org> Message-ID: On Sep 1, 2007, at 06:20, Weissmann Markus wrote: > On 31.08.2007, at 16:21, N_Ox wrote: > >> Le 30 ao?t 07 ? 19:40, Anders F Bj?rklund a ?crit : >> >>> Ryan Schmidt wrote: >>> >>>> Why do we keep repeating these lines in so many portfiles? Why >>>> isn't "configure.compiler gcc-4.0" the default on darwin 8, and >>>> similarly, "configure.compiler gcc-3.3" the default on darwin 7? >>> >>> +1 >>> >>> If nothing else, it keeps those pesky "+darwin_8" variants >>> alive. :-( >> >> I don't even understand why there is a default compiler hard >> written in ports. >> gcc-4 is the default on Tiger, users who change this behaviour >> surely know some things may break. > > The problem is that a user can use 'gcc_select' and you have no > idea what 'gcc' .. executes on 10.4; if you know that your port is > happy with any of the two, dont use a platform statement. If you > dont want or dont can (e. g. on x86) to test your port with both > compilers, state explicitly which one you know it compiles with. (I'm speaking of Tiger users here, which should be most of us:) I really don't think that any port authors, for every update of every port that they maintain, try it once with gcc 4 and once with gcc 3.3. Rather, I think they probably just try it with the default compiler selected on their machine, which would hopefully be gcc 4. By your logic, then, every such port should have gcc 4 listed in the darwin 8 section, to show that that's what it's been tested with. So, instead of that, it would be much better to do it globally at the MacPorts level, since it's reasonable to assume that ports on Tiger have been tested with Tiger's default compiler. Only ports that deviate from this (for example, the rare port that still requires gcc 3.3 on Tiger) should have to indicate this. > I have no idea what will happen to every single port if we tell > port to automatically select a compiler if none is requested > explicitly (though we can have a try). Let's work through some scenarios then. Let us assume that the ports about which we're talking currently compile correctly and work. (If they don't, then the ports need to be updated anyway.) Assume there is a port that does not indicate what compiler it requires. On a standard Tiger system where gcc 4 is selected, it will currently use gcc 4. If we now change MacPorts so that gcc 4 is used on Tiger in preference to whatever gcc_select says, nothing changes. The port continues to use gcc 4 and continues to work. Using the same port, let's assume some user has used gcc_select to select gcc 3.3 without understanding the implications. They build this port. It happens to work. Great, no problem. If we change MacPorts so that gcc 4 is the default, the port continues to work. Great. Using the same port and the same user who selected gcc 3.3, let's assume the port fails to build under gcc 3.3. In this case, with current MacPorts, the port fails and the user complains. If we change MacPorts to use gcc 4 as the default, the port would instead work, and the user would be happy. So this is a reason to change MacPorts as I indicated. Let's move on to a different port, one that explicitly lists gcc 4 for Tiger. In all scenarios, there is no change. Whether the user has gcc 4 or gcc 3.3 selected, the port works, because it explicitly asks for gcc 4. Great. And let's look at yet another port, one that explicitly lists gcc 3.3 for Tiger. In all scenarios, there is no change. Whether the user has gcc 4 or gcc 3.3 selected, the port works, because it explicitly asks for gcc 3.3. To sum up: if we make gcc 4 the default for ports on Tiger, nothing changes for ports that explicitly request a different compiler. Nothing changes for users who already have gcc 4 selected, which should be most people. The only thing that changes is that users who have for some reason selected gcc 3.3, and for ports that do not specify a compiler, these ports will use gcc 4 instead of gcc 3.3. And this is a good thing, because gcc 4 is probably what the port author tested with. And so the port has a greater chance of working correctly for the user. And then we can also remove the "gcc 4" selections from the darwin 8 variants of all ports where that occurs, since that's redundant, and it's good to remove redundancy. From ryandesign at macports.org Sat Sep 1 13:49:34 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:35 2007 Subject: daemondo defeats purpose of launchd? In-Reply-To: References: Message-ID: <4D80FE3E-E697-495D-AE45-C7C521685EB0@macports.org> On Sep 1, 2007, at 11:47, Chris Pickel wrote: > On 01 Sep, 2007, at 4:35, Ryan Schmidt wrote: > >> I have this problem: the lighttpd web server on my MacBook Pro >> unexpectedly dies rather frequently (much more frequently than it >> did on my PowerBook). When this happens, the daemondo process is >> still there, and I have to use launchctl to unload and then load >> the lighttpd plist to get the server running again. >> >> The point of launchd is that it notices when processes >> unexpectedly quit, and restarts them automatically so close to no >> downtime is observed. But launchd is monitoring daemondo, which >> does not exit, so launchd does not restart anything. And daemondo >> doesn't seem to have the same process-death-noticing feature so >> daemondo is not automatically restarting the failed lighttpd. > > Agreed. I try to avoid daemondo when possible. When it isn't > possible, daemondo is an indispensable tool, but it turns out that > for most cases, it's possible to avoid it. I've written many > launchd scripts on my own, several of which I've put online [1]. > > It's possible to make launchd scripts similar to these in MacPorts > via startupitem.executable, but currently, the startupitem.* > commands in MacPorts do not support setting the "User" key. For > lighttpd, that's not necessary; it starts as root so it can listen > on the privileged port 80, then drops privileges. For mysql, > though, it's pretty important. Thanks, I didn't even know about startupitem.executable. According to the new guide, it's the preferred startupitem method, but only 10 ports currently use it! I'll have to look into it. From ryandesign at macports.org Sat Sep 1 13:52:13 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:35 2007 Subject: Default compiler suite (was Re:[28325] trunk/dports/graphics/wxWidgets-devel/Portfile) In-Reply-To: <0EA02FB8-8E65-4F80-B82A-E2DB5A2BE137@macports.org> References: <20070828101842.B312975393A@cvs.opensource.apple.com> <8AC7C222-67AA-4913-90F3-237884375E9B@macports.org> <4E8DDB2E-0AB0-4311-AE7A-CCAD2FD30C72@gmail.com> <01EA8DDA-16E4-415A-B4F4-ED701A3E747C@macports.org> <0EA02FB8-8E65-4F80-B82A-E2DB5A2BE137@macports.org> Message-ID: <42F142B4-DBF5-4899-BB29-A9A267EF1BE3@macports.org> On Sep 1, 2007, at 12:45, Landon Fuller wrote: > On Sep 1, 2007, at 6:07 AM, Weissmann Markus wrote: > >> 'portconfigure.tcl' from trunk will chose a default for darwin >> 7/8/9 (gcc3.3/4.0/4.0). Please test it! Just replacing /opt/local/ >> share/macports/Tcl/port1.0/portconfigure.tcl with http:// >> svn.macports.org/repository/macports/trunk/base/src/port1.0/ >> portconfigure.tcl manually should do the trick. >> >> This version also fixes a bug that when using configure.compiler >> every user-added compiler selection (e.g. 'configure.cc /bin/ >> true') was overwritten. > > This is going to break ports that require a different compiler, but > specify the compiler using configure.env, or arguments to configure > via configure.args. Then we should start cleaning ports. All those that specify a different compiler via configure.env should be updated to use configure.cc, etc. Those that use configure.args (or build.args I've also seen) should... I don't know, be tested to see if they can instead use configure.cc (or build.cc, etc.; do we have that?). > It's a shame that there are no auto-builds, as we don't know what > will break. > > At the very least, would you be opposed to a new flag that enables > (or disables) this behavior? From ryandesign at macports.org Sat Sep 1 14:09:43 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:35 2007 Subject: Death of Hexley? ... was "Re(2): New website!" In-Reply-To: References: <9fb438449c6e3bd8b7bc63027edd491b@macports.org> Message-ID: On Aug 29, 2007, at 10:37, markd wrote: > Anders F Bj?rklund writes: > >> I like it a lot! It also gets away from Hexley, now that it's not >> doing >> Darwin... > > So is Hexley's use deprecated for OS X? I still associated him with > Darwin, even though OpenDarwin is no more. I still have him in > some other > documentation I have. I'm in favor of getting rid of Hexley. Never liked him. The goal of MacPorts should be to eventually appeal to any Mac user, and I don't feel that the image of a thing with devil horns and a pitchfork, no matter how cute or how lovingly rendered in Aqua style, is appropriate. :-/ From ryandesign at macports.org Sat Sep 1 14:11:05 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:35 2007 Subject: New website! ... not yet, really (Fwd: [28303] trunk/www) In-Reply-To: <272F2AC6-AF5A-432B-ACC5-F7A811B0F6DE@macports.org> References: <20070828010047.549A175305A@cvs.opensource.apple.com> <4B9E2A2A-D696-44BD-803A-87996B208E1C@macports.org> <272F2AC6-AF5A-432B-ACC5-F7A811B0F6DE@macports.org> Message-ID: On Aug 30, 2007, at 11:32, Juan Manuel Palacios wrote: > (DISCLAIMER after reading my message before hitting send: Hope it > doesn't come off as confrontational, that's really not my > intention! Rather, I want to be really sharp at pointing out our > shortcomings so that we can do a better job at fixing them) > > On Aug 28, 2007, at 12:33 PM, Weissmann Markus wrote: > >> I personally like the services that Apple provides for us via >> macosforge; with this installation we do have someone who is >> updating our software and caring about our server. >> Therefore I'd rather prefer to try to modify the macosforge >> provided framework to meet our needs, at least as far as this is >> possible. We can still add a ports page and a documentation >> subdirectory and keep the wordpress installation etc. > > I'm not proposing we forego any of Mac OS Forge's services if we > don't strictly have to, nor that we go back to our old website > (certainly not that! --not because of its functionality, which was > good, but because of its outdated look & feel--). All I had in mind > when recovering trunk/www/ from the ashes is that people take a > good look at those pages in their rendered form to better asses > what we'll need and what we'll discard in a new design going forward. Mmm.... Better asses... (I think there's an "s" missing there.... :)) > What I am indeed proposing is that we use the services we > currently have at our disposal in a dramatically improved and more > efficient manner. We now have on one end a wordpress front posing > as a sorely lacking home page for the project; and on the other > end, for the most part disjoint from the former, a considerably > disorganized trac front that, OK, is good at its main purpose of > tracking issue tickets and serving a source browser portal, but for > the rest is really inconsistent with the overall project look and > feel which we... eeeehhhhhhhhh, hhhhhmmmmmm, don't even have to > begin with! > > Added to that, our current layout has no space for a guide section > nor an "Available Ports" page providing dynamic listings our > software offerings, something many many users have been craving for > ever since we moved away from OpenDarwin. Those two areas of our > old site now exist mostly as independent efforts (http:// > geeklair.net/new_macports_guide/ & http://apollo.homeunix.net/ > macports/ports.php), so in my opinion they are even more than > disjoint from the two fronts listed above. > > We clearly need to get our act together and correct the current > situation by developing a unified site that does our web presence > the justice the project deserves. Take a look, for example, at > Adium's web page, www.adiumx.com, and focus on how their portal > integrates rather seamlessly with a blog, trac services and other > sections users might be interested in, both in functionality and in > look & feel. No need to stress what a long way a clean design like > that can go in making the whole web experience a valuable one... > something not many have expressed about our current site, if anyone... > > With this initiative I'm stating that we need a whole new website, > complete with redesigned functionality, new look & feel and, if > resources allow, a new project logo (& mascot ;-). We are all aware > that's quite a bit of an undertaking, I'm not day dreaming here, so > lets try to put together a protocol of how we should go about > finding the resources we'll need to make it all happen. Do we have > something we can work our way up from? Is Chris' mockup not only an > appealing one (it is to me), but also one that will scale up well? > Do we already have any volunteers that want to start coding/ > designing something? Do we have to go out to our user base and ask > people to join this task force? If so, how? What should the rules > look like? > > Before answering any of those questions, I think it would be wise > to asses what it is that we all want to see in a new web page, in > order to be able to tell anyone donating his/her time/resources: > "this, this and that is what we want to have". I'd now like to > refocus this thread on exactly that, with my personal take following: > > -) Home: a front page detailing what the project is about > (including a brief description of our ports tree), mission goals > (very brief summary of a project roadmap) and introductory text of > how to participate/join; > -) Download & Installation: section describing exactly what its > name says; > -) Available Ports: old ports.php page with some extensions I'll > explain below; > -) Documentation: new guide with automated regen in place; > -) Support & Development: link to our (revamped) trac portal. > > If you (any reader) have payed attention to trunk/www lately, > you'll realize I'm pretty much in line with the old web page, which > I do believe was good in functionality. Differing from it, though: > > -) first and foremost, of course, new look & feel and logo (and > project mascot? ;-) that wraps *all* of our site; > -) blog/news section, which can be provided by our existing > wordpress front, but which I wouldn't be too sure on how to > integrate with the rest of the site (separate tab? just below the > introductory text in the home page? maybe someone more webdesign > savvy can chime in); > -) Help section can easily be eliminated if we revamp trac's > welcoming page (take a look at trac.adiumx.com); > -) love Chris' idea of a sidebar, which can have a "Shortcuts" > section with direct links to areas we infer will be of special > interest to users. Chris does this but calls it "Development", and > I think that overlaps a tad too much with "Support & Development" > as a main section; I'd just call it "Shortcuts" and make it as > broad in scope as we like (shortcuts don't have to be developer > oriented only ;-). Another good example of a sidebar can be found > in Webkit's site (www.webkit.org), another page I love and that I > think we should study to design ours; > -) layout of "Available Ports" should be "re-thought" to allow room > for a "Build Status" section that will be populated with html > output from build log submissions, once we start our automated > build runs (http://trac.macports.org/projects/macports/wiki/ > PortLoggingProposal , which I/we will hopefully write before the > sun becomes a white dwarf). > > What says y'all? Anything obvious I'm missing? Anything obnoxious > about my ideas/proposal? I'd really love to get this show on the > road ASAP, so it would be great to get at least some feedback to > finally declare a "design freeze" that will allow us to set the > design team that will hopefully form in a defined course. > > Regards to all and thanks for reading this far, as always ;-) Just wanted to quickly say "yes" to pretty much everything you wrote. Also, in May, I started working on a new MacPorts web site design, but never posted it. I'll dust it off and post what I have, and people can see what they think. From n.oxyde at gmail.com Sun Sep 2 09:46:40 2007 From: n.oxyde at gmail.com (N_Ox) Date: Tue Oct 9 16:40:35 2007 Subject: Wormux homepage links to darwinports.com Message-ID: <8632E9B9-4EBF-498F-AF92-AC84893BE83A@gmail.com> Hello, Just a little mail to say that someone should contact the wormux staff and tell them that darwinports.com's owner is an obnoxious dwarf and that they should not link it [1]. [1] http://www.wormux.org/wiki/fr/download.php Regards, -- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org From mww at macports.org Sun Sep 2 10:11:00 2007 From: mww at macports.org (Weissmann Markus) Date: Tue Oct 9 16:40:35 2007 Subject: Default compiler suite (was Re:[28325] trunk/dports/graphics/wxWidgets-devel/Portfile) In-Reply-To: <42F142B4-DBF5-4899-BB29-A9A267EF1BE3@macports.org> References: <20070828101842.B312975393A@cvs.opensource.apple.com> <8AC7C222-67AA-4913-90F3-237884375E9B@macports.org> <4E8DDB2E-0AB0-4311-AE7A-CCAD2FD30C72@gmail.com> <01EA8DDA-16E4-415A-B4F4-ED701A3E747C@macports.org> <0EA02FB8-8E65-4F80-B82A-E2DB5A2BE137@macports.org> <42F142B4-DBF5-4899-BB29-A9A267EF1BE3@macports.org> Message-ID: <83C3AB7C-5529-428E-85C0-0FAD51146B4A@macports.org> On 01.09.2007, at 22:52, Ryan Schmidt wrote: > > On Sep 1, 2007, at 12:45, Landon Fuller wrote: > >> On Sep 1, 2007, at 6:07 AM, Weissmann Markus wrote: >> >>> 'portconfigure.tcl' from trunk will chose a default for darwin >>> 7/8/9 (gcc3.3/4.0/4.0). Please test it! Just replacing /opt/local/ >>> share/macports/Tcl/port1.0/portconfigure.tcl with http:// >>> svn.macports.org/repository/macports/trunk/base/src/port1.0/ >>> portconfigure.tcl manually should do the trick. >>> >>> This version also fixes a bug that when using configure.compiler >>> every user-added compiler selection (e.g. 'configure.cc /bin/ >>> true') was overwritten. >> >> This is going to break ports that require a different compiler, >> but specify the compiler using configure.env, or arguments to >> configure via configure.args. > > Then we should start cleaning ports. All those that specify a > different compiler via configure.env should be updated to use > configure.cc, etc. Those that use configure.args (or build.args > I've also seen) should... I don't know, be tested to see if they > can instead use configure.cc (or build.cc, etc.; do we have that?). > Indeed. "configure.env" is not officially supported anymore anyway... some ports cant do without, but most can. Please everybody clean your ports. >> It's a shame that there are no auto-builds, as we don't know what >> will break. >> >> At the very least, would you be opposed to a new flag that enables >> (or disables) this behavior? > Not at all. If it doesn't break anything by default, feel free to add it! Regards, -Markus --- Markus W. Weissmann http://www.mweissmann.de/ From afb at macports.org Sun Sep 2 11:54:47 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Oct 9 16:40:35 2007 Subject: Death of Hexley? ... was "Re(2): New website!" In-Reply-To: References: <9fb438449c6e3bd8b7bc63027edd491b@macports.org> Message-ID: <948840775cfe2ff3c3377d92322a6c79@macports.org> Ryan Schmidt wrote: > I'm in favor of getting rid of Hexley. Never liked him. The goal of > MacPorts should be to eventually appeal to any Mac user, and I don't > feel that the image of a thing with devil horns and a pitchfork, no > matter how cute or how lovingly rendered in Aqua style, is > appropriate. :-/ Maybe it's because that the operating system itself has a userland that is largely based on another such project with a mascot that has horns and a pitchfork... Then again nowadays maybe the Dodo would be a better symbol for the Darwin OS ? And there is always the "Hmmm. Interesting. See, we was just wondering why it is you have the lord of darkness on your chest there." * None of this matters much to MacPorts, of course. --anders * see http://www.lemis.com/grog/whyadaemon.html From jmpp at macports.org Sun Sep 2 12:43:48 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:35 2007 Subject: [28499] trunk/dports/x11 In-Reply-To: <20070902170101.740CF76ED8A@cvs.opensource.apple.com> References: <20070902170101.740CF76ED8A@cvs.opensource.apple.com> Message-ID: <9E79C535-12D1-4318-AD20-A8283F3D6186@macports.org> Hey Mark! Of all of the edits you made in this commit, the ones I left quoted below present somewhat of a puzzle: does the "configure.cppflags" env variable really need the "-L${prefix}/lib" linking argument? It's present in all of them. Regards,... -jmpp On Sep 2, 2007, at 1:01 PM, source_changes@macosforge.org wrote: > Modified: trunk/dports/x11/Terminal/Portfile (28498 => 28499) > --- trunk/dports/x11/Terminal/Portfile 2007-09-02 16:36:37 UTC (rev > 28498) > +++ trunk/dports/x11/Terminal/Portfile 2007-09-02 17:01:00 UTC (rev > 28499) > @@ -16,4 +16,4 @@ > depends_lib lib:libexo-0.3:libexo lib:libvte:vte > patchfiles patch-terminal-Makefile.in > configure.args --mandir=${prefix}/share/man > -configure.env CPPFLAGS="-L${prefix}/lib -I${prefix}/include" > +configure.cppflags-append "-L${prefix}/lib" > Modified: trunk/dports/x11/blt/Portfile (28498 => 28499) > > --- trunk/dports/x11/blt/Portfile 2007-09-02 16:36:37 UTC (rev 28498) > +++ trunk/dports/x11/blt/Portfile 2007-09-02 17:01:00 UTC (rev 28499) > @@ -21,9 +21,8 @@ > port:tcl \ > port:tk > > -configure.env CPPFLAGS="-L${prefix}/lib" \ > - CFLAGS="-O3 -fno-common" \ > - LDFLAGS="-L${prefix}/lib" > +configure.cppflags "-L${prefix}/lib" > +configure.cflags "-O3 -fno-common" > > configure.args --prefix=${prefix} \ > --exec_prefix=${prefix} \ > Modified: trunk/dports/x11/dlume/Portfile (28498 => 28499) > > --- trunk/dports/x11/dlume/Portfile 2007-09-02 16:36:37 UTC (rev > 28498) > +++ trunk/dports/x11/dlume/Portfile 2007-09-02 17:01:00 UTC (rev > 28499) > @@ -15,8 +15,8 @@ > checksums md5 6b2a3ef0eff622a412395187d1c5d178 > depends_lib lib:gtk.2:gtk2 lib:libxml2:libxml2 > configure.args --mandir=${prefix}/share/man > -configure.env CPPFLAGS="-I${prefix}/include -L${prefix}/lib" \ > - CFLAGS="-no-cpp-precomp -flat_namespace -undefined > suppress" > +configure.cppflags-append "-L${prefix}/lib" > +configure.cflags "-no-cpp-precomp -flat_namespace -undefined > suppress" > > post-configure { > reinplace "s|-export-dynamic||g" ${worksrcpath}/Makefile > Modified: trunk/dports/x11/gtk-smooth-engine/Portfile (28498 => 28499) > > --- trunk/dports/x11/gtk-smooth-engine/Portfile 2007-09-02 16:36:37 > UTC (rev 28498) > +++ trunk/dports/x11/gtk-smooth-engine/Portfile 2007-09-02 17:01:00 > UTC (rev 28499) > @@ -13,6 +13,5 @@ > checksums md5 a2231118c8187649d1e634fdfe6f36de > depends_lib lib:libX11.6:XFree86 lib:libglib.2:glib2 lib:libgtk. > 2:gtk2 > configure.args --mandir=${prefix}/share/man --disable-gtk-1 > -configure.env CPPFLAGS="-L${prefix}/lib -I${prefix}/include" \ > - CFLAGS="-no-cpp-precomp -flat_namespace -undefined > suppress" \ > - LDFLAGS="-L${prefix}/lib" > +configure.cppflags-append "-L${prefix}/lib" > +configure.cflags "-no-cpp-precomp -flat_namespace -undefined > suppress" > Modified: trunk/dports/x11/gtk-thinice-engine/Portfile (28498 => > 28499) > > --- trunk/dports/x11/gtk-thinice-engine/Portfile 2007-09-02 > 16:36:37 UTC (rev 28498) > +++ trunk/dports/x11/gtk-thinice-engine/Portfile 2007-09-02 > 17:01:00 UTC (rev 28499) > @@ -13,5 +13,5 @@ > depends_lib lib:libX11.6:XFree86 lib:libglib.2:glib2 lib:libgtk. > 2:gtk2 > use_bzip2 yes > configure.args --mandir=${prefix}/share/man > -configure.env CPPFLAGS="-L${prefix}/lib -I${prefix}/include" \ > - CFLAGS="-no-cpp-precomp -flat_namespace -undefined > suppress" > +configure.cppflags-append "-L${prefix}/lib" > +configure.cflags "-no-cpp-precomp -flat_namespace -undefined > suppress" > Modified: trunk/dports/x11/gtk2-clearlooks/Portfile (28498 => 28499) > > --- trunk/dports/x11/gtk2-clearlooks/Portfile 2007-09-02 16:36:37 > UTC (rev 28498) > +++ trunk/dports/x11/gtk2-clearlooks/Portfile 2007-09-02 17:01:00 > UTC (rev 28499) > @@ -14,7 +14,7 @@ > distname clearlooks-${version} > checksums md5 451ef33d1bffa261c5cbe01182199f97 > configure.args --mandir=${prefix}/share/man > -configure.env CPPFLAGS="-L${prefix}/lib -I${prefix}/include" \ > - CFLAGS="-no-cpp-precomp -flat_namespace -undefined suppress" > -depends_lib lib:libgtk.2:gtk2 > +configure.cppflags-append "-L${prefix}/lib" > +configure.cflags "-no-cpp-precomp -flat_namespace -undefined > suppress" > +depends_lib port:gtk2 > use_bzip2 yes > Modified: trunk/dports/x11/gtkspell2/Portfile (28498 => 28499) > > --- trunk/dports/x11/gtkspell2/Portfile 2007-09-02 16:36:37 UTC > (rev 28498) > +++ trunk/dports/x11/gtkspell2/Portfile 2007-09-02 17:01:00 UTC > (rev 28499) > @@ -14,11 +14,11 @@ > master_sites $homepage/download > distname gtkspell-${version} > checksums md5 494869f67146a12a3f17a958f51aeb05 > -depends_lib lib:libaspell:aspell \ > - lib:gtk.2:gtk2 > +depends_lib port:aspell \ > + port:gtk2 > configure.args --disable-debug > -configure.env CPPFLAGS="-L${prefix}/lib -I${prefix}/include" \ > - CFLAGS="-no-cpp-precomp -flat_namespace -undefined suppress" > +configure.cppflags-append "-L${prefix}/lib" > +configure.cflags "-no-cpp-precomp -flat_namespace -undefined > suppress" > > #NOTES Port is named gtkspell2 due to ongoing development of > gtkspell3 > # Although there are no ports that require this port, there are a > > > > Modified: trunk/dports/x11/siag/Portfile (28498 => 28499) > > --- trunk/dports/x11/siag/Portfile 2007-09-02 16:36:37 UTC (rev 28498) > +++ trunk/dports/x11/siag/Portfile 2007-09-02 17:01:00 UTC (rev 28499) > @@ -15,8 +15,7 @@ > checksums md5 bb7bb66dc9d3659fd11cdbac61ea6e13 > depends_lib lib:libneXtaw:neXtaw lib:libMowitz:mowitz lib:libXawM. > 1:XawM > patchfiles patch-oledecod.c patch-fileio_xls.c > -configure.env CPPFLAGS="-L${prefix}/lib -I${prefix}/include" \ > - LDFLAGS="-L${prefix}/lib" > +configure.cppflags-append "-L${prefix}/lib" > > pre-configure { > reinplace "s|malloc.h|stdlib.h|g" \ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20070902/dd1e6e5b/attachment.html From n.oxyde at gmail.com Sun Sep 2 13:31:04 2007 From: n.oxyde at gmail.com (N_Ox) Date: Tue Oct 9 16:40:35 2007 Subject: zsh and zsh-devel Message-ID: <40828949-1292-4B99-9C25-D9908B196B60@gmail.com> Hello, zsh is now quite old and its maintainship has been dropped. I'm the current maintainer of zsh-devel and I think it does not deserve its -devel nature. Should we delete zsh and rename zsh-devel? Regards, -- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org From jstrine at vexate.net Sun Sep 2 13:35:35 2007 From: jstrine at vexate.net (Jonathan Strine) Date: Tue Oct 9 16:40:35 2007 Subject: Newbie Port Creator Questions Message-ID: All, I am working on creating ports for a few applications. I have created and submitted my first one just yesterday (libelf-0.8.9). I am now working on my second (dynamips-0.2.7), but have a few questions I'm hoping someone can answer (not all relating to just dynamips-0.2.7). 1) I have successfully created a variant of dynamips using pcap. The process was rather simple. However, I am debating the creation of a third variant. A third party developer has created a source code patch that extends a certain function of dynamips in a useful way. Is it appropriate to include such a third party modification as a variant to a port? 2) In the case above, the third party patch file is written to be applied from the directory above the source code (I think this would be called the work directory) and not from inside the dynamips-0.2.7 directory created when the tarball is extracted. The best I can figure is that the patching phase does apply the patch while in this source directory (dynamips-0.2.7) and not from the work directory. It is possible to make it apply the patch from the work directory so that I do not have to modify the third party patch file for this variant? 3) The third party patch is licensed under the GPLv2 license. Are there any general concerns that I should worry about in either case where I use the patch file as is or in the case where I modify it? 4) If I cannot patch from the work directory, is it considered OK to modify the third party patch file to support patching from inside the dynamips-0.2.7 directory? 5) What is the best practice to make sure that during all the steps I am only referencing libraries and dependencies from the macports system and not accidentally compiling against pre-installed system libraries? I have run "port -d install foo" and read through the output, but I want to double check that I am not missing anything. I realize the above questions may be somewhat basic, but I'm hoping that armed with the answers I can make some valuable contributions to the vast library of ports available. Thanks! -- Jonathan Strine PGP Key ID: 0x0A02201C From afb at macports.org Sun Sep 2 13:40:01 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Oct 9 16:40:35 2007 Subject: zsh and zsh-devel In-Reply-To: <40828949-1292-4B99-9C25-D9908B196B60@gmail.com> References: <40828949-1292-4B99-9C25-D9908B196B60@gmail.com> Message-ID: N_Ox wrote: > zsh is now quite old and its maintainship has been dropped. > I'm the current maintainer of zsh-devel and I think it does not > deserve its -devel nature. > Should we delete zsh and rename zsh-devel? Upstream still lists 4.2.6 (2005-12-05) as the "stable" series and 4.3.4 (2007-04-19) as the "development" series, so it seems a good idea to keep the current naming ? Feel free to maintain the zsh port as well, though... :-) --anders From n.oxyde at gmail.com Sun Sep 2 13:48:56 2007 From: n.oxyde at gmail.com (N_Ox) Date: Tue Oct 9 16:40:35 2007 Subject: zsh and zsh-devel In-Reply-To: References: <40828949-1292-4B99-9C25-D9908B196B60@gmail.com> Message-ID: <8C440892-42AB-4589-8CB6-F0CE988CEEB5@gmail.com> Le 2 sept. 07 ? 22:40, Anders F Bj?rklund a ?crit : > N_Ox wrote: > >> zsh is now quite old and its maintainship has been dropped. >> I'm the current maintainer of zsh-devel and I think it does not >> deserve its -devel nature. >> Should we delete zsh and rename zsh-devel? > > Upstream still lists 4.2.6 (2005-12-05) as the "stable" series and > 4.3.4 (2007-04-19) as the "development" series, so it seems a good > idea to keep the current naming ? > > Feel free to maintain the zsh port as well, though... :-) > > --anders > Oh, you're right, I didn't notice that. I'll take over it soon so. -- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org From mww at macports.org Sun Sep 2 14:08:50 2007 From: mww at macports.org (Weissmann Markus) Date: Tue Oct 9 16:40:35 2007 Subject: [28499] trunk/dports/x11 In-Reply-To: <9E79C535-12D1-4318-AD20-A8283F3D6186@macports.org> References: <20070902170101.740CF76ED8A@cvs.opensource.apple.com> <9E79C535-12D1-4318-AD20-A8283F3D6186@macports.org> Message-ID: On 02.09.2007, at 21:43, Juan Manuel Palacios wrote: > > Hey Mark! > > Of all of the edits you made in this commit, the ones I left > quoted below present somewhat of a puzzle: does the > "configure.cppflags" env variable really need the "-L${prefix}/lib" > linking argument? It's present in all of them. > > honestly I have no idea. But the original author probably had a reason to do so and I did not test if it worked without. I only transformed the 'configure.env' statements to configure.whatever ones. Regards, -Markus > > On Sep 2, 2007, at 1:01 PM, source_changes@macosforge.org wrote: > >> Modified: trunk/dports/x11/Terminal/Portfile (28498 => 28499) >> --- trunk/dports/x11/Terminal/Portfile 2007-09-02 16:36:37 UTC >> (rev 28498) +++ trunk/dports/x11/Terminal/Portfile 2007-09-02 >> 17:01:00 UTC (rev 28499) @@ -16,4 +16,4 @@ depends_lib >> lib:libexo-0.3:libexo lib:libvte:vte patchfiles patch-terminal- >> Makefile.in configure.args --mandir=${prefix}/share/man - >> configure.env CPPFLAGS="-L${prefix}/lib -I${prefix}/include" >> +configure.cppflags-append "-L${prefix}/lib" >> Modified: trunk/dports/x11/blt/Portfile (28498 => 28499) --- trunk/ >> dports/x11/blt/Portfile 2007-09-02 16:36:37 UTC (rev 28498) +++ >> trunk/dports/x11/blt/Portfile 2007-09-02 17:01:00 UTC (rev 28499) >> @@ -21,9 +21,8 @@ port:tcl \ port:tk -configure.env CPPFLAGS="-L$ >> {prefix}/lib" \ - CFLAGS="-O3 -fno-common" \ - LDFLAGS="-L$ >> {prefix}/lib" +configure.cppflags "-L${prefix}/lib" >> +configure.cflags "-O3 -fno-common" configure.args --prefix=$ >> {prefix} \ --exec_prefix=${prefix} \ >> Modified: trunk/dports/x11/dlume/Portfile (28498 => 28499) --- >> trunk/dports/x11/dlume/Portfile 2007-09-02 16:36:37 UTC (rev >> 28498) +++ trunk/dports/x11/dlume/Portfile 2007-09-02 17:01:00 UTC >> (rev 28499) @@ -15,8 +15,8 @@ checksums md5 >> 6b2a3ef0eff622a412395187d1c5d178 depends_lib lib:gtk.2:gtk2 >> lib:libxml2:libxml2 configure.args --mandir=${prefix}/share/man - >> configure.env CPPFLAGS="-I${prefix}/include -L${prefix}/lib" \ - >> CFLAGS="-no-cpp-precomp -flat_namespace -undefined suppress" >> +configure.cppflags-append "-L${prefix}/lib" +configure.cflags "- >> no-cpp-precomp -flat_namespace -undefined suppress" post-configure >> { reinplace "s|-export-dynamic||g" ${worksrcpath}/Makefile >> Modified: trunk/dports/x11/gtk-smooth-engine/Portfile (28498 => >> 28499) >> --- trunk/dports/x11/gtk-smooth-engine/Portfile 2007-09-02 >> 16:36:37 UTC (rev 28498) +++ trunk/dports/x11/gtk-smooth-engine/ >> Portfile 2007-09-02 17:01:00 UTC (rev 28499) @@ -13,6 +13,5 @@ >> checksums md5 a2231118c8187649d1e634fdfe6f36de depends_lib >> lib:libX11.6:XFree86 lib:libglib.2:glib2 lib:libgtk.2:gtk2 >> configure.args --mandir=${prefix}/share/man --disable-gtk-1 - >> configure.env CPPFLAGS="-L${prefix}/lib -I${prefix}/include" \ - >> CFLAGS="-no-cpp-precomp -flat_namespace -undefined suppress" \ - >> LDFLAGS="-L${prefix}/lib" +configure.cppflags-append "-L${prefix}/ >> lib" +configure.cflags "-no-cpp-precomp -flat_namespace -undefined >> suppress" >> Modified: trunk/dports/x11/gtk-thinice-engine/Portfile (28498 => >> 28499) --- trunk/dports/x11/gtk-thinice-engine/Portfile 2007-09-02 >> 16:36:37 UTC (rev 28498) +++ trunk/dports/x11/gtk-thinice-engine/ >> Portfile 2007-09-02 17:01:00 UTC (rev 28499) @@ -13,5 +13,5 @@ >> depends_lib lib:libX11.6:XFree86 lib:libglib.2:glib2 lib:libgtk. >> 2:gtk2 use_bzip2 yes configure.args --mandir=${prefix}/share/man - >> configure.env CPPFLAGS="-L${prefix}/lib -I${prefix}/include" \ - >> CFLAGS="-no-cpp-precomp -flat_namespace -undefined suppress" >> +configure.cppflags-append "-L${prefix}/lib" +configure.cflags "- >> no-cpp-precomp -flat_namespace -undefined suppress" >> Modified: trunk/dports/x11/gtk2-clearlooks/Portfile (28498 => >> 28499) --- trunk/dports/x11/gtk2-clearlooks/Portfile 2007-09-02 >> 16:36:37 UTC (rev 28498) +++ trunk/dports/x11/gtk2-clearlooks/ >> Portfile 2007-09-02 17:01:00 UTC (rev 28499) @@ -14,7 +14,7 @@ >> distname clearlooks-${version} checksums md5 >> 451ef33d1bffa261c5cbe01182199f97 configure.args --mandir=$ >> {prefix}/share/man -configure.env CPPFLAGS="-L${prefix}/lib -I$ >> {prefix}/include" \ - CFLAGS="-no-cpp-precomp -flat_namespace - >> undefined suppress" -depends_lib lib:libgtk.2:gtk2 >> +configure.cppflags-append "-L${prefix}/lib" +configure.cflags "- >> no-cpp-precomp -flat_namespace -undefined suppress" +depends_lib >> port:gtk2 use_bzip2 yes >> Modified: trunk/dports/x11/gtkspell2/Portfile (28498 => 28499) >> --- trunk/dports/x11/gtkspell2/Portfile 2007-09-02 16:36:37 UTC >> (rev 28498) +++ trunk/dports/x11/gtkspell2/Portfile 2007-09-02 >> 17:01:00 UTC (rev 28499) @@ -14,11 +14,11 @@ master_sites >> $homepage/download distname gtkspell-${version} checksums md5 >> 494869f67146a12a3f17a958f51aeb05 -depends_lib lib:libaspell:aspell >> \ - lib:gtk.2:gtk2 +depends_lib port:aspell \ + port:gtk2 >> configure.args --disable-debug -configure.env CPPFLAGS="-L$ >> {prefix}/lib -I${prefix}/include" \ - CFLAGS="-no-cpp-precomp - >> flat_namespace -undefined suppress" +configure.cppflags-append "-L$ >> {prefix}/lib" +configure.cflags "-no-cpp-precomp -flat_namespace - >> undefined suppress" #NOTES Port is named gtkspell2 due to ongoing >> development of gtkspell3 # Although there are no ports that >> require this port, there are a >> Modified: trunk/dports/x11/siag/Portfile (28498 => 28499) --- >> trunk/dports/x11/siag/Portfile 2007-09-02 16:36:37 UTC (rev 28498) >> +++ trunk/dports/x11/siag/Portfile 2007-09-02 17:01:00 UTC (rev >> 28499) @@ -15,8 +15,7 @@ checksums md5 >> bb7bb66dc9d3659fd11cdbac61ea6e13 depends_lib lib:libneXtaw:neXtaw >> lib:libMowitz:mowitz lib:libXawM.1:XawM patchfiles patch- >> oledecod.c patch-fileio_xls.c -configure.env CPPFLAGS="-L${prefix}/ >> lib -I${prefix}/include" \ - LDFLAGS="-L${prefix}/lib" >> +configure.cppflags-append "-L${prefix}/lib" pre-configure >> { reinplace "s|malloc.h|stdlib.h|g" \ --- Markus W. Weissmann http://www.mweissmann.de/ From mww at macports.org Sun Sep 2 15:03:15 2007 From: mww at macports.org (Weissmann Markus) Date: Tue Oct 9 16:40:35 2007 Subject: Newbie Port Creator Questions In-Reply-To: References: Message-ID: <05BCB0A2-E3E0-4F89-85B0-9B30E98B7094@macports.org> Hi Jonathan, On 02.09.2007, at 22:35, Jonathan Strine wrote: > All, > > I am working on creating ports for a few applications. I have > created and submitted my first one just yesterday (libelf-0.8.9). > I am now working on my second (dynamips-0.2.7), but have a few > questions I'm hoping someone can answer (not all relating to just > dynamips-0.2.7). > > 1) I have successfully created a variant of dynamips using pcap. > The process was rather simple. However, I am debating the creation > of a third variant. A third party developer has created a source > code patch that extends a certain function of dynamips in a useful > way. Is it appropriate to include such a third party modification > as a variant to a port? > Absolutely. If you find it useful and no is bashing you for that (e.g. because it breaks ports that depend on it), go ahead! > 2) In the case above, the third party patch file is written to be > applied from the directory above the source code (I think this > would be called the work directory) and not from inside the > dynamips-0.2.7 directory created when the tarball is extracted. > The best I can figure is that the patching phase does apply the > patch while in this source directory (dynamips-0.2.7) and not from > the work directory. It is possible to make it apply the patch from > the work directory so that I do not have to modify the third party > patch file for this variant? > you could either modify the patch-directory via 'patch.dir $ {worksrcpath}/foo/bar/' or just create a new patch via diffing the original and the patches sources from the base dir; > 3) The third party patch is licensed under the GPLv2 license. Are > there any general concerns that I should worry about in either case > where I use the patch file as is or in the case where I modify it? > No problems for us. It'll only hit the people who link against the new product. We will happily distribute GPLed code (as long as port itself is not mixed with it). > 4) If I cannot patch from the work directory, is it considered OK > to modify the third party patch file to support patching from > inside the dynamips-0.2.7 directory? > yes, sure; GPLed code may be modified and distributed by us (see above). > 5) What is the best practice to make sure that during all the > steps I am only referencing libraries and dependencies from the > macports system and not accidentally compiling against pre- > installed system libraries? I have run "port -d install foo" and > read through the output, but I want to double check that I am not > missing anything. > It currently may be broke, but we do have 'trace' mode which can be activated with the '-t' switch. It'll tell you about all ports that your port touches during its build. For checking after you build it, I recommend a simple 'find' command like #> find work/destroot -type f | xargs otool -L 2>&1 | sort -u That'll tell you all libs that the files in destroot link against. Regards, -Markus --- Markus W. Weissmann http://www.mweissmann.de/ --- Markus W. Weissmann http://www.mweissmann.de/ From jstrine at vexate.net Sun Sep 2 15:15:14 2007 From: jstrine at vexate.net (Jonathan Strine) Date: Tue Oct 9 16:40:35 2007 Subject: Newbie Port Creator Questions In-Reply-To: <05BCB0A2-E3E0-4F89-85B0-9B30E98B7094@macports.org> References: <05BCB0A2-E3E0-4F89-85B0-9B30E98B7094@macports.org> Message-ID: <6FFAC741-233A-4425-BE2B-EFEB7CBD4197@vexate.net> Markus, Thank you very much for the answers, but I am left with one more question. Does the statement quoted below mean that as long as the patch *and* the base port (that is the main program, dynamips) are both GPL, then everything is OK? If I understand GPL correctly I cannot redistribute a patched version of of a non-GPL program (even if the patch is GPL) since that would "break" the license? Am I correct in the above? -- Jonathan Strine PGP Key ID: 0x0A02201C On Sep 2, 2007, at 6:03 PM, Weissmann Markus wrote: > We will happily distribute GPLed code (as long as port itself is > not mixed with it). From mww at macports.org Sun Sep 2 15:27:44 2007 From: mww at macports.org (Weissmann Markus) Date: Tue Oct 9 16:40:35 2007 Subject: Newbie Port Creator Questions In-Reply-To: <6FFAC741-233A-4425-BE2B-EFEB7CBD4197@vexate.net> References: <05BCB0A2-E3E0-4F89-85B0-9B30E98B7094@macports.org> <6FFAC741-233A-4425-BE2B-EFEB7CBD4197@vexate.net> Message-ID: <71EC8A7B-E320-413C-9934-B5C3BBEF669A@macports.org> On 03.09.2007, at 00:15, Jonathan Strine wrote: > Markus, > > Thank you very much for the answers, but I am left with one more > question. Does the statement quoted below mean that as long as the > patch *and* the base port (that is the main program, dynamips) are > both GPL, then everything is OK? If I understand GPL correctly I > cannot redistribute a patched version of of a non-GPL program (even > if the patch is GPL) since that would "break" the license? > > Am I correct in the above? > well, the deal is that macports will only distribute the patch and the user will create the patched version on his machine only - so for macports everything should be just fine. The thing with GPLed code is, that it is viral, so everything you link against it (or mix with it) will get GPLed code, too. I'm not quite sure what if you do not own the original source (e.g. it is BSD licensed), but I assume that everyone will be happy as long as the viral effect of the GPL is kept and you distribute the source code along a binary. Long story short: MacPorts only makes the patch available and not the patched software, so there is no problem for us (as long we don't distribute packages). For the rest, a lawyer should be contacted or even better: Someone should ask the author of the patch why he/she is not playing nice and not using the license of the original code. -Markus --- Markus W. Weissmann http://www.mweissmann.de/ From raimue at macports.org Sun Sep 2 15:54:27 2007 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue Oct 9 16:40:35 2007 Subject: Newbie Port Creator Questions In-Reply-To: <05BCB0A2-E3E0-4F89-85B0-9B30E98B7094@macports.org> References: <05BCB0A2-E3E0-4F89-85B0-9B30E98B7094@macports.org> Message-ID: <46DB3F23.9090902@macports.org> Weissmann Markus wrote: >> 2) In the case above, the third party patch file is written to be >> applied from the directory above the source code (I think this would >> be called the work directory) and not from inside the dynamips-0.2.7 >> directory created when the tarball is extracted. The best I can >> figure is that the patching phase does apply the patch while in this >> source directory (dynamips-0.2.7) and not from the work directory. It >> is possible to make it apply the patch from the work directory so that >> I do not have to modify the third party patch file for this variant? >> > > you could either modify the patch-directory via 'patch.dir > ${worksrcpath}/foo/bar/' or just create a new patch via diffing the > original and the patches sources from the base dir; There is also the possibility to use: patch.pre_args -p1 But I think this would apply to all patchfiles. Rainer From ryandesign at macports.org Sun Sep 2 17:43:15 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:35 2007 Subject: Default compiler suite (was Re:[28325] trunk/dports/graphics/wxWidgets-devel/Portfile) In-Reply-To: <83C3AB7C-5529-428E-85C0-0FAD51146B4A@macports.org> References: <20070828101842.B312975393A@cvs.opensource.apple.com> <8AC7C222-67AA-4913-90F3-237884375E9B@macports.org> <4E8DDB2E-0AB0-4311-AE7A-CCAD2FD30C72@gmail.com> <01EA8DDA-16E4-415A-B4F4-ED701A3E747C@macports.org> <0EA02FB8-8E65-4F80-B82A-E2DB5A2BE137@macports.org> <42F142B4-DBF5-4899-BB29-A9A267EF1BE3@macports.org> <83C3AB7C-5529-428E-85C0-0FAD51146B4A@macports.org> Message-ID: On Sep 2, 2007, at 12:11, Weissmann Markus wrote: > On 01.09.2007, at 22:52, Ryan Schmidt wrote: > >> On Sep 1, 2007, at 12:45, Landon Fuller wrote: >> >>> On Sep 1, 2007, at 6:07 AM, Weissmann Markus wrote: >>> >>>> 'portconfigure.tcl' from trunk will chose a default for darwin >>>> 7/8/9 (gcc3.3/4.0/4.0). Please test it! Just replacing /opt/ >>>> local/share/macports/Tcl/port1.0/portconfigure.tcl with http:// >>>> svn.macports.org/repository/macports/trunk/base/src/port1.0/ >>>> portconfigure.tcl manually should do the trick. >>>> >>>> This version also fixes a bug that when using configure.compiler >>>> every user-added compiler selection (e.g. 'configure.cc /bin/ >>>> true') was overwritten. >>> >>> This is going to break ports that require a different compiler, >>> but specify the compiler using configure.env, or arguments to >>> configure via configure.args. >> >> Then we should start cleaning ports. All those that specify a >> different compiler via configure.env should be updated to use >> configure.cc, etc. Those that use configure.args (or build.args >> I've also seen) should... I don't know, be tested to see if they >> can instead use configure.cc (or build.cc, etc.; do we have that?). > > Indeed. "configure.env" is not officially supported anymore > anyway... some ports cant do without, but most can. Please > everybody clean your ports. Why isn't configure.env supported anymore? The new guide documents this option, and does not mention anything about it being deprecated or unsupported. If it is unsupported, the guide should state that, and recommend alternatives. http://geeklair.net/new_macports_guide/#reference.keywords.configure From blair at orcaware.com Sun Sep 2 17:51:52 2007 From: blair at orcaware.com (Blair Zajac) Date: Tue Oct 9 16:40:35 2007 Subject: Default compiler suite (was Re:[28325] trunk/dports/graphics/wxWidgets-devel/Portfile) In-Reply-To: References: <20070828101842.B312975393A@cvs.opensource.apple.com> <8AC7C222-67AA-4913-90F3-237884375E9B@macports.org> <4E8DDB2E-0AB0-4311-AE7A-CCAD2FD30C72@gmail.com> <01EA8DDA-16E4-415A-B4F4-ED701A3E747C@macports.org> <0EA02FB8-8E65-4F80-B82A-E2DB5A2BE137@macports.org> <42F142B4-DBF5-4899-BB29-A9A267EF1BE3@macports.org> <83C3AB7C-5529-428E-85C0-0FAD51146B4A@macports.org> Message-ID: <46DB5AA8.5040208@orcaware.com> Ryan Schmidt wrote: > > On Sep 2, 2007, at 12:11, Weissmann Markus wrote: > >> On 01.09.2007, at 22:52, Ryan Schmidt wrote: >> >>> On Sep 1, 2007, at 12:45, Landon Fuller wrote: >>> >>>> On Sep 1, 2007, at 6:07 AM, Weissmann Markus wrote: >>>> >>>>> 'portconfigure.tcl' from trunk will chose a default for darwin >>>>> 7/8/9 (gcc3.3/4.0/4.0). Please test it! Just replacing >>>>> /opt/local/share/macports/Tcl/port1.0/portconfigure.tcl with >>>>> http://svn.macports.org/repository/macports/trunk/base/src/port1.0/portconfigure.tcl >>>>> manually should do the trick. >>>>> >>>>> This version also fixes a bug that when using configure.compiler >>>>> every user-added compiler selection (e.g. 'configure.cc /bin/true') >>>>> was overwritten. >>>> >>>> This is going to break ports that require a different compiler, but >>>> specify the compiler using configure.env, or arguments to configure >>>> via configure.args. >>> >>> Then we should start cleaning ports. All those that specify a >>> different compiler via configure.env should be updated to use >>> configure.cc, etc. Those that use configure.args (or build.args I've >>> also seen) should... I don't know, be tested to see if they can >>> instead use configure.cc (or build.cc, etc.; do we have that?). >> >> Indeed. "configure.env" is not officially supported anymore anyway... >> some ports cant do without, but most can. Please everybody clean your >> ports. > > Why isn't configure.env supported anymore? Yes, the qt3-mac port needs it, and actually, the it's been broken for a while due to the configure.env and build.env not honoring it. If somebody could fix MacPorts (and not the Portfile) to honor it, I would appreciate it. See this ticket for information on when the *.env broke: http://trac.macports.org/projects/macports/ticket/11895 Regards, Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies Subversion training, consulting and support http://www.orcaware.com/svn/ From mww at macports.org Sun Sep 2 17:58:14 2007 From: mww at macports.org (Weissmann Markus) Date: Tue Oct 9 16:40:35 2007 Subject: Default compiler suite (was Re:[28325] trunk/dports/graphics/wxWidgets-devel/Portfile) In-Reply-To: References: <20070828101842.B312975393A@cvs.opensource.apple.com> <8AC7C222-67AA-4913-90F3-237884375E9B@macports.org> <4E8DDB2E-0AB0-4311-AE7A-CCAD2FD30C72@gmail.com> <01EA8DDA-16E4-415A-B4F4-ED701A3E747C@macports.org> <0EA02FB8-8E65-4F80-B82A-E2DB5A2BE137@macports.org> <42F142B4-DBF5-4899-BB29-A9A267EF1BE3@macports.org> <83C3AB7C-5529-428E-85C0-0FAD51146B4A@macports.org> Message-ID: On 03.09.2007, at 02:43, Ryan Schmidt wrote: > > On Sep 2, 2007, at 12:11, Weissmann Markus wrote: > >> On 01.09.2007, at 22:52, Ryan Schmidt wrote: >> >>> On Sep 1, 2007, at 12:45, Landon Fuller wrote: >>> >>>> On Sep 1, 2007, at 6:07 AM, Weissmann Markus wrote: >>>> >>>>> 'portconfigure.tcl' from trunk will chose a default for darwin >>>>> 7/8/9 (gcc3.3/4.0/4.0). Please test it! Just replacing /opt/ >>>>> local/share/macports/Tcl/port1.0/portconfigure.tcl with http:// >>>>> svn.macports.org/repository/macports/trunk/base/src/port1.0/ >>>>> portconfigure.tcl manually should do the trick. >>>>> >>>>> This version also fixes a bug that when using >>>>> configure.compiler every user-added compiler selection (e.g. >>>>> 'configure.cc /bin/true') was overwritten. >>>> >>>> This is going to break ports that require a different compiler, >>>> but specify the compiler using configure.env, or arguments to >>>> configure via configure.args. >>> >>> Then we should start cleaning ports. All those that specify a >>> different compiler via configure.env should be updated to use >>> configure.cc, etc. Those that use configure.args (or build.args >>> I've also seen) should... I don't know, be tested to see if they >>> can instead use configure.cc (or build.cc, etc.; do we have that?). >> >> Indeed. "configure.env" is not officially supported anymore >> anyway... some ports cant do without, but most can. Please >> everybody clean your ports. > > Why isn't configure.env supported anymore? > oops - sorry, my fault! I really wanted to say: Using configure.env directly should be avoided - we do have a nice set of commands for setting the most used flags at configuration time. If you cannot do without, of course it is still supported. > The new guide documents this option, and does not mention anything > about it being deprecated or unsupported. If it is unsupported, the > guide should state that, and recommend alternatives. > > http://geeklair.net/new_macports_guide/#reference.keywords.configure > Well yes. We should probably though put our manpages online, too and clearly state that if in doubt the manpage is right. -Markus --- Markus W. Weissmann http://www.mweissmann.de/ From ryandesign at macports.org Sun Sep 2 18:03:15 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:35 2007 Subject: Default compiler suite (was Re:[28325] trunk/dports/graphics/wxWidgets-devel/Portfile) In-Reply-To: <46DB5AA8.5040208@orcaware.com> References: <20070828101842.B312975393A@cvs.opensource.apple.com> <8AC7C222-67AA-4913-90F3-237884375E9B@macports.org> <4E8DDB2E-0AB0-4311-AE7A-CCAD2FD30C72@gmail.com> <01EA8DDA-16E4-415A-B4F4-ED701A3E747C@macports.org> <0EA02FB8-8E65-4F80-B82A-E2DB5A2BE137@macports.org> <42F142B4-DBF5-4899-BB29-A9A267EF1BE3@macports.org> <83C3AB7C-5529-428E-85C0-0FAD51146B4A@macports.org> <46DB5AA8.5040208@orcaware.com> Message-ID: On Sep 2, 2007, at 19:51, Blair Zajac wrote: > Ryan Schmidt wrote: > >> On Sep 2, 2007, at 12:11, Weissmann Markus wrote: >> >>> Indeed. "configure.env" is not officially supported anymore >>> anyway... some ports cant do without, but most can. Please >>> everybody clean your ports. >> >> Why isn't configure.env supported anymore? > > Yes, the qt3-mac port needs it, and actually, the it's been broken > for a while due to the configure.env and build.env not honoring it. > > If somebody could fix MacPorts (and not the Portfile) to honor it, > I would appreciate it. > > See this ticket for information on when the *.env broke: > > http://trac.macports.org/projects/macports/ticket/11895 I'd still like to hear Paul's input on this. From ryandesign at macports.org Sun Sep 2 18:07:56 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:35 2007 Subject: Wormux homepage links to darwinports.com In-Reply-To: <8632E9B9-4EBF-498F-AF92-AC84893BE83A@gmail.com> References: <8632E9B9-4EBF-498F-AF92-AC84893BE83A@gmail.com> Message-ID: On Sep 2, 2007, at 11:46, N_Ox wrote: > Just a little mail to say that someone should contact the wormux > staff and tell them that darwinports.com's owner is an obnoxious > dwarf and that they should not link it [1]. > > [1] http://www.wormux.org/wiki/fr/download.php Why..... didn't you just do that, instead of emailing this list? From pguyot at kallisys.net Sun Sep 2 21:57:35 2007 From: pguyot at kallisys.net (Paul Guyot) Date: Tue Oct 9 16:40:35 2007 Subject: Binutils installation problem In-Reply-To: References: <327271D8-9642-4E28-AD56-869B6CF36B90@mac.com> <7756872d369728944d04d6b96e4b0ec4@macports.org> Message-ID: <5E265082-7372-4C93-81D1-693BDCFEC8FC@kallisys.net> Le 1 sept. 07 ? 01:26, Ryan Schmidt a ?crit : >>> I work on a MacBook with Mac OS X 10.4 and with gcc 4.2.1 >> >> Ah, OK... The Portfile is probably not set up to handle the >> FSF GCC but assumes you are using the Apple GCC (/usr/bin/gcc). >> If you have such a non-standard gcc in your path, then you'll >> probably run into port problems with more than just binutils ? >> >> I suggest moving GCC 4.2.1 out of the default paths at least. >> But the port should probably not add -cpp-precomp for new GCC, >> and it will fail with the FSF GCC (including other platforms). >> Not sure how to do it in Tcl, but could be done with "system". > > I have submitted a ticket: > > http://trac.macosforge.org/projects/macports/ticket/12584 I already commented on Trac. The binutils port is only there to provide binutils programs in an Apple gcc environment. It does not make sense to use MacPorts to install binutils for FSF compilers. Chiara should either remove FSF compiler and retry or try to compile an FSF-obtained version of binutils. Paul -- http://paul-guyot.com/ From n.oxyde at gmail.com Mon Sep 3 00:16:53 2007 From: n.oxyde at gmail.com (N_Ox) Date: Tue Oct 9 16:40:35 2007 Subject: Wormux homepage links to darwinports.com In-Reply-To: References: <8632E9B9-4EBF-498F-AF92-AC84893BE83A@gmail.com> Message-ID: Le 3 sept. 07 ? 03:07, Ryan Schmidt a ?crit : > > On Sep 2, 2007, at 11:46, N_Ox wrote: > >> Just a little mail to say that someone should contact the wormux >> staff and tell them that darwinports.com's owner is an obnoxious >> dwarf and that they should not link it [1]. >> >> [1] http://www.wormux.org/wiki/fr/download.php > > > Why..... didn't you just do that, instead of emailing this list? > Because I thought it would be better if it was one of our big guys which tells them... and because I lack confiance in my english level. But I've just discovered they are nearly all frenchies; so I guess I can do it ;) -- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org From markd at macports.org Mon Sep 3 02:05:40 2007 From: markd at macports.org (markd@macports.org) Date: Tue Oct 9 16:40:35 2007 Subject: Man pages / Doc strategy In-Reply-To: References: Message-ID: Weissmann Markus writes: >> Why isn't configure.env supported anymore? >> > >oops - sorry, my fault! I really wanted to say: >Using configure.env directly should be avoided - we do have a nice >set of commands for setting the most used flags at configuration >time. If you cannot do without, of course it is still supported. > > >> The new guide documents this option, and does not mention anything >> about it being deprecated or unsupported. If it is unsupported, the >> guide should state that, and recommend alternatives. >> >> http://geeklair.net/new_macports_guide/#reference.keywords.configure >> > >Well yes. We should probably though put our manpages online, too and >clearly state that if in doubt the manpage is right. I personally find the man pages less than adequate. They were built piecemeal, and therefore they lack overall coherence; they are just lists with less structure than they should have. I intend to make the guide as authoritative as possible, at least as much as the current man pages. And I am striving for more coherently structured information in the new guide than in the old one or the man pages. If that can be accomplished, perhaps the man pages should be reformatted in DocBook and then they could be regened into man pages daily as is the guide, and then xincluded into the guide's reference section so as not to maintain duplicate source docs. Or at least that seems feasilbe by considering portfile.7 anyway. If we got that far I would also want to have a scratchpad where base committers past their preliminary doc additions for review and inclusion by the doc team. No more permanent doc changes in the middle of the night 5 minutes after hacking on base. Otherwise the docs just degrade over time as entropy sets in. Sounds good on paper anyway. Comments welcome. Mark From mww at macports.org Mon Sep 3 03:30:11 2007 From: mww at macports.org (Weissmann Markus) Date: Tue Oct 9 16:40:35 2007 Subject: Man pages / Doc strategy In-Reply-To: References: Message-ID: <2F076B06-DA6F-460F-8412-35F2BD2CE3F8@macports.org> On 03.09.2007, at 11:05, markd@macports.org wrote: > Weissmann Markus writes: >>> Why isn't configure.env supported anymore? >>> >> >> oops - sorry, my fault! I really wanted to say: >> Using configure.env directly should be avoided - we do have a nice >> set of commands for setting the most used flags at configuration >> time. If you cannot do without, of course it is still supported. >> >> >>> The new guide documents this option, and does not mention anything >>> about it being deprecated or unsupported. If it is unsupported, the >>> guide should state that, and recommend alternatives. >>> >>> http://geeklair.net/new_macports_guide/#reference.keywords.configure >>> >> >> Well yes. We should probably though put our manpages online, too and >> clearly state that if in doubt the manpage is right. > > I personally find the man pages less than adequate. They were built > piecemeal, and therefore they lack overall coherence; they are just > lists > with less structure than they should have. I intend to make the > guide as > authoritative as possible, at least as much as the current man > pages. And > I am striving for more coherently structured information in the new > guide > than in the old one or the man pages. If that can be accomplished, > perhaps the man pages should be reformatted in DocBook and then > they could > be regened into man pages daily as is the guide, and then xincluded > into > the guide's reference section so as not to maintain duplicate > source docs. > Or at least that seems feasilbe by considering portfile.7 anyway. > If we > got that far I would also want to have a scratchpad where base > committers > past their preliminary doc additions for review and inclusion by > the doc > team. No more permanent doc changes in the middle of the night 5 > minutes > after hacking on base. Otherwise the docs just degrade over time as > entropy sets in. Sounds good on paper anyway. Comments welcome. > Having only one place for documentation sounds great! I suppose regenerating the manpages for every release only could be sufficient. -Markus --- Markus W. Weissmann http://www.mweissmann.de/ From david.trem at gmail.com Mon Sep 3 05:10:43 2007 From: david.trem at gmail.com (David Tremouilles) Date: Tue Oct 9 16:40:35 2007 Subject: xfig In-Reply-To: References: Message-ID: <129e1cd10709030510i7a8fc65al8e38bc8a7583b783@mail.gmail.com> Hi Sebastian, Does the xfig fix work for you? David 2007/8/30, Ryan Schmidt : > On Aug 29, 2007, at 11:27, Sebastian Sandersius wrote: > > > On 8/26/07, Sebastian Sandersius wrote: > > >> It seems that xfig crashes with macports now. I don't know if its > >> the new beta version (3.2.5-alpha5) or if its something with > >> macports, because it worked fine with darwin. Basically what > >> happens is that if you to click on the > >> 'File','Edit','View','Snap', or 'Help' tabs it pulls down a blank > >> list and then crashes with this message in the portal: > >> > >> > >> color = '#ffcccc' > >> > >> > >> xfig3.2.5: SIGBUS signal trapped > >> xfig: figure empty or not modified - exiting > >> Abort trap > > > > Here is the fix (from Brian Smith, xfig developer): > > > > > > X11 vendors are using the newer version of the 3D Xaw widget set, > > 1.5e, which > > is not compatible with the original 3D Xaw widget set. > > What you need to do is edit the xfig Imakefile and uncomment this > > line: > > > > XCOMM #define XAW3D1_5E > > > > by removing the "XCOMM". > > Then do "xmkmf" and "make clean" then "make install". > > Thanks. > > I searched the issue tracker and found two bugs for this issue, one > of which contains this fix: > > http://trac.macosforge.org/projects/macports/ticket/12335 > > http://trac.macosforge.org/projects/macports/ticket/12044 > > I'm Cc'ing the xfig maintainer on this email. I'm also testing now > whether this fix works. > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev > From vincent-opdarw at vinc17.org Mon Sep 3 06:15:46 2007 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Tue Oct 9 16:40:35 2007 Subject: Problem with patchfiles (same name for different versions) Message-ID: <20070903131546.GP27290@prunille.vinc17.org> MacPorts stores patchfiles in /opt/local/var/macports/distfiles/${name} e.g. /opt/local/var/macports/distfiles/mpfr contains here: -rw-r--r-- 1 root admin 787634 2007-07-24 16:10:58 mpfr-2.2.1.tar.bz2 -rw-r--r-- 1 root admin 872947 2007-08-29 15:38:57 mpfr-2.3.0.tar.bz2 -rw-r--r-- 1 root admin 1826 2007-07-24 16:10:49 patch01 -rw-r--r-- 1 root admin 1687 2007-07-24 16:10:52 patch02 -rw-r--r-- 1 root admin 11655 2007-07-24 16:10:52 patch03 -rw-r--r-- 1 root admin 7509 2007-07-24 16:10:53 patch04 -rw-r--r-- 1 root admin 16992 2007-07-24 16:10:53 patch05 The problem is that patches are not stored in a subdirectory that depends on the version. So, there is a clash if I want to declare patch01 as a new patchfile for mpfr-2.3.0. What is the recommended solution? -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From vincent-opdarw at vinc17.org Mon Sep 3 06:25:07 2007 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Tue Oct 9 16:40:35 2007 Subject: Doc directory (was: [28480] trunk/dports/archivers/p7zip) In-Reply-To: <20070901142825.B236276DA7D@cvs.opensource.apple.com> References: <20070901142825.B236276DA7D@cvs.opensource.apple.com> Message-ID: <20070903132507.GQ27290@prunille.vinc17.org> On 2007-09-01 07:28:25 -0700, source_changes@macosforge.org wrote: > * Changed doc directory to ${name}-${version}. I don't know if there has been a discussion about this, but is there any reason to include the version, given the fact that two different versions cannot be activated at the same time? I find this a bit annoying as including the version makes the pathnames change after an upgrade, so that one can no longer say: "see /opt/local/share/doc/p7zip/README" or make a symlink to it. -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From afb at macports.org Mon Sep 3 06:29:47 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Oct 9 16:40:35 2007 Subject: Problem with patchfiles (same name for different versions) In-Reply-To: <20070903131546.GP27290@prunille.vinc17.org> References: <20070903131546.GP27290@prunille.vinc17.org> Message-ID: <739c7219bf34fd1d05a02b73742c739f@macports.org> Vincent Lefevre wrote: > The problem is that patches are not stored in a subdirectory that > depends on the version. So, there is a clash if I want to declare > patch01 as a new patchfile for mpfr-2.3.0. What is the recommended > solution? Usually the patch files are overwritten along with the Portfile. So you have one set of Portfile + files for each version/release. And when you add the new distfile for the new version of the port, the old distfile is removed at the same time (usually same commit) If one wants to dig up old versions/releases, then SVN is used... (it can be archived into a portpkg or source package if so desired) --anders From vincent-opdarw at vinc17.org Mon Sep 3 06:47:45 2007 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Tue Oct 9 16:40:35 2007 Subject: zsh and zsh-devel In-Reply-To: References: <40828949-1292-4B99-9C25-D9908B196B60@gmail.com> Message-ID: <20070903134745.GR27290@prunille.vinc17.org> On 2007-09-02 22:40:01 +0200, Anders F Bj?rklund wrote: > N_Ox wrote: > >> zsh is now quite old and its maintainship has been dropped. >> I'm the current maintainer of zsh-devel and I think it does not deserve >> its -devel nature. >> Should we delete zsh and rename zsh-devel? > > Upstream still lists 4.2.6 (2005-12-05) as the "stable" series and 4.3.4 > (2007-04-19) as the "development" series, so it seems a good idea to keep > the current naming ? BTW, I don't really like the names "stable" and "development" since they don't always mean what they really mean. In particular, one may think that the development version is more buggy than the stable version. In the case of zsh, this is currently the opposite. Also "development" is misleading when at some point, a developement version becomes a stable version. For instance, what if the successor of 4.3.4 becomes the stable version 4.4.0, so that 4.3.4 is out-of-date and 4.5.0 isn't out yet? The user of zsh-devel should expect an upgrade to 4.4.0 instead of staying with the out-of-date 4.3.4. -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From n.oxyde at gmail.com Mon Sep 3 06:57:47 2007 From: n.oxyde at gmail.com (N_Ox) Date: Tue Oct 9 16:40:35 2007 Subject: Doc directory (was: [28480] trunk/dports/archivers/p7zip) In-Reply-To: <20070903132507.GQ27290@prunille.vinc17.org> References: <20070901142825.B236276DA7D@cvs.opensource.apple.com> <20070903132507.GQ27290@prunille.vinc17.org> Message-ID: <191BD43C-48B4-459F-BF22-A8D49FE0CA51@gmail.com> Le 3 sept. 07 ? 15:25, Vincent Lefevre a ?crit : > On 2007-09-01 07:28:25 -0700, source_changes@macosforge.org wrote: >> * Changed doc directory to ${name}-${version}. > > I don't know if there has been a discussion about this, but is there > any reason to include the version, given the fact that two different > versions cannot be activated at the same time? > > I find this a bit annoying as including the version makes the > pathnames change after an upgrade, so that one can no longer > say: "see /opt/local/share/doc/p7zip/README" or make a symlink > to it. > > -- > Vincent Lef?vre - Web: > 100% accessible validated (X)HTML - Blog: blog/> > Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS- > Lyon) Recent autotools-based package doc directories default to ${name}-$ {version} (see libogg and libvorbis). Also, I love to have maximum informations about my installed packages in the documentation directory and version _is_ an important information. Last, you do can have multiple versions of the same package, see automake and all, including version in docdir for only a few packages seems quite awkward and inconsistent to me. You cannot do a symlink, but you can always do `see /opt/local/share/ doc/p7zip*/README`. -- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org From vincent-opdarw at vinc17.org Mon Sep 3 06:59:50 2007 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Tue Oct 9 16:40:35 2007 Subject: Newbie Port Creator Questions In-Reply-To: <71EC8A7B-E320-413C-9934-B5C3BBEF669A@macports.org> References: <05BCB0A2-E3E0-4F89-85B0-9B30E98B7094@macports.org> <6FFAC741-233A-4425-BE2B-EFEB7CBD4197@vexate.net> <71EC8A7B-E320-413C-9934-B5C3BBEF669A@macports.org> Message-ID: <20070903135950.GS27290@prunille.vinc17.org> On 2007-09-03 00:27:44 +0200, Weissmann Markus wrote: > The thing with GPLed code is, that it is viral, so everything you > link against it (or mix with it) will get GPLed code, too. I'm not > quite sure what if you do not own the original source (e.g. it is > BSD licensed), but I assume that everyone will be happy as long as > the viral effect of the GPL is kept and you distribute the source > code along a binary. AFAIK, the BSD license allows you to create a derived work that would be distributed under the GPL. Owning the original source is necessary only if you want to change the license in an incompatible manner (e.g. you created a work which you distributed under the GPLv2 and you want to distribute a future version under the GPLv3+). -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From n.oxyde at gmail.com Mon Sep 3 07:01:54 2007 From: n.oxyde at gmail.com (N_Ox) Date: Tue Oct 9 16:40:35 2007 Subject: Problem with patchfiles (same name for different versions) In-Reply-To: <739c7219bf34fd1d05a02b73742c739f@macports.org> References: <20070903131546.GP27290@prunille.vinc17.org> <739c7219bf34fd1d05a02b73742c739f@macports.org> Message-ID: Le 3 sept. 07 ? 15:29, Anders F Bj?rklund a ?crit : > Vincent Lefevre wrote: > >> The problem is that patches are not stored in a subdirectory that >> depends on the version. So, there is a clash if I want to declare >> patch01 as a new patchfile for mpfr-2.3.0. What is the recommended >> solution? > > Usually the patch files are overwritten along with the Portfile. > So you have one set of Portfile + files for each version/release. > And when you add the new distfile for the new version of the port, > the old distfile is removed at the same time (usually same commit) > > If one wants to dig up old versions/releases, then SVN is used... > (it can be archived into a portpkg or source package if so desired) > > --anders I think he's talking about patches fetched from remote sources. -- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org From afb at macports.org Mon Sep 3 07:20:04 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Oct 9 16:40:35 2007 Subject: Problem with patchfiles (same name for different versions) In-Reply-To: References: <20070903131546.GP27290@prunille.vinc17.org> <739c7219bf34fd1d05a02b73742c739f@macports.org> Message-ID: <1519375e79e789294fd479b64cb590d6@macports.org> N_Ox wrote: >>> The problem is that patches are not stored in a subdirectory that >>> depends on the version. So, there is a clash if I want to declare >>> patch01 as a new patchfile for mpfr-2.3.0. What is the recommended >>> solution? >> >> Usually the patch files are overwritten along with the Portfile. >> So you have one set of Portfile + files for each version/release. >> And when you add the new distfile for the new version of the port, >> the old distfile is removed at the same time (usually same commit) > > I think he's talking about patches fetched from remote sources. Okay, then it will fall into the "what to do when upstream does not have versioned files" category. As in: they probably need renaming. e.g. patch01 -> mpfr-2.3.0-patch01 --anders From vincent-opdarw at vinc17.org Mon Sep 3 07:31:59 2007 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Tue Oct 9 16:40:35 2007 Subject: Doc directory (was: [28480] trunk/dports/archivers/p7zip) In-Reply-To: <191BD43C-48B4-459F-BF22-A8D49FE0CA51@gmail.com> References: <20070901142825.B236276DA7D@cvs.opensource.apple.com> <20070903132507.GQ27290@prunille.vinc17.org> <191BD43C-48B4-459F-BF22-A8D49FE0CA51@gmail.com> Message-ID: <20070903143159.GT27290@prunille.vinc17.org> On 2007-09-03 15:57:47 +0200, N_Ox wrote: > Recent autotools-based package doc directories default to > ${name}-${version} (see libogg and libvorbis). But why did they do such a change? Note that this is a setting that comes from these particular packages, not from the autotools: libogg-1.1.3/doc/Makefile.am contains: docdir = $(datadir)/doc/$(PACKAGE)-$(VERSION) AFAIK, this is not standard, as the default autoconf sets the default to DATAROOTDIR/doc/$(PACKAGE). Unless this has changed recently... > Also, I love to have maximum informations about my installed packages in > the documentation directory and version _is_ an important information. This can be done in some other way, though (e.g. a VERSION file in the doc directory, or the NEWS file...). > Last, you do can have multiple versions of the same package, see automake OK, but packages like automake are different: version information is included everywhere, including in the binary, and only the major version (e.g. 1.10, not 1.10.x). > and all, including version in docdir for only a few packages seems quite > awkward and inconsistent to me. Because for automake, there is a reason, and this is not even the version, but the package name. For instance, concerning automake17, you have ${prefix}/share/doc/automake17, not ${prefix}/share/doc/automake17-1.7.9. Ditto for DocBook: you have different incompatible versions, but it makes sense to have them installed at the same time. For consistency, it would be better to stick with the autotools standard. -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From vincent-opdarw at vinc17.org Mon Sep 3 07:39:35 2007 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Tue Oct 9 16:40:35 2007 Subject: Problem with patchfiles (same name for different versions) In-Reply-To: <1519375e79e789294fd479b64cb590d6@macports.org> References: <20070903131546.GP27290@prunille.vinc17.org> <739c7219bf34fd1d05a02b73742c739f@macports.org> <1519375e79e789294fd479b64cb590d6@macports.org> Message-ID: <20070903143935.GU27290@prunille.vinc17.org> On 2007-09-03 16:20:04 +0200, Anders F Bj?rklund wrote: > N_Ox wrote: >>> Usually the patch files are overwritten along with the Portfile. >>> So you have one set of Portfile + files for each version/release. >>> And when you add the new distfile for the new version of the port, >>> the old distfile is removed at the same time (usually same commit) >> >> I think he's talking about patches fetched from remote sources. Yes. Of course, I could put the patches in the MacPorts repository, but I don't think this is recommended, as not every MacPorts user need them (if every ports did that, it would multiply the repository and working copy size by some factor). > Okay, then it will fall into the "what to do when upstream does not > have versioned files" category. As in: they probably need renaming. Upstream patches are versioned: they are in different subdirectories. But MacPorts doesn't care, unless I've missed something to have the subdirectory taken into account. > e.g. patch01 -> mpfr-2.3.0-patch01 How can I do that? "patchfiles" contains only the patch names, I didn't see any possibility of rename. -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From vincent-opdarw at vinc17.org Mon Sep 3 07:48:33 2007 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Tue Oct 9 16:40:35 2007 Subject: Problem with patchfiles (same name for different versions) In-Reply-To: <20070903143935.GU27290@prunille.vinc17.org> References: <20070903131546.GP27290@prunille.vinc17.org> <739c7219bf34fd1d05a02b73742c739f@macports.org> <1519375e79e789294fd479b64cb590d6@macports.org> <20070903143935.GU27290@prunille.vinc17.org> Message-ID: <20070903144833.GB27845@prunille.vinc17.org> On 2007-09-03 16:39:35 +0200, Vincent Lefevre wrote: > Upstream patches are versioned: they are in different subdirectories. > But MacPorts doesn't care, unless I've missed something to have the > subdirectory taken into account. Also, I tried specifying the directory after patchfiles, but "port" does a bus error in this case: Portfile changed since last build; discarding previous state. ---> Fetching mpfr ---> mpfr-2.3.0/patch01 doesn't seem to exist in /opt/local/var/macports/distfiles/mpfr ---> Attempting to fetch mpfr-2.3.0/patch01 from http://www.mpfr.org/ zsh: bus error sudo port -v upgrade mpfr -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From chiara.sandionigi at mac.com Mon Sep 3 08:53:00 2007 From: chiara.sandionigi at mac.com (Chiara Sandionigi) Date: Tue Oct 9 16:40:36 2007 Subject: Binutils installation problem In-Reply-To: <5E265082-7372-4C93-81D1-693BDCFEC8FC@kallisys.net> References: <327271D8-9642-4E28-AD56-869B6CF36B90@mac.com> <7756872d369728944d04d6b96e4b0ec4@macports.org> <5E265082-7372-4C93-81D1-693BDCFEC8FC@kallisys.net> Message-ID: On 03/set/07, at 06:57, Paul Guyot wrote: > Chiara should either remove FSF compiler and retry or try to > compile an FSF-obtained version of binutils. Unfortunately no solution works properly. ::. Using gcc 4.0.1 of Apple and installing binutils through macport, I have the following error ---> Building binutils with target all Error: Target org.macports.build returned: shell command " cd "/opt/ local/var/macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_b inutils/work/build" && make all " returned error 2 Command output: if [ x"" != x ]; then \ cc -no-cpp-precomp -c -DHAVE_CONFIG_H -O2 -I. -I/opt/local/var/ macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_b inutils/work/binutils-2.17/libiberty/../include -W -Wall -pedantic - Wwrite-strings -Wstrict-prototypes -Wc++-compat /opt/local/var/ macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_b inutils/work/binutils-2.17/libiberty/fibheap.c -o pic/fibheap.o; \ else true; fi cc -no-cpp-precomp -c -DHAVE_CONFIG_H -O2 -I. -I/opt/local/var/ macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_b inutils/work/binutils-2.17/libiberty/../include -W -Wall -pedantic - Wwrite-strings -Wstrict-prototypes -Wc++-compat /opt/local/var/ macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_b inutils/work/binutils-2.17/libiberty/fibheap.c -o fibheap.o cc1: error: unrecognized command line option "-Wc++-compat" make[2]: *** [fibheap.o] Error 1 make[1]: *** [all-libiberty] Error 2 make: *** [all] Error 2 Error: Status 1 encountered during processing. ::. Using gcc 3.3 of Apple and installing binutils through macport, I have the following error ---> Building binutils with target all Error: Target org.macports.build returned: shell command " cd "/opt/ local/var/macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_b inutils/work/build" && make all " returned error 2 Command output: if [ x"" != x ]; then \ cc -no-cpp-precomp -c -DHAVE_CONFIG_H -O2 -I. -I/opt/local/var/ macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_b inutils/work/binutils-2.17/libiberty/../include -W -Wall -pedantic - Wwrite-strings -Wstrict-prototypes -Wc++-compat /opt/local/var/ macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_b inutils/work/binutils-2.17/libiberty/fibheap.c -o pic/fibheap.o; \ else true; fi cc -no-cpp-precomp -c -DHAVE_CONFIG_H -O2 -I. -I/opt/local/var/ macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_b inutils/work/binutils-2.17/libiberty/../include -W -Wall -pedantic - Wwrite-strings -Wstrict-prototypes -Wc++-compat /opt/local/var/ macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_b inutils/work/binutils-2.17/libiberty/fibheap.c -o fibheap.o cc: installation problem, cannot exec `cc1': No such file or directory make[2]: *** [fibheap.o] Error 1 make[1]: *** [all-libiberty] Error 2 make: *** [all] Error 2 Error: Status 1 encountered during processing. ::. Compiling a FSF version of binutils and using gcc 4.2.1 of FSF, I get the following during the installation phase /bin/sh ./mkinstalldirs /usr/local /usr/local for f in standards.info configure.info; do \ if test -f .././etc/`echo $f | sed -e 's/.info$/.texi/'`; then \ if make "MAKEINFO=makeinfo --split-size=5000000 --split- size=5000000" $f; then \ true; \ else \ exit 1; \ fi; \ fi; \ done make[3]: `standards.info' is up to date. make[3]: `configure.info' is up to date. /bin/sh .././etc/../mkinstalldirs /usr/local/info if test ! -f standards.info; then cd .././etc; fi; \ if test -f standards.info; then \ for i in standards.info*; do \ /usr/bin/install -c -m 644 $i /usr/local/info/$i; \ done; \ fi if test ! -f configure.info; then cd .././etc; fi; \ if test -f configure.info; then \ for i in configure.info*; do \ /usr/bin/install -c -m 644 $i /usr/local/info/$i; \ done; \ fi make[2]: Nothing to be done for `install'. make[3]: Nothing to be done for `all'. /bin/sh .././libiberty/../mkinstalldirs /usr/local/lib/`gcc -g -O2 - print-multi-os-directory` /usr/bin/install -c -m 644 ./libiberty.a /usr/local/lib/`gcc -g -O2 - print-multi-os-directory`/./libiberty.an ( cd /usr/local/lib/`gcc -g -O2 -print-multi-os-directory` ; chmod 644 ./libiberty.an ;ranlib ./libiberty.an ) mv -f /usr/local/lib/`gcc -g -O2 -print-multi-os-directory`/./ libiberty.an /usr/local/lib/`gcc -g -O2 -print-multi-os-directory`/./ libiberty.a if test -n ""; then \ case "" in \ /*) thd=;; \ *) thd=/usr/local/include/;; \ esac; \ /bin/sh .././libiberty/../mkinstalldirs ${thd}; \ for h in .././libiberty/../include/ansidecl.h .././libiberty/../ include/demangle.h .././libiberty/../include/dyn-string.h .././ libiberty/../include/fibheap.h .././libiberty/../include/ floatformat.h .././libiberty/../include/hashtab.h .././libiberty/../ include/libiberty.h .././libiberty/../include/objalloc.h .././ libiberty/../include/partition.h .././libiberty/../include/safe- ctype.h .././libiberty/../include/sort.h .././libiberty/../include/ splay-tree.h; do \ /usr/bin/install -c -m 644 $h ${thd}; \ done; \ fi make[3]: Nothing to be done for `install'. make[1]: Nothing to be done for `install-target'. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20070903/8ea2931a/attachment.html From jmpp at macports.org Mon Sep 3 10:11:41 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:36 2007 Subject: Infrastructure requests Message-ID: Hello all! I recently created a page listing what I believe are the top priority infrastructure requests we have for our Mac OS Forge host, http://trac.macports.org/projects/macports/wiki/InfrastructureRequests Per the introductory text in there: "When thinking about a functionality you may desire at the server level, keep in mind that Mac OS Forge is not only shared with other projects but also that it does not have a staff of dedicated system administrators to cater to every single request. Therefore please refrain from submitting any infrastructure related ticket before presenting a valid case for it on the MacPorts development list and gathering at least some consensus over your proposal. Generally speaking, it's best to channel such requests through the MacPorts management team (jberry, jmpp & mww), since they are the ones in most frequent communication with Mac OS Forge admin personnel and as a result have a better feel for the state of current infrastructure and/ or pending requests." So please do feel free to brainstorm over what I listed on that page and the tickets I linked, but also please do discuss here any modifications you might want to make to it or new request tickets you might want to submit. Thanks for your help in streamlining our feedback channels with our very kind host ;-) Regards,... -jmpp From ryandesign at macports.org Mon Sep 3 10:18:29 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:36 2007 Subject: Problem with patchfiles (same name for different versions) In-Reply-To: <20070903144833.GB27845@prunille.vinc17.org> References: <20070903131546.GP27290@prunille.vinc17.org> <739c7219bf34fd1d05a02b73742c739f@macports.org> <1519375e79e789294fd479b64cb590d6@macports.org> <20070903143935.GU27290@prunille.vinc17.org> <20070903144833.GB27845@prunille.vinc17.org> Message-ID: <1C8DCE52-8AE4-49AB-B71C-A2381A12F01B@macports.org> On Sep 3, 2007, at 09:48, Vincent Lefevre wrote: > On 2007-09-03 16:39:35 +0200, Vincent Lefevre wrote: > >> Upstream patches are versioned: they are in different subdirectories. >> But MacPorts doesn't care, unless I've missed something to have the >> subdirectory taken into account. > > Also, I tried specifying the directory after patchfiles, but "port" > does a bus error in this case: > > Portfile changed since last build; discarding previous state. > ---> Fetching mpfr > ---> mpfr-2.3.0/patch01 doesn't seem to exist in /opt/local/var/ > macports/distfiles/mpfr > ---> Attempting to fetch mpfr-2.3.0/patch01 from http://www.mpfr.org/ > zsh: bus error sudo port -v upgrade mpfr I also don't know if patchfiles/distfiles can be renamed after download. In the absence of that feature, I recommend: dist_subdir ${name}/${version} (Instead of the default dist_subdir ${name}) From ryandesign at macports.org Mon Sep 3 10:22:17 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:36 2007 Subject: zsh and zsh-devel In-Reply-To: <20070903134745.GR27290@prunille.vinc17.org> References: <40828949-1292-4B99-9C25-D9908B196B60@gmail.com> <20070903134745.GR27290@prunille.vinc17.org> Message-ID: <3A27714A-5FC3-4A9A-86A7-795D4B59A0A9@macports.org> On Sep 3, 2007, at 08:47, Vincent Lefevre wrote: > On 2007-09-02 22:40:01 +0200, Anders F Bj?rklund wrote: > >> N_Ox wrote: >> >>> zsh is now quite old and its maintainship has been dropped. >>> I'm the current maintainer of zsh-devel and I think it does not >>> deserve >>> its -devel nature. >>> Should we delete zsh and rename zsh-devel? >> >> Upstream still lists 4.2.6 (2005-12-05) as the "stable" series and >> 4.3.4 >> (2007-04-19) as the "development" series, so it seems a good idea >> to keep >> the current naming ? > > BTW, I don't really like the names "stable" and "development" since > they don't always mean what they really mean. In particular, one may > think that the development version is more buggy than the stable > version. In the case of zsh, this is currently the opposite. > > Also "development" is misleading when at some point, a developement > version becomes a stable version. For instance, what if the successor > of 4.3.4 becomes the stable version 4.4.0, so that 4.3.4 is out-of- > date > and 4.5.0 isn't out yet? The user of zsh-devel should expect an > upgrade > to 4.4.0 instead of staying with the out-of-date 4.3.4. What portname suffix would you propose instead of "-devel"? "-devel" seems ok to me -- it indicates that this will install the version currently being developed by the developers, as opposed to the version that is stable and has already been developed. We could use "-beta" but that would be inaccurate for many software projects where that's not the term they use to describe their development software. From jmpp at macports.org Mon Sep 3 11:00:31 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:36 2007 Subject: Wormux homepage links to darwinports.com In-Reply-To: References: <8632E9B9-4EBF-498F-AF92-AC84893BE83A@gmail.com> Message-ID: On Sep 3, 2007, at 3:16 AM, N_Ox wrote: > > Le 3 sept. 07 ? 03:07, Ryan Schmidt a ?crit : > >> >> On Sep 2, 2007, at 11:46, N_Ox wrote: >> >>> Just a little mail to say that someone should contact the wormux >>> staff and tell them that darwinports.com's owner is an obnoxious >>> dwarf and that they should not link it [1]. >>> >>> [1] http://www.wormux.org/wiki/fr/download.php >> >> >> Why..... didn't you just do that, instead of emailing this list? >> > > Because I thought it would be better if it was one of our big guys > which tells them... and because I lack confiance in my english level. > But I've just discovered they are nearly all frenchies; so I guess > I can do it ;) > I already contacted them and they corrected the link, thanks for the heads-up! On a related note, given that we don't really have useful and understandable per port pages, I had to provide them with a link to the Portfile through the trac browser, which in my opinion is a rather lame solution (though better than linking to darwinports.com ;-). In thinking our website redesign in parallel threads, this is something we should definitely take into account, some kind of a template page that can be dynamically rendered for every port with information similar to that of "port info" and instructions on how to install it. And yes, I do realize this is something we'd be more or less copying off darwinports.com, shame on us! But, first off, no one ever said we can't have our shot at getting back ;-) And second, the unfortunate popularity of that page has proven that such a per-port-page approach is successful, so we might as well implement it too. Regards,... -jmpp From vincent-opdarw at vinc17.org Mon Sep 3 11:33:13 2007 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Tue Oct 9 16:40:36 2007 Subject: zsh and zsh-devel In-Reply-To: <3A27714A-5FC3-4A9A-86A7-795D4B59A0A9@macports.org> References: <40828949-1292-4B99-9C25-D9908B196B60@gmail.com> <20070903134745.GR27290@prunille.vinc17.org> <3A27714A-5FC3-4A9A-86A7-795D4B59A0A9@macports.org> Message-ID: <20070903183313.GI27290@prunille.vinc17.org> On 2007-09-03 12:22:17 -0500, Ryan Schmidt wrote: > What portname suffix would you propose instead of "-devel"? "-devel" seems > ok to me -- it indicates that this will install the version currently being > developed by the developers, as opposed to the version that is stable and > has already been developed. But the version currently being developed can be the *same* as the stable version (e.g. after a feature freeze). -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From mww at macports.org Mon Sep 3 13:17:39 2007 From: mww at macports.org (Weissmann Markus) Date: Tue Oct 9 16:40:36 2007 Subject: [28562] trunk/dports In-Reply-To: <20070903195223.EEC14771FCC@cvs.opensource.apple.com> References: <20070903195223.EEC14771FCC@cvs.opensource.apple.com> Message-ID: Hey, thanks a lot for fixing my typos! That was really quick! :) -Markus On 03.09.2007, at 21:52, source_changes@macosforge.org wrote: > Revision 28562 Author ryandesign@macports.org Date 2007-09-03 > 12:52:23 -0700 (Mon, 03 Sep 2007) Log Message fix syntax errors > introduced in recent configure.env cleaning Modified Paths > trunk/dports/gnome/acme/Portfile > trunk/dports/gnome/mergeant/Portfile > trunk/dports/gnome/oregano/Portfile > trunk/dports/gnome/xchat-gnome/Portfile > trunk/dports/lang/swi-prolog-lite/Portfile > Diff > Modified: trunk/dports/gnome/acme/Portfile (28561 => 28562) --- > trunk/dports/gnome/acme/Portfile 2007-09-03 19:43:44 UTC (rev > 28561) +++ trunk/dports/gnome/acme/Portfile 2007-09-03 19:52:23 UTC > (rev 28562) @@ -16,5 +16,5 @@ checksums md5 > 0e4b240662a706d529757a86fe4bf0c5 depends_lib lib:libgnome-window- > settings:control-center use_bzip2 yes -configure.cppflaghs-append "- > L${prefix}/lib" +configure.cppflags-append "-L${prefix}/lib" > configure.cflags-append "-bind_at_load -no-cpp-precomp - > flat_namespace -undefined suppress" > Modified: trunk/dports/gnome/mergeant/Portfile (28561 => 28562) --- > trunk/dports/gnome/mergeant/Portfile 2007-09-03 19:43:44 UTC (rev > 28561) +++ trunk/dports/gnome/mergeant/Portfile 2007-09-03 19:52:23 > UTC (rev 28562) @@ -13,7 +13,7 @@ checksums md5 > 42a2f6778b81409db6cd1baa49663dca use_bzip2 yes depends_lib > lib:libgnomedb-2:libgnomedb -configure.cppflags-append "-L${prefix}/ > lib +configure.cppflags-append "-L${prefix}/lib" configure.cflags- > append "-I${prefix}/include" platform darwin 8 powerpc { > Modified: trunk/dports/gnome/oregano/Portfile (28561 => 28562) --- > trunk/dports/gnome/oregano/Portfile 2007-09-03 19:43:44 UTC (rev > 28561) +++ trunk/dports/gnome/oregano/Portfile 2007-09-03 19:52:23 > UTC (rev 28562) @@ -15,4 +15,4 @@ use_bzip2 yes configure.args -- > mandir=${prefix}/share/man configure.cppflags-append "-L${prefix}/ > lib" -configure.clfags-append "-no-cpp-precomp -flat_namespace - > undefined suppress" +configure.cflags-append "-no-cpp-precomp - > flat_namespace -undefined suppress" > Modified: trunk/dports/gnome/xchat-gnome/Portfile (28561 => 28562) > --- trunk/dports/gnome/xchat-gnome/Portfile 2007-09-03 19:43:44 UTC > (rev 28561) +++ trunk/dports/gnome/xchat-gnome/Portfile 2007-09-03 > 19:52:23 UTC (rev 28562) @@ -17,5 +17,5 @@ depends_lib bin:gnome- > session:gnome-session patchfiles patch_outbound.c > configure.cppflags-append "-L${prefix}/lib" -confgure.cflags-append > "-no-cpp-precomp -flat_namespace -undefined suppress" > +configure.cflags-append "-no-cpp-precomp -flat_namespace - > undefined suppress" configure.args --enable-gnomefe --disable-python > Modified: trunk/dports/lang/swi-prolog-lite/Portfile (28561 => > 28562) --- trunk/dports/lang/swi-prolog-lite/Portfile 2007-09-03 > 19:43:44 UTC (rev 28561) +++ trunk/dports/lang/swi-prolog-lite/ > Portfile 2007-09-03 19:52:23 UTC (rev 28562) @@ -30,7 +30,7 @@ > distname pl-${version} worksrcdir pl-${version}/src - > configure.cflas-append "-I${prefix}/include" +configure.cflags- > append "-I${prefix}/include" configure.env CIFLAGS="-I${prefix}/ > include" configure.args --mandir=/${prefix}/share/man \ > _______________________________________________ > macports-changes mailing list > macports-changes@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-changes --- Markus W. Weissmann http://www.mweissmann.de/ From afb at macports.org Mon Sep 3 13:30:01 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Oct 9 16:40:36 2007 Subject: [28562] trunk/dports In-Reply-To: References: <20070903195223.EEC14771FCC@cvs.opensource.apple.com> Message-ID: <54181aeb8abf4ae2bf3de1f660b4cd86@macports.org> Weissmann Markus wrote: > Hey, thanks a lot for fixing my typos! That was really quick! :) BTW; Syntax errors in Portfiles are detected by "port lint".... --anders From afb at macports.org Mon Sep 3 13:42:51 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Oct 9 16:40:36 2007 Subject: Portfile Pillow Fight In-Reply-To: References: Message-ID: <7168dbbd352e19e7e55be472810d9dd5@macports.org> Ryan Schmidt wrote: >> ---> Verifying Portfile for sleepwatcher >> Warning: Line 40 has trailing whitespace before newline >> Warning: Line 46 has trailing whitespace before newline >> ---> 0 errors and 2 warnings found. > > I wish to have that whitespace there and do not want port lint to > complain about it. "port lint" no longer complains about such whitespace use. --anders From mww at macports.org Mon Sep 3 14:17:51 2007 From: mww at macports.org (Weissmann Markus) Date: Tue Oct 9 16:40:36 2007 Subject: [28562] trunk/dports In-Reply-To: <54181aeb8abf4ae2bf3de1f660b4cd86@macports.org> References: <20070903195223.EEC14771FCC@cvs.opensource.apple.com> <54181aeb8abf4ae2bf3de1f660b4cd86@macports.org> Message-ID: <1AA2A3F9-3539-4FF9-8BD1-7152272DF6DD@macports.org> On 03.09.2007, at 22:30, Anders F Bj?rklund wrote: > Weissmann Markus wrote: > >> Hey, thanks a lot for fixing my typos! That was really quick! :) > > BTW; Syntax errors in Portfiles are detected by "port lint".... > I suppose this only is in trunk so far? -Markus --- Markus W. Weissmann http://www.mweissmann.de/ From afb at macports.org Mon Sep 3 14:28:13 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Oct 9 16:40:36 2007 Subject: [28562] trunk/dports In-Reply-To: <1AA2A3F9-3539-4FF9-8BD1-7152272DF6DD@macports.org> References: <20070903195223.EEC14771FCC@cvs.opensource.apple.com> <54181aeb8abf4ae2bf3de1f660b4cd86@macports.org> <1AA2A3F9-3539-4FF9-8BD1-7152272DF6DD@macports.org> Message-ID: <744b166b8bb9021ab26df7f0fa188272@macports.org> Weissmann Markus: >> BTW; Syntax errors in Portfiles are detected by "port lint".... > > I suppose this only is in trunk so far? Yes, that is correct. Trac and Trunk (1.6.0). --anders From vincent-opdarw at vinc17.org Mon Sep 3 15:19:09 2007 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Tue Oct 9 16:40:36 2007 Subject: Problem with patchfiles (same name for different versions) In-Reply-To: <1C8DCE52-8AE4-49AB-B71C-A2381A12F01B@macports.org> References: <20070903131546.GP27290@prunille.vinc17.org> <739c7219bf34fd1d05a02b73742c739f@macports.org> <1519375e79e789294fd479b64cb590d6@macports.org> <20070903143935.GU27290@prunille.vinc17.org> <20070903144833.GB27845@prunille.vinc17.org> <1C8DCE52-8AE4-49AB-B71C-A2381A12F01B@macports.org> Message-ID: <20070903221909.GJ27290@prunille.vinc17.org> On 2007-09-03 12:18:29 -0500, Ryan Schmidt wrote: > I also don't know if patchfiles/distfiles can be renamed after > download. In the absence of that feature, I recommend: > > dist_subdir ${name}/${version} > > (Instead of the default dist_subdir ${name}) Thanks, this solves the problem. -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From raimue at macports.org Mon Sep 3 15:38:15 2007 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue Oct 9 16:40:36 2007 Subject: Newbie Port Creator Questions In-Reply-To: <20070903135950.GS27290@prunille.vinc17.org> References: <05BCB0A2-E3E0-4F89-85B0-9B30E98B7094@macports.org> <6FFAC741-233A-4425-BE2B-EFEB7CBD4197@vexate.net> <71EC8A7B-E320-413C-9934-B5C3BBEF669A@macports.org> <20070903135950.GS27290@prunille.vinc17.org> Message-ID: <46DC8CD7.8010808@macports.org> Vincent Lefevre wrote: > AFAIK, the BSD license allows you to create a derived work that would > be distributed under the GPL. Owning the original source is necessary > only if you want to change the license in an incompatible manner (e.g. > you created a work which you distributed under the GPLv2 and you want > to distribute a future version under the GPLv3+). GPLv2 is not necessarily incompatible with GPLv3. GPL lets the original author choose how new versions apply to the software. See paragraph 9 of the GPLv2 [1]. --snip-- | Each version is given a distinguishing version number. If the Program | specifies a version number of this License which applies to it and "any | later version", you have the option of following the terms and conditions | either of that version or of any later version published by the Free | Software Foundation. --snap-- [1] http://www.gnu.org/licenses/gpl-2.0.html So if a software supplies the phrase "either version 2 of the License, or (at your option) any later version." then I think it can be used and redistributed under the Terms of GPLv3. IANAL, that's just how I understand it. Rainer From vincent-opdarw at vinc17.org Mon Sep 3 16:22:00 2007 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Tue Oct 9 16:40:36 2007 Subject: Problem with the repository: bogus date Message-ID: <20070903232200.GL27290@prunille.vinc17.org> I've noticed the following error: $ svn log -r2 https://svn.macosforge.org/repository/macports svn: Bogus date -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From raimue at macports.org Mon Sep 3 16:51:25 2007 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue Oct 9 16:40:36 2007 Subject: Problem with the repository: bogus date In-Reply-To: <20070903232200.GL27290@prunille.vinc17.org> References: <20070903232200.GL27290@prunille.vinc17.org> Message-ID: <46DC9DFD.7020509@macports.org> Vincent Lefevre wrote: > I've noticed the following error: > > $ svn log -r2 https://svn.macosforge.org/repository/macports > svn: Bogus date It is really a "Bogus date", as you can see in the following log: --snip-- | $ svn log --xml -r2 https://svn.macosforge.org/repository/macports | | | | landonf | http://svn.seven:8080/code | Initial revision | | | --snap-- Maybe this happened on import from an older repository or you can put the blame on cvs2svn. At least you can read the log message with --xml. Rainer From markd at macports.org Mon Sep 3 17:05:41 2007 From: markd at macports.org (markd@macports.org) Date: Tue Oct 9 16:40:36 2007 Subject: Man pages / Doc strategy In-Reply-To: <2F076B06-DA6F-460F-8412-35F2BD2CE3F8@macports.org> References: <2F076B06-DA6F-460F-8412-35F2BD2CE3F8@macports.org> Message-ID: Weissmann Markus writes: >Having only one place for documentation sounds great! I suppose >regenerating the manpages for every release only could be sufficient. Yes I suppose so. I was forgetting that if hte man pages were in DocBook, there would be two regens; one for the html guide reference pages, and one for the man pages themselves. The latter could be done at each release. Mark From rhwood at mac.com Mon Sep 3 17:37:34 2007 From: rhwood at mac.com (Randall Wood) Date: Tue Oct 9 16:40:36 2007 Subject: Missing tickets Message-ID: <1EA15710-5C92-4696-B839-B5630095F032@mac.com> I recently had a ticket that I was not being listed in Trac, #11903. Changing its priority from "Expected" to "Normal" solved the problem. I wonder how many other tickets have invalid priorities since the change in Trac priority values? 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 jmpp at macports.org Mon Sep 3 18:31:54 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:36 2007 Subject: Missing tickets In-Reply-To: <1EA15710-5C92-4696-B839-B5630095F032@mac.com> References: <1EA15710-5C92-4696-B839-B5630095F032@mac.com> Message-ID: <4C544AA5-72E7-4058-90DF-06E196C26BAA@macports.org> On Sep 3, 2007, at 8:37 PM, Randall Wood wrote: > I recently had a ticket that I was not being listed in Trac, > #11903. Changing its priority from "Expected" to "Normal" solved > the problem. I wonder how many other tickets have invalid > priorities since the change in Trac priority values? Unfortunately many of them were affected by the changes, namely all those that had the values that were removed/renamed [1]. For the purpose of fixing that side effect I created the "infrastructure request" ticket #12603, which contains proposed SQL statements [2] that when injected directly into the trac db should correct the situation. -jmpp [1] Thanks to Anthony Ramine (N_Ox) for manually fixing many of the affected tickets! [2] Thanks to Chris Pickel (sfiera) for figuring out the needed SQL statements to bring the db up to date. From vincent-opdarw at vinc17.org Mon Sep 3 18:53:32 2007 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Tue Oct 9 16:40:36 2007 Subject: Newbie Port Creator Questions In-Reply-To: <46DC8CD7.8010808@macports.org> References: <05BCB0A2-E3E0-4F89-85B0-9B30E98B7094@macports.org> <6FFAC741-233A-4425-BE2B-EFEB7CBD4197@vexate.net> <71EC8A7B-E320-413C-9934-B5C3BBEF669A@macports.org> <20070903135950.GS27290@prunille.vinc17.org> <46DC8CD7.8010808@macports.org> Message-ID: <20070904015332.GO27290@prunille.vinc17.org> On 2007-09-04 00:38:15 +0200, Rainer M?ller wrote: > GPLv2 is not necessarily incompatible with GPLv3. It is. > GPL lets the original author choose how new versions apply to the > software. See paragraph 9 of the GPLv2 [1]. > > --snip-- > | Each version is given a distinguishing version number. If the Program > | specifies a version number of this License which applies to it and "any > | later version", you have the option of following the terms and conditions > | either of that version or of any later version published by the Free > | Software Foundation. > --snap-- If you choose "or any later version", this is no longer GPLv2 (which means GPL version 2 only), but GPLv2+ (with the more-or-less official notation). -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From ryandesign at macports.org Mon Sep 3 23:18:28 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:36 2007 Subject: Problem with the repository: bogus date In-Reply-To: <46DC9DFD.7020509@macports.org> References: <20070903232200.GL27290@prunille.vinc17.org> <46DC9DFD.7020509@macports.org> Message-ID: <626A2EFC-B2F0-4BEE-BF6C-DAD36839F94A@macports.org> On Sep 3, 2007, at 18:51, Rainer M?ller wrote: > Vincent Lefevre wrote: > >> I've noticed the following error: >> >> $ svn log -r2 https://svn.macosforge.org/repository/macports >> svn: Bogus date > > It is really a "Bogus date", as you can see in the following log: > > --snip-- > | $ svn log --xml -r2 https://svn.macosforge.org/repository/macports > | > | > | | revision="2"> > | landonf > | http://svn.seven:8080/code > | Initial revision > | > | > | > --snap-- Very sorry! That was my fault. I've now fixed the svn:date property of revision 2 so the log should work again. The timestamp of revision 1 and revision 3 are identical, so I set revision 2 to that same timestamp. (I issued a bad "svn propset" command the other day. I was meaning to chan