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: