From mfwitten at MIT.EDU Tue Jan 1 00:42:31 2008 From: mfwitten at MIT.EDU (Michael Witten) Date: Tue Jan 1 00:40:49 2008 Subject: Version Update Patch: iverilog Message-ID: <79579DA2-0987-418B-A6FB-BEC8B4B9B304@mit.edu> Hello, The included patch updates the iverilog version from 0.8.2. to 0.8.6. Just apply as follows: # cd /opt/local/var/macports/sources/rsync.macports.org/release/ports/ science/iverilog # patch -p0 < path/to/Portfile-iverilog.diff I've sent the patch into the mailing list rather than using the Trac system, because this portfile is unmaintained, and because it feels like any submission to Trac would get lost. Also, I did not paste the diff directly into this email, because some clients automatically remove lines with only whitespace. Sincerely, Michael Witten -------------- next part -------------- A non-text attachment was scrubbed... Name: Portfile-iverilog.diff Type: application/octet-stream Size: 625 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080101/2866afea/Portfile-iverilog.obj -------------- next part -------------- From ryandesign at macports.org Tue Jan 1 12:56:03 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Jan 1 12:54:36 2008 Subject: [32441] trunk/base/src/port1.0/portchecksum.tcl In-Reply-To: <20080101170923.641766F48EE@beta.macosforge.org> References: <20080101170923.641766F48EE@beta.macosforge.org> Message-ID: <9759A444-AB42-493F-B4CB-E8CC4C7B0790@macports.org> On Jan 1, 2008, at 11:09, jberry@macports.org wrote: > Revision: 32441 > http://trac.macosforge.org/projects/macports/changeset/32441 > Author: jberry@macports.org > Date: 2008-01-01 09:09:21 -0800 (Tue, 01 Jan 2008) > > Log Message: > ----------- > If checksum is mismatched, and in verbose mode, present a corrected > pre-fabricated > checksum statement to make it easy to update a port. That does, of course, make it easier for people to just blindly copy and paste, rather than thinking about whether they should be changing the portfile checksum at all. http://trac.macosforge.org/projects/macports/wiki/ FAQ#IgetError:checksummd5sha1rmd160mismatchforport.WhatcanIdoaboutit From ryandesign at macports.org Tue Jan 1 12:53:21 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Jan 1 12:58:35 2008 Subject: Version Update Patch: iverilog In-Reply-To: <79579DA2-0987-418B-A6FB-BEC8B4B9B304@mit.edu> References: <79579DA2-0987-418B-A6FB-BEC8B4B9B304@mit.edu> Message-ID: <397B4EC8-BE9C-4176-8EE6-0C87D0F26EA5@macports.org> On Jan 1, 2008, at 02:42, Michael Witten wrote: > The included patch updates the iverilog version > from 0.8.2. to 0.8.6. > > Just apply as follows: > > # cd /opt/local/var/macports/sources/rsync.macports.org/release/ > ports/science/iverilog > # patch -p0 < path/to/Portfile-iverilog.diff > > > I've sent the patch into the mailing list rather > than using the Trac system, because this portfile > is unmaintained, and because it feels like any > submission to Trac would get lost. > > Also, I did not paste the diff directly into this > email, because some clients automatically remove > lines with only whitespace. Thanks for the update! I committed it in r32442. But it would be appropriate to file a ticket in Trac in the future. Email about new tickets is now sent to the macports-tickets list, so anyone subscribed to that list will be informed about the new ticket. If your ticket is not dealt with in a timely manner, you can always send a message to this list with the ticket number. From mfwitten at MIT.EDU Tue Jan 1 13:46:23 2008 From: mfwitten at MIT.EDU (Michael Witten) Date: Tue Jan 1 13:45:18 2008 Subject: Version Update Patch: iverilog In-Reply-To: <397B4EC8-BE9C-4176-8EE6-0C87D0F26EA5@macports.org> References: <79579DA2-0987-418B-A6FB-BEC8B4B9B304@mit.edu> <397B4EC8-BE9C-4176-8EE6-0C87D0F26EA5@macports.org> Message-ID: <5BF37EC2-DB80-4370-A6B1-D6BAA7C8F69F@MIT.EDU> On 1 Jan 2008, at 3:53 PM, Ryan Schmidt wrote: > On Jan 1, 2008, at 02:42, Michael Witten wrote: > >> The included patch updates the iverilog version >> from 0.8.2. to 0.8.6. >> ... > > Thanks for the update! I committed it in r32442. But it would be > appropriate to file a ticket in Trac in the future. Email about new > tickets is now sent to the macports-tickets list, so anyone > subscribed to that list will be informed about the new ticket. If > your ticket is not dealt with in a timely manner, you can always > send a message to this list with the ticket number. Sounds great. Thanks for the advice. From jberry at macports.org Tue Jan 1 14:00:07 2008 From: jberry at macports.org (James Berry) Date: Tue Jan 1 13:58:28 2008 Subject: [32441] trunk/base/src/port1.0/portchecksum.tcl In-Reply-To: <9759A444-AB42-493F-B4CB-E8CC4C7B0790@macports.org> References: <20080101170923.641766F48EE@beta.macosforge.org> <9759A444-AB42-493F-B4CB-E8CC4C7B0790@macports.org> Message-ID: Hi Ryan, On Jan 1, 2008, at 12:56 PM, Ryan Schmidt wrote: > On Jan 1, 2008, at 11:09, jberry@macports.org wrote: > >> Revision: 32441 >> http://trac.macosforge.org/projects/macports/changeset/32441 >> Author: jberry@macports.org >> Date: 2008-01-01 09:09:21 -0800 (Tue, 01 Jan 2008) >> >> Log Message: >> ----------- >> If checksum is mismatched, and in verbose mode, present a corrected >> pre-fabricated >> checksum statement to make it easy to update a port. > > That does, of course, make it easier for people to just blindly copy > and paste, rather than thinking about whether they should be > changing the portfile checksum at all. Yes, I did consider this argument for why it might not be a good idea, but quickly came to the conclusion that taking away the drudge work will hopefully give people _more_ time to consider some of those other factors. I don't believe that this is a case where we're putting a hair-trigger on a gun, or something; we're making the fife of a maintainer easier. I don't think this will make it more or less likely that someone will ignore the root cause behind a bad checksum. Besides, I think 99% of the time spent in updating checksums is for updated versions, rather than files which miraculously change in the night. Once again, hopefully this will make it more likely that maintainers will consider verifying the checksum against a signed version from the distro. James > > > http://trac.macosforge.org/projects/macports/wiki/ > FAQ#IgetError:checksummd5sha1rmd160mismatchforport.WhatcanIdoaboutit > > From cssdev at mac.com Wed Jan 2 09:23:25 2008 From: cssdev at mac.com (cssdev@mac.com) Date: Wed Jan 2 09:21:34 2008 Subject: doxygen vs libiconv oddity Message-ID: <33B0899B-A6B4-4B52-B3FB-2CC0D318C2F0@mac.com> Hi all, I'm having a heck of a time with what should be a simple bug. http://trac.macosforge.org/projects/macports/ticket/13156 Several people have reported the same problem, but I cannot replicate it on my MacBook Pro running Mac OS X 10.4.11. I have tested both with and without the libiconv port installed, and it looks like my libiconv simply doesn't match the results that others are seeing. What could make the libiconv port yield different function signatures? My iconv.h installed for libiconv @1.12_0+darwin_8 works fine, but it looks like others are getting different headers without the const parameter. I tried reinstalling the developer tools as well as XCode, but the port as is builds fine on my machine. I don't have a /usr/local. I could use some help trying to identify why the libiconv port is behaving differently. Thanks, Chris From kvv at apple.com Wed Jan 2 10:40:51 2008 From: kvv at apple.com (Kevin Van Vechten) Date: Wed Jan 2 10:40:27 2008 Subject: macforge.org via https? In-Reply-To: <1CB1E1C7-62B5-47E8-A102-998D60B63531@macports.org> References: <659D2647-8FF5-4301-BF36-422BF19B262A@macports.org> <1CB1E1C7-62B5-47E8-A102-998D60B63531@macports.org> Message-ID: <0ACF32F7-B24D-47C0-928B-54B3158EC5E0@apple.com> On Dec 31, 2007, at 3:26 PM, Landon Fuller wrote: > But HTTP digest doesn't solve any of the problems that SSL solves: > - It is still vulnerable to a MITM attack. Your password is hashed, > but the hash is password-equivalent -- an attacker can simply > forward it on. Not really... the server sends a random nonce-value, and the client must include that in the hashed-response. Replay is not an issue. response = MD5(MD5(username : realm : password), nonce, MD5(method : uri)) http://rfc.net/rfc2069.html > - Digest authentication is indistinguishable from Basic > authentication -- your browser will display the same dialog > regardless of the authentication type. Safari distinguishes them; Basic authentication dialogs say the password will be sent in the clear. > At best, it will prevent a passive attacker from acquiring your > password. Anyone engaging in an active MITM attack will have no > difficultly acquiring your password. I agree SSL provides additional security benefits, but digest authentication isn't as transparent as you indicate. - Kevin From ryandesign at macports.org Wed Jan 2 11:51:56 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Jan 2 11:57:15 2008 Subject: [32446] trunk/dports/sysutils/rpm-devel/Portfile In-Reply-To: <20080102093243.A64DA70A575@beta.macosforge.org> References: <20080102093243.A64DA70A575@beta.macosforge.org> Message-ID: Perhaps the port revision should also be incremented so that anyone who had beta 3 installed will be informed of the availability of this new beta 4? On Jan 2, 2008, at 03:32, afb@macports.org wrote: > Revision: 32446 > http://trac.macosforge.org/projects/macports/changeset/32446 > Author: afb@macports.org > Date: 2008-01-02 01:32:42 -0800 (Wed, 02 Jan 2008) > > Log Message: > ----------- > port upgrade: final rpm-5.0 beta > > Modified Paths: > -------------- > trunk/dports/sysutils/rpm-devel/Portfile > > Modified: trunk/dports/sysutils/rpm-devel/Portfile > =================================================================== > --- trunk/dports/sysutils/rpm-devel/Portfile 2008-01-02 09:15:58 > UTC (rev 32445) > +++ trunk/dports/sysutils/rpm-devel/Portfile 2008-01-02 09:32:42 > UTC (rev 32446) > @@ -16,10 +16,10 @@ > > homepage http://rpm5.org > master_sites ${homepage}/files/rpm/rpm-5.0 > -distname rpm-${version}b3 > -#distdate 20071222 > -checksums md5 444c0ea3399382535f43475d3c934e7a > -worksrcdir rpm-${version}b3 > +distname rpm-${version}b4 > +#distdate 20071231 > +checksums md5 89e5d27874724ac01f6ac229e2fa8a22 > +worksrcdir rpm-${version}b4 > # > ### CVS source > #fetch.type cvs From landonf at macports.org Wed Jan 2 12:37:35 2008 From: landonf at macports.org (Landon Fuller) Date: Wed Jan 2 12:35:49 2008 Subject: macforge.org via https? In-Reply-To: <0ACF32F7-B24D-47C0-928B-54B3158EC5E0@apple.com> References: <659D2647-8FF5-4301-BF36-422BF19B262A@macports.org> <1CB1E1C7-62B5-47E8-A102-998D60B63531@macports.org> <0ACF32F7-B24D-47C0-928B-54B3158EC5E0@apple.com> Message-ID: <1AFE5F87-1B7B-4EAB-BFA7-517DAD206DCC@macports.org> On Jan 2, 2008, at 10:40, Kevin Van Vechten wrote: > > On Dec 31, 2007, at 3:26 PM, Landon Fuller wrote: > >> But HTTP digest doesn't solve any of the problems that SSL solves: >> - It is still vulnerable to a MITM attack. Your password is >> hashed, but the hash is password-equivalent -- an attacker can >> simply forward it on. > > Not really... the server sends a random nonce-value, and the client > must include that in the hashed-response. Replay is not an issue. > > response = MD5(MD5(username : realm : password), nonce, MD5 > (method : uri)) > > http://rfc.net/rfc2069.html Replay isn't an issue, but that doesn't stop a MITM attack -- the password-equivalent value is usable once. Attack scenario: Client requests a page that requires authentication. MITM returns 301 redirect to the client. The redirect points to a URL the MITM wishes to access. Client automatically follows redirect. MITM passes the 401 Unauthorized response through, client authenticates using HTTP digest. MITM has now successfully directed the client to a resource of its choice, and acquired a single-use token. Can even be used to form POST, via a crafted HTML page. Nil chance of this happening at your home or internet cafe, but what about a targeted attack at a technical conference? Given the wide use and distribution of MacPorts, there is significant value in acquiring project access. >> - Digest authentication is indistinguishable from Basic >> authentication -- your browser will display the same dialog >> regardless of the authentication type. > > Safari distinguishes them; Basic authentication dialogs say the > password will be sent in the clear. Currently, trying to access http://www.macosforge.org/wp-login.php in Safari says the following: "Your password will be sent in the clear." I don't have digest auth set up anywhere, so I can't test digest vs. non-digest in Safari. Firefox doesn't show any difference in the auth dialog -- I'd easily login using the basic auth. Also, does Safari refuse to auto-login if the authentication type changes? >> At best, it will prevent a passive attacker from acquiring your >> password. Anyone engaging in an active MITM attack will have no >> difficultly acquiring your password. > > > I agree SSL provides additional security benefits, but digest > authentication isn't as transparent as you indicate. I still hold that it is -- digest auth makes passive sniffing useless, but it doesn't prevent an active attack from acquiring your password, especially if you're using a browser that fails to differentiate between digest and basic auth. -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/20080102/36c45118/PGP.bin From randall.h.wood at alexandriasoftware.com Wed Jan 2 12:44:10 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Wed Jan 2 12:44:21 2008 Subject: [32441] trunk/base/src/port1.0/portchecksum.tcl In-Reply-To: References: <20080101170923.641766F48EE@beta.macosforge.org> <9759A444-AB42-493F-B4CB-E8CC4C7B0790@macports.org> Message-ID: <6E6B01CF-A89B-42B4-A1B5-F1B891649FE2@alexandriasoftware.com> On 1 Jan 2008, at 17:00, James Berry wrote: > Hi Ryan, > > On Jan 1, 2008, at 12:56 PM, Ryan Schmidt wrote: > >> On Jan 1, 2008, at 11:09, jberry@macports.org wrote: >> >>> Revision: 32441 >>> http://trac.macosforge.org/projects/macports/changeset/ >>> 32441 >>> Author: jberry@macports.org >>> Date: 2008-01-01 09:09:21 -0800 (Tue, 01 Jan 2008) >>> >>> Log Message: >>> ----------- >>> If checksum is mismatched, and in verbose mode, present a >>> corrected pre-fabricated >>> checksum statement to make it easy to update a port. >> >> That does, of course, make it easier for people to just blindly >> copy and paste, rather than thinking about whether they should be >> changing the portfile checksum at all. > > Yes, I did consider this argument for why it might not be a good > idea, but quickly came to the conclusion that taking away the > drudge work will hopefully give people _more_ time to consider some > of those other factors. I don't believe that this is a case where > we're putting a hair-trigger on a gun, or something; we're making > the fife of a maintainer easier. I don't think this will make it > more or less likely that someone will ignore the root cause behind > a bad checksum. > > Besides, I think 99% of the time spent in updating checksums is for > updated versions, rather than files which miraculously change in > the night. Once again, hopefully this will make it more likely that > maintainers will consider verifying the checksum against a signed > version from the distro. You already get this in debug mode (-d) anyway (or is it debug and verbose mode (-dv)?). Randall Wood randall.h.wood@alexandriasoftware.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 kvv at apple.com Wed Jan 2 12:45:53 2008 From: kvv at apple.com (Kevin Van Vechten) Date: Wed Jan 2 12:44:59 2008 Subject: macforge.org via https? In-Reply-To: <1AFE5F87-1B7B-4EAB-BFA7-517DAD206DCC@macports.org> References: <659D2647-8FF5-4301-BF36-422BF19B262A@macports.org> <1CB1E1C7-62B5-47E8-A102-998D60B63531@macports.org> <0ACF32F7-B24D-47C0-928B-54B3158EC5E0@apple.com> <1AFE5F87-1B7B-4EAB-BFA7-517DAD206DCC@macports.org> Message-ID: <1E00E927-8C5E-4B83-86A1-3A1BD3120A7A@apple.com> On Jan 2, 2008, at 12:37 PM, Landon Fuller wrote: >>> - Digest authentication is indistinguishable from Basic >>> authentication -- your browser will display the same dialog >>> regardless of the authentication type. >> >> Safari distinguishes them; Basic authentication dialogs say the >> password will be sent in the clear. > > Currently, trying to access http://www.macosforge.org/wp-login.php > in Safari says the following: > "Your password will be sent in the clear." Oh right, ironically Safari has a bug in that message is displayed even for digest authentication (it is not intended to be). > Firefox doesn't show any difference in the auth dialog -- I'd easily > login using the basic auth. Also, does Safari refuse to auto-login > if the authentication type changes? Unknown. The RFC suggests that it should. =) >>> At best, it will prevent a passive attacker from acquiring your >>> password. Anyone engaging in an active MITM attack will have no >>> difficultly acquiring your password. >> >> I agree SSL provides additional security benefits, but digest >> authentication isn't as transparent as you indicate. > > I still hold that it is -- digest auth makes passive sniffing > useless, but it doesn't prevent an active attack from acquiring your > password, especially if you're using a browser that fails to > differentiate between digest and basic auth. We're probably talking past each other, and I'm probably splitting hairs. I disagree that the MITM can "acquire your password" but I agree that a MITM could "masquerade as you." - Kevin From kvv at apple.com Wed Jan 2 12:47:13 2008 From: kvv at apple.com (Kevin Van Vechten) Date: Wed Jan 2 12:46:48 2008 Subject: macforge.org via https? In-Reply-To: <1E00E927-8C5E-4B83-86A1-3A1BD3120A7A@apple.com> References: <659D2647-8FF5-4301-BF36-422BF19B262A@macports.org> <1CB1E1C7-62B5-47E8-A102-998D60B63531@macports.org> <0ACF32F7-B24D-47C0-928B-54B3158EC5E0@apple.com> <1AFE5F87-1B7B-4EAB-BFA7-517DAD206DCC@macports.org> <1E00E927-8C5E-4B83-86A1-3A1BD3120A7A@apple.com> Message-ID: <7A21951C-7EEF-41F0-AFF4-235223CFBDBA@apple.com> On Jan 2, 2008, at 12:45 PM, Kevin Van Vechten wrote: > We're probably talking past each other, and I'm probably splitting > hairs. I disagree that the MITM can "acquire your password" but I > agree that a MITM could "masquerade as you." Well from a protocol perspective anyway; I guess we've established no clients are well-behaved. sigh. - Kevin From guido.soranzio at gmail.com Wed Jan 2 13:18:44 2008 From: guido.soranzio at gmail.com (Guido Soranzio) Date: Wed Jan 2 13:16:53 2008 Subject: Workaround for PyGTK missing symbols under Leopard Message-ID: I tried to compile the latest Deluge (a BitTorrent client) and XPN (an experimental Python newsreader) after applying a workaround to py25-gobject, py25-cairo, py25-gtk and dbus-python25, all of which were reporting missing symbols under Leopard: the patches simply exclude the option "-export-symbols-regex" from the Makefile.am and Makefile.in files, as suggested successfully by several reports. Unfortunately all these fine ports are currently unmaintained, so I am reporting here the corresponding Trac submissions: http://trac.macosforge.org/projects/macports/ticket/13781 http://trac.macosforge.org/projects/macports/ticket/13763 http://trac.macosforge.org/projects/macports/ticket/13782 http://trac.macosforge.org/projects/macports/ticket/13792 http://trac.macosforge.org/projects/macports/ticket/13791 http://trac.macosforge.org/projects/macports/ticket/13784 Regards, Guido From afb at macports.org Wed Jan 2 15:25:49 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Wed Jan 2 15:23:57 2008 Subject: [32446] trunk/dports/sysutils/rpm-devel/Portfile In-Reply-To: References: <20080102093243.A64DA70A575@beta.macosforge.org> Message-ID: Ryan Schmidt wrote: > Perhaps the port revision should also be incremented so that anyone > who had beta 3 installed will be informed of the availability of this > new beta 4? Perhaps, but these -devel ports usally build from tip of trunk so they all had revision "0"... --anders From ryandesign at macports.org Wed Jan 2 16:02:22 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Jan 2 16:27:32 2008 Subject: [32446] trunk/dports/sysutils/rpm-devel/Portfile In-Reply-To: References: <20080102093243.A64DA70A575@beta.macosforge.org> Message-ID: <282B5917-4B79-42F9-A974-EC77E07515D4@macports.org> On Jan 2, 2008, at 17:25, Anders F Bj?rklund wrote: > Ryan Schmidt wrote: > >> Perhaps the port revision should also be incremented so that >> anyone who had beta 3 installed will be informed of the >> availability of this new beta 4? > > Perhaps, but these -devel ports usally build from tip of trunk so > they all had revision "0"... Ports should never build from tip of trunk or HEAD or similar concepts..... From afb at macports.org Thu Jan 3 03:11:01 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu Jan 3 03:09:05 2008 Subject: [32446] trunk/dports/sysutils/rpm-devel/Portfile In-Reply-To: <282B5917-4B79-42F9-A974-EC77E07515D4@macports.org> References: <20080102093243.A64DA70A575@beta.macosforge.org> <282B5917-4B79-42F9-A974-EC77E07515D4@macports.org> Message-ID: Ryan Schmidt wrote: >> Perhaps, but these -devel ports usally build from tip of trunk so >> they all had revision "0"... > > Ports should never build from tip of trunk or HEAD or similar > concepts..... These do. Not sure what the alternative would be, should I set up a cron job to commit a Portfile daily ? --anders From ryandesign at macports.org Thu Jan 3 05:54:07 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Jan 3 05:52:42 2008 Subject: [32470] trunk/dports/python/py25-gtk/Portfile In-Reply-To: <20080103120324.4B3257395B4@beta.macosforge.org> References: <20080103120324.4B3257395B4@beta.macosforge.org> Message-ID: <9D3678E3-5E94-49FB-97E5-EA7216EB7102@macports.org> On Jan 3, 2008, at 06:03, afb@macports.org wrote: > +platform darwin 9 { > + post-patch { > + reinplace "s| -export-symbols-regex.*||g" ${worksrcpath}/ > Makefile.am > + reinplace "s| -export-symbols-regex.*||g" ${worksrcpath}/ > Makefile.in > + reinplace "s| -export-symbols-regex.*||g" ${worksrcpath}/ > gtk/Makefile.am > + reinplace "s| -export-symbols-regex.*||g" ${worksrcpath}/ > gtk/Makefile.in > + } > +} reinplace does accept multiple files to patch, so you could just do: reinplace "s| -export-symbols-regex.*||g" ${worksrcpath}/Makefile.am \ ${worksrcpath}/Makefile.in \ ${worksrcpath}/gtk/Makefile.am \ ${worksrcpath}/gtk/Makefile.in > From nabble at jcharum.fastmail.net Thu Jan 3 16:48:10 2008 From: nabble at jcharum.fastmail.net (jcharum) Date: Thu Jan 3 16:46:09 2008 Subject: 'port build' different than 'make all' Message-ID: <14608835.post@talk.nabble.com> I have altered the GHC Portfile to have no build section (and no pre-build or post-build sections) and to set (amongst other things): build.cmd make build.type gnu build.args "" build.target all (1) $ sudo port configure $ cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.6.1 $ sudo make all (2) $ sudo port configure $ sudo port build I think that running (1) and (2) should be equivalent. However, when I do this, I do not get the same object files. Namely, when I install with (1), my GHC works (at least for trivial examples). When I install with (2), I get weird errors (that I can describe further if requested). I have built GHC about 25 times (at ~4 hours/build) to narrow it down to this. Can someone shed some light on why there is any difference? I think it must be somewhere in my environment, but I can't figure out what - I have at least set the PATHs to be the same. I am new to Portfile development and was interested in helping to get a good build for GHC 6.6.1 on Leopard. If any more information is needed, I will happily provide it. Thanks in advance for any help at all. -- View this message in context: http://www.nabble.com/%27port-build%27-different-than-%27make-all%27-tp14608835p14608835.html Sent from the MacPorts - Developer mailing list archive at Nabble.com. From ryandesign at macports.org Thu Jan 3 18:33:05 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Jan 3 18:31:34 2008 Subject: 'port build' different than 'make all' In-Reply-To: <14608835.post@talk.nabble.com> References: <14608835.post@talk.nabble.com> Message-ID: <167D33CF-934F-461B-B1C2-BA2028CFA042@macports.org> On Jan 3, 2008, at 18:48, jcharum wrote: > I have altered the GHC Portfile to have no build section (and no > pre-build or > post-build sections) and to set (amongst other things): > > build.cmd make > build.type gnu > build.args "" > build.target all > > (1) > $ sudo port configure > $ cd > /opt/local/var/macports/build/ > _opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ > ghc/work/ghc-6.6.1 > $ sudo make all > > (2) > $ sudo port configure > $ sudo port build > > > I think that running (1) and (2) should be equivalent. However, > when I do > this, I do not get the same object files. Namely, when I install > with (1), > my GHC works (at least for trivial examples). When I install with > (2), I > get weird errors (that I can describe further if requested). I > have built > GHC about 25 times (at ~4 hours/build) to narrow it down to this. Can > someone shed some light on why there is any difference? I think it > must be > somewhere in my environment, but I can't figure out what - I have > at least > set the PATHs to be the same. I am new to Portfile development and > was > interested in helping to get a good build for GHC 6.6.1 on Leopard. > > If any more information is needed, I will happily provide it. > Thanks in > advance for any help at all. I am not really familiar with ghc, but I can tell you that MacPorts builds in a modified environment. Any PATH you have set in your terminal, for example, is ignored, and MacPorts uses its own PATH. A slew of other environment variables are also set by MacPorts. I can't name them all off the top of my head but you can peek through the sources in src/port1.0 such as portconfigure.tcl and portbuild.tcl. From nabble at jcharum.fastmail.net Thu Jan 3 18:59:35 2008 From: nabble at jcharum.fastmail.net (jcharum) Date: Thu Jan 3 18:57:34 2008 Subject: 'port build' different than 'make all' In-Reply-To: <167D33CF-934F-461B-B1C2-BA2028CFA042@macports.org> References: <14608835.post@talk.nabble.com> <167D33CF-934F-461B-B1C2-BA2028CFA042@macports.org> Message-ID: <14610016.post@talk.nabble.com> Ryan Schmidt-24 wrote: > > I am not really familiar with ghc, but I can tell you that MacPorts > builds in a modified environment. Any PATH you have set in your > terminal, for example, is ignored, and MacPorts uses its own PATH. A > slew of other environment variables are also set by MacPorts. I can't > name them all off the top of my head but you can peek through the > sources in src/port1.0 such as portconfigure.tcl and portbuild.tcl. > I see. I actually built with the PATH that the configure script reports during the MacPorts configure phase, so I think I got that part right unless the PATH is different for the build phase(!). Thanks for the pointer to the sources to see the rest of the environment. I will investigate to see if I can reproduce the MacPorts build output. -- View this message in context: http://www.nabble.com/%27port-build%27-different-than-%27make-all%27-tp14608835p14610016.html Sent from the MacPorts - Developer mailing list archive at Nabble.com. From mww at macports.org Fri Jan 4 03:17:35 2008 From: mww at macports.org (Markus Weissmann) Date: Fri Jan 4 03:15:35 2008 Subject: 'port build' different than 'make all' In-Reply-To: <14610016.post@talk.nabble.com> References: <14608835.post@talk.nabble.com> <167D33CF-934F-461B-B1C2-BA2028CFA042@macports.org> <14610016.post@talk.nabble.com> Message-ID: <89A15F24-73DC-4E2C-B704-EF330D2A55C5@macports.org> On 4 Jan 2008, at 03:59, jcharum wrote: > Ryan Schmidt-24 wrote: >> >> I am not really familiar with ghc, but I can tell you that MacPorts >> builds in a modified environment. Any PATH you have set in your >> terminal, for example, is ignored, and MacPorts uses its own PATH. A >> slew of other environment variables are also set by MacPorts. I can't >> name them all off the top of my head but you can peek through the >> sources in src/port1.0 such as portconfigure.tcl and portbuild.tcl. >> > > I see. I actually built with the PATH that the configure script > reports > during the MacPorts configure phase, so I think I got that part > right unless > the PATH is different for the build phase(!). Thanks for the > pointer to the > sources to see the rest of the environment. I will investigate to > see if I > can reproduce the MacPorts build output. if you have a version of port < 1.6 installed: We removed two environment variables that caused build troubles on 10.5 (originally for prebinding). Regards, -Markus -- Dipl. Inf. (FH) Markus W. Weissmann http://www.macports.org/ http://www.mweissmann.de/ From ryandesign at macports.org Sat Jan 5 00:08:51 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat Jan 5 00:07:18 2008 Subject: [32500] trunk/base/src/port1.0/portutil.tcl In-Reply-To: <20080105080557.99F47790EEF@beta.macosforge.org> References: <20080105080557.99F47790EEF@beta.macosforge.org> Message-ID: <03E7D6E0-641E-4342-8118-656AB8A54CF1@macports.org> On Jan 5, 2008, at 02:05, ryandesign@macports.org wrote: > - foreach arch {"i386" "x86_64" "ppc" "pp64"} { > + foreach arch {"i386" "x86_64" "ppc" "ppc64"} { Can we replace this hardcoded list of architectures with the $ {universal_archs} variable? From ryandesign at macports.org Sat Jan 5 13:42:27 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat Jan 5 13:40:51 2008 Subject: [32446] trunk/dports/sysutils/rpm-devel/Portfile In-Reply-To: References: <20080102093243.A64DA70A575@beta.macosforge.org> <282B5917-4B79-42F9-A974-EC77E07515D4@macports.org> Message-ID: <3A097D40-7293-40DE-9E5B-85C61B7E4E60@macports.org> On Jan 3, 2008, at 05:11, Anders F Bj?rklund wrote: > Ryan Schmidt wrote: > >>> Perhaps, but these -devel ports usally build from tip of trunk so >>> they all had revision "0"... >> >> Ports should never build from tip of trunk or HEAD or similar >> concepts..... > > These do. But that's not reproducible, and I thought we always wanted that. If I install a specific version of a port today, I should get the same software if I install that same version of that port tomorrow. By fetching from HEAD, you break that assumption. > Not sure what the alternative would be, should I set up a cron job > to commit a Portfile daily ? I see for example that Markus commits a new version of gcc43 every week or so. I hope he tests it before committing, however. From afb at macports.org Sat Jan 5 13:50:49 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sat Jan 5 13:48:54 2008 Subject: [32446] trunk/dports/sysutils/rpm-devel/Portfile In-Reply-To: <3A097D40-7293-40DE-9E5B-85C61B7E4E60@macports.org> References: <20080102093243.A64DA70A575@beta.macosforge.org> <282B5917-4B79-42F9-A974-EC77E07515D4@macports.org> <3A097D40-7293-40DE-9E5B-85C61B7E4E60@macports.org> Message-ID: <610377e105edb0d5914d242e0b10e4ed@macports.org> Ryan Schmidt wrote: >>>> Perhaps, but these -devel ports usally build from tip of trunk so >>>> they all had revision "0"... >>> >>> Ports should never build from tip of trunk or HEAD or similar >>> concepts..... >> >> These do. > > But that's not reproducible, and I thought we always wanted that. If I > install a specific version of a port today, I should get the same > software if I install that same version of that port tomorrow. By > fetching from HEAD, you break that assumption. I understand what you are saying. I've only done it on some "-devel" ports, not on any release ports. >> Not sure what the alternative would be, should I set up a cron job to >> commit a Portfile daily ? > > I see for example that Markus commits a new version of gcc43 every > week or so. I hope he tests it before committing, however. I will probably move to snapshot versions instead, revision them by date or something like that... --anders From takeshi at mac.com Sat Jan 5 15:23:52 2008 From: takeshi at mac.com (Takeshi Enomoto) Date: Sat Jan 5 15:21:45 2008 Subject: libiconv Message-ID: <10C44B4C-BB17-4F60-842E-D85112606C7F@mac.com> Hello Ryan, I have received an error report on g95. It is related to MacPorts' libiconv. MacPorts' libiconv does not have symbols iconv_*. There are libiconv_* instead. System's libiconv have both. A quick google search tells me that it is a cause of build failure of a few other packages. Could you tell me if 1) iconv_* are deprecated and I should rewrite them to libiconv_*, 2) system's libiconv should be used, or 3) I should wait an update of libiconv package? Regards, Takeshi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080106/a1e18901/attachment.html From ryandesign at macports.org Sat Jan 5 15:26:31 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat Jan 5 15:24:56 2008 Subject: libiconv In-Reply-To: <10C44B4C-BB17-4F60-842E-D85112606C7F@mac.com> References: <10C44B4C-BB17-4F60-842E-D85112606C7F@mac.com> Message-ID: On Jan 5, 2008, at 17:23, Takeshi Enomoto wrote: > I have received an error report on g95. > > > It is related to MacPorts' libiconv. > MacPorts' libiconv does not have symbols iconv_*. > There are libiconv_* instead. > > System's libiconv have both. > > A quick google search tells me that it is a cause of > build failure of a few other packages. I do recall seeing this error reported before. > Could you tell me if > 1) iconv_* are deprecated and I should rewrite them to libiconv_*, > 2) system's libiconv should be used, or > 3) I should wait an update of libiconv package? I don't know the answer to any of those questions. Well, except for question 2, where I think the answer is "no" because of the reasons stated in the MacPorts FAQ (reasons for why MacPorts uses its own libraries and not the system libraries). I can ask the developers of iconv why those functions are not present. From peter at pogma.com Sat Jan 5 15:43:12 2008 From: peter at pogma.com (Peter O'Gorman) Date: Sat Jan 5 15:41:05 2008 Subject: libiconv In-Reply-To: References: <10C44B4C-BB17-4F60-842E-D85112606C7F@mac.com> Message-ID: <47801610.6080508@pogma.com> Ryan Schmidt wrote: > On Jan 5, 2008, at 17:23, Takeshi Enomoto wrote: > >> I have received an error report on g95. >> >> >> It is related to MacPorts' libiconv. >> MacPorts' libiconv does not have symbols iconv_*. >> There are libiconv_* instead. >> >> System's libiconv have both. >> >> A quick google search tells me that it is a cause of >> build failure of a few other packages. > > I do recall seeing this error reported before. > >> Could you tell me if >> 1) iconv_* are deprecated and I should rewrite them to libiconv_*, >> 2) system's libiconv should be used, or >> 3) I should wait an update of libiconv package? > > I don't know the answer to any of those questions. Well, except for > question 2, where I think the answer is "no" because of the reasons > stated in the MacPorts FAQ (reasons for why MacPorts uses its own > libraries and not the system libraries). I can ask the developers of > iconv why those functions are not present. Problem is related to a port finding the systems iconv.h but using the macports libiconv. Exapmle: /usr/bin/gcc-4.0 -O2 -DIN_GCC -Wall -Wmissing-prototypes -no-cpp-precomp -c version.c Does not have -I/opt/local/include but /usr/bin/gcc-4.0 -O2 -DIN_GCC -Wall -Wmissing-prototypes -no-cpp-precomp -L/opt/local/lib -o g95 g95-g95spec.o /opt/local/var/macports/build/_Users_ram_opt_macports_lang_g95/work/gcc-4.0.3/g95/gcc/prefix.o gcc.o version.o /opt/local/var/macports/build/_Users_ram_opt_macports_lang_g95/work/gcc-4.0.3/g95/gcc/intl.o /opt/local/var/macports/build/_Users_ram_opt_macports_lang_g95/work/gcc-4.0.3/g95/libiberty/libiberty.a /opt/local/var/macports/build/_Users_ram_opt_macports_lang_g95/work/gcc-4.0.3/g95/intl/libintl.a -liconv Does have -L/opt/local/lib Peter -- Peter O'Gorman http://pogma.com From takeshi at mac.com Sat Jan 5 15:43:44 2008 From: takeshi at mac.com (Takeshi Enomoto) Date: Sat Jan 5 15:41:38 2008 Subject: libiconv In-Reply-To: References: <10C44B4C-BB17-4F60-842E-D85112606C7F@mac.com> Message-ID: > I can ask the developers of iconv why those functions are not present. Man pages are iconv_* rather than libiconv_*. If LIBICONV_PLUG is defined, iconv_* are used. (See include/iconv.h.in) It must be introduce to avoid some conflicts... But if so gcc source should be using libiconv_*. Please ask the developers if you can. Thanks. Takeshi From ryandesign at macports.org Sat Jan 5 22:22:08 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat Jan 5 22:20:32 2008 Subject: [32516] trunk/dports/lang/llvm-gcc4/ In-Reply-To: <20080106052414.9A4487C4890@beta.macosforge.org> References: <20080106052414.9A4487C4890@beta.macosforge.org> Message-ID: <38597065-44A1-4EC4-9449-773DF7AE1C2D@macports.org> On Jan 5, 2008, at 23:24, erickt@macports.org wrote: > Revision: 32516 > http://trac.macosforge.org/projects/macports/changeset/32516 > Author: erickt@macports.org > Date: 2008-01-05 21:24:13 -0800 (Sat, 05 Jan 2008) > > Log Message: > ----------- > llvm-gcc4 has been replaced by llvm-gcc40 > > Removed Paths: > ------------- > trunk/dports/lang/llvm-gcc4/ Um... in r32515 you changed lang/llvm-gcc4, in that you changed the name of the port to llvm-gcc40, though the directory the portfile was in was still lang/llvm-gcc4. Now in r32516, you have deleted the port entirely. This doesn't seem to be what you wanted to happen. From apple at frinabulax.org Sun Jan 6 06:02:16 2008 From: apple at frinabulax.org (robert delius royar) Date: Sun Jan 6 06:00:27 2008 Subject: [MacPorts] #13848: esound library routine incorrectly identifies DISPLAY on Leopard (fwd) Message-ID: Because esound has no maintainer, I am copying this ticket to the developers' list. ---------- Forwarded message ---------- Date: Sun, 06 Jan 2008 13:57:41 -0000 From: MacPorts To: apple@frinabulax.org, macports-tickets@lists.macosforge.org Reply-To: noreply@macosforge.org Subject: [MacPorts] #13848: esound library routine incorrectly identifies DISPLAY on Leopard Message-ID: <050.3c48124381cb5efd5dfac874195ea494@macosforge.org> Content-Type: text/plain; charset="utf-8" #13848: esound library routine incorrectly identifies DISPLAY on Leopard ----------------------------------+----------------------------------------- Reporter: apple@frinabulax.org | Owner: macports-tickets@lists.macosforge.org Type: defect | Status: new Priority: High | Milestone: Component: ports | Version: 1.6.0 Keywords: audio esound | ----------------------------------+----------------------------------------- Running Leopard's X11.app the audio/esound port cannot any longer deal with a request to play sound on a local machine when code passes the NULL parameter to identify the desired server to the esdlib.c library functions. The function esd_open_sound expects a DISPLAY variable to be something such as 0:0. Leopard uses a different scheme. esd_open_sound cannot see DISPLAYs such as /tmp/launch-A6wxg2/:0 as valid. I have a patch that works, but I am not a programmer. Soemone who understands a better way to determine whether the code is running under Leopard should fix this. I have attached my patch. This port is not maintained. -- Ticket URL: MacPorts Ports system for Mac OS From mww at macports.org Sun Jan 6 06:26:36 2008 From: mww at macports.org (Markus Weissmann) Date: Sun Jan 6 06:24:30 2008 Subject: [32446] trunk/dports/sysutils/rpm-devel/Portfile In-Reply-To: <3A097D40-7293-40DE-9E5B-85C61B7E4E60@macports.org> References: <20080102093243.A64DA70A575@beta.macosforge.org> <282B5917-4B79-42F9-A974-EC77E07515D4@macports.org> <3A097D40-7293-40DE-9E5B-85C61B7E4E60@macports.org> Message-ID: On 5 Jan 2008, at 22:42, Ryan Schmidt wrote: > On Jan 3, 2008, at 05:11, Anders F Bj?rklund wrote: > >> Ryan Schmidt wrote: >> >>>> Perhaps, but these -devel ports usally build from tip of trunk so >>>> they all had revision "0"... >>> >>> Ports should never build from tip of trunk or HEAD or similar >>> concepts..... >> >> These do. > > But that's not reproducible, and I thought we always wanted that. If > I install a specific version of a port today, I should get the same > software if I install that same version of that port tomorrow. By > fetching from HEAD, you break that assumption. > >> Not sure what the alternative would be, should I set up a cron job >> to commit a Portfile daily ? > > I see for example that Markus commits a new version of gcc43 every > week or so. I hope he tests it before committing, however. > I do. Regards, -Markus -- Dipl. Inf. (FH) Markus W. Weissmann http://www.macports.org/ http://www.mweissmann.de/ From landonf at macports.org Sun Jan 6 11:43:45 2008 From: landonf at macports.org (Landon Fuller) Date: Sun Jan 6 11:41:33 2008 Subject: [32446] trunk/dports/sysutils/rpm-devel/Portfile In-Reply-To: <3A097D40-7293-40DE-9E5B-85C61B7E4E60@macports.org> References: <20080102093243.A64DA70A575@beta.macosforge.org> <282B5917-4B79-42F9-A974-EC77E07515D4@macports.org> <3A097D40-7293-40DE-9E5B-85C61B7E4E60@macports.org> Message-ID: <9CC80AE3-16EC-418F-9A91-F938268FECAE@macports.org> On Jan 5, 2008, at 1:42 PM, Ryan Schmidt wrote: > > On Jan 3, 2008, at 05:11, Anders F Bj?rklund wrote: > >> Ryan Schmidt wrote: >> >>>> Perhaps, but these -devel ports usally build from tip of trunk so >>>> they all had revision "0"... >>> >>> Ports should never build from tip of trunk or HEAD or similar >>> concepts..... >> >> These do. > > But that's not reproducible, and I thought we always wanted that. If > I install a specific version of a port today, I should get the same > software if I install that same version of that port tomorrow. By > fetching from HEAD, you break that assumption. This is why I've thought we should not support CVS/SVN fetching in any form -- No checksums, no guaranteed reproducibility. From afb at macports.org Sun Jan 6 12:20:49 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun Jan 6 12:18:55 2008 Subject: [32446] trunk/dports/sysutils/rpm-devel/Portfile In-Reply-To: <9CC80AE3-16EC-418F-9A91-F938268FECAE@macports.org> References: <20080102093243.A64DA70A575@beta.macosforge.org> <282B5917-4B79-42F9-A974-EC77E07515D4@macports.org> <3A097D40-7293-40DE-9E5B-85C61B7E4E60@macports.org> <9CC80AE3-16EC-418F-9A91-F938268FECAE@macports.org> Message-ID: Landon Fuller wrote: >> But that's not reproducible, and I thought we always wanted that. If >> I install a specific version of a port today, I should get the same >> software if I install that same version of that port tomorrow. By >> fetching from HEAD, you break that assumption. > > This is why I've thought we should not support CVS/SVN fetching in any > form -- No checksums, no guaranteed reproducibility. Specifying a revision should be reproducible (not verifiably so but), but I'll switch to tarball snapshots... Or delete the ports, whichever works. ("port not found" is guaranteed to be reproducible every single time) --anders From mww at macports.org Sun Jan 6 15:47:47 2008 From: mww at macports.org (Markus Weissmann) Date: Sun Jan 6 15:45:39 2008 Subject: [32446] trunk/dports/sysutils/rpm-devel/Portfile In-Reply-To: References: <20080102093243.A64DA70A575@beta.macosforge.org> <282B5917-4B79-42F9-A974-EC77E07515D4@macports.org> <3A097D40-7293-40DE-9E5B-85C61B7E4E60@macports.org> <9CC80AE3-16EC-418F-9A91-F938268FECAE@macports.org> Message-ID: On 6 Jan 2008, at 21:20, Anders F Bj?rklund wrote: > Landon Fuller wrote: > >>> But that's not reproducible, and I thought we always wanted that. >>> If I install a specific version of a port today, I should get the >>> same software if I install that same version of that port >>> tomorrow. By fetching from HEAD, you break that assumption. >> >> This is why I've thought we should not support CVS/SVN fetching in >> any form -- No checksums, no guaranteed reproducibility. > > Specifying a revision should be reproducible (not verifiably so > but), but I'll switch to tarball snapshots... > > Or delete the ports, whichever works. ("port not found" is > guaranteed to be reproducible every single time) > Imho -- at least for "-devel" ports -- cvs/svn fetching is o.k. if at least a date -- in the past ;) -- is supplied. Avoid it if possible, but if it leads to you generating weekly snapshots from some repository, just use cvs/svn fetching. Regards, -Markus -- Dipl. Inf. (FH) Markus W. Weissmann http://www.macports.org/ http://www.mweissmann.de/ From afb at macports.org Mon Jan 7 00:06:47 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon Jan 7 00:04:33 2008 Subject: [32446] trunk/dports/sysutils/rpm-devel/Portfile In-Reply-To: References: <20080102093243.A64DA70A575@beta.macosforge.org> <282B5917-4B79-42F9-A974-EC77E07515D4@macports.org> <3A097D40-7293-40DE-9E5B-85C61B7E4E60@macports.org> <9CC80AE3-16EC-418F-9A91-F938268FECAE@macports.org> Message-ID: <5b25908c170c98eab124755e19c3eca0@macports.org> Markus Weissmann wrote: >>> This is why I've thought we should not support CVS/SVN fetching in >>> any form -- No checksums, no guaranteed reproducibility. >> >> Specifying a revision should be reproducible (not verifiably so but), >> but I'll switch to tarball snapshots... >> >> Or delete the ports, whichever works. ("port not found" is guaranteed >> to be reproducible every single time) > > Imho -- at least for "-devel" ports -- cvs/svn fetching is o.k. if at > least a date -- in the past ;) -- is supplied. Avoid it if possible, > but if it leads to you generating weekly snapshots from some > repository, just use cvs/svn fetching. Weekly ? No, these all have daily snapshot tarballs generated since they are under development. But I'm cool with moving the ports to my local overlay, as I won't have time to update them... --anders From frstan at bellsouth.net Mon Jan 7 07:14:01 2008 From: frstan at bellsouth.net (William Davis) Date: Mon Jan 7 07:11:48 2008 Subject: Fwd: Beginner question -- how to resolve dependent dylib's when linking References: <47779959.9090806@wanadoo.fr> Message-ID: possible useful info from uni-porting list; Begin forwarded message: > From: Martin Costabel > Date: December 30, 2007 8:12:57 AM EST > To: kelsey@slac.stanford.edu > Cc: unix-porting@lists.apple.com > Subject: Re: Beginner question -- how to resolve dependent dylib's > when linking > > Peter O'Gorman wrote: >> Mike Kelsey wrote: >>> Is there an option I can give to |libtool| or/and |ld|, such that >>> dependent >>> libraries mentioned inside .dylib's will be resolved via the -L >>> options? >> See -dylib_file in the ld(1) manpage. > > If you are on Leopard, you probably don't have to do anything in > this case. It is standard behavior there (in most situations > perceived as an annoying bug, though) that indirect libraries are > *not* looked up according to their install_name, but in the > directories defined by -L. > > Perversely, you are forced to use -dylib_file, or explicit -L -l > references, if you want them to be looked up at the path mentioned > in the referencing dylib. This wreaks all kinds of havoc if you have > several dylibs of the same name on your system, but in your > situation this may be the behavior you are wishing for. > > -- > Martin > > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Unix-porting mailing list (Unix-porting@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/unix-porting/frstan%40bellsouth.net > > This email sent to frstan@bellsouth.net William Davis frstanATbellsouthDOTnet Mac OS X.5.1 Darwin 9.1.0 X11.app 2.1.1 - (xorg-server 1.3.0-apple5) Mac Mini Intel Duo @ 1.86 GHz Mundus vult decepi, ego non -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080107/59c87b45/attachment-0001.html From ryandesign at macports.org Mon Jan 7 13:03:32 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Jan 7 13:01:50 2008 Subject: Beginner question -- how to resolve dependent dylib's when linking In-Reply-To: References: <47779959.9090806@wanadoo.fr> Message-ID: <07F39105-3C02-42E9-9919-FC7FB5DD08AC@macports.org> On Jan 7, 2008, at 09:14, William Davis wrote: > possible useful info from uni-porting list; > > Begin forwarded message: > >> From: Martin Costabel >> Date: December 30, 2007 8:12:57 AM EST >> To: kelsey@slac.stanford.edu >> Cc: unix-porting@lists.apple.com >> Subject: Re: Beginner question -- how to resolve dependent dylib's >> when linking >> >> Peter O'Gorman wrote: >>> Mike Kelsey wrote: >>>> Is there an option I can give to |libtool| or/and |ld|, such >>>> that dependent >>>> libraries mentioned inside .dylib's will be resolved via the -L >>>> options? >>> See -dylib_file in the ld(1) manpage. >> >> If you are on Leopard, you probably don't have to do anything in >> this case. It is standard behavior there (in most situations >> perceived as an annoying bug, though) that indirect libraries are >> *not* looked up according to their install_name, but in the >> directories defined by -L. >> >> Perversely, you are forced to use -dylib_file, or explicit -L -l >> references, if you want them to be looked up at the path mentioned >> in the referencing dylib. This wreaks all kinds of havoc if you >> have several dylibs of the same name on your system, but in your >> situation this may be the behavior you are wishing for. Presumably you are sending this as information for solving the "cycle in dylib re-exports" problem we see with some software under Leopard? But isn't the solution provided by Apple in their technote already sufficient to resolve this? http://developer.apple.com/qa/qa2007/qa1567.html Or am I misunderstanding your message? From blb at macports.org Mon Jan 7 13:17:37 2008 From: blb at macports.org (Bryan Blackburn) Date: Mon Jan 7 13:15:23 2008 Subject: Commit needed for cidr port, ticket #13868 Message-ID: <211D5569-1DF3-4615-B0A3-A69B40AB6903@macports.org> When someone gets a chance, the cidr port needs an update as specified in ticket #13868: Thanks, Bryan From frstan at bellsouth.net Mon Jan 7 14:01:28 2008 From: frstan at bellsouth.net (William Davis) Date: Mon Jan 7 13:59:13 2008 Subject: Beginner question -- how to resolve dependent dylib's when linking In-Reply-To: <07F39105-3C02-42E9-9919-FC7FB5DD08AC@macports.org> References: <47779959.9090806@wanadoo.fr> <07F39105-3C02-42E9-9919-FC7FB5DD08AC@macports.org> Message-ID: <32EF2FBC-2612-498E-B8F4-D9ECD523183D@bellsouth.net> On Jan 7, 2008, at 4:03 PM, Ryan Schmidt wrote: > On Jan 7, 2008, at 09:14, William Davis wrote: > >> possible useful info from uni-porting list; >> >> Begin forwarded message: >> >>> From: Martin Costabel >>> Date: December 30, 2007 8:12:57 AM EST >>> To: kelsey@slac.stanford.edu >>> Cc: unix-porting@lists.apple.com >>> Subject: Re: Beginner question -- how to resolve dependent dylib's >>> when linking >>> >>> Peter O'Gorman wrote: >>>> Mike Kelsey wrote: >>>>> Is there an option I can give to |libtool| or/and |ld|, such >>>>> that dependent >>>>> libraries mentioned inside .dylib's will be resolved via the -L >>>>> options? >>>> See -dylib_file in the ld(1) manpage. >>> >>> If you are on Leopard, you probably don't have to do anything in >>> this case. It is standard behavior there (in most situations >>> perceived as an annoying bug, though) that indirect libraries are >>> *not* looked up according to their install_name, but in the >>> directories defined by -L. >>> >>> Perversely, you are forced to use -dylib_file, or explicit -L -l >>> references, if you want them to be looked up at the path mentioned >>> in the referencing dylib. This wreaks all kinds of havoc if you >>> have several dylibs of the same name on your system, but in your >>> situation this may be the behavior you are wishing for. > > Presumably you are sending this as information for solving the > "cycle in dylib re-exports" problem we see with some software under > Leopard? > > But isn't the solution provided by Apple in their technote already > sufficient to resolve this? > > http://developer.apple.com/qa/qa2007/qa1567.html > > Or am I misunderstanding your message? > Besides the recycling problem I thought perhaps some other ports which fail config or build on Leopard might be suffering from trying to find indirect libs from their "install_name". William Davis frstanATbellsouthDOTnet Mac OS X.5.1 Darwin 9.1.0 X11.app 2.1.1 - (xorg-server 1.3.0-apple5) Mac Mini Intel Duo @ 1.86 GHz Mundus vult decepi, ego non From jberry at macports.org Mon Jan 7 14:26:33 2008 From: jberry at macports.org (James Berry) Date: Mon Jan 7 14:24:27 2008 Subject: MacPorts servers will be down for a bit in about 5 hours Message-ID: <19531F38-9F5A-43B7-A3EF-9D4F2112ADC5@macports.org> Our friends at MacOSForge tell us that the servers running macports will be down in about 5 hours for some scheduled maintenance: > We need to take the servers down briefly to apply some updates and > configuration changes. All services will have 5-10m of downtime > starting around 8PM on Monday. The Trac & Subversion services will > have additional downtime to upgrade the RAM to improve performance. > I expect Trac/SVN to be down for 30m total. I'll make announcements > in #macosforge as each services goes down and up. Everything should > be back to normal around 9pm. If the unexpected occurs, as it sometimes does, please bear with us. If you need a status update you might stop in on the #macports or #macosforge channels on freenode, where more information might or might not be available ;) James From raimue at macports.org Mon Jan 7 15:52:40 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon Jan 7 15:50:35 2008 Subject: Commit needed for cidr port, ticket #13868 In-Reply-To: <211D5569-1DF3-4615-B0A3-A69B40AB6903@macports.org> References: <211D5569-1DF3-4615-B0A3-A69B40AB6903@macports.org> Message-ID: <4782BB48.4010109@macports.org> Bryan Blackburn wrote: > When someone gets a chance, the cidr port needs an update as specified > in ticket #13868: > > Committed in r32563. Just curious, as you are writing from an email address @macports.org; don't you have commit access yourself? Rainer From ryandesign at macports.org Mon Jan 7 19:14:15 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Jan 7 19:12:44 2008 Subject: [32566] trunk/dports/perl/p5-file-mmagic In-Reply-To: <20080108023003.8382D825241@beta.macosforge.org> References: <20080108023003.8382D825241@beta.macosforge.org> Message-ID: On Jan 7, 2008, at 20:30, ricci@macports.org wrote: > Added Paths: > ----------- > trunk/dports/perl/p5-file-mmagic/files/ > trunk/dports/perl/p5-file-mmagic/files/patch-MMagic.pm Please name patchfiles "patch-whatever.diff"; see the output of "sudo port lint p5-file-mmagic". From ryandesign at macports.org Mon Jan 7 19:26:50 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Jan 7 19:25:11 2008 Subject: [32565] trunk/dports/www/lynx/Portfile In-Reply-To: <20080108022402.560DA824F5B@beta.macosforge.org> References: <20080108022402.560DA824F5B@beta.macosforge.org> Message-ID: <21FA4518-C01C-41A0-93A8-FE6D3089D02F@macports.org> On Jan 7, 2008, at 20:24, raimue@macports.org wrote: > Modified: trunk/dports/www/lynx/Portfile > =================================================================== > --- trunk/dports/www/lynx/Portfile 2008-01-08 00:03:36 UTC (rev 32564) > +++ trunk/dports/www/lynx/Portfile 2008-01-08 02:24:01 UTC (rev 32565) > @@ -30,7 +30,8 @@ > sha1 019246b83fc7b6cb32bac0023f2ae6c5d330d18c \ > rmd160 0ea800c3204d66c1470f63a0143fd71eca06e005 > > -configure.args --mandir=${prefix}/share/man > +configure.args --mandir=${prefix}/share/man \ > + --enable-ipv6 > patchfiles patch-LYCharSets.c > > platforms darwin Since this changes the software that gets installed by the lynx port, the port revision should also be incremented. I did so in r32570. From raimue at macports.org Mon Jan 7 19:47:17 2008 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Mon Jan 7 19:45:11 2008 Subject: [32570] trunk/dports/www/lynx/Portfile In-Reply-To: <20080108032035.8502C82BE61@beta.macosforge.org> References: <20080108032035.8502C82BE61@beta.macosforge.org> Message-ID: <4782F245.9070406@macports.org> ryandesign@macports.org wrote: > Revision: 32570 > http://trac.macosforge.org/projects/macports/changeset/32570 > Author: ryandesign@macports.org > Date: 2008-01-07 19:20:00 -0800 (Mon, 07 Jan 2008) > > Log Message: > ----------- > lynx: increment revision so everyone gets the change from r32565; see #13864 Thanks! Actually I know that I have to increment the revision for such changes, but I simply forgot it. Rainer From mfwitten at MIT.EDU Mon Jan 7 22:38:54 2008 From: mfwitten at MIT.EDU (Michael Witten) Date: Mon Jan 7 22:39:00 2008 Subject: darwinports.com Message-ID: Maintainers of MacPorts, There is a fairly benign, but terribly frustrating issue with which you should deal swiftly. Somebody by the name of Mat Caughron is running a mirror of the MacPorts project at http://darwinports.com/ Unfortunately, such a usually kind favor is actually a mischievous attempt to garner advertisement revenue and glean user email addresses. While these ulterior motives are trashy, what disturbs me most is the confusion that results from 2 seemingly viable ports systems, especially since Mat Caughron not only hosts the system under the name DarwinPorts, but he also tries to hide the direct connection with MacPorts. Which one is the "correct" system? This semblance of disorganization and trashiness drives people away from open source or at least to other projects like fink. It is a branding issue. I advise the following: (1) Clarify the situation in the FAQ, in the Wiki, and on the main page. It should be stated in rather clear terms that darwinports.com is attempting to rebrand MacPorts mischievously for email gathering and unwarranted advertisement revenue. A strong statement makes it clear which project is official. (2) Explicitly state somewhere that derivatives must acknowledge MacPorts clearly; this will help with future troubles. (3) Try to negotiate the transfer of the ownership of darwinports.com to the MacPorts team; he can app- arently be contacted at Mat Caughron (408) 910-1266 caughron@gmail.com In any case, this subject of darwinports.com came up once in discussions: http://osdir.com/ml/opendarwin.darwinports/2004-02/msg00090.html and though Mat Caughron pretended to be a novice, who was just having fun and trying to support a project, it came to light that he had tried and is still trying to peddle other projects: http://osdir.com/ml/opendarwin.darwinports/2004-02/msg00091.html Furthermore, James Berry contacted Mat Caughron a couple of years ago in order to resolve this point of contention by initiating a transfer of the domain ownership to the project. In return, Matt Caughron required a PowerBook. With (1), it won't really matter if this transaction is refused. Sincerely, Michael Witten From ryandesign at macports.org Mon Jan 7 22:55:45 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Jan 7 22:56:24 2008 Subject: darwinports.com In-Reply-To: References: Message-ID: Well, we're aware that this problem exists. Partly as a result of this problem, since no agreement on the transfer of the domain name into our control could be reached, the name of the project was changed to MacPorts. The correct official web site for this project is http://www.macports.org/ . It was previously http:// www.darwinports.org/ . It has never been darwinports dot com. I don't know if anyone has attempted to contact the owner of darwinports dot com recently to negotiate a transfer. I'd be happy to do so on behalf of the project if desired, but we should coordinate this so that we don't all independently try to contact him. Someone from portmgr should chime in here and advise. On Jan 8, 2008, at 00:38, Michael Witten wrote: > Maintainers of MacPorts, > > There is a fairly benign, but terribly frustrating > issue with which you should deal swiftly. > > Somebody by the name of Mat Caughron is running a > mirror of the MacPorts project at > > http://darwinports.com/ > > Unfortunately, such a usually kind favor is actually > a mischievous attempt to garner advertisement revenue > and glean user email addresses. > > While these ulterior motives are trashy, what disturbs > me most is the confusion that results from 2 seemingly > viable ports systems, especially since Mat Caughron not > only hosts the system under the name DarwinPorts, but he > also tries to hide the direct connection with MacPorts. > > Which one is the "correct" system? > > This semblance of disorganization and trashiness drives > people away from open source or at least to other projects > like fink. > > It is a branding issue. > > > I advise the following: > > (1) Clarify the situation in the FAQ, in the Wiki, > and on the main page. > > It should be stated in rather clear terms that > darwinports.com is attempting to rebrand MacPorts > mischievously for email gathering and unwarranted > advertisement revenue. > > A strong statement makes it clear which project > is official. > > > (2) Explicitly state somewhere that derivatives must > acknowledge MacPorts clearly; this will help with > future troubles. > > > (3) Try to negotiate the transfer of the ownership of > darwinports.com to the MacPorts team; he can app- > arently be contacted at > > Mat Caughron > (408) 910-1266 > caughron@gmail.com > > In any case, this subject of darwinports.com came up > once in discussions: > > http://osdir.com/ml/opendarwin.darwinports/2004-02/msg00090.html > > and though Mat Caughron pretended to be a novice, who > was just having fun and trying to support a project, it > came to light that he had tried and is still trying to > peddle other projects: > > http://osdir.com/ml/opendarwin.darwinports/2004-02/msg00091.html > > Furthermore, James Berry contacted Mat Caughron a couple > of years ago in order to resolve this point of contention > by initiating a transfer of the domain ownership to the > project. In return, Matt Caughron required a PowerBook. > > > With (1), it won't really matter if this transaction > is refused. > > Sincerely, > Michael Witten From ryandesign at macports.org Mon Jan 7 22:59:46 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Jan 7 23:07:05 2008 Subject: darwinports dot com In-Reply-To: References: Message-ID: Oh, and: darwinports dot com is not a mirror of the MacPorts project. Rather, it is merely a different front-end to view the available ports, and it also contains (probably incorrect) instructions for installing and using MacPorts. I'm changing the subject line to a non-link so that we don't drive even more traffic to this inconvenient web site. On Jan 8, 2008, at 00:55, Ryan Schmidt wrote: > Well, we're aware that this problem exists. Partly as a result of > this problem, since no agreement on the transfer of the domain name > into our control could be reached, the name of the project was > changed to MacPorts. The correct official web site for this project > is http://www.macports.org/ . It was previously http:// > www.darwinports.org/ . It has never been darwinports dot com. > > I don't know if anyone has attempted to contact the owner of > darwinports dot com recently to negotiate a transfer. I'd be happy > to do so on behalf of the project if desired, but we should > coordinate this so that we don't all independently try to contact > him. Someone from portmgr should chime in here and advise. From jkh at apple.com Mon Jan 7 23:38:36 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Mon Jan 7 23:39:40 2008 Subject: darwinports.com In-Reply-To: References: Message-ID: I think there's little point in pursuing this further. We went through the whole froo-frah about this back when MacPorts was called DarwinPorts and darwinports.com was first brought to the project's attention. At that time, we negotiated unsuccessfully for the domain transfer and ultimately chose to change the project name to MacPorts and extensively rebrand the project (after, of course, obtaining all the appropriate macports domains this time around). The matter should now rest since it's hard enough just enforcing your actual project name much less going after derivatives. What next? Someone could register any one of macosports.com, macosxports.com, macsoftwareports.com, etc etc (all of which are closer to macports and even more likely to cause confusion) and the project would quickly find itself spending more time chasing people with sticks than actually maintaining ports. The darwinports.com horse is already dead and buried, and the set of folks who still remember it as "darwinports" is a decreasing number of people, so at some point the problem will ultimately solve itself. - Jordan On Jan 7, 2008, at 10:55 PM, Ryan Schmidt wrote: > Well, we're aware that this problem exists. Partly as a result of > this problem, since no agreement on the transfer of the domain name > into our control could be reached, the name of the project was > changed to MacPorts. The correct official web site for this project > is http://www.macports.org/ . It was previously http://www.darwinports.org/ > . It has never been darwinports dot com. > > I don't know if anyone has attempted to contact the owner of > darwinports dot com recently to negotiate a transfer. I'd be happy > to do so on behalf of the project if desired, but we should > coordinate this so that we don't all independently try to contact > him. Someone from portmgr should chime in here and advise. > > > On Jan 8, 2008, at 00:38, Michael Witten wrote: > >> Maintainers of MacPorts, >> >> There is a fairly benign, but terribly frustrating >> issue with which you should deal swiftly. >> >> Somebody by the name of Mat Caughron is running a >> mirror of the MacPorts project at >> >> http://darwinports.com/ >> >> Unfortunately, such a usually kind favor is actually >> a mischievous attempt to garner advertisement revenue >> and glean user email addresses. >> >> While these ulterior motives are trashy, what disturbs >> me most is the confusion that results from 2 seemingly >> viable ports systems, especially since Mat Caughron not >> only hosts the system under the name DarwinPorts, but he >> also tries to hide the direct connection with MacPorts. >> >> Which one is the "correct" system? >> >> This semblance of disorganization and trashiness drives >> people away from open source or at least to other projects >> like fink. >> >> It is a branding issue. >> >> >> I advise the following: >> >> (1) Clarify the situation in the FAQ, in the Wiki, >> and on the main page. >> >> It should be stated in rather clear terms that >> darwinports.com is attempting to rebrand MacPorts >> mischievously for email gathering and unwarranted >> advertisement revenue. >> >> A strong statement makes it clear which project >> is official. >> >> >> (2) Explicitly state somewhere that derivatives must >> acknowledge MacPorts clearly; this will help with >> future troubles. >> >> >> (3) Try to negotiate the transfer of the ownership of >> darwinports.com to the MacPorts team; he can app- >> arently be contacted at >> >> Mat Caughron >> (408) 910-1266 >> caughron@gmail.com >> >> In any case, this subject of darwinports.com came up >> once in discussions: >> >> http://osdir.com/ml/opendarwin.darwinports/2004-02/msg00090.html >> >> and though Mat Caughron pretended to be a novice, who >> was just having fun and trying to support a project, it >> came to light that he had tried and is still trying to >> peddle other projects: >> >> http://osdir.com/ml/opendarwin.darwinports/2004-02/msg00091.html >> >> Furthermore, James Berry contacted Mat Caughron a couple >> of years ago in order to resolve this point of contention >> by initiating a transfer of the domain ownership to the >> project. In return, Matt Caughron required a PowerBook. >> >> >> With (1), it won't really matter if this transaction >> is refused. >> >> Sincerely, >> Michael Witten > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080107/17a99628/attachment.html From afb at macports.org Tue Jan 8 00:34:00 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Jan 8 00:34:12 2008 Subject: [32194] trunk/base/src/port1.0/portconfigure.tcl In-Reply-To: <20071219144415.5DF344098C3@beta.macosforge.org> References: <20071219144415.5DF344098C3@beta.macosforge.org> Message-ID: <46dc6ab80652993f1bed080f70a83a61@macports.org> > Revision > 32194 > Author > mww@macports.org > Date > 2007-12-19 06:44:11 -0800 (Wed, 19 Dec 2007) > > Log Message > make the universal flags take the archs from a single source (thanks > to ryandesign for the idea), enable 64 bit universal builds This change makes all +universal ports with an UI based on Carbon break, since it (Carbon) doesn't support 64-bit... (and especially not x86_64) http://developer.apple.com/documentation/Carbon/Conceptual/ Carbon64BitGuide/ "Most APIs in Mac OS X v10.5 are available to both 32-bit and 64-bit applications, but some APIs commonly used by Carbon applications are not. In particular, the APIs used to implement a Carbon user interface are generally available only to 32-bit applications. If you want to create a 64-bit application for Mac OS X, you need to use Cocoa to implement its user interface." Never mind that it also makes each one twice as big (4 times the original) > > +# > +# internal functions to determine the "-arch xy" flags for the > compiler > +# -> these should preferably get a more global scope, perhaps be > user-configurable? > +set universal_archs {ppc ppc64 i386 x86_64} > + This should probably be reverted back to "set universal_archs {ppc i386}" ? --anders From afb at macports.org Tue Jan 8 00:34:10 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Jan 8 00:34:15 2008 Subject: darwinports.com In-Reply-To: References: Message-ID: <93023b6080675810153412209cc64838@macports.org> Jordan K. Hubbard wrote: > The matter should now?rest since it's hard enough just enforcing your > actual project name much less going after derivatives. ?What next? > ?Someone could register any one of macosports.com, macosxports.com, > macsoftwareports.com, etc etc (all of which are closer to macports and > even more likely to cause confusion) and the project would quickly > find itself spending more time chasing people with sticks than > actually maintaining ports. ?The darwinports.com horse is already dead > and buried, and the set of folks who still remember it as > "darwinports" is a decreasing number of people, so at some point the > problem will ultimately solve itself. The usual reason to why it reappears is because the port view at e.g. foo.darwinports.com usually comes up higher in search results from e.g. Google than what the corresponding page in http://db.macports.org or http://macports.org/ports.php does... And since it shows the same Portfile with the same version, people tend to get confused between darwinports and macports still. If the two (!) MacPorts lists could be consolidated (like the Guide has been), that would probably help clear things up ? --anders From mfwitten at MIT.EDU Tue Jan 8 00:48:23 2008 From: mfwitten at MIT.EDU (Michael Witten) Date: Tue Jan 8 00:48:27 2008 Subject: darwinports.com In-Reply-To: <93023b6080675810153412209cc64838@macports.org> References: <93023b6080675810153412209cc64838@macports.org> Message-ID: On 8 Jan 2008, at 3:34 AM, Anders F Bj?rklund wrote: > Jordan K. Hubbard wrote: > >> The matter should now rest since it's hard enough just enforcing >> your actual project name much less going after derivatives. What >> next? Someone could register any one of macosports.com, >> macosxports.com, macsoftwareports.com, etc etc (all of which are >> closer to macports and even more likely to cause confusion) and the >> project would quickly find itself spending more time chasing people >> with sticks than actually maintaining ports. The darwinports.com >> horse is already dead and buried, and the set of folks who still >> remember it as "darwinports" is a decreasing number of people, so >> at some point the problem will ultimately solve itself. > > The usual reason to why it reappears is because the port view at > e.g. foo.darwinports.com usually comes up higher in search results > from e.g. Google than what the corresponding page in http://db.macports.org > or http://macports.org/ports.php does... > > And since it shows the same Portfile with the same version, people > tend to get confused between darwinports and macports still. If the > two (!) MacPorts lists could be consolidated (like the Guide has > been), that would probably help clear things up ? I still think my first suggestion is the best: > (1) Clarify the situation in the FAQ, in the Wiki, > and on the main page. > > It should be stated in rather clear terms that > darwinports.com is attempting to rebrand MacPorts > mischievously for email gathering and unwarranted > advertisement revenue. > > A strong statement makes it clear which project > is official. From mww at macports.org Tue Jan 8 00:54:09 2008 From: mww at macports.org (Markus Weissmann) Date: Tue Jan 8 00:54:16 2008 Subject: [32194] trunk/base/src/port1.0/portconfigure.tcl In-Reply-To: <46dc6ab80652993f1bed080f70a83a61@macports.org> References: <20071219144415.5DF344098C3@beta.macosforge.org> <46dc6ab80652993f1bed080f70a83a61@macports.org> Message-ID: On 8 Jan 2008, at 09:34, Anders F Bj?rklund wrote: >> Revision >> 32194 >> Author >> mww@macports.org >> Date >> 2007-12-19 06:44:11 -0800 (Wed, 19 Dec 2007) >> >> Log Message >> make the universal flags take the archs from a single source >> (thanks to ryandesign for the idea), enable 64 bit universal builds > > This change makes all +universal ports with an UI based on Carbon > break, > since it (Carbon) doesn't support 64-bit... (and especially not > x86_64) > > http://developer.apple.com/documentation/Carbon/Conceptual/Carbon64BitGuide/ > > "Most APIs in Mac OS X v10.5 are available to both 32-bit and 64-bit > applications, but some APIs commonly used by Carbon applications are > not. In particular, the APIs used to implement a Carbon user > interface are generally available only to 32-bit applications. If > you want to create a 64-bit application for Mac OS X, you need to > use Cocoa to implement its user interface." > > Never mind that it also makes each one twice as big (4 times the > original) > >> >> +# >> +# internal functions to determine the "-arch xy" flags for the >> compiler >> +# -> these should preferably get a more global scope, perhaps be >> user-configurable? >> +set universal_archs {ppc ppc64 i386 x86_64} >> + > > This should probably be reverted back to "set universal_archs {ppc > i386}" ? > This should definitely be made user-configurable. Most people will actually be interested in building 32 and 64 bit for their machine, that is either ppc+ppc64 or i386+x86_64. Regards, -Markus -- Dipl. Inf. (FH) Markus W. Weissmann http://www.mweissmann.de/ From takeshi at mac.com Tue Jan 8 04:33:34 2008 From: takeshi at mac.com (Takeshi Enomoto) Date: Tue Jan 8 04:33:42 2008 Subject: libiconv In-Reply-To: <47801610.6080508@pogma.com> References: <10C44B4C-BB17-4F60-842E-D85112606C7F@mac.com> <47801610.6080508@pogma.com> Message-ID: <323A63DC-CEA1-4ADC-9404-C4C03AED4A1D@mac.com> Peter, > Does not have -I/opt/local/include > Does have -L/opt/local/lib You are right. Thanks. There is an inconsistency. With MacPorts' iconv.h iconv_* are redefined to libiconv_*. I think I fixed the problem. I will upload the patch after Trac is back. Takeshi From jkh at apple.com Tue Jan 8 09:14:43 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Tue Jan 8 09:15:16 2008 Subject: darwinports.com In-Reply-To: References: <93023b6080675810153412209cc64838@macports.org> Message-ID: <2BA60254-B041-4D66-92F4-35C538FFF2F8@apple.com> On Jan 8, 2008, at 12:48 AM, Michael Witten wrote: > I still think my first suggestion is the best: > >> (1) Clarify the situation in the FAQ, in the Wiki, >> and on the main page. Well, the project documentation is no different than, say, a Portfile - by all means open a ticket and attach a diff with the wording you think would be appropriate (I believe the web site contents are in svn, yes?). That will expedite this change since all a committer needs to do is apply your patch and check it in. - Jordan From jmpp at macports.org Tue Jan 8 11:17:06 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Jan 8 11:15:23 2008 Subject: darwinports dot com In-Reply-To: References: Message-ID: On Jan 8, 2008, at 2:25 AM, Ryan Schmidt wrote: > Well, we're aware that this problem exists. Partly as a result of > this problem, since no agreement on the transfer of the domain name > into our control could be reached, the name of the project was > changed to MacPorts. The correct official web site for this project > is http://www.macports.org/ . It was previously http://www.darwinports.org/ > . It has never been darwinports dot com. > > I don't know if anyone has attempted to contact the owner of > darwinports dot com recently to negotiate a transfer. I'd be happy > to do so on behalf of the project if desired, but we should > coordinate this so that we don't all independently try to contact > him. Someone from portmgr should chime in here and advise. As Jordan says, this is an already beaten to death horse. We tried a number of times, all to no avail, to negotiate the transfer of the domain to us back when we were called DarwinPorts, but now with our new project name that's a bit of a moot point. Negotiations for a cease and desist of this leeching activity were also fruitless, just as were invitations to Mr. Caughron to give a bit back to the project and invest some of those energies in improving our own web portal, since he obviously has a thing for web development. In conclusion, I'll state clearly with my PortMgr hat on that we hold NO TIES WHAT-SO-EVER to darwinports dot com and have NO INTEREST in establishing any at the time being. On the other hand, we do wish to work harder and harder to further consolidate our position as an Open Source software porting project for the Mac OS X platform, reason why some of us have been devoting a lot of energies lately to some of the project aspects that unfortunately were neglected for far too long: a real website with consolidated information and resulting improved search engine rankings, a revitalized and readily available project guide, a unified project name, etc, etc, etc... Any help in improving and extending in any way any of these efforts is more than gladly welcomed! For instance, anyone with obvious tips on how to improve our search engine rankings should not delay one bit in discussing them with me. As I said in a post a while ago (http://lists.macosforge.org/pipermail/macports-dev/2007-December/003922.html ), our web presence has improved dramatically! But as was appropriately noted by Emmanuel (http://lists.macosforge.org/pipermail/macports-dev/2007-December/003924.html ), there's still quite a bit of work to be done, as any search for MacPorts *and* a particular portname does give our dear leech a much higher ranking. As Jordan asked, our web sources are indeed in svn (/ trunk/www/), so anyone interested in giving us a hand there should dive right in! I have our www.macports.org URL registered with Google under my Gmail Id, so I have direct access to very interesting stats results that will definitely come in handy when improving our rank. To anyone reading, do contact me if you'd like to discuss this further. Another area of obvious improvement is finally bringing James' mpwa at http://db.macports.org into our consolidated web portal, by, among others, unifying its look and feel with our new one at www.macports.org and also finding smart ways to integrate its functionality with that at www.macports.org/ports.php. The sources for mpwa are at svn's /users/jberry/mpwa, so anyone interested in helping in that area can also jump right in (warning, mpwa is implemented in Ruby on Rails). I'm sure work on this area would greatly help balance what Emmanuel pointed out. Last but certainly not least, I'd like to state again that there are also other areas in which we could improve our presence while at the same time making it clear what our relation to darwinports dot com is (or lack of it, for that matter). Nevertheless, I wouldn't want to pollute things like our front page, guide and similar with notes about darwinports dot com, as that in itself would be, besides ugly, some form of advertisement for that site (there's already a very loud warning that springs up at www.macports.org if you're referred to us from darwinports dot com, cf. svn's /trunk/www/includes/warnings.inc). Other things like FAQ entries are gladly accepted, though (hint: as Jordan says, there's the "Website & Documentation" milestone up at our Roadmap -- http://trac.macports.org/projects/macports/roadmap -- to classify appropriate tickets which could hold suggested patches ;-). Regards,... -jmpp > > > > On Jan 8, 2008, at 00:38, Michael Witten wrote: > >> Maintainers of MacPorts, >> >> There is a fairly benign, but terribly frustrating >> issue with which you should deal swiftly. >> >> Somebody by the name of Mat Caughron is running a >> mirror of the MacPorts project at >> >> http://darwinports.com/ >> >> Unfortunately, such a usually kind favor is actually >> a mischievous attempt to garner advertisement revenue >> and glean user email addresses. >> >> While these ulterior motives are trashy, what disturbs >> me most is the confusion that results from 2 seemingly >> viable ports systems, especially since Mat Caughron not >> only hosts the system under the name DarwinPorts, but he >> also tries to hide the direct connection with MacPorts. >> >> Which one is the "correct" system? >> >> This semblance of disorganization and trashiness drives >> people away from open source or at least to other projects >> like fink. >> >> It is a branding issue. >> >> >> I advise the following: >> >> (1) Clarify the situation in the FAQ, in the Wiki, >> and on the main page. >> >> It should be stated in rather clear terms that >> darwinports.com is attempting to rebrand MacPorts >> mischievously for email gathering and unwarranted >> advertisement revenue. >> >> A strong statement makes it clear which project >> is official. >> >> >> (2) Explicitly state somewhere that derivatives must >> acknowledge MacPorts clearly; this will help with >> future troubles. >> >> >> (3) Try to negotiate the transfer of the ownership of >> darwinports.com to the MacPorts team; he can app- >> arently be contacted at >> >> Mat Caughron >> (408) 910-1266 >> caughron@gmail.com >> >> In any case, this subject of darwinports.com came up >> once in discussions: >> >> http://osdir.com/ml/opendarwin.darwinports/2004-02/msg00090.html >> >> and though Mat Caughron pretended to be a novice, who >> was just having fun and trying to support a project, it >> came to light that he had tried and is still trying to >> peddle other projects: >> >> http://osdir.com/ml/opendarwin.darwinports/2004-02/msg00091.html >> >> Furthermore, James Berry contacted Mat Caughron a couple >> of years ago in order to resolve this point of contention >> by initiating a transfer of the domain ownership to the >> project. In return, Matt Caughron required a PowerBook. >> >> >> With (1), it won't really matter if this transaction >> is refused. >> >> Sincerely, >> Michael Witten > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev From jmpp at macports.org Tue Jan 8 11:39:47 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Jan 8 11:37:55 2008 Subject: MacPorts 1.6.1 Message-ID: So, how about a quick and simple 1.6.1 release? There are a couple of things I'd like to give a bit of a wider audience to: -) James' "load" and "unload" port actions; -) MacPorts build fixes with Universal flags turned on (usually through the MacPorts Portfile) and a Panther specific fix to search the bundled sqlite sources; -) Kevin's switch to try-catch blocks in the UI initialization in macports1.0; -) my reworked selfupdate proc, which I've already cleanup quite a bit locally. Items 2 and 3 above will help us hunt down the problems that have prevented us so far from building a Panther dmg. On the other hand, is there something currently in trunk that anyone would like to keep out of the release branch for the time being? For instance, if I'm not mistaken there are some concerns about the changes to Universal building that have gone in recently....? Regards,... -jmpp From jmpp at macports.org Tue Jan 8 12:04:12 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Jan 8 12:02:20 2008 Subject: [32334] trunk/www/install.php In-Reply-To: <4e3a5db600361b1accd5c01efbff58a2@macports.org> References: <20071225213307.E3E445FCC84@beta.macosforge.org> <4e3a5db600361b1accd5c01efbff58a2@macports.org> Message-ID: On Dec 28, 2007, at 7:07 AM, Anders F Bj?rklund wrote: >> Revision >> 32334 >> Author >> jmpp@macports.org >> Date >> 2007-12-25 13:33:06 -0800 (Tue, 25 Dec 2007) >> >> Log Message >> Clarify that Leopard users need to install Xcode 3.0, while Tiger >> users need 2.5 (sorry Anders, no direct link to 2.4 off apple's >> site :-P). > > As long as you are willing to deal with the breakage from using > Xcode 2.5 (like #13736 et al), feel free to recommend either... I > still think 2.4(.1) is the one to use while on Tiger. But the link > is the same as ever: http://connect.apple.com > > "Xcode 2.5 is a minor update to the Tiger tools that is functionally > similar to Xcode 2.4.1. It is not considered a critical update. ... > This release is recommended for developers needing to continue to > use the Tiger tools while running Leopard, and serves as a > transition to Xcode 3.0..." My main concern was providing a direct link to a downloadable package, and currently Apple provides none for 2.4.1 unless you log into connect.apple.com (at which point the link to the 2.4.1 bundle becomes unique to your session, invalid out of it). That's why I advertised 2.5, but I guess I could revert that to 2.4.1 and live without a direct link. Done in r32584 > > >> Also switch to the now more familiar "Xcode" name, as the older >> "Developer Tools" is apparently being phased out. Closes #12779. > > I only use the name "Developer Tools" since "Xcode Tools" is > somewhat ambiguous and easily confused with Xcode.app even though it > also installs a lot of BSD tools... But you can say "Xcode Tools > 2.4" instead of "August 2006 Developer Tools" if you prefer that > name (but not just Xcode please) > > So saying Developer Tools is just a personal preference of mine, > that extends to FreeBSD and Fedora as well. But the name hasn't been > in use since Project Builder, when everything was renamed to Xcode. > I kinda expected Interface Builder to be renamed to Xgui or > something too, but that never happened. I was saying "Xcode 3.0 developer tools" for a mixed result, but I understand your concern so I capitalized "Developer Tools" for improved readability. Thanks for the feedback! Regards,... -jmpp From jmpp at macports.org Tue Jan 8 12:51:20 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Jan 8 12:49:34 2008 Subject: [MacPorts] #13352: Shortened "Assign to" list in tickets In-Reply-To: <5904AA14-1D72-41B4-A101-9EECA78F7063@macports.org> References: <047.137973bc57e93a3ba25521b5c627eef2@macosforge.org> <056.538a2e928e4a8651abcf8887994cde4c@macosforge.org> <21877768-08F3-4F3E-8914-135AB827E7D7@macports.org> <72CE17B1-0A6A-42C0-AC1E-66F4B063258E@apple.com> <5904AA14-1D72-41B4-A101-9EECA78F7063@macports.org> Message-ID: On Dec 21, 2007, at 6:12 PM, Ryan Schmidt wrote: > Bill, > > I made you a PHP script which parses out all the maintainer email > addresses from the PortIndex. It runs in less than 2 seconds on my > MacBook Pro. It's attached to this ticket: > > http://trac.macosforge.org/projects/macports/ticket/13673 > > (I tried to use the port command to produce the list, as you'll see > in the ticket description, but that took 9 minutes to run.) > > It would be great if maintainers would have extra privileges in > Trac, including being able to resolve tickets, change other ticket > fields, and have tickets assigned to them. > Implementing the 4th list of "maintainers" that you talk about would be sweet, as there indeed seems to be problems building the "Assign To" menu out of committers (for instance, Landon is a committer and doesn't appear in it -- could that be because lazy Landon hasn't logged in yet...? ;-). Also there are many maintainers who are not committers, so as things stand we're definitely leaving out an important part of the people that need to be on that menu. I think it's wise to give ticket modify perms to all maintainers, but maybe not to all those with Trac accounts (as discussed in ticket #10900). Is this possible with Rayn's script in #13673? Regards,.... -jmpp > > On Dec 21, 2007, at 12:40, William Siegrist wrote: > >> Oh, I can also make a distinction between "any user logged in" and >> "a maintainer", if someone provides me with a list of people. Right >> now there are 3 "lists" for your projects, "admin", "core", and >> "committers". I can make a 4th that doesnt have commit access but >> does get more Trac permissions (TICKET_MODIFY per the link in my >> last email). I dont have time to work out an automated script >> right now, but I'm happy to keep it up via email notices similar to >> the way committers are done right now. >> >> >> -Bill >> >> >> On Dec 21, 2007, at 10:33 AM, William Siegrist wrote: >> >>> Like I said in my previous comment, the list is limited to >>> accounts that can modify tickets. Thats just committers right now. >>> Sorry I wasnt more clear in this most recent comment. I can give >>> more permissions to the regular users, but to make them show up in >>> the assign-to list also lets them resolve tickets and change >>> properties. It was already decided on another ticket that the >>> properties permission was to be just committers. >>> >>> v0.11 will have a new permission system which might make this >>> easier, and also opens up more plugin options for this. >>> >>> The current permissions for v0.10: >>> >>> http://trac.edgewall.org/wiki/TracPermissions >>> >>> >>> -Bill >>> >>> >>> >>> >>> On Dec 21, 2007, at 1:39 AM, Ryan Schmidt wrote: >>> >>>> On Dec 20, 2007, at 13:29, MacPorts wrote: >>>> >>>>> #13352: Shortened "Assign to" list in tickets >>>>> -------------------------------- >>>>> +------------------------------------------- >>>>> Reporter: jmpp@macports.org | Owner: wsiegrist@apple.com >>>>> Type: defect | Status: closed >>>>> Priority: Normal | Milestone: >>>>> Component: server/hosting | Version: 1.5.2 >>>>> Resolution: fixed | Keywords: assign to list >>>>> -------------------------------- >>>>> +------------------------------------------- >>>>> Changes (by wsiegrist@apple.com): >>>>> >>>>> * status: new => closed >>>>> * resolution: => fixed >>>>> >>>>> Comment: >>>>> >>>>> Closing. Trac generates the list from all valid accounts, so if a >>>>> maintainer is missing they can just login to trac and they will >>>>> show up. >>>> >>>> So why do we have so few of our maintainers logging into Trac? >>>> The list of possible assignees contains only four email addresses >>>> not @macports.org, and two of those are @apple.com: >>>> >>>> kvv@apple.com >>>> macosforge@otierney.net >>>> pguyot@kallisys.net >>>> wsiegrist@apple.com >>>> >>>> But I count well over 200 maintainer email addresses in our >>>> portfiles that aren't @macports.org. How can it be that only two >>>> of our non-@macports.org maintainers are logging in? >>>> >>>> Take as an example this ticket: >>>> >>>> http://trac.macosforge.org/projects/macports/ticket/13597 >>>> >>>> It was filed by Paulo Moura, one of our maintainers. Surely he >>>> logged in in order to file the ticket. Why is his email address >>>> not showing up in the assignee list? From jmpp at macports.org Tue Jan 8 13:14:35 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Jan 8 13:12:47 2008 Subject: Different dmgs for different felines In-Reply-To: <4775338F.9090107@macports.org> References: <159ED350-ACF8-4629-BE90-C4C93291178D@macports.org> <11267.202.81.69.153.1198474096.squirrel@webmail.tuffmail.net> <3B2B99E9-1AF5-469B-8665-8AE7A80178BA@macports.org> <47752032.8080508@macports.org> <8F45516A-24C0-40D2-82B7-37E4CE9B7D8A@macports.org> <4775338F.9090107@macports.org> Message-ID: Even though I do believe that Universal building is a bit of a waste of space more often than not for most, I do buy into the simplicity such builds report for users that only have to go looking for a single download link. Maybe Markus could advise us on how we could achieve this through the MacPorts Portfile (sudo port dmg MacPorts)? In any case, for the time being while we have separate dmg's for different felines, I already cleared up a bit the instructions on www.macports.org/install.php so that it's clear which one is needed for each platform. Maun Suang, since you reported to me that you already got the Panther dmg built, and that the errors you're experiencing (ui_prefix) manifest themselves regardless of whether you install from the dmg or from source, what would you say about uploading that dmg regardless of the bug? Kevin introduced some code to hunt down those errors, but that wont see the light of day until 1.6.1, which is orthogonal to the dmg. Regards,.... -jmpp On Dec 28, 2007, at 1:34 PM, Rainer M?ller wrote: > Ryan Schmidt wrote: >> Rainer, would you prefer for us to distribute 5 different disk >> images of >> MacPorts then -- Panther PowerPC, Tiger PowerPC, Tiger Intel, Leopard >> PowerPC, Leopard Intel? > > A disk image with four architectures will be around four times bigger > than it needs to be... Why should anybody want to download a large > file > if 3/4 are useless data and just occupy disk space? > >> Apple wants developers to make universal binaries so that users don't >> need to care what kind of processor they have. Other Mac developers >> are >> making universal binaries. We should too. And we already do. We just >> have separate images for Panther, Tiger and Leopard right now. And >> I'd >> like to unify that as well so that we end up with a single >> downloadable >> for our software, like most other Mac developers already have. > > So why does Apple not just provide a interface to strip uneeded > architectures right on installing? Instead, they copy useless data. I > don't understand this... At least one can do it himself and remove > them > with ditto. > >> We already had several cases where users downloaded the Leopard >> MacPorts >> disk image, installed it on Tiger, and of course it didn't work. So >> distributing a single disk image which works everywhere is simpler >> for >> users. > > [Those stupid users should learn to read...] > > But if you download an universal disk image; after the first > selfupdate, > which you normally do after install to get a newer minor version, you > will end up with a single architecture - the one of your system. Why > should disk images distribute a different version than selfupdate? > > I don't want to debate over support universal building for ports, > somebody might need it. And I don't want to say that universal in > general is bad. > > Rainer From afb at macports.org Tue Jan 8 13:29:46 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Jan 8 13:29:47 2008 Subject: [32334] trunk/www/install.php In-Reply-To: References: <20071225213307.E3E445FCC84@beta.macosforge.org> <4e3a5db600361b1accd5c01efbff58a2@macports.org> Message-ID: <254b1df0ec489e9296da513def6ae23e@macports.org> Juan Manuel Palacios wrote: >> As long as you are willing to deal with the breakage from using Xcode >> 2.5 (like #13736 et al), feel free to recommend either... I still >> think 2.4(.1) is the one to use while on Tiger. But the link is the >> same as ever: http://connect.apple.com > My main concern was providing a direct link to a downloadable > package, and currently Apple provides none for 2.4.1 unless you log > into connect.apple.com (at which point the link to the 2.4.1 bundle > becomes unique to your session, invalid out of it). That's why I > advertised 2.5, but I guess I could revert that to 2.4.1 and live > without a direct link. Done in r32584 Apple don't ever offer links to old versions, presumably because it'd hurt sales of newer versions ;-) So I used http://store.apple.com for Mac OS X and http://connect.apple.com for Xcode, for the URLs. For the current breakage, someone could/should offer a PKG to fix up the missing glibtool files... Requiring the use of the port just because Apple messed up their update seems like wrong approach. --anders From ryandesign at macports.org Tue Jan 8 13:38:31 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Jan 8 13:39:08 2008 Subject: Different dmgs for different felines In-Reply-To: References: <159ED350-ACF8-4629-BE90-C4C93291178D@macports.org> <11267.202.81.69.153.1198474096.squirrel@webmail.tuffmail.net> <3B2B99E9-1AF5-469B-8665-8AE7A80178BA@macports.org> <47752032.8080508@macports.org> <8F45516A-24C0-40D2-82B7-37E4CE9B7D8A@macports.org> <4775338F.9090107@macports.org> Message-ID: On Jan 8, 2008, at 15:14, Juan Manuel Palacios wrote: > Even though I do believe that Universal building is a bit of a > waste of space more often than not for most, I do buy into the > simplicity such builds report for users that only have to go > looking for a single download link. Maybe Markus could advise us on > how we could achieve this through the MacPorts Portfile (sudo port > dmg MacPorts)? Why don't we instead change the base Makefile so that it builds universal (for 10.3.9 on PPC, for 10.4u on i386). That way, you get a universal build no matter how you do it, whether through the MacPorts Portfile, manually, or via selfupdate. This would also address Rainer's concerns from earlier, which may be a valid point (that selfupdate would make it non-universal again) (though I haven't tested whether this is really the case) (though I could see that it might be): > On Dec 28, 2007, at 1:34 PM, Rainer M?ller wrote: > >> But if you download an universal disk image; after the first >> selfupdate, >> which you normally do after install to get a newer minor version, you >> will end up with a single architecture - the one of your system. Why >> should disk images distribute a different version than selfupdate? From takeshi at mac.com Tue Jan 8 13:45:27 2008 From: takeshi at mac.com (Takeshi Enomoto) Date: Tue Jan 8 13:45:31 2008 Subject: libiconv In-Reply-To: <323A63DC-CEA1-4ADC-9404-C4C03AED4A1D@mac.com> References: <10C44B4C-BB17-4F60-842E-D85112606C7F@mac.com> <47801610.6080508@pogma.com> <323A63DC-CEA1-4ADC-9404-C4C03AED4A1D@mac.com> Message-ID: > I will upload the patch after Trac is back. I submitted the patch of g95 package. Could someone take a look? Takeshi From ryandesign at macports.org Tue Jan 8 14:09:50 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Jan 8 14:10:30 2008 Subject: [32592] trunk/dports/python/py-django-devel/Portfile In-Reply-To: <20080108214251.C8249D7F6264@lists.macosforge.org> References: <20080108214251.C8249D7F6264@lists.macosforge.org> Message-ID: On Jan 8, 2008, at 15:42, erickt@macports.org wrote: > Revision: 32592 > http://trac.macosforge.org/projects/macports/changeset/32592 > Author: erickt@macports.org > Date: 2008-01-08 13:42:49 -0800 (Tue, 08 Jan 2008) > > Log Message: > ----------- > version bump to 0.96.1 > > Modified Paths: > -------------- > trunk/dports/python/py-django-devel/Portfile > > Modified: trunk/dports/python/py-django-devel/Portfile > =================================================================== > --- trunk/dports/python/py-django-devel/Portfile 2008-01-08 > 21:10:31 UTC (rev 32591) > +++ trunk/dports/python/py-django-devel/Portfile 2008-01-08 > 21:42:49 UTC (rev 32592) > @@ -4,7 +4,7 @@ > PortGroup python24 1.0 > > name py-django-devel > -version 0.96 > +version 0.96.1 > revision 1 When you bump a port's version, don't forget to drop the revision back down to 0 (or remove the revision line entirely which does the same thing). > -master_sites http://media.djangoproject.com/releases/$ > {version}/ > +master_sites http://media.djangoproject.com/releases/0.96/ Instead of changing to hard-coding the version here, you could do this as in the glib2 portfile and others: set branch [join [lrange [split ${version} .] 0 1] .] master_sites http://media.djangoproject.com/releases/$ {branch}/ From ryandesign at macports.org Tue Jan 8 14:15:22 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Jan 8 14:16:04 2008 Subject: [32596] trunk/dports/print/libpaper/Portfile In-Reply-To: <20080108215112.7BD72D7F6B08@lists.macosforge.org> References: <20080108215112.7BD72D7F6B08@lists.macosforge.org> Message-ID: On Jan 8, 2008, at 15:51, ricci@macports.org wrote: > Modified: trunk/dports/print/libpaper/Portfile > =================================================================== > --- trunk/dports/print/libpaper/Portfile 2008-01-08 21:48:43 UTC > (rev 32595) > +++ trunk/dports/print/libpaper/Portfile 2008-01-08 21:51:10 UTC > (rev 32596) > @@ -2,8 +2,8 @@ > > PortSystem 1.0 > name libpaper > -version 1.1.14-3 > -set base_version 1.1.14 > +version 1.1.21 > +set base_version 1.1.21 > revision 1 FYI: Instead of listing the version number twice, you could list it just once in ${version} and compute it for ${base_version}, like this: version 1.1.21 set base_version [lindex [split ${version} -] 0] Also, when you increase the port's version, don't forget to drop the revision down to 0 (or remove the revision line entirely which does the same thing). From jmpp at macports.org Tue Jan 8 14:22:55 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Jan 8 14:21:00 2008 Subject: How embarrasing! Message-ID: <33A5BF6E-F37D-494B-A19C-E80C39AECFB8@macports.org> Warning: violation by /opt/local/man Warning: MacPorts violates the layout of the ports-filesystems! Warning: Please fix or indicate this misbehavior (if it is intended), it will be an error in future releases! Do you think it's safe to remove the ${prefix}/man symlink to $ {prefix}/share/man in MacPorts sources? Or do we have to bite the bullet and "destroot.violate_mtree yes"-justify ourselves to remove the warning? -jmpp From jmpp at macports.org Tue Jan 8 15:21:25 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Jan 8 15:19:37 2008 Subject: Different dmgs for different felines In-Reply-To: References: <159ED350-ACF8-4629-BE90-C4C93291178D@macports.org> <11267.202.81.69.153.1198474096.squirrel@webmail.tuffmail.net> <3B2B99E9-1AF5-469B-8665-8AE7A80178BA@macports.org> <47752032.8080508@macports.org> <8F45516A-24C0-40D2-82B7-37E4CE9B7D8A@macports.org> <4775338F.9090107@macports.org> Message-ID: <8AA96FB4-7063-4FB9-AEE2-50FB4D34747B@macports.org> On Jan 8, 2008, at 4:44 PM, Juan Manuel Palacios wrote: > > Maun Suang, since you reported to me that you already got the > Panther dmg built, and that the errors you're experiencing > (ui_prefix) manifest themselves regardless of whether you install > from the dmg or from source, what would you say about uploading that > dmg regardless of the bug? Kevin introduced some code to hunt down > those errors, but that wont see the light of day until 1.6.1, which > is orthogonal to the dmg. I should definitely keep a closer eye on the users list! ;-) I just realized there that the Panther runtime problems have been corrected (kevin's try-catch blocks, so much for my 1.6.1 related comments;-), so there shouldn't be any problem in uploading the 1.6.0 dmg for Panther. Once a user installs off that, the postfligth script will selfupdate to 1.6.1 when we release it, so Panther users will hopefully not see the runtime errors. -jmpp From opendarwin.org at darkart.com Tue Jan 8 17:52:18 2008 From: opendarwin.org at darkart.com (Eric Hall) Date: Tue Jan 8 17:52:16 2008 Subject: [32596] trunk/dports/print/libpaper/Portfile In-Reply-To: References: <20080108215112.7BD72D7F6B08@lists.macosforge.org> Message-ID: <20080109015217.GN5860@darkart.com> On Tue, Jan 08, 2008 at 04:15:22PM -0600, Ryan Schmidt wrote: > On Jan 8, 2008, at 15:51, ricci@macports.org wrote: > > >Modified: trunk/dports/print/libpaper/Portfile > >=================================================================== > >--- trunk/dports/print/libpaper/Portfile 2008-01-08 21:48:43 UTC > >(rev 32595) > >+++ trunk/dports/print/libpaper/Portfile 2008-01-08 21:51:10 UTC > >(rev 32596) > >@@ -2,8 +2,8 @@ > > > > PortSystem 1.0 > > name libpaper > >-version 1.1.14-3 > >-set base_version 1.1.14 > >+version 1.1.21 > >+set base_version 1.1.21 > > revision 1 > > FYI: Instead of listing the version number twice, you could list it > just once in ${version} and compute it for ${base_version}, like this: > > version 1.1.21 > set base_version [lindex [split ${version} -] 0] True, one can normalize things to no end. They're also harder to read for those that 1) don't keep up with Portfile syntax as much or 2) don't speak tcl. > > > Also, when you increase the port's version, don't forget to drop the > revision down to 0 (or remove the revision line entirely which does > the same thing). Whup, I did forget to drop the revision :( -eric From ryandesign at macports.org Tue Jan 8 18:00:40 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Jan 8 18:01:18 2008 Subject: [32596] trunk/dports/print/libpaper/Portfile In-Reply-To: <20080109015217.GN5860@darkart.com> References: <20080108215112.7BD72D7F6B08@lists.macosforge.org> <20080109015217.GN5860@darkart.com> Message-ID: <2FDFD3B1-8050-481E-8338-72367F008F9C@macports.org> On Jan 8, 2008, at 19:52, Eric Hall wrote: > On Tue, Jan 08, 2008 at 04:15:22PM -0600, Ryan Schmidt wrote: > >> On Jan 8, 2008, at 15:51, ricci@macports.org wrote: >> >>> Modified: trunk/dports/print/libpaper/Portfile >>> =================================================================== >>> --- trunk/dports/print/libpaper/Portfile 2008-01-08 21:48:43 UTC >>> (rev 32595) >>> +++ trunk/dports/print/libpaper/Portfile 2008-01-08 21:51:10 UTC >>> (rev 32596) >>> @@ -2,8 +2,8 @@ >>> >>> PortSystem 1.0 >>> name libpaper >>> -version 1.1.14-3 >>> -set base_version 1.1.14 >>> +version 1.1.21 >>> +set base_version 1.1.21 >>> revision 1 >> >> FYI: Instead of listing the version number twice, you could list it >> just once in ${version} and compute it for ${base_version}, like >> this: >> >> version 1.1.21 >> set base_version [lindex [split ${version} -] 0] > > True, one can normalize things to no end. They're also > harder to read for those that 1) don't keep up with Portfile > syntax as much or 2) don't speak tcl. I don't speak tcl either. I'm just picking things up as I go along. I only wanted to make sure ricci was aware of the option. Having the port's version in more than one place in the portfile makes it more work to update it. I wanted to give him an option to simplify the update process. Having the port's version in only one place is the "correct" way to do things from a programming perspective (the desire to avoid duplication of code, etc.). It's not normalization to no end. It's normalization to the specific end of defining the version only once in the portfile. >> Also, when you increase the port's version, don't forget to drop the >> revision down to 0 (or remove the revision line entirely which does >> the same thing). > > Whup, I did forget to drop the revision :( From landonf at macports.org Tue Jan 8 18:40:04 2008 From: landonf at macports.org (Landon Fuller) Date: Tue Jan 8 18:40:13 2008 Subject: [32194] trunk/base/src/port1.0/portconfigure.tcl In-Reply-To: References: <20071219144415.5DF344098C3@beta.macosforge.org> <46dc6ab80652993f1bed080f70a83a61@macports.org> Message-ID: <7C45690F-0BFB-4870-B4F0-77E990DD5600@macports.org> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080108/8e62da45/PGP.bin From ryandesign at macports.org Wed Jan 9 12:55:13 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Jan 9 12:55:48 2008 Subject: [32618] trunk/dports/science/molden/Portfile In-Reply-To: <20080109152203.2F037D8E046B@lists.macosforge.org> References: <20080109152203.2F037D8E046B@lists.macosforge.org> Message-ID: <0CE96C06-969B-4495-B2D8-F9DFF7E734F4@macports.org> On Jan 9, 2008, at 09:22, jochen@macports.org wrote: > Revision: 32618 > http://trac.macosforge.org/projects/macports/changeset/32618 > Author: jochen@macports.org > Date: 2008-01-09 07:22:00 -0800 (Wed, 09 Jan 2008) > > Log Message: > ----------- > follow upstream stealth update > > Modified Paths: > -------------- > trunk/dports/science/molden/Portfile > > Modified: trunk/dports/science/molden/Portfile > =================================================================== > --- trunk/dports/science/molden/Portfile 2008-01-09 14:28:28 UTC > (rev 32617) > +++ trunk/dports/science/molden/Portfile 2008-01-09 15:22:00 UTC > (rev 32618) > @@ -13,15 +13,15 @@ > > name molden > version 4.6 > -revision 2 > +revision 3 > categories science graphics > maintainers openmaintainer jochen > master_sites ftp://ftp.cmbi.ru.nl/pub/molgraph/molden > distname molden${version} > dist_subdir molden-${version}_${revision} > -checksums md5 b52d66fc61f3d85abba94e36c14b5d85 \ > - sha1 2faeea9f970d5430ab0d2863a7f59c1780c56d3e \ > - rmd160 c21b9359e30f24942baa6e3b0dd412c793e3ad17 > +checksums md5 f2d929fe96ab85a3f994557140f5dcbe \ > + sha1 04cc6e32c1c8a79e54c02cfacdcddee4a64d08dc \ > + rmd160 f11735e616afb7e6de7bd94bc8782068a9fb47bf Anyone who still has the old distfile on their hard drive will now experience a checksum error when attempting to upgrade this port. You should change the dist_subdir so that this problem does not happen. Please add something like dist_subdir ${distname}/${version}_${revision} to the portfile. This can then be removed at the next real version update (or left in, if this developer is prone to making stealth updates). From john_owens at yahoo.com Wed Jan 9 15:48:44 2008 From: john_owens at yahoo.com (John Owens) Date: Wed Jan 9 15:48:56 2008 Subject: tetex/texlive dependencies Message-ID: Howdy, new committer here, happy to be on board! For several years I've been using tetex successfully. But as it's no longer updated, I'm happy to move to the new texlive port. It was tricky to install texlive because of tetex (getting tetex deactivated and texlive activated was ugly). But more importantly, now that texlive is installed, there's lots of other ports that still depend on tetex that want to use tetex, such as: $ port deps bibtex2html bibtex2html has build dependencies on: ocaml bibtex2html has runtime dependencies on: teTeX Is there any way that we can have some sort of 'virtual' TeX port that either recognizes tetex or texlive, or otherwise convince ports that depend on tetex that texlive is good enough? JDO From ryandesign at macports.org Wed Jan 9 15:53:15 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Jan 9 15:53:50 2008 Subject: tetex/texlive dependencies In-Reply-To: References: Message-ID: <16E5B12E-C2CD-49AA-91A2-089920BE2A65@macports.org> On Jan 9, 2008, at 17:48, John Owens wrote: > For several years I've been using tetex successfully. > But as it's no longer updated, I'm happy to move to > the new texlive port. > > It was tricky to install texlive because of tetex > (getting tetex deactivated and texlive activated > was ugly). > > But more importantly, now that texlive is installed, > there's lots of other ports that still depend on > tetex that want to use tetex, such as: > > $ port deps bibtex2html > bibtex2html has build dependencies on: > ocaml > bibtex2html has runtime dependencies on: > teTeX > > Is there any way that we can have some sort of > 'virtual' TeX port that either recognizes tetex > or texlive, or otherwise convince ports that > depend on tetex that texlive is good enough? If more than one port installs a binary foo, and either one is good enough, this could be specified in a portfile by saying depends_lib path:${prefix}/bin/foo:bar where "bar" is the preferred port for providing foo if it is not already installed. The dependencies would have to be changed in all ports that currently depend directly on teTeX. From john_owens at yahoo.com Wed Jan 9 16:03:06 2008 From: john_owens at yahoo.com (John Owens) Date: Wed Jan 9 16:03:19 2008 Subject: tetex/texlive dependencies References: <16E5B12E-C2CD-49AA-91A2-089920BE2A65@macports.org> Message-ID: Ryan Schmidt writes: > If more than one port installs a binary foo, and either one is good > enough, this could be specified in a portfile by saying > > depends_lib path:${prefix}/bin/foo:bar > > where "bar" is the preferred port for providing foo if it is not > already installed. > > The dependencies would have to be changed in all ports that currently > depend directly on teTeX. OK cool. A few questions then: - At what point do we think about making texlive the 'default' TeX port rather than teTeX? (We should, eventually.) - Seems like it would be more valuable to say "either this port or that port" rather than "depends on file", because there might be many many files that need to be supported. - Let's say I'm updating a port and want to make this change. How can I actually tell what file is the dependency (without delving into the makefiles)? Seems like I'd have to delve. JDO From boeyms at macports.org Wed Jan 9 21:59:06 2008 From: boeyms at macports.org (Boey Maun Suang) Date: Wed Jan 9 21:59:00 2008 Subject: Different dmgs for different felines In-Reply-To: References: <159ED350-ACF8-4629-BE90-C4C93291178D@macports.org> <11267.202.81.69.153.1198474096.squirrel@webmail.tuffmail.net> <3B2B99E9-1AF5-469B-8665-8AE7A80178BA@macports.org> <47752032.8080508@macports.org> <8F45516A-24C0-40D2-82B7-37E4CE9B7D8A@macports.org> <4775338F.9090107@macports.org> Message-ID: <34227.203.20.35.28.1199944746.squirrel@webmail.tuffmail.net> On Wed, January 9, 2008 8:14 am, Juan Manuel Palacios wrote: > Maun Suang, since you reported to me that you already got the Panther > dmg built, and that the errors you're experiencing (ui_prefix) > manifest themselves regardless of whether you install from the dmg or > from source, what would you say about uploading that dmg regardless of > the bug? Actually, I never built the Panther dmg precisely because the ui_prefix/ui_channels problem prevented me from accessing sysutils/MacPorts! (I not sure how I gave the impression that I had, but apologies for however it happened). Anyway, I've now created the Panther dmg by applying the patches from r32105 [1], r32212 [2], r32514 [3] and r32525 [4] after sysutils/MacPorts' patch phase; these patches were cherry-picked to ensure that the Panther dmg is as close as possible to the Tiger and Leopard ones. The resultant Panther dmg passes the tests in the "Create Release Disk Image(s)" section of base/portmgr/ReleaseProcess, with the caveat that daemondo isn't built on Panther (see the configure script test for CFNotificationCenterGetDarwinNotifyCenter(), which is only in 10.4 and later [5]) and thus doesn't need testing; I updated ReleaseProcess to reflect this in r32631. The dmg and checksums updates were uploaded in r32630, but I'll leave it to you as to when to restore the links to it from www.macports.org. By the way, Juan, /trunk/base/portmgr/dmg/postflight in the repository seems well out of sync with /branches/release_1_6/base/portmgr/dmg/postflight. Is that supposed to be the case? Kind regards, Maun Suang [1] http://trac.macosforge.org/projects/macports/changeset/32105 [2] http://trac.macosforge.org/projects/macports/changeset/32212 [3] http://trac.macosforge.org/projects/macports/changeset/32514 [4] http://trac.macosforge.org/projects/macports/changeset/32525 [5] http://developer.apple.com/documentation/CoreFoundation/Reference/CFNotificationCenterRef/Reference/reference.html#//apple_ref/c/func/CFNotificationCenterGetDarwinNotifyCenter -- Boey Maun Suang Email: boeyms@macports.org From ryandesign at macports.org Wed Jan 9 22:18:14 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Jan 9 22:18:48 2008 Subject: [32627] branches/release_1_6/base/portmgr/dmg/postflight In-Reply-To: <20080110053746.F3123838E82@beta.macosforge.org> References: <20080110053746.F3123838E82@beta.macosforge.org> Message-ID: jmpp, did you mean to change 32627, 32628 and 32629 only on the 1.6 branch and not in trunk? From jmpp at macports.org Wed Jan 9 22:55:05 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Wed Jan 9 22:53:09 2008 Subject: [32627] branches/release_1_6/base/portmgr/dmg/postflight In-Reply-To: References: <20080110053746.F3123838E82@beta.macosforge.org> Message-ID: On Jan 10, 2008, at 1:48 AM, Ryan Schmidt wrote: > jmpp, did you mean to change 32627, 32628 and 32629 only on the 1.6 > branch and not in trunk? > Yes. For an explanation why, see http://lists.macosforge.org/pipermail/macports-users/2008-January/008206.html Regards,... -jmpp From jmpp at macports.org Wed Jan 9 23:03:18 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Wed Jan 9 23:01:21 2008 Subject: Different dmgs for different felines In-Reply-To: <34227.203.20.35.28.1199944746.squirrel@webmail.tuffmail.net> References: <159ED350-ACF8-4629-BE90-C4C93291178D@macports.org> <11267.202.81.69.153.1198474096.squirrel@webmail.tuffmail.net> <3B2B99E9-1AF5-469B-8665-8AE7A80178BA@macports.org> <47752032.8080508@macports.org> <8F45516A-24C0-40D2-82B7-37E4CE9B7D8A@macports.org> <4775338F.9090107@macports.org> <34227.203.20.35.28.1199944746.squirrel@webmail.tuffmail.net> Message-ID: <55E54F18-8C5A-4A12-9408-CB918B393AB8@macports.org> On Jan 10, 2008, at 1:29 AM, Boey Maun Suang wrote: > On Wed, January 9, 2008 8:14 am, Juan Manuel Palacios wrote: > >> Maun Suang, since you reported to me that you already got the >> Panther >> dmg built, and that the errors you're experiencing (ui_prefix) >> manifest themselves regardless of whether you install from the dmg or >> from source, what would you say about uploading that dmg regardless >> of >> the bug? > > Actually, I never built the Panther dmg precisely because the > ui_prefix/ui_channels problem prevented me from accessing > sysutils/MacPorts! (I not sure how I gave the impression that I had, > but > apologies for however it happened). So, you installed MacPorts 1.6.0 from source on Panther and then with that installation attempted to build the dmg? Gotta love bugs while bootstrapping! ;-) I thought you had 1.5.2 or earlier installed and were working off that. But in any case,.... > > > Anyway, I've now created the Panther dmg by applying the patches from > r32105 [1], r32212 [2], r32514 [3] and r32525 [4] after sysutils/ > MacPorts' > patch phase; these patches were cherry-picked to ensure that the > Panther > dmg is as close as possible to the Tiger and Leopard ones. All these patches are minor and will shortly end up in the release_1_6 branch, so I don't think there's any problem in having them in this not-so-stock 1.6.0 Panther dmg. Thanks for the hard work! > The resultant > Panther dmg passes the tests in the "Create Release Disk Image(s)" > section > of base/portmgr/ReleaseProcess, with the caveat that daemondo isn't > built > on Panther (see the configure script test for > CFNotificationCenterGetDarwinNotifyCenter(), which is only in 10.4 and > later [5]) and thus doesn't need testing; I updated ReleaseProcess to > reflect this in r32631. Sure thing, thanks for adding the note to the ReleaseProcess file. > The dmg and checksums updates were uploaded in > r32630, but I'll leave it to you as to when to restore the links to it > from www.macports.org. Done! > > > By the way, Juan, /trunk/base/portmgr/dmg/postflight in the repository > seems well out of sync with > /branches/release_1_6/base/portmgr/dmg/postflight. Is that supposed > to be > the case? > Yes. See http://lists.macosforge.org/pipermail/macports-users/2008-January/008206.html for the explanation why. > Kind regards, > > > Maun Suang Regards,.... -jmpp From boeyms at macports.org Wed Jan 9 23:09:46 2008 From: boeyms at macports.org (Boey Maun Suang) Date: Wed Jan 9 23:09:40 2008 Subject: MacPorts 1.6.0 dmg now available for Panther (Mac OS X 10.3) Message-ID: <16386.202.81.69.153.1199948986.squirrel@webmail.tuffmail.net> Hi everyone, Firstly, apologies for cross-posting, but I wanted to make sure everyone gets this. This message is to notify all of our wonderful Panther-using MacPorts users that we've finally ironed out the bugs that were preventing MacPorts 1.6.0 from operating correctly on Panther, and have now uploaded a Panther dmg incorporating our fixes, which you can now download (you can fetch it directly [1], or go via the installation page of the MacPorts website [2]). A big thank you to Juan Manuel Palacios and Kevin Ballard for providing the fixes, to Chris Janton for confirming that one particular problem wasn't just with my build machine, and to all of the Panther users who reported the problems! For those Panther users who like installing MacPorts from source instead of from our dmgs, the 1.6.0 tarball doesn't yet incorporate the Panther fixes, but we'll be releasing a 1.6.1 update soon, so you should have to wait too long. If you're really keen, however, you can still do a 1.6.0 source install by applying a few patches from our repository. Those not interested can safely skip this bit, but if you are interested, here's what to do: === Start of patch instructions === 1. Download and extract the MacPorts tarball as normal (see the "Source Install" section of the MacPorts Guide [3]). 2. Download the changesets 32105 [4], 32212 [5], 32514 [6] and 32525 [7] from the MacPorts repository, copying or saving them to the "MacPorts 1.x.x" directory that the MacPorts tarball extracted itself into. If your browser displays the patches instead of saving them, use your browser's "File > Save As..." menu item -- they should save with filenames like "changeset_32105.diff". 3. At the command line, change into the directory as per the MacPorts Guide [3], but before running the "./configure" command as described there, run the following commands (one for each of the changeset files you saved above): % patch -p3 < changeset_32105.diff % patch -p3 < changeset_32212.diff % patch -p3 < changeset_32514.diff % patch -p3 < changeset_32525.diff 4. Follow the rest of the source install procedure as normal. === End of patch instructions === Don't worry, we won't be making you source installers get used to doing things like this! Once again, apologies to all our Panther users out there, and thanks for using MacPorts. Wishing you all a happy 2008, Boey Maun Suang [1] http://svn.macports.org/repository/macports/downloads/MacPorts-1.6.0/MacPorts-1.6.0-10.3-Panther.dmg [2] http://www.macports.org/install.php [3] http://guide.macports.org/#installing.source [4] http://trac.macosforge.org/projects/macports/changeset/32105?format=diff&new=32105 [5] http://trac.macosforge.org/projects/macports/changeset/32212?format=diff&new=32212 [6] http://trac.macosforge.org/projects/macports/changeset/32514?format=diff&new=32514 [7] http://trac.macosforge.org/projects/macports/changeset/32525?format=diff&new=32525 -- Boey Maun Suang (Boey is my surname) Email: boeyms@macports.org From jochen at fhi-berlin.mpg.de Thu Jan 10 00:20:37 2008 From: jochen at fhi-berlin.mpg.de (=?ISO-8859-1?Q?Jochen_K=FCpper?=) Date: Thu Jan 10 00:20:55 2008 Subject: [32618] trunk/dports/science/molden/Portfile In-Reply-To: <0CE96C06-969B-4495-B2D8-F9DFF7E734F4@macports.org> References: <20080109152203.2F037D8E046B@lists.macosforge.org> <0CE96C06-969B-4495-B2D8-F9DFF7E734F4@macports.org> Message-ID: Hi Ryan, please forward this to macports-dev. On 09.01.2008, at 21:55, Ryan Schmidt wrote: > On Jan 9, 2008, at 09:22, jochen@macports.org wrote: > >> Revision: 32618 >> http://trac.macosforge.org/projects/macports/changeset/ >> 32618 >> Author: jochen@macports.org >> Date: 2008-01-09 07:22:00 -0800 (Wed, 09 Jan 2008) >> >> Log Message: >> ----------- >> follow upstream stealth update >> >> Modified Paths: >> -------------- >> trunk/dports/science/molden/Portfile >> >> Modified: trunk/dports/science/molden/Portfile >> =================================================================== >> --- trunk/dports/science/molden/Portfile 2008-01-09 14:28:28 UTC >> (rev 32617) >> +++ trunk/dports/science/molden/Portfile 2008-01-09 15:22:00 UTC >> (rev 32618) >> @@ -13,15 +13,15 @@ >> >> name molden >> version 4.6 >> -revision 2 >> +revision 3 >> categories science graphics >> maintainers openmaintainer jochen >> master_sites ftp://ftp.cmbi.ru.nl/pub/molgraph/molden >> distname molden${version} >> dist_subdir molden-${version}_${revision} Please keep this in mind for some seconds;) >> -checksums md5 b52d66fc61f3d85abba94e36c14b5d85 \ >> - sha1 2faeea9f970d5430ab0d2863a7f59c1780c56d3e \ >> - rmd160 c21b9359e30f24942baa6e3b0dd412c793e3ad17 >> +checksums md5 f2d929fe96ab85a3f994557140f5dcbe \ >> + sha1 04cc6e32c1c8a79e54c02cfacdcddee4a64d08dc \ >> + rmd160 f11735e616afb7e6de7bd94bc8782068a9fb47bf > > Anyone who still has the old distfile on their hard drive will now > experience a checksum error when attempting to upgrade this port. > You should change the dist_subdir so that this problem does not > happen. Please add something like > > dist_subdir ${distname}/${version}_${revision} Already done... (You told me after the previous stealth upgrade.) Greetings, Jochen -- Einigkeit und Recht und Freiheit http://www.Jochen- Kuepper.de Libert?, ?galit?, Fraternit? GnuPG key: CC1B0B4D Sex, drugs and rock-n-roll -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080110/bdc72e63/PGP-0001.bin From ryandesign at macports.org Thu Jan 10 00:27:30 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Jan 10 00:28:04 2008 Subject: [32618] trunk/dports/science/molden/Portfile In-Reply-To: References: <20080109152203.2F037D8E046B@lists.macosforge.org> <0CE96C06-969B-4495-B2D8-F9DFF7E734F4@macports.org> Message-ID: <52788C30-BC97-4EDA-A83F-95A23D428424@macports.org> On Jan 10, 2008, at 02:20, Jochen K?pper wrote: > On 09.01.2008, at 21:55, Ryan Schmidt wrote: > >> On Jan 9, 2008, at 09:22, jochen@macports.org wrote: >> >>> Revision: 32618 >>> http://trac.macosforge.org/projects/macports/changeset/ >>> 32618 >>> Author: jochen@macports.org >>> Date: 2008-01-09 07:22:00 -0800 (Wed, 09 Jan 2008) >>> >>> Log Message: >>> ----------- >>> follow upstream stealth update >>> >>> Modified Paths: >>> -------------- >>> trunk/dports/science/molden/Portfile >>> >>> Modified: trunk/dports/science/molden/Portfile >>> =================================================================== >>> --- trunk/dports/science/molden/Portfile 2008-01-09 14:28:28 UTC >>> (rev 32617) >>> +++ trunk/dports/science/molden/Portfile 2008-01-09 15:22:00 UTC >>> (rev 32618) >>> @@ -13,15 +13,15 @@ >>> >>> name molden >>> version 4.6 >>> -revision 2 >>> +revision 3 >>> categories science graphics >>> maintainers openmaintainer jochen >>> master_sites ftp://ftp.cmbi.ru.nl/pub/molgraph/molden >>> distname molden${version} >>> dist_subdir molden-${version}_${revision} > > Please keep this in mind for some seconds;) > >>> -checksums md5 b52d66fc61f3d85abba94e36c14b5d85 \ >>> - sha1 2faeea9f970d5430ab0d2863a7f59c1780c56d3e \ >>> - rmd160 c21b9359e30f24942baa6e3b0dd412c793e3ad17 >>> +checksums md5 f2d929fe96ab85a3f994557140f5dcbe \ >>> + sha1 04cc6e32c1c8a79e54c02cfacdcddee4a64d08dc \ >>> + rmd160 f11735e616afb7e6de7bd94bc8782068a9fb47bf >> >> Anyone who still has the old distfile on their hard drive will now >> experience a checksum error when attempting to upgrade this port. >> You should change the dist_subdir so that this problem does not >> happen. Please add something like >> >> dist_subdir ${distname}/${version}_${revision} > > Already done... > (You told me after the previous stealth upgrade.) So sorry! I should have remembered. From jochen at fhi-berlin.mpg.de Thu Jan 10 00:50:36 2008 From: jochen at fhi-berlin.mpg.de (=?ISO-8859-1?Q?Jochen_K=FCpper?=) Date: Thu Jan 10 00:50:32 2008 Subject: [32618] trunk/dports/science/molden/Portfile In-Reply-To: <52788C30-BC97-4EDA-A83F-95A23D428424@macports.org> References: <20080109152203.2F037D8E046B@lists.macosforge.org> <0CE96C06-969B-4495-B2D8-F9DFF7E734F4@macports.org> <52788C30-BC97-4EDA-A83F-95A23D428424@macports.org> Message-ID: <549ABB61-1229-4F85-9A25-676FE170735F@fhi-berlin.mpg.de> Ryan, On 10.01.2008, at 09:27, Ryan Schmidt wrote: > So sorry! I should have remembered. No problem! I very much appreciate your involvement and constant alertness about all the little issues coming up. This really helps keeping MacPorts ports up on track! Greetings, Jochen -- Einigkeit und Recht und Freiheit http://www.Jochen- Kuepper.de Libert?, ?galit?, Fraternit? GnuPG key: CC1B0B4D Sex, drugs and rock-n-roll -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080110/0b365c7e/PGP.bin From eridius at macports.org Thu Jan 10 01:13:26 2008 From: eridius at macports.org (Kevin Ballard) Date: Thu Jan 10 01:13:21 2008 Subject: How embarrasing! In-Reply-To: <33A5BF6E-F37D-494B-A19C-E80C39AECFB8@macports.org> References: <33A5BF6E-F37D-494B-A19C-E80C39AECFB8@macports.org> Message-ID: What's the purpose of the symlink? I'm surprised we even have it. -Kevin Ballard On Jan 8, 2008, at 5:22 PM, Juan Manuel Palacios wrote: > > Warning: violation by /opt/local/man > Warning: MacPorts violates the layout of the ports-filesystems! > Warning: Please fix or indicate this misbehavior (if it is > intended), it will be an error in future releases! > > > Do you think it's safe to remove the ${prefix}/man symlink to $ > {prefix}/share/man in MacPorts sources? Or do we have to bite the > bullet and "destroot.violate_mtree yes"-justify ourselves to remove > the warning? > > > -jmpp > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev -- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com From ryandesign at macports.org Wed Jan 9 23:53:12 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Jan 10 01:40:25 2008 Subject: [32635] trunk/dports/games/lincity-ng/Portfile In-Reply-To: <20080110071122.BEFF583C636@beta.macosforge.org> References: <20080110071122.BEFF583C636@beta.macosforge.org> Message-ID: On Jan 10, 2008, at 01:11, pguyot@kallisys.net wrote: > @@ -27,6 +28,7 @@ > depends_lib lib:libX11.6:XFree86 \ > lib:libxml2:libxml2 \ > bin:sdl-config:libsdl \ > + port:pkgconfig \ > lib:libsdl_mixer:libsdl_mixer \ > lib:libsdl_image:libsdl_image \ > lib:libsdl_ttf:libsdl_ttf \ pkgconfig does not provide any libraries. pkgconfig should be listed as a build dependency, not a library dependency. From afb at macports.org Thu Jan 10 02:07:04 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu Jan 10 02:07:11 2008 Subject: [32635] trunk/dports/games/lincity-ng/Portfile In-Reply-To: References: <20080110071122.BEFF583C636@beta.macosforge.org> Message-ID: <43bccf65d47fae1ae433ecb4568769bc@macports.org> Ryan Schmidt wrote: > On Jan 10, 2008, at 01:11, pguyot@kallisys.net wrote: > >> @@ -27,6 +28,7 @@ >> depends_lib lib:libX11.6:XFree86 \ >> lib:libxml2:libxml2 \ >> bin:sdl-config:libsdl \ >> + port:pkgconfig \ >> lib:libsdl_mixer:libsdl_mixer \ >> lib:libsdl_image:libsdl_image \ >> lib:libsdl_ttf:libsdl_ttf \ > > pkgconfig does not provide any libraries. pkgconfig should be listed > as a build dependency, not a library dependency. build dependencies are checked _after_ configure, so they're useless for pkg-config... depends_lib List of dependencies to check before configure, build, destroot, install, and package targets. depends_build List of dependencies to check before build, destroot, install, and package targets. depends_run List of dependencies to check before destroot, install and package targets. So it's more about where you want the depend to be checked, than the "type" of it ? --anders From mww at macports.org Thu Jan 10 02:08:08 2008 From: mww at macports.org (Markus Weissmann) Date: Thu Jan 10 02:08:09 2008 Subject: How embarrasing! In-Reply-To: References: <33A5BF6E-F37D-494B-A19C-E80C39AECFB8@macports.org> Message-ID: On 10 Jan 2008, at 10:13, Kevin Ballard wrote: > What's the purpose of the symlink? I'm surprised we even have it. > When we agreed to have man pages in $prefix/share/man, we put this symlink in place to automagically fix all misbehaving ports and afair also because of some man search directory weirdness, where man expected the man pages in $PATH[n]/../man, if I recall correctly. Anyway: We should definitely remove it! Most ports behave well already and the rest should be found by the mtree checks. > > On Jan 8, 2008, at 5:22 PM, Juan Manuel Palacios wrote: > >> >> Warning: violation by /opt/local/man >> Warning: MacPorts violates the layout of the ports-filesystems! >> Warning: Please fix or indicate this misbehavior (if it is >> intended), it will be an error in future releases! >> >> >> Do you think it's safe to remove the ${prefix}/man symlink to $ >> {prefix}/share/man in MacPorts sources? Or do we have to bite the >> bullet and "destroot.violate_mtree yes"-justify ourselves to remove >> the warning? >> >> >> -jmpp >> >> _______________________________________________ >> macports-dev mailing list >> macports-dev@lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo/macports-dev > > -- > Kevin Ballard > http://kevin.sb.org > eridius@macports.org > http://www.tildesoft.com > > Regards, -Markus -- Dipl. Inf. (FH) Markus W. Weissmann http://www.macports.org/ http://www.mweissmann.de/ From ryandesign at macports.org Thu Jan 10 02:31:54 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Jan 10 02:32:28 2008 Subject: How embarrasing! In-Reply-To: References: <33A5BF6E-F37D-494B-A19C-E80C39AECFB8@macports.org> Message-ID: On Jan 10, 2008, at 04:08, Markus Weissmann wrote: > On 10 Jan 2008, at 10:13, Kevin Ballard wrote: > >>> On Jan 8, 2008, at 5:22 PM, Juan Manuel Palacios wrote: >>> >>>> Warning: violation by /opt/local/man >>>> Warning: MacPorts violates the layout of the ports-filesystems! >>>> Warning: Please fix or indicate this misbehavior (if it is >>>> intended), it will be an error in future releases! >>>> >>>> >>>> Do you think it's safe to remove the ${prefix}/man symlink to $ >>>> {prefix}/share/man in MacPorts sources? Or do we have to bite >>>> the bullet and "destroot.violate_mtree yes"-justify ourselves to >>>> remove the warning? >> >> What's the purpose of the symlink? I'm surprised we even have it. > > When we agreed to have man pages in $prefix/share/man, we put this > symlink in place to automagically fix all misbehaving ports and > afair also because of some man search directory weirdness, where > man expected the man pages in $PATH[n]/../man, if I recall correctly. > Anyway: We should definitely remove it! Most ports behave well > already and the rest should be found by the mtree checks. I would say we should definitely keep the symlink, because some ports still misbehave and install manpages into ${prefix}/man instead of $ {prefix}/share/man; the symlink helps these files go to the right place anyway. Three ports that I currently have installed do this, as I see. Also, I would say that it rather points out again that the existence of the MacPorts port is weird. (It's weird to use MacPorts to install MacPorts.) From ryandesign at macports.org Thu Jan 10 03:21:38 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Jan 10 03:22:12 2008 Subject: [32635] trunk/dports/games/lincity-ng/Portfile In-Reply-To: <43bccf65d47fae1ae433ecb4568769bc@macports.org> References: <20080110071122.BEFF583C636@beta.macosforge.org> <43bccf65d47fae1ae433ecb4568769bc@macports.org> Message-ID: On Jan 10, 2008, at 04:07, Anders F Bj?rklund wrote: > Ryan Schmidt wrote: > >> On Jan 10, 2008, at 01:11, pguyot@kallisys.net wrote: >> >>> @@ -27,6 +28,7 @@ >>> depends_lib lib:libX11.6:XFree86 \ >>> lib:libxml2:libxml2 \ >>> bin:sdl-config:libsdl \ >>> + port:pkgconfig \ >>> lib:libsdl_mixer:libsdl_mixer \ >>> lib:libsdl_image:libsdl_image \ >>> lib:libsdl_ttf:libsdl_ttf \ >> >> pkgconfig does not provide any libraries. pkgconfig should be >> listed as a build dependency, not a library dependency. > > build dependencies are checked _after_ configure, so they're > useless for pkg-config... > > depends_lib > List of dependencies to check before configure, build, > destroot, > install, and package targets. > > depends_build > List of dependencies to check before build, destroot, > install, and > package targets. > > depends_run > List of dependencies to check before destroot, install and > package > targets. > > So it's more about where you want the depend to be checked, than > the "type" of it ? Is that really how it is? If so, that's really nonintuitive. Is that really how we want base to behave? From jmpp at macports.org Thu Jan 10 05:58:07 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Thu Jan 10 05:56:09 2008 Subject: How embarrasing! In-Reply-To: References: <33A5BF6E-F37D-494B-A19C-E80C39AECFB8@macports.org> Message-ID: <1D27A380-3B59-4D94-928F-BA421F0BE3EF@macports.org> On Jan 10, 2008, at 6:01 AM, Ryan Schmidt wrote: > > On Jan 10, 2008, at 04:08, Markus Weissmann wrote: > >> On 10 Jan 2008, at 10:13, Kevin Ballard wrote: >> >>>> On Jan 8, 2008, at 5:22 PM, Juan Manuel Palacios wrote: >>>> >>>>> Warning: violation by /opt/local/man >>>>> Warning: MacPorts violates the layout of the ports-filesystems! >>>>> Warning: Please fix or indicate this misbehavior (if it is >>>>> intended), it will be an error in future releases! >>>>> >>>>> >>>>> Do you think it's safe to remove the ${prefix}/man symlink to $ >>>>> {prefix}/share/man in MacPorts sources? Or do we have to bite >>>>> the bullet and "destroot.violate_mtree yes"-justify ourselves to >>>>> remove the warning? >>> >>> What's the purpose of the symlink? I'm surprised we even have it. >> >> When we agreed to have man pages in $prefix/share/man, we put this >> symlink in place to automagically fix all misbehaving ports and >> afair also because of some man search directory weirdness, where >> man expected the man pages in $PATH[n]/../man, if I recall correctly. >> Anyway: We should definitely remove it! Most ports behave well >> already and the rest should be found by the mtree checks. > > I would say we should definitely keep the symlink, because some > ports still misbehave and install manpages into ${prefix}/man > instead of ${prefix}/share/man; the symlink helps these files go to > the right place anyway. Three ports that I currently have installed > do this, as I see. I'd favor removing it. It's been eons since we introduced it and I'd think by now it's acceptable telling stragglers "hey, we gave you too much time!" If ports start failing somehow due to the removal, them let them fail I say. I'm sure tickets for them will be filed. > Also, I would say that it rather points out again that the existence > of the MacPorts port is weird. (It's weird to use MacPorts to > install MacPorts.) Why is it weird? Bootstrapping may not be the easiest thing around, but there certainly are some projects out there that do it (hint: gcc). In any case, our bootsrapping needs are incredibly simple: as far as I know, the only thing the MacPorts port is used for is to build the dmgs, as it makes it incredibly easier, but nothing more (certainly not to *install* MacPorts). Regards,... -jmpp From takeshi at mac.com Thu Jan 10 06:14:31 2008 From: takeshi at mac.com (Takeshi Enomoto) Date: Thu Jan 10 06:14:26 2008 Subject: g95, Open MPI, HDF4, tcl-nap Message-ID: <44F7FFFE-0928-4ED4-8675-C4782EA47CC9@mac.com> Hi, It would be nice if someone could commit those tickets. Build failure of g95, in particular, is affetting a number of other ports. I submitted hdf4 and tcl-nap about a month ago. Thanks in advance, Takeshi g95: fixes libiconv problem Open MPI: Xgrid support HDF4.2r2 tcl-nap-6.4.0 From raimue at macports.org Thu Jan 10 06:42:11 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu Jan 10 06:42:20 2008 Subject: [32635] trunk/dports/games/lincity-ng/Portfile In-Reply-To: References: <20080110071122.BEFF583C636@beta.macosforge.org> <43bccf65d47fae1ae433ecb4568769bc@macports.org> Message-ID: <47862EC3.60007@macports.org> Ryan Schmidt wrote: > On Jan 10, 2008, at 04:07, Anders F Bj?rklund wrote: [depends_lib, depends_build, depends_run explanation] >> So it's more about where you want the depend to be checked, than the >> "type" of it ? > > Is that really how it is? If so, that's really nonintuitive. Is that > really how we want base to behave? Uh. I didn't even know they were checked at different phases! I thought depends_build is everything you need to build, but is not needed afterwards. So this should be checked before configure, build and destroot. I am also wondering why all dependencies are checked before the install phase. The Makefile or other build scripts of the software is only used up to destrooting. The install phase is all done by MacPorts, so there is no check needed anymore at this phase. Rainer From jmpp at macports.org Thu Jan 10 07:35:55 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Thu Jan 10 07:34:01 2008 Subject: Different dmgs for different felines In-Reply-To: References: <159ED350-ACF8-4629-BE90-C4C93291178D@macports.org> <11267.202.81.69.153.1198474096.squirrel@webmail.tuffmail.net> <3B2B99E9-1AF5-469B-8665-8AE7A80178BA@macports.org> <47752032.8080508@macports.org> <8F45516A-24C0-40D2-82B7-37E4CE9B7D8A@macports.org> <4775338F.9090107@macports.org> Message-ID: On Jan 8, 2008, at 5:08 PM, Ryan Schmidt wrote: > > On Jan 8, 2008, at 15:14, Juan Manuel Palacios wrote: > >> Even though I do believe that Universal building is a bit of a >> waste of space more often than not for most, I do buy into the >> simplicity such builds report for users that only have to go >> looking for a single download link. Maybe Markus could advise us on >> how we could achieve this through the MacPorts Portfile (sudo port >> dmg MacPorts)? > > Why don't we instead change the base Makefile so that it builds > universal (for 10.3.9 on PPC, for 10.4u on i386). That way, you get > a universal build no matter how you do it, whether through the > MacPorts Portfile, manually, or via selfupdate. This would also > address Rainer's concerns from earlier, which may be a valid point > (that selfupdate would make it non-universal again) That's a very good suggestion, Ryan, thanks! Nevertheless, as I'm a bit out of time for the moment, I can't help employing Open Source's most enjoyable principle: care to propose a patch? ;-) Regards,... -jmpp From meissnem at gmail.com Thu Jan 10 18:51:06 2008 From: meissnem at gmail.com (Matthew K. Meissner) Date: Thu Jan 10 18:51:01 2008 Subject: How embarrasing! In-Reply-To: <1D27A380-3B59-4D94-928F-BA421F0BE3EF@macports.org> References: <33A5BF6E-F37D-494B-A19C-E80C39AECFB8@macports.org> <1D27A380-3B59-4D94-928F-BA421F0BE3EF@macports.org> Message-ID: On Jan 10, 2008, at 7:58 AM, Juan Manuel Palacios wrote: > > On Jan 10, 2008, at 6:01 AM, Ryan Schmidt wrote: > >> >> On Jan 10, 2008, at 04:08, Markus Weissmann wrote: >> >>> On 10 Jan 2008, at 10:13, Kevin Ballard wrote: >>>> What's the purpose of the symlink? I'm surprised we even have it. If I remember correctly -- it was a long time ago -- the original purpose of the symlink was to use the "nearby" manpath searching described in man(1). Without the symlink, the user has to either modify the MANPATH env var or the /etc/man.conf file. Leopard added / etc/manpath.d as well. Personally, I despise the idea of the MacPorts installer mucking with my .profile at all -- PATH or MANPATH. I would find it even more distasteful for it to edit /etc/man.conf. And /etc/manpath.d is Leopard only. So I think the link should stay -- it's the easiest way to get man searching working -- as long as PATH is set correctly, MANPATH is set implicitly. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2419 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080110/e72e2425/smime.bin From ryandesign at macports.org Fri Jan 11 00:15:03 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri Jan 11 00:15:34 2008 Subject: tetex/texlive dependencies In-Reply-To: References: <16E5B12E-C2CD-49AA-91A2-089920BE2A65@macports.org> Message-ID: <356D3161-B877-420B-BA13-29151D154BC3@macports.org> I hoped someone else would have something to say on the topic, since I myself don't use any of this TeX software. But they haven't so I will. On Jan 9, 2008, at 18:03, John Owens wrote: > Ryan Schmidt writes: > >> If more than one port installs a binary foo, and either one is good >> enough, this could be specified in a portfile by saying >> >> depends_lib path:${prefix}/bin/foo:bar >> >> where "bar" is the preferred port for providing foo if it is not >> already installed. >> >> The dependencies would have to be changed in all ports that currently >> depend directly on teTeX. > > OK cool. A few questions then: > > - At what point do we think about making texlive the 'default' > TeX port rather than teTeX? (We should, eventually.) The first thing on the teTeX homepage is a "De-support notice" explaining there will be no further versions. Sounds like now would be a good time. You could contact the maintainers of the teTeX and texlive ports to see if they agree. If they do, then you can contact the maintainers of all the ports that currently declare a dependency on teTeX and work with them to change this to texlive. > - Seems like it would be more valuable to say "either this port > or that port" rather than "depends on file", because there > might be many many files that need to be supported. Perhaps. But MacPorts does not currently have any syntax for specifying that, and we've gotten along without it so far. The alternative that we currently have available is to specify that a port depends on a certain file existing, and if it does not, then install one particular port that provides that file. There might be another port (or ports) that could also provide that file, but the user would have to know about this and install that other port first. The dependent port that's specified should be the one that "most" users would want. > - Let's say I'm updating a port and want to make this change. > How can I actually tell what file is the dependency (without > delving into the makefiles)? Seems like I'd have to delve. Personally, I would just pick any important file (a binary perhaps, or a library) that both teTeX and texlive provide. I'm not familiar with TeX software, but take perl as an example. We now have ports perl5.8 and perl5.10 which (as far as I know) both install ${prefix}/ bin/perl (and if they don't, then assume they do for the sake of this example). Instead of specifying a dependency on "port:perl5.8" this could be changed to "path:${prefix}/bin/perl:perl5.8". This way, perl5.10's perl is used if it was already installed, and if it wasn't, perl5.8 gets installed. From rowue at digitalis.org Fri Jan 11 00:50:23 2008 From: rowue at digitalis.org (=?ISO-8859-1?Q?Rolf_W=FCrdemann?=) Date: Fri Jan 11 00:50:14 2008 Subject: Can someone commit? (gtkglext, gwyddion, qucs) Message-ID: <54106214-5333-47B0-BABA-A9CF395BCD35@digitalis.org> First: #13624 (http://trac.macosforge.org/projects/macports/ticket/13624) (Update of the Portfile for gtkglext, so it runs on Leopard also) after that: #13737 (http://trac.macosforge.org/projects/macports/ticket/13737) (Update of gwyddion, so gwyddion works on leoparf also (depend on #13624) If this both updates are commited, tickets: #13560 (http://trac.macosforge.org/projects/macports/ticket/13560) and #13517 (http://trac.macosforge.org/projects/macports/ticket/13517) can also be closed (dealing with same issues, so no commits of them please;) if you have some spare time after this, it would be fine to commit #13826 (http://trac.macosforge.org/projects/macports/ticket/13826) which is an update of qucs to 0.0.13 ;) If there is anything whch denies to Portfiles from getting committed, please let me know ;) Reg's Rolf -- Security is an illusion - Datasecurity twice Rolf W?rdemann - private: rowue@digitalis.org - office: rowue@crew-gmbh.de GnuPG fingerprint: 7383 348F 67D1 CD27 C90F DDD0 86A3 31B6 67F0 D02F jabber: rowue@digitalis.org 2F66A061 89BCA1A0 AD654827 6FD037FF 53C3E932 -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: Signierter Teil der Nachricht Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080111/1966af85/PGP-0001.bin From afb at macports.org Fri Jan 11 01:09:21 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Fri Jan 11 01:09:15 2008 Subject: tetex/texlive dependencies In-Reply-To: <356D3161-B877-420B-BA13-29151D154BC3@macports.org> References: <16E5B12E-C2CD-49AA-91A2-089920BE2A65@macports.org> <356D3161-B877-420B-BA13-29151D154BC3@macports.org> Message-ID: <18752df284f1af66031e94a683a66f9e@macports.org> Ryan Schmidt wrote: >> - Let's say I'm updating a port and want to make this change. >> How can I actually tell what file is the dependency (without >> delving into the makefiles)? Seems like I'd have to delve. > > Personally, I would just pick any important file (a binary perhaps, or > a library) that both teTeX and texlive provide. I'm not familiar with > TeX software, but take perl as an example. We now have ports perl5.8 > and perl5.10 which (as far as I know) both install ${prefix}/bin/perl > (and if they don't, then assume they do for the sake of this example). > Instead of specifying a dependency on "port:perl5.8" this could be > changed to "path:${prefix}/bin/perl:perl5.8". This way, perl5.10's > perl is used if it was already installed, and if it wasn't, perl5.8 > gets installed. Not sure if that is a great example. For now, _only_ perl5.8 provides the ${prefix}/bin/perl program and perl5.10 doesn't provide it. Should it follow the lead of python24/python25, where _none_ of the ports supplies ${prefix}/bin/python since r28120, then there wouldn't be *anything* providing a "perl" program (just like with "python", that defaults to using /usr/bin/python - unless the user runs python_select manually for a different version) but only versioned ones like "perl5.8.8" and "perl5.10.0". That this whole situation sucks, as you have to patch each and every #! line to use a versioned interpreter, is a different story... --anders From jmpp at macports.org Fri Jan 11 12:09:40 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Fri Jan 11 12:07:54 2008 Subject: Call for help testing release_1_6's revamped postflight script Message-ID: As some of you may have seen, I've been improving the postflight script in the release_1_6 branch with the feedback I've received so far, plus some other relevant fixes/improvements. I've tested it locally on both virgin and customized accounts, extensively, and have found it to work reliably so far. Nevertheless, we all know a single workstation is no high quality measure ;-) so I'd like to openly call for wider testing in case I'm missing bugs that my environment is not surfacing. If you're up for it, please grab the script off this URL [1] and take it for a hard ride on whatever environment you can think of. I've tried to bullet-proof it for straight forward functionality in a default environment and to be as polite and non-disruptive as possible in a non-default one. For those of you wondering what I'm considering as a default environment, have a read at: http://guide.macports.org/#installing.binary.postflight.details That, plus the fact that I only do it for bash and tcsh shells, and the latter only as legacy support for Jaguar and previous accounts (Maun Suang, can we add a note about this to the guide section above?). I'm somewhat considering removing such support because tweaking tcsh configuration file has proven a tad difficult: 1) It's not easy to invoke a non-interactive, login tcsh shell session. In a nutshell, so far it has proven impossible for me. This limits my ability to properly test the environment to figure out what I need to add and what I don't, which takes me onto 2) below 2) It's not clear to me whether I should write to ~/.tchsrc, ~/.cshrc or ~/.login (I've heard solid claims for all of them), barring my inability to properly test the environment; 3) barring 2), the form of the settings to be written varies ("set foo = bar" Vs. "setenv foo bar"); 4) I'm by no means a tcsh user, so all I can do is *guess* the best approach in unpleasant tcsh debugging sessions ;-) In my various instances of 4), plus very kind help from both Eric Hall and Wilfredo Sanchez at times, have lead me to a combination of ~/.tcshrc with "setenv foo bar" statements, which I think works fairly well. But still, I'd love some experienced tcsh using eyes if available to shed some more light on this aspect of the script (thinking a bit more about it, resolving 1) above would probably solve this entire problem). So, without any further ado, I'd appreciate as much help I can get in testing this script and, in case of failure, getting detailed reports if possible. Success reports are also of course welcomed! Regards,... -jmpp [1] http://trac.macports.org/projects/macports/browser/branches/release_1_6/base/portmgr/dmg/postflight?format=ra From ryandesign at macports.org Fri Jan 11 12:48:45 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri Jan 11 12:49:14 2008 Subject: [32697] trunk/dports/devel/icu/Portfile In-Reply-To: <20080111162502.E60888951C2@beta.macosforge.org> References: <20080111162502.E60888951C2@beta.macosforge.org> Message-ID: On Jan 11, 2008, at 10:25, nox@macports.org wrote: > Revision: 32697 > http://trac.macosforge.org/projects/macports/changeset/32697 > Author: nox@macports.org > Date: 2008-01-11 08:25:00 -0800 (Fri, 11 Jan 2008) > > Log Message: > ----------- > icu: Updated to 3.8.1. > > Modified Paths: > -------------- > trunk/dports/devel/icu/Portfile > > Modified: trunk/dports/devel/icu/Portfile > =================================================================== > --- trunk/dports/devel/icu/Portfile 2008-01-11 16:15:06 UTC (rev > 32696) > +++ trunk/dports/devel/icu/Portfile 2008-01-11 16:25:00 UTC (rev > 32697) > @@ -4,7 +4,8 @@ > > name icu > set my_name icu4c > -version 3.8 > +version 3.8.1 > +set doc_version [join [lrange [split ${version} .] 0 1] _] > categories devel > platforms darwin freebsd > maintainers nox > @@ -25,20 +26,36 @@ > distfiles [suffix ${distname}-src] > > checksums [suffix ${distname}-src] \ > - sha1 4370becc68eab7a01292db62e1649239b1732a5b \ > - md5 67cc2650fbcae4c8e3ba5ce4dda4b072 \ > - rmd160 e9a0105477b54e6d3f222bf7741a61058c70665b \ > - ${distname}-docs.zip \ > + md5 a827dbc9d909febd4ec39b90386868ba \ > + sha1 c2b933aee6741c28956f1b87dc514dee49b949aa \ > + rmd160 d297330ff0eb91bff5ac91e59188f1751f899032 \ > + ${my_name}-${doc_version}-docs.zip \ > + md5 677b218cbca2acc304b9771c63bd69bf \ > sha1 94b47b5dd88bce15dab608719efbbd405d15e912 \ > - md5 677b218cbca2acc304b9771c63bd69bf \ > rmd160 927f4466758722e958b90a2bae873b11da222e88 > > worksrcdir ${name}/source > set docdir ${prefix}/share/doc/${name}-${version} > > +post-patch { > + reinplace "s;install_name ;install_name ${prefix}/lib/;" $ > {worksrcpath}/config/mh-darwin > +} > + > +configure.cmd ./runConfigureICU MacOSX The portfile claims to work on the freebsd platform in addition to darwin. Is this configure.cmd appropriate on FreeBSD? > configure.args --mandir=${prefix}/share/man \ > --disable-samples > > +# ICU wants to build with -O3, let's do as it wants. > +configure.cflags-delete -O2 > + > +pre-configure { > + # The -delete statement above may lead to configure.cflags > variable being unset > + if {! [info exists configure.cflags]} { > + configure.cflags > + } > +} What you're doing here in the pre-configure phase, is this a MacPorts base bug that needs to be fixed? From vincent-opdarw at vinc17.org Fri Jan 11 13:09:57 2008 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Fri Jan 11 13:09:45 2008 Subject: tetex/texlive dependencies In-Reply-To: <18752df284f1af66031e94a683a66f9e@macports.org> References: <16E5B12E-C2CD-49AA-91A2-089920BE2A65@macports.org> <356D3161-B877-420B-BA13-29151D154BC3@macports.org> <18752df284f1af66031e94a683a66f9e@macports.org> Message-ID: <20080111210957.GB8113@prunille.vinc17.org> On 2008-01-11 10:09:21 +0100, Anders F Bj?rklund wrote: > Not sure if that is a great example. For now, _only_ perl5.8 provides > the ${prefix}/bin/perl program and perl5.10 doesn't provide it. Should > it follow the lead of python24/python25, where _none_ of the ports > supplies ${prefix}/bin/python since r28120, then there wouldn't be > *anything* providing a "perl" program (just like with "python", that > defaults to using /usr/bin/python - unless the user runs python_select > manually for a different version) but only versioned ones like > "perl5.8.8" and "perl5.10.0". That this whole situation sucks, as you > have to patch each and every #! line to use a versioned interpreter, is > a different story... While different python versions are incompatible, different perl versions should be compatible (there are very few backward incompatibilities, but modules based on them should be seen as buggy). So, I'd say that perl5.10 should completely replace perl5.8, i.e. it should provide ${prefix}/bin/perl, and if some modules ever fail with 5.10[*] and the bug can't easily be fixed, then the perl5.8 port could provide a variant without ${prefix}/bin/perl. [*] Also look at reports on CPAN, testers sometimes do wrong things! -- 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 Fri Jan 11 15:24:19 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri Jan 11 15:24:49 2008 Subject: [32715] trunk/doc-new/guide/xml/portfile-keywords.xml In-Reply-To: <20080111225123.02C628B01F0@beta.macosforge.org> References: <20080111225123.02C628B01F0@beta.macosforge.org> Message-ID: On Jan 11, 2008, at 16:51, markd@macports.org wrote: > - If an epoch is used it must must never be > decreased or reset > - to zero, because this would always cause a port version > comparison > - to be incorrect after a port upgrade. > + An epoch is not needed for most ports. If an epoch > is used it > + must never be decreased without updating the port's > version number; > + this will cause port version comparisons to be > incorrect. I was led to believe that an epoch should never be decreased, ever, once it has been added to a portfile, even if the port's version is increased. I understood that the epoch takes precedence over the version. Do you have new information to the contrary? From markd at macports.org Fri Jan 11 16:03:23 2008 From: markd at macports.org (markd@macports.org) Date: Fri Jan 11 16:02:13 2008 Subject: [32715] epochs and the guide / was .. portfile-keywords.xml Message-ID: >On Jan 11, 2008, at 16:51, markd@macports.org wrote: > >> - If an epoch is used it must must never be >> decreased or reset >> - to zero, because this would always cause a port version >> comparison >> - to be incorrect after a port upgrade. >> + An epoch is not needed for most ports. If an epoch >> is used it >> + must never be decreased without updating the port's >> version number; >> + this will cause port version comparisons to be >> incorrect. > >I was led to believe that an epoch should never be decreased, ever, >once it has been added to a portfile, even if the port's version is >increased. I understood that the epoch takes precedence over the >version. Do you have new information to the contrary? I don't think the FreeBSD Porter's handbook states it clearly, some parts I'd interpret as agreeing with your understanding and other parts seem to say otherwise. But then I don't know for sure that MacPorts works the same anyway. http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-naming.html#MAKEFILE-NAMING-REVEPOCH I think discussion from someone (I forget who) some time ago made me to think otherwise so I changed it when revising the section. But I'm not really sure. If could someone could find out one way or another it would be great to know for sure and document it. Mark From sfiera at macports.org Fri Jan 11 16:46:37 2008 From: sfiera at macports.org (Chris Pickel) Date: Fri Jan 11 16:47:06 2008 Subject: [32715] epochs and the guide / was .. portfile-keywords.xml In-Reply-To: References: Message-ID: <702A0DE9-06E0-497A-AA1F-66C990196B91@macports.org> On 11 Jan, 2008, at 19:03, markd@macports.org wrote: >> On Jan 11, 2008, at 16:51, markd@macports.org wrote: >>> - If an epoch is used it must must never be >>> decreased or reset >>> - to zero, because this would always cause a port version >>> comparison >>> - to be incorrect after a port upgrade. >>> + An epoch is not needed for most ports. If an epoch >>> is used it >>> + must never be decreased without updating the port's >>> version number; >>> + this will cause port version comparisons to be >>> incorrect. >> >> I was led to believe that an epoch should never be decreased, ever, >> once it has been added to a portfile, even if the port's version is >> increased. I understood that the epoch takes precedence over the >> version. Do you have new information to the contrary? > > I don't think the FreeBSD Porter's handbook states it clearly, some > parts > I'd interpret as agreeing with your understanding and other parts > seem to > say otherwise. But then I don't know for sure that MacPorts works the > same anyway. > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-naming.html#MAKEFILE-NAMING-REVEPOCH > > I think discussion from someone (I forget who) some time ago made me > to > think otherwise so I changed it when revising the section. But I'm > not > really sure. If could someone could find out one way or another it > would > be great to know for sure and document it. For an example of how MacPorts does it, see port:543 (in proc get_outdated_ports). In pseudo-code, it says roughly: if current_epoch != available_epoch use epoch as basis for comparison else if current_version != available_version use version as basis for comparison else use revision as basis for comparison This means that an epoch should never be removed, since if the epoch is different, it will always be used as the basis for comparison when listing outdated ports. Some of the basis for confusion might come from macports.tcl:1923 (in proc upgrade), where the pseudo-code is roughly: if current_version != available_version use version as basis for comparison else use revision as basis for comparison if current_epoch < available_epoch upgrade anyway Now that I've read it more thoroughly, this code actually *does* allow the epoch to be removed--eventually, once the updated version has been pushed out to everyone. Hrm. In other words, it seems that a port in which the epoch has been removed could still be upgraded (with e.g. `port upgrade active`), but would not be listed as outdated (and would not be upgraded with `port upgrade outdated`). That's actually a bit of a mess and might deserve its own topic of discussion. For now, I think it should be stated that an epoch cannot be removed; this is the only case in which we can currently guarantee consistent behavior. At the same time, we should change MacPorts' behavior to be consistent. I think the method from port(1) is better than the one from macports.tcl, since it's the only one in which we can guarantee upgrades correctly--even if it does force an extra line of cruft to hang around in Portfiles with epochs (all 20 of 'em!) Chris From markd at macports.org Fri Jan 11 19:22:03 2008 From: markd at macports.org (markd@macports.org) Date: Fri Jan 11 19:20:45 2008 Subject: epochs and the guide Message-ID: >or an example of how MacPorts does it, see port:543 (in proc >get_outdated_ports). In pseudo-code, it says roughly: > >?? if current_epoch != available_epoch >???? use epoch as basis for comparison >?? else if current_version != available_version >???? use version as basis for comparison >?? else >???? use revision as basis for comparison > >This means that an epoch should never be removed, since if the epoch >is different, it will always be used as the basis for comparison when >listing outdated ports. > >Some of the basis for confusion might come from macports.tcl:1923 (in >proc upgrade), where the pseudo-code is roughly: > >?? if current_version != available_version >???? use version as basis for comparison >?? else >???? use revision as basis for comparison >?? if current_epoch < available_epoch >???? upgrade anyway > >Now that I've read it more thoroughly, this code actually *does* allow >the epoch to be removed--eventually, once the updated version has been >pushed out to everyone. > >Hrm. > >In other words, it seems that a port in which the epoch has been >removed could still be upgraded (with e.g. `port upgrade active`), but >would not be listed as outdated (and would not be upgraded with `port >upgrade outdated`). > >That's actually a bit of a mess and might deserve its own topic of >discussion. For now, I think it should be stated that an epoch cannot >be removed; this is the only case in which we can currently guarantee >consistent behavior. > >At the same time, we should change MacPorts' behavior to be >consistent. I think the method from port(1) is better than the one >from macports.tcl, since it's the only one in which we can guarantee >upgrades correctly--even if it does force an extra line of cruft to >hang around in Portfiles with epochs (all 20 of 'em!) Chris, I changed the text to this based on what you said about current behavior. Let me know if it needs adjusting. ---------- An epoch is not needed for most ports. If an epoch is used it must never be decreased or removed even when a port's version is updated; this would cause port version comparisons to be incorrect since epochs take precedence over versions once epochs have been used. ---------- Mark From sfiera at macports.org Fri Jan 11 19:34:08 2008 From: sfiera at macports.org (Chris Pickel) Date: Fri Jan 11 19:33:54 2008 Subject: epochs and the guide In-Reply-To: References: Message-ID: <12912AAA-F8F5-4D12-8134-0C56E91D9CE1@macports.org> On 11 Jan, 2008, at 22:22, markd@macports.org wrote: >> That's actually a bit of a mess and might deserve its own topic of >> discussion. For now, I think it should be stated that an epoch cannot >> be removed; this is the only case in which we can currently guarantee >> consistent behavior. >> >> At the same time, we should change MacPorts' behavior to be >> consistent. I think the method from port(1) is better than the one >> from macports.tcl, since it's the only one in which we can guarantee >> upgrades correctly--even if it does force an extra line of cruft to >> hang around in Portfiles with epochs (all 20 of 'em!) > > I changed the text to this based on what you said about current > behavior. > Let me know if it needs adjusting. > > ---------- > An epoch is not needed for most ports. If an epoch is used it must > never > be decreased or removed even when a port's version is updated; this > would > cause port version comparisons to be incorrect since epochs take > precedence over versions once epochs have been used. > ---------- That sounds right for the current behavior. Maybe once others weigh in (or don't) we can have a consistent behavior to base the description off of, though. Chris From pguyot at kallisys.net Sat Jan 12 11:58:50 2008 From: pguyot at kallisys.net (Paul Guyot) Date: Sat Jan 12 11:58:18 2008 Subject: [32635] trunk/dports/games/lincity-ng/Portfile In-Reply-To: References: <20080110071122.BEFF583C636@beta.macosforge.org> <43bccf65d47fae1ae433ecb4568769bc@macports.org> Message-ID: Le 10 janv. 08 ? 12:21, Ryan Schmidt a ?crit : >> build dependencies are checked _after_ configure, so they're >> useless for pkg-config... >> >> depends_lib >> List of dependencies to check before configure, build, >> destroot, >> install, and package targets. >> >> depends_build >> List of dependencies to check before build, destroot, >> install, and >> package targets. >> >> depends_run >> List of dependencies to check before destroot, install >> and package >> targets. >> >> So it's more about where you want the depend to be checked, than >> the "type" of it ? > > Is that really how it is? If so, that's really nonintuitive. Is > that really how we want base to behave? It's really how it is. And indeed, it's really nonintuitive. Paul -- http://paul-guyot.com/ From ryandesign at macports.org Sat Jan 12 12:32:23 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat Jan 12 12:32:50 2008 Subject: [32730] trunk/dports/net In-Reply-To: <20080112200050.7A6048F7353@beta.macosforge.org> References: <20080112200050.7A6048F7353@beta.macosforge.org> Message-ID: <39C02004-DAB1-4CFA-A577-D1EC7A025B99@macports.org> On Jan 12, 2008, at 14:00, ecronin@macports.org wrote: > Revision: 32730 > http://trac.macosforge.org/projects/macports/changeset/32730 > Author: ecronin@macports.org > Date: 2008-01-12 12:00:48 -0800 (Sat, 12 Jan 2008) > > Log Message: > ----------- > New port. Closes #13619 [snip] > +configure {} You should use "use_configure no" instead of "configure {}" From loshea at gmail.com Sat Jan 12 19:17:15 2008 From: loshea at gmail.com (Luis O'Shea) Date: Sat Jan 12 19:16:58 2008 Subject: New port needs commit Message-ID: Could someone commit the new port for asymptote? See ticket #13249 (http://trac.macosforge.org/projects/macports/ticket/13249). Thanks, Luis From ryandesign at macports.org Sat Jan 12 19:59:59 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat Jan 12 20:00:25 2008 Subject: apache mirrors Message-ID: In base/src/port1.0/resources/fetch/mirror_sites.tcl we define the apache mirror sites this way: set portfetch::mirror_sites::sites(apache) { http://www.apache.org/dist/ http://archive.apache.org/dist/ http://apache.planetmirror.com.au/dist/ ftp://ftp.planetmirror.com/pub/apache/dist/ ftp://ftp.is.co.za/Apache/dist/ ftp://ftp.infoscience.co.jp/pub/net/apache/dist/ } But at http://www.apache.org/dist/ it says in bold letters Please do not download from apache.org! And at http://www.apache.org/dist/httpd/ it says Download from your nearest mirror site! Do not download from www.apache.org. Please use a mirror site to help us save apache.org bandwidth. There are dozens of mirrors available. Should we add these to our apache mirror sites list? They provide a randomized or perhaps load-balanced download CGI, e.g.: http://www.apache.org/dyn/closer.cgi/apr/apr-0.9.17.tar.bz2 but that doesn't redirect you to the file; it returns an HTML page which contains a link to download the file. We could write a wrapper PHP script for this and stick it on www.macports.org and use that as the first apache mirror download location. This would make better use of the available mirrors and only fall back to www.apache.org and the rest if the script fails for some reason. I'd be happy to write that script if it's decided it's a good idea. From afb at macports.org Sun Jan 13 02:15:27 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun Jan 13 02:15:24 2008 Subject: tetex/texlive dependencies In-Reply-To: <20080111210957.GB8113@prunille.vinc17.org> References: <16E5B12E-C2CD-49AA-91A2-089920BE2A65@macports.org> <356D3161-B877-420B-BA13-29151D154BC3@macports.org> <18752df284f1af66031e94a683a66f9e@macports.org> <20080111210957.GB8113@prunille.vinc17.org> Message-ID: <312bddbf82523d2f5d4db1753c061ec2@macports.org> Vincent Lefevre wrote: > While different python versions are incompatible, different perl > versions should be compatible (there are very few backward > incompatibilities, but modules based on them should be seen as buggy). > So, I'd say that perl5.10 should completely replace perl5.8, i.e. it > should provide ${prefix}/bin/perl, and if some modules ever fail with > 5.10[*] and the bug can't easily be fixed, then the perl5.8 port could > provide a variant without ${prefix}/bin/perl. You are right, although there's a lot of ports that are using "bin:perl:perl5.8" (or port:perl and then ${prefix}/bin/perl) that would probably be surprised when such a change is made... --anders From simon at ruderich.com Sun Jan 13 06:30:32 2008 From: simon at ruderich.com (Simon Ruderich) Date: Sun Jan 13 07:24:44 2008 Subject: New port needs commit In-Reply-To: References: Message-ID: <20080113143031.GA26535@ruderich.com> On Sat, Jan 12, 2008 at 10:17:15PM -0500, Luis O'Shea wrote: > Could someone commit the new port for asymptote? See ticket #13249 > (http://trac.macosforge.org/projects/macports/ticket/13249). > > Thanks, > > Luis Hi, I just committed it [1] with one minor change. I added a post-activate hook with calls mktexlsr to make sure asymptote is found. Can I add you as maintainer for this port? Thanks, Simon [1]: http://trac.macosforge.org/projects/macports/changeset/32802 -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080113/3f437f34/attachment.bin From rowue at digitalis.org Sun Jan 13 07:43:42 2008 From: rowue at digitalis.org (=?ISO-8859-1?Q?Rolf_W=FCrdemann?=) Date: Sun Jan 13 07:43:29 2008 Subject: Port update (qucs) needs to get commited Message-ID: Hi Could someone commit the update of qucs to 0.0.13? See Ticket: #13826 http://trac.macports.org/projects/macports/ticket/13826 Thanks, Rolf -- Security is an illusion - Datasecurity twice Rolf W?rdemann - private: rowue@digitalis.org - office: rowue@crew-gmbh.de GnuPG fingerprint: 7383 348F 67D1 CD27 C90F DDD0 86A3 31B6 67F0 D02F jabber: rowue@digitalis.org 2F66A061 89BCA1A0 AD654827 6FD037FF 53C3E932 -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: Signierter Teil der Nachricht Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080113/7ff0c8c2/PGP-0001.bin From rowue at digitalis.org Sun Jan 13 07:48:36 2008 From: rowue at digitalis.org (=?ISO-8859-1?Q?Rolf_W=FCrdemann?=) Date: Sun Jan 13 07:48:22 2008 Subject: Port Change (gtkglext) needs to get committed Message-ID: Hi ... the Changes of the Portfile for gtkglext needs to get committed. #13624 http://trac.macports.org/projects/macports/ticket/13624 The Maintainer seems to doesn't respond. After this is done, #13517 (http://trac.macports.org/projects/ macports/ticket/13517) can be closed (dealing with the same issue - gtkglext on leopard) Thanks, Rolf -- Security is an illusion - Datasecurity twice Rolf W?rdemann - private: rowue@digitalis.org - office: rowue@crew-gmbh.de GnuPG fingerprint: 7383 348F 67D1 CD27 C90F DDD0 86A3 31B6 67F0 D02F jabber: rowue@digitalis.org 2F66A061 89BCA1A0 AD654827 6FD037FF 53C3E932 -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: Signierter Teil der Nachricht Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080113/ed2fdec0/PGP.bin From loshea at gmail.com Sun Jan 13 10:59:00 2008 From: loshea at gmail.com (Luis O'Shea) Date: Sun Jan 13 10:58:46 2008 Subject: New port needs commit In-Reply-To: <20080113143031.GA26535@ruderich.com> References: <20080113143031.GA26535@ruderich.com> Message-ID: <5990292D-2735-45EC-ADFF-B39DB13C3500@gmail.com> On Jan 13, 2008, at 9:30 AM, Simon Ruderich wrote: > On Sat, Jan 12, 2008 at 10:17:15PM -0500, Luis O'Shea wrote: >> Could someone commit the new port for asymptote? See ticket #13249 >> (http://trac.macosforge.org/projects/macports/ticket/13249). >> >> Thanks, >> >> Luis > > Hi, > > I just committed it [1] with one minor change. I added a post- > activate hook with > calls mktexlsr to make sure asymptote is found. Thanks. Now that the port is committed I wanted to make sure it worked, but I have run into a problem. After the commit, I uninstalled asymptote, removed the reference to my local port hierarchy from sources.conf, and did a selfupdate. However port seemed to not find the new asymptote port: % port info asymptote Error: Port asymptote not found But ${prefix}/var/macports/sources/rsync.macports.org/release/ports/ graphics/asymptote/Portfile does exist. I tried deleting ${prefix}/ var/macports/sources/rsync.macports.org/release/ports/PortIndex and doing another selfupdate, but that did not help. What am I doing wrong? Thanks, Luis From jmpp at macports.org Sun Jan 13 11:18:23 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Sun Jan 13 11:16:33 2008 Subject: New port needs commit In-Reply-To: <5990292D-2735-45EC-ADFF-B39DB13C3500@gmail.com> References: <20080113143031.GA26535@ruderich.com> <5990292D-2735-45EC-ADFF-B39DB13C3500@gmail.com> Message-ID: <3B179DBD-019B-4A44-8F5A-E708E9CE903A@macports.org> On Jan 13, 2008, at 2:29 PM, Luis O'Shea wrote: > On Jan 13, 2008, at 9:30 AM, Simon Ruderich wrote: >> On Sat, Jan 12, 2008 at 10:17:15PM -0500, Luis O'Shea wrote: >>> Could someone commit the new port for asymptote? See ticket #13249 >>> (http://trac.macosforge.org/projects/macports/ticket/13249). >>> >>> Thanks, >>> >>> Luis >> >> Hi, >> >> I just committed it [1] with one minor change. I added a post- >> activate hook with >> calls mktexlsr to make sure asymptote is found. > > Thanks. > > Now that the port is committed I wanted to make sure it worked, but > I have run into a problem. > > After the commit, I uninstalled asymptote, removed the reference to > my local port hierarchy from sources.conf, and did a selfupdate. Why did you do that? What did the entry that you removed look like, and what lead you to the conclusion that you needed to remove it in the first place? > However port seemed to not find the new asymptote port: > > % port info asymptote > Error: Port asymptote not found > > But ${prefix}/var/macports/sources/rsync.macports.org/release/ports/ > graphics/asymptote/Portfile does exist. I tried deleting ${prefix}/ > var/macports/sources/rsync.macports.org/release/ports/PortIndex and > doing another selfupdate, but that did not help. Entries in sources.conf point MacPorts to a valid PortIndex file, from which ports and their info are gathered; if there are no entries in sources.conf, no PortIndex will be found (regardless of the file(s) actually existing on the local filesystem). In the case of a stock MacPorts intallation, the rsync://rsync.macports.org/release/ports/ URL is the only entry in the souces.conf file, and it gets mapped locally to ${prefix}/var/macports/sources/rsync.macports.org/release/ ports/PortIndex as you infer. Nevertheless, again, if you remove the entry from sources.conf the corresponding index will not be found by MacPorts. I'm curious as to what lead you to believe you needed to remove the entry, in case it's something in our documentation that's misleading you. In any case, the only thing you need to update your local ports tree and get fresh search results is put the entry back and issue a "selfupdate" regularly, plain and simple. Regards,... -jmpp From rowue at digitalis.org Sun Jan 13 11:19:47 2008 From: rowue at digitalis.org (=?ISO-8859-1?Q?Rolf_W=FCrdemann?=) Date: Sun Jan 13 11:19:35 2008 Subject: Fwd: New port needs commit References: Message-ID: <583AEB2C-2873-49AC-AB0A-CA1DDA50E38A@digitalis.org> Anfang der weitergeleiteten E-Mail: > Von: Rolf W?rdemann > Datum: 13. Januar 2008 20:03:18 MEZ > An: Luis O'Shea > Betreff: Re: New port needs commit > > > Am 13.01.2008 um 19:59 schrieb Luis O'Shea: > >> On Jan 13, 2008, at 9:30 AM, Simon Ruderich wrote: >>> On Sat, Jan 12, 2008 at 10:17:15PM -0500, Luis O'Shea wrote: >>>> Could someone commit the new port for asymptote? See ticket #13249 >>>> (http://trac.macosforge.org/projects/macports/ticket/13249). >>>> >>>> Thanks, >>>> >>>> Luis >>> >>> Hi, >>> >>> I just committed it [1] with one minor change. I added a post- >>> activate hook with >>> calls mktexlsr to make sure asymptote is found. >> >> Thanks. >> >> Now that the port is committed I wanted to make sure it worked, >> but I have run into a problem. >> >> After the commit, I uninstalled asymptote, removed the reference >> to my local port hierarchy from sources.conf, and did a >> selfupdate. However port seemed to not find the new asymptote port: >> >> % port info asymptote >> Error: Port asymptote not found >> >> But ${prefix}/var/macports/sources/rsync.macports.org/release/ >> ports/graphics/asymptote/Portfile does exist. I tried deleting $ >> {prefix}/var/macports/sources/rsync.macports.org/release/ports/ >> PortIndex and doing another selfupdate, but that did not help. >> >> What am I doing wrong? > > The Portindex is updated every 12 Hours, > so it will take a little time to see your Port in Macports ;) > >> >> Thanks, >> >> Luis >> > > Reg's > > Rolf >> _______________________________________________ >> macports-dev mailing list >> macports-dev@lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo/macports-dev > > -- > Security is an illusion - Datasecurity twice > Rolf W?rdemann - private: rowue@digitalis.org - office: > rowue@crew-gmbh.de > GnuPG fingerprint: 7383 348F 67D1 CD27 C90F DDD0 86A3 > 31B6 67F0 D02F > jabber: rowue@digitalis.org 2F66A061 89BCA1A0 AD654827 6FD037FF > 53C3E932 > > -- Security is an illusion - Datasecurity twice Rolf W?rdemann - private: rowue@digitalis.org - office: rowue@crew-gmbh.de GnuPG fingerprint: 7383 348F 67D1 CD27 C90F DDD0 86A3 31B6 67F0 D02F jabber: rowue@digitalis.org 2F66A061 89BCA1A0 AD654827 6FD037FF 53C3E932 -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: Signierter Teil der Nachricht Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080113/514ab74e/PGP.bin From markd at macports.org Sun Jan 13 12:11:41 2008 From: markd at macports.org (markd@macports.org) Date: Sun Jan 13 12:09:37 2008 Subject: Subject: [32751] net/dhcp startupitem Message-ID: Hi Blair, Executable startupitems are the preferred type. Daemondo can track pids automatically and reliably restart an application if it quits. See the guide on this: http://guide.macports.org/#reference.startupitems Given how startupitem executables work, I don't see an advantage to reverting to a "script" startupitem. Or is there something I am missing particular to dhcp? Mark >Log Message: >----------- >Use a startupitem method that uses dhcpd's PID file. >Modified Paths: >-------------- > trunk/dports/net/dhcp/Portfile > >Modified: trunk/dports/net/dhcp/Portfile >=================================================================== >--- trunk/dports/net/dhcp/Portfile 2008-01-13 03:07:29 UTC (rev >32750) >+++ trunk/dports/net/dhcp/Portfile 2008-01-13 03:35:29 UTC (rev >32751) >@@ -4,7 +4,7 @@ > > name dhcp > version 3.1.0 >-revision 1 >+revision 2 > categories net > description ISC dhcpd server > long_description ISC's Dynamic Host Configuration Protocol >Distribution \ >@@ -40,8 +40,9 @@ > configure.pre_args > > startupitem.create yes >-startupitem.name dhcpd >-startupitem.executable ${prefix}/sbin/dhcpd >+startupitem.start "${prefix}/sbin/dhcpd" >+startupitem.restart "/bin/kill -HUP \$(/bin/cat >${prefix}/var/run/dhcpd.pid)" >+startupitem.stop "/bin/kill -15 \$(/bin/cat >${prefix}/var/run/dhcpd.pid)" From blair at orcaware.com Sun Jan 13 12:20:34 2008 From: blair at orcaware.com (Blair Zajac) Date: Sun Jan 13 12:20:15 2008 Subject: Subject: [32751] net/dhcp startupitem In-Reply-To: References: Message-ID: <932D9BF6-4934-4DB7-8C96-C998FC2FBB97@orcaware.com> Hi Mark, I was seeing the following: 1) One dhcpd would start. 2) Every 10 seconds thereafter, another dhcpd would be started, but it couldn't bind to the port since the first one was running. It appears that the startupitem infrastructure wasn't keeping track of dhcpd running and deamonizing itself. I haven't read the guide yet. What do you suggest? Putting a -f to dhcpd so it stays in the foreground? Regards, Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies Subversion training, consulting and support http://www.orcaware.com/svn/ On Jan 13, 2008, at 12:11 PM, markd@macports.org wrote: > Hi Blair, > > Executable startupitems are the preferred type. Daemondo can track > pids > automatically and reliably restart an application if it quits. See > the > guide on this: > > http://guide.macports.org/#reference.startupitems > > Given how startupitem executables work, I don't see an advantage to > reverting to a "script" startupitem. Or is there something I am > missing > particular to dhcp? > > Mark > >> Log Message: >> ----------- >> Use a startupitem method that uses dhcpd's PID file. > >> Modified Paths: >> -------------- >> trunk/dports/net/dhcp/Portfile >> >> Modified: trunk/dports/net/dhcp/Portfile >> =================================================================== >> --- trunk/dports/net/dhcp/Portfile 2008-01-13 03:07:29 UTC (rev >> 32750) >> +++ trunk/dports/net/dhcp/Portfile 2008-01-13 03:35:29 UTC (rev >> 32751) >> @@ -4,7 +4,7 @@ >> >> name dhcp >> version 3.1.0 >> -revision 1 >> +revision 2 >> categories net >> description ISC dhcpd server >> long_description ISC's Dynamic Host Configuration Protocol >> Distribution \ >> @@ -40,8 +40,9 @@ >> configure.pre_args >> >> startupitem.create yes >> -startupitem.name dhcpd >> -startupitem.executable ${prefix}/sbin/dhcpd >> +startupitem.start "${prefix}/sbin/dhcpd" >> +startupitem.restart "/bin/kill -HUP \$(/bin/cat >> ${prefix}/var/run/dhcpd.pid)" >> +startupitem.stop "/bin/kill -15 \$(/bin/cat >> ${prefix}/var/run/dhcpd.pid)" > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev > From loshea at gmail.com Sun Jan 13 12:32:07 2008 From: loshea at gmail.com (Luis O'Shea) Date: Sun Jan 13 12:31:54 2008 Subject: New port needs commit In-Reply-To: <3B179DBD-019B-4A44-8F5A-E708E9CE903A@macports.org> References: <20080113143031.GA26535@ruderich.com> <5990292D-2735-45EC-ADFF-B39DB13C3500@gmail.com> <3B179DBD-019B-4A44-8F5A-E708E9CE903A@macports.org> Message-ID: >> After the commit, I uninstalled asymptote, removed the reference >> to my local port hierarchy from sources.conf, and did a selfupdate. > > > Why did you do that? What did the entry that you removed look > like, and what lead you to the conclusion that you needed to remove > it in the first place? My goal was to verify that the new asymptote Portfile functioned correctly. While I was developing the Portfile my sources.conf looked like file:///Users/luis/macports/ports rsync://rsync.macports.org/release/ports/ I assume that while the "file:///..." line precedes the "rsync:///...", port will pickup my copy of the Portfile rather than the newly committed one. So I removed the first line and did a selfupdate. Two questions: - What is the best description of the ports referenced by "file:///..."? I called it "my local port hierarchy", but I now think this might be confusing. (It might mean my *copy* of "rsync:// rsync.macports...".) - After developing a new Portfile, what is the best way to pick up the newly committed Portfile? Should I leave sources.conf as is, delete my Portfile (the one under "file:///...") and re-portindex? See below for the source of my thick-headedness. > >> However port seemed to not find the new asymptote port: >> >> % port info asymptote >> Error: Port asymptote not found >> >> But ${prefix}/var/macports/sources/rsync.macports.org/release/ >> ports/graphics/asymptote/Portfile does exist. I tried deleting $ >> {prefix}/var/macports/sources/rsync.macports.org/release/ports/ >> PortIndex and doing another selfupdate, but that did not help. > > > Entries in sources.conf point MacPorts to a valid PortIndex file, > from which ports and their info are gathered; if there are no > entries in sources.conf, no PortIndex will be found (regardless of > the file(s) actually existing on the local filesystem). In the case > of a stock MacPorts intallation, the rsync://rsync.macports.org/ > release/ports/ URL is the only entry in the souces.conf file, and > it gets mapped locally to ${prefix}/var/macports/sources/ > rsync.macports.org/release/ports/PortIndex as you infer. > Nevertheless, again, if you remove the entry from sources.conf the > corresponding index will not be found by MacPorts. > > I'm curious as to what lead you to believe you needed to remove > the entry, in case it's something in our documentation that's > misleading you. In any case, the only thing you need to update your > local ports tree and get fresh search results is put the entry back > and issue a "selfupdate" regularly, plain and simple. Duh! PortIndex is under version control -- I thought it was generated locally after a sync. Thanks! Luis From blair at orcaware.com Sun Jan 13 12:36:34 2008 From: blair at orcaware.com (Blair Zajac) Date: Sun Jan 13 12:36:15 2008 Subject: Subject: [32751] net/dhcp startupitem In-Reply-To: References: Message-ID: Hi Mark, The guild says this: "startupitem.executable. Specifies the name of the daemon to be run in the background. It may have multiple arguments, but they must be appropriate for a call to exec; arbitrary shell code may not be used." Should the actual daemon remain in the foreground so that the parent parent process can wait() on it? Should the daemon make a PID file in a known location? The guide could expand on this a bit. Regards, Blair On Jan 13, 2008, at 12:11 PM, markd@macports.org wrote: > Hi Blair, > > Executable startupitems are the preferred type. Daemondo can track > pids > automatically and reliably restart an application if it quits. See > the > guide on this: > > http://guide.macports.org/#reference.startupitems > > Given how startupitem executables work, I don't see an advantage to > reverting to a "script" startupitem. Or is there something I am > missing > particular to dhcp? > > Mark > >> Log Message: >> ----------- >> Use a startupitem method that uses dhcpd's PID file. > >> Modified Paths: >> -------------- >> trunk/dports/net/dhcp/Portfile >> >> Modified: trunk/dports/net/dhcp/Portfile >> =================================================================== >> --- trunk/dports/net/dhcp/Portfile 2008-01-13 03:07:29 UTC (rev >> 32750) >> +++ trunk/dports/net/dhcp/Portfile 2008-01-13 03:35:29 UTC (rev >> 32751) >> @@ -4,7 +4,7 @@ >> >> name dhcp >> version 3.1.0 >> -revision 1 >> +revision 2 >> categories net >> description ISC dhcpd server >> long_description ISC's Dynamic Host Configuration Protocol >> Distribution \ >> @@ -40,8 +40,9 @@ >> configure.pre_args >> >> startupitem.create yes >> -startupitem.name dhcpd >> -startupitem.executable ${prefix}/sbin/dhcpd >> +startupitem.start "${prefix}/sbin/dhcpd" >> +startupitem.restart "/bin/kill -HUP \$(/bin/cat >> ${prefix}/var/run/dhcpd.pid)" >> +startupitem.stop "/bin/kill -15 \$(/bin/cat >> ${prefix}/var/run/dhcpd.pid)" > -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies Subversion training, consulting and support http://www.orcaware.com/svn/ From blair at orcaware.com Sun Jan 13 12:42:30 2008 From: blair at orcaware.com (Blair Zajac) Date: Sun Jan 13 12:42:09 2008 Subject: Subject: [32751] net/dhcp startupitem In-Reply-To: References: Message-ID: <834DF00F-6BE8-4834-A27A-E1C3F2391758@orcaware.com> Mark, It works fine if I use this: startupitem.create yes startupitem.name dhcpd startupitem.executable ${prefix}/sbin/dhcpd -f startupitem.netchange yes How's that? Regards, Blair On Jan 13, 2008, at 12:36 PM, Blair Zajac wrote: > Hi Mark, > > The guild says this: > > "startupitem.executable. Specifies the name of the daemon to be run > in the background. It may have multiple arguments, but they must be > appropriate for a call to exec; arbitrary shell code may not be used." > > Should the actual daemon remain in the foreground so that the parent > parent process can wait() on it? Should the daemon make a PID file > in a known location? > > The guide could expand on this a bit. > > Regards, > Blair > > On Jan 13, 2008, at 12:11 PM, markd@macports.org wrote: > >> Hi Blair, >> >> Executable startupitems are the preferred type. Daemondo can track >> pids >> automatically and reliably restart an application if it quits. See >> the >> guide on this: >> >> http://guide.macports.org/#reference.startupitems >> >> Given how startupitem executables work, I don't see an advantage to >> reverting to a "script" startupitem. Or is there something I am >> missing >> particular to dhcp? >> >> Mark >> >>> Log Message: >>> ----------- >>> Use a startupitem method that uses dhcpd's PID file. >> >>> Modified Paths: >>> -------------- >>> trunk/dports/net/dhcp/Portfile >>> >>> Modified: trunk/dports/net/dhcp/Portfile >>> =================================================================== >>> --- trunk/dports/net/dhcp/Portfile 2008-01-13 03:07:29 UTC (rev >>> 32750) >>> +++ trunk/dports/net/dhcp/Portfile 2008-01-13 03:35:29 UTC (rev >>> 32751) >>> @@ -4,7 +4,7 @@ >>> >>> name dhcp >>> version 3.1.0 >>> -revision 1 >>> +revision 2 >>> categories net >>> description ISC dhcpd server >>> long_description ISC's Dynamic Host Configuration Protocol >>> Distribution \ >>> @@ -40,8 +40,9 @@ >>> configure.pre_args >>> >>> startupitem.create yes >>> -startupitem.name dhcpd >>> -startupitem.executable ${prefix}/sbin/dhcpd >>> +startupitem.start "${prefix}/sbin/dhcpd" >>> +startupitem.restart "/bin/kill -HUP \$(/bin/cat >>> ${prefix}/var/run/dhcpd.pid)" >>> +startupitem.stop "/bin/kill -15 \$(/bin/cat >>> ${prefix}/var/run/dhcpd.pid)" >> > > -- > Blair Zajac, Ph.D. > CTO, OrcaWare Technologies > > Subversion training, consulting and support > http://www.orcaware.com/svn/ > > From markd at macports.org Sun Jan 13 13:25:11 2008 From: markd at macports.org (markd@macports.org) Date: Sun Jan 13 13:23:05 2008 Subject: Subject: [32751] net/dhcp startupitem Message-ID: Blair, I see. That's fine then. I just wanted to be sure there was a reason for making it a script startupitem and there is. I'm cc'ing James (master of all things startupitem) just in case he knows why the executable startupitem type wasn't adequate in this case. It seems like it should have worked. Thanks for fixing the port. Mark >Hi Mark, > >I was seeing the following: > >1) One dhcpd would start. > >2) Every 10 seconds thereafter, another dhcpd would be started, but it >couldn't bind to the port since the first one was running. > >It appears that the startupitem infrastructure wasn't keeping track of >dhcpd running and deamonizing itself. > >I haven't read the guide yet.? What do you suggest?? Putting a -f to >dhcpd so it stays in the foreground? > >Regards, >Blair > >-- >Blair Zajac, Ph.D. >CTO, OrcaWare Technologies > >Subversion training, consulting and support >[ >https://owa016.msoutlookonline.net/owa/redir.aspx?URL=http%3a%2f%2fwww.orcaware.com%2fsvn%2f >]http://www.orcaware.com/svn/ > >On Jan 13, 2008, at 12:11 PM, markd@macports.org wrote: > >> Hi Blair, >> >> Executable startupitems are the preferred type.? Daemondo can track >> pids >> automatically and reliably restart an application if it quits.? See >> the >> guide on this: >> >> [ >https://owa016.msoutlookonline.net/owa/redir.aspx?URL=http%3a%2f%2fguide.macports.org%2f%23reference.startupitems >]http://guide.macports.org/#reference.startupitems >> >> Given how startupitem executables work, I don't see an advantage to >> reverting to a "script" startupitem.? Or is there something I am >> missing >> particular to dhcp? From markd at macports.org Sun Jan 13 13:25:11 2008 From: markd at macports.org (markd@macports.org) Date: Sun Jan 13 13:38:28 2008 Subject: Subject: [32751] net/dhcp startupitem Message-ID: >Mark, > >It works fine if I use this: > >startupitem.create????? yes >startupitem.name??????? dhcpd >startupitem.executable? ${prefix}/sbin/dhcpd -f >startupitem.netchange?? yes > >How's that? The startupitem executable is preferred if it works automatically I think; but if it doesn't for some reason at that point I see no obligation to prefer a workaround using the executable type to using the "script" type startupitem. So I think leaving it as you had it is fine; I can't comment on whether starting in foreground mode is a good method, but as I said under the circumstances your current solution is perfectly fine in my opinion. > > >On Jan 13, 2008, at 12:36 PM, Blair Zajac wrote: > >> Hi Mark, >> >> The guild says this: >> >> "startupitem.executable.? Specifies the name of the daemon to be run >> in the background. It may have multiple arguments, but they must be >> appropriate for a call to exec; arbitrary shell code may not be used." >> >> Should the actual daemon remain in the foreground so that the parent >> parent process can wait() on it?? Should the daemon make a PID file >> in a known location? >> >> The guide could expand on this a bit. I hope James is listening out there and can comment on this. I think if one really wanted to use an executable startupitem, I think statupitem.pidfile could be used and that particular use isn't documented, but probably because I didn't expect the need for it to ever occur, as it has for dhcp. But as I said, if startupitm executable doesn't work in default setup, then I see no further advantage in using it as opposed to a "script" startupitem. Thanks for giving this attention. Mark From jberry at macports.org Sun Jan 13 14:23:57 2008 From: jberry at macports.org (James Berry) Date: Sun Jan 13 14:23:46 2008 Subject: Subject: [32751] net/dhcp startupitem In-Reply-To: References: Message-ID: <98E0CD6D-C333-420A-815A-3E8611558251@macports.org> Hi Mark, So it looks like the bit magic that got this to work is the -f command, which basically tells dhcpd not to daemonize, which would be a good thing in our case, as the process of daemonizing would look to daemondo or launchd as if dhcpd were exiting, which would cause the constantly restarting behavior Blair described. The startupitem.name spec should be completely redundant and unneeded; the name will default to the name of the port, which is dhcpd, right? Does that answer your question? James On Jan 13, 2008, at 1:25 PM, markd@macports.org wrote: > Blair, > > I see. That's fine then. I just wanted to be sure there was a > reason for > making it a script startupitem and there is. I'm cc'ing James > (master of > all things startupitem) just in case he knows why the executable > startupitem type wasn't adequate in this case. It seems like it > should > have worked. Thanks for fixing the port. > > Mark On Jan 13, 2008, at 12:42 PM, Blair Zajac wrote: > Mark, > > It works fine if I use this: > > startupitem.create yes > startupitem.name dhcpd > startupitem.executable ${prefix}/sbin/dhcpd -f > startupitem.netchange yes > > How's that? > > >> Hi Mark, >> >> I was seeing the following: >> >> 1) One dhcpd would start. >> >> 2) Every 10 seconds thereafter, another dhcpd would be started, but >> it >> couldn't bind to the port since the first one was running. >> >> It appears that the startupitem infrastructure wasn't keeping track >> of >> dhcpd running and deamonizing itself. >> >> I haven't read the guide yet.? What do you suggest?? Putting a -f to >> dhcpd so it stays in the foreground? >> >> Regards, >> Blair >> >> -- >> Blair Zajac, Ph.D. >> CTO, OrcaWare Technologies >> >> Subversion training, consulting and support >> [ >> https://owa016.msoutlookonline.net/owa/redir.aspx?URL=http%3a%2f%2fwww.orcaware.com%2fsvn%2f >> ]http://www.orcaware.com/svn/ >> >> On Jan 13, 2008, at 12:11 PM, markd@macports.org wrote: >> >>> Hi Blair, >>> >>> Executable startupitems are the preferred type.? Daemondo can track >>> pids >>> automatically and reliably restart an application if it quits.? See >>> the >>> guide on this: >>> >>> [ >> https://owa016.msoutlookonline.net/owa/redir.aspx?URL=http%3a%2f%2fguide.macports.org%2f%23reference.startupitems >> ]http://guide.macports.org/#reference.startupitems >>> >>> Given how startupitem executables work, I don't see an advantage to >>> reverting to a "script" startupitem.? Or is there something I am >>> missing >>> particular to dhcp? > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev From raimue at macports.org Sun Jan 13 17:05:35 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun Jan 13 17:05:17 2008 Subject: New port needs commit In-Reply-To: <5990292D-2735-45EC-ADFF-B39DB13C3500@gmail.com> References: <20080113143031.GA26535@ruderich.com> <5990292D-2735-45EC-ADFF-B39DB13C3500@gmail.com> Message-ID: <478AB55F.1070004@macports.org> Luis O'Shea wrote: > After the commit, I uninstalled asymptote, removed the reference to my > local port hierarchy from sources.conf, and did a selfupdate. However > port seemed to not find the new asymptote port: > > % port info asymptote > Error: Port asymptote not found The PortIndex is regenerated and committed every 12 hours. Your port is in the repository, but hasn't made it into PortIndex at that time. As port info takes all infos from the PortIndex, it could not be found. Rainer From blair at orcaware.com Sun Jan 13 17:07:45 2008 From: blair at orcaware.com (Blair Zajac) Date: Sun Jan 13 17:07:28 2008 Subject: New port needs commit In-Reply-To: <478AB55F.1070004@macports.org> References: <20080113143031.GA26535@ruderich.com> <5990292D-2735-45EC-ADFF-B39DB13C3500@gmail.com> <478AB55F.1070004@macports.org> Message-ID: <478AB5E1.6080103@orcaware.com> Rainer M?ller wrote: > Luis O'Shea wrote: >> After the commit, I uninstalled asymptote, removed the reference to my >> local port hierarchy from sources.conf, and did a selfupdate. However >> port seemed to not find the new asymptote port: >> >> % port info asymptote >> Error: Port asymptote not found > > The PortIndex is regenerated and committed every 12 hours. Your port is > in the repository, but hasn't made it into PortIndex at that time. As > port info takes all infos from the PortIndex, it could not be found. By the way, one can cd into your ${prefix}/var/macports/sources/rsync.macports.org/release/ports and run portindex by hand to update the index. Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies Subversion training, consulting and support http://www.orcaware.com/svn/ From jmpp at macports.org Sun Jan 13 18:35:47 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Sun Jan 13 18:34:08 2008 Subject: New port needs commit In-Reply-To: References: <20080113143031.GA26535@ruderich.com> <5990292D-2735-45EC-ADFF-B39DB13C3500@gmail.com> <3B179DBD-019B-4A44-8F5A-E708E9CE903A@macports.org> Message-ID: On Jan 13, 2008, at 4:02 PM, Luis O'Shea wrote: >>> After the commit, I uninstalled asymptote, removed the reference >>> to my local port hierarchy from sources.conf, and did a selfupdate. >> >> >> Why did you do that? What did the entry that you removed look >> like, and what lead you to the conclusion that you needed to remove >> it in the first place? > > My goal was to verify that the new asymptote Portfile functioned > correctly. While I was developing the Portfile my sources.conf > looked like > > file:///Users/luis/macports/ports > rsync://rsync.macports.org/release/ports/ I see. > > > I assume that while the "file:///..." line precedes the > "rsync:///...", port will pickup my copy of the Portfile rather than > the newly committed one. So I removed the first line and did a > selfupdate. My mistake, I replied under the assumption you were working with a stock MacPorts setup, which is just the rsync URL in sources.conf. Nevertheless, it's still not necessary to remove (or comment out, for that matter) your first entry pointing to your local/development ports tree to test whether or not your submission made it to our rsync server, since "search", "info" and similar actions parse all PortIndexes found; say you have nmap in both your local and in the selfupdate'd tree, then (assuming both trees are in sources.conf, of course) "port search nmap" should give you two results for that particular port and port(1)'s -d flag reveals where each one belongs. > > > Two questions: > - What is the best description of the ports referenced by > "file:///..."? I called it "my local port hierarchy", but I now > think this might be confusing. (It might mean my *copy* of "rsync:// > rsync.macports...".) It could be whatever. It could be a read-only subversion checkout of the ports tree, as an alternative to rsync; it could be your local development tree; it could be both or maybe even something completely different ;-). The way I see it, the only two things that differentiate a "file:.//" entry from the "rsync://" one is that: 1) access to the latter is limited to rsync only, while access to the former can vary; 2) we, The MacPorts Project, maintain the latter by refreshing it periodically (every 30 minutes) and even regen'ing its index every 12 hours, while the former is entirely up to you... with one sole exception: if the path for a file:// URL points to an svn checkout of subversion's /trunk/dports, then "port sync" also takes care of updating it. > > - After developing a new Portfile, what is the best way to pick up > the newly committed Portfile? Should I leave sources.conf as is, > delete my Portfile (the one under "file:///...") and re-portindex? Depends on what you mean by "pick up". If by that you mean distribute to other users, then yes, they have to wait until the new index is passed to the rsync server that feeds the sync & selfupdate operations. If on the other hand you mean local usage, then all you have to do is cd into your dports dir and regen the index manually. In short, as you can surely see, "seeing" the port basically pivots on the index, so refreshing that is what you have to keep in mind. > > > See below for the source of my thick-headedness. > >> >>> However port seemed to not find the new asymptote port: >>> >>> % port info asymptote >>> Error: Port asymptote not found >>> >>> But ${prefix}/var/macports/sources/rsync.macports.org/release/ >>> ports/graphics/asymptote/Portfile does exist. I tried deleting $ >>> {prefix}/var/macports/sources/rsync.macports.org/release/ports/ >>> PortIndex and doing another selfupdate, but that did not help. >> >> >> Entries in sources.conf point MacPorts to a valid PortIndex file, >> from which ports and their info are gathered; if there are no >> entries in sources.conf, no PortIndex will be found (regardless of >> the file(s) actually existing on the local filesystem). In the case >> of a stock MacPorts intallation, the rsync://rsync.macports.org/ >> release/ports/ URL is the only entry in the souces.conf file, and >> it gets mapped locally to ${prefix}/var/macports/sources/ >> rsync.macports.org/release/ports/PortIndex as you infer. >> Nevertheless, again, if you remove the entry from sources.conf the >> corresponding index will not be found by MacPorts. >> >> I'm curious as to what lead you to believe you needed to remove >> the entry, in case it's something in our documentation that's >> misleading you. In any case, the only thing you need to update your >> local ports tree and get fresh search results is put the entry back >> and issue a "selfupdate" regularly, plain and simple. > > Duh! PortIndex is under version control -- I thought it was > generated locally after a sync. Yes, every 12 hours on the box of one of our kind committers, Daniel; from there it is committed to svn and then, on the next half hour, pushed to the rsync server, from where both "sync" and "selfupdate" will pull it in. Have a look at the /trunk/base/portmgr/jobs dir in subversion for more info if you're interested. > > > Thanks! > > Luis Regards,... -jmpp From nox at macports.org Sun Jan 13 18:34:48 2008 From: nox at macports.org (N_Ox) Date: Sun Jan 13 18:34:42 2008 Subject: [32697] trunk/dports/devel/icu/Portfile In-Reply-To: References: <20080111162502.E60888951C2@beta.macosforge.org> Message-ID: <482300C6-C5A3-4582-B2A1-E18DEEB6C09C@macports.org> Le 11 janv. 08 ? 21:48, Ryan Schmidt a ?crit : > On Jan 11, 2008, at 10:25, nox@macports.org wrote: > >> Revision: 32697 >> http://trac.macosforge.org/projects/macports/changeset/ >> 32697 >> Author: nox@macports.org >> Date: 2008-01-11 08:25:00 -0800 (Fri, 11 Jan 2008) >> >> Log Message: >> ----------- >> icu: Updated to 3.8.1. >> >> Modified Paths: >> -------------- >> trunk/dports/devel/icu/Portfile >> >> Modified: trunk/dports/devel/icu/Portfile >> =================================================================== >> --- trunk/dports/devel/icu/Portfile 2008-01-11 16:15:06 UTC (rev >> 32696) >> +++ trunk/dports/devel/icu/Portfile 2008-01-11 16:25:00 UTC (rev >> 32697) >> @@ -4,7 +4,8 @@ >> >> name icu >> set my_name icu4c >> -version 3.8 >> +version 3.8.1 >> +set doc_version [join [lrange [split ${version} .] 0 1] _] >> categories devel >> platforms darwin freebsd >> maintainers nox >> @@ -25,20 +26,36 @@ >> distfiles [suffix ${distname}-src] >> >> checksums [suffix ${distname}-src] \ >> - sha1 4370becc68eab7a01292db62e1649239b1732a5b \ >> - md5 67cc2650fbcae4c8e3ba5ce4dda4b072 \ >> - rmd160 >> e9a0105477b54e6d3f222bf7741a61058c70665b \ >> - ${distname}-docs.zip \ >> + md5 a827dbc9d909febd4ec39b90386868ba \ >> + sha1 c2b933aee6741c28956f1b87dc514dee49b949aa \ >> + rmd160 d297330ff0eb91bff5ac91e59188f1751f899032 \ >> + ${my_name}-${doc_version}-docs.zip \ >> + md5 677b218cbca2acc304b9771c63bd69bf \ >> sha1 94b47b5dd88bce15dab608719efbbd405d15e912 \ >> - md5 677b218cbca2acc304b9771c63bd69bf \ >> rmd160 927f4466758722e958b90a2bae873b11da222e88 >> >> worksrcdir ${name}/source >> set docdir ${prefix}/share/doc/${name}-${version} >> >> +post-patch { >> + reinplace "s;install_name ;install_name ${prefix}/lib/;" $ >> {worksrcpath}/config/mh-darwin >> +} >> + >> +configure.cmd ./runConfigureICU MacOSX > > The portfile claims to work on the freebsd platform in addition to > darwin. Is this configure.cmd appropriate on FreeBSD? > I don't think so, thank you for noticing. I'll fix that. >> configure.args --mandir=${prefix}/share/man \ >> --disable-samples >> >> +# ICU wants to build with -O3, let's do as it wants. >> +configure.cflags-delete -O2 >> + >> +pre-configure { >> + # The -delete statement above may lead to configure.cflags >> variable being unset >> + if {! [info exists configure.cflags]} { >> + configure.cflags >> + } >> +} > > What you're doing here in the pre-configure phase, is this a > MacPorts base bug that needs to be fixed? > I think it is, or maybe not, as I've some uncommited patches wandering around in my base/ repos. I'll look into it. -- Anthony Ramine, the "Ports tree cleaning Maestro". From raimue at macports.org Sun Jan 13 19:09:02 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun Jan 13 19:08:42 2008 Subject: New port needs commit In-Reply-To: References: <20080113143031.GA26535@ruderich.com> <5990292D-2735-45EC-ADFF-B39DB13C3500@gmail.com> <3B179DBD-019B-4A44-8F5A-E708E9CE903A@macports.org> Message-ID: <478AD24E.8080106@macports.org> Luis O'Shea wrote: > Two questions: > - What is the best description of the ports referenced by > "file:///..."? I called it "my local port hierarchy", but I now think > this might be confusing. (It might mean my *copy* of > "rsync://rsync.macports...".) I would call it an "overlay". A term coming from my Gentoo experience. It describes, what it really is. Another ports tree which adds ports (which may lay over ports from the official ports tree). Rainer From boeyms at macports.org Sun Jan 13 21:32:44 2008 From: boeyms at macports.org (Boey Maun Suang) Date: Sun Jan 13 21:32:28 2008 Subject: [32715] trunk/doc-new/guide/xml/portfile-keywords.xml In-Reply-To: References: <20080111225123.02C628B01F0@beta.macosforge.org> Message-ID: <21F958C2-3905-453D-A04D-42CB326B45C3@macports.org> On 12/01/2008, at 10:24 AM, Ryan Schmidt wrote: > I was led to believe that an epoch should never be decreased, ever, > once it has been added to a portfile, even if the port's version is > increased. I understood that the epoch takes precedence over the > version. I'm pretty sure that that's still true; I haven't seen that part of the code altered. I noticed last year that netpbm failed to upgrade on my machine until I forced it because somebody removed the epoch line in an earlier revision, in which case epoch is assumed to be zero. Kind regards, Maun Suang -- Boey Maun Suang (Boey is my surname) Email: boeyms at macports dot org From jmpp at macports.org Sun Jan 13 21:47:59 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Sun Jan 13 21:46:08 2008 Subject: Call for help testing 1.6.1 revamped postflight script Message-ID: <72557479-00D7-42D9-838A-F64F8CF1EBBF@macports.org> As some of you may have seen, I've been improving the postflight script in the release_1_6 branch with the feedback I've received so far, plus some other relevant fixes/improvements. The final product is what will be in the 1.6.1 pkg installer, which I plan to upload to our website to replace the buggy 1.6.0 installers. I've tested it locally on both virgin and customized accounts, extensively, and have found it to work reliably so far. I'd now like to openly call for some wider testing in case I'm missing bugs that my environment is not surfacing. If you're up for it, please grab the script off this URL [1] and take it for a hard ride on whatever environment you can think of. I've tried to bullet-proof it for straight forward functionality in a default environment and to be as polite and non-disruptive as possible in a non-default one. Standard disclaimer applies about this code potentially having bugs that may disrupt your working environment, so do not use on a production machine/account if you can't afford any errors. For those of you wondering what I'm considering as a default environment, have a read at: http://guide.macports.org/#installing.binary.postflight.details That, plus the fact that I only do it for bash and tcsh shells, and the latter only as legacy support for Jaguar and previous accounts. I'm somewhat considering removing such support because tweaking tcsh configuration file has proven a tad difficult: 1) It's not easy to invoke a non-interactive, login tcsh shell session. In a nutshell, so far it has proven impossible for me. This limits my ability to properly test the environment to figure out what I need to add and what I don't, which takes me onto 2) below 2) It's not entirely clear to me whether I should write to ~/.tchsrc, ~/.cshrc or ~/.login (I've heard solid claims for all of them), barring my inability to properly test the environment; 3) barring 2), the form of the settings to be written varies ("set foo = bar" Vs. "setenv foo bar"); 4) I'm by no means a tcsh user, so all I can do is *guess* the best approach in unpleasant tcsh debugging sessions ;-) Various instances of 4), plus very kind help from both Eric Hall and Wilfredo Sanchez at times, have lead me to a combination of ~/.tcshrc with "setenv foo bar" statements, which I think works fairly well. But still, I'd love some experienced tcsh using eyes if available to shed some more light on this aspect of the script (thinking a bit more about it, resolving 1) above would probably solve this entire problem). So, without any further ado, I'd appreciate as much help I can get in testing this script and, in case of failure, getting detailed reports if possible. Success reports are also of course welcomed! Regards,... -jmpp [1] http://trac.macports.org/projects/macports/browser/branches/release_1_6/base/portmgr/dmg/postflight?format=ra From jmpp at macports.org Sun Jan 13 21:57:18 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Sun Jan 13 21:55:28 2008 Subject: Call for help testing 1.6.1 revamped postflight script In-Reply-To: <72557479-00D7-42D9-838A-F64F8CF1EBBF@macports.org> References: <72557479-00D7-42D9-838A-F64F8CF1EBBF@macports.org> Message-ID: <7DFFD3DA-35AB-4ECA-9BF2-B3BB39D5E372@macports.org> Sorry, meant to send this to macports-users ;-) But some testing from this audience wouldn't hurt either :-P -jmpp On Jan 14, 2008, at 1:17 AM, Juan Manuel Palacios wrote: > > As some of you may have seen, I've been improving the postflight > script in the release_1_6 branch with the feedback I've received so > far, plus some other relevant fixes/improvements. The final product > is what will be in the 1.6.1 pkg installer, which I plan to upload > to our website to replace the buggy 1.6.0 installers. > > I've tested it locally on both virgin and customized accounts, > extensively, and have found it to work reliably so far. I'd now like > to openly call for some wider testing in case I'm missing bugs that > my environment is not surfacing. > > If you're up for it, please grab the script off this URL [1] and > take it for a hard ride on whatever environment you can think of. > I've tried to bullet-proof it for straight forward functionality in > a default environment and to be as polite and non-disruptive as > possible in a non-default one. > > Standard disclaimer applies about this code potentially having bugs > that may disrupt your working environment, so do not use on a > production machine/account if you can't afford any errors. > > For those of you wondering what I'm considering as a default > environment, have a read at: > > http://guide.macports.org/#installing.binary.postflight.details > > That, plus the fact that I only do it for bash and tcsh shells, and > the latter only as legacy support for Jaguar and previous accounts. > I'm somewhat considering removing such support because tweaking tcsh > configuration file has proven a tad difficult: > > 1) It's not easy to invoke a non-interactive, login tcsh shell > session. In a nutshell, so far it has proven impossible for me. This > limits my ability to properly test the environment to figure out > what I need to add and what I don't, which takes me onto 2) below > 2) It's not entirely clear to me whether I should write to > ~/.tchsrc, ~/.cshrc or ~/.login (I've heard solid claims for all of > them), barring my inability to properly test the environment; > 3) barring 2), the form of the settings to be written varies ("set > foo = bar" Vs. "setenv foo bar"); > 4) I'm by no means a tcsh user, so all I can do is *guess* the best > approach in unpleasant tcsh debugging sessions ;-) > > Various instances of 4), plus very kind help from both Eric Hall > and Wilfredo Sanchez at times, have lead me to a combination of > ~/.tcshrc with "setenv foo bar" statements, which I think works > fairly well. But still, I'd love some experienced tcsh using eyes if > available to shed some more light on this aspect of the script > (thinking a bit more about it, resolving 1) above would probably > solve this entire problem). > > So, without any further ado, I'd appreciate as much help I can get > in testing this script and, in case of failure, getting detailed > reports if possible. Success reports are also of course welcomed! > > Regards,... > > > -jmpp > > > [1] http://trac.macports.org/projects/macports/browser/branches/release_1_6/base/portmgr/dmg/postflight?format=ra > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev From ryandesign at macports.org Mon Jan 14 00:44:03 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Jan 14 00:44:27 2008 Subject: [32862] trunk/dports/devel/codeblocks-devel/Portfile In-Reply-To: <20080114075019.61B8A98E5C9@beta.macosforge.org> References: <20080114075019.61B8A98E5C9@beta.macosforge.org> Message-ID: <2F9B29E5-EE10-42F4-B542-84D1B3AEC13A@macports.org> On Jan 14, 2008, at 01:50, afb@macports.org wrote: > Revision: 32862 > http://trac.macosforge.org/projects/macports/changeset/32862 > Author: afb@macports.org > Date: 2008-01-13 23:50:17 -0800 (Sun, 13 Jan 2008) > > Log Message: > ----------- > move from trunk, to a revision You mean "move from HEAD of trunk to a revision of trunk" right? From afb at macports.org Mon Jan 14 01:00:04 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon Jan 14 00:59:53 2008 Subject: [32862] trunk/dports/devel/codeblocks-devel/Portfile In-Reply-To: <2F9B29E5-EE10-42F4-B542-84D1B3AEC13A@macports.org> References: <20080114075019.61B8A98E5C9@beta.macosforge.org> <2F9B29E5-EE10-42F4-B542-84D1B3AEC13A@macports.org> Message-ID: <48332a8545dd0127839c6428cbfcca16@macports.org> Ryan Schmidt wrote: >> Log Message: >> ----------- >> move from trunk, to a revision > > You mean "move from HEAD of trunk to a revision of trunk" right? Correct, terminology between CVS/SVN/GIT/etc is confusing me... Anyway, it used to build from tip'o'trunk directly - but now will build the 20080113 "Nightly Build", until updated again. See also http://forums.codeblocks.org/index.php?board=20.0 -anders From milosh at macports.org Mon Jan 14 01:18:11 2008 From: milosh at macports.org (Emmanuel Hainry) Date: Mon Jan 14 01:17:53 2008 Subject: tetex/texlive dependencies In-Reply-To: <356D3161-B877-420B-BA13-29151D154BC3@macports.org> References: <16E5B12E-C2CD-49AA-91A2-089920BE2A65@macports.org> <356D3161-B877-420B-BA13-29151D154BC3@macports.org> Message-ID: <20080114091811.GA4002@weetamoe.loria.fr> Citando Ryan Schmidt : > I hoped someone else would have something to say on the topic, since I > myself don't use any of this TeX software. But they haven't so I will. I have something to say. > On Jan 9, 2008, at 18:03, John Owens wrote: > >> Ryan Schmidt writes: >> >>> If more than one port installs a binary foo, and either one is good >>> enough, this could be specified in a portfile by saying >>> >>> depends_lib path:${prefix}/bin/foo:bar >>> >>> where "bar" is the preferred port for providing foo if it is not >>> already installed. >>> >>> The dependencies would have to be changed in all ports that currently >>> depend directly on teTeX. >> >> OK cool. A few questions then: >> >> - At what point do we think about making texlive the 'default' >> TeX port rather than teTeX? (We should, eventually.) > > The first thing on the teTeX homepage is a "De-support notice" > explaining there will be no further versions. Sounds like now would be a > good time. You could contact the maintainers of the teTeX and texlive > ports to see if they agree. If they do, then you can contact the > maintainers of all the ports that currently declare a dependency on teTeX > and work with them to change this to texlive. I am the maintainer of the texlive package (with openmaintainer) and since the port exists, the only bugs reported were "does not compile in leopard" (which is now solved) and "a lex file is not understood by macports' lex on ppc" (which was reported and corrected by Simon). So It seems to me texlive *2007* is stable enough. More, it is the same package that is used in openBSD ports and pkgsrc so if there are bugs, they should also occur for them. On the other side, I don't have leopard, my mac is an old powerbook ppc with little ram (and I use it less and less) hence I cannot test deeply this package, neither correct bugs or feature requests*. So I would encourage anybody interested in tex to join in maintainership. Especially when texlive 2008 will appear. > >> - Seems like it would be more valuable to say "either this port >> or that port" rather than "depends on file", because there >> might be many many files that need to be supported. > > Perhaps. But MacPorts does not currently have any syntax for specifying > that, and we've gotten along without it so far. The alternative that we > currently have available is to specify that a port depends on a certain > file existing, and if it does not, then install one particular port that > provides that file. There might be another port (or ports) that could > also provide that file, but the user would have to know about this and > install that other port first. The dependent port that's specified should > be the one that "most" users would want. At the moment, what dependent ports will check for is a texmf tree (provided by texlive_texmf-minimal and some binaries (latex, pdflatex, mktexlsr...). So the best dependency scheme would probably be bin:latex:texlive. So that people with tetex who do not care to have the latest distribution can live with teTeX (which works well). I am in favor of replacing dependencies from teTeX to texlive where it is relevant. *: for example build of xetex, xdvipdfmx... xetex is a part of texlive and a distinct port in macports. But I disabled it in texlive as it failed to build and there are reports that the xetex port does not build with texlive... Best regards, Emmanuel -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080114/c2d37343/attachment-0001.bin From rowue at digitalis.org Mon Jan 14 01:46:05 2008 From: rowue at digitalis.org (=?ISO-8859-1?Q?Rolf_W=FCrdemann?=) Date: Mon Jan 14 01:45:46 2008 Subject: (Mass) Update for gtkglext on leopard? Message-ID: <7F62EB59-D107-4147-8F53-EF6B2A168A5A@digitalis.org> Hi everybody .... as you (perhaps) now, there is a linking problem with gtkglext on leopard that is fixed (#13624) ... the maintainer doesn't react, so I would send him an email and wait 72 hours before commiting the update. (after sign in for commiter is done) but all applications using gtkglxt have to get updated too (#13737) Soo - what should I do? Wait for all maintainers (if avail) to change the portfiles? - Do an automatic mass update? (Some shell script which appends the portfiles and commits them (one by one))? Write all maintainers to change their portfiles? The documentation state this problem as an exception to the rules of changing only one file per time/wait for the maintainers... what is your opinion/recommandation? Reg's Rolf -- Security is an illusion - Datasecurity twice Rolf W?rdemann - private: rowue@digitalis.org - office: rowue@crew-gmbh.de GnuPG fingerprint: 7383 348F 67D1 CD27 C90F DDD0 86A3 31B6 67F0 D02F jabber: rowue@digitalis.org 2F66A061 89BCA1A0 AD654827 6FD037FF 53C3E932 -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: Signierter Teil der Nachricht Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080114/67713fe4/PGP.bin From ryandesign at macports.org Mon Jan 14 02:06:15 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Jan 14 02:06:38 2008 Subject: tetex/texlive dependencies In-Reply-To: <20080114091811.GA4002@weetamoe.loria.fr> References: <16E5B12E-C2CD-49AA-91A2-089920BE2A65@macports.org> <356D3161-B877-420B-BA13-29151D154BC3@macports.org> <20080114091811.GA4002@weetamoe.loria.fr> Message-ID: <9369365D-EBDF-4569-9AD7-E53D6E64D595@macports.org> On Jan 14, 2008, at 03:18, Emmanuel Hainry wrote: >>>> If more than one port installs a binary foo, and either one is >>>> good enough, this could be specified in a portfile by saying >>>> >>>> depends_lib path:${prefix}/bin/foo:bar >>>> >>>> where "bar" is the preferred port for providing foo if it is not >>>> already installed. >>>> >>>> The dependencies would have to be changed in all ports that >>>> currently depend directly on teTeX. >>> >>> - Seems like it would be more valuable to say "either this port >>> or that port" rather than "depends on file", because there >>> might be many many files that need to be supported. >> >> Perhaps. But MacPorts does not currently have any syntax for >> specifying >> that, and we've gotten along without it so far. The alternative >> that we >> currently have available is to specify that a port depends on a >> certain >> file existing, and if it does not, then install one particular >> port that >> provides that file. There might be another port (or ports) that could >> also provide that file, but the user would have to know about this >> and >> install that other port first. The dependent port that's specified >> should >> be the one that "most" users would want. > > At the moment, what dependent ports will check for is a texmf tree > (provided by texlive_texmf-minimal and some binaries (latex, pdflatex, > mktexlsr...). So the best dependency scheme would probably be > bin:latex:texlive. So that people with tetex who do not care to have > the latest distribution can live with teTeX (which works well). Using something like "bin:latex:texlive" is discouraged because a latex binary outside of the MacPorts prefix would satisfy the dependency, but we don't want it to; we only want latex binaries installed by MacPorts to be detected[1]. Therefore, "path:${prefix}/ bin/latex:texlive" should be used instead. [1] http://trac.macosforge.org/projects/macports/wiki/ FAQ#WhyisMacPortsusingitsownlibraries From milosh at macports.org Mon Jan 14 02:26:16 2008 From: milosh at macports.org (Emmanuel Hainry) Date: Mon Jan 14 02:25:57 2008 Subject: tetex/texlive dependencies In-Reply-To: <9369365D-EBDF-4569-9AD7-E53D6E64D595@macports.org> References: <16E5B12E-C2CD-49AA-91A2-089920BE2A65@macports.org> <356D3161-B877-420B-BA13-29151D154BC3@macports.org> <20080114091811.GA4002@weetamoe.loria.fr> <9369365D-EBDF-4569-9AD7-E53D6E64D595@macports.org> Message-ID: <20080114102616.GA4972@weetamoe.loria.fr> Citando Ryan Schmidt : > On Jan 14, 2008, at 03:18, Emmanuel Hainry wrote: >> >> At the moment, what dependent ports will check for is a texmf tree >> (provided by texlive_texmf-minimal and some binaries (latex, pdflatex, >> mktexlsr...). So the best dependency scheme would probably be >> bin:latex:texlive. So that people with tetex who do not care to have >> the latest distribution can live with teTeX (which works well). > > Using something like "bin:latex:texlive" is discouraged because a latex > binary outside of the MacPorts prefix would satisfy the dependency, but > we don't want it to; we only want latex binaries installed by MacPorts to > be detected[1]. Therefore, "path:${prefix}/bin/latex:texlive" should be > used instead. I had the impression macports only searched for binaries and libraries in system paths and macports path, which is coherent with it only passing by default include from /usr/include, /usr/local/include and ${prefix}/include (or is it also a mistake on my part?). And since mac Tex distributions install in strange paths (including the architecture of your machine), it should not be found. However you are right that this "path" checking is the safest. Emmanuel From ryandesign at macports.org Mon Jan 14 02:52:30 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Jan 14 02:52:53 2008 Subject: [32733] trunk/dports/perl/p5-xml-sax-expat/Portfile In-Reply-To: <20080112200825.578958F7EAD@beta.macosforge.org> References: <20080112200825.578958F7EAD@beta.macosforge.org> Message-ID: <4F0F8421-D78B-4F41-8BEF-F37D83050108@macports.org> On Jan 12, 2008, at 14:08, pguyot@kallisys.net wrote: > +post-activate { > + system "cd ${worksrcpath} && ${build.cmd} install_sax_expat" > +} Why is something being built after the activate phase? Doesn't this mean that these items won't go into the destroot, won't show up in "port contents" and won't get uninstalled by "port uninstall"? From n.oxyde at gmail.com Mon Jan 14 06:50:37 2008 From: n.oxyde at gmail.com (N_Ox) Date: Mon Jan 14 06:50:45 2008 Subject: [32733] trunk/dports/perl/p5-xml-sax-expat/Portfile In-Reply-To: <4F0F8421-D78B-4F41-8BEF-F37D83050108@macports.org> References: <20080112200825.578958F7EAD@beta.macosforge.org> <4F0F8421-D78B-4F41-8BEF-F37D83050108@macports.org> Message-ID: <22C9FE85-7C91-46B7-B0B0-634B6E3AEE3C@gmail.com> Le 14 janv. 08 ? 11:52, Ryan Schmidt a ?crit : > On Jan 12, 2008, at 14:08, pguyot@kallisys.net wrote: > >> +post-activate { >> + system "cd ${worksrcpath} && ${build.cmd} install_sax_expat" >> +} > > Why is something being built after the activate phase? Doesn't this > mean that these items won't go into the destroot, won't show up in > "port contents" and won't get uninstalled by "port uninstall"? > Nope, see p5-xml-sax: post-activate { if {! [file isfile ${perl5.lib}/XML/SAX/ParserDetails.ini]} { system {perl -MXML::SAX -e "XML::SAX->add_parser(q (XML::SAX::PurePerl))->save_parsers()"} } } Every Perl XML parser writes to this file. There's something about not overwritting this file on update in p5- xml-sax; otherwise it may restore XML::SAX::PurePerl as the default parser (which as the name says, is in pure perl therefore a lot slower than the expat one). The "install_sax_expat" Makefile target does the same thing as the p5- xml-sax post-activate stage. Regards, -- Anthony Ramine, the "Ports tree cleaning Maestro". From ryandesign at macports.org Mon Jan 14 13:27:44 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Jan 14 13:28:05 2008 Subject: [32900] trunk/dports/devel/libffi/Portfile In-Reply-To: <20080114212155.1525D9D94A2@beta.macosforge.org> References: <20080114212155.1525D9D94A2@beta.macosforge.org> Message-ID: <81F46C07-59D3-4330-AB51-6C1A06EB9797@macports.org> On Jan 14, 2008, at 15:21, pguyot@kallisys.net wrote: > name libffi > version 2.1 > -revision 20040426 > +revision 20040426_1 I didn't think the revision was allowed to be anything but an increasing integer. From pguyot at kallisys.net Mon Jan 14 13:35:55 2008 From: pguyot at kallisys.net (Paul Guyot) Date: Mon Jan 14 13:35:31 2008 Subject: [32900] trunk/dports/devel/libffi/Portfile In-Reply-To: <81F46C07-59D3-4330-AB51-6C1A06EB9797@macports.org> References: <20080114212155.1525D9D94A2@beta.macosforge.org> <81F46C07-59D3-4330-AB51-6C1A06EB9797@macports.org> Message-ID: Le 14 janv. 08 ? 22:27, Ryan Schmidt a ?crit : > On Jan 14, 2008, at 15:21, pguyot@kallisys.net wrote: > >> name libffi >> version 2.1 >> -revision 20040426 >> +revision 20040426_1 > > I didn't think the revision was allowed to be anything but an > increasing integer. Was it? I'm not even sure of what this date meant in the first place. I changed it because I'm not sure that libffi files that are downloaded from the checkout are the same than those that were part of the now gone PyObjC 1.4 archive. Paul From ryandesign at macports.org Mon Jan 14 14:42:34 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Jan 14 14:49:37 2008 Subject: documentation: project.xml Message-ID: <534DF6A1-CDD4-4FA2-8274-A3909FC8DEAC@macports.org> Cc: The reporter should enter his or her email address and the maintainer's email address to notify both parties when updates to the ticket occur. This is important, because Trac currently only sends emails to addresses on the Cc list, not to the reporter or the assignee. Multiple emails should be separated with a comma (i.e. you@example.org, maintainer@macports.org). To get the maintainer email address use port info portname. This is not true anymore. Trac now automatically emails the reporter and the assignee. A ticket should be assigned to the port's maintainer if possible, and the assignee and maintainer do not need to appear in the Cc line. However if the maintainer does not appear in the assignee drop-down menu, then the maintainer should be listed in the Cc field. From simon at ruderich.com Mon Jan 14 14:32:20 2008 From: simon at ruderich.com (Simon Ruderich) Date: Mon Jan 14 16:29:46 2008 Subject: tetex/texlive dependencies In-Reply-To: <9369365D-EBDF-4569-9AD7-E53D6E64D595@macports.org> References: <16E5B12E-C2CD-49AA-91A2-089920BE2A65@macports.org> <356D3161-B877-420B-BA13-29151D154BC3@macports.org> <20080114091811.GA4002@weetamoe.loria.fr> <9369365D-EBDF-4569-9AD7-E53D6E64D595@macports.org> Message-ID: <20080114223220.GA28838@ruderich.com> Hi, I just checked which ports are using TeTeX. Quite a few. Nomaintainer: - advi - cfengine - gnustep-make-docs - kdegraphics3 - latex2html - latex2man - lcdf-typetools - maxima - py-pyx - revtex - t1lib - tex-cm-super - tex-fourier-gutenberg - tex-utopia - css@macports.org: doxygen - dan.kelley@dal.ca: gri - eridius@macports.org: caml-pcre - gwright@macports.org: TeXmacs cadabra DoCon breqn lhs2tex - jmpp@macports.org: latex2rtf - jochen@macports.org: gsl - marcuscalhounlopez@mac.com: sml-mode.el - mas@macports.org: mftrace - milosh@macports.org: rubber - minskim@bawi.org: latex-mk - mww@macports.org: tetex-rechnung - pguyot@kallisys.net: dvipdfmx - pguyot@kallisys.net: gnuplot - pguyot@kallisys.net: tex-tipa xdvipdfmx XeTeX - reilles@loria.fr: auxtex - reilles@loria.fr: bibtex2html - stechert@macports.org: octave - tristan@cs.dartmouth.edu: BibTex gtamacfonts - vincent-opdarw@vinc17.org: pari I think the best would be to mail all of them and ask if they can update their port to texlive. The other ports should be tested and then updated to texlive (and maybe also updated). What do you think? Simon -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080114/b693fcec/attachment-0001.bin From dluke at geeklair.net Mon Jan 14 17:10:00 2008 From: dluke at geeklair.net (Daniel J.Luke) Date: Mon Jan 14 17:09:47 2008 Subject: Macworld anyone? Message-ID: Anyone else attending macworld and interested in possibly hanging out (and possibly chatting about macports) at some point? I can probably meet up with people on Tues. or Wed. if anyone is interested. -- Daniel J. Luke From ecronin at macports.org Mon Jan 14 20:34:08 2008 From: ecronin at macports.org (Eric Cronin) Date: Mon Jan 14 20:34:12 2008 Subject: tetex/texlive dependencies In-Reply-To: <20080114091811.GA4002@weetamoe.loria.fr> References: <16E5B12E-C2CD-49AA-91A2-089920BE2A65@macports.org> <356D3161-B877-420B-BA13-29151D154BC3@macports.org> <20080114091811.GA4002@weetamoe.loria.fr> Message-ID: <2C23B5C0-902D-4A92-A17E-1B57064E418C@macports.org> On Jan 14, 2008, at 4:18 AM, Emmanuel Hainry wrote: > > I am the maintainer of the texlive package (with openmaintainer) and > since the port exists, the only bugs reported were "does not compile > in > leopard" (which is now solved) and "a lex file is not understood by > macports' lex on ppc" (which was reported and corrected by Simon). > So It > seems to me texlive *2007* is stable enough. More, it is the same > package that is used in openBSD ports and pkgsrc so if there are bugs, > they should also occur for them. > > On the other side, I don't have leopard, my mac is an old powerbook > ppc > with little ram (and I use it less and less) hence I cannot test > deeply > this package, neither correct bugs or feature requests*. So I would > encourage anybody interested in tex to join in maintainership. > Especially when texlive 2008 will appear. I exercise some of the configurations you don't (leopard, intel, plenty of disk/mips; 10.3, ppc) so I'm happy to help either implicitly through openmaintainer or explicitly. I have considerably less experience when it comes to *TeX innovations of the past 5 years (XeTeX in particular) so it would still be good if someone who exercises the font-heavy side of things were around. Thanks, Eric From blair at orcaware.com Mon Jan 14 20:39:37 2008 From: blair at orcaware.com (Blair Zajac) Date: Mon Jan 14 20:39:15 2008 Subject: Subject: [32751] net/dhcp startupitem In-Reply-To: <98E0CD6D-C333-420A-815A-3E8611558251@macports.org> References: <98E0CD6D-C333-420A-815A-3E8611558251@macports.org> Message-ID: <478C3909.5000308@orcaware.com> Hi guys, I put dhcp back to the startupitem.executable but using -f. The port's name is dhcp and the daemon's name is dhcpd, so startupitem.name is needed. Regards, Blair James Berry wrote: > Hi Mark, > > So it looks like the bit magic that got this to work is the -f command, > which basically tells dhcpd not to daemonize, which would be a good > thing in our case, as the process of daemonizing would look to daemondo > or launchd as if dhcpd were exiting, which would cause the constantly > restarting behavior Blair described. > > The startupitem.name spec should be completely redundant and unneeded; > the name will default to the name of the port, which is dhcpd, right? > > Does that answer your question? > > James > > > On Jan 13, 2008, at 1:25 PM, markd@macports.org wrote: > >> Blair, >> >> I see. That's fine then. I just wanted to be sure there was a reason >> for >> making it a script startupitem and there is. I'm cc'ing James (master of >> all things startupitem) just in case he knows why the executable >> startupitem type wasn't adequate in this case. It seems like it should >> have worked. Thanks for fixing the port. >> >> Mark > > On Jan 13, 2008, at 12:42 PM, Blair Zajac wrote: >> Mark, >> >> It works fine if I use this: >> >> startupitem.create yes >> startupitem.name dhcpd >> startupitem.executable ${prefix}/sbin/dhcpd -f >> startupitem.netchange yes >> >> How's that? > >> > >> >>> Hi Mark, >>> >>> I was seeing the following: >>> >>> 1) One dhcpd would start. >>> >>> 2) Every 10 seconds thereafter, another dhcpd would be started, but it >>> couldn't bind to the port since the first one was running. >>> >>> It appears that the startupitem infrastructure wasn't keeping track of >>> dhcpd running and deamonizing itself. >>> >>> I haven't read the guide yet.? What do you suggest?? Putting a -f to >>> dhcpd so it stays in the foreground? >>> >>> Regards, >>> Blair >>> >>> -- >>> Blair Zajac, Ph.D. >>> CTO, OrcaWare Technologies >>> >>> Subversion training, consulting and support >>> [ >>> https://owa016.msoutlookonline.net/owa/redir.aspx?URL=http%3a%2f%2fwww.orcaware.com%2fsvn%2f >>> >>> ]http://www.orcaware.com/svn/ >>> >>> On Jan 13, 2008, at 12:11 PM, markd@macports.org wrote: >>> >>>> Hi Blair, >>>> >>>> Executable startupitems are the preferred type.? Daemondo can track >>>> pids >>>> automatically and reliably restart an application if it quits.? See >>>> the >>>> guide on this: >>>> >>>> [ >>> https://owa016.msoutlookonline.net/owa/redir.aspx?URL=http%3a%2f%2fguide.macports.org%2f%23reference.startupitems >>> >>> ]http://guide.macports.org/#reference.startupitems >>>> >>>> Given how startupitem executables work, I don't see an advantage to >>>> reverting to a "script" startupitem.? Or is there something I am >>>> missing >>>> particular to dhcp? >> >> _______________________________________________ >> macports-dev mailing list >> macports-dev@lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo/macports-dev > > From boeyms at macports.org Mon Jan 14 21:28:04 2008 From: boeyms at macports.org (Boey Maun Suang) Date: Mon Jan 14 21:27:41 2008 Subject: (Mass) Update for gtkglext on leopard? In-Reply-To: <7F62EB59-D107-4147-8F53-EF6B2A168A5A@digitalis.org> References: <7F62EB59-D107-4147-8F53-EF6B2A168A5A@digitalis.org> Message-ID: <2E3ED4CB-6E8A-4E51-B59A-B21A6F808EC3@macports.org> Hi Rolf, > as you (perhaps) now, there is a linking problem with gtkglext on > leopard > that is fixed (#13624) ... > > the maintainer doesn't react, so I would send him an email and wait > 72 hours before commiting the update. (after sign in for commiter > is done) > > but all applications using gtkglxt have to get updated too (#13737) > Soo - what should I do? Wait for all maintainers (if avail) to change > the portfiles? - Do an automatic mass update? (Some shell script > which appends the portfiles and commits them (one by one))? > Write all maintainers to change their portfiles? > > The documentation state this problem as an exception to the rules > of changing only one file per time/wait for the maintainers... > > what is your opinion/recommandation? First of all, thanks for the fix to gtkglext. I'd have tested your patch with a view to committing it a while ago, but I don't have Leopard. And congratulations on becoming a committer! As for the updates to other ports, if it's only a matter of re- enabling gtkglext support at configure/build time, then I think that the normal "72-hour wait then commit" policy is in order. (If you do do that, don't forget to bump the revision number in the port so that users get the change, unless it's only in a variant; I still miss that occasionally.) If, on the other hand, the port depending on gtkglext needs more extensive work, I'd wait to consult with the port maintainer. Finally, as for how to do the patches to the ports. Personally, if the patches are all virtually identical (e.g. just adding a "--with- gtkglext" to configure.args), then I'd be happy doing it in one patch. However, I'd split off into separate patches anything that was a little different (or significantly different) from the others, just so it's easier to revert and fix just in case an unforeseen problem comes up. I hope that the above seems sensible and useful. And, once again, welcome to the committers' club! Kind regards, Maun Suang -- Boey Maun Suang (Boey is my surname) Email: boeyms at macports dot org From boeyms at macports.org Mon Jan 14 21:37:51 2008 From: boeyms at macports.org (Boey Maun Suang) Date: Mon Jan 14 21:37:31 2008 Subject: Macworld anyone? In-Reply-To: References: Message-ID: <8E40D24B-1A9B-42CB-A3BC-37771AF46986@macports.org> On 15/01/2008, at 12:10 PM, Daniel J.Luke wrote: > Anyone else attending macworld and interested in possibly hanging > out (and possibly chatting about macports) at some point? Ah, if only: 1. I live in Australia; 2. I have a student budget. Given the size of the market here, I rather doubt that a "Macworld Australia" would be worth it :) If anybody else _is_ going to Macworld, though, I encourage you to take up Daniel's offer -- any expo experience is much better when you're there as part of a group! Kind regards, Maun Suang -- Boey Maun Suang (Boey is my surname) Email: boeyms at macports dot org From jmpp at macports.org Tue Jan 15 00:23:28 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Jan 15 00:21:35 2008 Subject: documentation: project.xml In-Reply-To: <534DF6A1-CDD4-4FA2-8274-A3909FC8DEAC@macports.org> References: <534DF6A1-CDD4-4FA2-8274-A3909FC8DEAC@macports.org> Message-ID: <6A959D5F-FF09-4A00-83EC-894434890C96@macports.org> On Jan 14, 2008, at 6:12 PM, Ryan Schmidt wrote: > > Cc: The reporter should enter > his or her > email address and the maintainer's email address to notify > both > parties when updates to the ticket occur. This is > important, because > Trac currently only sends emails to addresses on the Cc > list, not to > the reporter or the assignee. Multiple emails should be > separated > with a comma (i.e. you@example.org, > maintainer@macports.org). To get the maintainer > email > address use port info > portname. > > > > This is not true anymore. Trac now automatically emails the reporter > and the assignee. A ticket should be assigned to the port's > maintainer if possible, and the assignee and maintainer do not need > to appear in the Cc line. However if the maintainer does not appear > in the assignee drop-down menu, then the maintainer should be listed > in the Cc field. Thanks for the reminder, done! -jmpp From ryandesign at macports.org Tue Jan 15 01:58:47 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Jan 15 01:59:08 2008 Subject: [32932] trunk/dports/news/xpn/Portfile In-Reply-To: <20080115084951.DFEEC9F94A8@beta.macosforge.org> References: <20080115084951.DFEEC9F94A8@beta.macosforge.org> Message-ID: <0B10F3F0-5346-4B1B-B89E-13EB7366FC95@macports.org> On Jan 15, 2008, at 02:49, gui_dos@macports.org wrote: > Revision: 32932 > http://trac.macosforge.org/projects/macports/changeset/32932 > Author: gui_dos@macports.org > Date: 2008-01-15 00:49:51 -0800 (Tue, 15 Jan 2008) > > Log Message: > ----------- > xpn: new dependency on py25-gtk > > Modified Paths: > -------------- > trunk/dports/news/xpn/Portfile > > Modified: trunk/dports/news/xpn/Portfile > =================================================================== > --- trunk/dports/news/xpn/Portfile 2008-01-15 08:44:02 UTC (rev 32931) > +++ trunk/dports/news/xpn/Portfile 2008-01-15 08:49:51 UTC (rev 32932) > @@ -17,7 +17,7 @@ > homepage http://xpn.altervista.org/ > master_sites ${homepage}codice > checksums md5 3df054fc7c25f2e579407c1f148b9a27 > -depends_lib port:py-gtk2 > +depends_lib port:py25-gtk > configure {} > build {} > destroot { Coincidentally, could you please use "use_configure no" instead of "configure {}"? You might also want to add "universal_variant no". Thanks. From guido.soranzio at gmail.com Tue Jan 15 03:01:29 2008 From: guido.soranzio at gmail.com (Guido Soranzio) Date: Tue Jan 15 03:01:04 2008 Subject: [32932] trunk/dports/news/xpn/Portfile In-Reply-To: <0B10F3F0-5346-4B1B-B89E-13EB7366FC95@macports.org> References: <20080115084951.DFEEC9F94A8@beta.macosforge.org> <0B10F3F0-5346-4B1B-B89E-13EB7366FC95@macports.org> Message-ID: On Jan 15, 2008, at 10:58 AM, Ryan Schmidt wrote: > Coincidentally, could you please use "use_configure no" instead of > "configure {}"? You might also want to add "universal_variant no". Thanks: I have corrected the Portfile with -Guido From n.oxyde at gmail.com Tue Jan 15 03:09:42 2008 From: n.oxyde at gmail.com (N_Ox) Date: Tue Jan 15 03:09:15 2008 Subject: [32733] trunk/dports/perl/p5-xml-sax-expat/Portfile In-Reply-To: <05E38266-A5FD-4F0E-8C05-B09A95628E0C@geeklair.net> References: <20080112200825.578958F7EAD@beta.macosforge.org> <4F0F8421-D78B-4F41-8BEF-F37D83050108@macports.org> <22C9FE85-7C91-46B7-B0B0-634B6E3AEE3C@gmail.com> <05E38266-A5FD-4F0E-8C05-B09A95628E0C@geeklair.net> Message-ID: <72F8580E-2066-402F-8809-63728B2F001D@gmail.com> Le 15 janv. 08 ? 02:15, Daniel J. Luke a ?crit : > Pre/post activate do not run on installs with 'direct' mode (they > only run in image mode). > > -- > Daniel J. Luke > Sent from my iPhone > > >> I know, but we don't have that much of a choice here. -- Anthony Ramine, the "Ports tree cleaning Maestro". From jmpp at macports.org Tue Jan 15 09:32:55 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Jan 15 09:31:05 2008 Subject: One change, multiple ports Message-ID: <9543389D-E0AC-44FC-8F0B-37EEDB790ED8@macports.org> Hi Takeshi! A little committer's hint: changes like the ones you just made to your ports to reflect your new maintainer address, it's perfectly acceptable to do all of them, spanning all affected ports, in a single commit. Our general rule reads "one logical change, one commit", and when it comes to Portfiles that usually maps to a single one. However, when the one logical change is something that affects multiple Portfiles on an equal basis (extra emphasis on this condition!), it's perfectly acceptable to commit all of them together. Other than that, welcome aboard! Regards,... -jmpp From pguyot at kallisys.net Tue Jan 15 10:43:45 2008 From: pguyot at kallisys.net (Paul Guyot) Date: Tue Jan 15 10:43:16 2008 Subject: tetex/texlive dependencies In-Reply-To: <20080114223220.GA28838@ruderich.com> References: <16E5B12E-C2CD-49AA-91A2-089920BE2A65@macports.org> <356D3161-B877-420B-BA13-29151D154BC3@macports.org> <20080114091811.GA4002@weetamoe.loria.fr> <9369365D-EBDF-4569-9AD7-E53D6E64D595@macports.org> <20080114223220.GA28838@ruderich.com> Message-ID: <322FA547-E6FA-46A4-8323-6BEEABDBBAC7@kallisys.net> Le 14 janv. 08 ? 23:32, Simon Ruderich a ?crit : > - pguyot@kallisys.net: dvipdfmx dvipdfmx is provided by texlive_base, but it's an older version that actually crashes when doing some operations. Paul From ryandesign at macports.org Tue Jan 15 15:38:20 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Jan 15 15:38:40 2008 Subject: [32977] trunk/dports/devel/qca/Portfile In-Reply-To: <20080115223648.CFDBCA1B8D0@beta.macosforge.org> References: <20080115223648.CFDBCA1B8D0@beta.macosforge.org> Message-ID: <57275F31-0A4B-4CA2-AFB7-9ED04752B914@macports.org> On Jan 15, 2008, at 16:36, rowue@macports.org wrote: > Revision: 32977 > http://trac.macosforge.org/projects/macports/changeset/32977 > Author: rowue@macports.org > Date: 2008-01-15 14:36:47 -0800 (Tue, 15 Jan 2008) > > Log Message: > ----------- > Added qt Information files And you also made whitespace changes to other lines of the portfile. Please, if you want to make whitespace changes, do them in a separate commit from functional changes. This makes it easier to see what functional changes were actually made. > Modified Paths: > -------------- > trunk/dports/devel/qca/Portfile > > Modified: trunk/dports/devel/qca/Portfile > =================================================================== > --- trunk/dports/devel/qca/Portfile 2008-01-15 20:44:30 UTC (rev > 32976) > +++ trunk/dports/devel/qca/Portfile 2008-01-15 22:36:47 UTC (rev > 32977) > @@ -1,11 +1,12 @@ > # $Id$ > > -PortSystem 1.0 > -name qca > -version 2.0.0 > -categories devel crypto security > -maintainers rowue@digitalis.org > -description Qt Cryptographic Architecture > +PortSystem 1.0 > +name qca > +version 2.0.0 > +categories devel crypto security > +maintainers rowue@digitalis.org > +description Qt Cryptographic Architecture > +revision 1 > long_description \ > This library provides an easy API for the following features: > SSL/TLS, \ > X509, SASL, RSA, Hashing (SHA1, MD5), Ciphers (BlowFish, 3DES, > AES), \ > @@ -32,21 +33,27 @@ > > destroot { > xinstall -m 755 -d ${destroot}${prefix}/lib ${destroot}$ > {prefix}/include \ > + ${destroot}${prefix}/share/qt4/mkspecs/features \ > + ${destroot}${prefix}/lib/pkgconfig \ > ${destroot}${prefix}/share/doc/${name} \ > ${destroot}${prefix}/share/examples/${name} \ > ${destroot}${prefix}/include/QTCrypto > > - xinstall -m 644 -W ${worksrcpath}/lib libqca.2.0.0.dylib \ > + xinstall -m 644 -W ${worksrcpath}/lib libqca.2.0.0.dylib \ > ${destroot}${prefix}/lib > - system "ln -sf libqca.2.0.0.dylib ${destroot}${prefix}/lib/ > libqca.dylib" > - system "ln -sf libqca.2.0.0.dylib ${destroot}${prefix}/lib/ > libqca.2.dylib" > - system "ln -sf libqca.2.0.0.dylib \ > + system "ln -sf libqca.2.0.0.dylib ${destroot}${prefix}/lib/ > libqca.dylib" > + system "ln -sf libqca.2.0.0.dylib ${destroot}${prefix}/lib/ > libqca.2.dylib" > + system "ln -sf libqca.2.0.0.dylib \ > ${destroot}${prefix}/lib/libqca.2.0.dylib" > > foreach f [glob ${worksrcpath}/include/QtCrypto/*] { > xinstall -m 644 $f ${destroot}${prefix}/include/QTCrypto > } > > + xinstall -m 644 -W ${worksrcpath} crypto.prf \ > + ${destroot}${prefix}/share/qt4/mkspecs/features > + xinstall -m 644 -W ${worksrcpath}/lib qca2.pc \ > + ${destroot}${prefix}/lib/pkgconfig > xinstall -m 644 -W ${worksrcpath} COPYING INSTALL README TODO \ > ${destroot}${prefix}/share/doc/${name} > eval file copy [glob ${worksrcpath}/examples/*] \ From ryandesign at macports.org Tue Jan 15 15:47:30 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Jan 15 15:47:52 2008 Subject: [32967] trunk/dports/gnome/libgnome/Portfile In-Reply-To: <20080115153515.1F63EA0A2C9@beta.macosforge.org> References: <20080115153515.1F63EA0A2C9@beta.macosforge.org> Message-ID: On Jan 15, 2008, at 09:35, nox@macports.org wrote: > Revision: 32967 > http://trac.macosforge.org/projects/macports/changeset/32967 > Author: nox@macports.org > Date: 2008-01-15 07:35:12 -0800 (Tue, 15 Jan 2008) > > Log Message: > ----------- > libgnome: > * Whitespace changes. > * Added md5 and sha1 checksums. > * Removed useless configure args. It would be easier to see what functional changes you made if you committed whitespace changes separately from other changes! :) > Modified Paths: > -------------- > trunk/dports/gnome/libgnome/Portfile > > Modified: trunk/dports/gnome/libgnome/Portfile > =================================================================== > --- trunk/dports/gnome/libgnome/Portfile 2008-01-15 15:19:57 UTC > (rev 32966) > +++ trunk/dports/gnome/libgnome/Portfile 2008-01-15 15:35:12 UTC > (rev 32967) > @@ -1,31 +1,34 @@ > # $Id$ > -PortSystem 1.0 > -name libgnome > -version 2.20.1.1 > -revision 1 > -description This is the non-gui part of the library formerly \ > - known as gnome-libs. > -long_description This is the non-gui part of the library > formerly \ > - known as gnome-libs. > -maintainers nomaintainer > -categories gnome > -platforms darwin > -homepage http://www.gnome.org/ > + > +PortSystem 1.0 > + > +name libgnome > +version 2.20.1.1 > +revision 1 > +maintainers nomaintainer > +categories gnome > +platforms darwin > +description This is the non-gui part of the library formerly > known as gnome-libs. > + > +long_description \ > + ${description} > + > +homepage http://www.gnome.org/ > master_sites gnome:sources/${name}/[join [lrange [split $ > {version} .] 0 1] .]/ > -checksums rmd160 616032d4af3c283e37728caeb705424dffbbac19 > +use_bzip2 yes > > +checksums md5 cfab025a8b9a19cdae1c64f8b005c513 \ > + sha1 59c1e8d8f8b50e290eb513eeadd729f271c20d2b \ > + rmd160 616032d4af3c283e37728caeb705424dffbbac19 > + > depends_lib \ > - port:libbonobo \ > - port:esound \ > - port:gnome-vfs \ > - port:dbus \ > - port:dbus-glib \ > - port:libiconv \ > - port:gettext > + port:libbonobo \ > + port:esound \ > + port:gnome-vfs \ > + port:dbus \ > + port:dbus-glib \ > + port:libiconv \ > + port:gettext > > -use_bzip2 yes > - > -patchfiles \ > - patch-configure.diff > - > -configure.args --mandir=${prefix}/share/man > +patchfiles \ > + patch-configure.diff From rowue at digitalis.org Tue Jan 15 15:58:37 2008 From: rowue at digitalis.org (=?ISO-8859-1?Q?Rolf_W=FCrdemann?=) Date: Tue Jan 15 15:58:17 2008 Subject: [32977] trunk/dports/devel/qca/Portfile In-Reply-To: <57275F31-0A4B-4CA2-AFB7-9ED04752B914@macports.org> References: <20080115223648.CFDBCA1B8D0@beta.macosforge.org> <57275F31-0A4B-4CA2-AFB7-9ED04752B914@macports.org> Message-ID: Am 16.01.2008 um 00:38 schrieb Ryan Schmidt: > On Jan 15, 2008, at 16:36, rowue@macports.org wrote: > >> Revision: 32977 >> http://trac.macosforge.org/projects/macports/changeset/ >> 32977 >> Author: rowue@macports.org >> Date: 2008-01-15 14:36:47 -0800 (Tue, 15 Jan 2008) >> >> Log Message: >> ----------- >> Added qt Information files > > And you also made whitespace changes to other lines of the > portfile. Please, if you want to make whitespace changes, do them > in a separate commit from functional changes. This makes it easier > to see what functional changes were actually made. f**k - overseen - sorry > > >> [...] -- Security is an illusion - Datasecurity twice Rolf W?rdemann - private: rowue@digitalis.org - office: rowue@crew-gmbh.de GnuPG fingerprint: 7383 348F 67D1 CD27 C90F DDD0 86A3 31B6 67F0 D02F jabber: rowue@digitalis.org 2F66A061 89BCA1A0 AD654827 6FD037FF 53C3E932 -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: Signierter Teil der Nachricht Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080116/176667d5/PGP.bin From rowue at digitalis.org Tue Jan 15 16:07:41 2008 From: rowue at digitalis.org (=?ISO-8859-1?Q?Rolf_W=FCrdemann?=) Date: Tue Jan 15 16:07:14 2008 Subject: (Mass) Update for gtkglext on leopard? In-Reply-To: <2E3ED4CB-6E8A-4E51-B59A-B21A6F808EC3@macports.org> References: <7F62EB59-D107-4147-8F53-EF6B2A168A5A@digitalis.org> <2E3ED4CB-6E8A-4E51-B59A-B21A6F808EC3@macports.org> Message-ID: <7BC57B3E-97B2-4180-8797-E52CEE315B3C@digitalis.org> Am 15.01.2008 um 06:28 schrieb Boey Maun Suang: > Hi Rolf, > >> as you (perhaps) now, there is a linking problem with gtkglext on >> leopard >> that is fixed (#13624) ... >> >> the maintainer doesn't react, so I would send him an email and wait >> 72 hours before commiting the update. (after sign in for commiter >> is done) >> >> but all applications using gtkglxt have to get updated too (#13737) >> Soo - what should I do? Wait for all maintainers (if avail) to change >> the portfiles? - Do an automatic mass update? (Some shell script >> which appends the portfiles and commits them (one by one))? >> Write all maintainers to change their portfiles? >> >> The documentation state this problem as an exception to the rules >> of changing only one file per time/wait for the maintainers... >> >> what is your opinion/recommandation? > > First of all, thanks for the fix to gtkglext. I'd have tested your > patch with a view to committing it a while ago, but I don't have > Leopard. And congratulations on becoming a committer! First: Thanks - second: a friend of mine is using leopard - and I can use his machine for testing ;) > > As for the updates to other ports, if it's only a matter of re- > enabling gtkglext support at configure/build time, then I think > that the normal "72-hour wait then commit" policy is in order. (If > you do do that, don't forget to bump the revision number in the > port so that users get the change, unless it's only in a variant; I > still miss that occasionally.) If, on the other hand, the port > depending on gtkglext needs more extensive work, I'd wait to > consult with the port maintainer. Each Port will get an variant part (for leopard) with three lines in it (setting ldflags) - if you want to see, look at #13737 (http://trac.macports.org/projects/macports/ticket/13737) I'll Email the maintainers after #13624 (http://trac.macports.org/ projects/macports/ticket/13624) is committed (currently waiting for reply ;) > > Finally, as for how to do the patches to the ports. Personally, if > the patches are all virtually identical (e.g. just adding a "--with- > gtkglext" to configure.args), then I'd be happy doing it in one > patch. However, I'd split off into separate patches anything that > was a little different (or significantly different) from the > others, just so it's easier to revert and fix just in case an > unforeseen problem comes up. And better to supervise ;) - I'll do one patch for each port ;) > > I hope that the above seems sensible and useful. And, once again, > welcome to the committers' club! > Thanks**2 again ;) > Kind regards, > > > Maun Suang > cheers, Rolf > -- Security is an illusion - Datasecurity twice Rolf W?rdemann - private: rowue@digitalis.org - office: rowue@crew-gmbh.de GnuPG fingerprint: 7383 348F 67D1 CD27 C90F DDD0 86A3 31B6 67F0 D02F jabber: rowue@digitalis.org 2F66A061 89BCA1A0 AD654827 6FD037FF 53C3E932 -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: Signierter Teil der Nachricht Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080116/269c0ee1/PGP-0001.bin From rowue at digitalis.org Tue Jan 15 16:11:29 2008 From: rowue at digitalis.org (=?ISO-8859-1?Q?Rolf_W=FCrdemann?=) Date: Tue Jan 15 16:10:57 2008 Subject: Abdon qca-tls? Message-ID: Hi everybody ... during the transfer of qca 1.0.0 to qca 2.0.0 qca-tls is no longer part of qca (TLS is now done by qca-ossl) - and was only needed by the 0.9.3 version of psi (which is now changed to 0.11) should I simply drop the port - or better leave some message for a while and drop then? Hints? Comments? Reg's, Rolf -- Security is an illusion - Datasecurity twice Rolf W?rdemann - private: rowue@digitalis.org - office: rowue@crew-gmbh.de GnuPG fingerprint: 7383 348F 67D1 CD27 C90F DDD0 86A3 31B6 67F0 D02F jabber: rowue@digitalis.org 2F66A061 89BCA1A0 AD654827 6FD037FF 53C3E932 -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: Signierter Teil der Nachricht Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080116/90ec001b/PGP.bin From mbrooksclark at mac.com Tue Jan 15 17:36:19 2008 From: mbrooksclark at mac.com (Brooks Clark) Date: Tue Jan 15 17:39:38 2008 Subject: Creating portfile for program that includes StartupItems script Message-ID: I'm trying to put together a portfile for some software that already compiles and runs on a Mac. I'd like to make the installation a bit easier, though, by creating a port, especially since the software already has several MacPorts dependencies. The software is actually a set of about six or so daemons that should be run at startup time. The source code ships with a working StartupItems script. I've gotten the portfile to the point where it downloads the source, compiles, and installs the executbles. I'm not having much luck with the startup script, however. Can anyone point me to any examples of portfiles that I could use as a go-by for launching multiple daemons at startup? Is it possible (preferred?) to just use the StartupItems script that comes with the software? Any recommendations or suggestions for how to best install the startup items would be much appreciated. Thanks, Brooks From jmpp at macports.org Tue Jan 15 20:46:55 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Jan 15 20:45:05 2008 Subject: [32983] trunk/dports/gnome/libgtkhtml3/Portfile In-Reply-To: <20080116005308.A099EA1FABC@beta.macosforge.org> References: <20080116005308.A099EA1FABC@beta.macosforge.org> Message-ID: <134F8B78-0A96-49A3-8A88-7A20B7ADB4AA@macports.org> On Jan 15, 2008, at 8:23 PM, nox@macports.org wrote: > Revision > 32983 > Author > nox@macports.org > Date > 2008-01-15 16:53:06 -0800 (Tue, 15 Jan 2008) > Log Message > > libgtkhtml3: > * Fixed dependencies. > * Removed useless configure env variable. > Modified Paths > > trunk/dports/gnome/libgtkhtml3/Portfile > Diff > > Modified: trunk/dports/gnome/libgtkhtml3/Portfile (32982 => 32983) > --- trunk/dports/gnome/libgtkhtml3/Portfile 2008-01-15 23:56:28 UTC > (rev 32982) > +++ trunk/dports/gnome/libgtkhtml3/Portfile 2008-01-16 00:53:06 UTC > (rev 32983) > @@ -2,10 +2,11 @@ > > PortSystem 1.0 > > -name libgtkhtml3 > +name libgtkhtml3 > set my_name gtkhtml > version 3.16.0 > set branch [join [lrange [split ${version} .] 0 1] .] > +set revision 1 > Off the top of my head, I'd be wary this local "revision" variable may collide with the internal "revision" property of Portfiles. I don't see any other use of "revision" in your Portfile which makes me think that you are using it in the regular context of a Portfile revision; but if that's the case, why do you use "set"? Regards,... -jmpp -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080116/b5238415/attachment.html From markd at macports.org Wed Jan 16 01:07:56 2008 From: markd at macports.org (markd@macports.org) Date: Wed Jan 16 01:05:42 2008 Subject: Subject: [32751] net/dhcp startupitem Message-ID: >i Mark, > >So it looks like the bit magic that got this to work is the -f >command, which basically tells dhcpd not to daemonize, which would be >a good thing in our case, as the process of daemonizing would look to >daemondo or launchd as if dhcpd were exiting, which would cause the >constantly restarting behavior Blair described. > Hi James, So I've looked up what "daemonize" means and I see it entails making a child of the initializing process. So I understand why daemondo thinks a daemonized process has exited. But might some processes not have a switch to keep in the foreground as in the case of dhcp? And if not, would that be the rare case where startupitem.pidfile would be used with startupitem.executable? If I recall correctly, they could be used together but I hadn't thought of a reason where it would be useful to do so. At the very least I should document that processes that daemonize are a problem for startupitem.executable. Mark From randall.h.wood at alexandriasoftware.com Wed Jan 16 01:14:53 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Wed Jan 16 01:14:29 2008 Subject: [32937] trunk/dports/gnome/evince/Portfile In-Reply-To: <20080115110719.8190C9FEFC4@beta.macosforge.org> References: <20080115110719.8190C9FEFC4@beta.macosforge.org> Message-ID: You might want to note that for the GNOME project, packages with a version x.y.z where y is an odd number are normally considered unstable, not fit for daily use. On 15 Jan 2008, at 06:07, gui_dos@macports.org wrote: > Revision32937Authorgui_dos@macports.orgDate2008-01-15 03:07:18 -0800 > (Tue, 15 Jan 2008)Log Message > Update to evince 2.21.1 > Added "djvu" variant > Modified Paths > ? trunk/dports/gnome/evince/Portfile > Diff > Modified: trunk/dports/gnome/evince/Portfile (32936 => 32937) > --- trunk/dports/gnome/evince/Portfile 2008-01-15 10:38:53 UTC (rev > 32936) > +++ trunk/dports/gnome/evince/Portfile 2008-01-15 11:07:18 UTC (rev > 32937) > @@ -1,7 +1,7 @@ > # $Id$ > PortSystem 1.0 > name evince > -version 2.20.1 > +version 2.21.1 > description Evince is a document viewer for multiple document > formats like pdf, and many others. > long_description ${description} > maintainers nomaintainer > @@ -10,7 +10,7 @@ > homepage http://www.gnome.org/ > master_sites gnome:sources/evince/[strsed ${version} {/\.[0-9]* > $//}]/ > use_bzip2 yes > -checksums md5 c0f3e4d5279ef3d08cc46b752e230c01 > +checksums md5 24fb73444987357373098e57c8361ebb > depends_lib \ > port:atk \ > port:audiofile \ > @@ -29,6 +29,7 @@ > port:gnome-icon-theme \ > port:gnome-vfs \ > port:gtk2 \ > + port:hicolor-icon-theme \ > port:jpeg \ > port:libart_lgpl \ > port:libglade2 \ > @@ -52,6 +53,11 @@ > port:perl5.8 \ > port:pkgconfig \ > port:scrollkeeper > + > +variant djvu { > + depends_lib-append port:djvulibre > +} > + > configure.args \ > --disable-scrollkeeper \ > --enable-nautilus \ > _______________________________________________ > macports-changes mailing list > macports-changes@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-changes Randall Wood randall.h.wood@alexandriasoftware.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 nox at macports.org Wed Jan 16 02:23:18 2008 From: nox at macports.org (N_Ox) Date: Wed Jan 16 02:22:45 2008 Subject: [32983] trunk/dports/gnome/libgtkhtml3/Portfile In-Reply-To: <134F8B78-0A96-49A3-8A88-7A20B7ADB4AA@macports.org> References: <20080116005308.A099EA1FABC@beta.macosforge.org> <134F8B78-0A96-49A3-8A88-7A20B7ADB4AA@macports.org> Message-ID: <3A5A5FD1-32BC-446B-BEE8-43202D77DE94@macports.org> Le 16 janv. 08 ? 05:46, Juan Manuel Palacios a ?crit : > > On Jan 15, 2008, at 8:23 PM, nox@macports.org wrote: > >> Revision >> 32983 >> Author >> nox@macports.org >> Date >> 2008-01-15 16:53:06 -0800 (Tue, 15 Jan 2008) >> Log Message >> >> libgtkhtml3: >> * Fixed dependencies. >> * Removed useless configure env variable. >> Modified Paths >> >> trunk/dports/gnome/libgtkhtml3/Portfile >> Diff >> >> Modified: trunk/dports/gnome/libgtkhtml3/Portfile (32982 => 32983) >> --- trunk/dports/gnome/libgtkhtml3/Portfile 2008-01-15 23:56:28 >> UTC (rev 32982) >> +++ trunk/dports/gnome/libgtkhtml3/Portfile 2008-01-16 00:53:06 >> UTC (rev 32983) >> @@ -2,10 +2,11 @@ >> >> PortSystem 1.0 >> >> -name libgtkhtml3 >> +name libgtkhtml3 >> set my_name gtkhtml >> version 3.16.0 >> set branch [join [lrange [split ${version} .] 0 1] .] >> +set revision 1 >> > > > Off the top of my head, I'd be wary this local "revision" variable > may collide with the internal "revision" property of Portfiles. I > don't see any other use of "revision" in your Portfile which makes > me think that you are using it in the regular context of a Portfile > revision; but if that's the case, why do you use "set"? > > Regards,... > Maybe I've got bored of simply writing "revision 1" with all of these "set branch blabla" everywhere. My mistake. Thanks for noticing. -- Anthony Ramine, the "Ports tree cleaning Maestro". From blair at orcaware.com Wed Jan 16 08:23:46 2008 From: blair at orcaware.com (Blair Zajac) Date: Wed Jan 16 08:23:23 2008 Subject: Subject: [32751] net/dhcp startupitem In-Reply-To: References: Message-ID: <478E2F92.8010303@orcaware.com> markd@macports.org wrote: >> i Mark, >> >> So it looks like the bit magic that got this to work is the -f >> command, which basically tells dhcpd not to daemonize, which would be >> a good thing in our case, as the process of daemonizing would look to >> daemondo or launchd as if dhcpd were exiting, which would cause the >> constantly restarting behavior Blair described. >> > Hi James, > > So I've looked up what "daemonize" means and I see it entails making a > child of the initializing process. So I understand why daemondo thinks a > daemonized process has exited. But might some processes not have a switch > to keep in the foreground as in the case of dhcp? And if not, would that > be the rare case where startupitem.pidfile would be used with > startupitem.executable? If I recall correctly, they could be used > together but I hadn't thought of a reason where it would be useful to do > so. At the very least I should document that processes that daemonize are > a problem for startupitem.executable. I think most programs that daemonize themselves have a command line option to stay in the foreground. It makes it easier for the program to be debugged. Regards, Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies Subversion training, consulting and support http://www.orcaware.com/svn/ From markd at macports.org Wed Jan 16 09:00:04 2008 From: markd at macports.org (markd@macports.org) Date: Wed Jan 16 09:01:09 2008 Subject: Creating portfile for program that includes StartupItems Message-ID: >Date: Wed, 16 Jan 2008 01:36:19 +0000 (UTC) >From: Brooks Clark >Subject: Creating portfile for program that includes StartupItems >??????? script >To: macports-dev@lists.macosforge.org >Message-ID: >Content-Type: text/plain; charset=us-ascii > >I'm trying to put together a portfile for some software that already >compiles >and runs on a Mac. I'd like to make the installation a bit easier, though, >by creating a port, especially since the software already has several >MacPorts dependencies. The software is actually a set of about six or so >daemons that should be run at startup time. > >The source code ships with a working StartupItems script. > >I've gotten the portfile to the point where it downloads the source, >compiles, and installs the executbles. I'm not having much luck with >the startup script, however. > >Can anyone point me to any examples of portfiles that I could use >as a go-by for launching multiple daemons at startup? Is it possible >(preferred?) to just use the StartupItems script that comes with the >software? Any recommendations or suggestions for how to best install >the startup items would be much appreciated. Hi Brooks, It is fine to use the startupitems script that come with a port if it works ok on OS X, and if the developer considers the script adequate you don't need to reinvent the wheel. On the other hand, if the developer provided scripts is very simple and merely launches daemon(s) and nothing more, there is not a lot of reason to use it and by using MacPorts startupitems to launch the daemon directly (startupitem.executable) where possible you'll get the monitored daemon that will be restarted if it dies. If you have a port that uses multiple daemons and a startup script is provided, it might be the best to use the script provided. But if the script merely launches a bunch of daemons then you could provide multiple startup scripts using MacPorts. But for more than one startup script per port, you'll end up creating some .plist files and copying them manually since only one startupitem per port can be supported automatically. See the net/nedi port for how I supported 3 startupitems for a port. See net/zabbix for an example of a startupitem that uses a distro provided startup script. BTW, one thing not supported is inetdcompatibility for daemons, though this is not needed frequently. That requires creating a .plist manually and copying it during the port install also. Mark From josh+macports at root.id.au Wed Jan 16 22:30:12 2008 From: josh+macports at root.id.au (Joshua Root) Date: Wed Jan 16 22:29:38 2008 Subject: tetex/texlive dependencies In-Reply-To: <20080114223220.GA28838@ruderich.com> References: <16E5B12E-C2CD-49AA-91A2-089920BE2A65@macports.org> <356D3161-B877-420B-BA13-29151D154BC3@macports.org> <20080114091811.GA4002@weetamoe.loria.fr> <9369365D-EBDF-4569-9AD7-E53D6E64D595@macports.org> <20080114223220.GA28838@ruderich.com> Message-ID: <478EF5F4.2050300@root.id.au> Simon Ruderich wrote: > I just checked which ports are using TeTeX. Quite a few. > > Nomaintainer: [...] I've made a patch for those and attached it to ticket #12913. I used the dependency style suggested by Ryan. Has someone mailed the maintainers of the other affected ports? Cheers, Josh From ryandesign at macports.org Wed Jan 16 22:58:30 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Jan 16 22:57:56 2008 Subject: [33003] trunk/dports/lang In-Reply-To: <20080116160912.671F5A43659@beta.macosforge.org> References: <20080116160912.671F5A43659@beta.macosforge.org> Message-ID: <6FB3386F-2668-405B-9A06-A4A3EA0107C9@macports.org> On Jan 16, 2008, at 10:09, reiffert@macports.org wrote: > +configure {} You should use "use_configure no" instead of "configure {}". You may also want "universal_variant no" or provide another solution for universal building. From ryandesign at macports.org Wed Jan 16 22:57:35 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Jan 16 23:03:43 2008 Subject: 2-architecture +universal variants please (was: Re: [32999] trunk/base/ChangeLog) In-Reply-To: <20080116125553.8B1E2A3ABB4@beta.macosforge.org> References: <20080116125553.8B1E2A3ABB4@beta.macosforge.org> Message-ID: On Jan 16, 2008, at 06:55, afb@macports.org wrote: > Revision: 32999 > http://trac.macosforge.org/projects/macports/changeset/32999 > Author: afb@macports.org > Date: 2008-01-16 04:55:44 -0800 (Wed, 16 Jan 2008) > > Log Message: > ----------- > update changelog for r32194 and r32724 > > Modified Paths: > -------------- > trunk/base/ChangeLog > > Modified: trunk/base/ChangeLog > =================================================================== > --- trunk/base/ChangeLog 2008-01-16 11:01:26 UTC (rev 32998) > +++ trunk/base/ChangeLog 2008-01-16 12:55:44 UTC (rev 32999) > @@ -6,6 +6,10 @@ > > Unreleased: [snip] > + - Enable 64 bit environment, ppc64 x86_64, for all +universal > builds (mww in r32194). May I change this so that we only build 32-bit versions again, please? I've already encountered ports that built fine as 32-bit universals that fail as 64-bit universals. Also, we still haven't thought of a solution for all the users who already have 32-bit +universal ports installed. What happens when they upgrade to a version of MacPorts that includes this change and continue building +universal ports? Everything goes to Hell, that's what happens, because the new ports want to build 4 architectures but the existing dependencies are only built with 2 architectures. If nobody offers a clear objection to this in 72 hours I'll change it to just the two 32-bit architectures again. From afb at macports.org Wed Jan 16 23:08:42 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Wed Jan 16 23:08:16 2008 Subject: 2-architecture +universal variants please (was: Re: [32999] trunk/base/ChangeLog) In-Reply-To: References: <20080116125553.8B1E2A3ABB4@beta.macosforge.org> Message-ID: <943fadb9e468046c48154a810629d2c1@macports.org> >> + - Enable 64 bit environment, ppc64 x86_64, for all +universal >> builds (mww in r32194). > > May I change this so that we only build 32-bit versions again, please? > I've already encountered ports that built fine as 32-bit universals > that fail as 64-bit universals. Also, we still haven't thought of a > solution for all the users who already have 32-bit +universal ports > installed. What happens when they upgrade to a version of MacPorts > that includes this change and continue building +universal ports? > Everything goes to Hell, that's what happens, because the new ports > want to build 4 architectures but the existing dependencies are only > built with 2 architectures. That was the main reason for bringing it up in the Changelog, trunk has been broken for weeks... It's OK to build 64-bit universals if desired, but it should not be the default and it should be configurable - and if it builds 32-bit binaries without +universal, it should build with it too. --anders From jmpp at macports.org Wed Jan 16 23:12:12 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Wed Jan 16 23:09:36 2008 Subject: Changes for 1.6.1 Message-ID: <110CF56A-75CB-4DD5-BABC-D7D90A283504@macports.org> Hello everyone! As you may have seen, I started getting the release_1_6 branch in sync with trunk in a couple of recent commits, in preparation for the 1.6.1 release. They're almost in sync, except for the following: Outstanding changes: *) Anders: r32722 and r32801, enabling and disabling cURL's --remote- time: so, I gather we're just as if r32722 (addition of --remote- time) had never gone in, yes/no? any word on the development of this feature? should I schedule it for 1.6.1? keep in trunk for the time being, instead? *) Markus: r31954, r32194, "merge" function for universal building (and r32500 and r32501, Ryan's related typo fixes): last I read on this list, there were concerns about changing the platforms for which we build universal, with respect to universal binaries that were built for the previous set of platforms. Any advise on what should be done? Are we good to go releasing this code to the public? Or should we instead keep it in the oven a bit longer? Blocked changes: *) James: all changes related to the addition of MacPorts paths to / etc/paths.d and /etc/manpaths.d (r31491, r31492, r31495, r31496, r31520, r31600, r31946), as we're still using the postflight script (much improved this time round, thankfully! -- I've received quite some good feedback this time round). So... anything else I might be missing? Now is the time to chime in ;-) I'll be posting an rc for 1.6.1 as soon as I get a chance. Regards,... -jmpp From jmpp at macports.org Wed Jan 16 23:17:40 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Wed Jan 16 23:15:01 2008 Subject: 2-architecture +universal variants please (was: Re: [32999] trunk/base/ChangeLog) In-Reply-To: References: <20080116125553.8B1E2A3ABB4@beta.macosforge.org> Message-ID: On Jan 17, 2008, at 2:27 AM, Ryan Schmidt wrote: > > [snip] > >> + - Enable 64 bit environment, ppc64 x86_64, for all +universal >> builds (mww in r32194). > > May I change this so that we only build 32-bit versions again, > please? I've already encountered ports that built fine as 32-bit > universals that fail as 64-bit universals. Also, we still haven't > thought of a solution for all the users who already have 32-bit > +universal ports installed. What happens when they upgrade to a > version of MacPorts that includes this change and continue building > +universal ports? Everything goes to Hell, that's what happens, > because the new ports want to build 4 architectures but the > existing dependencies are only built with 2 architectures. > > If nobody offers a clear objection to this in 72 hours I'll change > it to just the two 32-bit architectures again. Thanks for bringing this up, Ryan, take a look at my recent message about the upcoming 1.6.1 release. I'm keeping this change out of the release_1_6 branch for now, pending mww's advise for merging or not. However, if the situation is as bad as you describe, not only will I keep it out of 1.6.1 for longer, but I'd also vote for the decision to build 64bits to be reverted. Lets please hear what Markus has to say about it first. Regards,... -jmpp From ryandesign at macports.org Wed Jan 16 23:43:14 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Jan 16 23:42:43 2008 Subject: Changes for 1.6.1 In-Reply-To: <110CF56A-75CB-4DD5-BABC-D7D90A283504@macports.org> References: <110CF56A-75CB-4DD5-BABC-D7D90A283504@macports.org> Message-ID: On Jan 17, 2008, at 01:12, Juan Manuel Palacios wrote: > *) Markus: r31954, r32194, "merge" function for universal building > (and r32500 and r32501, Ryan's related typo fixes): last I read on > this list, there were concerns about changing the platforms for > which we build universal, with respect to universal binaries that > were built for the previous set of platforms. Any advise on what > should be done? Are we good to go releasing this code to the > public? Or should we instead keep it in the oven a bit longer? I'd like to see the "merge" function in 1.6.1. It will simplify the openssl port, and could be used for cairo and other ports as the need arises. But, as I said elsewhere, configure.universal_archs should be changed to just the two 32-bit architectures, and then the "merge" function should be changed to use configure.universal_archs instead of its own list of architectures. From afb at macports.org Wed Jan 16 23:44:48 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Wed Jan 16 23:44:21 2008 Subject: 2-architecture +universal variants please (was: Re: [32999] trunk/base/ChangeLog) In-Reply-To: <943fadb9e468046c48154a810629d2c1@macports.org> References: <20080116125553.8B1E2A3ABB4@beta.macosforge.org> <943fadb9e468046c48154a810629d2c1@macports.org> Message-ID: > It's OK to build 64-bit universals if desired, but it should not be > the default and it should be configurable - and if it builds 32-bit > binaries without +universal, it should build with it too. Also, it would be more "universal" if it was to use the 10.4u SDK on Leopard too, since then the generated binaries would work on Tiger in addition. (currently it uses the 10.5 SDK if available) --anders From guido.soranzio at gmail.com Thu Jan 17 00:28:54 2008 From: guido.soranzio at gmail.com (Guido Soranzio) Date: Thu Jan 17 00:28:21 2008 Subject: 32937] trunk/dports/gnome/evince/Portfile Message-ID: <801E3CF8-2120-4CF9-9CE6-9AA48F8A63D7@gmail.com> Randall Wood wrote: > You might want to note that for the GNOME project, packages > with a version x.y.z where y is an odd number are normally > considered unstable, not fit for daily use. When I submitted the patch to make djvulibre compile again by adding the -dylib_file option to the linker (as recently suggested by Apple QA1567 for all the programs using OpenGL), I noticed that in evince 2.11.1 the support for this format is active by default and it was very simple to add a "djvu" variant by simply requiring the presence of djvulibre in the system, I am not having the problem in compiling evince as reported by other users and, yes, I know that the Gnome 2.(2*n)+1.z releases are in preparation for the upcoming 2.2*(n+1).0 stable release but, looking at the changelog of evince, it seemed that their release process is quite different from the rest of the Gnome libraries and that a lot of bugs were fixed. There are more, much more serious problems in Gnome at the moment: until my latest patches to PyGTK, I couldn't even compile it under Leopard and running it is still a painful experience. I am noticing small improvements with every new release candidate that the Xquartz team is lately releasing but many broken things are still to be restored. Thanks to my workaround to another issue regarding missing symbols, now I am able to run Nautilus for the fist time. Gnome-control-center, which was providing the Nautilus extensions with the missing symbols, is still far from be working correctly in Leopard and probably will never be. From ryandesign at macports.org Thu Jan 17 00:34:41 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Jan 17 00:34:08 2008 Subject: 2-architecture +universal variants please (was: Re: [32999] trunk/base/ChangeLog) In-Reply-To: References: <20080116125553.8B1E2A3ABB4@beta.macosforge.org> <943fadb9e468046c48154a810629d2c1@macports.org> Message-ID: On Jan 17, 2008, at 01:44, Anders F Bj?rklund wrote: >> It's OK to build 64-bit universals if desired, but it should not >> be the default and it should be configurable - and if it builds 32- >> bit binaries without +universal, it should build with it too. > > Also, it would be more "universal" if it was to use the 10.4u SDK > on Leopard too, since then the generated binaries would work on > Tiger in addition. (currently it uses the 10.5 SDK if available) Yes, but I understood that it was changed to use the 10.5 SDK on Leopard because using the 10.4u SDK on Leopard was broken? From afb at macports.org Thu Jan 17 00:46:14 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu Jan 17 00:45:39 2008 Subject: 2-architecture +universal variants please (was: Re: [32999] trunk/base/ChangeLog) In-Reply-To: References: <20080116125553.8B1E2A3ABB4@beta.macosforge.org> <943fadb9e468046c48154a810629d2c1@macports.org> Message-ID: <975d71f3d75b062c362d67ed88cfe0e0@macports.org> Ryan Schmidt wrote: >> Also, it would be more "universal" if it was to use the 10.4u SDK on >> Leopard too, since then the generated binaries would work on Tiger in >> addition. (currently it uses the 10.5 SDK if available) > > Yes, but I understood that it was changed to use the 10.5 SDK on > Leopard because using the 10.4u SDK on Leopard was broken? No, the usage of it was broken. It wasn't setting MACOSX_DEPLOYMENT_TARGET (to use 10.4) "ld: library not found for -lcrt1.10.5.o" Changing to the 10.5 SDK made the problem "go away", since it would work with M_D_T=10.5 --anders From ryandesign at macports.org Thu Jan 17 00:58:35 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Jan 17 00:58:02 2008 Subject: 2-architecture +universal variants please (was: Re: [32999] trunk/base/ChangeLog) In-Reply-To: <975d71f3d75b062c362d67ed88cfe0e0@macports.org> References: <20080116125553.8B1E2A3ABB4@beta.macosforge.org> <943fadb9e468046c48154a810629d2c1@macports.org> <975d71f3d75b062c362d67ed88cfe0e0@macports.org> Message-ID: On Jan 17, 2008, at 02:46, Anders F Bj?rklund wrote: > Ryan Schmidt wrote: > >>> Also, it would be more "universal" if it was to use the 10.4u SDK >>> on Leopard too, since then the generated binaries would work on >>> Tiger in addition. (currently it uses the 10.5 SDK if available) >> >> Yes, but I understood that it was changed to use the 10.5 SDK on >> Leopard because using the 10.4u SDK on Leopard was broken? > > No, the usage of it was broken. It wasn't setting > MACOSX_DEPLOYMENT_TARGET (to use 10.4) > > "ld: library not found for -lcrt1.10.5.o" > > Changing to the 10.5 SDK made the problem "go away", since it would > work with M_D_T=10.5 Oh I see! Then yes, by all means, we should use the 10.4u SDK and set MACOSX_DEPLOYMENT_TARGET to 10.4. From rsync at reifferscheid.org Thu Jan 17 01:21:41 2008 From: rsync at reifferscheid.org (Thomas Reifferscheid) Date: Thu Jan 17 01:21:03 2008 Subject: [33003] trunk/dports/lang In-Reply-To: <6FB3386F-2668-405B-9A06-A4A3EA0107C9@macports.org> References: <20080116160912.671F5A43659@beta.macosforge.org> <6FB3386F-2668-405B-9A06-A4A3EA0107C9@macports.org> Message-ID: <478F1E25.50307@reifferscheid.org> Hi Ryan, am I supposed to take r33003 back or fix the +configure {} line in another (new) revision? Kind regards Thomas Ryan Schmidt wrote: > On Jan 16, 2008, at 10:09, reiffert@macports.org wrote: > >> +configure {} > > You should use "use_configure no" instead of "configure {}". You may > also want "universal_variant no" or provide another solution for > universal building. > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev From ryandesign at macports.org Thu Jan 17 01:31:21 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Jan 17 01:30:55 2008 Subject: [33003] trunk/dports/lang In-Reply-To: <478F1DA4.5080404@macports.org> References: <20080116160912.671F5A43659@beta.macosforge.org> <6FB3386F-2668-405B-9A06-A4A3EA0107C9@macports.org> <478F1DA4.5080404@macports.org> Message-ID: <25936B6B-4A1C-4045-B9E1-AD2FBB08B45C@macports.org> You can just make the change in a new revision. On Jan 17, 2008, at 03:19, Thomas Reifferscheid wrote: > Hi Ryan, > > am I supposed to take r33003 back or > fix the +configure {} line in another (new) revision? > > Kind regards > Thomas > > Ryan Schmidt wrote: > >> On Jan 16, 2008, at 10:09, reiffert@macports.org wrote: >> >>> +configure {} >> >> You should use "use_configure no" instead of "configure {}". You >> may also want "universal_variant no" or provide another solution >> for universal building. From opendarwin.org at darkart.com Thu Jan 17 08:44:25 2008 From: opendarwin.org at darkart.com (Eric Hall) Date: Thu Jan 17 08:43:46 2008 Subject: 2-architecture +universal variants please (was: Re: [32999] trunk/base/ChangeLog) In-Reply-To: References: <20080116125553.8B1E2A3ABB4@beta.macosforge.org> <943fadb9e468046c48154a810629d2c1@macports.org> <975d71f3d75b062c362d67ed88cfe0e0@macports.org> Message-ID: <20080117164425.GH5860@darkart.com> On Thu, Jan 17, 2008 at 02:58:35AM -0600, Ryan Schmidt wrote: > > On Jan 17, 2008, at 02:46, Anders F Bj?rklund wrote: > > >Ryan Schmidt wrote: > > > >>>Also, it would be more "universal" if it was to use the 10.4u SDK > >>>on Leopard too, since then the generated binaries would work on > >>>Tiger in addition. (currently it uses the 10.5 SDK if available) > >> > >>Yes, but I understood that it was changed to use the 10.5 SDK on > >>Leopard because using the 10.4u SDK on Leopard was broken? > > > >No, the usage of it was broken. It wasn't setting > >MACOSX_DEPLOYMENT_TARGET (to use 10.4) > > > >"ld: library not found for -lcrt1.10.5.o" > > > >Changing to the 10.5 SDK made the problem "go away", since it would > >work with M_D_T=10.5 > > Oh I see! Then yes, by all means, we should use the 10.4u SDK and set > MACOSX_DEPLOYMENT_TARGET to 10.4. > Mmm, this sounds like the idea is "build for Tiger if we're on Leopard" even if the user will never use the ports on Tiger. What's being given up by using the 10.4 SDK instead of 10.5 (i.e. what fixes, enhancements, etc.)? If there's no real difference, fine. If there is a difference, I think it should be an option for those who are going to build on Leopard and share with Tiger systems, otherwise use the platform-native SDKs. -eric From jmpp at macports.org Thu Jan 17 09:08:24 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Thu Jan 17 09:05:51 2008 Subject: 2-architecture +universal variants please (was: Re: [32999] trunk/base/ChangeLog) In-Reply-To: <20080117164425.GH5860@darkart.com> References: <20080116125553.8B1E2A3ABB4@beta.macosforge.org> <943fadb9e468046c48154a810629d2c1@macports.org> <975d71f3d75b062c362d67ed88cfe0e0@macports.org> <20080117164425.GH5860@darkart.com> Message-ID: On Jan 17, 2008, at 12:14 PM, Eric Hall wrote: > On Thu, Jan 17, 2008 at 02:58:35AM -0600, Ryan Schmidt wrote: >> >> On Jan 17, 2008, at 02:46, Anders F Bj?rklund wrote: >> >>> Ryan Schmidt wrote: >>> >>>>> Also, it would be more "universal" if it was to use the 10.4u SDK >>>>> on Leopard too, since then the generated binaries would work on >>>>> Tiger in addition. (currently it uses the 10.5 SDK if available) >>>> >>>> Yes, but I understood that it was changed to use the 10.5 SDK on >>>> Leopard because using the 10.4u SDK on Leopard was broken? >>> >>> No, the usage of it was broken. It wasn't setting >>> MACOSX_DEPLOYMENT_TARGET (to use 10.4) >>> >>> "ld: library not found for -lcrt1.10.5.o" >>> >>> Changing to the 10.5 SDK made the problem "go away", since it would >>> work with M_D_T=10.5 >> >> Oh I see! Then yes, by all means, we should use the 10.4u SDK and set >> MACOSX_DEPLOYMENT_TARGET to 10.4. >> > > Mmm, this sounds like the idea is "build for Tiger if we're > on Leopard" even if the user will never use the ports on Tiger. > What's being given up by using the 10.4 SDK instead of 10.5 (i.e. > what fixes, enhancements, etc.)? > If there's no real difference, fine. If there is a difference, > I think it should be an option for those who are going to build on > Leopard and share with Tiger systems, otherwise use the platform- > native > SDKs. > > > -eric Seconded all the way! We could have macports.conf settings for both, a) the OS's the users wishes to build for, Leopard and/or Tiger and/or Panther, and b) the desired architectures, Intel and/or PowerPc and 32 and/or 64 bits. But in the mean time, while we still don't have that level of abstraction (we don't, right?), it seems more logical to me to build as native as possible. Now, universal advocates, hold your horses! I'm not arguing against universal support itself; I am arguing, though, against universal support hampering in any way native builds, which I'm positive is what a considerable majority of MacPorts users do and need. Regards,... -jmpp From ryandesign at macports.org Thu Jan 17 09:15:25 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Jan 17 09:14:52 2008 Subject: 2-architecture +universal variants please (was: Re: [32999] trunk/base/ChangeLog) In-Reply-To: References: <20080116125553.8B1E2A3ABB4@beta.macosforge.org> <943fadb9e468046c48154a810629d2c1@macports.org> <975d71f3d75b062c362d67ed88cfe0e0@macports.org> <20080117164425.GH5860@darkart.com> Message-ID: <15BC78D9-EBF6-42B5-9273-A809D731C0E8@macports.org> On Jan 17, 2008, at 11:08, Juan Manuel Palacios wrote: > On Jan 17, 2008, at 12:14 PM, Eric Hall wrote: > >> On Thu, Jan 17, 2008 at 02:58:35AM -0600, Ryan Schmidt wrote: >> >>> On Jan 17, 2008, at 02:46, Anders F Bj?rklund wrote: >>> >>>> Ryan Schmidt wrote: >>>> >>>>>> Also, it would be more "universal" if it was to use the 10.4u SDK >>>>>> on Leopard too, since then the generated binaries would work on >>>>>> Tiger in addition. (currently it uses the 10.5 SDK if available) >>>>> >>>>> Yes, but I understood that it was changed to use the 10.5 SDK on >>>>> Leopard because using the 10.4u SDK on Leopard was broken? >>>> >>>> No, the usage of it was broken. It wasn't setting >>>> MACOSX_DEPLOYMENT_TARGET (to use 10.4) >>>> >>>> "ld: library not found for -lcrt1.10.5.o" >>>> >>>> Changing to the 10.5 SDK made the problem "go away", since it would >>>> work with M_D_T=10.5 >>> >>> Oh I see! Then yes, by all means, we should use the 10.4u SDK and >>> set >>> MACOSX_DEPLOYMENT_TARGET to 10.4. >> >> Mmm, this sounds like the idea is "build for Tiger if we're >> on Leopard" even if the user will never use the ports on Tiger. >> What's being given up by using the 10.4 SDK instead of 10.5 (i.e. >> what fixes, enhancements, etc.)? >> If there's no real difference, fine. If there is a difference, >> I think it should be an option for those who are going to build on >> Leopard and share with Tiger systems, otherwise use the platform- >> native >> SDKs. > > Seconded all the way! > > We could have macports.conf settings for both, a) the OS's the > users wishes to build for, Leopard and/or Tiger and/or Panther, and > b) the desired architectures, Intel and/or PowerPc and 32 and/or 64 > bits. But in the mean time, while we still don't have that level of > abstraction (we don't, right?), it seems more logical to me to > build as native as possible. Now, universal advocates, hold your > horses! I'm not arguing against universal support itself; I am > arguing, though, against universal support hampering in any way > native builds, which I'm positive is what a considerable majority > of MacPorts users do and need. The SDK is only used to build a universal binary, when using the +universal variant. The only users who will be using that option are those who by definition want to share the binary with other machines. Ok, maybe they want to share the binary only between Leopard machines. But I still think it's a relatively safe assumption to use the 10.4u SDK when building a universal binary. Until we start having ports for Leopard-only applications... As it is now, a port built +universal on Leopard is different from a port built +universal on Tiger, and that tastes wrong. But maybe that's just the way it has to be? What will happen when we get binary packages of ports? Will we have to have separate binaries for each cat? I guess maybe we will. We already have the problem that ports built +universal on Tiger won't be usable on Panther, so we'd need separate binaries for Panther anyway. From simon at ruderich.com Thu Jan 17 09:25:32 2008 From: simon at ruderich.com (Simon Ruderich) Date: Thu Jan 17 09:54:08 2008 Subject: tetex/texlive dependencies In-Reply-To: <478EF5F4.2050300@root.id.au> References: <16E5B12E-C2CD-49AA-91A2-089920BE2A65@macports.org> <356D3161-B877-420B-BA13-29151D154BC3@macports.org> <20080114091811.GA4002@weetamoe.loria.fr> <9369365D-EBDF-4569-9AD7-E53D6E64D595@macports.org> <20080114223220.GA28838@ruderich.com> <478EF5F4.2050300@root.id.au> Message-ID: <20080117172504.GA15817@ruderich.com> On Thu, Jan 17, 2008 at 05:30:12PM +1100, Joshua Root wrote: > > I've made a patch for those and attached it to ticket #12913. I used the > dependency style suggested by Ryan. > > > > Has someone mailed the maintainers of the other affected ports? > > Cheers, > Josh Hi, thanks for your patch. It looks good, but we have to test each port before updating it. I just mailed the maintainers. Simon -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080117/1bbc7f63/attachment.bin From jmpp at macports.org Thu Jan 17 21:46:52 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Thu Jan 17 21:44:13 2008 Subject: Milestoning duplicate tickets? Message-ID: Some of us are clashing on Trac: in one corner, those who keep duplicate tickets and/or set them to appropriate milestones; in the other corner, those (read, only me, I think) who take them out of milestones when encountering them. The way I see it, if the ticket is a duplicate of an "original" one, and said original is already properly milestoned, then what's the benefit of also having the duplicate in the same milestone? And if said original is *not* properly milestoned, then it should be ;-) But that's of course only one side of the ring. What does the other side have to say about it? Regards,... -jmpp From ryandesign at macports.org Thu Jan 17 21:51:10 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Jan 17 21:50:36 2008 Subject: Milestoning duplicate tickets? In-Reply-To: References: Message-ID: <4A3654CB-D61C-4CEF-AAFF-9CC4B9E70EC5@macports.org> On Jan 17, 2008, at 23:46, Juan Manuel Palacios wrote: > Some of us are clashing on Trac: in one corner, those who keep > duplicate tickets and/or set them to appropriate milestones; in the > other corner, those (read, only me, I think) who take them out of > milestones when encountering them. > > The way I see it, if the ticket is a duplicate of an "original" > one, and said original is already properly milestoned, then what's > the benefit of also having the duplicate in the same milestone? And > if said original is *not* properly milestoned, then it should be ;-) > > But that's of course only one side of the ring. What does the > other side have to say about it? Why shouldn't all tickets (even duplicate tickets) have the correct milestone? From wsiegrist at apple.com Thu Jan 17 21:56:26 2008 From: wsiegrist at apple.com (William Siegrist) Date: Thu Jan 17 21:57:18 2008 Subject: Milestoning duplicate tickets? In-Reply-To: <4A3654CB-D61C-4CEF-AAFF-9CC4B9E70EC5@macports.org> References: <4A3654CB-D61C-4CEF-AAFF-9CC4B9E70EC5@macports.org> Message-ID: I agree with Ryan, but are you also saying you also keep them "open"? Is there a reason for having multiple tickets open for the same issue? -Bill On Jan 17, 2008, at 9:51 PM, Ryan Schmidt wrote: > > On Jan 17, 2008, at 23:46, Juan Manuel Palacios wrote: > >> Some of us are clashing on Trac: in one corner, those who keep >> duplicate tickets and/or set them to appropriate milestones; in the >> other corner, those (read, only me, I think) who take them out of >> milestones when encountering them. >> >> The way I see it, if the ticket is a duplicate of an "original" >> one, and said original is already properly milestoned, then what's >> the benefit of also having the duplicate in the same milestone? And >> if said original is *not* properly milestoned, then it should be ;-) >> >> But that's of course only one side of the ring. What does the >> other side have to say about it? > > Why shouldn't all tickets (even duplicate tickets) have the correct > milestone? > > > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev ---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist@apple.com 408 862 7337 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080117/ea1788df/smime.bin From jmpp at macports.org Thu Jan 17 22:28:48 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Thu Jan 17 22:26:07 2008 Subject: Milestoning duplicate tickets? In-Reply-To: References: <4A3654CB-D61C-4CEF-AAFF-9CC4B9E70EC5@macports.org> Message-ID: <112ADECF-A039-476E-9249-3AE85B78048E@macports.org> On Jan 18, 2008, at 1:26 AM, William Siegrist wrote: > I agree with Ryan, but are you also saying you also keep them > "open"? Is there a reason for having multiple tickets open for the > same issue? > > -Bill > > No, if they're duplicates then they are closed, already dealt with. But I believe there's no point in either putting them in a milestone or keeping them in it if there's already one ticket there, the "original", that describes the same issue. There's the "original" and the others are just fat, bloat, in my opinion. The Adium team handles the issue by creating a milestone specifically for duplicate tickets, regardless of the program component they were filed against... but I don't think I like that approach too much either. -jmpp > > > On Jan 17, 2008, at 9:51 PM, Ryan Schmidt wrote: > >> >> On Jan 17, 2008, at 23:46, Juan Manuel Palacios wrote: >> >>> Some of us are clashing on Trac: in one corner, those who keep >>> duplicate tickets and/or set them to appropriate milestones; in >>> the other corner, those (read, only me, I think) who take them out >>> of milestones when encountering them. >>> >>> The way I see it, if the ticket is a duplicate of an "original" >>> one, and said original is already properly milestoned, then what's >>> the benefit of also having the duplicate in the same milestone? >>> And if said original is *not* properly milestoned, then it should >>> be ;-) >>> >>> But that's of course only one side of the ring. What does the >>> other side have to say about it? >> >> Why shouldn't all tickets (even duplicate tickets) have the correct >> milestone? >> From jmpp at macports.org Thu Jan 17 22:57:08 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Thu Jan 17 22:54:28 2008 Subject: 2-architecture +universal variants please (was: Re: [32999] trunk/base/ChangeLog) In-Reply-To: <15BC78D9-EBF6-42B5-9273-A809D731C0E8@macports.org> References: <20080116125553.8B1E2A3ABB4@beta.macosforge.org> <943fadb9e468046c48154a810629d2c1@macports.org> <975d71f3d75b062c362d67ed88cfe0e0@macports.org> <20080117164425.GH5860@darkart.com> <15BC78D9-EBF6-42B5-9273-A809D731C0E8@macports.org> Message-ID: <2258AFA7-FE08-41EA-87D3-89DFD2E5980A@macports.org> On Jan 17, 2008, at 12:45 PM, Ryan Schmidt wrote: >>> Mmm, this sounds like the idea is "build for Tiger if we're >>> on Leopard" even if the user will never use the ports on Tiger. >>> What's being given up by using the 10.4 SDK instead of 10.5 (i.e. >>> what fixes, enhancements, etc.)? >>> If there's no real difference, fine. If there is a difference, >>> I think it should be an option for those who are going to build on >>> Leopard and share with Tiger systems, otherwise use the platform- >>> native >>> SDKs. >> >> Seconded all the way! >> >> We could have macports.conf settings for both, a) the OS's the >> users wishes to build for, Leopard and/or Tiger and/or Panther, and >> b) the desired architectures, Intel and/or PowerPc and 32 and/or 64 >> bits. But in the mean time, while we still don't have that level of >> abstraction (we don't, right?), it seems more logical to me to >> build as native as possible. Now, universal advocates, hold your >> horses! I'm not arguing against universal support itself; I am >> arguing, though, against universal support hampering in any way >> native builds, which I'm positive is what a considerable majority >> of MacPorts users do and need. > > The SDK is only used to build a universal binary, when using the > +universal variant. The only users who will be using that option are > those who by definition want to share the binary with other > machines. Ok, maybe they want to share the binary only between > Leopard machines. But I still think it's a relatively safe > assumption to use the 10.4u SDK when building a universal binary. > Until we start having ports for Leopard-only applications... Oohhh, I see, wasn't too aware that these SDKs are used only for universal builds. Sorry for commenting rather blindly, maybe I should have looked at the source before posting. So, in this case, I wouldn't be opposed to using the Tiger SDK when building universal on Leopard, although it'd still be advisable finding out if there are any major losses to doing, as Eric questioned originally. Going forward, what I'd really like to see is an abstraction of these settings into macports.conf. Anders tells me there are three important settings to look after: 1) sysroot, the SDK employed; 2) MACOSX_DEPLOYMENT_TARGET: what's the state of these at the moment, what are we using? 3) archs, 32 Vs. 64 bits: according to Anders' last change, we're back at building only 32 bits for both Intel and PowerPC, which is what I believe we should stick to until we figure out a transparent migration path to 4-way built binaries. We should ship 1.6.1 with the most sensible possible set of defaults for all these three settings and then work toward abstracting them into macports.conf keys. > > > As it is now, a port built +universal on Leopard is different from a > port built +universal on Tiger, and that tastes wrong. Different how? Sorry if it's been discussed already and I'm just not keeping up with this topic. The way I understand it, there are two approaches: *) 1st: build universal but solely for Tiger, then I'd expect the binary to work either on Intel or PowerPC, but in both cases on Tiger only; build universal but solely for Leopard, then I'd expect the same thing from the binary, but on Leopard in this case. *) 2nd: we could certainly switch the SDK to 10.4 on Leopard, but then a binary built in this environment would work on any combination of Tiger and/or Leopard with PowerPC and/or Intel; on the other hand, a binary built universal on Tiger would not enjoy the same diversity, and this does constitute different "universal realities" (long live String Theory!), depending on the production environment. Maybe I'm universal impaired, but I don't see a clear winner between either one. What makes more sense and why? Or am I just smoking crack with my understanding of the problem and not get one bit the "As it is now, a port built +universal on Leopard is different from a port built +universal on Tiger" assertion? > But maybe that's just the way it has to be? What will happen when we > get binary packages of ports? Will we have to have separate binaries > for each cat? I guess this exercise helps us prepare for the case scenario of not finding enough support to get all the needed hardware when the time comes ;-) PowerPC will eventually fade away, but the choice of multiple cats will always be with us. > I guess maybe we will. We already have the problem that ports built > +universal on Tiger won't be usable on Panther, so we'd need > separate binaries for Panther anyway. Yes, certainly, but that's the boundary where you draw the line and start cutting the fat. If not, they we'd have to think about a way to build "universal" binaries on Panther that would work on Jaguar, and... uuuggghhh, don't even want to think about it!!!! Regards,... -jmpp From guido.soranzio at gmail.com Thu Jan 17 23:37:42 2008 From: guido.soranzio at gmail.com (Guido Soranzio) Date: Thu Jan 17 23:37:06 2008 Subject: /opt/local/bin/python2.5 as default MacPorts' "python" interpreter Message-ID: Currently there is no official "python" interpreter for MacPorts (in the past there was a link to python2.3 even when python24 was installed, IIRC) but many Python programs (or their shebang lines) expect a "python" command in the PATH, otherwise Leopard's python2.5 is picked from its symbolic link "/usr/bin/python" and they don't work correctly. This is the case, for example, of Sudoku and Chess in gnome-games. I think that, similarly to the destroot phase of Tcl (ln -s ${prefix}/bin/tclsh8.5 ${destroot}${prefix}/bin/tclsh) an "/opt/local/bin/python" link should be created pointing to the 2.5 version, as MacPorts' "default" Python version. From afb at macports.org Fri Jan 18 01:34:37 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Fri Jan 18 01:34:03 2008 Subject: /opt/local/bin/python2.5 as default MacPorts' "python" interpreter In-Reply-To: References: Message-ID: <827540ea365107e1a3ff9245292727cd@macports.org> Guido Soranzio wrote: > Currently there is no official "python" interpreter for MacPorts > (in the past there was a link to python2.3 even when python24 > was installed, IIRC) but many Python programs (or their shebang lines) > expect a "python" command in the PATH, otherwise Leopard's python2.5 > is picked from its symbolic link "/usr/bin/python" and they don't work > correctly. Or Tiger's python2.3 is picked, and it works even less correctly... (or alternatively python2.5, from python.org and /usr/local/bin) > This is the case, for example, of Sudoku and Chess in gnome-games. And a lot of other ports have been patched, to avoid any use of the "python" command directly (this has been something of a pain to do) > I think that, similarly to the destroot phase of Tcl > > (ln -s ${prefix}/bin/tclsh8.5 ${destroot}${prefix}/bin/tclsh) > > an "/opt/local/bin/python" link should be created pointing to > the 2.5 version, as MacPorts' "default" Python version. The /opt/local/bin/python was leading to "python24", which was the default MacPorts Python version. The decision was made to move to python_select instead, and not have any default at all. http://lists.macosforge.org/pipermail/macports-dev/2007-August/ 002547.html So currently the initial setup with python_select(8) is mandatory... But I think it was a mistake to remove the default python version, and we should probably upgrade python to 2.5 - and perl to 5.10 ? --anders From randall.h.wood at alexandriasoftware.com Fri Jan 18 02:03:36 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Fri Jan 18 02:03:06 2008 Subject: /opt/local/bin/python2.5 as default MacPorts' "python" interpreter In-Reply-To: <827540ea365107e1a3ff9245292727cd@macports.org> References: <827540ea365107e1a3ff9245292727cd@macports.org> Message-ID: <709C2D53-7276-4FF8-B6B7-5589FBCCDCD4@alexandriasoftware.com> A number of portfiles also just set the configure.env variable PYTHON=$ {prefix}/bin/python2.5 Is there any reason this can not be made part of the default environment for port? On 18 Jan 2008, at 04:34, Anders F Bj?rklund wrote: > Guido Soranzio wrote: > >> Currently there is no official "python" interpreter for MacPorts >> (in the past there was a link to python2.3 even when python24 >> was installed, IIRC) but many Python programs (or their shebang >> lines) >> expect a "python" command in the PATH, otherwise Leopard's python2.5 >> is picked from its symbolic link "/usr/bin/python" and they don't >> work >> correctly. > > Or Tiger's python2.3 is picked, and it works even less correctly... > (or alternatively python2.5, from python.org and /usr/local/bin) > >> This is the case, for example, of Sudoku and Chess in gnome-games. > > And a lot of other ports have been patched, to avoid any use of the > "python" command directly (this has been something of a pain to do) > >> I think that, similarly to the destroot phase of Tcl >> >> (ln -s ${prefix}/bin/tclsh8.5 ${destroot}${prefix}/bin/tclsh) >> >> an "/opt/local/bin/python" link should be created pointing to >> the 2.5 version, as MacPorts' "default" Python version. > > The /opt/local/bin/python was leading to "python24", which was > the default MacPorts Python version. The decision was made to > move to python_select instead, and not have any default at all. > > http://lists.macosforge.org/pipermail/macports-dev/2007-August/002547.html > > So currently the initial setup with python_select(8) is mandatory... > But I think it was a mistake to remove the default python version, > and we should probably upgrade python to 2.5 - and perl to 5.10 ? > > --anders > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev Randall Wood randall.h.wood@alexandriasoftware.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 milosh at macports.org Fri Jan 18 02:29:23 2008 From: milosh at macports.org (Emmanuel Hainry) Date: Fri Jan 18 02:28:54 2008 Subject: /opt/local/bin/python2.5 as default MacPorts' "python" interpreter In-Reply-To: <827540ea365107e1a3ff9245292727cd@macports.org> References: <827540ea365107e1a3ff9245292727cd@macports.org> Message-ID: <20080118102923.GA3695@weetamoe.loria.fr> Citando Anders F Bj?rklund : > Guido Soranzio wrote: > >> Currently there is no official "python" interpreter for MacPorts >> (in the past there was a link to python2.3 even when python24 >> was installed, IIRC) but many Python programs (or their shebang lines) >> expect a "python" command in the PATH, otherwise Leopard's python2.5 >> is picked from its symbolic link "/usr/bin/python" and they don't work >> correctly. > > Or Tiger's python2.3 is picked, and it works even less correctly... > (or alternatively python2.5, from python.org and /usr/local/bin) > >> This is the case, for example, of Sudoku and Chess in gnome-games. > > And a lot of other ports have been patched, to avoid any use of the > "python" command directly (this has been something of a pain to do) > >> I think that, similarly to the destroot phase of Tcl >> >> (ln -s ${prefix}/bin/tclsh8.5 ${destroot}${prefix}/bin/tclsh) >> >> an "/opt/local/bin/python" link should be created pointing to >> the 2.5 version, as MacPorts' "default" Python version. > > The /opt/local/bin/python was leading to "python24", which was > the default MacPorts Python version. The decision was made to > move to python_select instead, and not have any default at all. > > http://lists.macosforge.org/pipermail/macports-dev/2007-August/ > 002547.html > > So currently the initial setup with python_select(8) is mandatory... > But I think it was a mistake to remove the default python version, > and we should probably upgrade python to 2.5 - and perl to 5.10 ? > So, for a port that works well with tiger's python2.3, leopard's python2.5 and macports' python2.3, 2.4 or 2.5, the correct dependency would be port:python_select or bin:python:python_select? And the python to choose ${prefix}/bin/python or the first python in the PATH? Emmanuel From raimue at macports.org Fri Jan 18 03:21:25 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri Jan 18 03:20:46 2008 Subject: /opt/local/bin/python2.5 as default MacPorts' "python" interpreter In-Reply-To: <20080118102923.GA3695@weetamoe.loria.fr> References: <827540ea365107e1a3ff9245292727cd@macports.org> <20080118102923.GA3695@weetamoe.loria.fr> Message-ID: <47908BB5.2020300@macports.org> Emmanuel Hainry wrote: > So, for a port that works well with tiger's python2.3, leopard's > python2.5 and macports' python2.3, 2.4 or 2.5, the correct dependency > would be port:python_select or bin:python:python_select? And the > python to choose ${prefix}/bin/python or the first python in the > PATH? No, because python_select does not depend on any specific python version. It is used to make symlinks for already installed python version. Although the select files which are currently in python_select/files should be moved into the appropriate ports. The purpose of python_select is to give the user the choice which python version they want to run when typing in "python" or by #!/usr/bin/env python. Rainer From afb at macports.org Fri Jan 18 04:39:22 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Fri Jan 18 04:39:01 2008 Subject: /opt/local/bin/python2.5 as default MacPorts' "python" interpreter In-Reply-To: <47908BB5.2020300@macports.org> References: <827540ea365107e1a3ff9245292727cd@macports.org> <20080118102923.GA3695@weetamoe.loria.fr> <47908BB5.2020300@macports.org> Message-ID: Rainer M?ller wrote: > The purpose of python_select is to give the user the choice which > python version they want to run when typing in "python" or by > #!/usr/bin/env python. The default, however, with or without python-select is now: /usr/bin/python. But it seems that it is missing a "python25-apple" selection for Leopard, so default selection there is /usr/bin/python2.3 (No such file or directory) --anders From raimue at macports.org Fri Jan 18 04:44:41 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri Jan 18 04:44:01 2008 Subject: /opt/local/bin/python2.5 as default MacPorts' "python" interpreter In-Reply-To: References: <827540ea365107e1a3ff9245292727cd@macports.org> <20080118102923.GA3695@weetamoe.loria.fr> <47908BB5.2020300@macports.org> Message-ID: <47909F39.9090200@macports.org> Anders F Bj?rklund wrote: > But it seems that it is missing a "python25-apple" selection for Leopard, > so default selection there is /usr/bin/python2.3 (No such file or > directory) Good catch. I will fix that. Rainer From dgou at mac.com Fri Jan 18 06:04:17 2008 From: dgou at mac.com (Douglas Philips) Date: Fri Jan 18 06:03:53 2008 Subject: /opt/local/bin/python2.5 as default MacPorts' "python" interpreter In-Reply-To: <47909F39.9090200@macports.org> References: <827540ea365107e1a3ff9245292727cd@macports.org> <20080118102923.GA3695@weetamoe.loria.fr> <47908BB5.2020300@macports.org> <47909F39.9090200@macports.org> Message-ID: Just a note that ticket #13452 is still open, so given that the gnome/ python 'which (python) version will be used where' is still not resolved (and I realize that involves several maintainers coordinating, so I am not complaining, just observing), I'm not terrribly sanguine about seeing the default python move up to 2.5, but I suppose that won't affect this underlying issue either way... --Doug From ryandesign at macports.org Fri Jan 18 14:08:40 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri Jan 18 14:08:06 2008 Subject: Milestoning duplicate tickets? In-Reply-To: <112ADECF-A039-476E-9249-3AE85B78048E@macports.org> References: <4A3654CB-D61C-4CEF-AAFF-9CC4B9E70EC5@macports.org> <112ADECF-A039-476E-9249-3AE85B78048E@macports.org> Message-ID: On Jan 18, 2008, at 00:28, Juan Manuel Palacios wrote: > On Jan 18, 2008, at 1:26 AM, William Siegrist wrote: > >> On Jan 17, 2008, at 9:51 PM, Ryan Schmidt wrote: >> >>> On Jan 17, 2008, at 23:46, Juan Manuel Palacios wrote: >>> >>>> Some of us are clashing on Trac: in one corner, those who keep >>>> duplicate tickets and/or set them to appropriate milestones; in >>>> the other corner, those (read, only me, I think) who take them >>>> out of milestones when encountering them. >>>> >>>> The way I see it, if the ticket is a duplicate of an "original" >>>> one, and said original is already properly milestoned, then >>>> what's the benefit of also having the duplicate in the same >>>> milestone? And if said original is *not* properly milestoned, >>>> then it should be ;-) >>>> >>>> But that's of course only one side of the ring. What does the >>>> other side have to say about it? >>> >>> Why shouldn't all tickets (even duplicate tickets) have the >>> correct milestone? >> >> I agree with Ryan, but are you also saying you also keep them >> "open"? Is there a reason for having multiple tickets open for the >> same issue? > > No, if they're duplicates then they are closed, already dealt with. > > But I believe there's no point in either putting them in a > milestone or keeping them in it if there's already one ticket > there, the "original", that describes the same issue. There's the > "original" and the others are just fat, bloat, in my opinion. > > The Adium team handles the issue by creating a milestone > specifically for duplicate tickets, regardless of the program > component they were filed against... but I don't think I like that > approach too much either. I think the natural thing to do, the thing that most people would think to do, would be to assign all tickets to their correct milestone, whether they are duplicates or not. If you want duplicates to have no milestone, I'll defer to your portmgr hat, but request that this be documented in the guide. Currently it says nothing about duplicate tickets. Having a "Duplicate Tickets" milestone would certainly make it clear that duplicate tickets should be placed in that milestone. However, I'm not sure I see why it's desirable to have duplicate tickets in a different (or no) milestone. From jkh at apple.com Sat Jan 19 16:17:53 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Sat Jan 19 16:18:05 2008 Subject: platform range and set arguments? Message-ID: <4E7D4720-E37B-4016-83C7-62B5C391BB56@apple.com> Hey all, I was just looking at the ghc port a few days ago, mostly in an attempt to figure out why it a-splode! on my 10.5 PPC system, and I noticed a lot of this: platform darwin 7 powerpc { ... } platform darwin 8 powerpc { ... } platform darwin 8 i386 { ... } And so on. It occurred to me that if "platform darwin 9 powerpc" (that's me) was going to duplicate a lot of the existing rules, maybe it would make more sense to introduce ranges and sets to the existing logic (I checked, and there's currently no support for it that a cursory glance indicated, anyway). Then we could do stuff like this: platform darwin [7-8] powerpc { ... } platform darwin 9 {powerpc, i386} { .. } And have far more concise portfiles. We might also have a platform_isset procedure so that you could do: platform darwin [7-9] { if {[platform_isset darwin 8]} { .. do some special tiger-only magic .. } ... more darwin generic foo here ... } Thoughts? If folks like the idea and nobody immediately jumps to do it, I might give the appropriate hacks a whack (eee! managers coding!). - Jordan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080119/cdbe28fd/attachment.html From kbrown0 at earugula.com Sat Jan 19 18:18:20 2008 From: kbrown0 at earugula.com (kevin brown) Date: Sat Jan 19 18:17:31 2008 Subject: Fwd: upgrading a port with no maintainer In-Reply-To: <65cdc62c0801191813g577fd97ckc880e1b7de2eaf21@mail.gmail.com> References: <65cdc62c0801191813g577fd97ckc880e1b7de2eaf21@mail.gmail.com> Message-ID: <65cdc62c0801191818n3fc4147am19c1bbf5f7f983a7@mail.gmail.com> Dev, Suppose I wanted to upgrade a version of a port with no maintainer,say, http://www.macports.org/ports.php?by=name&substr=pixen, from version 2.2 to 3.0. How might I go about making the change on my local box (leaving the submitting a patch process out for the time being)? Is there a doc you could point me to? I'm familiar with how to perform this task in gentoo, but not yet very familiar with macports. - Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080119/74fd67d9/attachment.html From jkh at apple.com Sat Jan 19 23:46:56 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Sat Jan 19 23:47:07 2008 Subject: upgrading a port with no maintainer In-Reply-To: <65cdc62c0801191818n3fc4147am19c1bbf5f7f983a7@mail.gmail.com> References: <65cdc62c0801191813g577fd97ckc880e1b7de2eaf21@mail.gmail.com> <65cdc62c0801191818n3fc4147am19c1bbf5f7f983a7@mail.gmail.com> Message-ID: <1F8DBED5-6058-4F08-807F-C6FAA9C4A4B0@apple.com> 1. Easy enough - just change the Portfile with "port edit ", make your changes, test/edit/repeat. 2. The submit process, however, should be a lot easier than it is. Today, you open a new trac ticket and attach your new Portfile asking "can somebody please commit this for me?" In a more ideal world, there would be a "port submit" command which caused far more magical things to happen. Whatever happened to the "port submit" project initiative anyway? Wasn't that supposed to come about for free with the remote index? :-) - Jordan On Jan 19, 2008, at 6:18 PM, kevin brown wrote: > > Dev, > > Suppose I wanted to upgrade a version of a port with no > maintainer,say, http://www.macports.org/ports.php? > by=name&substr=pixen, from version 2.2 to 3.0. How might I go about > making the change on my local box (leaving the submitting a patch > process out for the time being)? Is there a doc you could point me > to? I'm familiar with how to perform this task in gentoo, but not > yet very familiar with macports. > > - Kevin > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080119/7ba6f7e3/attachment.html From takeshi at enomosphere.net Sun Jan 20 04:47:14 2008 From: takeshi at enomosphere.net (Takeshi Enomoto) Date: Sun Jan 20 04:46:27 2008 Subject: libwww Message-ID: Hi, This ticket (libwww) has not been taken care of for a while. A package I maintain (science/grads) depends upon libwww. For grads, the contributed patch seems to be sufficient. However, I imagine that libwww should affect a number of packages. I would like to commit the patch and close the ticket for grads but I would like to hear opinions of those who maintain packages affected by libwww. Takeshi From ryandesign at macports.org Sun Jan 20 14:19:28 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun Jan 20 14:18:47 2008 Subject: upgrading a port with no maintainer In-Reply-To: <1F8DBED5-6058-4F08-807F-C6FAA9C4A4B0@apple.com> References: <65cdc62c0801191813g577fd97ckc880e1b7de2eaf21@mail.gmail.com> <65cdc62c0801191818n3fc4147am19c1bbf5f7f983a7@mail.gmail.com> <1F8DBED5-6058-4F08-807F-C6FAA9C4A4B0@apple.com> Message-ID: <2C9C8D98-DA84-46BF-BF41-852E87A08216@macports.org> On Jan 20, 2008, at 01:46, Jordan K. Hubbard wrote: > On Jan 19, 2008, at 6:18 PM, kevin brown wrote: > >> Suppose I wanted to upgrade a version of a port with no >> maintainer,say, http://www.macports.org/ports.php? >> by=name&substr=pixen, from version 2.2 to 3.0. How might I go >> about making the change on my local box (leaving the submitting a >> patch process out for the time being)? Is there a doc you could >> point me to? I'm familiar with how to perform this task in >> gentoo, but not yet very familiar with macports. > > 1. Easy enough - just change the Portfile with "port edit > ", make your changes, test/edit/repeat. [snip] The doc to refer you to is: http://guide.macports.org/ If you find it's unclear or doesn't contain the information you need, please point out how it could be improved. The guide authors are still refining it and would probably appreciate feedback. From jmpp at macports.org Mon Jan 21 06:15:56 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Mon Jan 21 06:13:13 2008 Subject: upgrading a port with no maintainer In-Reply-To: <1F8DBED5-6058-4F08-807F-C6FAA9C4A4B0@apple.com> References: <65cdc62c0801191813g577fd97ckc880e1b7de2eaf21@mail.gmail.com> <65cdc62c0801191818n3fc4147am19c1bbf5f7f983a7@mail.gmail.com> <1F8DBED5-6058-4F08-807F-C6FAA9C4A4B0@apple.com> Message-ID: <356F053F-D2FD-4A30-BC38-420519563282@macports.org> On Jan 20, 2008, at 3:16 AM, Jordan K. Hubbard wrote: > 1. Easy enough - just change the Portfile with "port edit > ", make your changes, test/edit/repeat. > > 2. The submit process, however, should be a lot easier than it is. > Today, you open a new trac ticket and attach your new Portfile > asking "can somebody please commit this for me?" In a more ideal > world, there would be a "port submit" command which caused far more > magical things to happen. > > Whatever happened to the "port submit" project initiative anyway? > Wasn't that supposed to come about for free with the remote index? :-) Sure, it was! Remote Index would have brought that and many other goodies. Sadly enough, remote index was never implemented, so we don't have them at present :-( Hope somebody steps up in the not too distant future to start doing some of the leg work ;-) So, as an alternative, our guidelines to submitting tickets are very well explained in this document: http://guide.macports.org/#project.tickets (regardless of the port having a maintainer or not). Regards,... -jmpp > > - Jordan > > On Jan 19, 2008, at 6:18 PM, kevin brown wrote: > >> >> Dev, >> >> Suppose I wanted to upgrade a version of a port with no >> maintainer,say, http://www.macports.org/ports.php?by=name&substr=pixen >> , from version 2.2 to 3.0. How might I go about making the change >> on my local box (leaving the submitting a patch process out for the >> time being)? Is there a doc you could point me to? I'm familiar >> with how to perform this task in gentoo, but not yet very familiar >> with macports. >> >> - Kevin >> _______________________________________________ >> macports-dev mailing list >> macports-dev@lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo/macports-dev > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080121/a0060297/attachment-0001.html From kvv at apple.com Mon Jan 21 14:25:15 2008 From: kvv at apple.com (Kevin Van Vechten) Date: Mon Jan 21 14:26:18 2008 Subject: upgrading a port with no maintainer In-Reply-To: <356F053F-D2FD-4A30-BC38-420519563282@macports.org> References: <65cdc62c0801191813g577fd97ckc880e1b7de2eaf21@mail.gmail.com> <65cdc62c0801191818n3fc4147am19c1bbf5f7f983a7@mail.gmail.com> <1F8DBED5-6058-4F08-807F-C6FAA9C4A4B0@apple.com> <356F053F-D2FD-4A30-BC38-420519563282@macports.org> Message-ID: On Jan 21, 2008, at 6:15 AM, Juan Manuel Palacios wrote: >> Whatever happened to the "port submit" project initiative anyway? >> Wasn't that supposed to come about for free with the remote >> index? :-) > > Sure, it was! Remote Index would have brought that and many other > goodies. Sadly enough, remote index was never implemented, so we > don't have them at present :-( Hope somebody steps up in the not too > distant future to start doing some of the leg work ;-) It was implemented, just never integrated ;) All the sources are in subversion, though probably suffering from bit-rot at this point. - Kevin From jberry at macports.org Mon Jan 21 15:19:58 2008 From: jberry at macports.org (James Berry) Date: Mon Jan 21 15:19:13 2008 Subject: upgrading a port with no maintainer In-Reply-To: References: <65cdc62c0801191813g577fd97ckc880e1b7de2eaf21@mail.gmail.com> <65cdc62c0801191818n3fc4147am19c1bbf5f7f983a7@mail.gmail.com> <1F8DBED5-6058-4F08-807F-C6FAA9C4A4B0@apple.com> <356F053F-D2FD-4A30-BC38-420519563282@macports.org> Message-ID: On Jan 21, 2008, at 2:25 PM, Kevin Van Vechten wrote: > > On Jan 21, 2008, at 6:15 AM, Juan Manuel Palacios wrote: > >>> Whatever happened to the "port submit" project initiative anyway? >>> Wasn't that supposed to come about for free with the remote >>> index? :-) >> >> Sure, it was! Remote Index would have brought that and many other >> goodies. Sadly enough, remote index was never implemented, so we >> don't have them at present :-( Hope somebody steps up in the not >> too distant future to start doing some of the leg work ;-) > > It was implemented, just never integrated ;) All the sources are in > subversion, though probably suffering from bit-rot at this point. Note that the some of this stuff is manifested in mpwa (look at http://db.macports.org ), which uses a (heavilly) modified version of Kevin's submit code to submit changes to the db. A cron job runs every 20 minutes (and has been for about 10 months now) to autosubmit any ports that have been changed and checked into svn. In a better world, any joe blow could simply run "port submit" to submit changes to a port. That almost (maybe does?) work right now. So mpwa can serve as the index, but we don't have any integration currently to query that index. Allowing generalized submission to mpwa would require a stronger implementation of user authentication and signing, which isn't too hard. Anyone interested should review the docs http://svn.macports.org/repository/macports/users/jberry/mpwa/doc/. I'd be happy to brainstorm, take criticism, answer questions, etc. The one thing I don't have right now, however, is the time to take this further just now (though I hope to in the indefinite and optimistic future). Others are welcome to pick this up, with appropriate discussion of course. James From ryandesign at macports.org Mon Jan 21 15:27:26 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Jan 21 15:26:44 2008 Subject: [33224] trunk/dports/devel/gtkglext/Portfile In-Reply-To: <20080121214049.8BD24B9E171@beta.macosforge.org> References: <20080121214049.8BD24B9E171@beta.macosforge.org> Message-ID: <4B52FCD0-8D9D-4D40-A720-5FEBAF375D48@macports.org> On Jan 21, 2008, at 15:40, rowue@macports.org wrote: > Revision: 33224 > http://trac.macosforge.org/projects/macports/changeset/33224 > Author: rowue@macports.org > Date: 2008-01-21 13:40:45 -0800 (Mon, 21 Jan 2008) > > Log Message: > ----------- > Appended Patch to enable build on OS X 10.5. > Closes #13624 > > Modified Paths: > -------------- > trunk/dports/devel/gtkglext/Portfile > > Modified: trunk/dports/devel/gtkglext/Portfile > =================================================================== > --- trunk/dports/devel/gtkglext/Portfile 2008-01-21 20:50:54 UTC > (rev 33223) > +++ trunk/dports/devel/gtkglext/Portfile 2008-01-21 21:40:45 UTC > (rev 33224) > @@ -17,3 +17,7 @@ > depends_lib port:gtk2 \ > lib:libGL.1:XFree86 > > +platform darwin 9 { > + darwin_9_glpath /System/Library/Frameworks/OpenGL.framework/ > Versions/A/Libraries > + configure.args --with-gl-libdir=${darwin_9_glpath} > +} If you're trying to define a local variable here, you should put "set" before it. set darwin_9_glpath /System/Library/whatever From rowue at digitalis.org Mon Jan 21 15:44:17 2008 From: rowue at digitalis.org (=?ISO-8859-1?Q?Rolf_W=FCrdemann?=) Date: Mon Jan 21 15:43:29 2008 Subject: [33224] trunk/dports/devel/gtkglext/Portfile In-Reply-To: <4B52FCD0-8D9D-4D40-A720-5FEBAF375D48@macports.org> References: <20080121214049.8BD24B9E171@beta.macosforge.org> <4B52FCD0-8D9D-4D40-A720-5FEBAF375D48@macports.org> Message-ID: Am 22.01.2008 um 00:27 schrieb Ryan Schmidt: > On Jan 21, 2008, at 15:40, rowue@macports.org wrote: > >> [...] > If you're trying to define a local variable here, you should put > "set" before it. > > set darwin_9_glpath /System/Library/whatever > Thanks! (Also for supervising) (But why it worked without? ;) reg's Rolf -- Security is an illusion - Datasecurity twice Rolf W?rdemann - private: rowue@digitalis.org - office: rowue@crew-gmbh.de GnuPG fingerprint: 7383 348F 67D1 CD27 C90F DDD0 86A3 31B6 67F0 D02F jabber: rowue@digitalis.org 2F66A061 89BCA1A0 AD654827 6FD037FF 53C3E932 -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: Signierter Teil der Nachricht Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080122/9d8fb2a9/PGP.bin From ryandesign at macports.org Mon Jan 21 15:47:13 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Jan 21 15:46:33 2008 Subject: [33224] trunk/dports/devel/gtkglext/Portfile In-Reply-To: References: <20080121214049.8BD24B9E171@beta.macosforge.org> <4B52FCD0-8D9D-4D40-A720-5FEBAF375D48@macports.org> Message-ID: <6E03B1E5-AF17-4C68-886D-56CF7A8147DF@macports.org> On Jan 21, 2008, at 17:44, Rolf W?rdemann wrote: > Am 22.01.2008 um 00:27 schrieb Ryan Schmidt: > >> On Jan 21, 2008, at 15:40, rowue@macports.org wrote: >> >>> [...] >> If you're trying to define a local variable here, you should put >> "set" before it. >> >> set darwin_9_glpath /System/Library/whatever > > Thanks! (Also for supervising) > > (But why it worked without? ;) I believe you instead created a global variable. Local variables are better because they can't conflict with other parts of MacPorts. From ryandesign at macports.org Tue Jan 22 03:20:03 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Jan 22 03:20:22 2008 Subject: [33255] trunk/dports/python/py25-orbit/Portfile In-Reply-To: <20080122105922.38BD6BB9094@beta.macosforge.org> References: <20080122105922.38BD6BB9094@beta.macosforge.org> Message-ID: On Jan 22, 2008, at 04:59, gui_dos@macports.org wrote: > Revision: 33255 > http://trac.macosforge.org/projects/macports/changeset/33255 > Author: gui_dos@macports.org > Date: 2008-01-22 02:59:20 -0800 (Tue, 22 Jan 2008) > > Log Message: > ----------- > Workaround for missing symbols on Leopard You also made lots of whitespace changes, so that it's difficult to see what functional changes you made. Please, if you want to make whitespace changes, commit them by themselves in a separate commit. > Modified Paths: > -------------- > trunk/dports/python/py25-orbit/Portfile > > Modified: trunk/dports/python/py25-orbit/Portfile > =================================================================== > --- trunk/dports/python/py25-orbit/Portfile 2008-01-22 10:58:53 UTC > (rev 33254) > +++ trunk/dports/python/py25-orbit/Portfile 2008-01-22 10:59:20 UTC > (rev 33255) > @@ -1,33 +1,40 @@ > # $Id$ > > PortSystem 1.0 > -name py25-orbit > -version 2.14.3 > -categories python gnome > -platforms darwin > -maintainers pguyot@kallisys.net > -description Python binding for the ORBit2 CORBA ORB - Default > branch. > -long_description PyORBit is a Python binding for the ORBit2 CORBA > ORB. It \ > - was developped to suit the needs of the bonobo bindings \ > - in GNOME-Python, but is usable for other purposes as well. \ > - It aims to follow the standard Python language mapping for \ > - CORBA. It can generate stubs at runtime from typelibs, IDL \ > - files, or by introspecting remote objects using ORBit2's \ > - IModule typelib capabilities. > +name py25-orbit > +version 2.14.3 > +revision 1 > +categories python gnome > +platforms darwin > +maintainers pguyot@kallisys.net > +description Python binding for the ORBit2 CORBA ORB - Default > branch. > +long_description PyORBit is a Python binding for the ORBit2 CORBA > ORB. It \ > + was developped to suit the needs of the bonobo > bindings \ > + in GNOME-Python, but is usable for other purposes > as well. \ > + It aims to follow the standard Python language > mapping for \ > + CORBA. It can generate stubs at runtime from > typelibs, IDL \ > + files, or by introspecting remote objects using > ORBit2's \ > + IModule typelib capabilities. > > -homepage http://www.pygtk.org/ > -master_sites gnome:sources/pyorbit/2.14/ > -use_bzip2 yes > -distname pyorbit-${version} > -checksums md5 3c4d42ae1a7303fd85071a842617043f > +homepage http://www.pygtk.org/ > +master_sites gnome:sources/pyorbit/2.14/ > +use_bzip2 yes > +distname pyorbit-${version} > +checksums md5 3c4d42ae1a7303fd85071a842617043f > > -depends_lib port:python25 \ > - port:orbit2 > +depends_lib port:python25 \ > + port:orbit2 > > -configure.env PYTHON=python2.5 > +configure.python ${prefix}/bin/python2.5 > > -build.args PYTHON_LDFLAGS= PYTHON_LIBS= > +build.args PYTHON_LDFLAGS= PYTHON_LIBS= > > +platform darwin 9 { > + post-patch { > + reinplace "s| -export-symbols-regex.*||g" ${worksrcpath}/ > src/Makefile.in > + } > +} > + > livecheck.check md5 > livecheck.url ftp://ftp.gnome.org/pub/GNOME/sources/pyorbit/ > livecheck.md5 c44aad7204b0cc64e524610a82b97340 From ryandesign at macports.org Tue Jan 22 03:24:04 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Jan 22 03:24:34 2008 Subject: [33247] trunk/dports/devel/dialog/Portfile In-Reply-To: <20080122105140.5BEEABB89BA@beta.macosforge.org> References: <20080122105140.5BEEABB89BA@beta.macosforge.org> Message-ID: <35C89897-0C54-4FEE-B761-044B2D203B3D@macports.org> On Jan 22, 2008, at 04:51, jwa@macports.org wrote: > Revision: 33247 > http://trac.macosforge.org/projects/macports/changeset/33247 > Author: jwa@macports.org > Date: 2008-01-22 02:51:38 -0800 (Tue, 22 Jan 2008) > > Log Message: > ----------- > make port lint clean, make utf8 a default with installation Then you must increment the port's revision so everyone gets that change. > Modified Paths: > -------------- > trunk/dports/devel/dialog/Portfile > > Modified: trunk/dports/devel/dialog/Portfile > =================================================================== > --- trunk/dports/devel/dialog/Portfile 2008-01-22 10:50:02 UTC (rev > 33246) > +++ trunk/dports/devel/dialog/Portfile 2008-01-22 10:51:38 UTC (rev > 33247) > @@ -1,6 +1,7 @@ > # $Id$ > > PortSystem 1.0 > + > name dialog > version 1.1-20071028 > epoch 20071028 > @@ -27,7 +28,8 @@ > > depends_lib port:ncurses > > -configure.args --mandir=${prefix}/share/man > +configure.args --mandir=${prefix}/share/man \ > + --with-ncursesw > > post-destroot { > xinstall -m 755 -d ${destroot}${prefix}/share/doc/${name}/ > examples > @@ -56,9 +58,5 @@ > configure.compiler gcc-4.0 > } > > -variant utf8 { > - configure.args-append --with-ncursesw > -} > - > livecheck.check moddate > livecheck.url ${homepage}CHANGES From ryandesign at macports.org Thu Jan 24 03:34:12 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Jan 24 03:34:27 2008 Subject: [32900] trunk/dports/devel/libffi/Portfile In-Reply-To: References: <20080114212155.1525D9D94A2@beta.macosforge.org> <81F46C07-59D3-4330-AB51-6C1A06EB9797@macports.org> Message-ID: On Jan 14, 2008, at 15:35, Paul Guyot wrote: > Le 14 janv. 08 ? 22:27, Ryan Schmidt a ?crit : > >> On Jan 14, 2008, at 15:21, pguyot@kallisys.net wrote: >> >>> name libffi >>> version 2.1 >>> -revision 20040426 >>> +revision 20040426_1 >> >> I didn't think the revision was allowed to be anything but an >> increasing integer. > > Was it? > > I'm not even sure of what this date meant in the first place. I > changed it because I'm not sure that libffi files that are > downloaded from the checkout are the same than those that were part > of the now gone PyObjC 1.4 archive. I've found it: http://trac.macosforge.org/projects/macports/ticket/12204 It is indeed an error for the revision to be nonnumeric. libffi is the only port at this time with a nonnumeric revision. So you should fix the port so that the revision is numeric. From guido.soranzio at gmail.com Thu Jan 24 06:00:08 2008 From: guido.soranzio at gmail.com (Guido Soranzio) Date: Thu Jan 24 06:00:28 2008 Subject: Trying porting back WebKit Message-ID: The GTK port of WebKit is being used by more and more Gnome programs as an alternative to the Gecko engine, so I have tried to create the attached minimal portfile for "webkitgtk", but the compilation fails with the following error: /opt/local/include/X11/X.h:108: error: conflicting declaration 'typedef XID Cursor' /System/Library/Frameworks/ApplicationServices.framework/Frameworks/ QD.framework/Headers/QuickdrawTypes.h:269: error: 'Cursor' has a previous declaration as 'typedef struct Cursor Cursor' make[1]: *** [WebCore/page/libWebKitGtk_la-Frame.lo] Error 1 Which is the elegant way of proceeding with Apple sources? :) -Guido --------------------8<---------------------------------------- # $Id$ PortSystem 1.0 name webkitgtk version r29753 maintainers nomaintainer categories devel description GTK+ port of WebKit. long_description ${description} homepage http://www.webkit.org platforms darwin master_sites http://nightly.webkit.org/files/trunk/src use_bzip2 yes distname WebKit-${version} checksums md5 9ad7d64dd106b10b55d4bf81a0bbd650 configure.cmd ./autogen.sh depends_build port:libtool \ port:icu \ port:pkg-config depends_lib port:gtk2 pre-configure { reinplace "s|aclocal |aclocal -I${prefix}/share/aclocal |" \ ${worksrcpath}/autogen.sh reinplace "s|libtoolize|glibtoolize|" \ ${worksrcpath}/autogen.sh } --------------------8<------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080124/2d026d0b/attachment.html From opendarwin.org at darkart.com Thu Jan 24 13:52:21 2008 From: opendarwin.org at darkart.com (Eric Hall) Date: Thu Jan 24 13:52:13 2008 Subject: platform range and set arguments? In-Reply-To: <4E7D4720-E37B-4016-83C7-62B5C391BB56@apple.com> References: <4E7D4720-E37B-4016-83C7-62B5C391BB56@apple.com> Message-ID: <20080124215221.GD963@darkart.com> On Sat, Jan 19, 2008 at 04:17:53PM -0800, Jordan K. Hubbard wrote: > Hey all, > > I was just looking at the ghc port a few days ago, mostly in an > attempt to figure out why it a-splode! on my 10.5 PPC system, and I > noticed a lot of this: > > platform darwin 7 powerpc { ... } > platform darwin 8 powerpc { ... } > platform darwin 8 i386 { ... } > > And so on. It occurred to me that if "platform darwin 9 > powerpc" (that's me) was going to duplicate a lot of the existing > rules, maybe it would make more sense to introduce ranges and sets to > the existing logic (I checked, and there's currently no support for it > that a cursory glance indicated, anyway). > > Then we could do stuff like this: > > platform darwin [7-8] powerpc { ... } > > platform darwin 9 {powerpc, i386} { .. } > > And have far more concise portfiles. We might also have a > platform_isset procedure so that you could do: > > platform darwin [7-9] { > if {[platform_isset darwin 8]} { .. do some special tiger-only > magic .. } > ... more darwin generic foo here ... > } > > Thoughts? If folks like the idea and nobody immediately jumps to do > it, I might give the appropriate hacks a whack (eee! managers coding!). > That makes good sense to me, especially after looking at the ghc Portfile. -eric From ryandesign at macports.org Thu Jan 24 21:35:00 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Jan 24 21:35:10 2008 Subject: platform range and set arguments? In-Reply-To: <20080124215221.GD963@darkart.com> References: <4E7D4720-E37B-4016-83C7-62B5C391BB56@apple.com> <20080124215221.GD963@darkart.com> Message-ID: On Jan 24, 2008, at 15:52, Eric Hall wrote: > On Sat, Jan 19, 2008 at 04:17:53PM -0800, Jordan K. Hubbard wrote: > >> I was just looking at the ghc port a few days ago, mostly in an >> attempt to figure out why it a-splode! on my 10.5 PPC system, and I >> noticed a lot of this: >> >> platform darwin 7 powerpc { ... } >> platform darwin 8 powerpc { ... } >> platform darwin 8 i386 { ... } >> >> And so on. It occurred to me that if "platform darwin 9 >> powerpc" (that's me) was going to duplicate a lot of the existing >> rules, maybe it would make more sense to introduce ranges and sets to >> the existing logic (I checked, and there's currently no support >> for it >> that a cursory glance indicated, anyway). >> >> Then we could do stuff like this: >> >> platform darwin [7-8] powerpc { ... } >> >> platform darwin 9 {powerpc, i386} { .. } >> >> And have far more concise portfiles. We might also have a >> platform_isset procedure so that you could do: >> >> platform darwin [7-9] { >> if {[platform_isset darwin 8]} { .. do some special tiger-only >> magic .. } >> ... more darwin generic foo here ... >> } >> >> Thoughts? If folks like the idea and nobody immediately jumps to do >> it, I might give the appropriate hacks a whack (eee! managers >> coding!). >> > > That makes good sense to me, especially after looking at the > ghc Portfile. The gsl port seems to think this functionality already exists: platform darwin 6 7 { configure.cflags-append "-O1" } I wonder whether this section actually gets used on Panther or Jaguar... From randall.h.wood at alexandriasoftware.com Thu Jan 24 22:24:05 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Thu Jan 24 22:23:54 2008 Subject: Trying porting back WebKit In-Reply-To: References: Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Portfile Type: application/octet-stream Size: 1140 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080125/db01452c/Portfile.obj From randall.h.wood at alexandriasoftware.com Thu Jan 24 23:23:18 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Thu Jan 24 23:23:07 2008 Subject: Trying porting back WebKit In-Reply-To: References: Message-ID: I am getting the same error and have reported it at http://bugs.webkit.org/show_bug.cgi?id=17001 if you wish to follow it. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080125/a6009ba7/attachment-0001.html From jochen at fhi-berlin.mpg.de Fri Jan 25 01:23:23 2008 From: jochen at fhi-berlin.mpg.de (=?ISO-8859-1?Q?Jochen_K=FCpper?=) Date: Fri Jan 25 01:23:26 2008 Subject: platform range and set arguments? In-Reply-To: References: <4E7D4720-E37B-4016-83C7-62B5C391BB56@apple.com> <20080124215221.GD963@darkart.com> Message-ID: <0BA35E0B-710E-447D-9209-D8C23347A966@fhi-berlin.mpg.de> On 25.01.2008, at 06:35, Ryan Schmidt wrote: > platform darwin 6 7 { > configure.cflags-append "-O1" > } > > I wonder whether this section actually gets used on Panther or > Jaguar... Me too! [1] This bit was in the Portfile when I took maintainership, I do not have any of the relevant systems, and nobody ever complained about problems... Greetings, Jochen [1] I am the gsl port maintainer;) -- Fritz-Haber-Institut der MPG -- Department of Molecular Physics Faradayweg 4-6 (C1.03) D-14195 Berlin, Germany phone: +49-30-84135686 fax: +49-30-84135892 http://www.fhi-berlin.mpg.de/mp/jochen -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080125/5c9dff59/PGP.bin From guido.soranzio at gmail.com Fri Jan 25 01:29:34 2008 From: guido.soranzio at gmail.com (Guido Soranzio) Date: Fri Jan 25 01:29:27 2008 Subject: Trying porting back WebKit In-Reply-To: References: Message-ID: On Jan 25, 2008, at 7:24 AM, Randall Wood wrote: > Your best bet maybe to work with the WebKit developers, as WebKit is > not Apple (its mostly Apple, but not just Apple). Indeed, the problem is that the includes of AplicationServices.framework are evaluated even when PLATFORM(GTK) is defined. I tried to add post-configure { reinplace "s|-Wl,-framework,CoreServices,- framework,ApplicationServices ||" \ ${worksrcpath}/GNUmakefile \ ${worksrcpath}/WebKit/gtk/WebKitGtk.pc } and to nullify the line FRAMEWORK_SEARCH_PATHS = $(SYSTEM_LIBRARY_DIR)/Frameworks/ Carbon.framework/Frameworks $(SYSTEM_LIBRARY_DIR)/Frameworks/ ApplicationServices.framework/Frameworks $(FRAMEWORK_SEARCH_PATHS); from Webcore/Configurations/WebCore.xcconfig but, when Frame.cpp is compiled, the double definition of the struct Cursor is still imported from the Carbon system includes. Perhaps hacking WebCore/plaform/Cursor.h could solve it. From afb at macports.org Fri Jan 25 01:50:08 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Fri Jan 25 01:50:03 2008 Subject: Trying porting back WebKit In-Reply-To: References: Message-ID: Guido Soranzio wrote: >> Your best bet maybe to work with the WebKit developers, as WebKit is >> not Apple (its mostly Apple, but not just Apple). > > Indeed, the problem is that the includes of > AplicationServices.framework > are evaluated even when PLATFORM(GTK) is defined. ... > from Webcore/Configurations/WebCore.xcconfig but, when Frame.cpp > is compiled, the double definition of the struct Cursor is still > imported from the Carbon system includes. The usual workaround is to #define Cursor to something else, so that it won't conflict with the legacy Mac OS headers... #if defined(__APPLE__) && defined(__MACH__) /* conflicts with Quickdraw.h */ #define Cursor X11Cursor #endif #include ... #if defined(__APPLE__) && defined(__MACH__) /* matches the re-define above */ #undef Cursor #endif --anders From randall.h.wood at alexandriasoftware.com Fri Jan 25 04:17:16 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Fri Jan 25 04:17:05 2008 Subject: Trying porting back WebKit In-Reply-To: References: Message-ID: On 1/25/08, Anders F Bj?rklund wrote: > > Guido Soranzio wrote: > > >> Your best bet maybe to work with the WebKit developers, as WebKit is > >> not Apple (its mostly Apple, but not just Apple). > > > > Indeed, the problem is that the includes of > > AplicationServices.framework > > are evaluated even when PLATFORM(GTK) is defined. > ... > > from Webcore/Configurations/WebCore.xcconfig but, when Frame.cpp > > is compiled, the double definition of the struct Cursor is still > > imported from the Carbon system includes. > > The usual workaround is to #define Cursor to something else, > so that it won't conflict with the legacy Mac OS headers... Don't forget that under certain conditions GTK will be compiled to run in the Aqua environment and not in X11. #if defined(__APPLE__) && defined(__MACH__) > /* conflicts with Quickdraw.h */ > #define Cursor X11Cursor > #endif > > #include > ... > > #if defined(__APPLE__) && defined(__MACH__) > /* matches the re-define above */ > #undef Cursor > #endif > > --anders > > -- Randall Wood randall.h.wood@alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080125/c55ed1ab/attachment.html From afb at macports.org Fri Jan 25 04:24:39 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Fri Jan 25 04:24:31 2008 Subject: Trying porting back WebKit In-Reply-To: References: Message-ID: <0e9df01a8441316e72c674c07ce1b22c@macports.org> Randall Wood wrote: >> The usual workaround is to #define Cursor to something else, >> so that it won't conflict with the legacy Mac OS headers... > Don't forget that under certain conditions GTK will be compiled to run > in the Aqua environment and not in X11.? Right, but most likely that code won't include X11 then ? :-) Seriously, this was for the X11 code path - not for Aqua... So it undefined the symbol again, after potentially using it. --anders From guido.soranzio at gmail.com Fri Jan 25 10:46:51 2008 From: guido.soranzio at gmail.com (Guido Soranzio) Date: Fri Jan 25 10:46:44 2008 Subject: Trying porting back WebKit In-Reply-To: References: Message-ID: <18B4B9D4-5E3D-4562-AC2F-299CF108D5EC@gmail.com> On Jan 25, 2008, at 8:23 AM, Randall Wood wrote: > I am getting the same error and have reported it at http://bugs.webkit.org/show_bug.cgi?id=17001 > if you wish to follow it. Thanks. I have applied the patch by Mark Raw in the attached updated portfile. Now the compilation fails towards the end in WebCore/xml reporting this error: In file included from ./JavaScriptCore/wtf/unicode/icu/UnicodeIcu.h:28, from ./JavaScriptCore/wtf/unicode/Unicode.h:31, from ./JavaScriptCore/wtf/unicode/utf8.h:29, from /opt/local/include/unicode/utf.h:221, from /opt/local/include/unicode/utypes.h:37, from /opt/local/include/unicode/ucnv_err.h:86, from /opt/local/include/unicode/ucnv.h:50, from WebCore/xml/XSLTUnicodeSort.cpp:38: /opt/local/include/unicode/uchar.h:2317:6: warning: "UCONFIG_NO_NORMALIZATION" is not defined In file included from ./JavaScriptCore/wtf/unicode/icu/UnicodeIcu.h:29, from ./JavaScriptCore/wtf/unicode/Unicode.h:31, from ./JavaScriptCore/wtf/unicode/utf8.h:29, from /opt/local/include/unicode/utf.h:221, from /opt/local/include/unicode/utypes.h:37, from /opt/local/include/unicode/ucnv_err.h:86, from /opt/local/include/unicode/ucnv.h:50, from WebCore/xml/XSLTUnicodeSort.cpp:38: /opt/local/include/unicode/ustring.h:679:6: warning: "UCONFIG_NO_CONVERSION" is not defined /opt/local/include/unicode/ustring.h:1092:6: warning: "UCONFIG_NO_BREAK_ITERATION" is not defined /opt/local/include/unicode/ustring.h:1169:64: warning: "UCONFIG_NO_CONVERSION" is not defined /opt/local/include/unicode/uchar.h:2293: error: expected initializer before 'UCharEnumTypeRange' [...] /opt/local/include/unicode/ucol.h:472: error: 'UCharIterator' has not been declared /opt/local/include/unicode/ucol.h:725: error: 'UCharIterator' has not been declared make[1]: *** [WebCore/xml/libWebKitGtk_la-XSLTUnicodeSort.lo] Error 1 make: *** [all] Error 2 -Guido ---------------8<----------------------------------------- PortSystem 1.0 name webkitgtk version r29785 categories devel description GTK+ port of WebKit. long_description ${description} maintainers nomaintainer homepage http://www.webkit.org platforms darwin master_sites http://nightly.webkit.org/files/trunk/src use_bzip2 yes distname WebKit-${version} checksums md5 2c45b3c706be67a1b6d57784a4239407 configure.cmd ./autogen.sh depends_build port:libtool \ port:pkgconfig depends_lib port:curl \ port:icu \ port:libxslt \ port:sqlite3 \ port:gtk2 pre-configure { reinplace "s|aclocal |aclocal -I ${prefix}/share/aclocal |" \ ${worksrcpath}/autogen.sh reinplace "s|libtoolize|glibtoolize|" \ ${worksrcpath}/autogen.sh reinplace "s|!defined(__MACOS_CLASSIC__)|! defined(__MACOS_CLASSIC__) \\\&\\\& !defined(XP_UNIX)|" \ ${worksrcpath}/JavaScriptCore/bindings/npapi.h } -------------------8<------------------------------------ From n.oxyde at gmail.com Fri Jan 25 17:15:11 2008 From: n.oxyde at gmail.com (N_Ox) Date: Fri Jan 25 17:15:02 2008 Subject: Trying porting back WebKit In-Reply-To: <18B4B9D4-5E3D-4562-AC2F-299CF108D5EC@gmail.com> References: <18B4B9D4-5E3D-4562-AC2F-299CF108D5EC@gmail.com> Message-ID: Le 25 janv. 08 ? 19:46, Guido Soranzio a ?crit : > > On Jan 25, 2008, at 8:23 AM, Randall Wood wrote: > >> I am getting the same error and have reported it at http:// >> bugs.webkit.org/show_bug.cgi?id=17001 if you wish to follow it. > > Thanks. I have applied the patch by Mark Raw in the attached > updated portfile. > > Now the compilation fails towards the end in WebCore/xml reporting > this error: > > In file included from ./JavaScriptCore/wtf/unicode/icu/UnicodeIcu.h: > 28, > from ./JavaScriptCore/wtf/unicode/Unicode.h:31, > from ./JavaScriptCore/wtf/unicode/utf8.h:29, > from /opt/local/include/unicode/utf.h:221, > from /opt/local/include/unicode/utypes.h:37, > from /opt/local/include/unicode/ucnv_err.h:86, > from /opt/local/include/unicode/ucnv.h:50, > from WebCore/xml/XSLTUnicodeSort.cpp:38: > /opt/local/include/unicode/uchar.h:2317:6: warning: > "UCONFIG_NO_NORMALIZATION" is not defined > In file included from ./JavaScriptCore/wtf/unicode/icu/UnicodeIcu.h: > 29, > from ./JavaScriptCore/wtf/unicode/Unicode.h:31, > from ./JavaScriptCore/wtf/unicode/utf8.h:29, > from /opt/local/include/unicode/utf.h:221, > from /opt/local/include/unicode/utypes.h:37, > from /opt/local/include/unicode/ucnv_err.h:86, > from /opt/local/include/unicode/ucnv.h:50, > from WebCore/xml/XSLTUnicodeSort.cpp:38: > /opt/local/include/unicode/ustring.h:679:6: warning: > "UCONFIG_NO_CONVERSION" is not defined > /opt/local/include/unicode/ustring.h:1092:6: warning: > "UCONFIG_NO_BREAK_ITERATION" is not defined > /opt/local/include/unicode/ustring.h:1169:64: warning: > "UCONFIG_NO_CONVERSION" is not defined > /opt/local/include/unicode/uchar.h:2293: error: expected > initializer before 'UCharEnumTypeRange' > > [...] > > /opt/local/include/unicode/ucol.h:472: error: 'UCharIterator' has > not been declared > /opt/local/include/unicode/ucol.h:725: error: 'UCharIterator' has > not been declared > make[1]: *** [WebCore/xml/libWebKitGtk_la-XSLTUnicodeSort.lo] Error 1 > make: *** [all] Error 2 > That's icu's fault, is a specific version of it required? MacPorts is up to date, 3.8.1 is the latest version. -- Anthony Ramine, the "Ports tree cleaning Maestro". From randall.h.wood at alexandriasoftware.com Fri Jan 25 17:19:42 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Fri Jan 25 17:19:27 2008 Subject: Trying porting back WebKit In-Reply-To: References: <18B4B9D4-5E3D-4562-AC2F-299CF108D5EC@gmail.com> Message-ID: I went ahead and committed the port at www/webkit-gtk so that we can all work on the same port in SVN. Its commit number 33380. On 1/25/08, N_Ox wrote: > > > Le 25 janv. 08 ? 19:46, Guido Soranzio a ?crit : > > > > > On Jan 25, 2008, at 8:23 AM, Randall Wood wrote: > > > >> I am getting the same error and have reported it at http:// > >> bugs.webkit.org/show_bug.cgi?id=17001 if you wish to follow it. > > > > Thanks. I have applied the patch by Mark Raw in the attached > > updated portfile. > > > > Now the compilation fails towards the end in WebCore/xml reporting > > this error: > > > > In file included from ./JavaScriptCore/wtf/unicode/icu/UnicodeIcu.h: > > 28, > > from ./JavaScriptCore/wtf/unicode/Unicode.h:31, > > from ./JavaScriptCore/wtf/unicode/utf8.h:29, > > from /opt/local/include/unicode/utf.h:221, > > from /opt/local/include/unicode/utypes.h:37, > > from /opt/local/include/unicode/ucnv_err.h:86, > > from /opt/local/include/unicode/ucnv.h:50, > > from WebCore/xml/XSLTUnicodeSort.cpp:38: > > /opt/local/include/unicode/uchar.h:2317:6: warning: > > "UCONFIG_NO_NORMALIZATION" is not defined > > In file included from ./JavaScriptCore/wtf/unicode/icu/UnicodeIcu.h: > > 29, > > from ./JavaScriptCore/wtf/unicode/Unicode.h:31, > > from ./JavaScriptCore/wtf/unicode/utf8.h:29, > > from /opt/local/include/unicode/utf.h:221, > > from /opt/local/include/unicode/utypes.h:37, > > from /opt/local/include/unicode/ucnv_err.h:86, > > from /opt/local/include/unicode/ucnv.h:50, > > from WebCore/xml/XSLTUnicodeSort.cpp:38: > > /opt/local/include/unicode/ustring.h:679:6: warning: > > "UCONFIG_NO_CONVERSION" is not defined > > /opt/local/include/unicode/ustring.h:1092:6: warning: > > "UCONFIG_NO_BREAK_ITERATION" is not defined > > /opt/local/include/unicode/ustring.h:1169:64: warning: > > "UCONFIG_NO_CONVERSION" is not defined > > /opt/local/include/unicode/uchar.h:2293: error: expected > > initializer before 'UCharEnumTypeRange' > > > > [...] > > > > /opt/local/include/unicode/ucol.h:472: error: 'UCharIterator' has > > not been declared > > /opt/local/include/unicode/ucol.h:725: error: 'UCharIterator' has > > not been declared > > make[1]: *** [WebCore/xml/libWebKitGtk_la-XSLTUnicodeSort.lo] Error 1 > > make: *** [all] Error 2 > > > > That's icu's fault, is a specific version of it required? MacPorts is > up to date, 3.8.1 is the latest version. AFAIK the WebKit developers want to remove the dependency on ICU for portability reasons. -- > Anthony Ramine, the "Ports tree cleaning Maestro". > > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev > -- Randall Wood randall.h.wood@alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080125/e705e040/attachment.html From mp-user at geeklair.net Sat Jan 26 00:33:19 2008 From: mp-user at geeklair.net (Macports User) Date: Sat Jan 26 00:33:06 2008 Subject: PortIndex Regen Failure on Saturday 2008-01-26 at 03:30:00 Message-ID: <20080126083319.CCE8B2FAC10F@gandalf.geeklair.net> checking build system type... powerpc-apple-darwin9.1.0 checking host system type... powerpc-apple-darwin9.1.0 checking target system type... powerpc-apple-darwin9.1.0 checking for sw_vers... sw_vers checking Mac OS X version... 10.5.1 checking Xcode version... 3.0 checking MacPorts version... 1.6.0 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for gcc... gcc checking whether we are using the GNU Objective C compiler... yes checking whether gcc accepts -g... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether make sets $(MAKE)... yes checking whether ln -s works... yes checking for mtree... /usr/sbin/mtree checking for cvs... /usr/bin/cvs checking for svn... /usr/bin/svn checking for rsync... /usr/bin/rsync checking for sed... /usr/bin/sed checking for tar... /usr/bin/tar checking for make... /usr/bin/make checking for launchd... no checking for launchctl... /bin/launchctl checking for xcodebuild... /usr/bin/xcodebuild checking for gnutar... /usr/bin/gnutar checking for gnumake... /usr/bin/gnumake checking for bzip2... /usr/bin/bzip2 checking for xar... /usr/bin/xar checking for open... /usr/bin/open checking for sed... (cached) /usr/bin/sed checking which sed flag to use for extended regexp... -E (BSD) checking for tar... (cached) /usr/bin/tar checking for gnutar... (cached) /usr/bin/gnutar checking for which tar variant to use... /usr/bin/gnutar checking for /usr/bin/gnutar --no-same-owner support... yes checking how to mark unused variables... checking for gcc symbol visibility attribute... __attribute__((visibility("hidden"))) checking for the pthreads library -lpthreads... no checking whether pthreads work without any flags... yes checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE checking if more special flags are required for pthreads... -D_THREAD_SAFE checking how to run the Objective C preprocessor... gcc -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... rm: conftest.dSYM: is a directory rm: conftest.dSYM: is a directory yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking objc/objc.h usability... yes checking objc/objc.h presence... yes checking for objc/objc.h... yes checking if linking libobjc requires pthreads... no checking for Apple Objective-C runtime... yes checking for GNU Objective C runtime... no configure: Using Apple Objective-C runtime checking for Apple Foundation library... yes configure: WARNING: GNUSTEP_SYSTEM_ROOT is not defined in your environment, preventing the use of GNUstep's Foundation library configure: Using Apple Foundation library checking for CoreFoundation framework... yes checking for SystemConfiguration framework... yes checking for IOKit framework... yes checking for CFNotificationCenterGetDarwinNotifyCenter... yes checking for whether we will build daemondo... yes checking for ports tree... configure: WARNING: No ports tree found checking for MacPorts config directory... ${sysconfdir}/macports checking for install user... mp-user checking for install group... mp-user checking what permissions to use for installation directories... 0755 checking how to run the C preprocessor... gcc -E checking for ANSI C header files... (cached) yes checking for dirent.h that defines DIR... yes checking for library containing opendir... none required checking for sys/wait.h that is POSIX.1 compatible... yes checking whether stat file-mode macros are broken... no checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking paths.h usability... yes checking paths.h presence... yes checking for paths.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking crt_externs.h usability... yes checking crt_externs.h presence... yes checking for crt_externs.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/cdefs.h usability... yes checking sys/cdefs.h presence... yes checking for sys/cdefs.h... yes checking err.h usability... yes checking err.h presence... yes checking for err.h... yes checking libgen.h usability... yes checking libgen.h presence... yes checking for libgen.h... yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking readline/readline.h usability... yes checking readline/readline.h presence... yes checking for readline/readline.h... yes checking readline/history.h usability... yes checking readline/history.h presence... yes checking for readline/history.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking sys/paths.h usability... yes checking sys/paths.h presence... yes checking for sys/paths.h... yes checking utime.h usability... yes checking utime.h presence... yes checking for utime.h... yes checking whether closedir returns void... no checking for pid_t... yes checking vfork.h usability... no checking vfork.h presence... no checking for vfork.h... no checking for fork... yes checking for vfork... yes checking for working fork... yes checking for working vfork... (cached) yes checking whether strerror_r is declared... yes checking for strerror_r... yes checking whether strerror_r returns char *... no checking for bzero... yes checking for memset... yes checking for dup2... yes checking for regcomp... yes checking for strdup... yes checking for strerror... yes checking for strtol... yes checking for fgetln... yes checking for lockf... yes checking for flock... yes checking for setmode... yes checking for strcasecmp... yes checking for strncasecmp... yes checking for strlcpy... yes checking for copyfile... yes checking if readlink conforms to POSIX 1003.1a... yes checking for MD5Update in -lmd... no checking for MD5_Update in -lcrypto... yes checking openssl/md5.h usability... yes checking openssl/md5.h presence... yes checking for openssl/md5.h... yes checking for X... no checking for XOpenDisplay in -lX11... yes Please install the X11 SDK packages from the Xcode Developer Tools CD configure: error: Broken X11 install. No X11 headers ./configure script failed. From ryandesign at macports.org Sat Jan 26 01:00:05 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat Jan 26 01:00:16 2008 Subject: [MacPorts] #13586: Upgrade libtorrent/rtorrent 0.11.7-9/0.7.7-9 In-Reply-To: References: <047.85dfcb1fdd91684d8964ce215d8bbb1c@macosforge.org> <056.d61b7e4238b6786d6f778da8a593359e@macosforge.org> Message-ID: On Jan 26, 2008, at 02:12, Marcus D'Camp wrote: > On Jan 25, 2008 5:48 PM, MacPorts wrote: > >> #13586: Upgrade libtorrent/rtorrent 0.11.7-9/0.7.7-9 >> -------------------------------- >> +------------------------------------------- >> Reporter: carcus@carcus.net | Owner: >> ryandesign@macports.org >> Type: enhancement | Status: closed >> Priority: Normal | Milestone: Port Updates >> Component: ports | Version: 1.5.2 >> Resolution: fixed | Keywords: >> -------------------------------- >> +------------------------------------------- >> Changes (by ryandesign@macports.org): >> >> * cc: imajes@macports.org (added) >> * status: new => closed >> * resolution: => fixed >> >> Comment: >> >> The checksums in the patch for rtorrent were a bit messed up >> (space after >> backslash on md5 line, rmd160 checksum listed as "rmd16" with an >> extra 0 >> after the end of the checksum) but I fixed it and committed both >> updates >> in r33383. Thanks! > > That's my bad, sorry about that! What editor do you use for those? > I don't seem to have very good luck with vi. No worries. :) I know, vi is pretty weird. I use TextWrangler by Bare Bones Software, which is the free lite version of BBEdit. I have the editor set up to show invisible characters all the time (except for spaces) so I can see where tabs and newlines are. Helps for spotting whitespace errors. I have my EDITOR environment variable set up so that when I type "port edit foo" or "svn commit" it pops up into TextWrangler, and when I'm done in TextWrangler and save and close the document, it brings me back to the Terminal. In ~/.bashrc I have "export EDITOR=editor.sh" and somewhere in my PATH I have editor.sh which contains: #!/bin/sh edit +1 --wait --resume "$@" I also have a shell function which calculates the correct checksums for me and sends them to a new document in TextWrangler formatted in my default port editing style. Very handy for copying and pasting into ports I'm updating. MacPorts base has been updated to print this out too, if you try to install and the checksums are wrong. I think I still like my script better because I prefer my formatting style. :) From ryandesign at macports.org Sat Jan 26 05:12:42 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat Jan 26 05:12:47 2008 Subject: [33413] trunk/dports In-Reply-To: <20080126125725.4EC4ACA96A4@beta.macosforge.org> References: <20080126125725.4EC4ACA96A4@beta.macosforge.org> Message-ID: <1010B987-0E96-4288-9B8D-24DDFE818B70@macports.org> On Jan 26, 2008, at 06:57, ryandesign@macports.org wrote: > Revision: 33413 > http://trac.macosforge.org/projects/macports/changeset/33413 > Author: ryandesign@macports.org > Date: 2008-01-26 04:56:28 -0800 (Sat, 26 Jan 2008) > > Log Message: > ----------- > These ports build from source but build a universal version by > default, and no effort has yet been expended to change this. The > port defines an empty universal variant and selects it by default. > Now additionally ensure that this default selection cannot be > overridden, since to do so would be inaccurate. > > Modified Paths: > -------------- > trunk/dports/aqua/BwanaDik/Portfile > trunk/dports/aqua/CosmicDebris/Portfile > trunk/dports/aqua/NicePlayer/Portfile > trunk/dports/aqua/X-MasTree/Portfile > trunk/dports/aqua/binclocken/Portfile > trunk/dports/aqua/osxvnc/Portfile > trunk/dports/sysutils/sleepwatcher/Portfile Anthony, I remember you've patched a lot of ports before to work around default-universal build scripts, to make the ports build "normally" (local arch only, unless +universal is selected). Maybe you could apply the same wizardry to these ports and get rid of my poor hack? A patch was submitted for osxvnc in #13804 but it didn't look like yours :) (I didn't like how it called out to `uname`) so maybe you can come up with something better. You might want to start with the other ports first though, since I'm about to update osxvnc to 3.0 and who knows what all that will change. From mp-user at geeklair.net Sat Jan 26 12:34:59 2008 From: mp-user at geeklair.net (Macports User) Date: Sat Jan 26 12:34:49 2008 Subject: PortIndex Regen Failure on Saturday 2008-01-26 at 15:30:00 Message-ID: <20080126203459.3F3362FB4D40@gandalf.geeklair.net> checking build system type... powerpc-apple-darwin9.1.0 checking host system type... powerpc-apple-darwin9.1.0 checking target system type... powerpc-apple-darwin9.1.0 checking for sw_vers... sw_vers checking Mac OS X version... 10.5.1 checking Xcode version... 3.0 checking MacPorts version... 1.6.0 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for gcc... gcc checking whether we are using the GNU Objective C compiler... yes checking whether gcc accepts -g... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether make sets $(MAKE)... yes checking whether ln -s works... yes checking for mtree... /usr/sbin/mtree checking for cvs... /usr/bin/cvs checking for svn... /usr/bin/svn checking for rsync... /usr/bin/rsync checking for sed... /usr/bin/sed checking for tar... /usr/bin/tar checking for make... /usr/bin/make checking for launchd... no checking for launchctl... /bin/launchctl checking for xcodebuild... /usr/bin/xcodebuild checking for gnutar... /usr/bin/gnutar checking for gnumake... /usr/bin/gnumake checking for bzip2... /usr/bin/bzip2 checking for xar... /usr/bin/xar checking for open... /usr/bin/open checking for sed... (cached) /usr/bin/sed checking which sed flag to use for extended regexp... -E (BSD) checking for tar... (cached) /usr/bin/tar checking for gnutar... (cached) /usr/bin/gnutar checking for which tar variant to use... /usr/bin/gnutar checking for /usr/bin/gnutar --no-same-owner support... yes checking how to mark unused variables... checking for gcc symbol visibility attribute... __attribute__((visibility("hidden"))) checking for the pthreads library -lpthreads... no checking whether pthreads work without any flags... yes checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE checking if more special flags are required for pthreads... -D_THREAD_SAFE checking how to run the Objective C preprocessor... gcc -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... rm: conftest.dSYM: is a directory rm: conftest.dSYM: is a directory yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking objc/objc.h usability... yes checking objc/objc.h presence... yes checking for objc/objc.h... yes checking if linking libobjc requires pthreads... no checking for Apple Objective-C runtime... yes checking for GNU Objective C runtime... no configure: Using Apple Objective-C runtime checking for Apple Foundation library... yes configure: WARNING: GNUSTEP_SYSTEM_ROOT is not defined in your environment, preventing the use of GNUstep's Foundation library configure: Using Apple Foundation library checking for CoreFoundation framework... yes checking for SystemConfiguration framework... yes checking for IOKit framework... yes checking for CFNotificationCenterGetDarwinNotifyCenter... yes checking for whether we will build daemondo... yes checking for ports tree... configure: WARNING: No ports tree found checking for MacPorts config directory... ${sysconfdir}/macports checking for install user... mp-user checking for install group... mp-user checking what permissions to use for installation directories... 0755 checking how to run the C preprocessor... gcc -E checking for ANSI C header files... (cached) yes checking for dirent.h that defines DIR... yes checking for library containing opendir... none required checking for sys/wait.h that is POSIX.1 compatible... yes checking whether stat file-mode macros are broken... no checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking paths.h usability... yes checking paths.h presence... yes checking for paths.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking crt_externs.h usability... yes checking crt_externs.h presence... yes checking for crt_externs.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/cdefs.h usability... yes checking sys/cdefs.h presence... yes checking for sys/cdefs.h... yes checking err.h usability... yes checking err.h presence... yes checking for err.h... yes checking libgen.h usability... yes checking libgen.h presence... yes checking for libgen.h... yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking readline/readline.h usability... yes checking readline/readline.h presence... yes checking for readline/readline.h... yes checking readline/history.h usability... yes checking readline/history.h presence... yes checking for readline/history.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking sys/paths.h usability... yes checking sys/paths.h presence... yes checking for sys/paths.h... yes checking utime.h usability... yes checking utime.h presence... yes checking for utime.h... yes checking whether closedir returns void... no checking for pid_t... yes checking vfork.h usability... no checking vfork.h presence... no checking for vfork.h... no checking for fork... yes checking for vfork... yes checking for working fork... yes checking for working vfork... (cached) yes checking whether strerror_r is declared... yes checking for strerror_r... yes checking whether strerror_r returns char *... no checking for bzero... yes checking for memset... yes checking for dup2... yes checking for regcomp... yes checking for strdup... yes checking for strerror... yes checking for strtol... yes checking for fgetln... yes checking for lockf... yes checking for flock... yes checking for setmode... yes checking for strcasecmp... yes checking for strncasecmp... yes checking for strlcpy... yes checking for copyfile... yes checking if readlink conforms to POSIX 1003.1a... yes checking for MD5Update in -lmd... no checking for MD5_Update in -lcrypto... yes checking openssl/md5.h usability... yes checking openssl/md5.h presence... yes checking for openssl/md5.h... yes checking for X... no checking for XOpenDisplay in -lX11... yes Please install the X11 SDK packages from the Xcode Developer Tools CD configure: error: Broken X11 install. No X11 headers ./configure script failed. From ryandesign at macports.org Sat Jan 26 14:46:38 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat Jan 26 14:46:44 2008 Subject: PortIndex Regen Failure on Saturday 2008-01-26 at 15:30:00 In-Reply-To: <20080126203459.3F3362FB4D40@gandalf.geeklair.net> References: <20080126203459.3F3362FB4D40@gandalf.geeklair.net> Message-ID: Sooo.... what's goin' on here, Daniel? :) On Jan 26, 2008, at 14:34, Macports User wrote: > checking build system type... powerpc-apple-darwin9.1.0 > checking host system type... powerpc-apple-darwin9.1.0 > checking target system type... powerpc-apple-darwin9.1.0 > checking for sw_vers... sw_vers > checking Mac OS X version... 10.5.1 > checking Xcode version... 3.0 > checking MacPorts version... 1.6.0 > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ISO C89... none needed > checking for gcc... gcc > checking whether we are using the GNU Objective C compiler... yes > checking whether gcc accepts -g... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether make sets $(MAKE)... yes > checking whether ln -s works... yes > checking for mtree... /usr/sbin/mtree > checking for cvs... /usr/bin/cvs > checking for svn... /usr/bin/svn > checking for rsync... /usr/bin/rsync > checking for sed... /usr/bin/sed > checking for tar... /usr/bin/tar > checking for make... /usr/bin/make > checking for launchd... no > checking for launchctl... /bin/launchctl > checking for xcodebuild... /usr/bin/xcodebuild > checking for gnutar... /usr/bin/gnutar > checking for gnumake... /usr/bin/gnumake > checking for bzip2... /usr/bin/bzip2 > checking for xar... /usr/bin/xar > checking for open... /usr/bin/open > checking for sed... (cached) /usr/bin/sed > checking which sed flag to use for extended regexp... -E (BSD) > checking for tar... (cached) /usr/bin/tar > checking for gnutar... (cached) /usr/bin/gnutar > checking for which tar variant to use... /usr/bin/gnutar > checking for /usr/bin/gnutar --no-same-owner support... yes > checking how to mark unused variables... > checking for gcc symbol visibility attribute... __attribute__ > ((visibility("hidden"))) > checking for the pthreads library -lpthreads... no > checking whether pthreads work without any flags... yes > checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE > checking if more special flags are required for pthreads... - > D_THREAD_SAFE > checking how to run the Objective C preprocessor... gcc -E > checking for grep that handles long lines and -e... /usr/bin/grep > checking for egrep... /usr/bin/grep -E > checking for ANSI C header files... rm: conftest.dSYM: is a directory > rm: conftest.dSYM: is a directory > yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking objc/objc.h usability... yes > checking objc/objc.h presence... yes > checking for objc/objc.h... yes > checking if linking libobjc requires pthreads... no > checking for Apple Objective-C runtime... yes > checking for GNU Objective C runtime... no > configure: Using Apple Objective-C runtime > checking for Apple Foundation library... yes > configure: WARNING: GNUSTEP_SYSTEM_ROOT is not defined in your > environment, preventing the use of GNUstep's Foundation library > configure: Using Apple Foundation library > checking for CoreFoundation framework... yes > checking for SystemConfiguration framework... yes > checking for IOKit framework... yes > checking for CFNotificationCenterGetDarwinNotifyCenter... yes > checking for whether we will build daemondo... yes > checking for ports tree... configure: WARNING: No ports tree found > checking for MacPorts config directory... ${sysconfdir}/macports > checking for install user... mp-user > checking for install group... mp-user > checking what permissions to use for installation directories... 0755 > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... (cached) yes > checking for dirent.h that defines DIR... yes > checking for library containing opendir... none required > checking for sys/wait.h that is POSIX.1 compatible... yes > checking whether stat file-mode macros are broken... no > checking limits.h usability... yes > checking limits.h presence... yes > checking for limits.h... yes > checking paths.h usability... yes > checking paths.h presence... yes > checking for paths.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking crt_externs.h usability... yes > checking crt_externs.h presence... yes > checking for crt_externs.h... yes > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/cdefs.h usability... yes > checking sys/cdefs.h presence... yes > checking for sys/cdefs.h... yes > checking err.h usability... yes > checking err.h presence... yes > checking for err.h... yes > checking libgen.h usability... yes > checking libgen.h presence... yes > checking for libgen.h... yes > checking sys/socket.h usability... yes > checking sys/socket.h presence... yes > checking for sys/socket.h... yes > checking readline/readline.h usability... yes > checking readline/readline.h presence... yes > checking for readline/readline.h... yes > checking readline/history.h usability... yes > checking readline/history.h presence... yes > checking for readline/history.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking sys/paths.h usability... yes > checking sys/paths.h presence... yes > checking for sys/paths.h... yes > checking utime.h usability... yes > checking utime.h presence... yes > checking for utime.h... yes > checking whether closedir returns void... no > checking for pid_t... yes > checking vfork.h usability... no > checking vfork.h presence... no > checking for vfork.h... no > checking for fork... yes > checking for vfork... yes > checking for working fork... yes > checking for working vfork... (cached) yes > checking whether strerror_r is declared... yes > checking for strerror_r... yes > checking whether strerror_r returns char *... no > checking for bzero... yes > checking for memset... yes > checking for dup2... yes > checking for regcomp... yes > checking for strdup... yes > checking for strerror... yes > checking for strtol... yes > checking for fgetln... yes > checking for lockf... yes > checking for flock... yes > checking for setmode... yes > checking for strcasecmp... yes > checking for strncasecmp... yes > checking for strlcpy... yes > checking for copyfile... yes > checking if readlink conforms to POSIX 1003.1a... yes > checking for MD5Update in -lmd... no > checking for MD5_Update in -lcrypto... yes > checking openssl/md5.h usability... yes > checking openssl/md5.h presence... yes > checking for openssl/md5.h... yes > checking for X... no > checking for XOpenDisplay in -lX11... yes > Please install the X11 SDK packages from the > Xcode Developer Tools CD > configure: error: Broken X11 install. No X11 headers > ./configure script failed. From jmpp at macports.org Sat Jan 26 16:21:15 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Sat Jan 26 16:19:12 2008 Subject: Website localization In-Reply-To: <6D11BB06-6D2F-4796-B820-ADEA00D37C9B@google.com> References: <8E38BA71-0117-1000-EE3B-5CBC448CF2E4-Webmail-10014@mac.com> <199FEC9E-BD52-42BE-AA73-FD68ACEE119F@macports.org> <6D11BB06-6D2F-4796-B820-ADEA00D37C9B@google.com> Message-ID: <40E7F47E-AF6F-4369-8F59-E971D39B10C7@macports.org> Hi Tetsuya! On Jan 25, 2008, at 3:30 PM, Tetsuya Wada wrote: > Hi Juan, > > Thanks for reply. I'll check the URL. > > Thank you for providing us the MacPorts. I'm building one of my Mac > mini as a home server. It couldn't be made without the site. Since > the site is so useful, it would be so nice if the site has Japanese. > I'm sure many Japanese users are interested, also. > > Do you have any plan to publish the site with Japanese as well? If I > could contribute the Japanese translation, it is my pleasure. > > Have a nice weekend. > > Ted I think it would be great to start localizing our new website, even though at the moment we currently don't have any structured plans for it. I guess it's a great moment to start putting them together ;-) If you're acquainted with subversion and our source repository I'd recommend checking out the trunk/www directory, which is where the website sources live. Have a look at the files there and give it a try translating into Japanese the main section files, like contact.php , index.php, install.php and ports.php, in utf-8 format please. There are others that you'll need to have a fully functional Japanese website, but those will have to be sorted out as we put together the new localization structure within trunk/www (there's trunk/www/ localized already, but it's sorely outdated, so don't waste any time looking into that). When you have that initial set of files ready, please submit them as attachments to an appropriate ticket filed under our "Website & Documentation" milestone (http://guide.macports.org/#project.tickets & http://trac.macports.org/projects/macports/newticket) . I'll suggest a localization hierarchy as I give them a try on my local web server. Thank you a lot for your enthusiasm for the project and up-coming contributions, much appreciated! Regards,... -jmpp -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080126/fa76e8de/attachment.html From jmpp at macports.org Sat Jan 26 16:36:07 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Sat Jan 26 16:34:07 2008 Subject: New Trac & Subversion downtime Message-ID: <55304D54-4182-4EF8-A344-169F9B3CDD7B@macports.org> Our energetic sysadmins are working hard to improve our Mac OS Forge experience by yet again boosting server performance. For this reason there will be a scheduled 30 minutes downtime on Monday, January 28th, 8pm PST, so lets plan ahead our svn commits and ticket activity to make room for that. Information will be posted in the #MacOSForge channel of the Freenode IRC network, as usual. A big thank you to Mac OS Forge personnel for the hard work and amazing support they've given us to keep us running so smoothly, much appreciated! Regards,... -jmpp From ryandesign at macports.org Sat Jan 26 17:07:30 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat Jan 26 17:07:33 2008 Subject: Website localization In-Reply-To: <40E7F47E-AF6F-4369-8F59-E971D39B10C7@macports.org> References: <8E38BA71-0117-1000-EE3B-5CBC448CF2E4-Webmail-10014@mac.com> <199FEC9E-BD52-42BE-AA73-FD68ACEE119F@macports.org> <6D11BB06-6D2F-4796-B820-ADEA00D37C9B@google.com> <40E7F47E-AF6F-4369-8F59-E971D39B10C7@macports.org> Message-ID: <647789F8-D15D-43CC-998B-CC44AA60BA26@macports.org> On Jan 26, 2008, at 18:21, Juan Manuel Palacios wrote: > On Jan 25, 2008, at 3:30 PM, Tetsuya Wada wrote: > >> Thank you for providing us the MacPorts. I'm building one of my >> Mac mini as a home server. It couldn't be made without the site. >> Since the site is so useful, it would be so nice if the site has >> Japanese. I'm sure many Japanese users are interested, also. >> >> Do you have any plan to publish the site with Japanese as well? If >> I could contribute the Japanese translation, it is my pleasure. > > > I think it would be great to start localizing our new website, > even though at the moment we currently don't have any structured > plans for it. I guess it's a great moment to start putting them > together ;-) > > If you're acquainted with subversion and our source repository I'd > recommend checking out the trunk/www directory, which is where the > website sources live. Have a look at the files there and give it a > try translating into Japanese the main section files, like > contact.php , index.php, install.php and ports.php, in utf-8 format > please. There are others that you'll need to have a fully > functional Japanese website, but those will have to be sorted out > as we put together the new localization structure within trunk/www > (there's trunk/www/localized already, but it's sorely outdated, so > don't waste any time looking into that). > > When you have that initial set of files ready, please submit them > as attachments to an appropriate ticket filed under our "Website & > Documentation" milestone (http://guide.macports.org/ > #project.tickets & http://trac.macports.org/projects/macports/ > newticket). I'll suggest a localization hierarchy as I give them a > try on my local web server. I'm in favor of having our web site localized. However, I don't think we're at the point where we can start soliciting translations yet. Before a web site can be localized (translated into different languages), it must be internationalized (engineered so that it can be localized). And our web site is very much not. The few times I have looked at the web site source, it has struck me that logic and presentation and user-visible strings are all mixed together which does not lend itself to internationalization. I was going to suggest (and forgot before, so I'm mentioning it now) that we remove the pretty flag flyout menu from the upper right of the site since it doesn't do anything, and can't, until we internationalize. While working at a web site programming company in Germany for 3 years, internationalization was one of my specialties. I researched available options and we ended up using a PHP-reimplementation of gettext in our projects, which I wrote. Message catalogs were edited with POEdit. We also had libraries of functions for dealing with internationalized representations of dates, times and currency. I'll be happy to help internationalize the MacPorts web site. However I fear we need some more work before we can start that. We currently have separate looks and separate code for www.macports.org, guide.macports.org, db.macports.org and trac.macports.org. I would very much like all of this content to have a unified appearance and sensible unified URLs under www.macports.org. This is of course difficult since www.macports.org is PHP, guide.macports.org is XML, db.macports.org is Ruby, and trac.macports.org is Python. Trac can probably be skinned; I'll have to read the docs. XML can be restyled with a different XSLT and CSS. The main web site can be rewritten. As for the MacPorts DB, I still struggle to understand its purpose and its relationship with the Available Ports page. Can someone clarify this for me? Recently I have been interested in the Zend Framework. It is a framework for writing PHP web sites, and yes, there are a zillion other frameworks out there, but the Zend Framework has the distinct advantage of having been written by the same people who wrote the PHP language. I watched the tutorial videos and it seems reasonable. It includes components for DB access using PDO (something else we should be using but aren't), and for localization using gettext or several other apparently standard methods (though I haven't tried using these components yet). I think it would be good if www.macports.org were written to use the Zend Framework. I intend to put together a small unrelated web site using Zend Framework to see how it works. Then it might be nice to sit down and work out what exactly the site map for the MacPorts web experience is. And from that maybe a new internationalized web site can emerge. From dluke at geeklair.net Sat Jan 26 18:44:31 2008 From: dluke at geeklair.net (Daniel J. Luke) Date: Sat Jan 26 18:44:15 2008 Subject: PortIndex Regen Failure on Saturday 2008-01-26 at 15:30:00 In-Reply-To: References: <20080126203459.3F3362FB4D40@gandalf.geeklair.net> Message-ID: <31792435-2547-45F5-85C5-8A2673B35B15@geeklair.net> On Jan 26, 2008, at 5:46 PM, Ryan Schmidt wrote: > Sooo.... what's goin' on here, Daniel? :) Sorry, the machine I run the regen on was upgraded to 10.5 recently. I thought I had installed the X11SDK, but I could have missed it. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080126/5fda07a0/PGP-0001.bin From dluke at geeklair.net Sat Jan 26 18:55:55 2008 From: dluke at geeklair.net (Daniel J. Luke) Date: Sat Jan 26 18:55:38 2008 Subject: PortIndex Regen Failure on Saturday 2008-01-26 at 15:30:00 In-Reply-To: <31792435-2547-45F5-85C5-8A2673B35B15@geeklair.net> References: <20080126203459.3F3362FB4D40@gandalf.geeklair.net> <31792435-2547-45F5-85C5-8A2673B35B15@geeklair.net> Message-ID: <486A759A-5573-4A4A-8690-0819FBC0B5B3@geeklair.net> On Jan 26, 2008, at 9:44 PM, Daniel J. Luke wrote: > On Jan 26, 2008, at 5:46 PM, Ryan Schmidt wrote: >> Sooo.... what's goin' on here, Daniel? :) > > Sorry, the machine I run the regen on was upgraded to 10.5 recently. > I thought I had installed the X11SDK, but I could have missed it. Ok, the headers are there (I think) but in /usr/X11/include/X11 (or / usr/X11R6/include/X11) so the configure script needs to be updated. Looks like it fails with the 'Broken X11 install. No X11 headers' error even if you run it with -without-x I probably won't have time to figure this out until Monday or so, though. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080126/594a0773/PGP.bin From mp-user at geeklair.net Sun Jan 27 00:33:35 2008 From: mp-user at geeklair.net (Macports User) Date: Sun Jan 27 00:33:17 2008 Subject: PortIndex Regen Failure on Sunday 2008-01-27 at 03:30:01 Message-ID: <20080127083335.33A782FC064F@gandalf.geeklair.net> checking build system type... powerpc-apple-darwin9.1.0 checking host system type... powerpc-apple-darwin9.1.0 checking target system type... powerpc-apple-darwin9.1.0 checking for sw_vers... sw_vers checking Mac OS X version... 10.5.1 checking Xcode version... 3.0 checking MacPorts version... 1.6.0 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for gcc... gcc checking whether we are using the GNU Objective C compiler... yes checking whether gcc accepts -g... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether make sets $(MAKE)... yes checking whether ln -s works... yes checking for mtree... /usr/sbin/mtree checking for cvs... /usr/bin/cvs checking for svn... /usr/bin/svn checking for rsync... /usr/bin/rsync checking for sed... /usr/bin/sed checking for tar... /usr/bin/tar checking for make... /usr/bin/make checking for launchd... no checking for launchctl... /bin/launchctl checking for xcodebuild... /usr/bin/xcodebuild checking for gnutar... /usr/bin/gnutar checking for gnumake... /usr/bin/gnumake checking for bzip2... /usr/bin/bzip2 checking for xar... /usr/bin/xar checking for open... /usr/bin/open checking for sed... (cached) /usr/bin/sed checking which sed flag to use for extended regexp... -E (BSD) checking for tar... (cached) /usr/bin/tar checking for gnutar... (cached) /usr/bin/gnutar checking for which tar variant to use... /usr/bin/gnutar checking for /usr/bin/gnutar --no-same-owner support... yes checking how to mark unused variables... checking for gcc symbol visibility attribute... __attribute__((visibility("hidden"))) checking for the pthreads library -lpthreads... no checking whether pthreads work without any flags... yes checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE checking if more special flags are required for pthreads... -D_THREAD_SAFE checking how to run the Objective C preprocessor... gcc -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... rm: conftest.dSYM: is a directory rm: conftest.dSYM: is a directory yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking objc/objc.h usability... yes checking objc/objc.h presence... yes checking for objc/objc.h... yes checking if linking libobjc requires pthreads... no checking for Apple Objective-C runtime... yes checking for GNU Objective C runtime... no configure: Using Apple Objective-C runtime checking for Apple Foundation library... yes configure: WARNING: GNUSTEP_SYSTEM_ROOT is not defined in your environment, preventing the use of GNUstep's Foundation library configure: Using Apple Foundation library checking for CoreFoundation framework... yes checking for SystemConfiguration framework... yes checking for IOKit framework... yes checking for CFNotificationCenterGetDarwinNotifyCenter... yes checking for whether we will build daemondo... yes checking for ports tree... configure: WARNING: No ports tree found checking for MacPorts config directory... ${sysconfdir}/macports checking for install user... mp-user checking for install group... mp-user checking what permissions to use for installation directories... 0755 checking how to run the C preprocessor... gcc -E checking for ANSI C header files... (cached) yes checking for dirent.h that defines DIR... yes checking for library containing opendir... none required checking for sys/wait.h that is POSIX.1 compatible... yes checking whether stat file-mode macros are broken... no checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking paths.h usability... yes checking paths.h presence... yes checking for paths.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking crt_externs.h usability... yes checking crt_externs.h presence... yes checking for crt_externs.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/cdefs.h usability... yes checking sys/cdefs.h presence... yes checking for sys/cdefs.h... yes checking err.h usability... yes checking err.h presence... yes checking for err.h... yes checking libgen.h usability... yes checking libgen.h presence... yes checking for libgen.h... yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking readline/readline.h usability... yes checking readline/readline.h presence... yes checking for readline/readline.h... yes checking readline/history.h usability... yes checking readline/history.h presence... yes checking for readline/history.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking sys/paths.h usability... yes checking sys/paths.h presence... yes checking for sys/paths.h... yes checking utime.h usability... yes checking utime.h presence... yes checking for utime.h... yes checking whether closedir returns void... no checking for pid_t... yes checking vfork.h usability... no checking vfork.h presence... no checking for vfork.h... no checking for fork... yes checking for vfork... yes checking for working fork... yes checking for working vfork... (cached) yes checking whether strerror_r is declared... yes checking for strerror_r... yes checking whether strerror_r returns char *... no checking for bzero... yes checking for memset... yes checking for dup2... yes checking for regcomp... yes checking for strdup... yes checking for strerror... yes checking for strtol... yes checking for fgetln... yes checking for lockf... yes checking for flock... yes checking for setmode... yes checking for strcasecmp... yes checking for strncasecmp... yes checking for strlcpy... yes checking for copyfile... yes checking if readlink conforms to POSIX 1003.1a... yes checking for MD5Update in -lmd... no checking for MD5_Update in -lcrypto... yes checking openssl/md5.h usability... yes checking openssl/md5.h presence... yes checking for openssl/md5.h... yes checking for X... no checking for XOpenDisplay in -lX11... yes Please install the X11 SDK packages from the Xcode Developer Tools CD configure: error: Broken X11 install. No X11 headers ./configure script failed. From ryandesign at macports.org Sun Jan 27 04:19:21 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun Jan 27 04:19:23 2008 Subject: [33443] trunk/dports/python/py25-matplotlib/Portfile In-Reply-To: <20080127120234.1AADCCDB955@beta.macosforge.org> References: <20080127120234.1AADCCDB955@beta.macosforge.org> Message-ID: On Jan 27, 2008, at 06:02, jochen@macports.org wrote: > +variant cairo conflicts description "Allow to use cairo for > interactive plotting" { > + depends_lib-append port:py25-cairo > +} Does the cairo variant conflict with another variant? If so, you didn't say which one. If not, the "conflicts" keyword should be removed. From raimue at macports.org Sun Jan 27 10:50:07 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun Jan 27 10:49:49 2008 Subject: PortIndex Regen Failure on Saturday 2008-01-26 at 15:30:00 In-Reply-To: <486A759A-5573-4A4A-8690-0819FBC0B5B3@geeklair.net> References: <20080126203459.3F3362FB4D40@gandalf.geeklair.net> <31792435-2547-45F5-85C5-8A2673B35B15@geeklair.net> <486A759A-5573-4A4A-8690-0819FBC0B5B3@geeklair.net> Message-ID: <479CD25F.2050204@macports.org> Daniel J. Luke wrote: > Looks like it fails with the 'Broken X11 install. No X11 headers' error > even if you run it with -without-x As a workaround: ./configure LDFLAGS=-L/usr/X11/lib Works for me... Rainer From afb at macports.org Sun Jan 27 12:24:48 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun Jan 27 12:24:31 2008 Subject: PortIndex Regen Failure on Saturday 2008-01-26 at 15:30:00 In-Reply-To: <479CD25F.2050204@macports.org> References: <20080126203459.3F3362FB4D40@gandalf.geeklair.net> <31792435-2547-45F5-85C5-8A2673B35B15@geeklair.net> <486A759A-5573-4A4A-8690-0819FBC0B5B3@geeklair.net> <479CD25F.2050204@macports.org> Message-ID: <0e5c325026669390e3166055f3fa2c08@macports.org> Rainer M?ller: >> Looks like it fails with the 'Broken X11 install. No X11 headers' >> error even if you run it with -without-x > > As a workaround: > > ./configure LDFLAGS=-L/usr/X11/lib > Works for me... Errors like these are sometimes caused by the stupid symlink: /usr/include/X11 -> ../X11/include/X11 It has a tendency to make autoconf think that X11 doesn't have a prefix, since the header "worked"... --anders From mp-user at geeklair.net Sun Jan 27 12:30:01 2008 From: mp-user at geeklair.net (Macports User) Date: Sun Jan 27 12:29:40 2008 Subject: PortIndex Regen Failure on Sunday 2008-01-27 at 15:30:00 Message-ID: <20080127203002.132832FC9A76@gandalf.geeklair.net> svn: Working copy '/Users/mp-user/mp_svn_index_regen/source/dports' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) Updating the dports tree from http://svn.macports.org/repository/macports/trunk/dports failed. From afb at macports.org Sun Jan 27 12:47:43 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun Jan 27 12:47:25 2008 Subject: PortIndex Regen Failure on Saturday 2008-01-26 at 15:30:00 In-Reply-To: <486A759A-5573-4A4A-8690-0819FBC0B5B3@geeklair.net> References: <20080126203459.3F3362FB4D40@gandalf.geeklair.net> <31792435-2547-45F5-85C5-8A2673B35B15@geeklair.net> <486A759A-5573-4A4A-8690-0819FBC0B5B3@geeklair.net> Message-ID: <8c9cda32cc199c64bc4b9a0360a998c2@macports.org> Daniel J. Luke wrote: > Looks like it fails with the 'Broken X11 install. No X11 headers' > error even if you run it with -without-x I can reproduce this, on Leopard. It's a bug, will add to Trac once it wakes up from the coma. i.e. it reports that error even *with* all headers, if you specify the --without-x option... --anders From dluke at geeklair.net Sun Jan 27 14:53:56 2008 From: dluke at geeklair.net (Daniel J. Luke) Date: Sun Jan 27 14:53:45 2008 Subject: PortIndex Regen Failure on Saturday 2008-01-26 at 15:30:00 In-Reply-To: <0e5c325026669390e3166055f3fa2c08@macports.org> References: <20080126203459.3F3362FB4D40@gandalf.geeklair.net> <31792435-2547-45F5-85C5-8A2673B35B15@geeklair.net> <486A759A-5573-4A4A-8690-0819FBC0B5B3@geeklair.net> <479CD25F.2050204@macports.org> <0e5c325026669390e3166055f3fa2c08@macports.org> Message-ID: <990AC219-FB9B-4193-AF25-0EAA31AA8359@geeklair.net> On Jan 27, 2008, at 3:24 PM, Anders F Bj?rklund wrote: >>> Looks like it fails with the 'Broken X11 install. No X11 headers' >>> error even if you run it with -without-x >> >> As a workaround: >> >> ./configure LDFLAGS=-L/usr/X11/lib >> Works for me... > > Errors like these are sometimes caused by the stupid symlink: /usr/ > include/X11 -> ../X11/include/X11 > > It has a tendency to make autoconf think that X11 doesn't have a > prefix, since the header "worked"... It doesn't look like that was the problem in this case, since it fails the same way for me when I remove that symlink. I don't have the same problem with configure on my other Leopard machine, so I suppose there's something peculiar with how I have my server setup. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080127/798fdcbb/PGP-0001.bin From frstan at bellsouth.net Sun Jan 27 22:13:35 2008 From: frstan at bellsouth.net (William Davis) Date: Sun Jan 27 22:13:14 2008 Subject: Fwd: Trying to revert X11 after 2.1.3 install References: Message-ID: <52B429AB-9E22-4CBF-9B8D-7AF3AEC46C1E@bellsouth.net> Begin forwarded message: > From: Jeremy Huddleston > Date: January 27, 2008 6:06:35 PM EST > To: Fred Dushin > Cc: x11-users@lists.apple.com, Harald Hanche-Olsen > > Subject: Re: Trying to revert X11 after 2.1.3 install > > > On Jan 27, 2008, at 09:27, Fred Dushin wrote: > >> Starting wireshark is still killing my X server (after reverting >> back to 2.0, and then upgrading to 2.1.3). I'm attaching the >> report that would go to Apple (and I assume not prioritized?). >> >> I built wireshark using a fresh install of macports 1.6.0, after >> doing an upgrade from 10.4.latest to 10.5, and then 10.5.1. >> >> Here's what otool is telling me (interesting that it's taking >> libXrender from macports -- now that I think if it, I wonder if I >> built my macports when I only had X11User -- not X11SDK instaled): > > macports will always do this... one of the reasons I'm considering > dropping macports and looking into fink... <======== NOTE > >> Thread 1 Crashed: >> 0 X 0x000b0088 fbSolid + 600 > > This is already in the buglist in trac, and one of the bugs that I > think/hope will be fixed automagically by out switch to 1.4 since I > think most of this code was reworked by x.org during that transition > (not 100% certain of that). We still have one major regression in > 1.4 over 1.3 that Ben and I are trying to work out before we release > a drop-in beta Xquartz binary for you guys to test out. > > --Jeremy _______________________________________________ > Do not post admin requests to the list. They will be ignored. > X11-users mailing list (X11-users@lists.apple.com) > Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/x11-users/frstan%40bellsouth.net > > This email sent to frstan@bellsouth.net Please see the line marked NOTE above William Davis frstanATbellsouthDOTnet Mac OS X.5.1 Darwin 9.1.0 XQuartz 2.1.3 - (xorg-server 1.3.0-apple9) Mac Mini Intel Duo @ 1.86 GHz Mundus vult decepi, ego non -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080128/253e4235/attachment.html From ryandesign at macports.org Mon Jan 28 00:14:18 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Jan 28 00:14:15 2008 Subject: Trying to revert X11 after 2.1.3 install In-Reply-To: <52B429AB-9E22-4CBF-9B8D-7AF3AEC46C1E@bellsouth.net> References: <52B429AB-9E22-4CBF-9B8D-7AF3AEC46C1E@bellsouth.net> Message-ID: <79D7A7F4-3A60-4896-ABBD-D4AF8517ACA4@macports.org> On Jan 28, 2008, at 00:13, William Davis wrote: > Begin forwarded message: > >> From: Jeremy Huddleston >> Date: January 27, 2008 6:06:35 PM EST >> To: Fred Dushin >> Cc: x11-users@lists.apple.com, Harald Hanche-Olsen >> >> Subject: Re: Trying to revert X11 after 2.1.3 install >> >> On Jan 27, 2008, at 09:27, Fred Dushin wrote: >> >>> Starting wireshark is still killing my X server (after reverting >>> back to 2.0, and then upgrading to 2.1.3). I'm attaching the >>> report that would go to Apple (and I assume not prioritized?). >>> >>> I built wireshark using a fresh install of macports 1.6.0, after >>> doing an upgrade from 10.4.latest to 10.5, and then 10.5.1. >>> >>> Here's what otool is telling me (interesting that it's taking >>> libXrender from macports -- now that I think if it, I wonder if I >>> built my macports when I only had X11User -- not X11SDK instaled): >> >> macports will always do this... one of the reasons I'm considering >> dropping macports and looking into fink... <======== NOTE >> >>> Thread 1 Crashed: >>> 0 X 0x000b0088 fbSolid + 600 >> >> This is already in the buglist in trac, and one of the bugs that I >> think/hope will be fixed automagically by out switch to 1.4 since >> I think most of this code was reworked by x.org during that >> transition (not 100% certain of that). We still have one major >> regression in 1.4 over 1.3 that Ben and I are trying to work out >> before we release a drop-in beta Xquartz binary for you guys to >> test out. > > Please see the line marked NOTE above It's disorienting to be thrown into a thread with no context or explanation like this. It sounds to me like Fred Dushin is noting that a wireshark installed using MacPorts is linking with its own xrender library instead of the system's, and Jeremy Huddleston points out that MacPorts will always do this, and that he's considering leaving MacPorts because of this. So what is the problem with linking with the MacPorts xrender? Is this a problem for all ports or just wireshark? Should we change to using the system's xrender instead, or is there a bug in the xrender port that we should be fixing? If Jeremy or Fred would like to come to this list to discuss the matter I'm sure we could begin a dialog of some sort. From mp-user at geeklair.net Mon Jan 28 00:33:43 2008 From: mp-user at geeklair.net (Macports User) Date: Mon Jan 28 00:33:21 2008 Subject: PortIndex Regen Failure on Monday 2008-01-28 at 03:30:00 Message-ID: <20080128083343.A0DBF2FE01CF@gandalf.geeklair.net> checking build system type... powerpc-apple-darwin9.1.0 checking host system type... powerpc-apple-darwin9.1.0 checking target system type... powerpc-apple-darwin9.1.0 checking for sw_vers... sw_vers checking Mac OS X version... 10.5.1 checking Xcode version... 3.0 checking MacPorts version... 1.6.0 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for gcc... gcc checking whether we are using the GNU Objective C compiler... yes checking whether gcc accepts -g... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether make sets $(MAKE)... yes checking whether ln -s works... yes checking for mtree... /usr/sbin/mtree checking for cvs... /usr/bin/cvs checking for svn... /usr/bin/svn checking for rsync... /usr/bin/rsync checking for sed... /usr/bin/sed checking for tar... /usr/bin/tar checking for make... /usr/bin/make checking for launchd... no checking for launchctl... /bin/launchctl checking for xcodebuild... /usr/bin/xcodebuild checking for gnutar... /usr/bin/gnutar checking for gnumake... /usr/bin/gnumake checking for bzip2... /usr/bin/bzip2 checking for xar... /usr/bin/xar checking for open... /usr/bin/open checking for sed... (cached) /usr/bin/sed checking which sed flag to use for extended regexp... -E (BSD) checking for tar... (cached) /usr/bin/tar checking for gnutar... (cached) /usr/bin/gnutar checking for which tar variant to use... /usr/bin/gnutar checking for /usr/bin/gnutar --no-same-owner support... yes checking how to mark unused variables... checking for gcc symbol visibility attribute... __attribute__((visibility("hidden"))) checking for the pthreads library -lpthreads... no checking whether pthreads work without any flags... yes checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE checking if more special flags are required for pthreads... -D_THREAD_SAFE checking how to run the Objective C preprocessor... gcc -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... rm: conftest.dSYM: is a directory rm: conftest.dSYM: is a directory yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking objc/objc.h usability... yes checking objc/objc.h presence... yes checking for objc/objc.h... yes checking if linking libobjc requires pthreads... no checking for Apple Objective-C runtime... yes checking for GNU Objective C runtime... no configure: Using Apple Objective-C runtime checking for Apple Foundation library... yes configure: WARNING: GNUSTEP_SYSTEM_ROOT is not defined in your environment, preventing the use of GNUstep's Foundation library configure: Using Apple Foundation library checking for CoreFoundation framework... yes checking for SystemConfiguration framework... yes checking for IOKit framework... yes checking for CFNotificationCenterGetDarwinNotifyCenter... yes checking for whether we will build daemondo... yes checking for ports tree... configure: WARNING: No ports tree found checking for MacPorts config directory... ${sysconfdir}/macports checking for install user... mp-user checking for install group... mp-user checking what permissions to use for installation directories... 0755 checking how to run the C preprocessor... gcc -E checking for ANSI C header files... (cached) yes checking for dirent.h that defines DIR... yes checking for library containing opendir... none required checking for sys/wait.h that is POSIX.1 compatible... yes checking whether stat file-mode macros are broken... no checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking paths.h usability... yes checking paths.h presence... yes checking for paths.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking crt_externs.h usability... yes checking crt_externs.h presence... yes checking for crt_externs.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/cdefs.h usability... yes checking sys/cdefs.h presence... yes checking for sys/cdefs.h... yes checking err.h usability... yes checking err.h presence... yes checking for err.h... yes checking libgen.h usability... yes checking libgen.h presence... yes checking for libgen.h... yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking readline/readline.h usability... yes checking readline/readline.h presence... yes checking for readline/readline.h... yes checking readline/history.h usability... yes checking readline/history.h presence... yes checking for readline/history.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking sys/paths.h usability... yes checking sys/paths.h presence... yes checking for sys/paths.h... yes checking utime.h usability... yes checking utime.h presence... yes checking for utime.h... yes checking whether closedir returns void... no checking for pid_t... yes checking vfork.h usability... no checking vfork.h presence... no checking for vfork.h... no checking for fork... yes checking for vfork... yes checking for working fork... yes checking for working vfork... (cached) yes checking whether strerror_r is declared... yes checking for strerror_r... yes checking whether strerror_r returns char *... no checking for bzero... yes checking for memset... yes checking for dup2... yes checking for regcomp... yes checking for strdup... yes checking for strerror... yes checking for strtol... yes checking for fgetln... yes checking for lockf... yes checking for flock... yes checking for setmode... yes checking for strcasecmp... yes checking for strncasecmp... yes checking for strlcpy... yes checking for copyfile... yes checking if readlink conforms to POSIX 1003.1a... yes checking for MD5Update in -lmd... no checking for MD5_Update in -lcrypto... yes checking openssl/md5.h usability... yes checking openssl/md5.h presence... yes checking for openssl/md5.h... yes checking for X... no checking for XOpenDisplay in -lX11... yes Please install the X11 SDK packages from the Xcode Developer Tools CD configure: error: Broken X11 install. No X11 headers ./configure script failed. From ryandesign at macports.org Mon Jan 28 01:17:38 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Jan 28 01:17:35 2008 Subject: [33483] trunk/base/src/port1.0/portconfigure.tcl In-Reply-To: <20080127204011.C32FACEE5A6@beta.macosforge.org> References: <20080127204011.C32FACEE5A6@beta.macosforge.org> Message-ID: <9C04F100-B55C-4A01-AD06-A0FB9C89BFC2@macports.org> On Jan 27, 2008, at 14:40, afb@macports.org wrote: > Revision: 33483 > http://trac.macosforge.org/projects/macports/changeset/33483 > Author: afb@macports.org > Date: 2008-01-27 12:40:10 -0800 (Sun, 27 Jan 2008) > > Log Message: > ----------- > set canonical system name, for universal configure > > Modified Paths: > -------------- > trunk/base/src/port1.0/portconfigure.tcl > > Modified: trunk/base/src/port1.0/portconfigure.tcl > =================================================================== > --- trunk/base/src/port1.0/portconfigure.tcl 2008-01-27 20:32:06 > UTC (rev 33482) > +++ trunk/base/src/port1.0/portconfigure.tcl 2008-01-27 20:40:10 > UTC (rev 33483) > @@ -116,9 +116,23 @@ > ui_msg "$UI_PREFIX [format [msgcat::mc "Configuring %s"] > [option portname]]" > } > > +# internal function to determine canonical system name for configure > +proc configure_get_universal_system_name {args} { > + global configure.universal_target > + switch -- ${configure.universal_target} { > + "10.4" { return "i686-apple-darwin8" } > + "10.5" { return "i686-apple-darwin9" } > + } > + return "" > +} > + > # internal function to determine the universal args for configure.cmd > proc configure_get_universal_args {args} { > + set system [configure_get_universal_system_name] > set params "--disable-dependency-tracking" > + if {[info exists system] && $system != ""} { > + set params "$params --host=${system} --target=${system}" > + } > return $params > } This works on PowerPC Macs too? What problem does this solve? Just curious. From afb at macports.org Mon Jan 28 03:09:39 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon Jan 28 03:09:15 2008 Subject: [33483] trunk/base/src/port1.0/portconfigure.tcl In-Reply-To: <9C04F100-B55C-4A01-AD06-A0FB9C89BFC2@macports.org> References: <20080127204011.C32FACEE5A6@beta.macosforge.org> <9C04F100-B55C-4A01-AD06-A0FB9C89BFC2@macports.org> Message-ID: <76dda19be007c3f1ee07bcdf135ac72f@macports.org> Ryan Schmidt wrote: > This works on PowerPC Macs too? Sortof. It works OK when building the default i386+ppc archs, but if one wants to build a single "ppc" arch then it should probably be changed into "powerpc-apple-darwin#" instead... Something which is actually rather fun to have around, as it can then build for earlier Mac OS X releases using the SDKs. (Will probably add 10.1-10.3 for completeness, and geek fun) But for the regular UB case it doesn't matter, since the Universal Binaries will run on both platforms anyway... Probably needs to be fixed for the "build twice and merge" > What problem does this solve? Just curious. It solves the (pretty rare) case where you have the configure scripts cue off the current system name... For instance, when they look for "*-*-darwin9*" and then do something Leopardy ? So when compiling using the 10.4u.sdk on Leopard (for instance), one needs to tell ./configure that we're actually targetting an earlier release (also works for 10.1-10.3, as per above) Otherwise, it will run with `/usr/share/libtool/config.guess` --anders From billitch at gmail.com Mon Jan 28 07:23:00 2008 From: billitch at gmail.com (Thomas de Grivel) Date: Mon Jan 28 07:22:36 2008 Subject: Website localization In-Reply-To: <4ec7f0880801280722n1cda67f7qc5d9c6b5e7030fd9@mail.gmail.com> References: <8E38BA71-0117-1000-EE3B-5CBC448CF2E4-Webmail-10014@mac.com> <199FEC9E-BD52-42BE-AA73-FD68ACEE119F@macports.org> <6D11BB06-6D2F-4796-B820-ADEA00D37C9B@google.com> <40E7F47E-AF6F-4369-8F59-E971D39B10C7@macports.org> <647789F8-D15D-43CC-998B-CC44AA60BA26@macports.org> <4ec7f0880801280722n1cda67f7qc5d9c6b5e7030fd9@mail.gmail.com> Message-ID: <4ec7f0880801280723x7ce43f28qe7831231c0e2accc@mail.gmail.com> 2008/1/27, Ryan Schmidt : > > On Jan 26, 2008, at 18:21, Juan Manuel Palacios wrote: > > > On Jan 25, 2008, at 3:30 PM, Tetsuya Wada wrote: > > > >> Thank you for providing us the MacPorts. I'm building one of my > >> Mac mini as a home server. It couldn't be made without the site. > >> Since the site is so useful, it would be so nice if the site has > >> Japanese. I'm sure many Japanese users are interested, also. > >> > >> Do you have any plan to publish the site with Japanese as well? If > >> I could contribute the Japanese translation, it is my pleasure. > > > > > > I think it would be great to start localizing our new website, > > even though at the moment we currently don't have any structured > > plans for it. I guess it's a great moment to start putting them > > together ;-) > > > > If you're acquainted with subversion and our source repository I'd > > recommend checking out the trunk/www directory, which is where the > > website sources live. Have a look at the files there and give it a > > try translating into Japanese the main section files, like > > contact.php , index.php, install.php and ports.php, in utf-8 format > > please. There are others that you'll need to have a fully > > functional Japanese website, but those will have to be sorted out > > as we put together the new localization structure within trunk/www > > (there's trunk/www/localized already, but it's sorely outdated, so > > don't waste any time looking into that). > > > > When you have that initial set of files ready, please submit them > > as attachments to an appropriate ticket filed under our "Website & > > Documentation" milestone (http://guide.macports.org/ > > #project.tickets & http://trac.macports.org/projects/macports/ > > newticket). I'll suggest a localization hierarchy as I give them a > > try on my local web server. > > I'm in favor of having our web site localized. However, I don't think > we're at the point where we can start soliciting translations yet. > Before a web site can be localized (translated into different > languages), it must be internationalized (engineered so that it can > be localized). And our web site is very much not. The few times I > have looked at the web site source, it has struck me that logic and > presentation and user-visible strings are all mixed together which > does not lend itself to internationalization. I was going to suggest > (and forgot before, so I'm mentioning it now) that we remove the > pretty flag flyout menu from the upper right of the site since it > doesn't do anything, and can't, until we internationalize. > > While working at a web site programming company in Germany for 3 > years, internationalization was one of my specialties. I researched > available options and we ended up using a PHP-reimplementation of > gettext in our projects, which I wrote. Message catalogs were edited > with POEdit. We also had libraries of functions for dealing with > internationalized representations of dates, times and currency. I'll > be happy to help internationalize the MacPorts web site. However I > fear we need some more work before we can start that. > > We currently have separate looks and separate code for > www.macports.org, guide.macports.org, db.macports.org and > trac.macports.org. I would very much like all of this content to have > a unified appearance and sensible unified URLs under > www.macports.org. This is of course difficult since www.macports.org > is PHP, guide.macports.org is XML, db.macports.org is Ruby, and > trac.macports.org is Python. Trac can probably be skinned; I'll have > to read the docs. XML can be restyled with a different XSLT and CSS. > The main web site can be rewritten. As for the MacPorts DB, I still > struggle to understand its purpose and its relationship with the > Available Ports page. Can someone clarify this for me? > > Recently I have been interested in the Zend Framework. It is a > framework for writing PHP web sites, and yes, there are a zillion > other frameworks out there, but the Zend Framework has the distinct > advantage of having been written by the same people who wrote the PHP > language. I watched the tutorial videos and it seems reasonable. It > includes components for DB access using PDO (something else we should > be using but aren't), and for localization using gettext or several > other apparently standard methods (though I haven't tried using these > components yet). I think it would be good if www.macports.org were > written to use the Zend Framework. I intend to put together a small > unrelated web site using Zend Framework to see how it works. Then it > might be nice to sit down and work out what exactly the site map for > the MacPorts web experience is. And from that maybe a new > internationalized web site can emerge. Sorry for interfering in this discussion but I must object that in a modern website you ought to separate infrastructure and content, because both always change and could always be further improved (and will be hopefully). However if you wait one to be finished to start the other you will cripple yourself badly because none of them will ever be finished. I assume some translated copy of the site could be made available rather simply and when the time comes it could be merged into the new optimized infrastructure. Well.. that's just suggestion as I can't do much more right now (I might contribute to some ports soon enough though ; ) . Hope it helps, regards, -- Thomas de Grivel From dluke at geeklair.net Mon Jan 28 07:53:51 2008 From: dluke at geeklair.net (Daniel J. Luke) Date: Mon Jan 28 07:53:28 2008 Subject: PortIndex Regen Failure on Saturday 2008-01-26 at 15:30:00 In-Reply-To: <990AC219-FB9B-4193-AF25-0EAA31AA8359@geeklair.net> References: <20080126203459.3F3362FB4D40@gandalf.geeklair.net> <31792435-2547-45F5-85C5-8A2673B35B15@geeklair.net> <486A759A-5573-4A4A-8690-0819FBC0B5B3@geeklair.net> <479CD25F.2050204@macports.org> <0e5c325026669390e3166055f3fa2c08@macports.org> <990AC219-FB9B-4193-AF25-0EAA31AA8359@geeklair.net> Message-ID: <7CFFF6E1-52A3-458D-A7AB-00BB6E99AB8F@geeklair.net> On Jan 27, 2008, at 5:53 PM, Daniel J. Luke wrote: > It doesn't look like that was the problem in this case, since it > fails the same way for me when I remove that symlink. I don't have > the same problem with configure on my other Leopard machine, so I > suppose there's something peculiar with how I have my server setup. After playing with this for a bit, it appears to need /usr/X11/bin in the PATH in order for the configure script to work. This should probably be fixed, but for now I'll just add it to the PATH that the regen script sets for itself. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080128/96081bea/PGP.bin From jkh at apple.com Mon Jan 28 15:22:26 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Mon Jan 28 15:23:01 2008 Subject: platform range and set arguments? In-Reply-To: References: <4E7D4720-E37B-4016-83C7-62B5C391BB56@apple.com> <20080124215221.GD963@darkart.com> Message-ID: On Jan 24, 2008, at 9:35 PM, Ryan Schmidt wrote: >> That makes good sense to me, especially after looking at the >> ghc Portfile. > > The gsl port seems to think this functionality already exists: > > platform darwin 6 7 { > configure.cflags-append "-O1" > } > > I wonder whether this section actually gets used on Panther or > Jaguar... Looking at the code, I don't think it can be. The current code treats the arguments as "platform-name [arch] [version]", so the above statement is only matching for darwin version 7, architecture "6". Unfortunately, fixing this is a bit more complicated than simply hacking some regex matches. The platform procedure just recasts its arguments in terms of a variant, so you'd have to walk the set notation and register multiple variants for each element. I may still find time to do this, but it's more complicated than a 10 minute change. - Jordan From ryandesign at macports.org Tue Jan 29 05:53:44 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Jan 29 05:53:26 2008 Subject: [33536] trunk/dports/sysutils/beanstalkd/Portfile In-Reply-To: <20080129132958.384DED9870E@beta.macosforge.org> References: <20080129132958.384DED9870E@beta.macosforge.org> Message-ID: On Jan 29, 2008, at 07:29, brett@macports.org wrote: > Revision: 33536 > http://trac.macosforge.org/projects/macports/changeset/33536 > Author: brett@macports.org > Date: 2008-01-29 05:29:47 -0800 (Tue, 29 Jan 2008) > > Log Message: > ----------- > and fix portfile for new location > > Modified Paths: > -------------- > trunk/dports/sysutils/beanstalkd/Portfile > > Modified: trunk/dports/sysutils/beanstalkd/Portfile > =================================================================== > --- trunk/dports/sysutils/beanstalkd/Portfile 2008-01-29 13:20:28 > UTC (rev 33535) > +++ trunk/dports/sysutils/beanstalkd/Portfile 2008-01-29 13:29:47 > UTC (rev 33536) > @@ -22,7 +22,7 @@ > port:gmake > > use_configure no > -patchfiles patch-Makefile > +patchfiles files/patch-Makefile > patch.pre_args -p1 > post-patch { > reinplace "s|__PREFIX__|${prefix}|g" ${worksrcpath}/Makefile No, that's not correct; this gives you: $ sudo port install beanstalkd Password: ---> Fetching beanstalkd ---> Attempting to fetch files/patch-Makefile from http:// svn.macports.org/repository/macports/distfiles/beanstalkd ---> Attempting to fetch files/patch-Makefile from http:// svn.macports.org/repository/macports/distfiles/general/ ---> Attempting to fetch files/patch-Makefile from http:// svn.macports.org/repository/macports/downloads/beanstalkd Error: Target org.macports.fetch returned: fetch failed Error: Status 1 encountered during processing. $ This revision should be reverted. The "files" directory is the location in which patchfiles are looked for. The directive "patchfiles patch-Makefile" was already correct. From ryandesign at macports.org Tue Jan 29 06:29:00 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Jan 29 06:28:39 2008 Subject: [33525] trunk/dports/python/py25-gsl/Portfile In-Reply-To: <20080129072126.EE27FD6B239@beta.macosforge.org> References: <20080129072126.EE27FD6B239@beta.macosforge.org> Message-ID: <4A4DFBD8-C2AF-4062-BF14-5273737516AE@macports.org> On Jan 29, 2008, at 01:21, jmpp@macports.org wrote: > Revision: 33525 > http://trac.macosforge.org/projects/macports/changeset/33525 > Author: jmpp@macports.org > Date: 2008-01-28 23:21:25 -0800 (Mon, 28 Jan 2008) > > Log Message: > ----------- > > Change portname to py25-gsl, as it should have been from the start. > > To all committers: when using a given port as the basis of a new > one, please always remember to make sure > you adapt the portname for the latter, as having duplicate portname > entries in our tree is not allowed > (not only does it mess up informational operations, but it could > also wreck havoc for a user that somehow > manages to install the two colliding ports). > > Yes, I'm aware we don't have strong checks against this harmful > situation within MacPorts' base, and I'm also > aware that we should... But, as we currently don't, let warnings > like this raise committers' awareness of the > issue, while we develop a *real* solution. Yeah. A good solution would already be: * "port lint" should issue a warning for this: http://trac.macosforge.org/projects/macports/ticket/13263 * "port lint" should be run by the Subversion repository in a post- commit hook and any problems found emailed to the committer and the maintainer: http://trac.macosforge.org/projects/macports/ticket/12594#comment:4 From ryandesign at macports.org Tue Jan 29 08:06:24 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Jan 29 08:06:10 2008 Subject: [33538] trunk/dports/science/molden/Portfile In-Reply-To: <20080129142108.02220D9A917@beta.macosforge.org> References: <20080129142108.02220D9A917@beta.macosforge.org> Message-ID: <1197758C-5960-41AA-8795-17E017C8718D@macports.org> On Jan 29, 2008, at 08:21, jochen@macports.org wrote: > -destroot { cd ${workpath}/${distname} > - system "cp molden ${destroot}${prefix}/bin" > - } > +destroot { system "install -c -m 755 ${workpath}/$ > {distname}/molden ${destroot}${prefix}/bin/" } Removing the "cd" command is good, but really you should use the Tcl xinstall command, not shell out to the install command using system. This should do it: xinstall -W ${worksrcpath} molden ${destroot}${prefix}/bin From jochen at fhi-berlin.mpg.de Tue Jan 29 08:26:57 2008 From: jochen at fhi-berlin.mpg.de (=?ISO-8859-1?Q?Jochen_K=FCpper?=) Date: Tue Jan 29 08:26:43 2008 Subject: [33538] trunk/dports/science/molden/Portfile In-Reply-To: <1197758C-5960-41AA-8795-17E017C8718D@macports.org> References: <20080129142108.02220D9A917@beta.macosforge.org> <1197758C-5960-41AA-8795-17E017C8718D@macports.org> Message-ID: <5150F742-E603-46C0-ABE0-5DEC0BC41529@fhi-berlin.mpg.de> On 29.01.2008, at 17:06, Ryan Schmidt wrote: > Removing the "cd" command is good, but really you should use the Tcl > xinstall command, not shell out to the install command using system. > This should do it: > > xinstall -W ${worksrcpath} molden ${destroot}${prefix}/bin Thanks Ryan, that works;) Could you please also close the molden ticket for me, Safari still keeps crashing for me when loging in to MacOSforge Ticket URL: Thanks! Greetings, Jochen -- Einigkeit und Recht und Freiheit http://www.Jochen-Kuepper.de Libert?, ?galit?, Fraternit? GnuPG key: CC1B0B4D Sex, drugs and rock-n-roll -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080129/db01e8f4/PGP.bin From wsiegrist at apple.com Tue Jan 29 08:42:55 2008 From: wsiegrist at apple.com (William Siegrist) Date: Tue Jan 29 09:00:36 2008 Subject: Safari Crashed when logging into Mac OS Forge In-Reply-To: <5150F742-E603-46C0-ABE0-5DEC0BC41529@fhi-berlin.mpg.de> References: <20080129142108.02220D9A917@beta.macosforge.org> <1197758C-5960-41AA-8795-17E017C8718D@macports.org> <5150F742-E603-46C0-ABE0-5DEC0BC41529@fhi-berlin.mpg.de> Message-ID: I just wanted to broadcast this since it came up in the thread below... It is a known bug in Safari/MacOS that causes it to crash during a digest exchange over a proxy. Unfortunately, the best thing I can offer as a solution right now is to use another browser when going over a proxy. We are working on moving to a standard SSL-protected form as soon as possible so this wont be an issue anymore, but I have no ETA to give you. Thanks, -Bill On Jan 29, 2008, at 8:26 AM, Jochen K?pper wrote: > Could you please also close the molden ticket for me, Safari still > keeps crashing for me when loging in to MacOSforge > Ticket URL: > > Thanks! ---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist@apple.com 408 862 7337 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080129/4ebd8e54/smime.bin From wsiegrist at apple.com Tue Jan 29 10:59:10 2008 From: wsiegrist at apple.com (William Siegrist) Date: Tue Jan 29 11:00:14 2008 Subject: [33525] trunk/dports/python/py25-gsl/Portfile In-Reply-To: <4A4DFBD8-C2AF-4062-BF14-5273737516AE@macports.org> References: <20080129072126.EE27FD6B239@beta.macosforge.org> <4A4DFBD8-C2AF-4062-BF14-5273737516AE@macports.org> Message-ID: I can add `port lint` to the post-commit for any Portfiles if you want. I dont see a way to get only the list of maintainers from port, but I can always grep/regexp to get them from `port info`? I seem to remember a better way though. -Bill On Jan 29, 2008, at 6:29 AM, Ryan Schmidt wrote: > On Jan 29, 2008, at 01:21, jmpp@macports.org wrote: > >> Revision: 33525 >> http://trac.macosforge.org/projects/macports/changeset/33525 >> Author: jmpp@macports.org >> Date: 2008-01-28 23:21:25 -0800 (Mon, 28 Jan 2008) >> >> Log Message: >> ----------- >> >> Change portname to py25-gsl, as it should have been from the start. >> >> To all committers: when using a given port as the basis of a new >> one, please always remember to make sure >> you adapt the portname for the latter, as having duplicate portname >> entries in our tree is not allowed >> (not only does it mess up informational operations, but it could >> also wreck havoc for a user that somehow >> manages to install the two colliding ports). >> >> Yes, I'm aware we don't have strong checks against this harmful >> situation within MacPorts' base, and I'm also >> aware that we should... But, as we currently don't, let warnings >> like this raise committers' awareness of the >> issue, while we develop a *real* solution. > > Yeah. A good solution would already be: > > > * "port lint" should issue a warning for this: > > http://trac.macosforge.org/projects/macports/ticket/13263 > > > * "port lint" should be run by the Subversion repository in a post- > commit hook and any problems found emailed to the committer and the > maintainer: > > http://trac.macosforge.org/projects/macports/ticket/12594#comment:4 > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev ---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist@apple.com 408 862 7337 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080129/c320e04c/smime.bin From steve at icarus.com Tue Jan 29 18:03:55 2008 From: steve at icarus.com (Stephen Williams) Date: Tue Jan 29 18:10:10 2008 Subject: Poppler won't build on Mac OS X 10.3.9 Message-ID: There are trak items for this issue but it seems to be setting fallow for a while and this is leaving me unable to install gimp. Has anybody any clue how to work around poppler not building so that I can get on with trying to install gimp on my Mac? -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." From wsiegrist at apple.com Tue Jan 29 20:02:08 2008 From: wsiegrist at apple.com (William Siegrist) Date: Tue Jan 29 20:04:29 2008 Subject: [33525] trunk/dports/python/py25-gsl/Portfile In-Reply-To: References: <20080129072126.EE27FD6B239@beta.macosforge.org> <4A4DFBD8-C2AF-4062-BF14-5273737516AE@macports.org> Message-ID: <313B32B1-7C17-4B37-964B-959EEA9D338F@apple.com> I dont need the ticket, but feel free to file one in server/hosting if you want to move the discussion there. I should be able to get this setup tomorrow. Thanks for the "--maintainer", I figured there was a better way, and also the "-q" since I had noticed the exit status issue and was going to also do some grepping for that. -Bill On Jan 29, 2008, at 7:21 PM, Ryan Schmidt wrote: > On Jan 29, 2008, at 12:59, William Siegrist wrote: > >> On Jan 29, 2008, at 6:29 AM, Ryan Schmidt wrote: >> >>> * "port lint" should be run by the Subversion repository in a post- >>> commit hook and any problems found emailed to the committer and >>> the maintainer: >>> >>> http://trac.macosforge.org/projects/macports/ticket/12594#comment:4 >> >> I can add `port lint` to the post-commit for any Portfiles if you >> want. > > That would be great. Should I file you a ticket for that? > >> I dont see a way to get only the list of maintainers from port, but >> I can always grep/regexp to get them from `port info`? I seem to >> remember a better way though. > > Get the port's maintainers (comma-space separated) like this: > > port -q info --maintainer $PORT > > Then you'll have to filter that to exclude nomaintainer@macports.org > and openmaintainer@macports.org. > > `port lint` currently always exits with status 0, even if it finds > something wrong with the portfile. This is unfortunate. However, an > acceptable workaround for now would be to run: > > port -q lint $PORT > > This will only produce output if there are problems in the port. And > only in that case should the email be sent. > ---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist@apple.com 408 862 7337 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080129/6f720e35/smime-0001.bin From cssdev at mac.com Tue Jan 29 20:05:41 2008 From: cssdev at mac.com (cssdev@mac.com) Date: Tue Jan 29 20:07:18 2008 Subject: tetex/texlive dependencies In-Reply-To: <478EF5F4.2050300@root.id.au> References: <16E5B12E-C2CD-49AA-91A2-089920BE2A65@macports.org> <356D3161-B877-420B-BA13-29151D154BC3@macports.org> <20080114091811.GA4002@weetamoe.loria.fr> <9369365D-EBDF-4569-9AD7-E53D6E64D595@macports.org> <20080114223220.GA28838@ruderich.com> <478EF5F4.2050300@root.id.au> Message-ID: On Jan 17, 2008, at 1:30 AM, Joshua Root wrote: > I've made a patch for those and attached it to ticket #12913. I > used the dependency style suggested by Ryan. > > > > Has someone mailed the maintainers of the other affected ports? I just tried to get doxygen to build, but something must be haywire with my system. I had a lot of stuff that didn't get properly uninstalled from teTeX, so I'm not sure if that might still be messing things up. I'm not familiar enough with texlive to know where the problems might be. http://trac.macosforge.org/projects/macports/ticket/13986 Any ideas? Chris From ryandesign at macports.org Wed Jan 30 03:52:35 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Jan 30 03:52:45 2008 Subject: 64-bit versions of some ports In-Reply-To: <2E1AE0A0-2141-44C8-BA6C-C29D5EEDE90A@di.ubi.pt> References: <2E1AE0A0-2141-44C8-BA6C-C29D5EEDE90A@di.ubi.pt> Message-ID: <9EF4D60B-236B-4BA4-B0A2-FF1FFFA92BBB@macports.org> The ability for MacPorts to build 64-bit versions of ports was discussed a little while ago, but I don't think there was any resolution. Let's try again. Paulo Moura wrote to me because users of his swi-prolog port have requested this (requires dependencies gmp and readline to be 64-bit too): On Jan 30, 2008, at 05:30, Paulo Moura wrote: > Some time ago, I posted to the mailing list a message about 64 bits > variants but received no reply. Maybe you're able to provide me > some feedback on this issue. I would like to add 64 bits variants > to some port such as "readline" and "gmp". Is my understanding > (please correct me if I'm wrong) that 64 bits and 32 bits versions > of the same library co-exist peacefully. The reason I'm asking is > that some SWI-Prolog users are asking for a 64 bits variant. In > order to provide this 64 bits variant I need first to have 64 bits > variants in-place for all the libraries SWI-Prolog depend on. And Randy Melder requested this for my mysql5 port (probably requires 64-bit openssl and zlib): On Jan 28, 2008, at 12:35, Randy Melder wrote: > Is this a 64bit compile, or 32? I seems the 32bit compiles have > problems with allocating memory above 2GB. From the previous discussion, I remember that we (or rather mww) started by changing the +universal variant to build all 4 versions (2 architectures each of 32-bit and 64-bit) but this was problematic because many ports failed to build out of the box as 64-bit, and there was no clear upgrade path for those who already had 2- architecture universal variants installed, and it was said that 64- bit versions of most ports don't make sense anyway (aren't faster, or possibly are even slower). But it seems like we want to be able to do this for selected ports. Suppose we say we want to define a new variant called +64bit. Let's figure out what we want that to do. Are we asking for a way to build a 64-bit local-architecture binary instead of a 32-bit local- architecture binary (e.g. x86_64 only)? or in addition to a 32-bit local-architecture binary by installing both into separate paths (e.g. ${prefix}/lib and ${prefix}/lib64 -- I don't think this is the Mac way)? or in addition to a 32-bit local-architecture binary by making a single fat binary (e.g. i386 and x86_64 in one file)? What if the user selects +universal in addition to +64bit? How will we handle that? I saw some commits fly by (by afb) about the universal support in base. Was this something to do with making the universal_archs array configurable? If so, is that user-configurable or port-configurable? The above is really just babbling to demonstrate that I don't know what to do about this problem. Maybe someone else can be smarter for me and figure it out. From afb at macports.org Wed Jan 30 04:21:52 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Wed Jan 30 04:22:05 2008 Subject: 64-bit versions of some ports In-Reply-To: <9EF4D60B-236B-4BA4-B0A2-FF1FFFA92BBB@macports.org> References: <2E1AE0A0-2141-44C8-BA6C-C29D5EEDE90A@di.ubi.pt> <9EF4D60B-236B-4BA4-B0A2-FF1FFFA92BBB@macports.org> Message-ID: <082912fd117f7a8ee3696118ca12a84e@macports.org> Ryan Schmidt wrote: > From the previous discussion, I remember that we (or rather mww) > started by changing the +universal variant to build all 4 versions (2 > architectures each of 32-bit and 64-bit) but this was problematic > because many ports failed to build out of the box as 64-bit, and there > was no clear upgrade path for those who already had 2-architecture > universal variants installed, and it was said that 64-bit versions of > most ports don't make sense anyway (aren't faster, or possibly are > even slower). But it seems like we want to be able to do this for > selected ports. Most of the ports that failed were using Carbon, or otherwise old... (old Carbon GUI does not support 64-bit, only Cocoa GUI does that) I reverted +universal back to meaning "10.4u SDK for ppc/i386 arch", and then made them into parameters for overriding locally if desired. > Suppose we say we want to define a new variant called +64bit. Let's > figure out what we want that to do. Are we asking for a way to build a > 64-bit local-architecture binary instead of a 32-bit > local-architecture binary (e.g. x86_64 only)? or in addition to a > 32-bit local-architecture binary by installing both into separate > paths (e.g. ${prefix}/lib and ${prefix}/lib64 -- I don't think this is > the Mac way)? or in addition to a 32-bit local-architecture binary by > making a single fat binary (e.g. i386 and x86_64 in one file)? What if > the user selects +universal in addition to +64bit? How will we handle > that? I have experimented with adding two new "variants" (or configure options): +m32 +m64 These corresponded with the GCC settings with the same name: -m32 and -m64. When doing +m32 it would add -m32 to CFLAGS, and thus make ppc/i386 binaries. When saying +m64 it would instead add -m64, and make ppc64/x86_64 binaries... The default would be "neither", meaning "go with whatever default GCC has", which would be 32-bit for the Apple version of gcc (Panther-Leopard at least) Or you can use the +universal target, and add all of them to universal_archs. (but this requires that the port supports building universal, at the moment) It probably needs a lot more thought, and needs to be separated from configure so that it can "build twice and merge" for ports not supporting "fat" builds. But for ports using GNU Autotools, the experiments did work out just fine. :-) While I was at it, I also added support for tweaking -march and -mtune... > I saw some commits fly by (by afb) about the universal support in > base. Was this something to do with making the universal_archs array > configurable? If so, is that user-configurable or port-configurable? User-configurable. Currently it is run-time, both will be config-time. One question would be if it would affect the target platform or not ? i.e. would the platform now be "darwin 9 i386", or "darwin 9 x86_64" (probably it shouldn't affect the variants at all, but should affect the binaries created so that they end up as ppc64 and x86_64 instead) And like you mention, doing multilib on other platforms needs "lib64". (at least I think it would, as I am not running any 64-bit just yet) --anders From afb at macports.org Wed Jan 30 04:45:00 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Wed Jan 30 04:45:07 2008 Subject: 64-bit versions of some ports In-Reply-To: <082912fd117f7a8ee3696118ca12a84e@macports.org> References: <2E1AE0A0-2141-44C8-BA6C-C29D5EEDE90A@di.ubi.pt> <9EF4D60B-236B-4BA4-B0A2-FF1FFFA92BBB@macports.org> <082912fd117f7a8ee3696118ca12a84e@macports.org> Message-ID: > And like you mention, doing multilib on other platforms needs "lib64". > (at least I think it would, as I am not running any 64-bit just yet) On second thought, we don't need any /opt/local/lib/{lib32,lib64} or multilib on other platforms - just one native "lib" directory. Just because the system has /usr/lib/lib32 and /usr/lib/lib64 for compatibility, doesn't mean one has to compile using it... Then again, I said the same thing about Universal Binaries too. So maybe MP does "need" multilib, like it "needed" +universal ? But compiling 64-bit binaries on a 64-bit system, _that_ is at least a often required feature and thus it should be supported. --anders PS. http://www.redhat.com/magazine/009jul05/features/multilib/ (on Darwin this is all handled by using the fat binaries) From afb at macports.org Wed Jan 30 05:07:40 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Wed Jan 30 05:07:42 2008 Subject: MacPorts as non-root (and non-admin) Message-ID: <72b2c3dde7673733da228c2ae0ea2106@macports.org> The old request of being able to run MacPorts as non-root resurfaced, something that isn't supported at the moment... Most ports do install under the configurable ${prefix} (and ${x11prefix} for some of the optional X11 ports), but there are also a bunch that are hardcoding the (admin) locations of /Applications/MacPorts and /Library/Frameworks. So the Mac OS X tree (macosx.mtree) probably also needs a prefix added, so that they would instead install under ~/Applications and ~/Library, when running as non-admin ? (and probably default to ~/Library/Tcl for macports1.0) As a first step, I added* two parameters to configure: --with-applications-dir and --with-frameworks-dir It also needs a new Portfile setting added somewhere: a flag for "this port requires root/admin priviledges" It would be set for things like servers or extensions, that really *needs* root in order to run properly... Possibly tying in with the "startupitem.type none", http://lists.macosforge.org/pipermail/macports-dev/2006-October/ 000136.html Then the above two variables could go in as something like: ${destroot.applications} ${destroot.frameworks} --anders * http://trac.macosforge.org/projects/macports/changeset/33499 From raimue at macports.org Wed Jan 30 07:18:18 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed Jan 30 07:18:24 2008 Subject: MacPorts as non-root (and non-admin) In-Reply-To: <72b2c3dde7673733da228c2ae0ea2106@macports.org> References: <72b2c3dde7673733da228c2ae0ea2106@macports.org> Message-ID: <47A0953A.6080307@macports.org> Anders F Bj?rklund wrote: > It also needs a new Portfile setting added somewhere: > a flag for "this port requires root/admin priviledges" > It would be set for things like servers or extensions, > that really *needs* root in order to run properly... That's a good thing, I also don't like the hardcoded /Applications/MacPorts at the moment. > Possibly tying in with the "startupitem.type none", > http://lists.macosforge.org/pipermail/macports-dev/2006-October/000136.html > Then the above two variables could go in as something > like: ${destroot.applications} ${destroot.frameworks} Some ports may also require the real path where Application gets installed. So is ${destroot.applications} meant to be written as ${destroot}${destroot.applications}? And if it only contains /Applications/MacPorts (by default), I think ${destroot.applications} is the wrong name as it is not only used for destrooting. Rainer From wsiegrist at apple.com Wed Jan 30 15:44:36 2008 From: wsiegrist at apple.com (William Siegrist) Date: Wed Jan 30 15:46:08 2008 Subject: [33525] trunk/dports/python/py25-gsl/Portfile In-Reply-To: References: <20080129072126.EE27FD6B239@beta.macosforge.org> <4A4DFBD8-C2AF-4062-BF14-5273737516AE@macports.org> Message-ID: <5998DFA5-A938-4CCE-B2A0-DE1FFA0C8B20@apple.com> Do you want any of the mailing lists emailed as well when errors are found? -Bill On Jan 29, 2008, at 7:21 PM, Ryan Schmidt wrote: > On Jan 29, 2008, at 12:59, William Siegrist wrote: > >> On Jan 29, 2008, at 6:29 AM, Ryan Schmidt wrote: >> >>> * "port lint" should be run by the Subversion repository in a post- >>> commit hook and any problems found emailed to the committer and >>> the maintainer: >>> >>> http://trac.macosforge.org/projects/macports/ticket/12594#comment:4 >> >> I can add `port lint` to the post-commit for any Portfiles if you >> want. > > That would be great. Should I file you a ticket for that? > >> I dont see a way to get only the list of maintainers from port, but >> I can always grep/regexp to get them from `port info`? I seem to >> remember a better way though. > > Get the port's maintainers (comma-space separated) like this: > > port -q info --maintainer $PORT > > Then you'll have to filter that to exclude nomaintainer@macports.org > and openmaintainer@macports.org. > > `port lint` currently always exits with status 0, even if it finds > something wrong with the portfile. This is unfortunate. However, an > acceptable workaround for now would be to run: > > port -q lint $PORT > > This will only produce output if there are problems in the port. And > only in that case should the email be sent. > ---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist@apple.com 408 862 7337 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080130/7341d55a/smime-0001.bin From ryandesign at macports.org Wed Jan 30 16:42:11 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Jan 30 16:42:16 2008 Subject: [33588] trunk/dports/security/cracklib In-Reply-To: <20080130232143.0FFC3E85943@beta.macosforge.org> References: <20080130232143.0FFC3E85943@beta.macosforge.org> Message-ID: In this diff, it's hard to see what functional changes you made, because you also reformatted the whitespace of the file. In the future, could you please commit whitespace changes in a separate revision from functional changes? Thanks. It's not necessary to set the extract.suffix to .tar.gz since that's the default already. You shouldn't define a "largedict" variant, then use "default_variants +largedict" to enable it always. This makes it difficult for the user to disable this functionality, should they want to. (The user can "sudo port install cracklib -largedict" but next time they want to "sudo port upgrade" the +largedict variant will be selected again.) Rather, you should write the port so that this is the default functionality, and then define a "no_largedict" variant to disable it. The largedict variant has the path /opt/local hardcoded into the portfile. MacPorts might be installed into a different prefix so the variable ${prefix} should always be used instead. On Jan 30, 2008, at 17:21, ecronin@macports.org wrote: > Revision: 33588 > http://trac.macosforge.org/projects/macports/changeset/33588 > Author: ecronin@macports.org > Date: 2008-01-30 15:21:42 -0800 (Wed, 30 Jan 2008) > > Log Message: > ----------- > Update to 2.8.12 and set new maintainer. Closes #14100 > > Modified Paths: > -------------- > trunk/dports/security/cracklib/Portfile > > Removed Paths: > ------------- > trunk/dports/security/cracklib/files/ > > Modified: trunk/dports/security/cracklib/Portfile > =================================================================== > --- trunk/dports/security/cracklib/Portfile 2008-01-30 23:11:30 UTC > (rev 33587) > +++ trunk/dports/security/cracklib/Portfile 2008-01-30 23:21:42 UTC > (rev 33588) > @@ -1,3 +1,5 @@ > +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: > nil; c-basic-offset: 4 -*- > +# vim:fenc=utf-8:filetype=tcl:et:sw=4:ts=4:sts=4 > # $Id$ > > PortSystem 1.0 > @@ -2,42 +4,43 @@ > > -name cracklib > -version 2.7 > -categories security > -maintainers nomaintainer > -description A ProActive Password Sanity Library > -long_description CrackLib is a library containing a C function > (well, \ > - lots of functions really, but you only need to use \ > - one of them) which may be used in a passwd-like \ > - program. The idea is simple: try to prevent users \ > - from choosing passwords that could be guessed by \ > - Crack by filtering them out, at source. > -homepage http://www.crypticide.com/users/alecm/ > -master_sites http://www.crypticide.com/users/alecm/security/ > -distname ${name},${version} > -checksums md5 0c84ad7413d9dd3e5c2eaa5f97d53c4a > -platforms darwin > +name cracklib > +version 2.8.12 > +categories security > +maintainers theonelab.com:june > +description A ProActive Password Sanity Library > +long_description CrackLib is a library containing a C function > (well, \ > + lots of functions really, but you only need to > use \ > + one of them) which may be used in a passwd- > like \ > + program. The idea is simple: try to prevent > users \ > + from choosing passwords that could be guessed > by \ > + Crack by filtering them out, at source. > > -patchfiles patch-Makefile.diff \ > - patch-cracklib-Makefile.diff \ > - patch-util-Makefile.diff \ > - patch-util-mkdict.diff > -post-patch { > - file copy ${filespath}/cracklib.3 ${worksrcpath}/cracklib > - file copy ${filespath}/mkdict.1 ${worksrcpath}/util > - file copy ${filespath}/teststr.1 ${worksrcpath}/util > -} > +homepage http://sourceforge.net/projects/cracklib/ > +platforms darwin > +depends_lib port:gettext > +default_variants +largedict > > -configure { > - reinplace "s|@PREFIX@|${prefix}|g" \ > - ${worksrcpath}/util/mkdict.1 \ > - ${worksrcpath}/util/teststr.1 > +master_sites sourceforge > +checksums md5 580346fa1012f9d9769192f49d3801fa \ > + sha1 0a77b21366cfbad675e6e44642026c89b87f41ce \ > + rmd160 91649e66c3ce491b2ebea6135eaa6ba4705ffb58 \ > + > +extract.suffix .tar.gz > + > +configure.args-append --without-python > + > +variant largedict { > + depends_build port:cracklib-words > + destroot.target-append dict-local > } > > -build.args PREFIX=${prefix} VERSION=${version} > -destroot.args PREFIX=${prefix} VERSION=${version} > -post-destroot { > - set docPath "${prefix}/share/doc/${name}" > - xinstall -d -m 0755 ${destroot}${docPath} > - xinstall -m 0644 ${worksrcpath}/README ${destroot}${docPath} > +post-build { > + if {[variant_isset largedict]} { > + file copy /opt/local/share/cracklib/cracklib-words $ > {worksrcpath}/dicts > + } > + > + file attributes ${worksrcpath}/util/cracklib-format - > permissions 0755 > } > > +test.run yes > +test.cmd make > +test.target check From ryandesign at macports.org Wed Jan 30 16:44:17 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Jan 30 16:44:39 2008 Subject: [33586] trunk/dports/security In-Reply-To: <20080130230609.8DB1FE83B50@beta.macosforge.org> References: <20080130230609.8DB1FE83B50@beta.macosforge.org> Message-ID: On Jan 30, 2008, at 17:06, ecronin@macports.org wrote: > +destroot { > + xinstall -d -m 0755 ${destroot}/${prefix}/share/cracklib > + xinstall -m 0644 ${worksrcpath}/${name} ${destroot}/${prefix}/ > share/cracklib > +} There should not be a slash between ${destroot} and ${prefix} because ${prefix} already begins with a slash. From ryandesign at macports.org Wed Jan 30 20:44:59 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Jan 30 20:45:06 2008 Subject: [33588] trunk/dports/security/cracklib In-Reply-To: References: <20080130232143.0FFC3E85943@beta.macosforge.org> Message-ID: On Jan 30, 2008, at 19:01, June Tate-Gans wrote: > On Wed, Jan 30, 2008 at 5:42 PM, Ryan Schmidt wrote: > >> In this diff, it's hard to see what functional changes you made, >> because you also reformatted the whitespace of the file. In the >> future, could you please commit whitespace changes in a separate >> revision from functional changes? Thanks. > > Absolutely. The trick in this case, though, was that I literally > ripped out most of the original portfile, so a diff was actually > rather insufficient to show what it was I did. I will keep this in > mind the next time I send out a revision, though -- I know how painful > diffs can be. My apologies for the additional eye-strain. > >> It's not necessary to set the extract.suffix to .tar.gz since that's >> the default already. > > Noted. I'll remove that from the portfile. > >> You shouldn't define a "largedict" variant, then use >> "default_variants +largedict" to enable it always. This makes it >> difficult for the user to disable this functionality, should they >> want to. (The user can "sudo port install cracklib -largedict" but >> next time they want to "sudo port upgrade" the +largedict variant >> will be selected again.) Rather, you should write the port so that >> this is the default functionality, and then define a "no_largedict" >> variant to disable it. > > Mm. I thought about this for a while before submitting the patch. > Thing is, cracklib's functionality is severely reduced without that > dictionary, and it seemed to be the upstream maintainer's intention to > include it, which is why it is the default. Your idea makes quite a > lot of sense, though, and I will include it soon. FYI: the macports > guide doesn't mention anything about the upgrade issue you mentioned > above in the variants section, which is why I didn't consider that > aspect. The guide mentions it here: http://guide.macports.org/#reference.variants.user-selected "Due to a bug in the current MacPorts base default_variants shouldn't be used at the moment as they cause problems while upgrading ports." >> The largedict variant has the path /opt/local hardcoded into the >> portfile. MacPorts might be installed into a different prefix so the >> variable ${prefix} should always be used instead. > > Greh -- thought I managed to nix most of those. I'll fix that in the > next revision. My apologies. > > Thanks for the human-linting -- it was quite informative. =o) What can I say, I like keeping an eye on the commit mails. :) From june at theonelab.com Wed Jan 30 20:48:35 2008 From: june at theonelab.com (June Tate-Gans) Date: Wed Jan 30 20:48:34 2008 Subject: [33588] trunk/dports/security/cracklib In-Reply-To: References: <20080130232143.0FFC3E85943@beta.macosforge.org> Message-ID: > > Mm. I thought about this for a while before submitting the patch. > > Thing is, cracklib's functionality is severely reduced without that > > dictionary, and it seemed to be the upstream maintainer's intention to > > include it, which is why it is the default. Your idea makes quite a > > lot of sense, though, and I will include it soon. FYI: the macports > > guide doesn't mention anything about the upgrade issue you mentioned > > above in the variants section, which is why I didn't consider that > > aspect. > > The guide mentions it here: > > http://guide.macports.org/#reference.variants.user-selected > > "Due to a bug in the current MacPorts base default_variants shouldn't > be used at the moment as they cause problems while upgrading ports." Heh -- that'll teach me to not double-check before I spout something like that again. Mouth? Meet foot. You two will be having a great time together for a while... =o) -- June Tate-Gans | Don't try to outweird me, three-eyes. I get stranger things www.theonelab.com | than you free with my breakfast cereal. -- Zaphod Beeblebrox From jmpp at macports.org Wed Jan 30 22:50:48 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Wed Jan 30 22:49:08 2008 Subject: [33591] branches/release_1_6/base/portmgr/dmg/postflight In-Reply-To: <20080131063652.C603BE97348@beta.macosforge.org> References: <20080131063652.C603BE97348@beta.macosforge.org> Message-ID: <72C56823-5E77-46EA-BB2D-8066DE78EA09@macports.org> On Jan 31, 2008, at 2:06 AM, jmpp@macports.org wrote: > Revision > 33591 > Author > jmpp@macports.org > Date > 2008-01-30 22:36:50 -0800 (Wed, 30 Jan 2008) > Log Message > > Seems like the source of all my pains is Installer.app, which > aparently limits the environment I run under in some way > and forces SHELL to /bin/sh always (even if I run as a login shell, > it just doesn't seem to be possible to get to the > user's info), rendering useless the `case` routine that tries to > determine the shell I need to tweak. > > As a lame workaround, I'm going to glob for *sh to match /bin/sh and > thus still write my settings to the common profile file, > leaving all those *csh users out there a bit in dispair. Please disregard this, r33592 explains why. -jmpp -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080131/b143a07f/attachment.html From ryandesign at macports.org Thu Jan 31 00:06:23 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Jan 31 00:06:28 2008 Subject: [33591] branches/release_1_6/base/portmgr/dmg/postflight In-Reply-To: <20080131063652.C603BE97348@beta.macosforge.org> References: <20080131063652.C603BE97348@beta.macosforge.org> Message-ID: <7BE7D875-E4B5-4A14-888B-E479ADBB0BC7@macports.org> On Jan 31, 2008, at 00:36, jmpp@macports.org wrote: > Revision: 33591 > http://trac.macosforge.org/projects/macports/changeset/33591 > Author: jmpp@macports.org > Date: 2008-01-30 22:36:50 -0800 (Wed, 30 Jan 2008) > > Log Message: > ----------- > > Seems like the source of all my pains is Installer.app, which > aparently limits the environment I run under in some way > and forces SHELL to /bin/sh always (even if I run as a login shell, > it just doesn't seem to be possible to get to the > user's info), rendering useless the `case` routine that tries to > determine the shell I need to tweak. > > As a lame workaround, I'm going to glob for *sh to match /bin/sh > and thus still write my settings to the common profile file, > leaving all those *csh users out there a bit in dispair. Could you read the user's real shell like this? USHELL="$(nicl . -read /users/rschmidt shell | sed 's/^shell: //'')" From jmpp at macports.org Thu Jan 31 07:29:55 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Thu Jan 31 07:28:19 2008 Subject: [33591] branches/release_1_6/base/portmgr/dmg/postflight In-Reply-To: <7BE7D875-E4B5-4A14-888B-E479ADBB0BC7@macports.org> References: <20080131063652.C603BE97348@beta.macosforge.org> <7BE7D875-E4B5-4A14-888B-E479ADBB0BC7@macports.org> Message-ID: On Jan 31, 2008, at 3:36 AM, Ryan Schmidt wrote: > On Jan 31, 2008, at 00:36, jmpp@macports.org wrote: > >> Revision: 33591 >> http://trac.macosforge.org/projects/macports/changeset/33591 >> Author: jmpp@macports.org >> Date: 2008-01-30 22:36:50 -0800 (Wed, 30 Jan 2008) >> >> Log Message: >> ----------- >> >> Seems like the source of all my pains is Installer.app, which >> aparently limits the environment I run under in some way >> and forces SHELL to /bin/sh always (even if I run as a login shell, >> it just doesn't seem to be possible to get to the >> user's info), rendering useless the `case` routine that tries to >> determine the shell I need to tweak. >> >> As a lame workaround, I'm going to glob for *sh to match /bin/sh >> and thus still write my settings to the common profile file, >> leaving all those *csh users out there a bit in dispair. > > Could you read the user's real shell like this? > > USHELL="$(nicl . -read /users/rschmidt shell | sed 's/^shell: //'')" Very nice suggestion Ryan, thanks! I'd been making assumptions about the environment under which a shell script runs, and not only do I think I was mistaken in the general case, but also Installer.app seems to make the situation even worse by apparently enforcing a very specific environment (understandable from the security concerned point of view), but then again it could have been just my tired eyes last night reading that from /var/log/install.log In any case, your suggestion seems straight forward and simple enough, so I'll quit trying to reinvent the wheel and will give it a shot as soon as I get a few spare minutes (there are some implementation details, like nicl for < 10.4 and dscl for Leopard, among others). Regards,... -jmpp From dluke at geeklair.net Thu Jan 31 08:08:31 2008 From: dluke at geeklair.net (Daniel J. Luke) Date: Thu Jan 31 08:08:30 2008 Subject: [33591] branches/release_1_6/base/portmgr/dmg/postflight In-Reply-To: References: <20080131063652.C603BE97348@beta.macosforge.org> <7BE7D875-E4B5-4A14-888B-E479ADBB0BC7@macports.org> Message-ID: On Jan 31, 2008, at 10:29 AM, Juan Manuel Palacios wrote: >> USHELL="$(nicl . -read /users/rschmidt shell | sed 's/^shell: //'')" > > In any case, your suggestion seems straight forward and simple > enough, so I'll quit trying to reinvent the wheel and will give it a > shot as soon as I get a few spare minutes (there are some > implementation details, like nicl for < 10.4 and dscl for Leopard, > among others). except that you want to use dscl instead of nicl (and then need to tweak the sed pattern). Something like: dscl . -read /users/dluke shell | sed 's/^.*shell: //' -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080131/06d6cfa9/PGP.bin From ryandesign at macports.org Thu Jan 31 08:19:10 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Jan 31 08:19:15 2008 Subject: [MacPorts] #14104: pv 1.1.0 upgrade/build failure In-Reply-To: <057.ddc27094b693614ec785e2173ccd6525@macosforge.org> References: <048.4072866a14b5f47a2d18d4295369273e@macosforge.org> <057.ddc27094b693614ec785e2173ccd6525@macosforge.org> Message-ID: <4AA02C64-DDFA-41F7-AA2A-3FE4D6172184@macports.org> On Jan 31, 2008, at 09:54, MacPorts wrote: > #14104: pv 1.1.0 upgrade/build failure > --------------------------------- > +------------------------------------------ > Reporter: meissnem@gmail.com | Owner: > ryandesign@macports.org > Type: defect | Status: new > Priority: Normal | Milestone: Port Bugs > Component: ports | Version: 1.6.0 > Resolution: | Keywords: pv upgrade build > failure > --------------------------------- > +------------------------------------------ > Comment (by meissnem@gmail.com): > > The post-patch is needed on Leopard -- that's my primary system > and I can > confirm it. > > I got my hands on a 10.4.11 system myself and confirmed what you > found, so > I'm attaching an updated patch. > > As an aside, it sure would be nice to have a 10.3, 10.4, and 10.5 > machine > available to maintainers for testing... or if not maintainers then at > least committers! That could be nice... but has some complications. First, getting funds and getting machines. I suppose three Mac minis could be found for cheap (ideally five: three PowerPC OSes, two Intel ones). Then, probably each committer would need their own user account with their own MacPorts installation, so as not to step on one another's toes. And then there's the problem that not all ports can install without root access, which none of the commiters would likely have on these testing boxes. From ryandesign at macports.org Thu Jan 31 08:25:40 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Jan 31 08:25:47 2008 Subject: [33591] branches/release_1_6/base/portmgr/dmg/postflight In-Reply-To: References: <20080131063652.C603BE97348@beta.macosforge.org> <7BE7D875-E4B5-4A14-888B-E479ADBB0BC7@macports.org> Message-ID: <3F3A81AC-2C54-414B-BCA2-51C3311C882B@macports.org> On Jan 31, 2008, at 10:08, Daniel J. Luke wrote: > On Jan 31, 2008, at 10:29 AM, Juan Manuel Palacios wrote: > >>> USHELL="$(nicl . -read /users/rschmidt shell | sed 's/^shell: //'')" >> >> In any case, your suggestion seems straight forward and simple >> enough, so I'll quit trying to reinvent the wheel and will give it >> a shot as soon as I get a few spare minutes (there are some >> implementation details, like nicl for < 10.4 and dscl for Leopard, >> among others). > > except that you want to use dscl instead of nicl (and then need to > tweak the sed pattern). > > Something like: > > dscl . -read /users/dluke shell | sed 's/^.*shell: //' For those without access to both 10.4 and 10.5 machines: On 10.4: nicl . -read /users/$USER shell and dscl . -read /users/$USER shell both produce output like this: shell: /bin/bash On 10.5, nicl does not exist, and dscl . -read /users/$USER shell produces output like this: dsAttrTypeNative:shell: /bin/bash So we should set THE_UTIL to "nicl" on 10.4 and earlier, or "dscl" on 10.5 and up, and then use: $THE_UTIL . -read /users/$USER shell | sed 's/^.*: //' From dluke at geeklair.net Thu Jan 31 08:53:29 2008 From: dluke at geeklair.net (Daniel J. Luke) Date: Thu Jan 31 09:08:02 2008 Subject: [33591] branches/release_1_6/base/portmgr/dmg/postflight In-Reply-To: <3F3A81AC-2C54-414B-BCA2-51C3311C882B@macports.org> References: <20080131063652.C603BE97348@beta.macosforge.org> <7BE7D875-E4B5-4A14-888B-E479ADBB0BC7@macports.org> <3F3A81AC-2C54-414B-BCA2-51C3311C882B@macports.org> Message-ID: <55A19A6B-D964-49D3-BD9E-8A340A92D9DE@geeklair.net> On Jan 31, 2008, at 11:25 AM, Ryan Schmidt wrote: > So we should set THE_UTIL to "nicl" on 10.4 and earlier, or "dscl" > on 10.5 and up, and then use: > > $THE_UTIL . -read /users/$USER shell | sed 's/^.*: //' I don't see why you need to use nicl anywhere (if they both produce the same output as you say). As an added bonus, dscl will work on 10.4 even if the user's information isn't stored in netinfo (whereas nicl won't). -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080131/5369158f/PGP.bin From ryandesign at macports.org Thu Jan 31 09:04:01 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Jan 31 09:08:53 2008 Subject: [33591] branches/release_1_6/base/portmgr/dmg/postflight In-Reply-To: <55A19A6B-D964-49D3-BD9E-8A340A92D9DE@geeklair.net> References: <20080131063652.C603BE97348@beta.macosforge.org> <7BE7D875-E4B5-4A14-888B-E479ADBB0BC7@macports.org> <3F3A81AC-2C54-414B-BCA2-51C3311C882B@macports.org> <55A19A6B-D964-49D3-BD9E-8A340A92D9DE@geeklair.net> Message-ID: <12296379-68E5-4894-A7E6-1F04A904AF7B@macports.org> On Jan 31, 2008, at 10:53, Daniel J. Luke wrote: > On Jan 31, 2008, at 11:25 AM, Ryan Schmidt wrote: > >> So we should set THE_UTIL to "nicl" on 10.4 and earlier, or "dscl" >> on 10.5 and up, and then use: >> >> $THE_UTIL . -read /users/$USER shell | sed 's/^.*: //' > > I don't see why you need to use nicl anywhere (if they both produce > the same output as you say). > > As an added bonus, dscl will work on 10.4 even if the user's > information isn't stored in netinfo (whereas nicl won't). Does dscl exist and work on 10.3 and earlier too? The manpage for nicl is from December 2000 which makes me think it exists back to the beginning of Mac OS X, whereas the manpage for dscl is from August 2003. 10.3 was released in October 2003 so maybe it does contain dscl. Can someone with 10.3 (Chris?) please test whether dscl . -read /users/$USER shell works on 10.3, and if so what its output is? From meissnem at gmail.com Thu Jan 31 09:11:31 2008 From: meissnem at gmail.com (Matthew K. Meissner) Date: Thu Jan 31 09:11:32 2008 Subject: [MacPorts] #14104: pv 1.1.0 upgrade/build failure In-Reply-To: <4AA02C64-DDFA-41F7-AA2A-3FE4D6172184@macports.org> References: <048.4072866a14b5f47a2d18d4295369273e@macosforge.org> <057.ddc27094b693614ec785e2173ccd6525@macosforge.org> <4AA02C64-DDFA-41F7-AA2A-3FE4D6172184@macports.org> Message-ID: <9822576D-67FF-4950-A14F-6BE9B140AF8E@gmail.com> On Jan 31, 2008, at 10:19 AM, Ryan Schmidt wrote: > On Jan 31, 2008, at 09:54, MacPorts wrote: > >> #14104: pv 1.1.0 upgrade/build failure >> --------------------------------- >> +------------------------------------------ >> Reporter: meissnem@gmail.com | Owner: ryandesign@macports.org >> Type: defect | Status: new >> Priority: Normal | Milestone: Port Bugs >> Component: ports | Version: 1.6.0 >> Resolution: | Keywords: pv upgrade build >> failure >> --------------------------------- >> +------------------------------------------ >> Comment (by meissnem@gmail.com): >> >> The post-patch is needed on Leopard -- that's my primary system and >> I can >> confirm it. >> >> I got my hands on a 10.4.11 system myself and confirmed what you >> found, so >> I'm attaching an updated patch. >> >> As an aside, it sure would be nice to have a 10.3, 10.4, and 10.5 >> machine >> available to maintainers for testing... or if not maintainers then at >> least committers! > > That could be nice... but has some complications. First, getting > funds and getting machines. I suppose three Mac minis could be found > for cheap (ideally five: three PowerPC OSes, two Intel ones). Then, > probably each committer would need their own user account with their > own MacPorts installation, so as not to step on one another's toes. > And then there's the problem that not all ports can install without > root access, which none of the commiters would likely have on these > testing boxes. > True on all points. I never claimed it was easy :) I just tried using the 10.4 SDK (-isysroot, -mmacosx-version-min, etc.) on my Leopard system to reproduce the results on Tiger and it worked. Does anyone have any experience using that approach to test for different platforms? Would it be a decent poor-man's workaround, or just a waste of time? -- Matt Meissner meissnem at gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2419 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080131/1fbc3f91/smime.bin From dluke at geeklair.net Thu Jan 31 09:35:17 2008 From: dluke at geeklair.net (Daniel J. Luke) Date: Thu Jan 31 09:35:17 2008 Subject: [33591] branches/release_1_6/base/portmgr/dmg/postflight In-Reply-To: <12296379-68E5-4894-A7E6-1F04A904AF7B@macports.org> References: <20080131063652.C603BE97348@beta.macosforge.org> <7BE7D875-E4B5-4A14-888B-E479ADBB0BC7@macports.org> <3F3A81AC-2C54-414B-BCA2-51C3311C882B@macports.org> <55A19A6B-D964-49D3-BD9E-8A340A92D9DE@geeklair.net> <12296379-68E5-4894-A7E6-1F04A904AF7B@macports.org> Message-ID: On Jan 31, 2008, at 12:04 PM, Ryan Schmidt wrote: >> As an added bonus, dscl will work on 10.4 even if the user's >> information isn't stored in netinfo (whereas nicl won't). > > Does dscl exist and work on 10.3 and earlier too? I'm not certain (I think so, given 2 below), but there are two points I would make here. 1. Officially we support the current and previous release of Mac OS X, so 10.3 isn't really a target anymore (and having the automatic path setup not work on 10.3 isn't enough to block usage there - people can still set up $PATH manually like they had to with older releases). 2. MacPorts base already uses dscl (see portutil.tcl) -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080131/232ffc54/PGP-0001.bin From ryandesign at macports.org Thu Jan 31 09:39:12 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Jan 31 09:39:18 2008 Subject: [33591] branches/release_1_6/base/portmgr/dmg/postflight In-Reply-To: References: <20080131063652.C603BE97348@beta.macosforge.org> <7BE7D875-E4B5-4A14-888B-E479ADBB0BC7@macports.org> <3F3A81AC-2C54-414B-BCA2-51C3311C882B@macports.org> <55A19A6B-D964-49D3-BD9E-8A340A92D9DE@geeklair.net> <12296379-68E5-4894-A7E6-1F04A904AF7B@macports.org> Message-ID: <21905386-4E4A-4114-B285-8D76EB9CF322@macports.org> On Jan 31, 2008, at 11:35, Daniel J. Luke wrote: > On Jan 31, 2008, at 12:04 PM, Ryan Schmidt wrote: > >>> As an added bonus, dscl will work on 10.4 even if the user's >>> information isn't stored in netinfo (whereas nicl won't). >> >> Does dscl exist and work on 10.3 and earlier too? > > I'm not certain (I think so, given 2 below), but there are two > points I would make here. > > 1. Officially we support the current and previous release of Mac OS > X, so 10.3 isn't really a target anymore (and having the automatic > path setup not work on 10.3 isn't enough to block usage there - > people can still set up $PATH manually like they had to with older > releases). > > 2. MacPorts base already uses dscl (see portutil.tcl) Chris tested on 10.3 and it works: On Jan 31, 2008, at 11:06, Chris Janton wrote: > face@x:face:122 $ sw_vers > ProductName: Mac OS X Server > ProductVersion: 10.3.9 > BuildVersion: 7W98 > face@x:face:123 $ dscl . -read /users/$USER shell > shell: /bin/bash > face@x:face:124 $ which dscl > /usr/bin/dscl > face@x:face:125 $ If we can support 10.3 without too much additional effort, we should. In this case, we can use dscl on 10.3, 10.4 and 10.5 so no additional effort is required. From afb at macports.org Thu Jan 31 14:55:23 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu Jan 31 14:55:22 2008 Subject: [33591] branches/release_1_6/base/portmgr/dmg/postflight In-Reply-To: References: <20080131063652.C603BE97348@beta.macosforge.org> <7BE7D875-E4B5-4A14-888B-E479ADBB0BC7@macports.org> <3F3A81AC-2C54-414B-BCA2-51C3311C882B@macports.org> <55A19A6B-D964-49D3-BD9E-8A340A92D9DE@geeklair.net> <12296379-68E5-4894-A7E6-1F04A904AF7B@macports.org> Message-ID: <62f20675c5c267fea9540ca893160ad8@macports.org> Daniel J. Luke wrote: > 1. Officially we support the current and previous release of Mac OS X, > so 10.3 isn't really a target anymore (and having the automatic path > setup not work on 10.3 isn't enough to block usage there - people can > still set up $PATH manually like they had to with older releases). Mac OS X 10.5 isn't really out of the Public Beta stage until 10.5.2 and a new X11.app arrives, so it probably doesn't hurt to support Mac OS X 10.3 a little longer still... Besides, PATH isn't working on Leopard either but that doesn't seem to stop everyone (just the occasional puzzled newcomer) Some of us would even *prefer* it being "manual". --anders