From mark.duling at biola.edu Wed Nov 1 21:09:23 2006 From: mark.duling at biola.edu (Mark Duling) Date: Tue Oct 9 16:39:51 2007 Subject: Trac rights In-Reply-To: <45424BA1.1050206@orcaware.com> References: <45424BA1.1050206@orcaware.com> Message-ID: Blair Zajac on Friday, October 27, 2006 at 11:10 AM -0800 wrote: >I don't have rights to change ticket tickets, close tickets, etc, which I >would >like to do given some of my recent commits have fixed these things. > >How do I get those rights? Who handles them? Who do we need to poke to get Blair Trac priviliges? People that want to close bugs are hard to find. Most people only want to open them. :) Mark From ryandesign at macports.org Thu Nov 2 13:37:52 2006 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:39:51 2007 Subject: Renaming a port Message-ID: <0AF10DC6-491D-44DE-AAEF-7B5F0F3A698C@macports.org> What's the procedure if I want to rename a port? I've been meaning to install ViewVC on my Mac since forever, and now that I finally have some free time, I thought I'd give it a shot, and realized it would be good to have a port for it. And in fact there is a port for ViewCVS, the old name of ViewVC, but it's old and not maintained. I'd like to try to update it, but the first step would be to rename it from viewcvs to viewvc. Do I just "cd dports/devel && svn mv viewcvs viewvc" or should we keep the viewcvs port around with a note about the name change? I note that the ethereal port still exists even though that project has been renamed wireshark. What's the recommended way to handle this situation? Is it documented somewhere? From dluke at geeklair.net Thu Nov 2 13:46:02 2006 From: dluke at geeklair.net (Daniel J. Luke) Date: Tue Oct 9 16:39:51 2007 Subject: Renaming a port In-Reply-To: <0AF10DC6-491D-44DE-AAEF-7B5F0F3A698C@macports.org> References: <0AF10DC6-491D-44DE-AAEF-7B5F0F3A698C@macports.org> Message-ID: <56A26B94-C694-42CA-8F6E-6B65B2A39C75@geeklair.net> On Nov 2, 2006, at 4:37 PM, Ryan Schmidt wrote: > What's the recommended way to handle this situation? Is it > documented somewhere? I don't think we have a fixed policy (and if we do, it was developed before we switched to subversion, so we didn't have svn mv available). I would vote to just svn mv it and check in an updated portfile, but I could see where an argument could be made to make it easier for users who only do 'port upgrade' to know what is going on. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20061102/8c61ae77/PGP.bin From cssdev at mac.com Thu Nov 2 14:25:43 2006 From: cssdev at mac.com (cssdev@mac.com) Date: Tue Oct 9 16:39:51 2007 Subject: Renaming a port In-Reply-To: <56A26B94-C694-42CA-8F6E-6B65B2A39C75@geeklair.net> References: <0AF10DC6-491D-44DE-AAEF-7B5F0F3A698C@macports.org> <56A26B94-C694-42CA-8F6E-6B65B2A39C75@geeklair.net> Message-ID: <6F5106A3-F6A1-4623-98B3-8A820B2B9889@mac.com> On Nov 2, 2006, at 3:46 PM, Daniel J. Luke wrote: > On Nov 2, 2006, at 4:37 PM, Ryan Schmidt wrote: >> What's the recommended way to handle this situation? Is it >> documented somewhere? > > I don't think we have a fixed policy (and if we do, it was > developed before we switched to subversion, so we didn't have svn > mv available). > > I would vote to just svn mv it and check in an updated portfile, > but I could see where an argument could be made to make it easier > for users who only do 'port upgrade' to know what is going on. What about adding a ui_error message indicating that the old port has been renamed? Users would need to deactivate the old port before attempting to build or install the new one. Could that be somehow automated as a part of port upgrade? Chris From dluke at geeklair.net Thu Nov 2 15:21:46 2006 From: dluke at geeklair.net (Daniel J. Luke) Date: Tue Oct 9 16:39:51 2007 Subject: Renaming a port In-Reply-To: <6F5106A3-F6A1-4623-98B3-8A820B2B9889@mac.com> References: <0AF10DC6-491D-44DE-AAEF-7B5F0F3A698C@macports.org> <56A26B94-C694-42CA-8F6E-6B65B2A39C75@geeklair.net> <6F5106A3-F6A1-4623-98B3-8A820B2B9889@mac.com> Message-ID: <49670524-5764-4A5B-87CA-71962809115D@geeklair.net> On Nov 2, 2006, at 5:25 PM, cssdev@mac.com wrote: >> I would vote to just svn mv it and check in an updated portfile, >> but I could see where an argument could be made to make it easier >> for users who only do 'port upgrade' to know what is going on. > > What about adding a ui_error message indicating that the old port > has been renamed? That was what I was thinking of for the case where we left the existing port there for a while. The port's description should probably be changed to indicate that it's old, been replaced by the newer port, and will be going away in the future too. > Users would need to deactivate the old port before attempting to > build or install the new one. Could that be somehow automated as a > part of port upgrade? The current upgrade code doesn't have any hooks that would enable that sort of behavior. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20061102/bc76da26/PGP.bin From meissnem at gmail.com Fri Nov 3 07:08:10 2006 From: meissnem at gmail.com (Matt Meissner) Date: Tue Oct 9 16:39:51 2007 Subject: Ticket #8230: MPlayer 1.0rc1 In-Reply-To: <05B706AC-186A-4F35-8700-8D9D528F78B6@gmail.com> References: <05B706AC-186A-4F35-8700-8D9D528F78B6@gmail.com> Message-ID: <42016ECC-3BA9-410A-8673-D9175B6B635D@gmail.com> Looks like this got lost in the shuffle the first time around. I cannot contact the maintainer since MPlayer is not maintained right now. So...would someone please look at the patch in ticket #8230 and commit it? Or let me know why it can't be committed. Thanks, Matt On Oct 24, 2006, at 12:36 PM, Matt Meissner wrote: > The latest release of MPlayer builds on my Intel Mac. I've > attached a patch to ticket #8230. Would an interested commiter > please take a look? > > Thanks, > Matt > > -- > Matt Meissner > meissnem at gmail.com > > -- Matt Meissner meissnem at gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2419 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20061103/f4518dcd/smime.bin From mark.duling at biola.edu Fri Nov 3 14:00:34 2006 From: mark.duling at biola.edu (Mark Duling) Date: Tue Oct 9 16:39:51 2007 Subject: Can any perl gurus answer this? Message-ID: I want to port the perl module CGI-SpeedyCGI for a dependency of another port I want to make. The developer doesn't seem to be available, the other package managers patches don't help, and I can't Google up anything valuable. It configures fine but it fails during build. Anyone have a clue as to why that might be? Mark /usr/bin/gcc-4.0 -o speedy_backend speedy_backend_main.o speedy_perl.o speedy_util.o speedy_sig.o speedy_frontend.o speedy_backend.o speedy_file.o speedy_slot.o speedy_poll.o speedy_ipc.o speedy_group.o speedy_script.o speedy_opt.o speedy_optdefs.o xsinit.o -L/opt/local/lib /opt/local/lib/perl5/5.8.8/darwin-2level/auto/DynaLoader/DynaLoader.a -L/opt/local/lib/perl5/5.8.8/darwin-2level/CORE -lperl -ldl -lm -lc /usr/bin/ld: multiple definitions of symbol _my_perl speedy_backend_main.o definition of _my_perl in section (__DATA,__common) speedy_perl.o definition of _my_perl in section (__DATA,__common) speedy_util.o definition of _my_perl in section (__DATA,__common) speedy_sig.o definition of _my_perl in section (__DATA,__common) speedy_frontend.o definition of _my_perl in section (__DATA,__common) speedy_backend.o definition of _my_perl in section (__DATA,__common) speedy_file.o definition of _my_perl in section (__DATA,__common) speedy_slot.o definition of _my_perl in section (__DATA,__common) speedy_poll.o definition of _my_perl in section (__DATA,__common) speedy_ipc.o definition of _my_perl in section (__DATA,__common) speedy_group.o definition of _my_perl in section (__DATA,__common) speedy_script.o definition of _my_perl in section (__DATA,__common) speedy_opt.o definition of _my_perl in section (__DATA,__common) speedy_optdefs.o definition of _my_perl in section (__DATA,__common) collect2: ld returned 1 exit status make[1]: *** [speedy_backend] Error 1 make: *** [subdirs] Error 2 From dluke at geeklair.net Fri Nov 3 14:37:37 2006 From: dluke at geeklair.net (Daniel J. Luke) Date: Tue Oct 9 16:39:51 2007 Subject: Ticket #8230: MPlayer 1.0rc1 In-Reply-To: <42016ECC-3BA9-410A-8673-D9175B6B635D@gmail.com> References: <05B706AC-186A-4F35-8700-8D9D528F78B6@gmail.com> <42016ECC-3BA9-410A-8673-D9175B6B635D@gmail.com> Message-ID: <60CF4884-2F38-4842-94DD-CC9F3B3C38A9@geeklair.net> On Nov 3, 2006, at 10:08 AM, Matt Meissner wrote: > Looks like this got lost in the shuffle the first time around. > > I cannot contact the maintainer since MPlayer is not maintained > right now. So...would someone please look at the patch in ticket > #8230 and commit it? Or let me know why it can't be committed. I've just committed this. In the future, it would be helpful if you could attach the patch (as file.patch) to the bug instead of having it be in the comments, it's easier to view/apply that way. Also, would you be interested in maintaining this port, since you have an interest in it? [patches from maintainers generally get applied faster, and it's the first step to getting commit access where you'd be able to just update it yourself]. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20061103/6e947402/PGP.bin From meissnem at gmail.com Fri Nov 3 14:55:29 2006 From: meissnem at gmail.com (Matt Meissner) Date: Tue Oct 9 16:39:51 2007 Subject: Ticket #8230: MPlayer 1.0rc1 In-Reply-To: <60CF4884-2F38-4842-94DD-CC9F3B3C38A9@geeklair.net> References: <05B706AC-186A-4F35-8700-8D9D528F78B6@gmail.com> <42016ECC-3BA9-410A-8673-D9175B6B635D@gmail.com> <60CF4884-2F38-4842-94DD-CC9F3B3C38A9@geeklair.net> Message-ID: <454D3A5B-E97C-4AFC-9FF1-71CFDE938DCD@gmail.com> On Nov 3, 2006, at 4:37 PM, Daniel J. Luke wrote: > On Nov 3, 2006, at 10:08 AM, Matt Meissner wrote: >> Looks like this got lost in the shuffle the first time around. >> >> I cannot contact the maintainer since MPlayer is not maintained >> right now. So...would someone please look at the patch in ticket >> #8230 and commit it? Or let me know why it can't be committed. > > I've just committed this. Thanks! > In the future, it would be helpful if you could attach the patch > (as file.patch) to the bug instead of having it be in the comments, > it's easier to view/apply that way. Sorry about that. I'm finding Trac to be a bit unclear sometimes -- I must have missed the attachment button. Also, I couldn't (and still can't) figure out how to add myself to the CC: list on an existing ticket... > Also, would you be interested in maintaining this port, since you > have an interest in it? [patches from maintainers generally get > applied faster, and it's the first step to getting commit access > where you'd be able to just update it yourself]. I'm a pretty light MPlayer user. If no one else on the list wants to maintain it, though, I'd be glad to take it. thanks again, Matt -- Matt Meissner meissnem at gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2419 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20061103/358c09d0/smime.bin From mark.duling at biola.edu Fri Nov 3 14:57:25 2006 From: mark.duling at biola.edu (Mark Duling) Date: Tue Oct 9 16:39:51 2007 Subject: Ticket #8230: MPlayer 1.0rc1 In-Reply-To: <60CF4884-2F38-4842-94DD-CC9F3B3C38A9@geeklair.net> References: <60CF4884-2F38-4842-94DD-CC9F3B3C38A9@geeklair.net> Message-ID: "Daniel J. Luke" on Friday, November 3, 2006 at 3:37 PM -0800 wrote: >> Looks like this got lost in the shuffle the first time around. >> >> I cannot contact the maintainer since MPlayer is not maintained >> right now. So...would someone please look at the patch in ticket >> #8230 and commit it? Or let me know why it can't be committed. > >I've just committed this. > >In the future, it would be helpful if you could attach the patch (as >file.patch) to the bug instead of having it be in the comments, it's >easier to view/apply that way. > >Also, would you be interested in maintaining this port, since you >have an interest in it? [patches from maintainers generally get >applied faster, and it's the first step to getting commit access >where you'd be able to just update it yourself]. There was a duplicate submission on this. Ot can be closed I guess but the submitter is interested in being a maintainer. https://svn.macosforge.org/projects/macports/ticket/10948 Mark From jwa at macports.org Sat Nov 4 03:39:59 2006 From: jwa at macports.org (Jyrki Wahlstedt) Date: Tue Oct 9 16:39:51 2007 Subject: Naming of postgresql & related Message-ID: <3F37E552-5086-4B0B-8197-02AAF21F8300@macports.org> Hi, I just wonder about naming postgresql, some other ports could have the same. Currently postgresql installs v.7.4.12. Then we have postgresql7 (v.7.4.13), postgresql8 (v.8.1.3) and postgresql81 (v. 8.1.4). This is a mess. I think postgresql should always be the latest, then we could, if we want, to have version-specific ports (~7, ~8, ~81). How about this? The related thing comes from the fact that the database formats between point versions of postgresql are not compatible (8.0->8.1). Is there a way to make sure that database is dumped before upgrade. Could one ask a question from the user and wait for an answer (to confirm the operation)? ! ! Jyrki Wahlstedt ! Kolmas linja 12 A 18 mob. +358-400-347 015 skype:jyrkiwahlstedt ! FI-00530 Helsinki http://www.wahlstedt.fi/jyrki/ ! ! Our life is no dream; but it ought to become one and perhaps will. ! PGP key ID: 0x139CC386 fingerprint: F355 B46F 026C B8C1 89C0 A780 6366 EFD9 139C C386 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20061104/ea315b85/attachment.html From dluke at geeklair.net Sat Nov 4 06:46:38 2006 From: dluke at geeklair.net (Daniel J. Luke) Date: Tue Oct 9 16:39:51 2007 Subject: Naming of postgresql & related In-Reply-To: <3F37E552-5086-4B0B-8197-02AAF21F8300@macports.org> References: <3F37E552-5086-4B0B-8197-02AAF21F8300@macports.org> Message-ID: <1107CBE6-1374-4541-A1E6-CE4D1107E199@geeklair.net> On Nov 4, 2006, at 6:39 AM, Jyrki Wahlstedt wrote: > I just wonder about naming postgresql, some other ports could have > the same. Currently postgresql installs v.7.4.12. Then we have > postgresql7 (v.7.4.13), postgresql8 (v.8.1.3) and postgresql81 (v. > 8.1.4). This is a mess. I think postgresql should always be the > latest, then we could, if we want, to have version-specific ports > (~7, ~8, ~81). How about this? This was changed because people do 'port upgrade' and wanted things to work. And because of your point below, the easiest thing is to just have version-specific ports (and let the user handle the file format incompatible upgrades themselves). I believe the 'postgresql' port was deprecated when the decision was made and that it was intended for it to be removed (but I could remember incorrectly). > The related thing comes from the fact that the database formats > between point versions of postgresql are not compatible (8.0->8.1). > Is there a way to make sure that database is dumped before upgrade. That is probably possible, but I don't know if it makes sense to attempt this (for instance, I have a database that would take days to dump that contains data that I'm happy to toss when I want to do an upgrade, but the upgrade step can't know that). Also, 'upgrade' isn't really a normal target, so it would be a hack in the portfile to attempt to do this. > Could one ask a question from the user and wait for an answer (to > confirm the operation)? No. Ports don't prompt for things - this would break unattended (scripted) operation. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20061104/46e2c65f/PGP.bin From rhwood at mac.com Sat Nov 4 08:00:50 2006 From: rhwood at mac.com (Randall Wood) Date: Tue Oct 9 16:39:51 2007 Subject: Renaming a port In-Reply-To: <49670524-5764-4A5B-87CA-71962809115D@geeklair.net> References: <0AF10DC6-491D-44DE-AAEF-7B5F0F3A698C@macports.org> <56A26B94-C694-42CA-8F6E-6B65B2A39C75@geeklair.net> <6F5106A3-F6A1-4623-98B3-8A820B2B9889@mac.com> <49670524-5764-4A5B-87CA-71962809115D@geeklair.net> Message-ID: <854F7AEA-C2EF-4AA6-B7CD-F53238FB5CFF@mac.com> A couple of months ago I moved the abiword2 port to abiword-x11 Take a look at the last version of the abiword2 port for how I made an update switch the ports. On 2 Nov 2006, at 18:21, Daniel J. Luke wrote: > On Nov 2, 2006, at 5:25 PM, cssdev@mac.com wrote: >>> I would vote to just svn mv it and check in an updated portfile, >>> but I could see where an argument could be made to make it easier >>> for users who only do 'port upgrade' to know what is going on. >> >> What about adding a ui_error message indicating that the old port >> has been renamed? > > That was what I was thinking of for the case where we left the > existing port there for a while. > > The port's description should probably be changed to indicate that > it's old, been replaced by the newer port, and will be going away > in the future too. > >> Users would need to deactivate the old port before attempting to >> build or install the new one. Could that be somehow automated as a >> part of port upgrade? > > The current upgrade code doesn't have any hooks that would enable > that sort of behavior. > -- > Daniel J. Luke > +========================================================+ > | *---------------- dluke@geeklair.net ----------------* | > | *-------------- http://www.geeklair.net -------------* | > +========================================================+ > | Opinions expressed are mine and do not necessarily | > | reflect the opinions of my employer. | > +========================================================+ > > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev Randall Wood rhwood@mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From roederja at student.ethz.ch Sun Nov 5 04:31:20 2006 From: roederja at student.ethz.ch (=?UTF-8?B?SmFubiBSw7ZkZXI=?=) Date: Tue Oct 9 16:39:51 2007 Subject: Can any perl gurus answer this? In-Reply-To: References: Message-ID: I think the problem is that there are multiple global variables with the same name. This seems to work on some non-MacOSX systems. The correct way of handling such things is to declare variables with the same name as external (except one). So I guess you'll have to patch the source, however there's also a not recommended linker switch to work arround this. Jann Mark Duling schrieb: > I want to port the perl module CGI-SpeedyCGI for a dependency of another > port I want to make. The developer doesn't seem to be available, the > other package managers patches don't help, and I can't Google up anything > valuable. It configures fine but it fails during build. Anyone have a > clue as to why that might be? > > Mark > > /usr/bin/gcc-4.0 -o speedy_backend speedy_backend_main.o speedy_perl.o > speedy_util.o speedy_sig.o speedy_frontend.o speedy_backend.o > speedy_file.o speedy_slot.o speedy_poll.o speedy_ipc.o speedy_group.o > speedy_script.o speedy_opt.o speedy_optdefs.o xsinit.o -L/opt/local/lib > /opt/local/lib/perl5/5.8.8/darwin-2level/auto/DynaLoader/DynaLoader.a > -L/opt/local/lib/perl5/5.8.8/darwin-2level/CORE -lperl -ldl -lm -lc > /usr/bin/ld: multiple definitions of symbol _my_perl > speedy_backend_main.o definition of _my_perl in section (__DATA,__common) > speedy_perl.o definition of _my_perl in section (__DATA,__common) > speedy_util.o definition of _my_perl in section (__DATA,__common) > speedy_sig.o definition of _my_perl in section (__DATA,__common) > speedy_frontend.o definition of _my_perl in section (__DATA,__common) > speedy_backend.o definition of _my_perl in section (__DATA,__common) > speedy_file.o definition of _my_perl in section (__DATA,__common) > speedy_slot.o definition of _my_perl in section (__DATA,__common) > speedy_poll.o definition of _my_perl in section (__DATA,__common) > speedy_ipc.o definition of _my_perl in section (__DATA,__common) > speedy_group.o definition of _my_perl in section (__DATA,__common) > speedy_script.o definition of _my_perl in section (__DATA,__common) > speedy_opt.o definition of _my_perl in section (__DATA,__common) > speedy_optdefs.o definition of _my_perl in section (__DATA,__common) > collect2: ld returned 1 exit status > make[1]: *** [speedy_backend] Error 1 > make: *** [subdirs] Error 2 From pguyot at kallisys.net Mon Nov 6 06:40:15 2006 From: pguyot at kallisys.net (Paul Guyot) Date: Tue Oct 9 16:39:51 2007 Subject: Easily build Portfiles from ruby gems Message-ID: <9F110DE7-8DF6-4159-B584-4E62ABD96767@kallisys.net> Hi all, I wrote a script that generates a ready to use Portfile for any gem. You can find it here: http://www.opendarwin.org/~pguyot/gems_to_portfile.rb The syntax is pretty simple: ./gems_to_portfile.rb gem_file.gem or ./gems_to_portfile.rb gem_name In both cases, it creates a new directory, rb-gem_name, with the Portfile in it. Please note that this portfile uses the new rubyforge_gem fetch syntax (available with the ruby group modification I just committed to the svn repository). The second version will download the gem in the current directory. I need the file to be able to compute the checksums. Besides, if several gems exist and some of them are binaries, it will ask you to choose a version (using the native gem mechanism). This script requires gems (sudo port install rb-rubygems). With such a script, there's no reason to continue to use gem to install ruby gems. Using gem may yield in inconsistencies. I know that most ruby tutorial around say: get ruby with darwinports, then use gem. But I strongly disagree. At some point, we may rename gem binary and put a fake one that displays a warning message. Enjoy! Paul -- Ministre ultrapl?nipotentiaire en disponibilit?. Mobile. Sans baignoire fixe. http://www.kallisys.com/ http://www-poleia.lip6.fr/~guyot/ From mark.m.fredrickson at gmail.com Mon Nov 6 06:55:37 2006 From: mark.m.fredrickson at gmail.com (Mark Fredrickson) Date: Tue Oct 9 16:39:51 2007 Subject: Easily build Portfiles from ruby gems In-Reply-To: <9F110DE7-8DF6-4159-B584-4E62ABD96767@kallisys.net> References: <9F110DE7-8DF6-4159-B584-4E62ABD96767@kallisys.net> Message-ID: <3db8a8970611060655t639c0504m1e78ed8a3b91f4a4@mail.gmail.com> Salut Paul, Would you mind explaining this a little more? It is not clear to me why (as a developer just starting to use Ruby) I would want to get my libraries from MacPorts instead directly from rubyforge or another gem server. In a similar vein, should MacPorts replace CPAN (Perl) or PEAR (PHP)? I'm replying on-list, as I suspect others have the same question. But feel free to respond privately if this falls outside the scope of the macports list. Merci, -Mark On 11/6/06, Paul Guyot wrote: > Hi all, > > I wrote a script that generates a ready to use Portfile for any gem. > You can find it here: > http://www.opendarwin.org/~pguyot/gems_to_portfile.rb > > The syntax is pretty simple: > > ./gems_to_portfile.rb gem_file.gem > > or > > ./gems_to_portfile.rb gem_name > > In both cases, it creates a new directory, rb-gem_name, with the > Portfile in it. Please note that this portfile uses the new > rubyforge_gem fetch syntax (available with the ruby group > modification I just committed to the svn repository). The second > version will download the gem in the current directory. I need the > file to be able to compute the checksums. Besides, if several gems > exist and some of them are binaries, it will ask you to choose a > version (using the native gem mechanism). > > This script requires gems (sudo port install rb-rubygems). > > With such a script, there's no reason to continue to use gem to > install ruby gems. Using gem may yield in inconsistencies. I know > that most ruby tutorial around say: get ruby with darwinports, then > use gem. But I strongly disagree. At some point, we may rename gem > binary and put a fake one that displays a warning message. > > Enjoy! > > Paul > -- > Ministre ultrapl?nipotentiaire en disponibilit?. > Mobile. Sans baignoire fixe. > http://www.kallisys.com/ > http://www-poleia.lip6.fr/~guyot/ > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev > From dluke at geeklair.net Mon Nov 6 07:23:01 2006 From: dluke at geeklair.net (Daniel J. Luke) Date: Tue Oct 9 16:39:51 2007 Subject: Easily build Portfiles from ruby gems In-Reply-To: <3db8a8970611060655t639c0504m1e78ed8a3b91f4a4@mail.gmail.com> References: <9F110DE7-8DF6-4159-B584-4E62ABD96767@kallisys.net> <3db8a8970611060655t639c0504m1e78ed8a3b91f4a4@mail.gmail.com> Message-ID: <2344A429-D001-42D9-8788-1D56993701DA@geeklair.net> On Nov 6, 2006, at 9:55 AM, Mark Fredrickson wrote: > Would you mind explaining this a little more? It is not clear to me > why (as a developer just starting to use Ruby) I would want to get my > libraries from MacPorts instead directly from rubyforge or another gem > server. In a similar vein, should MacPorts replace CPAN (Perl) or PEAR > (PHP)? It gives you one system for controlling (and updating) added software on your machine. It also helps keep everything in ${prefix} (/opt/local) under MacPorts control. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20061106/185f3358/PGP.bin From jberry at macports.org Mon Nov 6 08:00:20 2006 From: jberry at macports.org (James Berry) Date: Tue Oct 9 16:39:51 2007 Subject: Easily build Portfiles from ruby gems In-Reply-To: <9F110DE7-8DF6-4159-B584-4E62ABD96767@kallisys.net> References: <9F110DE7-8DF6-4159-B584-4E62ABD96767@kallisys.net> Message-ID: <7C699BF6-63BF-49A9-9BD0-062018D805E6@macports.org> Hey Paul, On Nov 6, 2006, at 6:40 AM, Paul Guyot wrote: > In both cases, it creates a new directory, rb-gem_name, with the > Portfile in it. Please note that this portfile uses the new > rubyforge_gem fetch syntax (available with the ruby group > modification I just committed to the svn repository). The second > version will download the gem in the current directory. I need the > file to be able to compute the checksums. Besides, if several gems > exist and some of them are binaries, it will ask you to choose a > version (using the native gem mechanism). Looks great! I think this is a good step forward. The gem issues were getting a bit weird. This will help MacPorts really shine as a source for ruby software. > This script requires gems (sudo port install rb-rubygems). > > With such a script, there's no reason to continue to use gem to > install ruby gems. Using gem may yield in inconsistencies. I know > that most ruby tutorial around say: get ruby with darwinports, then > use gem. But I strongly disagree. At some point, we may rename gem > binary and put a fake one that displays a warning message. Question: does it make sense to now make the gem software installed by MacPorts actually install gems into the "usual" location rather that in /opt/local? That would mean that MacPorts can source gem, but gem installs gems in a typical fashion, not intermingling them into / opt/local, which I think would complete the separation. Thanks for your work on this! James From johnl at johnlabovitz.com Mon Nov 6 08:39:24 2006 From: johnl at johnlabovitz.com (John Labovitz) Date: Tue Oct 9 16:39:51 2007 Subject: Easily build Portfiles from ruby gems In-Reply-To: <9F110DE7-8DF6-4159-B584-4E62ABD96767@kallisys.net> References: <9F110DE7-8DF6-4159-B584-4E62ABD96767@kallisys.net> Message-ID: On Nov 6, 2006, at 6:40am, Paul Guyot wrote: > With such a script, there's no reason to continue to use gem to > install ruby gems. Using gem may yield in inconsistencies. I know > that most ruby tutorial around say: get ruby with darwinports, then > use gem. But I strongly disagree. At some point, we may rename gem > binary and put a fake one that displays a warning message. Please don't. I've been using native Ruby gems for at least two years with MacPorts, and have had absolutely no trouble. I don't have any problem with *providing* gem ports, especially for major/complex systems like ImageMagick and Rails. I use a select few rb-* gems, for their ease of installation (eg, rb-imagemagick). The combination of native and ported gems has never caused me grief; on the contrary, it's been a very pleasant experience. (Yes, I realize there could be dependency issues with a gem that required something installed as a port.) Besides, there are currently over a thousand gems; only ~130 of those currently have ports. Do you really suggest that we make ports for every single one? And keep them up to date? Perhaps if there are specific issues or conflicts, we could talk about those and try to find a solution or a workaround. (For example, I wonder whether a gem port could somehow be a wrapper around the gem command; that way the user would continue to use the ports system, but actually be installing native gems that were kept track of.) In the meantime, I'll be standing up for voice of the common gem. ;) --John From pguyot at kallisys.net Mon Nov 6 13:26:35 2006 From: pguyot at kallisys.net (Paul Guyot) Date: Tue Oct 9 16:39:51 2007 Subject: Easily build Portfiles from ruby gems In-Reply-To: References: <9F110DE7-8DF6-4159-B584-4E62ABD96767@kallisys.net> Message-ID: <488A59DD-2894-4E0E-A658-4AC0E99315A9@kallisys.net> Le 7 nov. 06 ? 01:39, John Labovitz a ?crit : > On Nov 6, 2006, at 6:40am, Paul Guyot wrote: > >> With such a script, there's no reason to continue to use gem to >> install ruby gems. Using gem may yield in inconsistencies. I know >> that most ruby tutorial around say: get ruby with darwinports, >> then use gem. But I strongly disagree. At some point, we may >> rename gem binary and put a fake one that displays a warning message. > > Please don't. > > I've been using native Ruby gems for at least two years with > MacPorts, and have had absolutely no trouble. > > I don't have any problem with *providing* gem ports, especially for > major/complex systems like ImageMagick and Rails. I use a select > few rb-* gems, for their ease of installation (eg, rb- > imagemagick). The combination of native and ported gems has never > caused me grief; on the contrary, it's been a very pleasant > experience. (Yes, I realize there could be dependency issues with > a gem that required something installed as a port.) > > Besides, there are currently over a thousand gems; only ~130 of > those currently have ports. Do you really suggest that we make > ports for every single one? And keep them up to date? > > Perhaps if there are specific issues or conflicts, we could talk > about those and try to find a solution or a workaround. (For > example, I wonder whether a gem port could somehow be a wrapper > around the gem command; that way the user would continue to use the > ports system, but actually be installing native gems that were kept > track of.) This is exactly what happens for a while now. That's true that only 12 ports use this technology, but it's there and it works (including for rails). If you look at rb-actionmailer, the ruby.setup line says: ruby.setup actionmailer 1.2.3 gem {} rubyforge:11331 It means: use the gem mechanism, get it from rubyforge, the ID is 11331. However, the trouble with this was to get the ID. I realized that gem itself doesn't know about it but download from another URL. So the new code (available only in svn now, forthcoming in 1.3.3) works like this: ruby.setup mongrel 0.3.13.4 gem {} rubyforge_gem I know that using gem and port at the same time is almost without any trouble. Gem is a good piece of code and it's behaving. The only issue is that gem is installing stuff in /opt/local and MacPorts doesn't know about it. So from there, I think there are the following paths: - port the one thousand or something gems to MacPorts using the script I wrote. It's just a matter of converting and testing. - patch gem so it registers the files into MacPorts system. - something between the two. It is what FreeBSD does with CPAN as far as I know. CPAN can install stuff and what is installed is registered in FreeBSD database. Until then, it might be worth it when enough gems are made available through MacPorts to just rename gem command so it's still available and implement a fake warning one to convince ruby users to use the MacPort version or provides tickets so we update to the latest when there's a problem. Paul -- Ministre ultrapl?nipotentiaire en disponibilit?. Mobile. Sans baignoire fixe. http://www.kallisys.com/ http://www-poleia.lip6.fr/~guyot/ From pguyot at kallisys.net Mon Nov 6 13:57:31 2006 From: pguyot at kallisys.net (Paul Guyot) Date: Tue Oct 9 16:39:51 2007 Subject: Easily build Portfiles from ruby gems In-Reply-To: <7C699BF6-63BF-49A9-9BD0-062018D805E6@macports.org> References: <9F110DE7-8DF6-4159-B584-4E62ABD96767@kallisys.net> <7C699BF6-63BF-49A9-9BD0-062018D805E6@macports.org> Message-ID: Le 7 nov. 06 ? 01:00, James Berry a ?crit : > Hey Paul, > > On Nov 6, 2006, at 6:40 AM, Paul Guyot wrote: > >> In both cases, it creates a new directory, rb-gem_name, with the >> Portfile in it. Please note that this portfile uses the new >> rubyforge_gem fetch syntax (available with the ruby group >> modification I just committed to the svn repository). The second >> version will download the gem in the current directory. I need the >> file to be able to compute the checksums. Besides, if several gems >> exist and some of them are binaries, it will ask you to choose a >> version (using the native gem mechanism). > > Looks great! I think this is a good step forward. The gem issues > were getting a bit weird. This will help MacPorts really shine as a > source for ruby software. > >> This script requires gems (sudo port install rb-rubygems). >> >> With such a script, there's no reason to continue to use gem to >> install ruby gems. Using gem may yield in inconsistencies. I know >> that most ruby tutorial around say: get ruby with darwinports, >> then use gem. But I strongly disagree. At some point, we may >> rename gem binary and put a fake one that displays a warning message. > > Question: does it make sense to now make the gem software installed > by MacPorts actually install gems into the "usual" location rather > that in /opt/local? That would mean that MacPorts can source gem, > but gem installs gems in a typical fashion, not intermingling them > into /opt/local, which I think would complete the separation. I'm not sure I understand what you mean by the "usual" location. /opt/local/bin/gem installs stuff in /opt/local /opt/local/bin/port also does, when it uses gem and when it doesn't. Technically, the only difference when using a port based on the new script and gem is that with a port: - you can deactivate the port. - the files are registered in MacPorts database (filemap). Otherwise, the files are at the same place. Paul -- Ministre ultrapl?nipotentiaire en disponibilit?. Mobile. Sans baignoire fixe. http://www.kallisys.com/ http://www-poleia.lip6.fr/~guyot/ From jeanpierre at gmail.com Mon Nov 6 15:15:32 2006 From: jeanpierre at gmail.com (jeanpierre@gmail.com) Date: Tue Oct 9 16:39:51 2007 Subject: Easily build Portfiles from ruby gems In-Reply-To: <9F110DE7-8DF6-4159-B584-4E62ABD96767@kallisys.net> References: <9F110DE7-8DF6-4159-B584-4E62ABD96767@kallisys.net> Message-ID: On 11/6/06, Paul Guyot wrote: > With such a script, there's no reason to continue to use gem to > install ruby gems. rubygems allows multiple version of a single package to be installed simultaneously and allows one to define a required package version: require_gem 'hpricot', '>= 0.4.59' 'no reason' might be a bit strong =) > Using gem may yield in inconsistencies. what inconsistencies may arise? > I know that most ruby tutorial around say: get ruby with > darwinports, then use gem. But I strongly disagree. you have said this before, but i never caught why? > At some point, we may rename gem binary and put a fake one that > displays a warning message. is that really desirable? what problem is your script working to solve? it has been suggested that the omniscience of macports would be compromised when rubygems (or pear, cpan, or how about touch, cp, mv), is that it? why couldn't macports become more tolerant and able to handle foreign files? if my macports prefix was /usr/local would it be reasonable for macports to break just because i installed something by hand into the same prefix? i think my mirror world, constant lagging and unnecessarily fragile comments from august may still apply: http://article.gmane.org/gmane.os.opendarwin.darwinports/18853 i think it is great that there is a way to convert gems to ports and have them available to the macports audience, but i do not understand the motivation to discourage the use of and try and replicate some of the functionality of rubygems. cheers, jean-pierre From pguyot at kallisys.net Mon Nov 6 15:31:00 2006 From: pguyot at kallisys.net (Paul Guyot) Date: Tue Oct 9 16:39:51 2007 Subject: Easily build Portfiles from ruby gems In-Reply-To: References: <9F110DE7-8DF6-4159-B584-4E62ABD96767@kallisys.net> Message-ID: Jean-Pierre, MacPorts is based on several axioms. One of them is that it's based on a tree of its own, by default /opt/local, and it's here to managed everything in this tree. If you install MacPorts on /usr/local and then install stuff the regular way or if you install gems with rubygems, then you're violating this axiom. This means several things, among others: - your tree is in an unsupported state. Don't come and whine if ports don't compile. - you cannot take advantage of MacPorts to uninstall software. I know you can do it with gems, but it's not the case with stuff usually installed in /usr/local. - you cannot take advantage of commands such as port provides or port livecheck. Another (more recent) axiom is that MacPorts should depend as much as possible on MacPorts stuff only. So say you want a software that is not available via rubygems but that depends on a ruby package also available through rubygems. If you installed the dependency with rubygems and then you try to install the software with MacPorts, you're likely to end up with two copies of the dependency on your system, the one from RubyGems and the one for MacPorts. Even worse, if the MacPorts copy is gem based, it will simply fail to install. You've been warned. Yes, MacPorts should handle foreign files, but definitely not the crap you might install there with "make install". I think the way to go is an integration ? la FreeBSD with CPAN. Yes, MacPorts and rubygems should be better integrated and the script is explicitly done for this purpose, even if it's just a first step (well, a third step, rather). I realize installing with rubygems has some advantages over MacPorts. But installing with MacPorts also has some advantages that long-term MacPorts users are aware of. For example, if a gem requires a native library, will rubygems install it? Does rubygems provides some checksumming facility? Mirroring? So I think the good policy is: - install anything you can with Macports - if it's not available, use rubygems - once 1.3.3 is out and if you're a MacPorts developer, instead of using rubygems, please build a portfile for what you want, test it and commit it. This is just what I *suggest*. Fortunately, I don't administrate all the boxes of MacPorts users. Paul Le 7 nov. 06 ? 08:15, jeanpierre@gmail.com a ?crit : > On 11/6/06, Paul Guyot wrote: > >> With such a script, there's no reason to continue to use gem to >> install ruby gems. > > rubygems allows multiple version of a single package to be installed > simultaneously and allows one to define a required package version: > require_gem 'hpricot', '>= 0.4.59' > > 'no reason' might be a bit strong =) > >> Using gem may yield in inconsistencies. > > what inconsistencies may arise? > >> I know that most ruby tutorial around say: get ruby with >> darwinports, then use gem. But I strongly disagree. > > you have said this before, but i never caught why? > >> At some point, we may rename gem binary and put a fake one that >> displays a warning message. > > is that really desirable? > > what problem is your script working to solve? it has been suggested > that the omniscience of macports would be compromised when rubygems > (or pear, cpan, or how about touch, cp, mv), is that it? why couldn't > macports become more tolerant and able to handle foreign files? if my > macports prefix was /usr/local would it be reasonable for macports to > break just because i installed something by hand into the same prefix? > > i think my mirror world, constant lagging and unnecessarily fragile > comments from august may still apply: > http://article.gmane.org/gmane.os.opendarwin.darwinports/18853 > > i think it is great that there is a way to convert gems to ports and > have them available to the macports audience, but i do not understand > the motivation to discourage the use of and try and replicate some of > the functionality of rubygems. > > cheers, > jean-pierre -- Ministre ultrapl?nipotentiaire en disponibilit?. Mobile. Sans baignoire fixe. http://www.kallisys.com/ http://www-poleia.lip6.fr/~guyot/ From pmq at macports.org Tue Nov 7 01:48:20 2006 From: pmq at macports.org (Pierre Queinnec) Date: Tue Oct 9 16:39:51 2007 Subject: Building in chroot [Was: Re: Latest ruby 1.8.5_1] In-Reply-To: <8527E2BA-89F1-4048-932F-6CA8C36BA999@kallisys.net> References: <8527E2BA-89F1-4048-932F-6CA8C36BA999@kallisys.net> Message-ID: <45505664.2050701@macports.org> [Cc'ing mp-dev, removing mp-users] Hi Paul, Jordan, Paul Guyot wrote: > Le 7 nov. 06 ? 07:42, Jordan K. Hubbard a ?crit : >> On Nov 6, 2006, at 2:02 PM, Paul Guyot wrote: >>> I don't know how to turn it into a variant in such a way that without >>> this variant, ruby doesn't touch tk & tcl if they're available. >> >> Well, maybe if the trace code returned ENOENT on any attempt to >> satisfy non-explicit dependencies, you could use it to create a >> virtual chroot and then turn that virtual chroot mode on by default. >> Oh wait, we already went over all that in the message you cited. :-) :-) > > Heh. You love to be right, don't you? > > I gave more thought to the way MacPorts work recently and I believe > trace mode needs to be on by default. Then the problem is that it > generates warnings where we want errors to make sure that portfiles are > correct. In such a case, we want the minimum dependency set. For > example, many ports will use MP install or autoconf where the system one > would be perfectly fine. So yes, I changed my mind and I think we should > have a chroot-like environment like you suggested -- it has some holes > as ports could disable the dyld injection, but I guess it's fine for > what we're doing, it's not a security concern, and it's much cheaper > than a real chroot with union mounts, and it provides informations about > forbidden accesses. I know you probably looked at it before, but here's a description of buildlink, which is PKGSRC's way of doing this: http://www.netbsd.org/Documentation/pkgsrc/buildlink.html Basically it is a way of implementing a portable chroot. It *has* some drawbacks too, and besides we don't need that much portability since we changed name, so we might prefer the real chroot way. > The problem is I don't have enough time to implement all this now. I > toyed with ruby ports because of a work project of mine that is based on > ruby. I'll try to do the 1.3.3 release as asked by James, but I think > this will be all for 2006. > > Paul > --Ministre ultrapl?nipotentiaire en disponibilit?. > Mobile. Sans baignoire fixe. > http://www.kallisys.com/ > http://www-poleia.lip6.fr/~guyot/ -- Pierre From blair at orcaware.com Wed Nov 8 17:14:57 2006 From: blair at orcaware.com (Blair Zajac) Date: Tue Oct 9 16:39:51 2007 Subject: MD5 hash of fpconst-0.7.2.tar.gz Message-ID: <45528111.1080907@orcaware.com> Hi Greg, Sorry to hear that your site went down. Mine when down this week and it's a pain. I work on the MacPorts team and we have a package for your fpconst 0.7.2. The MD5 hash of the new tarball at http://mac.warnes.net/~warnes/files/fpconst-0.7.2.tar.gz is different than the original. I have the original hash as 0c194744ab60f3301dfda2da9f7c4068 and a copy of the file with that hash can be found at http://distro.ibiblio.org/pub/linux/distributions/gentoo/distfiles/fpconst-0.7.2.tar.gz I don't know if you want to replace the new tarball with this one and do a diff between the two, which only shows minor changes in comments, but it would make packagers life easier :) We get a little anal at times and when we see a MD5 mismatch, then we're concerned about something happening to the code. Regards, Blair -- Blair Zajac, Ph.D. http://www.orcaware.com/svn/ From mas at seligma.com Wed Nov 15 09:26:29 2006 From: mas at seligma.com (=?ISO-8859-1?Q?Marc_Andr=E9_Selig?=) Date: Tue Oct 9 16:39:51 2007 Subject: Temporary slib *downgrade* acceptable? Message-ID: <64717D7F-7104-41A2-B359-FC71B45B9F28@seligma.com> Dear all, the recent slib upgrade to 3a4 gives us (well, me) more headaches than I would wish for. GnuCash does not work with versions 3a2 and 3a4 of slib, only 3a3. The last few days, all of the time I can spend for MacPorts was busy instructing people how to manually downgrade slib to 3a3. I have tried to provide a package "slib- stable" with 3a3, but this would have to filter through too many ports to make it actually desirable. From a cursory grep at the dports directory, it appears (I may be mistaken!) that the only ports that actually use slib are GnuCash and lang/gauche. Also, that the major reason slib was upgraded for MacPorts seems to have been that the sources for 3a3 had moved and the people fixing this thought the upgrade to the latest alpha release was the simplest solution. Are my premises correct? Would it thus be acceptable for me to actually revert the slib portfile to version 3a3 (including a fix for the source location)? For a limited period of time? It would certainly make life easier for anybody wanting to use GnuCash on OS X. (fink is no alternative, since it does not yet provide GnuCash 2.0.) Regards, Marc -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2413 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20061115/0d1cc22a/smime.bin From mark.duling at biola.edu Mon Nov 27 22:07:46 2006 From: mark.duling at biola.edu (Mark Duling) Date: Tue Oct 9 16:39:51 2007 Subject: Imagemagick - change x11 variant to nox11? Message-ID: Wouldn't it make more sense for IamgeMagick to have X11 support by default and provide a nox11 for turning it off as suggested in this ticket? http://trac.macosforge.org/projects/macports/ticket/10624 Mark From blair at orcaware.com Mon Nov 27 22:16:40 2006 From: blair at orcaware.com (Blair Zajac) Date: Tue Oct 9 16:39:51 2007 Subject: Imagemagick - change x11 variant to nox11? In-Reply-To: References: Message-ID: <01EC1A62-E869-4C71-A712-F1C9CC853527@orcaware.com> On Nov 27, 2006, at 10:07 PM, Mark Duling wrote: > Wouldn't it make more sense for IamgeMagick to have X11 support by > default > and provide a nox11 for turning it off as suggested in this ticket? > > http://trac.macosforge.org/projects/macports/ticket/10624 +1. Blair From luc at honk-honk.com Tue Nov 28 04:55:39 2006 From: luc at honk-honk.com (Luc Heinrich) Date: Tue Oct 9 16:39:51 2007 Subject: Patch file for ticket #11006 Message-ID: <94F8108F-2C95-4BF2-A5AF-16E461BFD876@honk-honk.com> Greetings, As already discussed in the MacPorts-Users list and as described in ticket #11006, the ruby Portfile has unnecessary dependencies: having the whole Tcl/Tk/X11 bloatware as default requirements is slightly over the top, imho :) I have attached a patch for the Portfile to the ticket, which move the 'tcl' and 'tk' ports dependencies to a 'tk' variant and disable the ruby 'tk' extension by default and enable it in the 'tk' variant. -- Luc Heinrich - luc@honk-honk.com - http://www.honk-honk.com From yeled at macports.org Thu Nov 30 05:48:22 2006 From: yeled at macports.org (Charlie Allom) Date: Tue Oct 9 16:39:51 2007 Subject: [20806] trunk/dports/net/wireshark In-Reply-To: <20061129195704.4D49937D00D@cvs.opensource.apple.com> References: <20061129195704.4D49937D00D@cvs.opensource.apple.com> Message-ID: <07357D21-EF11-4E96-8145-4BF3B8A332EF@macports.org> either this or the .94 bump broke my wireshark configure. configure:21540: result: no configure:21573: gcc -o conftest -no-cpp-precomp -D_U_="__attribute__ ((unused))" -Wall -Wpointer-arith -W -g -O2 -I/opt/local/include/ glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include - Wl,-search_paths_first conftest.c -L/opt/local/lib -lgmodule-2.0 - lglib-2.0 -lintl -liconv >&5 /usr/bin/ld: warning can't open dynamic library: /opt/local/lib/ libintl.3.dylib referenced from: /opt/local/lib/libgmodule-2.0.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) configure:21579: $? = 0 configure:21582: test -z || test ! -s conftest.err configure:21585: $? = 0 configure:21588: test -s conftest configure:21591: $? = 0 configure:21620: error: GLib2 distribution not found. On 29/11/2006, at 7:57 PM, source_changes@macosforge.org wrote: > Revision: 20806 > http://trac.macosforge.org/projects/macports/changeset/20806 > Author: ricci@macports.org > Date: 2006-11-29 11:57:03 -0800 (Wed, 29 Nov 2006) > > Log Message: > ----------- > patch configure so it can find net-snmp. patch sent upstream and > has been incorporated already > > Modified Paths: > -------------- > trunk/dports/net/wireshark/Portfile > > Added Paths: > ----------- > trunk/dports/net/wireshark/files/ > trunk/dports/net/wireshark/files/patch-configure > > Modified: trunk/dports/net/wireshark/Portfile > =================================================================== > --- trunk/dports/net/wireshark/Portfile 2006-11-29 19:41:16 UTC > (rev 20805) > +++ trunk/dports/net/wireshark/Portfile 2006-11-29 19:57:03 UTC > (rev 20806) > @@ -3,7 +3,7 @@ > PortSystem 1.0 > name wireshark > version 0.99.4 > -revision 0 > +revision 1 > categories net > maintainers opendarwin.org@darkart.com > description Graphical network analyzer and capture tool > @@ -21,6 +21,7 @@ > sha1 696216d794b418da3cb0a1829281ef65bf3e64ff \ > rmd160 6bf940af951ddfcf66157a8cb299e6342dd3f955 > > +patchfiles patch-configure > > use_bzip2 yes > > > Added: trunk/dports/net/wireshark/files/patch-configure > =================================================================== > --- trunk/dports/net/wireshark/files/patch- > configure (rev 0) > +++ trunk/dports/net/wireshark/files/patch-configure 2006-11-29 > 19:57:03 UTC (rev 20806) > @@ -0,0 +1,11 @@ > +--- configure.orig 2006-11-25 22:38:30.000000000 -0800 > ++++ configure 2006-11-25 22:40:08.000000000 -0800 > +@@ -28319,7 +28319,7 @@ > + fi > + > + else > +- NETSNMPCNFIG=$netsnmpconfig > ++ NETSNMPCONFIG=$netsnmpconfig > + if test ! -x $NETSNMPCONFIG -o ! -f $NETSNMPCONFIG ; then > + NETSNMPCONFIG=$netsnmpconfig/bin/net-snmp-config > + if test ! -x $NETSNMPCONFIG -o ! -f $NETSNMPCONFIG ; then > > _______________________________________________ > macports-changes mailing list > macports-changes@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-changes From pmq at macports.org Thu Nov 30 06:01:13 2006 From: pmq at macports.org (Pierre Queinnec) Date: Tue Oct 9 16:39:51 2007 Subject: [20806] trunk/dports/net/wireshark In-Reply-To: <07357D21-EF11-4E96-8145-4BF3B8A332EF@macports.org> References: <20061129195704.4D49937D00D@cvs.opensource.apple.com> <07357D21-EF11-4E96-8145-4BF3B8A332EF@macports.org> Message-ID: <456EE429.6020501@macports.org> Hi yeled, this is the gettext upgrade "bug". See http://trac.macosforge.org/projects/macports/wiki/ProblemHotlist. -- Pierre Charlie Allom wrote: > either this or the .94 bump broke my wireshark configure. > > configure:21540: result: no > configure:21573: gcc -o conftest -no-cpp-precomp > -D_U_="__attribute__((unused))" -Wall -Wpointer-arith -W -g -O2 > -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include > -I/opt/local/include -Wl,-search_paths_first conftest.c > -L/opt/local/lib -lgmodule-2.0 -lglib-2.0 -lintl -liconv >&5 > /usr/bin/ld: warning can't open dynamic library: > /opt/local/lib/libintl.3.dylib referenced from: > /opt/local/lib/libgmodule-2.0.dylib (checking for undefined symbols may > be affected) (No such file or directory, errno = 2) > configure:21579: $? = 0 > configure:21582: test -z || test ! -s conftest.err > configure:21585: $? = 0 > configure:21588: test -s conftest > configure:21591: $? = 0 > configure:21620: error: GLib2 distribution not found. > > > On 29/11/2006, at 7:57 PM, source_changes@macosforge.org wrote: > >> Revision: 20806 >> http://trac.macosforge.org/projects/macports/changeset/20806 >> Author: ricci@macports.org >> Date: 2006-11-29 11:57:03 -0800 (Wed, 29 Nov 2006) >> >> Log Message: >> ----------- >> patch configure so it can find net-snmp. patch sent upstream and has >> been incorporated already >> >> Modified Paths: >> -------------- >> trunk/dports/net/wireshark/Portfile >> >> Added Paths: >> ----------- >> trunk/dports/net/wireshark/files/ >> trunk/dports/net/wireshark/files/patch-configure >> >> Modified: trunk/dports/net/wireshark/Portfile >> =================================================================== >> --- trunk/dports/net/wireshark/Portfile 2006-11-29 19:41:16 UTC >> (rev 20805) >> +++ trunk/dports/net/wireshark/Portfile 2006-11-29 19:57:03 UTC >> (rev 20806) >> @@ -3,7 +3,7 @@ >> PortSystem 1.0 >> name wireshark >> version 0.99.4 >> -revision 0 >> +revision 1 >> categories net >> maintainers opendarwin.org@darkart.com >> description Graphical network analyzer and capture tool >> @@ -21,6 +21,7 @@ >> sha1 696216d794b418da3cb0a1829281ef65bf3e64ff \ >> rmd160 6bf940af951ddfcf66157a8cb299e6342dd3f955 >> >> +patchfiles patch-configure >> >> use_bzip2 yes >> >> >> Added: trunk/dports/net/wireshark/files/patch-configure >> =================================================================== >> --- >> trunk/dports/net/wireshark/files/patch-configure >> (rev 0) >> +++ trunk/dports/net/wireshark/files/patch-configure 2006-11-29 >> 19:57:03 UTC (rev 20806) >> @@ -0,0 +1,11 @@ >> +--- configure.orig 2006-11-25 22:38:30.000000000 -0800 >> ++++ configure 2006-11-25 22:40:08.000000000 -0800 >> +@@ -28319,7 +28319,7 @@ >> + fi >> + >> + else >> +- NETSNMPCNFIG=$netsnmpconfig >> ++ NETSNMPCONFIG=$netsnmpconfig >> + if test ! -x $NETSNMPCONFIG -o ! -f $NETSNMPCONFIG ; then >> + NETSNMPCONFIG=$netsnmpconfig/bin/net-snmp-config >> + if test ! -x $NETSNMPCONFIG -o ! -f $NETSNMPCONFIG ; then >> >> _______________________________________________ >> macports-changes mailing list >> macports-changes@lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo/macports-changes > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev From yeled at macports.org Thu Nov 30 06:04:07 2006 From: yeled at macports.org (Charlie Allom) Date: Tue Oct 9 16:39:51 2007 Subject: [20806] trunk/dports/net/wireshark In-Reply-To: <456EE429.6020501@macports.org> References: <20061129195704.4D49937D00D@cvs.opensource.apple.com> <07357D21-EF11-4E96-8145-4BF3B8A332EF@macports.org> <456EE429.6020501@macports.org> Message-ID: On 30/11/2006, at 2:01 PM, Pierre Queinnec wrote: > Hi yeled, > > this is the gettext upgrade "bug". See http://trac.macosforge.org/ > projects/macports/wiki/ProblemHotlist. bah - bitten and didnt know it! thanks Pierre. C. -- hail eris http://rubberduck.com/ From opendarwin.org at darkart.com Thu Nov 30 12:25:06 2006 From: opendarwin.org at darkart.com (Eric Hall) Date: Tue Oct 9 16:39:51 2007 Subject: [20806] trunk/dports/net/wireshark In-Reply-To: <98A93015-3828-4E1F-B138-796B89758FDD@rubberduck.com> References: <20061129195704.4D49937D00D@cvs.opensource.apple.com> <98A93015-3828-4E1F-B138-796B89758FDD@rubberduck.com> Message-ID: <20061130202506.GG23299@darkart.com> On Thu, Nov 30, 2006 at 01:42:47PM +0000, Charlie Allom wrote: > either this or the .94 bump broke my wireshark configure. > > configure:21540: result: no > configure:21573: gcc -o conftest -no-cpp-precomp -D_U_="__attribute__ > ((unused))" -Wall -Wpointer-arith -W -g -O2 -I/opt/local/include/ > glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include - > Wl,-search_paths_first conftest.c -L/opt/local/lib -lgmodule-2.0 - > lglib-2.0 -lintl -liconv >&5 > /usr/bin/ld: warning can't open dynamic library: /opt/local/lib/ > libintl.3.dylib referenced from: /opt/local/lib/libgmodule-2.0.dylib > (checking for undefined symbols may be affected) (No such file or > directory, errno = 2) > configure:21579: $? = 0 > configure:21582: test -z || test ! -s conftest.err > configure:21585: $? = 0 > configure:21588: test -s conftest > configure:21591: $? = 0 > configure:21620: error: GLib2 distribution not found. > Arrrrr! Ye be bitten by the gettext update bug me thinks! Refer ye self to #2 on: http://trac.macosforge.org/projects/macports/wiki/ProblemHotlist -eric From jenix at jinhyung.org Thu Nov 30 18:48:51 2006 From: jenix at jinhyung.org (Jin Hyung Park) Date: Tue Oct 9 16:39:51 2007 Subject: How to fire a new ticket? and there is a checksum error in Python25. Message-ID: Hello. I'm Park, Jin Hyung. My system is Powerbook G4 1.5Ghz with Tiger 10.4.8 (Darwin Cocoa.local 8.8.0 Darwin Kernel Version 8.8.0: Fri Sep 8 17:18:57 PDT 2006; root:xnu-792.12.6.obj~1/RELEASE_PPC Power Macintosh powerpc) When I tried to install python25 in this morning, I got an error related with checksum --------------------------------------------------------------------------- ---> Python-2.5.tar.bz2 doesn't seem to exist in /opt/local/var/db/dports/distfiles/python25 ---> Attempting to fetch Python-2.5.tar.bz2 from http://www.python.org/ftp/python/2.5 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 9137k 100 9137k 0 0 99k 0 0:01:31 0:01:31 --:--:-- 88463 ---> Verifying checksum(s) for python25 DEBUG: Executing com.apple.checksum (python25) ---> Checksumming Python-2.5.tar.bz2 Error: Checksum (sha1) mismatch for Python-2.5.tar.bz2 Portfile checksum: Python-2.5.tar.bz2 sha1 98ce9346cc4a7ef4621ecdcfc3957d595d97a078 Distfile checksum: Python-2.5.tar.bz2 sha1 fa24649cfd5db305f16d79aba8776c332d76a672 Error: Checksum (rmd160) mismatch for Python-2.5.tar.bz2 Portfile checksum: Python-2.5.tar.bz2 rmd160 f6977a6c3d3ca54c27ad9270918237a7e6521d0b Distfile checksum: Python-2.5.tar.bz2 rmd160 67c42f1d8cfe61b8f2f5812014a9739ff21af734 Error: Target com.apple.checksum returned: Unable to verify file checksums Warning: the following items did not execute (for python25): com.apple.activate com.apple.extract com.apple.checksum com.apple.patch com.apple.configure com.apple.build com.apple.destroot com.apple.archive com.apple.install Error: Status 1 encountered during processing. Cocoa:/opt/local/var/db/dports/sources/rsync.rsync.darwinports.org_dpupdate_dports/lang/python25 jenix$ --------------------------------------------------------------------------- I had tried to fire a new bug ticket in MacPorts Trac, but I couldn't do that, So, I mail this problem to macports-dev. is it a right way to report a bug?