From afb at macports.org Tue Apr 1 01:03:31 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Apr 1 01:02:29 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <9B91E8F7-35AC-49BC-8633-14C2948777D4@gmail.com> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> <47F116FB.6080303@macports.org> <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> <9B91E8F7-35AC-49BC-8633-14C2948777D4@gmail.com> Message-ID: <01304AEA-CA49-44D1-8302-105EFABCAB1B@macports.org> Guido Soranzio wrote: > We have already the well-made free Porticus GUI and we have already > the new sqlite receipt database engine in Leopard's Apple > InstallerPackageMaker: we only need pkgutils to fully support > --unlink, reference counting and dependency analysis. [...] It doesn't bother you that both of those are proprietary ? (Never mind that flat pkg are Leopard-only and unfeatured) But current main problem with PKG is the same as with RPM, in that it doesn't share its registry with the source ports. And if those two (Porticus and Leopard PKG) are enough, why is MacPorts employing students to write new open solutions ? - "Task 4: Binaries" - "Task 5: Graphical user interface" I also think that binary packages and graphical interface are the two most important new features. But Open Source! Personally I also think they should be cross-platform, or at least have a fair chance of being portable (unlike these two) --anders From jkh at apple.com Tue Apr 1 01:08:49 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Tue Apr 1 01:09:17 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <9B91E8F7-35AC-49BC-8633-14C2948777D4@gmail.com> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> <47F116FB.6080303@macports.org> <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> <9B91E8F7-35AC-49BC-8633-14C2948777D4@gmail.com> Message-ID: On Mar 31, 2008, at 11:53 PM, Guido Soranzio wrote: > We don't have a central building machine, we don't have binary Yes, you do. You need to read my entire message again, making a more sincere attempt to understand it this time. Everything you're asking for comes from creating that infrastructure. Asking users to upload random packaged bits as a substitute for actually doing the right thing for the project is like putting a band-aid on a gunshot wound, and just as likely to end in a bad infection and death. - Jordan From florian.ebeling at gmail.com Tue Apr 1 01:27:43 2008 From: florian.ebeling at gmail.com (Florian Ebeling) Date: Tue Apr 1 01:26:42 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> <47F116FB.6080303@macports.org> <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> Message-ID: <5cbbe4ae0804010127ie90be62i74c67daf8a48fc8@mail.gmail.com> > There is no coherency in how the dependencies are expressed in MacPorts at > the moment: some ports lists all the dependencies recursively while other > ones limit to list only their direct dependencies, as garnome and jhbuild do > the right way. > > This is a mess. Maybe I'm too ignorant, but isn't also the fact that dependencies are version-agnostic one major cause of build fails and probably a cost-effective gain to change? I'm rather new to macports, but I was delighted to find that it can keep multiple versions installed, with only a single one active (usually) -- only to learn later then that it is otherwise not using this feature, really. So the only workaround is `port -R upgrade', which went into endless looping for mne more than once (I filed a bug [1]). And cleaning the big backlog of obsolete versions does not really work either, as I learned, unless the version is not depended on anywhere or you force it everywhere [2]. Feels like version-awareness might help here sometimes. Florian [1] http://trac.macports.org/projects/macports/ticket/14829 [2] http://www.nabble.com/port-uninstall%3A-dep-check-broken--to16316418.html#a16333096 -- Florian Ebeling florian.ebeling@gmail.com From exodusd at gmx.de Tue Apr 1 01:40:05 2008 From: exodusd at gmx.de (Robert Hinn) Date: Tue Apr 1 01:39:04 2008 Subject: variants / sub-packages In-Reply-To: References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> <47F116FB.6080303@macports.org> <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> <9B91E8F7-35AC-49BC-8633-14C2948777D4@gmail.com> Message-ID: <1088A77F-1B2F-4FBE-8016-8798A14BAE04@gmx.de> Hello, I was wondering: seeing some ports called *-devel in the list, does MacPorts offer a sub-package mechanism? I haven't found anything in the guide, so I considered using variants as a proper way to handle optional features in a software which I would otherwise build a sub- package for. Also, following the discussion about binary builds, I think it might get difficult if there are variants of a package that offer optional features which result in some destroot files only being built for certain variants. You'd have to specify which files belong to which variant in that case... Is there already a mechanism for that in the portfiles? I definitely like the idea of binary builds. Although I am a developer, I usually like to get required packages into my system as quickly and hasslefree as possible, so I can continue my work. And I think most users wouldn't want a build environment on their machine if they're not developers (the Mac OS X SDK is an optional install, too ;-) ). I also like sub-packages (variants?) very much, since they reduce the need for package dependencies which I don't really need on my machine... Is it okay to use variants for sub-package-like behavior (which I am currently doing in the pike port I updated), or should this done another way? Best regards, Robert From florian.ebeling at gmail.com Tue Apr 1 01:58:07 2008 From: florian.ebeling at gmail.com (Florian Ebeling) Date: Tue Apr 1 01:57:05 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <748BEF7B-0BC6-453D-B5CF-922B929A9F8F@macports.org> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <748BEF7B-0BC6-453D-B5CF-922B929A9F8F@macports.org> Message-ID: <5cbbe4ae0804010158rd21ed31v4b0d22668935c751@mail.gmail.com> > > There are two few committers for dports/ and REALLY very few committers > for base/ - I think we should be more liberal in allowing new committers, > being ever mindful of the fact that source control always means you can back > things out (and, as we grow, I think it's also important to be flexible > about that during/because of any dispute). > > > > We have tried over the last year to really loosen up the committer > requirements, solicit new committers, etc. We've called a number of times > for new submitter applications and basically take anybody who has shown any > sort of commitment or experience with MacPorts. So I'll say it once more: if > you're interested in being a macports committer, please just ask: > http://trac.macosforge.org/projects/macports/wiki/NewCommittersGuide. I would apply for this but I find the wording in the guide quite disheartening. "Prove track record" etc. For me macports is interesting, because I am a programmer, work with open source packages, and don't fancy to do a simply "make install" in the middle of nowhere and then are not able to get rid of the leftovers of my experiments. That's where a portfile comes quite handy. And when I'm at it and find I had to uprade an existing port in the process, then I'm happy to share these results with the community. When this then means I file a bug which is being ignored for 6 weeks then I don't do this again, I guess. Just add more committers, and also offer commit right where you see it fit. There is a bell curve of committers, and there are outstanding ones, the majority, and bad ones, and one could probably also revoke this right after a warning, if it doesn't work out. But people also start slowly and unimpressive, and you probably dont want to discourage them further. macports is a project which needs a lot of people who do a housekeeping, rather boring kind of job, maintaining the ports and keep them up to date. So there should probably not too much ceremony around this process of commit rights either. It's just not the kind of project which will solve world peace and offers fulfillment in your life, but it can be a very handy tool for users, if it achieves to leverage all the small effeorts of the many. Florian -- Florian Ebeling florian.ebeling@gmail.com From jkh at apple.com Tue Apr 1 02:02:57 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Tue Apr 1 02:03:24 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <5cbbe4ae0804010127ie90be62i74c67daf8a48fc8@mail.gmail.com> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> <47F116FB.6080303@macports.org> <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> <5cbbe4ae0804010127ie90be62i74c67daf8a48fc8@mail.gmail.com> Message-ID: <117C1FF8-51ED-436C-A3BF-2EC6CBB753F0@apple.com> On Apr 1, 2008, at 1:27 AM, Florian Ebeling wrote: > Maybe I'm too ignorant, but isn't also the fact that dependencies > are version-agnostic one major cause of build fails and probably a > cost-effective gain to change? Not ignorant at all, yes, this is a well-known shortcoming of dependencies. No way to specify minimum version, maximum version, range of versions, and so on. Package systems like RPM do, but lacking this in the base system means MacPorts can't make more intelligent dependency decisions and it can't pass those on to the packaging system, which will need to make the same decision if the user uses packages to install instead. I think "new dependency engine" has even been on the task list for for several years now. > I'm rather new to macports, but I was delighted to find that it can > keep multiple versions installed, with only a single one active > (usually) -- only to learn later then that it is otherwise not using > this feature, really. This is sadly somewhat controversial. I think dependencies should definitely be directed at the depot location, e.g. something that links with, say, jpeg version 6.2, shouldn't link to /usr/lib/libjpeg. 62.dylib but rather /opt/local/var/macports/software/jpeg/6b_2/opt/ local/lib/libjpeg.62.dylib, and so on and so forth for any absolute- path dependencies. Then whether something is "active" or not has nothing to do with whether it can be depended on. Every time the subject comes up, however, various people rapidly get the creeping crawlies and we lose the courage to actually attempt this. To be fair, and make no mistake, it's actually pretty hard to get this right. Smashing everything together in a common $prefix and assuming that all your deps are part of $prefix at any given time is a hugely simplifying assumption, too. For most ports, a simple -I${prefix}/ include and -L${prefix}/lib is all the stands between their vanilla state and working properly with MacPorts. In a true multiple-version world, each and every dependency potentially adds to the search paths. - Jordan From afb at macports.org Tue Apr 1 02:06:26 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Apr 1 02:06:45 2008 Subject: variants / sub-packages In-Reply-To: <1088A77F-1B2F-4FBE-8016-8798A14BAE04@gmx.de> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> <47F116FB.6080303@macports.org> <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> <9B91E8F7-35AC-49BC-8633-14C2948777D4@gmail.com> <1088A77F-1B2F-4FBE-8016-8798A14BAE04@gmx.de> Message-ID: Robert Hinn wrote: > Hello, > > I was wondering: seeing some ports called *-devel in the list, does > MacPorts offer a sub-package mechanism? Sadly, it doesn't. The "*-devel" ports are experimental/pre-release, like if "foo" is the stable release then "foo-devel" is the unstable version. This is like BSD Ports, but unlike RPM and DEB. > I haven't found anything in the guide, so I considered using > variants as a proper way to handle optional features in a software > which I would otherwise build a sub-package for. That's how it usually works. But there is only one package built, with all files. > Also, following the discussion about binary builds, I think it > might get difficult if there are variants of a package that offer > optional features which result in some destroot files only being > built for certain variants. You'd have to specify which files > belong to which variant in that case... Is there already a > mechanism for that in the portfiles? It is difficult, as each combination of variants will be a new package. Variants do not equal subpackages, like some other build systems have (for instance RPM has one separate file list for each subpackage, where as the variants are called "options" and given as rpmbuild arguments) For archives (tgz/tbz/tlz), the variants used are encoded in the file name. For packages (pkg/rpm/deb), all different variants use the same file name. > I definitely like the idea of binary builds. Although I am a > developer, I usually like to get required packages into my system > as quickly and hasslefree as possible, so I can continue my work. > And I think most users wouldn't want a build environment on their > machine if they're not developers (the Mac OS X SDK is an optional > install, too ;-) ). MacPorts doesn't yet have any such subpackages. So developer files are mandatory at the moment. > I also like sub-packages (variants?) very much, since they reduce > the need for package dependencies which I don't really need on my > machine... Sub-packages are nice, but variants aren't the same (they are also nice, but a different concept) > Is it okay to use variants for sub-package-like behavior (which I > am currently doing in the pike port I updated), or should this done > another way? Fink uses "Split-Off:" to designate subpackages: http://wiki.finkproject.org/index.php/Fink:Shlibs_tutorial#SplitOffs --anders From jkh at apple.com Tue Apr 1 02:11:07 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Tue Apr 1 02:11:35 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <5cbbe4ae0804010158rd21ed31v4b0d22668935c751@mail.gmail.com> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <748BEF7B-0BC6-453D-B5CF-922B929A9F8F@macports.org> <5cbbe4ae0804010158rd21ed31v4b0d22668935c751@mail.gmail.com> Message-ID: <4E9F0C50-C68D-4413-8E44-9E2871E4BD2D@apple.com> I think it's also important to remember that the wording for that was probably drafted during an earlier, more idealistic age. If toning it down a little would result in better recruitment counts then I think most folks would be all for it, though I think the part about demonstrating some tangible interest (in the form of a new Portfile or patches to existing ones) is still reasonable since you don't want folks just walking up, registering themselves, and then walking away again never to return, either. That just clutters things up. Perhaps there's some way to word this that would be less disheartening. Your description of yourself and your motivation certainly suggests to ME that you should have been a committer already. What's the hold-up? - Jordan On Apr 1, 2008, at 1:58 AM, Florian Ebeling wrote: >>> There are two few committers for dports/ and REALLY very few >>> committers >> for base/ - I think we should be more liberal in allowing new >> committers, >> being ever mindful of the fact that source control always means you >> can back >> things out (and, as we grow, I think it's also important to be >> flexible >> about that during/because of any dispute). >>> >> >> We have tried over the last year to really loosen up the committer >> requirements, solicit new committers, etc. We've called a number of >> times >> for new submitter applications and basically take anybody who has >> shown any >> sort of commitment or experience with MacPorts. So I'll say it once >> more: if >> you're interested in being a macports committer, please just ask: >> http://trac.macosforge.org/projects/macports/wiki/NewCommittersGuide. > > I would apply for this but I find the wording in the guide quite > disheartening. "Prove track record" etc. For me macports is > interesting, because I am a programmer, work with open source > packages, and don't fancy to do a simply "make install" in the middle > of nowhere and then are not able to get rid of the leftovers of my > experiments. That's where a portfile comes quite handy. And when I'm > at it and find I had to uprade an existing port in the process, then > I'm happy to share these results with the community. When this then > means I file a bug which is being ignored for 6 weeks then I don't do > this again, I guess. Just add more committers, and also offer commit > right where you see it fit. There is a bell curve of committers, and > there are outstanding ones, the majority, and bad ones, and one could > probably also revoke this right after a warning, if it doesn't work > out. But people also start slowly and unimpressive, and you probably > dont want to discourage them further. > > macports is a project which needs a lot of people who do a > housekeeping, rather boring kind of job, maintaining the ports and > keep them up to date. So there should probably not too much ceremony > around this process of commit rights either. It's just not the kind of > project which will solve world peace and offers fulfillment in your > life, but it can be a very handy tool for users, if it achieves to > leverage all the small effeorts of the many. > > Florian > > -- > Florian Ebeling > florian.ebeling@gmail.com From florian.ebeling at gmail.com Tue Apr 1 02:34:19 2008 From: florian.ebeling at gmail.com (Florian Ebeling) Date: Tue Apr 1 02:33:16 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <4E9F0C50-C68D-4413-8E44-9E2871E4BD2D@apple.com> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <748BEF7B-0BC6-453D-B5CF-922B929A9F8F@macports.org> <5cbbe4ae0804010158rd21ed31v4b0d22668935c751@mail.gmail.com> <4E9F0C50-C68D-4413-8E44-9E2871E4BD2D@apple.com> Message-ID: <5cbbe4ae0804010234l89bd423oa8cc3575af47b585@mail.gmail.com> > I think it's also important to remember that the wording for that was > probably drafted during an earlier, more idealistic age. If toning it down > a little would result in better recruitment counts then I think most folks > would be all for it, though I think the part about demonstrating some > tangible interest (in the form of a new Portfile or patches to existing > ones) is still reasonable since you don't want folks just walking up, > registering themselves, and then walking away again never to return, either. > That just clutters things up. Perhaps there's some way to word this that > would be less disheartening. It could probably be made to sound more like an invitation and less like a "filtering." People would probably still understand that there is this responsibility when you have only one trunk branch, and such, and that there are rules, on which the whole community relies. > Your description of yourself and your motivation certainly suggests to ME > that you should have been a committer already. What's the hold-up? Sounds good :) I send an email then. Florian -- Florian Ebeling florian.ebeling@gmail.com From exodusd at gmx.de Tue Apr 1 02:45:40 2008 From: exodusd at gmx.de (Robert Hinn) Date: Tue Apr 1 02:44:39 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <117C1FF8-51ED-436C-A3BF-2EC6CBB753F0@apple.com> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> <47F116FB.6080303@macports.org> <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> <5cbbe4ae0804010127ie90be62i74c67daf8a48fc8@mail.gmail.com> <117C1FF8-51ED-436C-A3BF-2EC6CBB753F0@apple.com> Message-ID: Am 01.04.2008 um 11:02 schrieb Jordan K. Hubbard: > This is sadly somewhat controversial. I think dependencies should > definitely be directed at the depot location, e.g. something that > links with, say, jpeg version 6.2, shouldn't link to /usr/lib/ > libjpeg.62.dylib but rather /opt/local/var/macports/software/jpeg/ > 6b_2/opt/local/lib/libjpeg.62.dylib, and so on and so forth for any > absolute-path dependencies. Then whether something is "active" or > not has nothing to do with whether it can be depended on. Every > time the subject comes up, however, various people rapidly get the > creeping crawlies and we lose the courage to actually attempt this. Hm, do you suggest using and linking only to ports? I find the lib:* dependency quite useful as I'm using the official .dmg package of MySQL from the MySQL homepage instead of the mac port (mainly because I've already been using it before installing MacPorts). Allowing such dependencies offers end users more choice in what software "distribution" to use, as long as libraries are correct. Sorry if I misunderstood you, just wanted to point out that dependencies against non-ports software can make sense for some people ;-) Robert From afb at macports.org Tue Apr 1 03:02:33 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Apr 1 03:01:54 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <5cbbe4ae0804010158rd21ed31v4b0d22668935c751@mail.gmail.com> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <748BEF7B-0BC6-453D-B5CF-922B929A9F8F@macports.org> <5cbbe4ae0804010158rd21ed31v4b0d22668935c751@mail.gmail.com> Message-ID: <15E12733-2347-4A51-BFAB-527860E75C70@macports.org> Florian Ebeling wrote: > I would apply for this but I find the wording in the guide quite > disheartening. "Prove track record" etc. For me macports is > interesting, because I am a programmer, work with open source > packages, and don't fancy to do a simply "make install" in the middle > of nowhere and then are not able to get rid of the leftovers of my > experiments. That's where a portfile comes quite handy. And when I'm > at it and find I had to uprade an existing port in the process, then > I'm happy to share these results with the community. When this then > means I file a bug which is being ignored for 6 weeks then I don't do > this again, I guess. Just add more committers, and also offer commit > right where you see it fit. There is a bell curve of committers, and > there are outstanding ones, the majority, and bad ones, and one could > probably also revoke this right after a warning, if it doesn't work > out. But people also start slowly and unimpressive, and you probably > dont want to discourage them further. I applied for commit rights after my patches had been sitting for 6 months. So I'm not sure if MacPorts has committers, or just bored port maintainers. --anders From guido.soranzio at gmail.com Tue Apr 1 05:32:54 2008 From: guido.soranzio at gmail.com (Guido Soranzio) Date: Tue Apr 1 05:32:03 2008 Subject: Ticket #14796 (pike): please commit Message-ID: <5ED26E5E-8005-41B0-BEE2-FF8A9BBAEECF@gmail.com> Jordan K. Hubbard wrote: > You need to read my entire message again, making a more > sincere attempt to understand it this time. Everything you're > asking for comes from creating that infrastructure. I have already expressed my specific current efforts: I am not interested in the integrity of hundreds semiabandoned portfiles and in writing scripts to traverse them. I was trying just to build Gnome 2.22 from scratch, following the dependencies as for the official sources: http://ftp.acc.umu.se/pub/GNOME/teams/releng/2.22.0/versions http://svn.gnome.org/viewvc/garnome/trunk/ http://svn.gnome.org/viewvc/jhbuild/trunk/modulesets/ I installed jhbuild and graphwiz since I preferred to run "jhbuild dot | dot -Tpng > dependencies.png" instead of continuing making by hand . I am blocked now at evolution-data-server and I can't afford to compile again and again WebKit, firefox-x11 and seamonkey for hours just for testing the last commits: I only suggested that the proven committers, who had already compiled and tested an archived binary, could make it available to the other committers so to speed the approval of the accumulating tickets: I didn't beg for free hosting on Apple's servers but for the URLs of prebuilt archives created by and for committers. --Guido From raimue at macports.org Tue Apr 1 07:41:04 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue Apr 1 07:40:03 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <15E12733-2347-4A51-BFAB-527860E75C70@macports.org> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <748BEF7B-0BC6-453D-B5CF-922B929A9F8F@macports.org> <5cbbe4ae0804010158rd21ed31v4b0d22668935c751@mail.gmail.com> <15E12733-2347-4A51-BFAB-527860E75C70@macports.org> Message-ID: <47F24980.5000408@macports.org> Anders F Bj?rklund wrote: > I applied for commit rights after my patches had been sitting for 6 > months. > So I'm not sure if MacPorts has committers, or just bored port > maintainers. That might be a major problem. If new people submit patches/Portfiles to Trac but they do not get committed in time they might just turn away because the team does not seem to care for their changes. Rainer From adamore at email.it Tue Apr 1 09:19:58 2008 From: adamore at email.it (Andrea D'Amore) Date: Tue Apr 1 09:18:56 2008 Subject: tilibs and tilp submitted Message-ID: <2081FA8D-37DD-4309-B1FD-0C9C14F1E6F6@email.it> Hi, I've submitted portfiles for ticket #13227 Please check it. Andrea From armahg at gmail.com Tue Apr 1 18:29:40 2008 From: armahg at gmail.com (George Armah) Date: Tue Apr 1 18:28:38 2008 Subject: A RoadMap for MacPorts Message-ID: <47F2E184.1080601@gmail.com> Hello, I am a GSoC applicant who has been following the Ticket#14796(pike): please commit email thread. There was a mention of the need of some sort of RoadMap for MacPorts (possibly) on the Wiki and this is to second that suggestion. After interacting with some of your developers for a while, I have gained the impression that much more work needs to be done on MacPorts but exactly what and exactly how hasn't been made that clear (or collected in one place). Also, it seems like there are a lot of dependencies for some of these tasks but that also hasn't been documented anywhere (afaik). A RoadMap would be most helpful for newcomers like me who might be looking to contribute to Port Development (i.e. source code) and will be wondering how their interests might fit into MacPorts' "big picture to-do list". It would also (hopefully) lead to some consensus on what needs to be done and a general idea of how MacPorts would want to go about doing it. Thanks for reading my suggestion, George Armah. From jkh at apple.com Tue Apr 1 20:42:26 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Tue Apr 1 20:42:52 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> <47F116FB.6080303@macports.org> <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> <5cbbe4ae0804010127ie90be62i74c67daf8a48fc8@mail.gmail.com> <117C1FF8-51ED-436C-A3BF-2EC6CBB753F0@apple.com> Message-ID: On Apr 1, 2008, at 2:45 AM, Robert Hinn wrote: > Hm, do you suggest using and linking only to ports? I find the lib:* > dependency quite useful as I'm using the official .dmg package of > MySQL from the MySQL homepage instead of the mac port (mainly > because I've already been using it before installing MacPorts). > Allowing such dependencies offers end users more choice in what > software "distribution" to use, as long as libraries are correct. > > Sorry if I misunderstood you, just wanted to point out that > dependencies against non-ports software can make sense for some > people ;-) I'm not going so far as to suggest that dependencies should be limited to items in the Depot, and I definitely see the value of being able to link with components of the OS which would be painful to duplicate (all of X11 comes to mind) or have been specifically optimized so as to make them more attractive than the MacPorts-provided ones. What I'm saying is that for the MacPorts-provided dependencies, being able to force them into the depot and out of /opt/local would allow a lot more things to coexist simultaneously. As MacPorts grows into a real collection (4,622 ports may seem a lot, but it's nothing close to FreeBSD's 18,280), this will become a larger and larger problem. FreeBSD "solves" it by doing namespace munging for every port that conflicts (/usr/local/bin/foo-5.6.2, /usr/lib/libfoo.5.6.2.so, /usr/ include/foo-5.6.2 and so on), which is about as much work as forcing things into the depot without the benefits of having an "uncluttered" / usr/local by default. - Jordan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080401/88cd29e6/attachment-0001.html From afb at macports.org Wed Apr 2 01:05:53 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Wed Apr 2 01:04:55 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> <47F116FB.6080303@macports.org> <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> <5cbbe4ae0804010127ie90be62i74c67daf8a48fc8@mail.gmail.com> <117C1FF8-51ED-436C-A3BF-2EC6CBB753F0@apple.com> Message-ID: <85984DE0-9D21-436F-9E9D-2FFF2CE436EB@macports.org> Jordan K. Hubbard wrote: > I'm not going so far as to suggest that dependencies should be > limited to items in the Depot, and I definitely see the value of > being able to link with components of the OS which would be painful > to duplicate (all of X11 comes to mind) or have been specifically > optimized so as to make them more attractive than the MacPorts- > provided ones. What I'm saying is that for the MacPorts-provided > dependencies, being able to force them into the depot and out of / > opt/local would allow a lot more things to coexist simultaneously. It would also make the "images" actually do something except just clutter up the disk and mess with upgrades (activity state not checked, inactive ports filling dependencies, etc), like they do now. For instance there's a linux distribution called GoboLinux that uses multiple "images". http://www.netbsd.org/gallery/pkgsrc-interviews.html#gobo-linux > As MacPorts grows into a real collection (4,622 ports may seem a > lot, but it's nothing close to FreeBSD's 18,280), this will become > a larger and larger problem. FreeBSD "solves" it by doing > namespace munging for every port that conflicts (/usr/local/bin/ > foo-5.6.2, /usr/lib/libfoo.5.6.2.so, /usr/include/foo-5.6.2 and so > on), which is about as much work as forcing things into the depot > without the benefits of having an "uncluttered" /usr/local by default. MacPorts already does this too... For instance Python doesn't install as "python", but as "python2.4" and "python2.5" etc (meaning that all shebangs needs changing). And Apache installs into either /opt/local or /opt/local/apache2, so that you can run both Apache 1.3 and Apache 2.2 at once. It's very ad-hoc, and tough on both packagers and users... --anders From ryandesign at macports.org Wed Apr 2 02:51:59 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Apr 2 02:51:38 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <85984DE0-9D21-436F-9E9D-2FFF2CE436EB@macports.org> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> <47F116FB.6080303@macports.org> <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> <5cbbe4ae0804010127ie90be62i74c67daf8a48fc8@mail.gmail.com> <117C1FF8-51ED-436C-A3BF-2EC6CBB753F0@apple.com> <85984DE0-9D21-436F-9E9D-2FFF2CE436EB@macports.org> Message-ID: <388D3E3D-B107-4C3E-8CEA-A6BA82DC4C27@macports.org> On Apr 2, 2008, at 03:05, Anders F Bj?rklund wrote: > Apache installs into either /opt/local or /opt/local/apache2, so > that you can run both Apache 1.3 and Apache 2.2 at once. If that was the goal of the /opt/local/apache2 prefix, it has failed, because you cannot activate both apache and apache2 at once. $ sudo port activate apache ---> Activating apache Error: port activate failed: Image error: /opt/local/share/man/man1/ dbmmanage.1.gz is being used by the active apache2 port. Please deactivate this port first, or use the -f flag to force the activation. $ Also, there has been a request to change apache2's prefix back to / opt/local to make it more normal. http://lists.macosforge.org/pipermail/macports-dev/2008-March/ 004648.html From ryandesign at macports.org Wed Apr 2 02:57:25 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Apr 2 02:57:00 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> <47F116FB.6080303@macports.org> <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> <5cbbe4ae0804010127ie90be62i74c67daf8a48fc8@mail.gmail.com> <117C1FF8-51ED-436C-A3BF-2EC6CBB753F0@apple.com> Message-ID: <8B98996C-6714-4CF3-8861-667055029643@macports.org> On Apr 1, 2008, at 04:45, Robert Hinn wrote: > Hm, do you suggest using and linking only to ports? I find the > lib:* dependency quite useful as I'm using the official .dmg > package of MySQL from the MySQL homepage instead of the mac port > (mainly because I've already been using it before installing > MacPorts). Allowing such dependencies offers end users more choice > in what software "distribution" to use, as long as libraries are > correct. > > Sorry if I misunderstood you, just wanted to point out that > dependencies against non-ports software can make sense for some > people ;-) However, it is not a design goal of MacPorts to support that. MacPorts is designed to use its own ports, not other software, wherever possible. There are some exceptions, like Apple's X11 for the X ports, Apple's Apache web server for things like PHP. But in general, the lib:* dependency style is deprecated and ports should be using other ports. See the FAQ: http://trac.macosforge.org/projects/macports/wiki/ FAQ#WhyisMacPortsusingitsownlibraries and the Guide: http://guide.macports.org/#reference.dependencies.types From ryandesign at macports.org Wed Apr 2 03:02:14 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Apr 2 03:01:48 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <5ED26E5E-8005-41B0-BEE2-FF8A9BBAEECF@gmail.com> References: <5ED26E5E-8005-41B0-BEE2-FF8A9BBAEECF@gmail.com> Message-ID: On Apr 1, 2008, at 07:32, Guido Soranzio wrote: > I installed jhbuild and graphwiz since I preferred to run > "jhbuild dot | dot -Tpng > dependencies.png" instead of > continuing making by hand macports/wiki/gui_dos>. Maybe you'll be interested in my port-visualization script portviz which also uses graphviz: http://www.mail-archive.com/macports-users@lists.macosforge.org/ msg07860.html From ryandesign at macports.org Wed Apr 2 04:12:29 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Apr 2 04:12:05 2008 Subject: variants / sub-packages In-Reply-To: <1088A77F-1B2F-4FBE-8016-8798A14BAE04@gmx.de> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> <47F116FB.6080303@macports.org> <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> <9B91E8F7-35AC-49BC-8633-14C2948777D4@gmail.com> <1088A77F-1B2F-4FBE-8016-8798A14BAE04@gmx.de> Message-ID: On Apr 1, 2008, at 03:40, Robert Hinn wrote: > I was wondering: seeing some ports called *-devel in the list, does > MacPorts offer a sub-package mechanism? I haven't found anything in > the guide, so I considered using variants as a proper way to handle > optional features in a software which I would otherwise build a sub- > package for. Anders already explained what *-devel ports are in MacPorts, that we don't have sub-packages, and that variants are the correct place to implement optional features in a port. I just wanted to add that there is already a request to document *-devel ports in the Guide: http://trac.macosforge.org/projects/macports/ticket/14540 See that ticket for more about *-devel ports if interested. From opendarwin.org at darkart.com Wed Apr 2 09:50:38 2008 From: opendarwin.org at darkart.com (Eric Hall) Date: Wed Apr 2 09:49:30 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <117C1FF8-51ED-436C-A3BF-2EC6CBB753F0@apple.com> References: <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> <47F116FB.6080303@macports.org> <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> <5cbbe4ae0804010127ie90be62i74c67daf8a48fc8@mail.gmail.com> <117C1FF8-51ED-436C-A3BF-2EC6CBB753F0@apple.com> Message-ID: <20080402165038.GB42614@darkart.com> On Tue, Apr 01, 2008 at 02:02:57AM -0700, Jordan K. Hubbard wrote: > > On Apr 1, 2008, at 1:27 AM, Florian Ebeling wrote: > > >Maybe I'm too ignorant, but isn't also the fact that dependencies > >are version-agnostic one major cause of build fails and probably a > >cost-effective gain to change? > > Not ignorant at all, yes, this is a well-known shortcoming of > dependencies. No way to specify minimum version, maximum version, > range of versions, and so on. Package systems like RPM do, but > lacking this in the base system means MacPorts can't make more > intelligent dependency decisions and it can't pass those on to the > packaging system, which will need to make the same decision if the > user uses packages to install instead. I think "new dependency > engine" has even been on the task list for for several years now. > > >I'm rather new to macports, but I was delighted to find that it can > >keep multiple versions installed, with only a single one active > >(usually) -- only to learn later then that it is otherwise not using > >this feature, really. > > This is sadly somewhat controversial. I think dependencies should > definitely be directed at the depot location, e.g. something that > links with, say, jpeg version 6.2, shouldn't link to /usr/lib/libjpeg. > 62.dylib but rather /opt/local/var/macports/software/jpeg/6b_2/opt/ > local/lib/libjpeg.62.dylib, and so on and so forth for any absolute- > path dependencies. Then whether something is "active" or not has > nothing to do with whether it can be depended on. Every time the > subject comes up, however, various people rapidly get the creeping > crawlies and we lose the courage to actually attempt this. I've always thought this was an excellent idea, it neatly solves conflicting version problems (libnet for example) and allows a new version of $THIS_DEPENDENCY to be installed without breaking $OTHER_SOFTWARE that's linked against $OLDER_VERSION_OF_THIS_DEPENDENCY, and/or resulting in the massive rebuild fsck to bring everything back to happyness when a dependency is upgraded. > > To be fair, and make no mistake, it's actually pretty hard to get this > right. Smashing everything together in a common $prefix and assuming > that all your deps are part of $prefix at any given time is a hugely > simplifying assumption, too. For most ports, a simple -I${prefix}/ > include and -L${prefix}/lib is all the stands between their vanilla > state and working properly with MacPorts. In a true multiple-version > world, each and every dependency potentially adds to the search paths. > Is it really that hard? Its non-trivial, that's clear, but is it something larger than a GSoC person could tackle? Or should an item like this be added to the design scope of a new dependency engine? It certainly seems like a very worthy feature to me. -eric From jmr at macports.org Wed Apr 2 10:52:31 2008 From: jmr at macports.org (Joshua Root) Date: Wed Apr 2 10:52:20 2008 Subject: Please review: fastest mirror selection proposal (with patch) Message-ID: <47F3C7DF.5030802@macports.org> Ticket: Cheers, Josh From jkh at apple.com Wed Apr 2 11:47:42 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Wed Apr 2 11:48:03 2008 Subject: Dependencies [was Re: Ticket #14796 (pike): please commit] In-Reply-To: <20080402165038.GB42614@darkart.com> References: <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> <47F116FB.6080303@macports.org> <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> <5cbbe4ae0804010127ie90be62i74c67daf8a48fc8@mail.gmail.com> <117C1FF8-51ED-436C-A3BF-2EC6CBB753F0@apple.com> <20080402165038.GB42614@darkart.com> Message-ID: [OK, time to change the bloody subject line finally! :-) ] On Apr 2, 2008, at 9:50 AM, Eric Hall wrote: > Is it really that hard? Its non-trivial, that's clear, but is > it something larger than a GSoC person could tackle? Or should an > item > like this be added to the design scope of a new dependency engine? It > certainly seems like a very worthy feature to me. I think it's an excellent GSoC project given that it's a bit tedious, requires some thought on how to traverse the dependency list and get the "target locations" for each of them in order to permute the current port builds' resource search paths, and a certain amount of coding to put it all together, but it's most definitely not rocket science. - Jordan From apple at frinabulax.org Wed Apr 2 15:37:53 2008 From: apple at frinabulax.org (robert delius royar) Date: Wed Apr 2 15:37:06 2008 Subject: [MacPorts] #14901: firefox-x11 does not provide file-selection browsers (fwd) Message-ID: I am forwarding this ticket because firefox-x11 has no maintainer, and because I wonder whether anyone has installed firefox-x11 and has it working without the error I report. I searched for tickets on this and found none. #14901: firefox-x11 does not provide file-selection browsers ----------------------------------+----------------------------------------- Reporter: apple@frinabulax.org | Owner: macports-tickets@lists.macosforge.org Type: defect | Status: new Priority: High | Milestone: Port Bugs Component: ports | Version: 1.6.0 Keywords: x11 www ui | ----------------------------------+----------------------------------------- The X11 port of firefox (2.0.0.13) does not include the code to allow the user to change preferences which require a file-browser box to "Save Link As" or to select local files/directories such as the default download directory. To test this go to Edit->Preferences->Main and select the Browse button next to "Save files to" in the "Downloads" section. On my 10.5.2 PPC system, nothing happens when the Browse button is selected. I recall from my own attempts to build SeaMonkey for Mac X11 that I could not get it to link in the gnome-vfs components (listed as required in the port file). It always insisted on trying to link in the Carbon frameworks. My Seamonkey attempts would eventually crash after repeated attempts to call the file browser. So far firefox-x11 just does nothing. Other functions work fine so far as I can tell--although the copy highlight does not work the way it should (as Mozilla X11 version 1.7.13 and Linux Firefox 2.0.0.13 do). It should copy the selection directly to the X11 Clipboard so that a middle mouse click will past the selection. Instead it requires that the selection be copied using a menu or keyboard command. That makes me believe that some of the X11 UI bits are missing from the linking. I wonder if anyone of the folks who have recently fixed problems in the port file have tried to use the port (beyond just assuring it builds, installs, and opens correctly). -- Ticket URL: MacPorts Ports system for Mac OS From peter at pogma.com Wed Apr 2 15:44:31 2008 From: peter at pogma.com (Peter O'Gorman) Date: Wed Apr 2 15:43:22 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <20080402165038.GB42614@darkart.com> References: <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> <47F116FB.6080303@macports.org> <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> <5cbbe4ae0804010127ie90be62i74c67daf8a48fc8@mail.gmail.com> <117C1FF8-51ED-436C-A3BF-2EC6CBB753F0@apple.com> <20080402165038.GB42614@darkart.com> Message-ID: <47F40C4F.6040704@pogma.com> Eric Hall wrote: > On Tue, Apr 01, 2008 at 02:02:57AM -0700, Jordan K. Hubbard wrote: >> On Apr 1, 2008, at 1:27 AM, Florian Ebeling wrote: >> This is sadly somewhat controversial. I think dependencies should >> definitely be directed at the depot location, e.g. something that >> links with, say, jpeg version 6.2, shouldn't link to /usr/lib/libjpeg. >> 62.dylib but rather /opt/local/var/macports/software/jpeg/6b_2/opt/ >> local/lib/libjpeg.62.dylib, and so on and so forth for any absolute- >> path dependencies. Then whether something is "active" or not has >> nothing to do with whether it can be depended on. Every time the >> subject comes up, however, various people rapidly get the creeping >> crawlies and we lose the courage to actually attempt this. > > I've always thought this was an excellent idea, it neatly > solves conflicting version problems (libnet for example) and allows > a new version of $THIS_DEPENDENCY to be installed without breaking > $OTHER_SOFTWARE that's linked against $OLDER_VERSION_OF_THIS_DEPENDENCY, > and/or resulting in the massive rebuild fsck to bring everything back > to happyness when a dependency is upgraded. It does not solve all that much, as all the embedded paths are still /opt/local, the install_name of the libs is still /opt/local, applications will still look for resources in /opt/local, they will not look in the depot. Passing the -L -I PKG_CONFIG_PATH etc flags to link to the stuff in the depot will have absolutely no effect on the resulting binary, making such a change, imo, pointless, older versions of things will still be broken when you update some dependency. Peter -- Peter O'Gorman http://pogma.com From raimue at macports.org Wed Apr 2 15:56:25 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed Apr 2 15:55:18 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <20080402165038.GB42614@darkart.com> References: <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> <47F116FB.6080303@macports.org> <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> <5cbbe4ae0804010127ie90be62i74c67daf8a48fc8@mail.gmail.com> <117C1FF8-51ED-436C-A3BF-2EC6CBB753F0@apple.com> <20080402165038.GB42614@darkart.com> Message-ID: <47F40F19.6090402@macports.org> Eric Hall wrote: > I've always thought this was an excellent idea, it neatly > solves conflicting version problems (libnet for example) and allows > a new version of $THIS_DEPENDENCY to be installed without breaking > $OTHER_SOFTWARE that's linked against $OLDER_VERSION_OF_THIS_DEPENDENCY, > and/or resulting in the massive rebuild fsck to bring everything back > to happyness when a dependency is upgraded. I think it is a horrible idea. It totally defeats the feature of having multiple versions of a port but only one active version. If you start linking into the depot, also rewrite all calls to binaries to the depot and all access to /opt/local/share and so on. Otherwise it would totally become inconsistent. And I don't understand why you want to look for such files inside the depot. The depot stores multiple versions and you activate one and only one of them - the others are inactive and not used at all. - If I deactivate a port, I *expect* depending ports to break. Of course a port will no longer work if a dependency is not active. - If I upgrade a port, of course I might also have to rebuild depending ports, because the installed library changed. - If I uninstall an inactive port, I expect it to be *safe* because it is not used. Please tell me what advantage you want to achieve with this? Rainer From jberry at macports.org Wed Apr 2 15:58:58 2008 From: jberry at macports.org (James Berry) Date: Wed Apr 2 15:57:58 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <47F40C4F.6040704@pogma.com> References: <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> <47F116FB.6080303@macports.org> <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> <5cbbe4ae0804010127ie90be62i74c67daf8a48fc8@mail.gmail.com> <117C1FF8-51ED-436C-A3BF-2EC6CBB753F0@apple.com> <20080402165038.GB42614@darkart.com> <47F40C4F.6040704@pogma.com> Message-ID: <98A717FD-D082-4261-97AE-49281F22F2BE@macports.org> On Apr 2, 2008, at 3:44 PM, Peter O'Gorman wrote: > Eric Hall wrote: >> On Tue, Apr 01, 2008 at 02:02:57AM -0700, Jordan K. Hubbard wrote: >>> On Apr 1, 2008, at 1:27 AM, Florian Ebeling wrote: > >>> This is sadly somewhat controversial. I think dependencies should >>> definitely be directed at the depot location, e.g. something that >>> links with, say, jpeg version 6.2, shouldn't link to /usr/lib/ >>> libjpeg. >>> 62.dylib but rather /opt/local/var/macports/software/jpeg/6b_2/opt/ >>> local/lib/libjpeg.62.dylib, and so on and so forth for any absolute- >>> path dependencies. Then whether something is "active" or not has >>> nothing to do with whether it can be depended on. Every time the >>> subject comes up, however, various people rapidly get the creeping >>> crawlies and we lose the courage to actually attempt this. >> >> I've always thought this was an excellent idea, it neatly >> solves conflicting version problems (libnet for example) and allows >> a new version of $THIS_DEPENDENCY to be installed without breaking >> $OTHER_SOFTWARE that's linked against >> $OLDER_VERSION_OF_THIS_DEPENDENCY, >> and/or resulting in the massive rebuild fsck to bring everything back >> to happyness when a dependency is upgraded. > > It does not solve all that much, as all the embedded paths are still > /opt/local, the install_name of the libs is still /opt/local, > applications will still look for resources in /opt/local, they will > not > look in the depot. > > Passing the -L -I PKG_CONFIG_PATH etc flags to link to the stuff in > the > depot will have absolutely no effect on the resulting binary, making > such a change, imo, pointless, older versions of things will still be > broken when you update some dependency. I also worry about cases like when A links against B and C. B was linked against D.version1 while C was linked against D.version2. Thus when A loads, it pulls in two (?) potentially incompatible versions of D? James -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2761 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080402/d73358a2/smime.bin From jkh at apple.com Wed Apr 2 17:13:43 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Wed Apr 2 17:14:02 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <47F40C4F.6040704@pogma.com> References: <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> <47F116FB.6080303@macports.org> <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> <5cbbe4ae0804010127ie90be62i74c67daf8a48fc8@mail.gmail.com> <117C1FF8-51ED-436C-A3BF-2EC6CBB753F0@apple.com> <20080402165038.GB42614@darkart.com> <47F40C4F.6040704@pogma.com> Message-ID: I think we must be talking about a different mechanism since in what I'm suggesting, the embedded paths WOULD point to the appropriate depot locations, the install_name of the libs WOULD be the target locations and applications absolutely WOULD look for their resources in the depot locations. There are no technical reasons why this wouldn't be possible and, as someone else recently pointed out, the GoboLinux* folks have certainly managed to do it. The only function of /opt/local in that scenario would be as a link farm to activated applications in the depot so that users did not have to adjust their $PATH to contain a path to each and every /opt/local/ var/macports/software/foo/bar/bin directory (though, frankly, if there were some sort of path-helper tool to set that, one could potentially retire /opt/local entirely and dispense with the activated/deactivated state, but that's probably too ambitious to start with). - Jordan * http://www.gobolinux.org/?page=at_a_glance is interesting reading. It makes me glad to see that at least some folks have been willing to tackle this in such a systematic way and, if they get the whole "per- dependency-tree namespace" stuff ironed out, will definitely have achieved something impressive here. On Apr 2, 2008, at 3:44 PM, Peter O'Gorman wrote: > It does not solve all that much, as all the embedded paths are still > /opt/local, the install_name of the libs is still /opt/local, > applications will still look for resources in /opt/local, they will > not > look in the depot. > > Passing the -L -I PKG_CONFIG_PATH etc flags to link to the stuff in > the > depot will have absolutely no effect on the resulting binary, making > such a change, imo, pointless, older versions of things will still be > broken when you update some dependency. From jkh at apple.com Wed Apr 2 17:43:05 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Wed Apr 2 17:42:25 2008 Subject: Depot dependencies [was Re: Ticket #14796 (pike): please commit] In-Reply-To: <47F40F19.6090402@macports.org> References: <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> <47F116FB.6080303@macports.org> <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> <5cbbe4ae0804010127ie90be62i74c67daf8a48fc8@mail.gmail.com> <117C1FF8-51ED-436C-A3BF-2EC6CBB753F0@apple.com> <20080402165038.GB42614@darkart.com> <47F40F19.6090402@macports.org> Message-ID: [ Making another futile attempt to use a more descriptive subject line ] On Apr 2, 2008, at 3:56 PM, Rainer M?ller wrote: > I think it is a horrible idea. It totally defeats the feature of > having multiple versions of a port but only one active version. Not at all. If you want to continue the notion of /opt/local then there's still only one "active" non-colliding port permitted in there at a time and you still have this "feature", for whatever it's worth, and that's not much. See below: > If you start linking into the depot, also rewrite all calls to > binaries to the depot and all access to /opt/local/share and so on. > Otherwise it would totally become inconsistent. And I don't > understand why you want to look for such files inside the depot. The > depot stores multiple versions and you activate one and only one of > them - the others are inactive and not used at all. That's the problem - the others are inactive and you might WISH that they weren't used at all, but reality from an end-user's perspective will not fulfill this wish for you. Users WILL want to be able to use portX and portY simultaneously where each depends on a different version of portZ, and expecting the portX and portY folks to converge on a single version of portZ is about as practical as expecting everyone in the middle east to stop fighting. It won't happen, you can't force it to happen (well, you can try, but you'll quickly run out of time and energy) and the best you can do is try and devise a framework which allows it to happen in a controlled fashion. > - If I deactivate a port, I *expect* depending ports to break. You are talking like a developer, not a user. Users *expect* to use what may be a large collection of software, all "activated" at the same time, and they don't want to hear about how limitations in cooperation / available time among software developers are keeping them from having portX and portY active at the same time. After you have listened to them complain for a couple of years, you won't want to hear about it either. MacPorts is still in the honeymoon phase where few actual "end users" use it (largely due to the absence of pre-built packages and a GUI) and the collection is small enough that these sorts of problems don't happen very often. Do not, however, make the mistake of thinking that just because it is not a problem for you, or a problem today, that it is not going to be a problem in the future. People are also free to not believe me - that's cool - I'm used to that. Do, however, at least give me the courtesy of keeping in mind the fact that I did create the FreeBSD Ports Collection and was in an excellent position to watch it grow from 200 ports to 2,000 ports to 12,000 ports, observing a number of painful experiences and "gosh, if we'd only done X, Y or Z at the start" lessons learned along the way. When my group at Apple created DarwinPorts, we also tried to learn from some of those lessons and create a more flexible ports framework, but we didn't attempt to solve every problem we knew would be coming in the future since we had only so much time and few resources. This is one of the problems we didn't have time to solve but knew we'd need to if DarwinPorts ever truly became a big success and had lots of users. Maybe that lack of success has been a blessing in disguise, but it hardly seems like something the project would want to aim for. A system for developers and by developers isn't nearly as interesting as trying to actually solve the hard problems. - Jordan From peter at pogma.com Wed Apr 2 17:43:58 2008 From: peter at pogma.com (Peter O'Gorman) Date: Wed Apr 2 17:43:01 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: References: <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> <47F116FB.6080303@macports.org> <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> <5cbbe4ae0804010127ie90be62i74c67daf8a48fc8@mail.gmail.com> <117C1FF8-51ED-436C-A3BF-2EC6CBB753F0@apple.com> <20080402165038.GB42614@darkart.com> <47F40C4F.6040704@pogma.com> Message-ID: <47F4284E.7070708@pogma.com> Jordan K. Hubbard wrote: > I think we must be talking about a different mechanism since in what I'm > suggesting, the embedded paths WOULD point to the appropriate depot > locations, the install_name of the libs WOULD be the target locations > and applications absolutely WOULD look for their resources in the depot > locations. There are no technical reasons why this wouldn't be possible > and, as someone else recently pointed out, the GoboLinux* folks have > certainly managed to do it. We do it at work (thewrittenword.com) too. For the default customer, packages are installed to /opt/TWWfsw/. e.g. libpng is installed to the /opt/TWWfsw/libpng12 prefix (for libpng-1.2.x), gcc-4.2.2 is installed at /opt/TWWfsw/gcc42 and so on. There is really little point in having libpng1218 libpng1219 etc as they are ABI compatible. If we had fully versioned library install locations like that, we could not update the libpng version for security fixes without rebuilding everything that uses it too. It certainly works, but we have to patch the majority of packages to get them to work like that. And to build some packages you end up with a very long list of things in PKG_CONFIG_PATH LDFLAGS and CPPFLAGS. Peter -- Peter O'Gorman http://pogma.com From dluke at geeklair.net Wed Apr 2 18:25:31 2008 From: dluke at geeklair.net (Daniel J. Luke) Date: Wed Apr 2 18:24:43 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <98A717FD-D082-4261-97AE-49281F22F2BE@macports.org> References: <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> <47F116FB.6080303@macports.org> <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> <5cbbe4ae0804010127ie90be62i74c67daf8a48fc8@mail.gmail.com> <117C1FF8-51ED-436C-A3BF-2EC6CBB753F0@apple.com> <20080402165038.GB42614@darkart.com> <47F40C4F.6040704@pogma.com> <98A717FD-D082-4261-97AE-49281F22F2BE@macports.org> Message-ID: <8932A94D-36B3-406F-9CA0-8946D096A5BF@geeklair.net> On Apr 2, 2008, at 6:58 PM, James Berry wrote: >> Passing the -L -I PKG_CONFIG_PATH etc flags to link to the stuff in >> the >> depot will have absolutely no effect on the resulting binary, making >> such a change, imo, pointless, older versions of things will still be >> broken when you update some dependency. > > I also worry about cases like when A links against B and C. B was > linked against D.version1 while C was linked against D.version2. > Thus when A loads, it pulls in two (?) potentially incompatible > versions of D? How about when someone discovers a security vulnerability in D and upstream only fixes it in Version 2 (which was ABI incompatible with version 1 and has changed so much that you can't simply diff & patch to use the fix on version 1)? We still end up needing to re-link everything that was linked against D version 1 so that it uses D version 2 + security patch. MacPorts is already pretty weak when dealing with the dependency graph, making the graph significantly more complicated won't help things here (I'd like to be proven wrong, though :) ). -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080402/9a65ca00/PGP.bin From milosh at macports.org Wed Apr 2 23:54:23 2008 From: milosh at macports.org (Emmanuel Hainry) Date: Wed Apr 2 23:53:13 2008 Subject: Depot dependencies [was Re: Ticket #14796 (pike): please commit] In-Reply-To: References: <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> <47F116FB.6080303@macports.org> <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> <5cbbe4ae0804010127ie90be62i74c67daf8a48fc8@mail.gmail.com> <117C1FF8-51ED-436C-A3BF-2EC6CBB753F0@apple.com> <20080402165038.GB42614@darkart.com> <47F40F19.6090402@macports.org> Message-ID: <20080403065423.GA3286@velsheda.lateralis.org> Citando Jordan K. Hubbard : > [ Making another futile attempt to use a more descriptive subject line ] > > On Apr 2, 2008, at 3:56 PM, Rainer M?ller wrote: > >> I think it is a horrible idea. It totally defeats the feature of >> having multiple versions of a port but only one active version. > > Not at all. If you want to continue the notion of /opt/local then > there's still only one "active" non-colliding port permitted in there at > a time and you still have this "feature", for whatever it's worth, and > that's not much. See below: > >> If you start linking into the depot, also rewrite all calls to >> binaries to the depot and all access to /opt/local/share and so on. >> Otherwise it would totally become inconsistent. And I don't understand >> why you want to look for such files inside the depot. The depot stores >> multiple versions and you activate one and only one of them - the >> others are inactive and not used at all. > > That's the problem - the others are inactive and you might WISH that > they weren't used at all, but reality from an end-user's perspective > will not fulfill this wish for you. Users WILL want to be able to use > portX and portY simultaneously where each depends on a different version > of portZ, I certainly won't be a user of That macports. > and expecting the portX and portY folks to converge on a single > version of portZ is about as practical as expecting everyone in the > middle east to stop fighting. It won't happen, you can't force it to > happen (well, you can try, but you'll quickly run out of time and energy) > and the best you can do is try and devise a framework which allows it to > happen in a controlled fashion. What you are talking about is dependencies on version, not on inactive ports. Dependency on version is useful on some cases, and its implemented in macports (there's a workaround): some ports have more than one version: libnet vs libnet11, the handful of db4x ports. Depending on an inactive port is a nightmare: if you update a library, you don't expect its dependents to still use the unsecure deprecated one: users expect dependents to link against the new secure lib (no API change) or the dependent ti be relinked... The way to go in my mind is more to inform of an API change so that dependents are rebuilt by default if needed. > >> - If I deactivate a port, I *expect* depending ports to break. > > You are talking like a developer, not a user. Users *expect* to use > what may be a large collection of software, all "activated" at the same > time, and they don't want to hear about how limitations in cooperation / > available time among software developers are keeping them from having > portX and portY active at the same time. After you have listened to > them complain for a couple of years, you won't want to hear about it > either. The thing is we developpers (or people thinking like developpers) are also users and we want things to work as expected and in a logical and predictible way, not necessarily in a way that is the most comfortable. I don't expect that many of us will want to be developpers of a project we won't use, do you? > > MacPorts is still in the honeymoon phase where few actual "end users" > use it (largely due to the absence of pre-built packages and a GUI) > and the collection is small enough that these sorts of problems don't > happen very often. Do not, however, make the mistake of thinking that > just because it is not a problem for you, or a problem today, that it > is not going to be a problem in the future. > > People are also free to not believe me - that's cool - I'm used to > that. Do, however, at least give me the courtesy of keeping in mind > the fact that I did create the FreeBSD Ports Collection and was in an > excellent position to watch it grow from 200 ports to 2,000 ports to > 12,000 ports, observing a number of painful experiences and "gosh, if > we'd only done X, Y or Z at the start" lessons learned along the way. > > When my group at Apple created DarwinPorts, we also tried to learn > from some of those lessons and create a more flexible ports framework, > but we didn't attempt to solve every problem we knew would be coming > in the future since we had only so much time and few resources. This > is one of the problems we didn't have time to solve but knew we'd need > to if DarwinPorts ever truly became a big success and had lots of > users. Maybe that lack of success has been a blessing in disguise, > but it hardly seems like something the project would want to aim for. > A system for developers and by developers isn't nearly as interesting > as trying to actually solve the hard problems. > > - Jordan > Last thing: the problem of dependents would greatly benefit from binary builds as port maintainers would be able to test more easily if dependents are breaking and thus to mark them for rebuild. But the way it is now, the only thing that would be needed for users to be more comfortable would be changing the default behaviour of upgrade and solving the cycling when using recursive upgrade. Emmanuel From jkh at apple.com Thu Apr 3 01:23:59 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Thu Apr 3 01:24:17 2008 Subject: Depot dependencies [was Re: Ticket #14796 (pike): please commit] In-Reply-To: <20080403065423.GA3286@velsheda.lateralis.org> References: <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> <47F116FB.6080303@macports.org> <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> <5cbbe4ae0804010127ie90be62i74c67daf8a48fc8@mail.gmail.com> <117C1FF8-51ED-436C-A3BF-2EC6CBB753F0@apple.com> <20080402165038.GB42614@darkart.com> <47F40F19.6090402@macports.org> <20080403065423.GA3286@velsheda.lateralis.org> Message-ID: <12A6396F-F8E8-40D4-8D01-0717ABBA96A8@apple.com> On Apr 2, 2008, at 11:54 PM, Emmanuel Hainry wrote: > I certainly won't be a user of That macports. That would be your choice. > What you are talking about is dependencies on version, not on inactive > ports. There is no effective distinction. We are both talking about the same thing. > The way to go in my mind is more to inform of an API change so that > dependents are rebuilt by default if needed. That is a very pretty world you describe, one where API changes just require a rebuild or two, never breaking anything really important or in lots of places at the same time. I would like to live in that world too - it sounds much nicer than this one. :-) > The thing is we developpers (or people thinking like developpers) are > also users and we want things to work as expected and in a logical and > predictible way One developer's "logical and predictable" is another developer's "gah, that totally SUCKS!". That is why we design for users and not developers. Get used to it. - Jordan From milosh at macports.org Thu Apr 3 02:27:24 2008 From: milosh at macports.org (Emmanuel Hainry) Date: Thu Apr 3 02:25:40 2008 Subject: Depot dependencies [was Re: Ticket #14796 (pike): please commit] In-Reply-To: <12A6396F-F8E8-40D4-8D01-0717ABBA96A8@apple.com> References: <47F116FB.6080303@macports.org> <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> <5cbbe4ae0804010127ie90be62i74c67daf8a48fc8@mail.gmail.com> <117C1FF8-51ED-436C-A3BF-2EC6CBB753F0@apple.com> <20080402165038.GB42614@darkart.com> <47F40F19.6090402@macports.org> <20080403065423.GA3286@velsheda.lateralis.org> <12A6396F-F8E8-40D4-8D01-0717ABBA96A8@apple.com> Message-ID: <20080403092724.GA4730@weetamoe.loria.fr> Citando Jordan K. Hubbard : > > On Apr 2, 2008, at 11:54 PM, Emmanuel Hainry wrote: > >> The way to go in my mind is more to inform of an API change so that >> dependents are rebuilt by default if needed. > > That is a very pretty world you describe, one where API changes just > require a rebuild or two, never breaking anything really important or in > lots of places at the same time. I would like to live in that world too > - it sounds much nicer than this one. :-) > The problem is, if a rebuild is not enough, it means people who don't have the old version won't be able to build it either. A clean source install is supposed to work or be sought after. At least as long as we don't provide binary build archives (not just binary builds...). Emmanuel From afb at macports.org Thu Apr 3 02:31:36 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu Apr 3 02:30:33 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: References: <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> <47F116FB.6080303@macports.org> <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> <5cbbe4ae0804010127ie90be62i74c67daf8a48fc8@mail.gmail.com> <117C1FF8-51ED-436C-A3BF-2EC6CBB753F0@apple.com> <20080402165038.GB42614@darkart.com> <47F40C4F.6040704@pogma.com> Message-ID: <55F76D41-689C-4C91-9116-5BDEF1D98CCB@macports.org> Jordan K. Hubbard wrote: > * http://www.gobolinux.org/?page=at_a_glance is interesting > reading. It makes me glad to see that at least some folks have > been willing to tackle this in such a systematic way and, if they > get the whole "per-dependency-tree namespace" stuff ironed out, > will definitely have achieved something impressive here. The Gobo Compile bootstrapping scripts "work" on Mac OS X (pretty much in the same way that Gentoo Portage "works"), just that they are GNU/Linux-centric in the same way that MacPorts is BSD/Darwin- centric. But Gobo is somewhat interesting, since it uses a more "Mac" layout than even Mac OS X does (mostly a traditional UNIX layout for lowlevel BSD stuff). No frameworks, though, "only" headers/libraries. http://www.gobolinux.org/?page=rootless http://www.gobolinux.org/index.php?page=doc/articles/porting_guide http://www.gobolinux.org/screenshots/screenshots/ 000_Massen_RootlessOnOSX.png --anders From randall.h.wood at alexandriasoftware.com Thu Apr 3 04:01:48 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Thu Apr 3 04:00:41 2008 Subject: A RoadMap for MacPorts In-Reply-To: <47F2E184.1080601@gmail.com> References: <47F2E184.1080601@gmail.com> Message-ID: On Tue, Apr 1, 2008 at 9:29 PM, George Armah wrote: > Hello, > > I am a GSoC applicant who has been following the Ticket#14796(pike): please > commit email > thread. There was a mention of the need of some sort of RoadMap for > MacPorts (possibly) > on the Wiki and this is to second that suggestion. > > After interacting with some of your developers for a while, I have gained > the impression > that much more work needs to be done on MacPorts but exactly what and > exactly how > hasn't been made that clear (or collected in one place). > Also, it seems like there are a lot of dependencies for some of these > tasks but that also hasn't been documented anywhere (afaik). > > A RoadMap would be most helpful for newcomers like me who might be looking > to contribute to Port Development (i.e. source code) and will be wondering > how their interests might fit into MacPorts' "big picture to-do list". It > would also > (hopefully) lead to some consensus on what needs to be done and a general > idea > of how MacPorts would want to go about doing it. > > Thanks for reading my suggestion, > > George Armah. > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev > I've created a ticket for this: http://trac.macosforge.org/projects/macports/ticket/14909 Which leads to another problem: we don't use Trac effectively--it seems to sit off to the side of the email lists, frequently referred to, but basically unused unless someone brings his or her ticket to our attention, or unless someone requests that a ticket can be created to hang work off of. -- Randall Wood randall.h.wood@alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From frstan at bellsouth.net Sat Apr 5 22:55:19 2008 From: frstan at bellsouth.net (William Davis) Date: Sat Apr 5 22:54:07 2008 Subject: scrollkeeper Message-ID: <51227A9E-9B73-4CE9-9B93-1F348D8F7029@bellsouth.net> dang it all you have fixed scrollkeeper so I cant re-install it but now I cant install half the gnome updates because they want scrollkeeper! Im disgussted........ Well I need some sleep. Ill try to write it all up tommorow because if I do it now Ill rant :/ William Davis frstanATbellsouthDOTnet Mac OS X.5.2 Darwin 9.2.2 Xquartz 2.2.0 - (xorg-server 1.3.0-apple13) Mac Mini Intel Duo @ 1.86 GHz Mundus vult decepi, ego non From randall.h.wood at alexandriasoftware.com Sun Apr 6 01:26:12 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Sun Apr 6 01:24:47 2008 Subject: scrollkeeper In-Reply-To: <51227A9E-9B73-4CE9-9B93-1F348D8F7029@bellsouth.net> References: <51227A9E-9B73-4CE9-9B93-1F348D8F7029@bellsouth.net> Message-ID: On Sun, Apr 6, 2008 at 1:55 AM, William Davis wrote: > dang it all > you have fixed scrollkeeper so I cant re-install it but now I cant install > half the gnome updates because they want scrollkeeper! > Im disgussted........ There are no ports that depend on scrollkeeper. None. Every port that had a dependency on scrollkeeper now has a dependency on rarian. Try sudo port selfupdate ; sudo port clean --all all ; sudo port upgrade outdated and see if that helps. > Well I need some sleep. Ill try to write it all up tommorow because if I do > it now Ill rant > > :/ > > > William Davis > frstanATbellsouthDOTnet > Mac OS X.5.2 Darwin 9.2.2 > Xquartz 2.2.0 - (xorg-server 1.3.0-apple13) > Mac Mini Intel Duo @ 1.86 GHz > > Mundus vult decepi, ego non > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev > -- Randall Wood randall.h.wood@alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From randall.h.wood at alexandriasoftware.com Sun Apr 6 02:59:28 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Sun Apr 6 02:58:02 2008 Subject: MacPorts.org infrastructure Message-ID: If I want to build a test environment that mimics the www.macports.org server, what should I do? Clearly we are using php, mysql, and apache on that server, but what versions are we using? What are the special scripts we are using? -- Randall Wood randall.h.wood@alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From randall.h.wood at alexandriasoftware.com Sun Apr 6 04:29:49 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Sun Apr 6 04:28:24 2008 Subject: Port sqlite build error: Message-ID: ---> Building sqlite3 with target all Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_sqlite3/work/sqlite-3.5.7" && gnumake all " returned error 2 Command output: sed -e s/--VERS--/3.5.7/ ./src/sqlite.h.in | \ sed -e s/--VERSION-NUMBER--/3005007/ >sqlite3.h /usr/bin/gcc-4.0 -O2 -o mkkeywordhash ./tool/mkkeywordhash.c ./mkkeywordhash >keywordhash.h /usr/bin/gcc-4.0 -O2 -o lemon ./tool/lemon.c cp ./tool/lempar.c . cp ./src/parse.y . ./lemon parse.y mv parse.h parse.h.temp f ./addopcodes.awk parse.h.temp >parse.h /bin/sh: f: command not found gnumake: [parse.c] Error 127 (ignored) cat parse.h ./src/vdbe.c | -f ./mkopcodeh.awk >opcodes.h /bin/sh: -f: command not found cat: stdout: Broken pipe gnumake: *** [opcodes.h] Error 127 Error: The following dependencies failed to build: apache2 apr-util sqlite3 Error: Status 1 encountered during processing. See http://trac.macosforge.org/projects/macports/ticket/14938 -- Randall Wood randall.h.wood@alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From guido.soranzio at gmail.com Sun Apr 6 04:46:17 2008 From: guido.soranzio at gmail.com (Guido Soranzio) Date: Sun Apr 6 04:44:58 2008 Subject: Port sqlite build error: In-Reply-To: References: Message-ID: > Error: The following dependencies failed to build: apache2 apr-util > sqlite3 > Error: Status 1 encountered during processing. > > See http://trac.macosforge.org/projects/macports/ticket/14938 A simple "sudo port clean sqlite3 ; sudo port install sqlite3" should work. This trick always work in MacPorts 1.6 (i.e. with the python packages) when strange messages are reporting missing commands/compilers and these ones have been just installed as dependencies. --Guido From frstan at bellsouth.net Sun Apr 6 07:48:55 2008 From: frstan at bellsouth.net (William Davis) Date: Sun Apr 6 07:47:31 2008 Subject: scrollkeeper In-Reply-To: References: <51227A9E-9B73-4CE9-9B93-1F348D8F7029@bellsouth.net> Message-ID: <03E7F2BB-F7DB-4E33-A83B-B656CE329B00@bellsouth.net> On Apr 6, 2008, at 4:26 AM, Randall Wood wrote: > On Sun, Apr 6, 2008 at 1:55 AM, William Davis > wrote: >> dang it all >> you have fixed scrollkeeper so I cant re-install it but now I cant >> install >> half the gnome updates because they want scrollkeeper! >> Im disgussted........ > > There are no ports that depend on scrollkeeper. None. Every port that > had a dependency on scrollkeeper now has a dependency on rarian. Try > > sudo port selfupdate ; sudo port clean --all all ; sudo port upgrade > outdated > > and see if that helps. > >> 1. Using $(sysconfdir)/gconf/schemas as install directory for schema files checking for scrollkeeper-config... no configure: error: Couldn't find scrollkeeper-config ./configure: line 4586: exit: please: numeric argument required ./configure: line 4586: exit: please: numeric argument required Warning: the following items did not execute (for bug-buddy): org.macports.destroot org.macports.configure org.macports.build DEBUG: Error: Unable to upgrade port: 1 2. checking for scrollkeeper-config... no configure: error: Couldn't find scrollkeeper-config ./configure: line 26210: exit: please: numeric argument required ./configure: line 26210: exit: please: numeric argument required Warning: the following items did not execute (for gnome-applets): org.macports.destroot org.macports.configure org.macports.build DEBUG: Error: Unable to upgrade port: 1 3. checking for scrollkeeper-config... no configure: error: Couldn't find scrollkeeper-config. Please install the scrollkeeper package Warning: the following items did not execute (for gnome-desktop): org.macports.destroot org.macports.configure org.macports.build DEBUG: Error: Unable to upgrade port: 1 macintosh:~ frstan$ 4. Making all in doc /bin/sh: scrollkeeper-config: command not found /bin/sh: scrollkeeper-config: command not found The file '/Templates/C/scrollkeeper_cl.xml' does not exist. Please check your ScrollKeeper installation. make[3]: *** [gnome-volume-control-C.omf] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Warning: the following items did not execute (for gnome-media): org.macports.destroot org.macports.build DEBUG: Error: Unable to upgrade port: 1 5. Making all in it for file in gucharmap-it.omf; do \ scrollkeeper-preinstall /opt/local/share/gnome/help/gucharmap/it/ gucharmap.xml ./$file $file.out; \ done /bin/sh: scrollkeeper-preinstall: command not found make[3]: [omf_timestamp] Error 127 (ignored) touch omf_timestamp Making all in ja for file in gucharmap-ja.omf; do \ scrollkeeper-preinstall /opt/local/share/gnome/help/gucharmap/ja/ gucharmap.xml ./$file $file.out; \ done /bin/sh: scrollkeeper-preinstall: command not found make[3]: [omf_timestamp] Error 127 (ignored) touch omf_timestamp Making all in zh_CN for file in gucharmap-zh_CN.omf; do \ scrollkeeper-preinstall /opt/local/share/gnome/help/gucharmap/zh_CN/ gucharmap.xml ./$file $file.out; \ done /bin/sh: scrollkeeper-preinstall: command not found make[3]: [omf_timestamp] Error 127 (ignored) touch omf_timestamp Making all in zh_TW for file in gucharmap-zh_TW.omf; do \ scrollkeeper-preinstall /opt/local/share/gnome/help/gucharmap/zh_TW/ gucharmap.xml ./$file $file.out; \ done /bin/sh: scrollkeeper-preinstall: command not found make[3]: [omf_timestamp] Error 127 (ignored) touch omf_timestamp /snip/ install: gucharmap-it.omf.out: No such file or directory make[4]: *** [install-data-hook-omf] Error 71 make[3]: *** [install-data-am] Error 2 make[2]: *** [install-am] Error 2 make[1]: *** [install-recursive] Error 1 make: *** [install-recursive] Error 1 Warning: the following items did not execute (for gucharmap): org.macports.destroot DEBUG: Error: Unable to upgrade port: 1 6. others (such as yelp) attempt to use scrollkeeper which fails but the install completes Those are all I care to take time to bother to list. And yes I did selfupdate and clean --all : I do those regularly. Im very disapointed with the lack of quality in the MacPorts system and its undepedability. William Davis frstanATbellsouthDOTnet Mac OS X.5.2 Darwin 9.2.2 Xquartz 2.2.0 - (xorg-server 1.3.0-apple13) Mac Mini Intel Duo @ 1.86 GHz Mundus vult decepi, ego non From randall.h.wood at alexandriasoftware.com Sun Apr 6 17:14:53 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Sun Apr 6 17:13:38 2008 Subject: scrollkeeper In-Reply-To: <03E7F2BB-F7DB-4E33-A83B-B656CE329B00@bellsouth.net> References: <51227A9E-9B73-4CE9-9B93-1F348D8F7029@bellsouth.net> <03E7F2BB-F7DB-4E33-A83B-B656CE329B00@bellsouth.net> Message-ID: On Sun, Apr 6, 2008 at 10:48 AM, William Davis wrote: > > On Apr 6, 2008, at 4:26 AM, Randall Wood wrote: > > > > On Sun, Apr 6, 2008 at 1:55 AM, William Davis > wrote: > > > > > dang it all > > > you have fixed scrollkeeper so I cant re-install it but now I cant > install > > > half the gnome updates because they want scrollkeeper! > > > Im disgussted........ > > > > > > > There are no ports that depend on scrollkeeper. None. Every port that > > had a dependency on scrollkeeper now has a dependency on rarian. Try > > > > sudo port selfupdate ; sudo port clean --all all ; sudo port upgrade > outdated > > > > and see if that helps. > > > > > > > > > > > > > > 1. > Using $(sysconfdir)/gconf/schemas as install directory for schema files > checking for scrollkeeper-config... no > configure: error: Couldn't find scrollkeeper-config > ./configure: line 4586: exit: please: numeric argument required > ./configure: line 4586: exit: please: numeric argument required > > Warning: the following items did not execute (for bug-buddy): > org.macports.destroot org.macports.configure org.macports.build > DEBUG: > Error: Unable to upgrade port: 1 > 2. > checking for scrollkeeper-config... no > configure: error: Couldn't find scrollkeeper-config > ./configure: line 26210: exit: please: numeric argument required > ./configure: line 26210: exit: please: numeric argument required > > Warning: the following items did not execute (for gnome-applets): > org.macports.destroot org.macports.configure org.macports.build > DEBUG: > Error: Unable to upgrade port: 1 > 3. > checking for scrollkeeper-config... no > configure: error: Couldn't find scrollkeeper-config. Please install the > scrollkeeper package > > Warning: the following items did not execute (for gnome-desktop): > org.macports.destroot org.macports.configure org.macports.build > DEBUG: > Error: Unable to upgrade port: 1 > macintosh:~ frstan$ > 4. > Making all in doc > /bin/sh: scrollkeeper-config: command not found > /bin/sh: scrollkeeper-config: command not found > The file '/Templates/C/scrollkeeper_cl.xml' does not exist. > Please check your ScrollKeeper installation. > make[3]: *** [gnome-volume-control-C.omf] Error 1 > make[2]: *** [all-recursive] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > > Warning: the following items did not execute (for gnome-media): > org.macports.destroot org.macports.build > DEBUG: > Error: Unable to upgrade port: 1 > 5. > Making all in it > for file in gucharmap-it.omf; do \ > scrollkeeper-preinstall > /opt/local/share/gnome/help/gucharmap/it/gucharmap.xml ./$file $file.out; \ > done > /bin/sh: scrollkeeper-preinstall: command not found > make[3]: [omf_timestamp] Error 127 (ignored) > touch omf_timestamp > Making all in ja > for file in gucharmap-ja.omf; do \ > scrollkeeper-preinstall > /opt/local/share/gnome/help/gucharmap/ja/gucharmap.xml ./$file $file.out; \ > done > /bin/sh: scrollkeeper-preinstall: command not found > make[3]: [omf_timestamp] Error 127 (ignored) > touch omf_timestamp > Making all in zh_CN > for file in gucharmap-zh_CN.omf; do \ > scrollkeeper-preinstall > /opt/local/share/gnome/help/gucharmap/zh_CN/gucharmap.xml ./$file $file.out; > \ > done > /bin/sh: scrollkeeper-preinstall: command not found > make[3]: [omf_timestamp] Error 127 (ignored) > touch omf_timestamp > Making all in zh_TW > for file in gucharmap-zh_TW.omf; do \ > scrollkeeper-preinstall > /opt/local/share/gnome/help/gucharmap/zh_TW/gucharmap.xml ./$file $file.out; > \ > done > /bin/sh: scrollkeeper-preinstall: command not found > make[3]: [omf_timestamp] Error 127 (ignored) > touch omf_timestamp > > /snip/ > > install: gucharmap-it.omf.out: No such file or directory > make[4]: *** [install-data-hook-omf] Error 71 > make[3]: *** [install-data-am] Error 2 > make[2]: *** [install-am] Error 2 > make[1]: *** [install-recursive] Error 1 > make: *** [install-recursive] Error 1 > > Warning: the following items did not execute (for gucharmap): > org.macports.destroot > DEBUG: > Error: Unable to upgrade port: 1 > > 6. > others (such as yelp) attempt to use scrollkeeper which fails but the > install completes The current version of yelp breaks if scrollkeeper is installed. This is a deliberate decision on the upstream maintainers of that package for the GNOME project. They provide a package called rarian that is a drop-in replacement for scrollkeeper with extended capabilities to support internationalization needs, as scrollkeeper has not been updated by its maintainers for a few years now. > Those are all I care to take time to bother to list. Did you perhaps bother to read the notes in the scrollkeeper port when it aborts the installation, or bother to my original reply to your message. The port named "rarian" is the port you want to use. Every port that did depend on scrollkeeper (or on a port that depended on scrollkeeper) no w depends on the port named "rarian" (or on a port that depends on "rarian"). Every problem you list is the result of not having the port named "rarian" installed. The scrollkeeper port is explicit: you should use the port rarian instead of it. > And yes I did selfupdate and clean --all : I do those regularly. > > Im very disapointed with the lack of quality in the MacPorts system and its > undepedability. ... > William Davis > frstanATbellsouthDOTnet > Mac OS X.5.2 Darwin 9.2.2 > Xquartz 2.2.0 - (xorg-server 1.3.0-apple13) > Mac Mini Intel Duo @ 1.86 GHz > > Mundus vult decepi, ego non > > -- Randall Wood randall.h.wood@alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From jgm at berkeley.edu Sun Apr 6 18:54:26 2008 From: jgm at berkeley.edu (John MacFarlane) Date: Sun Apr 6 18:51:27 2008 Subject: [MacPorts] #14886 (pandoc) - patch uploaded, needs commit Message-ID: <20080407015426.GA14421@berkeley.edu> Hello all, I've uploaded a small patch that fixes #14886 (pandoc fails to build). If someone could commit it, that would be much appreciated! John From frstan at bellsouth.net Sun Apr 6 23:20:22 2008 From: frstan at bellsouth.net (William Davis) Date: Sun Apr 6 23:18:54 2008 Subject: scrollkeeper In-Reply-To: References: <51227A9E-9B73-4CE9-9B93-1F348D8F7029@bellsouth.net> <03E7F2BB-F7DB-4E33-A83B-B656CE329B00@bellsouth.net> Message-ID: <9E73F335-C690-4FB8-B749-9FBF269B6B5C@bellsouth.net> On Apr 6, 2008, at 8:14 PM, Randall Wood wrote: > On Sun, Apr 6, 2008 at 10:48 AM, William Davis > wrote: >> >> On Apr 6, 2008, at 4:26 AM, Randall Wood wrote: >> >> >>> On Sun, Apr 6, 2008 at 1:55 AM, William Davis >> wrote: >>> >>>> dang it all >>>> you have fixed scrollkeeper so I cant re-install it but now I cant >> install >>>> half the gnome updates because they want scrollkeeper! >>>> Im disgussted........ >>>> >>> >>> There are no ports that depend on scrollkeeper. None. Every port >>> that >>> had a dependency on scrollkeeper now has a dependency on rarian. Try >>> >>> sudo port selfupdate ; sudo port clean --all all ; sudo port upgrade >> outdated >>> >>> and see if that helps. >>> >>> >>>> >>>> >>> >> >> 1. >> Using $(sysconfdir)/gconf/schemas as install directory for schema >> files >> checking for scrollkeeper-config... no >> configure: error: Couldn't find scrollkeeper-config >> ./configure: line 4586: exit: please: numeric argument required >> ./configure: line 4586: exit: please: numeric argument required >> >> Warning: the following items did not execute (for bug-buddy): >> org.macports.destroot org.macports.configure org.macports.build >> DEBUG: >> Error: Unable to upgrade port: 1 >> 2. >> checking for scrollkeeper-config... no >> configure: error: Couldn't find scrollkeeper-config >> ./configure: line 26210: exit: please: numeric argument required >> ./configure: line 26210: exit: please: numeric argument required >> >> Warning: the following items did not execute (for gnome-applets): >> org.macports.destroot org.macports.configure org.macports.build >> DEBUG: >> Error: Unable to upgrade port: 1 >> 3. >> checking for scrollkeeper-config... no >> configure: error: Couldn't find scrollkeeper-config. Please install >> the >> scrollkeeper package >> >> Warning: the following items did not execute (for gnome-desktop): >> org.macports.destroot org.macports.configure org.macports.build >> DEBUG: >> Error: Unable to upgrade port: 1 >> macintosh:~ frstan$ >> 4. >> Making all in doc >> /bin/sh: scrollkeeper-config: command not found >> /bin/sh: scrollkeeper-config: command not found >> The file '/Templates/C/scrollkeeper_cl.xml' does not exist. >> Please check your ScrollKeeper installation. >> make[3]: *** [gnome-volume-control-C.omf] Error 1 >> make[2]: *** [all-recursive] Error 1 >> make[1]: *** [all-recursive] Error 1 >> make: *** [all] Error 2 >> >> Warning: the following items did not execute (for gnome-media): >> org.macports.destroot org.macports.build >> DEBUG: >> Error: Unable to upgrade port: 1 >> 5. >> Making all in it >> for file in gucharmap-it.omf; do \ >> scrollkeeper-preinstall >> /opt/local/share/gnome/help/gucharmap/it/gucharmap.xml ./$file >> $file.out; \ >> done >> /bin/sh: scrollkeeper-preinstall: command not found >> make[3]: [omf_timestamp] Error 127 (ignored) >> touch omf_timestamp >> Making all in ja >> for file in gucharmap-ja.omf; do \ >> scrollkeeper-preinstall >> /opt/local/share/gnome/help/gucharmap/ja/gucharmap.xml ./$file >> $file.out; \ >> done >> /bin/sh: scrollkeeper-preinstall: command not found >> make[3]: [omf_timestamp] Error 127 (ignored) >> touch omf_timestamp >> Making all in zh_CN >> for file in gucharmap-zh_CN.omf; do \ >> scrollkeeper-preinstall >> /opt/local/share/gnome/help/gucharmap/zh_CN/gucharmap.xml ./$file >> $file.out; >> \ >> done >> /bin/sh: scrollkeeper-preinstall: command not found >> make[3]: [omf_timestamp] Error 127 (ignored) >> touch omf_timestamp >> Making all in zh_TW >> for file in gucharmap-zh_TW.omf; do \ >> scrollkeeper-preinstall >> /opt/local/share/gnome/help/gucharmap/zh_TW/gucharmap.xml ./$file >> $file.out; >> \ >> done >> /bin/sh: scrollkeeper-preinstall: command not found >> make[3]: [omf_timestamp] Error 127 (ignored) >> touch omf_timestamp >> >> /snip/ >> >> install: gucharmap-it.omf.out: No such file or directory >> make[4]: *** [install-data-hook-omf] Error 71 >> make[3]: *** [install-data-am] Error 2 >> make[2]: *** [install-am] Error 2 >> make[1]: *** [install-recursive] Error 1 >> make: *** [install-recursive] Error 1 >> >> Warning: the following items did not execute (for gucharmap): >> org.macports.destroot >> DEBUG: >> Error: Unable to upgrade port: 1 >> >> 6. >> others (such as yelp) attempt to use scrollkeeper which fails but the >> install completes > > The current version of yelp breaks if scrollkeeper is installed. This > is a deliberate decision on the upstream maintainers of that package > for the GNOME project. They provide a package called rarian that is a > drop-in replacement for scrollkeeper with extended capabilities to > support internationalization needs, as scrollkeeper has not been > updated by its maintainers for a few years now. > >> Those are all I care to take time to bother to list. > > Did you perhaps bother to read the notes in the scrollkeeper port when > it aborts the installation, or bother to my original reply to your > message. The port named "rarian" is the port you want to use. Every > port that did depend on scrollkeeper (or on a port that depended on > scrollkeeper) no w depends on the port named "rarian" (or on a port > that depends on "rarian"). > > Every problem you list is the result of not having the port named > "rarian" installed. The scrollkeeper port is explicit: you should use > the port rarian instead of it. > >> And yes I did selfupdate and clean --all : I do those regularly. >> >> Im very disapointed with the lack of quality in the MacPorts system >> and its >> undepedability. > > ... > >> William Davis >> frstanATbellsouthDOTnet >> Mac OS X.5.2 Darwin 9.2.2 >> Xquartz 2.2.0 - (xorg-server 1.3.0-apple13) >> Mac Mini Intel Duo @ 1.86 GHz >> >> Mundus vult decepi, ego non >> >> > > > > -- > Randall Wood > randall.h.wood@alexandriasoftware.com > > "The rules are simple: The ball is round. The game lasts 90 minutes. > All the rest is just philosophy." And I find your presumption of ignorance of basics on my part instead of looking at the problem rather inept. macintosh:~ frstan$ port installed rarian The following ports are currently installed: rarian @0.8.0_0 (active) macintosh:~ frstan$ OF COURSE I HAD PREVIOUSLY INSTALLED RARIAN! What's your excuse going to be this time? William Davis frstanATbellsouthDOTnet Mac OS X.5.2 Darwin 9.2.2 Xquartz 2.2.0 - (xorg-server 1.3.0-apple13) Mac Mini Intel Duo @ 1.86 GHz Mundus vult decepi, ego non From guido.soranzio at gmail.com Sun Apr 6 23:59:48 2008 From: guido.soranzio at gmail.com (Guido Soranzio) Date: Sun Apr 6 23:58:24 2008 Subject: scrollkeeper In-Reply-To: <9E73F335-C690-4FB8-B749-9FBF269B6B5C@bellsouth.net> References: <51227A9E-9B73-4CE9-9B93-1F348D8F7029@bellsouth.net> <03E7F2BB-F7DB-4E33-A83B-B656CE329B00@bellsouth.net> <9E73F335-C690-4FB8-B749-9FBF269B6B5C@bellsouth.net> Message-ID: On Apr 7, 2008, at 8:20 AM, William Davis wrote: > > macintosh:~ frstan$ port installed rarian > The following ports are currently installed: > rarian @0.8.0_0 (active) > macintosh:~ frstan$ > > OF COURSE I HAD PREVIOUSLY INSTALLED RARIAN! Then "port contents rarian" should provide: Port rarian contains: /opt/local/bin/rarian-example /opt/local/bin/rarian-sk-config [...] /opt/local/bin/scrollkeeper-config /opt/local/bin/scrollkeeper-extract [...] /opt/local/bin/scrollkeeper-update [...] bug-buddy already use system "${prefix}/bin/scrollkeeper-update" instead of the simpler system "scrollkeeper-update" but this wouldn't be the cause of the error, since MacPorts assumes that ${prefix}/bin is in your $PATH. Please, investigate further and send us more logs through Trac (http://trac.macports.org/projects/macports/newticket): it's improbable that was "port upgrade" to have screwed your configuration. -Guido From wsiegrist at apple.com Mon Apr 7 00:04:46 2008 From: wsiegrist at apple.com (William Siegrist) Date: Mon Apr 7 00:04:17 2008 Subject: MacPorts.org infrastructure In-Reply-To: References: Message-ID: Apache 2.2 PHP 5.2 MySQL 5.0 The ports.php page is populated via the PortIndex2MySQL script which is in the jobs dir in the svn repo. Guide.macports is generated via a script from there too. -Bill On Apr 6, 2008, at 2:59 AM, Randall Wood wrote: > If I want to build a test environment that mimics the www.macports.org > server, what should I do? > > Clearly we are using php, mysql, and apache on that server, but what > versions are we using? What are the special scripts we are using? > > -- > Randall Wood > randall.h.wood@alexandriasoftware.com > > "The rules are simple: The ball is round. The game lasts 90 minutes. > All the rest is just philosophy." > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev ---- William Siegrist Mac OS Forge http://macosforge.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080407/21a556fd/smime.bin From frstan at bellsouth.net Mon Apr 7 00:10:24 2008 From: frstan at bellsouth.net (William Davis) Date: Mon Apr 7 00:08:56 2008 Subject: scrollkeeper In-Reply-To: References: <51227A9E-9B73-4CE9-9B93-1F348D8F7029@bellsouth.net> <03E7F2BB-F7DB-4E33-A83B-B656CE329B00@bellsouth.net> Message-ID: <0C4CB21E-3413-467B-93D4-BD3E67A8F556@bellsouth.net> On Apr 6, 2008, at 8:14 PM, Randall Wood wrote: >>>> >>> >>> There are no ports that depend on scrollkeeper. None. Every port >>> that >>> had a dependency on scrollkeeper now has a dependency on rarian. Try >>> >>> sudo port selfupdate ; sudo port clean --all all ; sudo port upgrade >> outdated >>> >>> and see if that helps. >>> >>> >>>> >>>> >>> >> >> 1. >> Using $(sysconfdir)/gconf/schemas as install directory for schema >> files >> checking for scrollkeeper-config... no >> configure: error: Couldn't find scrollkeeper-config >> ./configure: line 4586: exit: please: numeric argument required >> ./configure: line 4586: exit: please: numeric argument required >> >> Warning: the following items did not execute (for bug-buddy): >> org.macports.destroot org.macports.configure org.macports.build >> DEBUG: >> Error: Unable to upgrade port: 1 >> 2. >> checking for scrollkeeper-config... no >> configure: error: Couldn't find scrollkeeper-config >> ./configure: line 26210: exit: please: numeric argument required >> ./configure: line 26210: exit: please: numeric argument required >> >> Warning: the following items did not execute (for gnome-applets): >> org.macports.destroot org.macports.configure org.macports.build >> DEBUG: >> Error: Unable to upgrade port: 1 >> 3. >> checking for scrollkeeper-config... no >> configure: error: Couldn't find scrollkeeper-config. Please install >> the >> scrollkeeper package >> >> Warning: the following items did not execute (for gnome-desktop): >> org.macports.destroot org.macports.configure org.macports.build >> DEBUG: >> Error: Unable to upgrade port: 1 >> macintosh:~ frstan$ >> 4. >> Making all in doc >> /bin/sh: scrollkeeper-config: command not found >> /bin/sh: scrollkeeper-config: command not found >> The file '/Templates/C/scrollkeeper_cl.xml' does not exist. >> Please check your ScrollKeeper installation. >> make[3]: *** [gnome-volume-control-C.omf] Error 1 >> make[2]: *** [all-recursive] Error 1 >> make[1]: *** [all-recursive] Error 1 >> make: *** [all] Error 2 >> >> Warning: the following items did not execute (for gnome-media): >> org.macports.destroot org.macports.build >> DEBUG: >> Error: Unable to upgrade port: 1 >> 5. >> Making all in it >> for file in gucharmap-it.omf; do \ >> scrollkeeper-preinstall >> /opt/local/share/gnome/help/gucharmap/it/gucharmap.xml ./$file >> $file.out; \ >> done >> /bin/sh: scrollkeeper-preinstall: command not found >> make[3]: [omf_timestamp] Error 127 (ignored) >> touch omf_timestamp >> Making all in ja >> for file in gucharmap-ja.omf; do \ >> scrollkeeper-preinstall >> /opt/local/share/gnome/help/gucharmap/ja/gucharmap.xml ./$file >> $file.out; \ >> done >> /bin/sh: scrollkeeper-preinstall: command not found >> make[3]: [omf_timestamp] Error 127 (ignored) >> touch omf_timestamp >> Making all in zh_CN >> for file in gucharmap-zh_CN.omf; do \ >> scrollkeeper-preinstall >> /opt/local/share/gnome/help/gucharmap/zh_CN/gucharmap.xml ./$file >> $file.out; >> \ >> done >> /bin/sh: scrollkeeper-preinstall: command not found >> make[3]: [omf_timestamp] Error 127 (ignored) >> touch omf_timestamp >> Making all in zh_TW >> for file in gucharmap-zh_TW.omf; do \ >> scrollkeeper-preinstall >> /opt/local/share/gnome/help/gucharmap/zh_TW/gucharmap.xml ./$file >> $file.out; >> \ >> done >> /bin/sh: scrollkeeper-preinstall: command not found >> make[3]: [omf_timestamp] Error 127 (ignored) >> touch omf_timestamp >> >> /snip/ >> >> install: gucharmap-it.omf.out: No such file or directory >> make[4]: *** [install-data-hook-omf] Error 71 >> make[3]: *** [install-data-am] Error 2 >> make[2]: *** [install-am] Error 2 >> make[1]: *** [install-recursive] Error 1 >> make: *** [install-recursive] Error 1 >> >> Warning: the following items did not execute (for gucharmap): >> org.macports.destroot >> DEBUG: >> Error: Unable to upgrade port: 1 >> >> 6. >> others (such as yelp) attempt to use scrollkeeper which fails but the >> install completes > > The current version of yelp breaks if scrollkeeper is installed. This > is a deliberate decision on the upstream maintainers of that package > for the GNOME project. They provide a package called rarian that is a > drop-in replacement for scrollkeeper with extended capabilities to > support internationalization needs, as scrollkeeper has not been > updated by its maintainers for a few years now. > >> Those are all I care to take time to bother to list. > > Did you perhaps bother to read the notes in the scrollkeeper port when > it aborts the installation, or bother to my original reply to your > message. The port named "rarian" is the port you want to use. Every > port that did depend on scrollkeeper (or on a port that depended on > scrollkeeper) no w depends on the port named "rarian" (or on a port > that depends on "rarian"). > > Every problem you list is the result of not having the port named > "rarian" installed. The scrollkeeper port is explicit: you should use > the port rarian instead of it. > As I previously reported: I did (and still do) have rarian installed. and I can now add: 7. DEBUG: Executing proc-post-org.macports.activate-activate-0 DEBUG: Updating scrollkeeper database... sh: /opt/local/bin/scrollkeeper-update: No such file or directory Error: Target org.macports.activate returned: shell command "/opt/ local/bin/scrollkeeper-update" returned error 127 Command output: sh: /opt/local/bin/scrollkeeper-update: No such file or directory Warning: the following items did not execute (for gtk-doc): org.macports.activate macintosh:~ frstan$ William Davis frstanATbellsouthDOTnet Mac OS X.5.2 Darwin 9.2.2 Xquartz 2.2.0 - (xorg-server 1.3.0-apple13) Mac Mini Intel Duo @ 1.86 GHz Mundus vult decepi, ego non From guido.soranzio at gmail.com Mon Apr 7 00:25:30 2008 From: guido.soranzio at gmail.com (Guido Soranzio) Date: Mon Apr 7 00:24:04 2008 Subject: scrollkeeper In-Reply-To: <0C4CB21E-3413-467B-93D4-BD3E67A8F556@bellsouth.net> References: <51227A9E-9B73-4CE9-9B93-1F348D8F7029@bellsouth.net> <03E7F2BB-F7DB-4E33-A83B-B656CE329B00@bellsouth.net> <0C4CB21E-3413-467B-93D4-BD3E67A8F556@bellsouth.net> Message-ID: <32EAF10B-6505-42AA-963D-25DE698DE5B2@gmail.com> On Apr 7, 2008, at 9:10 AM, William Davis wrote: > > As I previously reported: I did (and still do) have rarian installed. Have you already tried to reinstall it with "sudo port -f uninstall rarian ; sudo port install rarian" ? -Guido From randall.h.wood at alexandriasoftware.com Mon Apr 7 01:08:50 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Mon Apr 7 01:07:22 2008 Subject: scrollkeeper In-Reply-To: <32EAF10B-6505-42AA-963D-25DE698DE5B2@gmail.com> References: <51227A9E-9B73-4CE9-9B93-1F348D8F7029@bellsouth.net> <03E7F2BB-F7DB-4E33-A83B-B656CE329B00@bellsouth.net> <0C4CB21E-3413-467B-93D4-BD3E67A8F556@bellsouth.net> <32EAF10B-6505-42AA-963D-25DE698DE5B2@gmail.com> Message-ID: On Mon, Apr 7, 2008 at 3:25 AM, Guido Soranzio wrote: > On Apr 7, 2008, at 9:10 AM, William Davis wrote: > > > > > As I previously reported: I did (and still do) have rarian installed. > > > > > Have you already tried to reinstall it with > > "sudo port -f uninstall rarian ; sudo port install rarian" ? I think I might understand the problem now. At some point port may have attempted to activate, and been blocked by the then active scrollkeeper port. Upgrading scrollkeeper may have deactivated scrollkeeper without activating rarian, leading to the empty state that William saw. Is rarian active? If "port list active | grep rarian" does not return "rarian @0.8.0 textproc/rarian" then a "sudo port activate rarian" should do the trick. > -Guido > -- Randall Wood randall.h.wood@alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From frstan at bellsouth.net Mon Apr 7 07:46:12 2008 From: frstan at bellsouth.net (William Davis) Date: Mon Apr 7 07:44:44 2008 Subject: scrollkeeper In-Reply-To: References: <51227A9E-9B73-4CE9-9B93-1F348D8F7029@bellsouth.net> <03E7F2BB-F7DB-4E33-A83B-B656CE329B00@bellsouth.net> <0C4CB21E-3413-467B-93D4-BD3E67A8F556@bellsouth.net> <32EAF10B-6505-42AA-963D-25DE698DE5B2@gmail.com> Message-ID: <4D1A7AA6-7A06-4538-8EA2-9A3333E47108@bellsouth.net> On Apr 7, 2008, at 4:08 AM, Randall Wood wrote: > On Mon, Apr 7, 2008 at 3:25 AM, Guido Soranzio > wrote: >> On Apr 7, 2008, at 9:10 AM, William Davis wrote: >> >>> >>> As I previously reported: I did (and still do) have rarian >>> installed. >>> >> >> >> Have you already tried to reinstall it with >> >> "sudo port -f uninstall rarian ; sudo port install rarian" ? > > I think I might understand the problem now. At some point port may > have attempted to activate, and been blocked by the then active > scrollkeeper port. Upgrading scrollkeeper may have deactivated > scrollkeeper without activating rarian, leading to the empty state > that William saw. > > Is rarian active? If "port list active | grep rarian" does not return > "rarian @0.8.0 textproc/rarian" then a "sudo port activate rarian" > should do the trick. > >> -Guido >> > > > > -- > Randall Wood > randall.h.wood@alexandriasoftware.com > > "The rules are simple: The ball is round. The game lasts 90 minutes. > All the rest is just philosophy." macintosh:~ frstan$ port list active | grep rarian rarian @0.8.0 textproc/rarian macintosh:~ frstan$ and I previously reported: macintosh:~ frstan$ port installed rarian The following ports are currently installed: rarian @0.8.0_0 (active) macintosh:~ frstan$ which runs somewhat faster btw. ok,I tried Guido's suggestion and uninstalled (-f) rarian and reinstalled it. Now both bug-buddy and gnome-applets upgrade ok! THANK YOU GUIDO :D I'll go on with my upgrades of the other 5 programs I previously reported but so far this does seem to fix the problem. Im sorry to have been so "persnickkidy" Randall. I know you do a LOT of work for the MacPorts system, and I appreciate that. Still and all, can you imagine how frustrated I felt when after doing "what I was told to do" suddenly program after program would not upgrade AND the path back to the old system was blocked? AND nobody seemed to believe there was a real problem? best regards William Davis frstanATbellsouthDOTnet Mac OS X.5.2 Darwin 9.2.2 Xquartz 2.2.0 - (xorg-server 1.3.0-apple13) Mac Mini Intel Duo @ 1.86 GHz Mundus vult decepi, ego non From ryandesign at macports.org Mon Apr 7 11:15:34 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Apr 7 11:16:08 2008 Subject: [35801] trunk/dports/lang/slime/Portfile In-Reply-To: <20080406203133.728ED1561B56@beta.macosforge.org> References: <20080406203133.728ED1561B56@beta.macosforge.org> Message-ID: <1A3831E6-9A0F-4BD9-855E-1DA8552E8C38@macports.org> On Apr 6, 2008, at 15:31, easieste@macports.org wrote: > Revision: 35801 > http://trac.macosforge.org/projects/macports/changeset/35801 > Author: easieste@macports.org > Date: 2008-04-06 13:31:33 -0700 (Sun, 06 Apr 2008) > > Log Message: > ----------- > Updated SLIME to 20080404 with the following changes: > > Adding 'app' variant to build SLIME against editors/emacs-app > > > Default variant is 'sbcl'. > > Moved setup code from 'configure' to 'platform darwin' (#macports > jmr_mp) > > Updated post-activate message. > > Check for emacs binary to actually byte compile *.el files. In the future could you please make functional changes separately from whitespace changes? That way we have a chance of understanding what functional changes were made, by looking at the diff. Also, one of your recent changes (possibly "Moved setup code from 'configure' to 'platform darwin' (#macports jmr_mp)") has broken the port. It now does this: $ port info slime Error: Error executing darwin: Registry error: emacs not registered as installed. Error: Unable to open port: Error evaluating variants $ This is also blowing up the PortIndex process, therefore the port is (automatically) no longer being included in the PortIndex until this is fixed. From ryandesign at macports.org Mon Apr 7 11:19:13 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Apr 7 11:20:02 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <47F40F19.6090402@macports.org> References: <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> <47F116FB.6080303@macports.org> <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> <5cbbe4ae0804010127ie90be62i74c67daf8a48fc8@mail.gmail.com> <117C1FF8-51ED-436C-A3BF-2EC6CBB753F0@apple.com> <20080402165038.GB42614@darkart.com> <47F40F19.6090402@macports.org> Message-ID: <1EB953DF-7206-413F-8CE9-AD9A45615DB6@macports.org> On Apr 2, 2008, at 17:56, Rainer M?ller wrote: > Eric Hall wrote: > >> I've always thought this was an excellent idea, it neatly >> solves conflicting version problems (libnet for example) and allows >> a new version of $THIS_DEPENDENCY to be installed without breaking >> $OTHER_SOFTWARE that's linked against >> $OLDER_VERSION_OF_THIS_DEPENDENCY, >> and/or resulting in the massive rebuild fsck to bring everything back >> to happyness when a dependency is upgraded. > > I think it is a horrible idea. It totally defeats the feature of > having multiple versions of a port but only one active version. > > If you start linking into the depot, also rewrite all calls to > binaries to the depot and all access to /opt/local/share and so on. > Otherwise it would totally become inconsistent. And I don't > understand why you want to look for such files inside the depot. > The depot stores multiple versions and you activate one and only > one of them - the others are inactive and not used at all. > > - If I deactivate a port, I *expect* depending ports to break. > Of course a port will no longer work if a dependency is not active. > - If I upgrade a port, of course I might also have to rebuild > depending > ports, because the installed library changed. > - If I uninstall an inactive port, I expect it to be *safe* because it > is not used. > > Please tell me what advantage you want to achieve with this? I believe we are trying to find a way to allow multiple versions of a single port to be active and in use at the same time. So far I haven't formed an opinion on whether we should do this, or whether the method described above is the best way to do it. From ryandesign at macports.org Mon Apr 7 11:37:13 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Apr 7 11:40:05 2008 Subject: Multiple versions of a port at the same time Message-ID: <9BE6C9D0-291F-481A-A594-8359987649F4@macports.org> Some thoughts related to those being expressed in the "Re: Ticket #14796 (pike): please commit" thread... Assume we have a way to install multiple versions of a port at the same time. Assume we've worked out everything about the directory layout and allowing other software to link with things properly. How do we express multiple versions of the software in the portfile? The problem with simply going back to older versions of the portfile is that there may be bugs in old versions of the portfile which were fixed in later versions. But there may also be (for example) configure options which were appropriate for old versions but not for new ones, or vice-versa. Other things may change as well. So we also can't just use the newer version of the portfile and swap out the version number. Consider cairo: version 1.5 and later depend on libpixman, while earlier versions don't. What *is* the goal of this exercise? Is it to allow any arbitrary (maintainer-approved) version of a port to be installed? Or are we just trying to allow the major versions to be installed, which we already have with separate ports? If the latter, we could find a way to combine multiple ports like apache and apache2; php4 and php5; mysql3, mysql4 and mysql5. For example, we might keep the separate portfiles for each version and just place them in a common directory: dports/ databases/ mysql/ mysql3.port (installs 3.23.58) mysql4.port (installs 4.1.22) mysql5.port (installs 5.0.51) From ryandesign at macports.org Mon Apr 7 11:40:02 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Apr 7 11:46:14 2008 Subject: [35801] trunk/dports/lang/slime/Portfile In-Reply-To: <1A3831E6-9A0F-4BD9-855E-1DA8552E8C38@macports.org> References: <20080406203133.728ED1561B56@beta.macosforge.org> <1A3831E6-9A0F-4BD9-855E-1DA8552E8C38@macports.org> Message-ID: <0FADBAB8-D693-4FAA-9BAA-2E922F22437A@macports.org> On Apr 7, 2008, at 13:15, Ryan Schmidt wrote: > On Apr 6, 2008, at 15:31, easieste@macports.org wrote: > >> Revision: 35801 >> http://trac.macosforge.org/projects/macports/changeset/ >> 35801 >> Author: easieste@macports.org >> Date: 2008-04-06 13:31:33 -0700 (Sun, 06 Apr 2008) >> >> Log Message: >> ----------- >> Updated SLIME to 20080404 with the following changes: >> >> Adding 'app' variant to build SLIME against editors/emacs-app >> >> >> Default variant is 'sbcl'. >> >> Moved setup code from 'configure' to 'platform darwin' (#macports >> jmr_mp) >> >> Updated post-activate message. >> >> Check for emacs binary to actually byte compile *.el files. > > In the future could you please make functional changes separately > from whitespace changes? That way we have a chance of understanding > what functional changes were made, by looking at the diff. > > Also, one of your recent changes (possibly "Moved setup code from > 'configure' to 'platform darwin' (#macports jmr_mp)") has broken > the port. It now does this: > > $ port info slime > Error: Error executing darwin: Registry error: emacs not registered > as installed. > Error: Unable to open port: Error evaluating variants > $ > > This is also blowing up the PortIndex process, therefore the port > is (automatically) no longer being included in the PortIndex until > this is fixed. Also, are you the maintainer of this port, or were the changes approved by the maintainer, or did the maintainer not respond within 72 hours? From ryandesign at macports.org Mon Apr 7 14:09:42 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Apr 7 14:16:43 2008 Subject: [35820] trunk/dports/mail/mutt-devel/Portfile In-Reply-To: <20080407135032.A17B21565900@beta.macosforge.org> References: <20080407135032.A17B21565900@beta.macosforge.org> Message-ID: On Apr 7, 2008, at 08:50, simon@macports.org wrote: > mail/mutt-devel: Use the correct patch for the nntp variant. > - patchfiles-append patch-1.5.17.rr.compressed.gz > - checksums-append patch-1.5.17.rr.compressed.gz md5 \ > - 4f8edaa937d308d80f0f585b1c7fe47c > + patchfiles-append patch-1.5.17.vvv.nntp.gz > + checksums-append patch-1.5.17.vvv.nntp.gz md5 \ > + 42945bbe500e8e016d6760a05fd2e8ed What is the difference between the old and new patches? From ryandesign at macports.org Mon Apr 7 14:16:28 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Apr 7 14:16:48 2008 Subject: [35796] trunk/dports/net/fragroute/Portfile In-Reply-To: <20080406195356.8FFC91561831@beta.macosforge.org> References: <20080406195356.8FFC91561831@beta.macosforge.org> Message-ID: On Apr 6, 2008, at 14:53, pmq@macports.org wrote: > Fix the mtree violation. > +configure.args --mandir=${prefix}/share/man And since this changes where files get installed by the port, you should increment the port's revision. I did so in r35830. From raimue at macports.org Mon Apr 7 14:49:50 2008 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Mon Apr 7 14:48:19 2008 Subject: [35831] trunk/dports In-Reply-To: <20080407213248.9AAAA1569DB0@beta.macosforge.org> References: <20080407213248.9AAAA1569DB0@beta.macosforge.org> Message-ID: <47FA96FE.50601@macports.org> ryandesign@macports.org wrote: > Revision: 35831 > http://trac.macosforge.org/projects/macports/changeset/35831 > Author: ryandesign@macports.org > Date: 2008-04-07 14:32:47 -0700 (Mon, 07 Apr 2008) > > Log Message: > ----------- > Set svn:keywords to Id on all Portfiles per current guidelines I may remind all committers to set up your svn client according to the guidelines. See [1] for more. Bill, couldn't we install a pre-commit hook which rejects addition of Portfiles without the required properties? Should be possible with a pre-commit hook. Rainer [1] http://trac.macosforge.org/projects/macports/wiki/CommittersTipsAndTricks#SetsvnpropertiesautomaticallyonnewPortfiles From ryandesign at macports.org Mon Apr 7 15:22:19 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Apr 7 15:21:40 2008 Subject: [35831] trunk/dports In-Reply-To: <47FA96FE.50601@macports.org> References: <20080407213248.9AAAA1569DB0@beta.macosforge.org> <47FA96FE.50601@macports.org> Message-ID: On Apr 7, 2008, at 16:49, Rainer M?ller wrote: > ryandesign@macports.org wrote: >> Revision: 35831 >> http://trac.macosforge.org/projects/macports/changeset/ >> 35831 >> Author: ryandesign@macports.org >> Date: 2008-04-07 14:32:47 -0700 (Mon, 07 Apr 2008) >> Log Message: >> ----------- >> Set svn:keywords to Id on all Portfiles per current guidelines > > I may remind all committers to set up your svn client according to > the guidelines. See [1] for more. > > Bill, couldn't we install a pre-commit hook which rejects addition > of Portfiles without the required properties? Should be possible > with a pre-commit hook. Yes, that request was filed a long time ago, and I have a mostly- working pre-commit hook written, but it had one bug, so I didn't attach it to the ticket yet. It also needs to be fixed to take out the lint-like features I had in there (before we had a port lint feature). I'll fix it up and attach it soon. I won't get to it until the end of this week at the earliest, however. http://trac.macosforge.org/projects/macports/ticket/12594 > Rainer > > [1] http://trac.macosforge.org/projects/macports/wiki/ > CommittersTipsAndTricks#SetsvnpropertiesautomaticallyonnewPortfiles From evenson at panix.com Mon Apr 7 23:51:06 2008 From: evenson at panix.com (Mark Evenson) Date: Mon Apr 7 23:50:01 2008 Subject: [35801] trunk/dports/lang/slime/Portfile In-Reply-To: <1A3831E6-9A0F-4BD9-855E-1DA8552E8C38@macports.org> References: <20080406203133.728ED1561B56@beta.macosforge.org> <1A3831E6-9A0F-4BD9-855E-1DA8552E8C38@macports.org> Message-ID: <47FB15DA.5090502@panix.com> Ryan Schmidt wrote: [...] > In the future could you please make functional changes separately from > whitespace changes? That way we have a chance of understanding what > functional changes were made, by looking at the diff. Acknowledged. The Portfile had so many accumulated changes *and* the Portfile had changed radically since I originally wrote the port (in 2006?), that I pushed everything together. Ticket [14136][1] has most of the blow by blow if you wish to construct. [1]: http://trac.macosforge.org/projects/macports/ticket/14136 > Also, one of your recent changes (possibly "Moved setup code from > 'configure' to 'platform darwin' (#macports jmr_mp)") has broken the > port. It now does this: I could use advice on how to move that code into a "global" section. Eventually all those variables should be moved into a "Emacsen" section of the base system, but for now, I was just trying to setup everything in one place in the Portfile. I originally had that block in 'configure', but that had the property that osx$ sudo port build slime osx$ sudo port install slime would fail. Any advice on where I can put such a section that is always invoked when the Portfile is parsed. I need to dig through the base macports code more to understand how TCL is interpolating the Portfile, but pointers from the more knowledgable would be helpful. > $ port info slime > Error: Error executing darwin: Registry error: emacs not registered as > installed. > Error: Unable to open port: Error evaluating variants > $ > > This is also blowing up the PortIndex process, therefore the port is > (automatically) no longer being included in the PortIndex until this is > fixed. Mea culpa. How do I run the PortIndex process manually to verify my fix? Mark From evenson at panix.com Mon Apr 7 23:51:50 2008 From: evenson at panix.com (Mark Evenson) Date: Mon Apr 7 23:53:32 2008 Subject: [35801] trunk/dports/lang/slime/Portfile In-Reply-To: <0FADBAB8-D693-4FAA-9BAA-2E922F22437A@macports.org> References: <20080406203133.728ED1561B56@beta.macosforge.org> <1A3831E6-9A0F-4BD9-855E-1DA8552E8C38@macports.org> <0FADBAB8-D693-4FAA-9BAA-2E922F22437A@macports.org> Message-ID: <47FB1606.6030004@panix.com> Ryan Schmidt wrote: > > > Also, are you the maintainer of this port, or were the changes approved > by the maintainer, or did the maintainer not respond within 72 hours? > I am the maintainer of the port. From randall.h.wood at alexandriasoftware.com Tue Apr 8 01:53:02 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Tue Apr 8 01:51:29 2008 Subject: Fwd: [MacPorts] #12966: BUG: avahi cannot find Python module gtk In-Reply-To: <058.e9a1a7a2ec356174c7be2df2dc94dcb6@macosforge.org> References: <049.59533c445b54f377e83a94fdf9b4e7f6@macosforge.org> <058.e9a1a7a2ec356174c7be2df2dc94dcb6@macosforge.org> Message-ID: Does someone want to reach out to this person? ---------- Forwarded message ---------- From: MacPorts Date: Mon, Apr 7, 2008 at 6:30 PM Subject: Re: [MacPorts] #12966: BUG: avahi cannot find Python module gtk To: vinc17@macports.org, rhwood@macports.org Cc: macports-tickets@lists.macosforge.org, amgine@saewyc.net #12966: BUG: avahi cannot find Python module gtk ----------------------------------+----------------------------------------- Reporter: vinc17@macports.org | Owner: rhwood@macports.org Type: defect | Status: reopened Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.5.2 Resolution: | Keywords: ----------------------------------+----------------------------------------- Comment (by amgine@saewyc.net): I've given up on using macports with Leopard. Can't help. -- Ticket URL: MacPorts Ports system for Mac OS -- Randall Wood randall.h.wood@alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From randall.h.wood at alexandriasoftware.com Tue Apr 8 02:05:22 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Tue Apr 8 02:03:48 2008 Subject: [MacPorts] #12966: BUG: avahi cannot find Python module gtk In-Reply-To: References: <049.59533c445b54f377e83a94fdf9b4e7f6@macosforge.org> <058.e9a1a7a2ec356174c7be2df2dc94dcb6@macosforge.org> Message-ID: On Tue, Apr 8, 2008 at 4:53 AM, Randall Wood wrote: > Does someone want to reach out to this person? I have reached out to this individual in separate and personal email. > ---------- Forwarded message ---------- > From: MacPorts > Date: Mon, Apr 7, 2008 at 6:30 PM > Subject: Re: [MacPorts] #12966: BUG: avahi cannot find Python module gtk > To: vinc17@macports.org, rhwood@macports.org > Cc: macports-tickets@lists.macosforge.org, amgine@saewyc.net > > > #12966: BUG: avahi cannot find Python module gtk > ----------------------------------+----------------------------------------- > Reporter: vinc17@macports.org | Owner: rhwood@macports.org > Type: defect | Status: reopened > Priority: Normal | Milestone: Port Bugs > Component: ports | Version: 1.5.2 > Resolution: | Keywords: > ----------------------------------+----------------------------------------- > Comment (by amgine@saewyc.net): > > I've given up on using macports with Leopard. Can't help. > > -- > Ticket URL: > MacPorts > Ports system for Mac OS > > > > -- > Randall Wood > randall.h.wood@alexandriasoftware.com > > "The rules are simple: The ball is round. The game lasts 90 minutes. > All the rest is just philosophy." > -- Randall Wood randall.h.wood@alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From guido.soranzio at gmail.com Tue Apr 8 02:18:13 2008 From: guido.soranzio at gmail.com (Guido Soranzio) Date: Tue Apr 8 02:16:45 2008 Subject: [MacPorts] #12966: BUG: avahi cannot find Python module gtk In-Reply-To: References: <049.59533c445b54f377e83a94fdf9b4e7f6@macosforge.org> <058.e9a1a7a2ec356174c7be2df2dc94dcb6@macosforge.org> Message-ID: On Apr 8, 2008, at 10:53 AM, Randall Wood wrote: > Does someone want to reach out to this person? This problem has been solved some months ago and it is due to the new Apple's libtool in Leopard. I applied a simple workaround to many python ports whose makefiles make use of the flag "-export-symbol-regex" by simply removing it and so making the missing symbols public again. This rough trick works also with apache2 and the missing symbol "_ssl_cmd_SSLCACertificateFile" (http://trac.macports.org/projects/macports/ticket/13182) but it has not been committed. pogma is reporting on his blog that using the new libtool 1.5.26 instread of the Apple's one can alleviate such troubles: . -Guido From randall.h.wood at alexandriasoftware.com Tue Apr 8 02:23:43 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Tue Apr 8 02:22:12 2008 Subject: [MacPorts] #12966: BUG: avahi cannot find Python module gtk In-Reply-To: References: <049.59533c445b54f377e83a94fdf9b4e7f6@macosforge.org> <058.e9a1a7a2ec356174c7be2df2dc94dcb6@macosforge.org> Message-ID: Thanks! On Tue, Apr 8, 2008 at 5:18 AM, Guido Soranzio wrote: > On Apr 8, 2008, at 10:53 AM, Randall Wood wrote: > > > > Does someone want to reach out to this person? > > > > This problem has been solved some months ago and it is > due to the new Apple's libtool in Leopard. > > I applied a simple workaround to many python ports > whose makefiles make use of the flag "-export-symbol-regex" > by simply removing it and so making the missing symbols > public again. > > > This rough trick works also with apache2 and the missing > symbol "_ssl_cmd_SSLCACertificateFile" > (http://trac.macports.org/projects/macports/ticket/13182) > but it has not been committed. > > > pogma is reporting on his blog that using the new libtool > 1.5.26 instread of the Apple's one can alleviate such troubles: > . > > > -Guido > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev > -- Randall Wood randall.h.wood@alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From jstrine at vexate.net Tue Apr 8 06:20:43 2008 From: jstrine at vexate.net (Jonathan Strine) Date: Tue Apr 8 06:19:17 2008 Subject: Commit request for ticket 14955 (libelf) Message-ID: Libelf has been updated according to ticket 14955. This ticket includes libelf-Portfile.2.diff which fixes the problem as it relates to libelf. The libelf port is ready to have that diff committed. Ticket 14955 should remain open, however, as it also requests a patch be made to ghc. -- Jonathan Strine PGP Key ID: 0x0A02201C From codeshepherd at gmail.com Tue Apr 8 15:54:39 2008 From: codeshepherd at gmail.com (Deepan Chakravarthy) Date: Tue Apr 8 15:53:14 2008 Subject: mysql error Message-ID: <47FBF7AF.8090701@gmail.com> Hi All, I installed mysql5 using ports using the following command #port install mysql5 +server #/opt/local/bin/mysql_install_db5 now when I try to start mysql I get the following error. CodeShed:var root# /opt/local/share/mysql5/mysql/mysql.server start Starting MySQL /opt/local/share/mysql5/mysql/mysql.server: line 159: kill: (75848) - No such process ERROR! -- Deepan Sudoku Solver http://www.sudoku-solver.net/ From guglielmo.celata at gmail.com Tue Apr 8 16:36:22 2008 From: guglielmo.celata at gmail.com (guglielmo.celata) Date: Tue Apr 8 16:34:50 2008 Subject: Port sqlite build error: Message-ID: <16537424.post@talk.nabble.com> I have the same issues, while installing sqlite3. The problem seems to be that the Makefile is not written correctly (the NAWK variable is not assigned any value). I have tried to compile manually ./configure make and then resume the installation with port install sqlite the installation went through with some warnings: [Users/guglielmo] > install sqlite3 ---> Building sqlite3 with target all ---> Staging sqlite3 into destroot Warning: violation by /System Warning: violation by /usr Warning: sqlite3 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! ---> Installing sqlite3 3.5.7_0 ---> Activating sqlite3 3.5.7_0 ---> Cleaning sqlite3 Randall Wood-3 wrote: > > ---> Building sqlite3 with target all > Error: Target org.macports.build returned: shell command " cd > "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_sqlite3/work/sqlite-3.5.7" > && gnumake all " returned error 2 > Command output: sed -e s/--VERS--/3.5.7/ ./src/sqlite.h.in | \ > sed -e s/--VERSION-NUMBER--/3005007/ >sqlite3.h > /usr/bin/gcc-4.0 -O2 -o mkkeywordhash ./tool/mkkeywordhash.c > ./mkkeywordhash >keywordhash.h > /usr/bin/gcc-4.0 -O2 -o lemon ./tool/lemon.c > cp ./tool/lempar.c . > cp ./src/parse.y . > ./lemon parse.y > mv parse.h parse.h.temp > f ./addopcodes.awk parse.h.temp >parse.h > /bin/sh: f: command not found > gnumake: [parse.c] Error 127 (ignored) > cat parse.h ./src/vdbe.c | -f ./mkopcodeh.awk >opcodes.h > /bin/sh: -f: command not found > cat: stdout: Broken pipe > gnumake: *** [opcodes.h] Error 127 > > Error: The following dependencies failed to build: apache2 apr-util > sqlite3 > Error: Status 1 encountered during processing. > > See http://trac.macosforge.org/projects/macports/ticket/14938 > > -- > Randall Wood > randall.h.wood@alexandriasoftware.com > > "The rules are simple: The ball is round. The game lasts 90 minutes. > All the rest is just philosophy." > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev > > -- View this message in context: http://www.nabble.com/Port-sqlite-build-error%3A-tp16523464p16537424.html Sent from the MacPorts - Developer mailing list archive at Nabble.com. From dluke at geeklair.net Wed Apr 9 07:12:38 2008 From: dluke at geeklair.net (Daniel J. Luke) Date: Wed Apr 9 07:11:01 2008 Subject: Port sqlite build error: In-Reply-To: <16537424.post@talk.nabble.com> References: <16537424.post@talk.nabble.com> Message-ID: <1C18A9AD-9694-42C4-B93C-65441FF9070C@geeklair.net> On Apr 8, 2008, at 7:36 PM, guglielmo.celata wrote: > I have the same issues, while installing sqlite3. > The problem seems to be that the Makefile is not written correctly > (the NAWK > variable is not assigned any value). > > I have tried to compile manually > > ./configure > make you shouldn't do this. You've just re-configured sqlite to install outside of macports' $ {prefix} (/opt/local). > and then resume the installation with > > port install sqlite > > the installation went through with some warnings: > > [Users/guglielmo] > install sqlite3 > ---> Building sqlite3 with target all > ---> Staging sqlite3 into destroot > Warning: violation by /System > Warning: violation by /usr > Warning: sqlite3 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! > ---> Installing sqlite3 3.5.7_0 > ---> Activating sqlite3 3.5.7_0 > ---> Cleaning sqlite3 -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080409/c3e67703/PGP.bin From blair at orcaware.com Wed Apr 9 09:43:23 2008 From: blair at orcaware.com (Blair Zajac) Date: Wed Apr 9 09:41:58 2008 Subject: Upgrade and test Message-ID: <47FCF22B.9050903@orcaware.com> Currently I don't use the upgrade feature for two reasons and end up manually removing, building, testing and installing each port by hand: 1) Can't test the build before upgrading. Having 'port upgrade --test foo' would be nice. 2) It doesn't tell you about new variants and ask if you want them. Would this be something worth doing? I can open a ticket to log these ideads. Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies Subversion training, consulting and support http://www.orcaware.com/svn/ From dluke at geeklair.net Wed Apr 9 11:22:03 2008 From: dluke at geeklair.net (Daniel J. Luke) Date: Wed Apr 9 11:20:27 2008 Subject: Upgrade and test In-Reply-To: <47FCF22B.9050903@orcaware.com> References: <47FCF22B.9050903@orcaware.com> Message-ID: <1A6FE9C4-1323-4FBF-B18C-553C17A0C907@geeklair.net> On Apr 9, 2008, at 12:43 PM, Blair Zajac wrote: > Currently I don't use the upgrade feature for two reasons and end up > manually removing, building, testing and installing each port by hand: > > 1) Can't test the build before upgrading. Having 'port upgrade -- > test foo' would be nice. You could do port test foo && port upgrade foo if you wanted, but this might be a nice feature (and/or a conf setting to always run the test phase if it's available). > 2) It doesn't tell you about new variants and ask if you want them. port actions aren't interactive (this is a purposeful design decision), so getting something like that that requires interactive input would at a minimum require a special flag to be passed to port. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080409/9c6f8280/PGP.bin From simon at ruderich.com Wed Apr 9 14:18:47 2008 From: simon at ruderich.com (Simon Ruderich) Date: Wed Apr 9 14:16:54 2008 Subject: [35820] trunk/dports/mail/mutt-devel/Portfile In-Reply-To: References: Message-ID: <20080409211847.GA27792@ruderich.com> On Mon, Apr 07, 2008 at 04:09:42PM -0500, Ryan Schmidt wrote: > On Apr 7, 2008, at 08:50, simon@macports.org wrote: > >> mail/mutt-devel: Use the correct patch for the nntp variant. >> >> - patchfiles-append patch-1.5.17.rr.compressed.gz >> - checksums-append patch-1.5.17.rr.compressed.gz md5 \ >> - 4f8edaa937d308d80f0f585b1c7fe47c >> + patchfiles-append patch-1.5.17.vvv.nntp.gz >> + checksums-append patch-1.5.17.vvv.nntp.gz md5 \ >> + 42945bbe500e8e016d6760a05fd2e8ed > > What is the difference between the old and new patches? The old patch was adding support for using compressed mboxes instead of adding support for nntp. Simon -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080409/e26ff907/attachment.bin From randall.h.wood at alexandriasoftware.com Thu Apr 10 02:35:53 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Thu Apr 10 02:34:11 2008 Subject: scrollkeeper and rarian Message-ID: Everyone: Recently, the GNOME developers wrote a replacement for scrollkeeper named rarian. rarian is a drop-in replacement for scrollkeeper with the advantage of continuing active development and support as well as other under-the-hood improvements. Unfortunately, it has caused some problems on MacPorts, in that rarian and scrollkeeper conflict on our system. Here is a workaround: 1) make sure everything is update in the ports tree: sudo port sync 2) determine the state of these ports on your system: port installed rarian scrollkeeper If everything is as it should be, you'll see this: The following ports are currently installed: rarian @0.8.0_0 (active) scrollkeeper @0.3.14_6 or this: The following ports are currently installed: rarian @0.8.0_0 (active) or this: None of the specified ports are installed. 3) If you see anything other than those three statements, copy the following command to a terminal window and run it: sudo port -f uninstall scrollkeeper ; sudo port install rarian ; sudo port activate rarian NOTE: Once rarian is installed and active, scrollkeeper may be safely removed at any time -- Randall Wood randall.h.wood@alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From randall.h.wood at alexandriasoftware.com Thu Apr 10 02:38:19 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Thu Apr 10 02:36:41 2008 Subject: scrollkeeper and rarian In-Reply-To: References: Message-ID: This would have all just magically worked if bug 7361 was fixed. See http://svn.macosforge.org/projects/macports/ticket/7361 On Thu, Apr 10, 2008 at 5:35 AM, Randall Wood wrote: > Everyone: > > Recently, the GNOME developers wrote a replacement for scrollkeeper > named rarian. rarian is a drop-in replacement for scrollkeeper with > the advantage of continuing active development and support as well as > other under-the-hood improvements. > > Unfortunately, it has caused some problems on MacPorts, in that rarian > and scrollkeeper conflict on our system. Here is a workaround: > > 1) make sure everything is update in the ports tree: > > sudo port sync > > 2) determine the state of these ports on your system: > > port installed rarian scrollkeeper > > If everything is as it should be, you'll see this: > The following ports are currently installed: > rarian @0.8.0_0 (active) > scrollkeeper @0.3.14_6 > > or this: > The following ports are currently installed: > rarian @0.8.0_0 (active) > > or this: > None of the specified ports are installed. > > 3) If you see anything other than those three statements, copy the > following command to a terminal window and run it: > > sudo port -f uninstall scrollkeeper ; sudo port install rarian ; sudo > port activate rarian > > NOTE: Once rarian is installed and active, scrollkeeper may be safely > removed at any time > > -- > Randall Wood > randall.h.wood@alexandriasoftware.com > > "The rules are simple: The ball is round. The game lasts 90 minutes. > All the rest is just philosophy." > -- Randall Wood randall.h.wood@alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From blair at orcaware.com Fri Apr 11 06:07:34 2008 From: blair at orcaware.com (Blair Zajac) Date: Fri Apr 11 06:05:50 2008 Subject: Upgrade and test In-Reply-To: <1A6FE9C4-1323-4FBF-B18C-553C17A0C907@geeklair.net> References: <47FCF22B.9050903@orcaware.com> <1A6FE9C4-1323-4FBF-B18C-553C17A0C907@geeklair.net> Message-ID: <97EE7AF0-FD81-41F3-9204-75EE32A9CF38@orcaware.com> On Apr 9, 2008, at 11:22 AM, Daniel J. Luke wrote: > On Apr 9, 2008, at 12:43 PM, Blair Zajac wrote: >> Currently I don't use the upgrade feature for two reasons and end >> up manually removing, building, testing and installing each port by >> hand: >> >> 1) Can't test the build before upgrading. Having 'port upgrade -- >> test foo' would be nice. > > You could do port test foo && port upgrade foo if you wanted, but > this might be a nice feature (and/or a conf setting to always run > the test phase if it's available). The nice thing about upgrade is that it remembers your variants (at least I think it does) so if you have any, then you don't have to do port -v test foo +bar && port -v upgrade foo If you had a test option, then you could do port -v --test upgrade foo and it would use the +bar variant. Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies Subversion training, consulting and support http://www.orcaware.com/svn/ From raimue at macports.org Fri Apr 11 13:58:36 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri Apr 11 13:56:49 2008 Subject: Variant +universal broken in trunk Message-ID: <47FFD0FC.1020905@macports.org> Hi, Currently +universal is broken in trunk. I get the following error message: $ sudo port configure +universal Error: Error executing universal: can't read "configure.universal_cflags": can't read "configure.universal_target": no such variable Rainer From afb at macports.org Fri Apr 11 14:36:02 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Fri Apr 11 14:34:16 2008 Subject: Variant +universal broken in trunk In-Reply-To: <47FFD0FC.1020905@macports.org> References: <47FFD0FC.1020905@macports.org> Message-ID: <9BBE3B0D-9304-4D15-BA31-07DB8C46D87C@macports.org> Rainer M?ller wrote: > Currently +universal is broken in trunk. I get the following error > message: > > $ sudo port configure +universal > Error: Error executing universal: can't read > "configure.universal_cflags": can't read > "configure.universal_target": no such variable Hopefully fixed in r35970, gave no error here for some strange reason... --anders From raimue at macports.org Fri Apr 11 14:47:28 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri Apr 11 14:45:51 2008 Subject: Variant +universal broken in trunk In-Reply-To: <9BBE3B0D-9304-4D15-BA31-07DB8C46D87C@macports.org> References: <47FFD0FC.1020905@macports.org> <9BBE3B0D-9304-4D15-BA31-07DB8C46D87C@macports.org> Message-ID: <47FFDC70.1030200@macports.org> Anders F Bj?rklund wrote: > Hopefully fixed in r35970, gave no error here for some strange reason... Thanks, it works for me now. Maybe this could be due to a different Tcl version? I am on Leopard which comes with Tcl 8.4, but tclsh doesn't tell me the exact version (tried -h and --version, but no luck). Rainer From blb at macports.org Fri Apr 11 15:43:28 2008 From: blb at macports.org (Bryan Blackburn) Date: Fri Apr 11 15:41:43 2008 Subject: Variant +universal broken in trunk In-Reply-To: <47FFDC70.1030200@macports.org> References: <47FFD0FC.1020905@macports.org> <9BBE3B0D-9304-4D15-BA31-07DB8C46D87C@macports.org> <47FFDC70.1030200@macports.org> Message-ID: On Apr 11, 2008, at 3:47 PM, Rainer M?ller wrote: > Anders F Bj?rklund wrote: >> Hopefully fixed in r35970, gave no error here for some strange >> reason... > > Thanks, it works for me now. > > Maybe this could be due to a different Tcl version? I am on Leopard > which comes with Tcl 8.4, but tclsh doesn't tell me the exact > version (tried -h and --version, but no luck). > Use the tcl_patchLevel variable: $ echo 'puts $tcl_patchLevel' | tclsh My 10.5.2 says 8.4.7. Bryan > Rainer From raimue at macports.org Sat Apr 12 04:57:58 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat Apr 12 04:56:10 2008 Subject: [34977] trunk/base In-Reply-To: <47E1BAC7.6020807@macports.org> References: <20080313141352.0844714A0BA2@beta.macosforge.org> <47E1BAC7.6020807@macports.org> Message-ID: <4800A3C6.2040401@macports.org> Rainer M?ller wrote: > eridius@macports.org wrote: >> Revision >> 34977 >> Author >> eridius@macports.org >> Date >> 2008-03-13 07:13:51 -0700 (Thu, 13 Mar 2008) >> >> >> Log Message >> >> Add new --recursive option to port uninstall to uninstall dependents (#14637) > > I'm not quite happy with the name --recursive, because it does not imply > in which direction we recurse. I would rather propose something like > --with-dependents or --follow-dependents. Although this is longer, but > much more clear. > > We were also talking about 'recursive dependencies' before, especially > for 'port deps'. But in that case it was meant following dependencies, > not dependents. So --recursive might really lead to confusion here. > > In order to provide a consistent interface, we should define two options > for this. One for following dependencies and one for following > dependents. (And even one for doing both?) > > Currently, we also have the global -R und -n flags which are only used > by upgrade and -u which is used by uninstall and upgrade. In my opinion > these should not be global because they are only used by one or two > targets. Therefore these should use the same naming convention. Could we please find a better solution here before we branch off another release? Any reply appreciated. Rainer From wsiegrist at apple.com Sat Apr 12 11:01:40 2008 From: wsiegrist at apple.com (William Siegrist) Date: Sat Apr 12 11:01:17 2008 Subject: [34977] trunk/base In-Reply-To: <4800A3C6.2040401@macports.org> References: <20080313141352.0844714A0BA2@beta.macosforge.org> <47E1BAC7.6020807@macports.org> <4800A3C6.2040401@macports.org> Message-ID: On Apr 12, 2008, at 4:57 AM, Rainer M?ller wrote: > Rainer M?ller wrote: >> eridius@macports.org wrote: >>> Revision >>> 34977 >> > >>> Author >>> eridius@macports.org >>> Date >>> 2008-03-13 07:13:51 -0700 (Thu, 13 Mar 2008) >>> >>> >>> Log Message >>> >>> Add new --recursive option to port uninstall to uninstall >>> dependents (#14637) >> I'm not quite happy with the name --recursive, because it does not >> imply in which direction we recurse. I would rather propose >> something like --with-dependents or --follow-dependents. Although >> this is longer, but much more clear. >> We were also talking about 'recursive dependencies' before, >> especially for 'port deps'. But in that case it was meant following >> dependencies, not dependents. So --recursive might really lead to >> confusion here. >> In order to provide a consistent interface, we should define two >> options for this. One for following dependencies and one for >> following dependents. (And even one for doing both?) >> Currently, we also have the global -R und -n flags which are only >> used by upgrade and -u which is used by uninstall and upgrade. In >> my opinion these should not be global because they are only used by >> one or two targets. Therefore these should use the same naming >> convention. > > Could we please find a better solution here before we branch off > another release? Any reply appreciated. I can see a use for both directions, so I guess having options for both directions would be nice. But also a name like "follow- dependents" or "also-dependents" would be clearer. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080412/d5d2543a/smime.bin From ryandesign at macports.org Mon Apr 14 14:04:51 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon Apr 14 14:02:52 2008 Subject: mysql error In-Reply-To: <47FBF7AF.8090701@gmail.com> References: <47FBF7AF.8090701@gmail.com> Message-ID: <1A4436F9-95AE-4DFD-B9EA-9317549C36BF@macports.org> On Apr 8, 2008, at 5:54 PM, Deepan Chakravarthy wrote: > Hi All, > I installed mysql5 using ports using the following command > > #port install mysql5 +server > #/opt/local/bin/mysql_install_db5 > > now when I try to start mysql I get the following error. > > CodeShed:var root# /opt/local/share/mysql5/mysql/mysql.server start > Starting MySQL > /opt/local/share/mysql5/mysql/mysql.server: line 159: kill: (75848) > - No such process > ERROR! The correct way to start and stop mysql is to use the launchd plist. Instructions for using the launchctl command were printed when you installed the port. Check the logfile to see why the server won't start. From bruda at cs.ubishops.ca Wed Apr 16 07:29:45 2008 From: bruda at cs.ubishops.ca (Stefan Bruda) Date: Wed Apr 16 07:28:25 2008 Subject: [MacPorts] #14901: firefox-x11 does not provide file-selection browsers (fwd) In-Reply-To: References: Message-ID: <18438.3417.817101.546505@godel.local> Hi, Apologies for resurrecting this somehow old thread. I am using firefox-x11 all the time (I simply hate the Mac OS GUI and it's lack of sloppy focus so I am trying to stay under X as much as possible) and the lack of file browser annoys the heck out of me. This is a really long standing problem. I have also inquired on this list awhile ago but got no response. Other than the file browser (or lack thereof) the port works fine on my machine (MBP 2,2). At 18:37 -0400 on 2008-4-2 robert delius royar wrote: > > I recall from my own attempts to build SeaMonkey for Mac X11 that I > could not get it to link in the gnome-vfs components (listed as > required in the port file). It always insisted on trying to link > in the Carbon Looking at the port file, the firefox-x11 port does use gnome-vfs apparently. I have not watched the build process though. Instead, I tried (to tweak the configuration flags) to no effect. Have you made any attempt at this? If so, with what effect? I meant to try some more stuff in this respect (I also meant to answer this email earlier... ;-) ) but so far I did not quite find the time to do it right, I just poked around now and then (without any noticeable effect). > Ticket URL: > MacPorts > Ports system for Mac OS Cheers, Stefan -- If it was so, it might be; and if it were so, it would be; but as it isn't, it ain't. That's logic. --Lewis Carroll, Through the Looking-Glass From ryandesign at macports.org Wed Apr 16 08:52:03 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Apr 16 08:49:57 2008 Subject: [36059] trunk/dports/devel/mercurial/Portfile In-Reply-To: <20080416114549.AA34415A09F0@beta.macosforge.org> References: <20080416114549.AA34415A09F0@beta.macosforge.org> Message-ID: <17D5D0A4-AA19-48FA-9532-0AC9DDD61AC3@macports.org> On Apr 16, 2008, at 6:45 AM, deric@macports.org wrote: > Revision: 36059 > http://trac.macosforge.org/projects/macports/changeset/36059 > Author: deric@macports.org > Date: 2008-04-16 04:45:48 -0700 (Wed, 16 Apr 2008) > > Log Message: > ----------- > Add py25-bz2 to the dependency list as it's required by the mq > extension. Closes #15007. You should probably increase the port revision so that anybody who already had mercurial installed will get this update. From ryandesign at macports.org Wed Apr 16 08:53:39 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Apr 16 08:51:32 2008 Subject: [36060] trunk/dports/graphics/libguichan/Portfile In-Reply-To: <20080416131440.CBA5415A0FE7@beta.macosforge.org> References: <20080416131440.CBA5415A0FE7@beta.macosforge.org> Message-ID: <570A07D5-B304-4D36-9486-38EEB399B988@macports.org> On Apr 16, 2008, at 8:14 AM, jmr@macports.org wrote: > Revision: 36060 > http://trac.macosforge.org/projects/macports/changeset/36060 > Author: jmr@macports.org > Date: 2008-04-16 06:14:38 -0700 (Wed, 16 Apr 2008) > > Log Message: > ----------- > libguichan: update to 0.8.0, work around broken googlecode livecheck You also made a lot of whitespace changes that make it hard to see what actual substantive changes were made. Please, in the future, commit whitespace changes separately from functional changes. > Modified Paths: > -------------- > trunk/dports/graphics/libguichan/Portfile > > Modified: trunk/dports/graphics/libguichan/Portfile > =================================================================== > --- trunk/dports/graphics/libguichan/Portfile 2008-04-16 11:45:48 > UTC (rev 36059) > +++ trunk/dports/graphics/libguichan/Portfile 2008-04-16 13:14:38 > UTC (rev 36060) > @@ -1,28 +1,32 @@ > -# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: > nil; c-basic-offset: 4 -*- > vim:fenc=utf-8:filetype=tcl:et:sw=4:ts=4:sts=4 > +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: > nil; c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4 > # $Id$ > > PortSystem 1.0 > > -name libguichan > -version 0.7.1 > -categories graphics devel > -platforms darwin > -maintainers jmr \ > - openmaintainer > -description portable C++ GUI library designed for games using SDL > -long_description Guichan is a portable C++ GUI library designed for \ > - games using SDL and/or OpenGL. > +name libguichan > +version 0.8.0 > +categories graphics devel > +platforms darwin > +maintainers jmr openmaintainer > +description portable C++ GUI library designed for games using SDL > +long_description Guichan is a portable C++ GUI library designed > for \ > + games using SDL and/or OpenGL. > > -homepage http://guichan.sourceforge.net/ > -master_sites googlecode:guichan > -distname guichan-${version} > -checksums md5 275c5bad231d2ce55e654d80cb1e05be \ > - sha1 e08bed7d7638687f627bcf1a24e8ffa90913dacc \ > - rmd160 09cd4d102ae73c99759e97c0f9db247950b508af > +homepage http://guichan.sourceforge.net/ > +master_sites googlecode:guichan > +distname guichan-${version} > +checksums md5 29a03f05645b669fdc98ec2db5de13f5 \ > + sha1 5993e0a5e948b0f3e614025ff02f818bfe9c2198 \ > + rmd160 a8ab10d9c49542e018d688b9ee90ef2879f94a28 > > -depends_lib port:libsdl port:libsdl_image port:allegro > +depends_lib port:libsdl port:libsdl_image port:allegro > > -configure.args --enable-sdl --enable-sdl-image --enable-force-opengl > -configure.cflags-append "-I${prefix}/include" > -configure.cxxflags-append "-I${prefix}/include" > +configure.cppflags-append -I${x11prefix}/include > +configure.ldflags-append -L${x11prefix}/lib > use_parallel_build yes > + > +platform darwin 9 { > + configure.ldflags-append "-Wl,-dylib_file,/System/Library/ > Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/ > System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/ > libGL.dylib" > +} > + > +livecheck.regex guichan\\-(.*)[quotemeta ${extract.suffix}]\" From ryandesign at macports.org Wed Apr 16 09:03:21 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Apr 16 09:01:13 2008 Subject: [36031] trunk/dports/devel/bugzilla/Portfile In-Reply-To: <20080415054304.1A6CA1598D49@beta.macosforge.org> References: <20080415054304.1A6CA1598D49@beta.macosforge.org> Message-ID: > post-patch { > - cd ${worksrcpath} > + system "cd ${worksrcpath}" > foreach item [exec find . -type f -name .cvsignore] { > file delete -force ${item} > } > @@ -99,7 +107,7 @@ > > set docPath "${prefix}/share/doc/${name}" > xinstall -d -m 0755 ${destroot}${docPath} > - cd ${worksrcpath} > + system "cd ${worksrcpath}" > xinstall -m 0644 \ > README QUICKSTART UPGRADING UPGRADING-pre-2.8 \ > ${destroot}${docPath}/ That change isn't going to work, is it? I mean, the reason why the tcl "cd" command was deprecated is because we don't want portfiles changing the working directory. Using 'system "cd"' won't change the working directory, so e.g. the subsequent tcl "file delete" commands won't find the files to delete. To fix the post-patch phase, you'd have to "exec find ${worksrcpath} ..." instead. Haven't looked at the second bit. From blair at orcaware.com Wed Apr 16 09:19:39 2008 From: blair at orcaware.com (Blair Zajac) Date: Wed Apr 16 09:17:32 2008 Subject: libevent upgrades Message-ID: <4806271B.4080903@orcaware.com> Brett, When you bump a libevent version, please bump the revision number on all packages that depend upon it since they will need to be recompiled. Here's memcached after running with the libevent upgrade: $ /opt/local/bin/memcached --help dyld: Library not loaded: /Users/blair/my-macports/lib/libevent-1.3e.1.dylib Referenced from: /opt/local/bin/memcached Reason: image not found Trace/BPT trap I've bumped the revision number of memcached in r36063 to force a recompile. Regards, Blair From ryandesign at macports.org Wed Apr 16 09:22:27 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Apr 16 09:20:19 2008 Subject: [36013] trunk/dports/devel/libevent/Portfile In-Reply-To: <20080414114006.17F421594893@beta.macosforge.org> References: <20080414114006.17F421594893@beta.macosforge.org> Message-ID: <447DBF1B-18FA-4050-96C7-7FDCA4C8FE0A@macports.org> On Apr 14, 2008, at 6:40 AM, brett@macports.org wrote: > Revision: 36013 > http://trac.macosforge.org/projects/macports/changeset/36013 > Author: brett@macports.org > Date: 2008-04-14 04:40:01 -0700 (Mon, 14 Apr 2008) > > Log Message: > ----------- > update to 1.4.3 > > Modified Paths: > -------------- > trunk/dports/devel/libevent/Portfile > > Modified: trunk/dports/devel/libevent/Portfile > =================================================================== > --- trunk/dports/devel/libevent/Portfile 2008-04-14 11:26:53 UTC > (rev 36012) > +++ trunk/dports/devel/libevent/Portfile 2008-04-14 11:40:01 UTC > (rev 36013) > @@ -3,7 +3,7 @@ > PortSystem 1.0 > > name libevent > -version 1.3e > +version 1.4.3 > categories devel > maintainers brett@macports.org > description asynchronous event library > @@ -17,7 +17,9 @@ > homepage http://monkey.org/~provos/libevent/ > platforms darwin > master_sites http://monkey.org/~provos/ > -checksums sha1 67b064a4533c640dfb86e3d81c0cca9247427353 > +distfiles ${distname}-stable.tar.gz > +worksrcdir ${distname}-stable > +checksums sha1 222812fc8993823895567ea5de1dc16880b0fac6 Why did you change to downloading "libevent-stable.tar.gz"? You should continue to download a file whose name includes the version number, so that when the developer releases a newer version, MacPorts users don't start encountering checksum errors. From brett at macports.org Wed Apr 16 09:46:45 2008 From: brett at macports.org (Brett Eisenberg) Date: Wed Apr 16 09:44:59 2008 Subject: [36013] trunk/dports/devel/libevent/Portfile In-Reply-To: <447DBF1B-18FA-4050-96C7-7FDCA4C8FE0A@macports.org> References: <20080414114006.17F421594893@beta.macosforge.org> <447DBF1B-18FA-4050-96C7-7FDCA4C8FE0A@macports.org> Message-ID: <98CB6BC4-9A24-4309-9D6C-36CDEC9CC021@macports.org> Ryan, ${distname} includes the version number. best, Brett On Apr 16, 2008, at 12:22 , Ryan Schmidt wrote: > > Why did you change to downloading "libevent-stable.tar.gz"? You > should continue to download a file whose name includes the version > number, so that when the developer releases a newer version, > MacPorts users don't start encountering checksum errors. > From wsiegrist at apple.com Wed Apr 16 09:48:49 2008 From: wsiegrist at apple.com (William Siegrist) Date: Wed Apr 16 09:48:12 2008 Subject: [36031] trunk/dports/devel/bugzilla/Portfile In-Reply-To: References: <20080415054304.1A6CA1598D49@beta.macosforge.org> Message-ID: <9E67927B-39C9-4E88-8D0C-897D18A18D70@apple.com> On Apr 16, 2008, at 9:03 AM, Ryan Schmidt wrote: >> post-patch { >> - cd ${worksrcpath} >> + system "cd ${worksrcpath}" >> foreach item [exec find . -type f -name .cvsignore] { >> file delete -force ${item} >> } >> @@ -99,7 +107,7 @@ >> >> set docPath "${prefix}/share/doc/${name}" >> xinstall -d -m 0755 ${destroot}${docPath} >> - cd ${worksrcpath} >> + system "cd ${worksrcpath}" >> xinstall -m 0644 \ >> README QUICKSTART UPGRADING UPGRADING-pre-2.8 \ >> ${destroot}${docPath}/ > > That change isn't going to work, is it? I mean, the reason why the > tcl "cd" command was deprecated is because we don't want portfiles > changing the working directory. Using 'system "cd"' won't change the > working directory, so e.g. the subsequent tcl "file delete" commands > won't find the files to delete. To fix the post-patch phase, you'd > have to "exec find ${worksrcpath} ..." instead. Haven't looked at > the second bit. > > Thanks for catching that and explaining it. The correct fix wasnt clear to me so I tried to match what some other ports were doing. Please see my fix in r36065 and let me know if there's anything else I missed. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080416/e6ff3031/smime.bin From ryandesign at macports.org Wed Apr 16 09:53:05 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Apr 16 09:51:01 2008 Subject: [36013] trunk/dports/devel/libevent/Portfile In-Reply-To: <98CB6BC4-9A24-4309-9D6C-36CDEC9CC021@macports.org> References: <20080414114006.17F421594893@beta.macosforge.org> <447DBF1B-18FA-4050-96C7-7FDCA4C8FE0A@macports.org> <98CB6BC4-9A24-4309-9D6C-36CDEC9CC021@macports.org> Message-ID: <3B6585FC-04E9-46F0-BE01-A809DA387BB2@macports.org> Oh, yes, of course. Sorry! Carry on. On Apr 16, 2008, at 11:46 AM, Brett Eisenberg wrote: > Ryan, > > ${distname} includes the version number. > > best, > Brett > > > On Apr 16, 2008, at 12:22 , Ryan Schmidt wrote: >> Why did you change to downloading "libevent-stable.tar.gz"? You >> should continue to download a file whose name includes the version >> number, so that when the developer releases a newer version, >> MacPorts users don't start encountering checksum errors. From brett at macports.org Wed Apr 16 09:54:16 2008 From: brett at macports.org (Brett Eisenberg) Date: Wed Apr 16 09:52:06 2008 Subject: libevent upgrades In-Reply-To: <4806271B.4080903@orcaware.com> References: <4806271B.4080903@orcaware.com> Message-ID: Blair, Thanks. I presumed that depends_lib would track versions for static libraries, to maintain state. I was also unaware that dylibs are broken compared to normal shared libraries, live and learn. Noted, and I'll track down the rest of the dependencies. Bumping revisions manually in all dependent ports (possibly maintained by separate authors) seems broken. b On Apr 16, 2008, at 12:19 , Blair Zajac wrote: > Brett, > > When you bump a libevent version, please bump the revision number on > all packages that depend upon it since they will need to be > recompiled. > > Here's memcached after running with the libevent upgrade: > > $ /opt/local/bin/memcached --help > dyld: Library not loaded: /Users/blair/my-macports/lib/libevent-1.3e. > 1.dylib > Referenced from: /opt/local/bin/memcached > Reason: image not found > Trace/BPT trap > > I've bumped the revision number of memcached in r36063 to force a > recompile. > > Regards, > Blair > > > !DSPAM:48062721763465369021049! > From blair at orcaware.com Wed Apr 16 09:59:04 2008 From: blair at orcaware.com (Blair Zajac) Date: Wed Apr 16 09:57:03 2008 Subject: libevent upgrades In-Reply-To: References: <4806271B.4080903@orcaware.com> Message-ID: <48063058.1090001@orcaware.com> Brett, This is a dynamic library, the issue is that libevent renames the .dylib on each version upgrade. Maybe they change the ABI so this is a way to force dependents to recompile? I don't know off hand. The current shared library is named /Users/blair/my-macports/lib/libevent-1.4.2.dylib and binaries that use it end up with this name in the binary: $ otool -L /opt/local/bin/memcached /opt/local/bin/memcached: /opt/local/lib/libevent-1.4.2.dylib (compatibility version 3.0.0, current version 3.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.10) So an upgrade to libevent 1.4.3 presumably will remove that libevent-1.4.2.dylib file. I don't see how MacPorts should handle this problem gracefully. Agreed that it is a pain to update all dependents. Presumably a simple recursive grep should be enough to find them all. Regards, Blair Brett Eisenberg wrote: > Blair, > > Thanks. > > I presumed that depends_lib would track versions for static libraries, > to maintain state. I was also unaware that dylibs are broken compared to > normal shared libraries, live and learn. > > Noted, and I'll track down the rest of the dependencies. Bumping > revisions manually in all dependent ports (possibly maintained by > separate authors) seems broken. > > b > > On Apr 16, 2008, at 12:19 , Blair Zajac wrote: >> Brett, >> >> When you bump a libevent version, please bump the revision number on >> all packages that depend upon it since they will need to be recompiled. >> >> Here's memcached after running with the libevent upgrade: >> >> $ /opt/local/bin/memcached --help >> dyld: Library not loaded: >> /Users/blair/my-macports/lib/libevent-1.3e.1.dylib >> Referenced from: /opt/local/bin/memcached >> Reason: image not found >> Trace/BPT trap >> >> I've bumped the revision number of memcached in r36063 to force a >> recompile. >> >> Regards, >> Blair >> >> >> !DSPAM:48062721763465369021049! From brett at macports.org Wed Apr 16 10:05:11 2008 From: brett at macports.org (Brett Eisenberg) Date: Wed Apr 16 10:03:19 2008 Subject: libevent upgrades In-Reply-To: <48063058.1090001@orcaware.com> References: <4806271B.4080903@orcaware.com> <48063058.1090001@orcaware.com> Message-ID: <307FE346-FC03-4130-8D27-A5AC42CAB30B@macports.org> That makes sense. I'll get the dependents revisions updated, and for future releases see about patch libevent to embed the version information into the library. Apologies for the confusion. best, Brett On Apr 16, 2008, at 12:59 , Blair Zajac wrote: > Brett, > > This is a dynamic library, the issue is that libevent renames > the .dylib on each version upgrade. Maybe they change the ABI so > this is a way to force dependents to recompile? I don't know off > hand. > > The current shared library is named > > /Users/blair/my-macports/lib/libevent-1.4.2.dylib > > and binaries that use it end up with this name in the binary: > > $ otool -L /opt/local/bin/memcached > /opt/local/bin/memcached: > /opt/local/lib/libevent-1.4.2.dylib (compatibility version > 3.0.0, current version 3.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 88.3.10) > > So an upgrade to libevent 1.4.3 presumably will remove that > libevent-1.4.2.dylib file. > > I don't see how MacPorts should handle this problem gracefully. > > Agreed that it is a pain to update all dependents. Presumably a > simple recursive grep should be enough to find them all. > > Regards, > Blair > > Brett Eisenberg wrote: >> Blair, >> Thanks. >> I presumed that depends_lib would track versions for static >> libraries, to maintain state. I was also unaware that dylibs are >> broken compared to normal shared libraries, live and learn. >> Noted, and I'll track down the rest of the dependencies. Bumping >> revisions manually in all dependent ports (possibly maintained by >> separate authors) seems broken. >> b >> On Apr 16, 2008, at 12:19 , Blair Zajac wrote: >>> Brett, >>> >>> When you bump a libevent version, please bump the revision number >>> on all packages that depend upon it since they will need to be >>> recompiled. >>> >>> Here's memcached after running with the libevent upgrade: >>> >>> $ /opt/local/bin/memcached --help >>> dyld: Library not loaded: /Users/blair/my-macports/lib/ >>> libevent-1.3e.1.dylib >>> Referenced from: /opt/local/bin/memcached >>> Reason: image not found >>> Trace/BPT trap >>> >>> I've bumped the revision number of memcached in r36063 to force a >>> recompile. >>> >>> Regards, >>> Blair >>> >>> > > !DSPAM:4806305d829911890169363! > From jkh at apple.com Wed Apr 16 11:07:50 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Wed Apr 16 11:07:09 2008 Subject: [36031] trunk/dports/devel/bugzilla/Portfile In-Reply-To: References: <20080415054304.1A6CA1598D49@beta.macosforge.org> Message-ID: Doesn't xinstall have a way to change $CWD for its operations? That would work... On Apr 16, 2008, at 9:03 AM, Ryan Schmidt wrote: > That change isn't going to work, is it? I mean, the reason why the > tcl "cd" command was deprecated is because we don't want portfiles > changing the working directory. Using 'system "cd"' won't change the > working directory, so e.g. the subsequent tcl "file delete" commands > won't find the files to delete. To fix the post-patch phase, you'd > have to "exec find ${worksrcpath} ..." instead. Haven't looked at > the second bit. From opendarwin.org at darkart.com Wed Apr 16 12:13:03 2008 From: opendarwin.org at darkart.com (Eric Hall) Date: Wed Apr 16 12:11:02 2008 Subject: RFC: inverting @INC for perl5.{8,10} Message-ID: <20080416191303.GF1423@darkart.com> Macports perl installs use the default @INC [1], which can lead to problems if a perl module requires a newer version of a (perl) Core module than what shipped with that version of perl. One example is MIME::Tools, which requires File::Temp of 0.18 or greater (in 5.426, 5.425 requires File::Temp 0.17), perl 5.8.8 ships with File::Temp 0.16. Because this is a core module, and @INC is set to look there (${prefix}/lib/perl/5.8.8) before site_perl and vendor_perl, a macports installed File::Temp isn't used unless specific changes are made to every file that uses File::Temp. If we invert @INC so that vendor_perl and site_perl come before the core module location, macports installed modules will take precedence over core-installed modules, giving macports better control over what is installed. This is something that FreeBSD ports does [2], so its not a new idea. I don't know what negative impacts this has (I can imagine problems with core modules expecting to get an older version of another modules, dunno if that's a real problem or not), and I'd expect this would be exposed in FreeBSD if it is a real-world problem. Anyone see any other problems with this idea, and/or reasons we should not do this? -eric [1] perl 5.8.8 @INC is currently (sub ${prefix} for MP's prefix): @INC: ${prefix}/lib/perl5/5.8.8/darwin-thread-multi-2level ${prefix}/lib/perl5/5.8.8 ${prefix}/lib/perl5/site_perl/5.8.8/darwin-thread-multi-2level ${prefix}/lib/perl5/site_perl/5.8.8 ${prefix}/lib/perl5/site_perl ${prefix}/lib/perl5/vendor_perl/5.8.8/darwin-thread-multi-2level ${prefix}/lib/perl5/vendor_perl/5.8.8 ${prefix}/lib/perl5/vendor_perl . --- end --- [2]: perl 5.8.8 @INC as installed by FreeBSD ports, noe that site_perl comes before the core module location (/usr/local/lib/perl5/5.8.8): @INC: /usr/local/lib/perl5/5.8.8/BSDPAN /usr/local/lib/perl5/site_perl/5.8.8/mach /usr/local/lib/perl5/site_perl/5.8.8 /usr/local/lib/perl5/site_perl/5.8.7 /usr/local/lib/perl5/site_perl /usr/local/lib/perl5/5.8.8/mach /usr/local/lib/perl5/5.8.8 . --- end --- On Sat, Dec 22, 2007 at 08:37:46AM -0500, robert delius royar wrote: > Sat, 22 Dec 2007 (00:54 +0100 UTC) Vincent Lefevre wrote: > > >On 2007-12-21 10:34:00 -0500, robert delius royar wrote: > >>I compiled perl 5.10.0 with the same configuration that macports 5.8.8 > >>used. [I have the perl5.8 port set as the primary perl interpretor and > >>have created links in /usr/local/[bin|lib|share] to make it so that > >>other software finds macports perl before the system one--including > >>apache.] > >> > >>When I tried to run a module through 5.10.0 from CPAN (Net::TiVo), > >>5.10.0 failed because a bundle from macports (p5-digest-sha1) referenced > >>a symbol not in the 5.10.0 version: > >[...] > > > >I'd say that you probably need to recompile every module (well, those > >that don't contain just Perl code) against 5.10. BTW, that may be a > >reason to have a single Perl port installed (activated). Otherwise > >the risk of using some module with a different Perl version for which > >it has been built would be too high IMHO. > > I have the latest version of perl5.8.8 (from macports) installed: > % port installed perl5.8 > The following ports are currently installed: > perl5.8 @5.8.8_0+darwin_8+shared+threads > % port outdated perl5.8 > No installed ports are outdated > However, occasionally I have had to abort installs of other software > because that software requires perl5.8 and tries to install it. I would > not want that to be the case with software wrt perl5.10 because that > could hose a system with a lot of perl 5.8 modules that have been > compiled and linked into bundles. > > > > >>dyld: lazy symbol binding failed: Symbol not found: _Perl_Tstack_sp_ptr > >> Referenced from: > >> /opt/local/lib/perl5/site_perl/5.10.0/darwin-thread-multi-2level/auto/Digest/SHA1/SHA1.bundle > >> Expected in: dynamic lookup > >> > >>dyld: Symbol not found: _Perl_Tstack_sp_ptr > >> Referenced from: > >> /opt/local/lib/perl5/site_perl/5.10.0/darwin-thread-multi-2level/auto/Digest/SHA1/SHA1.bundle > >> Expected in: dynamic lookup > >> > >>Trace/BPT trap > >> > >>I suspect there may be a number of these. Perl_Tstack_sp_ptr() was in > >>CORE in 5.8. I believe that it is part of the pre-5.8 legacy code and > >>in there for compatibility with verions that expected functions for what > >>are array or incrementable pointer variables. > >> > >>It is defined in the 5.8.8 source in perlapi.h but not defined anywhere > >>in the 5.10.0 source. > > > >I don't know what you try to mean exactly, but Digest-SHA1 2.11 is > >compatible with Perl 5.10 as you can see: > > > > http://cpantesters.perl.org/show/Digest-SHA1.html > > The API has changed and the symbol Perl_Tstack_sp_ptr is not in the > current API. It was in 5.8.8 and before. The discussion I have been > able to Google points to this symbol being a problem if old code is not > recompiled with the new libperl. > > I think moving up to perl5.10 is more drastic for the user than was > 5.6 to 5.8. Somehow the user should be warned that all bundles (I > suppose mod-perl and its companionions, also) will need to be > reinstalled or recompiled for 5.10 > > Because macports does not add any earlier directories to @INC, the user > would just see these errors as not being able to locate a module, rather > than the missing symbol error. Still, it means a bit of work for > someone who has a number of bundles. The user should be told that ahead > of time. > > >Vincent Lef??vre - Web: > >100% accessible validated (X)HTML - Blog: > >Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) > > -- > Dr. Robert Delius Royar Associate Professor of English > Morehead State University Morehead, Kentucky > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev From apple at frinabulax.org Thu Apr 17 03:38:52 2008 From: apple at frinabulax.org (robert delius royar) Date: Thu Apr 17 03:37:01 2008 Subject: [MacPorts] #14901: firefox-x11 does not provide file-selection browsers (fwd) In-Reply-To: <18438.3417.817101.546505@godel.local> References: <18438.3417.817101.546505@godel.local> Message-ID: Comments are inline in your quoted response Wed, 16 Apr 2008 (10:29 -0400 UTC) Stefan Bruda wrote: > Hi, > > Apologies for resurrecting this somehow old thread. > > I am using firefox-x11 all the time (I simply hate the Mac OS GUI and > it's lack of sloppy focus so I am trying to stay under X as much as > possible) and the lack of file browser annoys the heck out of me. > This is a really long standing problem. I have also inquired on this > list awhile ago but got no response. Other than the file browser (or > lack thereof) the port works fine on my machine (MBP 2,2). > > At 18:37 -0400 on 2008-4-2 robert delius royar wrote: > > > > I recall from my own attempts to build SeaMonkey for Mac X11 that I > > could not get it to link in the gnome-vfs components (listed as > > required in the port file). It always insisted on trying to link > > in the Carbon > > Looking at the port file, the firefox-x11 port does use gnome-vfs > apparently. I have not watched the build process though. Instead, I > tried (to tweak the configuration flags) to no effect. Have you made > any attempt at this? If so, with what effect? I tried editing the configure files to change references to Mac OS sections and Frameworks so that Mac compilations would be treated as GTK/Unix, but I was unable to find exactly where the compilation would switch from running as an X-based compilation to a Mac Carbon compilation. The current Macports port does not have the build or crash problems that the earlier one I tried to work out did. For the earlier ports, I managed to get the Carbon frameworks not to be added, but then the program would crash when i tried to get a file browsing dialog--sometimes the first try, and other times on subsequent tries. It was still not linking properly. I do still have the end-of-line Mozilla that works really well under X--really well in that I can leave it running for weeks. It is outdated and doesn't support much of what Firefox does on my Linux system (also running X.org's X). If you run otool -L on the resulting executable (firefox-bin) and its Mozilla directory libraries, do you find references to /opt/local/lib/libgnomevfs*.dylib? I cannot see them in mine. Instead I see references to Corefoundation and Coreservices Frameworks. I do not understand the autoconf tools really at all. I can make minor changes to configure files, but the Firefox build system is so complex that it would require someone who understood autoconf and the system to make it so that OS X with X11 was recognized as a valid GTK-based UI. It looks as though the folks who wrote the Mac part just never assumed there was a Gnome package to use for OS X. > I meant to try some more stuff in this respect (I also meant to answer > this email earlier... ;-) ) but so far I did not quite find the time > to do it right, I just poked around now and then (without any > noticeable effect). > > > Ticket URL: > > MacPorts > > Ports system for Mac OS > > Cheers, > Stefan > > -- Dr. Robert Delius Royar Associate Professor of English Morehead State University Morehead, Kentucky From afb at macports.org Thu Apr 17 04:23:43 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu Apr 17 04:21:32 2008 Subject: [MacPorts] #14901: firefox-x11 does not provide file-selection browsers (fwd) In-Reply-To: References: <18438.3417.817101.546505@godel.local> Message-ID: robert delius royar wrote: > I do not understand the autoconf tools really at all. I can make > minor changes to configure files, but the Firefox build system is > so complex that it would require someone who understood autoconf > and the system to make it so that OS X with X11 was recognized as a > valid GTK-based UI. It looks as though the folks who wrote the Mac > part just never assumed there was a Gnome package to use for OS X. Yes, this is the problem - and it is true for all the Mozilla ports... Darwin with X11 just isn't supported by the upstream. So it needs to be patched (heavilly) first, there are some attempts at this in mozilla/seamonkey/firefox/thunderbird/sunbird. --anders From raimue at macports.org Thu Apr 17 09:45:28 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu Apr 17 09:43:19 2008 Subject: [36031] trunk/dports/devel/bugzilla/Portfile In-Reply-To: References: <20080415054304.1A6CA1598D49@beta.macosforge.org> Message-ID: <48077EA8.7050001@macports.org> Ryan Schmidt wrote: >> post-patch { >> - cd ${worksrcpath} >> + system "cd ${worksrcpath}" >> foreach item [exec find . -type f -name .cvsignore] { >> file delete -force ${item} >> } >> @@ -99,7 +107,7 @@ >> >> set docPath "${prefix}/share/doc/${name}" >> xinstall -d -m 0755 ${destroot}${docPath} >> - cd ${worksrcpath} >> + system "cd ${worksrcpath}" >> xinstall -m 0644 \ >> README QUICKSTART UPGRADING UPGRADING-pre-2.8 \ >> ${destroot}${docPath}/ > > That change isn't going to work, is it? I mean, the reason why the tcl > "cd" command was deprecated is because we don't want portfiles changing > the working directory. Using 'system "cd"' won't change the working > directory, so e.g. the subsequent tcl "file delete" commands won't find > the files to delete. To fix the post-patch phase, you'd have to "exec > find ${worksrcpath} ..." instead. Haven't looked at the second bit. No, this is not going to work. The system command spawns a new shell in which the directory is changed but that does not change the current directory of the Tcl interpreter. Use absolute paths or xinstall -W ${worksrcpath} instead. To avoid the use of constructs like "exec find", there is fs-traverse which does what you probably want there. Rainer From ryandesign at macports.org Thu Apr 17 17:50:03 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Apr 17 17:49:22 2008 Subject: [36072] trunk/dports In-Reply-To: <20080416173347.B695B15A227A@beta.macosforge.org> References: <20080416173347.B695B15A227A@beta.macosforge.org> Message-ID: <8E6CBE8B-3764-4A75-8B10-64F4A164541B@macports.org> On Apr 16, 2008, at 12:33 PM, brett@macports.org wrote: > Revision: 36072 > http://trac.macosforge.org/projects/macports/changeset/36072 > Author: brett@macports.org > Date: 2008-04-16 10:33:46 -0700 (Wed, 16 Apr 2008) > > Log Message: > ----------- > revision bumped for libevent upgrade > name libdnsres > version 0.1a > +revision 0 > categories net > maintainers markd > description A non-blocking DNS resolver library > name scanssh > version 2.1 > +revision 0 > categories net security > platforms darwin > maintainers nomaintainer > name tor > version 0.1.2.19 > +revision 0 > categories security > maintainers boeyms openmaintainer > description anonymizing overlay network for TCP > name tor-devel > version 0.2.0.23-rc > +revision 0 > categories security > maintainers boeyms openmaintainer > description anonymizing overlay network for TCP 0 is the default revision, therefore no effective change was made to these four ports. If you wanted to force a reinstall of these ports, you would have to increase the revision from the default 0 to 1. I did this in r36101. From ryandesign at macports.org Fri Apr 18 18:22:14 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri Apr 18 18:19:57 2008 Subject: [36108] trunk/dports/math/xplot/files/patch-Makefile.in In-Reply-To: <20080418060612.783B915ACACA@beta.macosforge.org> References: <20080418060612.783B915ACACA@beta.macosforge.org> Message-ID: <3AEEE35B-0E6B-485D-9876-927CFD9D9B4C@macports.org> On Apr 18, 2008, at 1:06 AM, fenner@macports.org wrote: > Revision: 36108 > http://trac.macosforge.org/projects/macports/changeset/36108 > Author: fenner@macports.org > Date: 2008-04-17 23:06:11 -0700 (Thu, 17 Apr 2008) > > Log Message: > ----------- > Install man pages in share/man > > Modified Paths: > -------------- > trunk/dports/math/xplot/files/patch-Makefile.in The port's revision should be incremented so that everyone who already has this port installed gets this change. From bruda at cs.ubishops.ca Fri Apr 18 20:48:20 2008 From: bruda at cs.ubishops.ca (Stefan Bruda) Date: Fri Apr 18 20:46:36 2008 Subject: [MacPorts] #14901: firefox-x11 does not provide file-selection browsers (fwd) In-Reply-To: References: <18438.3417.817101.546505@godel.local> Message-ID: <18441.27524.820475.443018@godel.local> Hi, At 06:38 -0400 on 2008-4-17 robert delius royar wrote: > > I do still have the end-of-line Mozilla that works really well > under X--really well in that I can leave it running for weeks. It > is outdated and doesn't support much of what Firefox does on my > Linux system (also running X.org's X). Which mozilla do you have, and how did you get it? I would much prefer a modern firefox, but a fully working browser would be nice too--I am willing ot try things out. > If you run otool -L on the resulting executable (firefox-bin) and > its Mozilla directory libraries, do you find references to > /opt/local/lib/libgnomevfs*.dylib? I cannot see them in mine. You are right and I jumped to a too early conclusion just looking at the options in the port. There is not gnomevfs reference in the binary. > Instead I see references to Corefoundation and Coreservices > Frameworks. I don't seem to have these either, in fact here is the whole list of libraries: /opt/local/lib/firefox-2.0.0.13/libmozjs.dylib (compatibility version 1.0.0, current version 1.0.0) /opt/local/lib/firefox-2.0.0.13/libxpcom.dylib (compatibility version 1.0.0, current version 1.0.0) /opt/local/lib/firefox-2.0.0.13/libxpcom_core.dylib (compatibility version 1.0.0, current version 1.0.0) /opt/local/lib/libplds4.dylib (compatibility version 1.0.0, current version 1.0.0) /opt/local/lib/libplc4.dylib (compatibility version 1.0.0, current version 1.0.0) /opt/local/lib/libnspr4.dylib (compatibility version 1.0.0, current version 1.0.0) /opt/local/lib/libgtk-x11-2.0.0.dylib (compatibility version 1201.0.0, current version 1201.9.0) /opt/local/lib/libgdk-x11-2.0.0.dylib (compatibility version 1201.0.0, current version 1201.9.0) /opt/local/lib/libatk-1.0.0.dylib (compatibility version 2210.0.0, current version 2210.1.0) /opt/local/lib/libgdk_pixbuf-2.0.0.dylib (compatibility version 1201.0.0, current version 1201.9.0) /opt/local/lib/libpangocairo-1.0.0.dylib (compatibility version 2001.0.0, current version 2001.0.0) /opt/local/lib/libcairo.2.dylib (compatibility version 14.0.0, current version 14.7.0) /usr/X11R6/lib/libSM.6.dylib (compatibility version 6.0.0, current version 6.0.0) /usr/X11R6/lib/libICE.6.dylib (compatibility version 6.3.0, current version 6.3.0) /opt/local/lib/libpangoft2-1.0.0.dylib (compatibility version 2001.0.0, current version 2001.0.0) /opt/local/lib/libpango-1.0.0.dylib (compatibility version 2001.0.0, current version 2001.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.10) /opt/local/lib/libgobject-2.0.0.dylib (compatibility version 1601.0.0, current version 1601.1.0) /opt/local/lib/libgmodule-2.0.0.dylib (compatibility version 1601.0.0, current version 1601.1.0) /opt/local/lib/libglib-2.0.0.dylib (compatibility version 1601.0.0, current version 1601.1.0) /opt/local/lib/libintl.8.dylib (compatibility version 9.0.0, current version 9.2.0) /opt/local/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /opt/local/lib/libfreetype.6.dylib (compatibility version 10.0.0, current version 10.16.0) /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) /opt/local/lib/libfontconfig.1.dylib (compatibility version 5.0.0, current version 5.0.0) /opt/local/lib/libexpat.1.dylib (compatibility version 7.0.0, current version 7.2.0) /opt/local/lib/libpng12.0.dylib (compatibility version 26.0.0, current version 26.0.0) /opt/local/lib/libXrender.1.dylib (compatibility version 5.0.0, current version 5.0.0) /usr/X11R6/lib/libX11.6.dylib (compatibility version 6.2.0, current version 6.2.0) /opt/local/lib/libgthread-2.0.0.dylib (compatibility version 1601.0.0, current version 1601.1.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) If that's of any use I am running the "stock" (meaning: unmodified) firefox-x11 port (currently 2.0.0.13). > It looks as though the folks who wrote the Mac part just never > assumed there was a Gnome package to use for OS X. Apparently so. Still, for me the Carbon firefox sucks, I want an X11 one. So far I am using it with some limitations and workarounds (given the lack of file chooser), retorting to the Carbon firefox when the limitations prove too much for the task at hand. But then I would really like a complete browser. If anybody points to things that should be tried I would be more than willing to try them out. As somebody else mentioned too, the thing is too large a beast for me to understand entirely. At 13:23 +0200 on 2008-4-17 Anders F Bj?rklund wrote: > > So it needs to be patched (heavilly) first, there are some attempts > at this in mozilla/seamonkey/firefox/thunderbird/sunbird. How does one get hold of them? I would be interested in trying them out and maybe (if I can) change them for the better. Thanks again, Stefan -- If it was so, it might be; and if it were so, it would be; but as it isn't, it ain't. That's logic. --Lewis Carroll, Through the Looking-Glass From afb at macports.org Sat Apr 19 02:35:28 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sat Apr 19 02:33:09 2008 Subject: [MacPorts] #14901: firefox-x11 does not provide file-selection browsers (fwd) In-Reply-To: <18441.27524.820475.443018@godel.local> References: <18438.3417.817101.546505@godel.local> <18441.27524.820475.443018@godel.local> Message-ID: Stefan Bruda wrote: >> So it needs to be patched (heavilly) first, there are some attempts >> at this in mozilla/seamonkey/firefox/thunderbird/sunbird. > > How does one get hold of them? I would be interested in trying them > out and maybe (if I can) change them for the better. The obsolete Mozilla 1.7.x versions live in port "mozilla", while new SeaMonkey 1.1.x versions are in port "seamonkey". (the community project that took over the development of the internet suite when Mozilla Foundation stopped, back in 2005) For the various projects from Mozilla Foundation, they are in "firefox-x11" and "thunderbird-x11" and "sunbird-x11"... (implying that there could be Carbon variants some day, but for now the official mozilla.com binaries are used instead) The patches for mozilla/seamonkey has been ported from Fink, which has had a working installation of both for a long time. Interest in these X11 applications have faded in MacPorts, since the old DarwinPorts days when there was no Safari etc. The main reason I resurrected the ports was so that there could be a web browser and mail/news client for Xfce 4.4. Usually it uses Mozilla Firefox? and Mozilla Thunderbird?, SeaMonkey? or even Iceweasel/Icedove/Iceape are also used. If someone wants to maintain firefox / thunderbird in MacPorts, that would be great. All Mozilla ports need some major cleanup. --anders PS. I tried a few selected patches / workarounds, but haven't seen the file dialog yet so likely it needs to be redone. From takeshi at enomosphere.net Sat Apr 19 04:41:11 2008 From: takeshi at enomosphere.net (Takeshi Enomoto) Date: Sat Apr 19 04:38:52 2008 Subject: ImageMagick Message-ID: <58D2439C-98D7-4195-83DD-FE531CEADA2F@enomosphere.net> Hi, A defect of gnudatalanguage has been reported. It turned out that the name of a library of ImageMagick had been changed from libMagick to libMagicCore. Header file Magick++.h is now in ${prefix}/include/ImageMagick ($ {prefix}/include previously). 2008-02-03 6.3.8-5 Cristy * New Unix/Linux refactoring (should be transparent since changes are reflected in Magick-config and ImageMagick.pc pkg-config files): /usr/local/include => /usr/local/include/ImageMagick libMagick => libMagickCore libWand => libMagickWand Magick-config (deprecated) => MagickCore-config Wand-config (deprecated) => MagickWand-config Add Magick++-config, MagickCore.pc, MagickWand.pc, Magick++.pc It is transparent for some packages using Magick-config or pkg-config but it is not for other packages. I chose to see whether if there is libMagick or libMagickCore since not everyone is up-to-date as below. set imflag [lsearch [exec pkg-config --libs-only-l ImageMagick] - lMagickCore] There may be some other packages with the same problem. Takeshi From ryandesign at macports.org Sat Apr 19 15:34:21 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat Apr 19 15:32:00 2008 Subject: [36148] trunk/dports/aqua/dnsupdate/Portfile In-Reply-To: <20080419135516.6B1F915B736B@beta.macosforge.org> References: <20080419135516.6B1F915B736B@beta.macosforge.org> Message-ID: <980078D9-57C0-4EE9-BD79-F2C161CF94A5@macports.org> On Apr 19, 2008, at 8:55 AM, jmr@macports.org wrote: > Revision: 36148 > http://trac.macosforge.org/projects/macports/changeset/36148 > Author: jmr@macports.org > Date: 2008-04-19 06:55:13 -0700 (Sat, 19 Apr 2008) > > Log Message: > ----------- > dnsupdate: avoid symlink creation failure > > Modified Paths: > -------------- > trunk/dports/aqua/dnsupdate/Portfile > > Modified: trunk/dports/aqua/dnsupdate/Portfile > =================================================================== > --- trunk/dports/aqua/dnsupdate/Portfile 2008-04-19 12:16:32 UTC > (rev 36147) > +++ trunk/dports/aqua/dnsupdate/Portfile 2008-04-19 13:55:13 UTC > (rev 36148) > @@ -91,7 +91,7 @@ > xinstall -d -m 0755 ${destroot}${itemPath} > xinstall -d -m 0755 ${itemAliasPath} > xinstall -m 0755 ${worksrcpath}/org.dnsupdate.daemon.plist $ > {destroot}${itemPath}/${itemName} > - file link -symbolic ${itemAliasPath}/${itemName} ${itemPath}/$ > {itemName} > + system "ln -s ${itemPath}/${itemName} ${itemAliasPath}/${itemName}" Could you explain in more detail what's going on with this change? I would think we would want to be using the tcl "ln" procedure, not calling out to a shell command with system, so I'm interested in why you decided to change *to* using system. From ryandesign at macports.org Sat Apr 19 15:38:55 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat Apr 19 15:36:33 2008 Subject: [36146] trunk/dports/math/gnudatalanguage/Portfile In-Reply-To: <20080419113805.BC55015B6C6F@beta.macosforge.org> References: <20080419113805.BC55015B6C6F@beta.macosforge.org> Message-ID: <191BC5AC-C1A9-4E66-BED3-00FC6EDD5EE4@macports.org> On Apr 19, 2008, at 6:38 AM, takeshi@macports.org wrote: > Revision: 36146 > http://trac.macosforge.org/projects/macports/changeset/36146 > Author: takeshi@macports.org > Date: 2008-04-19 04:37:58 -0700 (Sat, 19 Apr 2008) > > Log Message: > ----------- > gnudatalanguage: fixed compatibility with ImageMagick >= 6.3.8-5 > @@ -46,6 +47,10 @@ > --enable-python_version=2.4 \ > --with-Magick=${prefix} \ > --disable-dependency-tracking > +set imflag [lsearch [exec pkg-config --libs-only-l ImageMagick] - > lMagickCore] > +if {$imflag} { > + configure.cppflags-append "-I${prefix}/include/ImageMagick" > +} I think this is the change that broke the portindex, and in any case isn't compatible with users who do not have the pkgconfig port installed at the time that they execute any port command (e.g. port info). You should probably wrap these new lines in a pre-configure section. From raimue at macports.org Sat Apr 19 18:51:08 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat Apr 19 18:48:45 2008 Subject: [34977] trunk/base In-Reply-To: References: <20080313141352.0844714A0BA2@beta.macosforge.org> <47E1BAC7.6020807@macports.org> <4800A3C6.2040401@macports.org> Message-ID: <480AA18C.9040701@macports.org> William Siegrist wrote: > I can see a use for both directions, so I guess having options for > both directions would be nice. But also a name like "follow- > dependents" or "also-dependents" would be clearer. I renamed --recursive to --follow-dependents for port uninstall in r36160. Rainer From raimue at macports.org Sat Apr 19 18:58:50 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat Apr 19 18:56:25 2008 Subject: Status of registry2.0 Message-ID: <480AA35A.20404@macports.org> Hi, What is the current status of registry 2.0? As we are still putting new features (recursive uninstall) into registry1.0 I was wondering what the status of registry2.0 is at the moment. It is sitting around in trunk now for quite some time without active work. What is missing from registry2.0, what needs to be done? Where can somebody jump in and help? Not necessarily me, I just want to put general attention to the new registry. If you install a lot of ports activating/deactivating takes longer than actual compiling because of the old file_map.db of registry1.0. I hope this will become a lot better with the sqlite database of registry2.0. Rainer From jmr at macports.org Sun Apr 20 05:52:25 2008 From: jmr at macports.org (Joshua Root) Date: Sun Apr 20 05:49:59 2008 Subject: [36148] trunk/dports/aqua/dnsupdate/Portfile In-Reply-To: <980078D9-57C0-4EE9-BD79-F2C161CF94A5@macports.org> References: <20080419135516.6B1F915B736B@beta.macosforge.org> <980078D9-57C0-4EE9-BD79-F2C161CF94A5@macports.org> Message-ID: <480B3C89.6020107@macports.org> Ryan Schmidt wrote: > On Apr 19, 2008, at 8:55 AM, jmr@macports.org wrote: > >> Revision: 36148 >> http://trac.macosforge.org/projects/macports/changeset/36148 >> Author: jmr@macports.org >> Date: 2008-04-19 06:55:13 -0700 (Sat, 19 Apr 2008) >> >> Log Message: >> ----------- >> dnsupdate: avoid symlink creation failure >> >> Modified Paths: >> -------------- >> trunk/dports/aqua/dnsupdate/Portfile >> >> Modified: trunk/dports/aqua/dnsupdate/Portfile >> =================================================================== >> --- trunk/dports/aqua/dnsupdate/Portfile 2008-04-19 12:16:32 UTC >> (rev 36147) >> +++ trunk/dports/aqua/dnsupdate/Portfile 2008-04-19 13:55:13 UTC >> (rev 36148) >> @@ -91,7 +91,7 @@ >> xinstall -d -m 0755 ${destroot}${itemPath} >> xinstall -d -m 0755 ${itemAliasPath} >> xinstall -m 0755 ${worksrcpath}/org.dnsupdate.daemon.plist >> ${destroot}${itemPath}/${itemName} >> - file link -symbolic ${itemAliasPath}/${itemName} >> ${itemPath}/${itemName} >> + system "ln -s ${itemPath}/${itemName} ${itemAliasPath}/${itemName}" > > Could you explain in more detail what's going on with this change? I > would think we would want to be using the tcl "ln" procedure, not > calling out to a shell command with system, so I'm interested in why you > decided to change *to* using system. The link being created points to a path that does not (yet) exist. 'file link -symbolic' worked when I tested the port on Leopard, but failed when I just recently tried installing it on Tiger. 'ln -s' works on both OS versions. - Josh From ryandesign at macports.org Wed Apr 23 00:07:04 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Apr 23 00:04:30 2008 Subject: [36218] trunk/dports/audio/libsamplerate/Portfile In-Reply-To: <20080423043026.6BDF815CED31@beta.macosforge.org> References: <20080423043026.6BDF815CED31@beta.macosforge.org> Message-ID: <6E20E9B5-E771-46C5-A45E-4421FAFEB88D@macports.org> On Apr 22, 2008, at 11:30 PM, gui_dos@macports.org wrote: > Revision: 36218 > http://trac.macosforge.org/projects/macports/changeset/36218 > Author: gui_dos@macports.org > Date: 2008-04-22 21:30:25 -0700 (Tue, 22 Apr 2008) > > Log Message: > ----------- > libsamplerate: version bump to 0.1.3 > > Modified Paths: > -------------- > trunk/dports/audio/libsamplerate/Portfile > > Modified: trunk/dports/audio/libsamplerate/Portfile > =================================================================== > --- trunk/dports/audio/libsamplerate/Portfile 2008-04-22 21:03:10 > UTC (rev 36217) > +++ trunk/dports/audio/libsamplerate/Portfile 2008-04-23 04:30:25 > UTC (rev 36218) > @@ -3,7 +3,7 @@ > PortSystem 1.0 > > name libsamplerate > -version 0.1.2 > +version 0.1.3 > categories audio > maintainers boeyms openmaintainer > description libsamplerate (also known as Secret Rabbit Code) > is a library \ No checksum update? $ port -d checksum libsamplerate DEBUG: Found port in file:///Volumes/data/macports/ports/audio/ libsamplerate DEBUG: Changing to port directory: /Volumes/data/macports/ports/audio/ libsamplerate DEBUG: Requested variant powerpc is not provided by port libsamplerate. DEBUG: Requested variant darwin is not provided by port libsamplerate. DEBUG: Requested variant macosx is not provided by port libsamplerate. DEBUG: Executing org.macports.main (libsamplerate) ---> Fetching libsamplerate DEBUG: Executing org.macports.fetch (libsamplerate) ---> libsamplerate-0.1.3.tar.gz doesn't seem to exist in /macports/ var/macports/distfiles/libsamplerate ---> Attempting to fetch libsamplerate-0.1.3.tar.gz from http:// www.mega-nerd.com/libsamplerate/ % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 4161k 100 4161k 0 0 235k 0 0:00:17 0:00:17 --:--:-- 276k ---> Verifying checksum(s) for libsamplerate DEBUG: Executing org.macports.checksum (libsamplerate) ---> Checksumming libsamplerate-0.1.3.tar.gz Error: Checksum (md5) mismatch for libsamplerate-0.1.3.tar.gz Portfile checksum: libsamplerate-0.1.3.tar.gz md5 06861c2c6b8e5273c9b80cf736b9fd0e Distfile checksum: libsamplerate-0.1.3.tar.gz md5 3f91af22a6c4135485594d0d2c91d45d Error: Checksum (sha1) mismatch for libsamplerate-0.1.3.tar.gz Portfile checksum: libsamplerate-0.1.3.tar.gz sha1 663ac147d1dfbe686bf687e78143259b5075fc13 Distfile checksum: libsamplerate-0.1.3.tar.gz sha1 4a0b493aa868fb6f9e7e8e5db2fb44cfbcd2d123 Error: Checksum (rmd160) mismatch for libsamplerate-0.1.3.tar.gz Portfile checksum: libsamplerate-0.1.3.tar.gz rmd160 4e5453821b80b17586ad66068e409ed0437cca02 Distfile checksum: libsamplerate-0.1.3.tar.gz rmd160 7bf12883ade8f9dd24d4ee89cb740e5df06358ec Error: Target org.macports.checksum returned: Unable to verify file checksums Warning: the following items did not execute (for libsamplerate): org.macports.checksum Error: Status 1 encountered during processing. $ From ryandesign at macports.org Wed Apr 23 06:34:54 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Apr 23 06:32:19 2008 Subject: [36240] trunk/dports/math/cadabra/Portfile In-Reply-To: <20080423122146.C422A15D00C2@beta.macosforge.org> References: <20080423122146.C422A15D00C2@beta.macosforge.org> Message-ID: On Apr 23, 2008, at 7:21 AM, gwright@macports.org wrote: > Revision: 36240 > http://trac.macosforge.org/projects/macports/changeset/36240 > Author: gwright@macports.org > Date: 2008-04-23 05:21:43 -0700 (Wed, 23 Apr 2008) > > Log Message: > ----------- > Update checksums (upstream tarballs were rebuilt, but no > other changes were made). > -checksums md5 74ff6fdaf6f44583a11f385dc9d526ba \ > - sha1 c43c85bf4a03fa517d328172edc269570860bb6b \ > - rmd160 04b2ceefdc53c28c2727443f6ddba229ab537a5d > +checksums md5 b0ffd5fa1e9619a2b453f20a3c5c968d \ > + sha1 aba2937348eecfc93c45eb32d87566359fbf9b3d \ > + rmd160 99c805c861fc3bf4520ea4bbdf7bf2790db660c9 Then you should also change the dist_subdir. so that people who already had the old distfile downloaded will not now encounter checksum errors. For example you could change it from the default $ {name} to: dist_subdir ${name}/${version} From ryandesign at macports.org Wed Apr 23 07:06:30 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Apr 23 07:03:54 2008 Subject: [36241] trunk/dports/science/magic/Portfile In-Reply-To: <20080423134628.440BF15D069C@beta.macosforge.org> References: <20080423134628.440BF15D069C@beta.macosforge.org> Message-ID: <5318737B-3C01-49F7-A5FE-46CF57C2DE97@macports.org> Don't forget to commit the actual patchfile too! $ port checksum magic ---> Fetching magic ---> Attempting to fetch patch-tkcon.tcl from http:// svn.macports.org/repository/macports/distfiles/magic ---> Attempting to fetch patch-tkcon.tcl from http:// svn.macports.org/repository/macports/distfiles/general/ ---> Attempting to fetch patch-tkcon.tcl from http:// svn.macports.org/repository/macports/downloads/magic Error: Target org.macports.fetch returned: fetch failed Error: Status 1 encountered during processing. $ On Apr 23, 2008, at 8:46 AM, raimue@macports.org wrote: > Revision: 36241 > http://trac.macosforge.org/projects/macports/changeset/36241 > Author: raimue@macports.org > Date: 2008-04-23 06:46:23 -0700 (Wed, 23 Apr 2008) > > Log Message: > ----------- > science/magic: > Fix runtime issue with Tcl 8.5.x (where x != 0), closes #15050 > > Modified Paths: > -------------- > trunk/dports/science/magic/Portfile > > Modified: trunk/dports/science/magic/Portfile > =================================================================== > --- trunk/dports/science/magic/Portfile 2008-04-23 12:21:43 UTC > (rev 36240) > +++ trunk/dports/science/magic/Portfile 2008-04-23 13:46:23 UTC > (rev 36241) > @@ -4,6 +4,7 @@ > > name magic > version 7.5.129 > +revision 1 > categories science > maintainers waqar@macports.org > description A VLSI Layout System > @@ -25,6 +26,9 @@ > depends_lib port:blt > } > > +patchfiles patch-tkcon.tcl > +patch.pre_args -p0 > + > configure.args --mandir=${prefix}/share/man \ > --infodir=${prefix}/share/info From raimue at macports.org Wed Apr 23 09:13:12 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed Apr 23 09:10:34 2008 Subject: [36241] trunk/dports/science/magic/Portfile In-Reply-To: <5318737B-3C01-49F7-A5FE-46CF57C2DE97@macports.org> References: <20080423134628.440BF15D069C@beta.macosforge.org> <5318737B-3C01-49F7-A5FE-46CF57C2DE97@macports.org> Message-ID: <480F6018.9050606@macports.org> Ryan Schmidt wrote: > Don't forget to commit the actual patchfile too! Thanks, forgot to svn add it. Added in r36242. Rainer From sfiera at macports.org Wed Apr 23 08:41:30 2008 From: sfiera at macports.org (Chris Pickel) Date: Wed Apr 23 11:36:44 2008 Subject: Status of registry2.0 In-Reply-To: <480AA35A.20404@macports.org> References: <480AA35A.20404@macports.org> Message-ID: <0455052E-CE67-4C75-8EDC-6D827C912004@macports.org> On 19 Apr, 2008, at 21:58, Rainer M?ller wrote: > What is the current status of registry 2.0? As we are still putting > new features (recursive uninstall) into registry1.0 I was wondering > what the status of registry2.0 is at the moment. It is sitting > around in trunk now for quite some time without active work. > > What is missing from registry2.0, what needs to be done? Where can > somebody jump in and help? Not necessarily me, I just want to put > general attention to the new registry. I am very busy and haven't looked in a while. If I haven't given a better response within 3 weeks or so, feel free to remind me to do so. -------------- 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/20080423/d1b99cb2/PGP.bin From wsiegrist at apple.com Wed Apr 23 14:07:46 2008 From: wsiegrist at apple.com (William Siegrist) Date: Wed Apr 23 14:11:16 2008 Subject: Fwd: Website viewing problem References: <41A72463-9EBA-44B6-AFBD-FF8EBFEFCF20@u.washington.edu> Message-ID: Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080423/b7d41124/smime-0001.bin From raimue at macports.org Wed Apr 23 14:37:18 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed Apr 23 14:34:37 2008 Subject: Fwd: Website viewing problem In-Reply-To: References: <41A72463-9EBA-44B6-AFBD-FF8EBFEFCF20@u.washington.edu> Message-ID: <480FAC0E.4000909@macports.org> William Siegrist wrote: > I'm forwarding on to macports-dev since it seems like the XML > declaration they are using makes that browser treat the site as an XML > doc instead of an XHTML 1.1 doc. What they have is valid XHTML 1.1, > so it might just be that Shiira2 doesnt work well with the latest > XHTML 1.1 draft. I think that would be covered by ticket #14062 [1]. Already with patch included, but not yet committed because I was waiting for confirmation. It fixes the issue for IE7, not sure if also for Shiira2. Rainer [1] http://trac.macosforge.org/projects/macports/ticket/14062 From dluke at geeklair.net Wed Apr 23 22:11:21 2008 From: dluke at geeklair.net (Daniel J. Luke) Date: Wed Apr 23 22:08:39 2008 Subject: RFC: inverting @INC for perl5.{8,10} In-Reply-To: <20080416191303.GF1423@darkart.com> References: <20080416191303.GF1423@darkart.com> Message-ID: <4CCE4C12-F026-4A58-9CF7-917898D35BDD@geeklair.net> On Apr 16, 2008, at 3:13 PM, Eric Hall wrote: > I don't know what negative impacts this has (I can imagine > problems with core modules expecting to get an older version of > another modules, dunno if that's a real problem or not), That's the only problem I can think of. > and > I'd expect this would be exposed in FreeBSD if it is a real-world > problem. Right, since FreeBSD does it this way, I think we're safe to at least try it. > Anyone see any other problems with this idea, and/or > reasons we should not do this? I think this is a good change, we'll be able to get rid of the few ports that require being installed with force (and therefore mess things up when reinstalling/upgrading the perl port). -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080424/415bab7b/PGP.bin From dgou at mac.com Thu Apr 24 05:11:32 2008 From: dgou at mac.com (Douglas Philips) Date: Thu Apr 24 05:08:52 2008 Subject: py25-dot needs python24? Message-ID: Using macports 1.60 on Leopard (10.5.2): py25-dot depends on py-parsing, and py-parsing needs python24. There doesn't seem to be a py25-parsing... I don't mind if the python24 module works with python25, its just annoying to have to install python24 (or rather, the annoying part is the build. :) ). Thanks, --Doug From dgou at mac.com Thu Apr 24 05:26:28 2008 From: dgou at mac.com (Douglas Philips) Date: Thu Apr 24 05:23:47 2008 Subject: py25-dot needs python24? In-Reply-To: References: Message-ID: I just wrote: On 2008 Apr 24, at 8:11 AM, Douglas Philips wrote: > Using macports 1.60 on Leopard (10.5.2): > py25-dot depends on py-parsing, and py-parsing needs python24. > > There doesn't seem to be a py25-parsing... > I don't mind if the python24 module works with python25, its just > annoying to have to install python24 (or rather, the annoying part > is the build. :) ). But of course it doesn't work, because py-parsing is installed under python24's site-packages so when python25 does an import of pydot, it can't find the parsing module. Sigh. --Doug From ryandesign at macports.org Thu Apr 24 12:10:52 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Apr 24 12:08:10 2008 Subject: py25-dot needs python24? In-Reply-To: References: Message-ID: <47156E27-31D6-4B6D-AFF2-A58CF8D767E9@macports.org> On Apr 24, 2008, at 7:26 AM, Douglas Philips wrote: > I just wrote: > On 2008 Apr 24, at 8:11 AM, Douglas Philips wrote: > >> Using macports 1.60 on Leopard (10.5.2): >> py25-dot depends on py-parsing, and py-parsing needs python24. >> >> There doesn't seem to be a py25-parsing... >> I don't mind if the python24 module works with python25, its just >> annoying to have to install python24 (or rather, the annoying part >> is the build. :) ). > > But of course it doesn't work, because py-parsing is installed > under python24's site-packages so when python25 does an import of > pydot, it can't find the parsing module. Sigh. Right. py-* packages are for Python 2.4. py25-* packages are for Python 2.5. Python 2.5 packages should not depend on Python 2.4 packages, so this is a bug in py25-dot. Please file a ticket in the issue tracker and assign or Cc it to the port's maintainer. py25-dot was just created from py-dot in r34410 so this dependency was probably overlooked. http://guide.macports.org/#project If a py25-parsing does not exist, and that's needed for py25-dot, then it will need to be created from py-parsing. From guglielmo.celata at gmail.com Fri Apr 25 10:44:18 2008 From: guglielmo.celata at gmail.com (Guglielmo Celata) Date: Fri Apr 25 10:41:28 2008 Subject: PHP5 XsltProcessor and apache segfault Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: xslt_crash.php Type: application/octet-stream Size: 1384 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080425/65d15ddc/xslt_crash.obj -------------- next part -------------- The following ports are currently installed: antlr @2.7.7_0 (active) apache2 @2.2.8_0+darwin_9 (active) apr @1.2.12_1+darwin_9 (active) apr-util @1.2.12_0 (active) asciidoc @7.1.2_0 (active) autoconf @2.61_0 (active) automake @1.10.1_0 (active) bzip2 @1.0.3_0 bzip2 @1.0.5_0 (active) cclient @2004g_0 (active) curl @7.16.0_0+darwin_8 curl @7.16.2_0+darwin_8 curl @7.18.1_0 (active) db44 @4.4.20_0+darwin_8 (active) dejagnu @1.4.4_0 (active) expat @2.0.0_1 expat @2.0.1_0 (active) fftw-3 @3.1.2_0 (active) flex @2.5.33_0 (active) fontconfig @2.5.0_0+macosx (active) freetype @2.1.10_1 freetype @2.3.4_1 freetype @2.3.5_1 (active) gawk @3.1.6_0 (active) gettext @0.15_0 gettext @0.16.1_0 gettext @0.17_3 (active) gmake @3.81_0 (active) ImageMagick @6.4.0-3_0+q16 (active) jasper @1.701.0_0 (active) jpeg @6b_1 jpeg @6b_2 (active) libevent @1.3b_0 (active) libiconv @1.11_0+darwin_8 libiconv @1.11_4+darwin_8 libiconv @1.12_0+darwin_8 (active) libmcrypt @2.5.7_2+darwin_8 libmcrypt @2.5.8_0+darwin_8 (active) libpng @1.2.10_2+darwin_8 libpng @1.2.18_0+darwin_8 libpng @1.2.26_0 (active) libtool @1.5.26_0 (active) libxml2 @2.6.31_0 (active) libxslt @1.1.22_0 (active) memcached @1.2.2_0 (active) metis @4.0_0 (active) mhash @0.9.2_0+darwin_8 mhash @0.9.9_0+darwin_8 (active) mysql5 @5.0.27_0+darwin_8+server (active) ncurses @5.5_1+darwin_8 ncurses @5.6_0+darwin_8 (active) ncursesw @5.5_0+darwin_8 ncursesw @5.6_0+darwin_8 ncursesw @5.6_1 (active) neon @0.26.2_0 (active) openssl @0.9.8d_0+darwin_8 openssl @0.9.8e_0+darwin_8 openssl @0.9.8g_0 (active) pcre @6.7_0 pcre @7.1_1+utf8 pcre @7.6_0 (active) php5 @5.2.5_2+apache2+macosx+mysql5+pear+readline (active) pkgconfig @0.21_0 pkgconfig @0.23_0 (active) python25 @2.5.1_1+darwin_9 (active) readline @5.1.004_0 readline @5.2.001_0 (active) saxpath @1.0_0 (active) sqlite3 @3.5.7_0 (active) subversion @1.4.6_0 (active) SuiteSparse @2.4.0_0 (active) tidy @20051026_0 (active) tiff @3.8.2_0+darwin_8 tiff @3.8.2_1+macosx (active) wget @1.10.2_0+darwin_8 (active) zlib @1.2.3_0 zlib @1.2.3_1 (active) From shreevatsa.public at gmail.com Fri Apr 25 10:59:12 2008 From: shreevatsa.public at gmail.com (Shreevatsa R) Date: Fri Apr 25 10:56:21 2008 Subject: Recursive dependencies, recursive uninstall, variants Message-ID: <7675454e0804251059q75ef6d56mb719640953048431@mail.gmail.com> Hi MacPorts developers, I was planning to write some non-trivial code before posting to this list, but I thought I would first check if I was doing anything stupid. I found that the "port deps" command only lists the explicit dependencies of a port, and not everything that the port actually depends on ("recursive dependencies"). This meant that often installing something trivial looking would start pulling in something enormous that I didn't want to install, and I would have to kill it, or wait hours. Contrast this to something like Debian's apt (used by Fink too), which when you try to install something, gives a message like: # apt-get install nautilus Reading Package Lists... Done Building Dependency Tree... Done The following extra packages will be installed: bonobo libmedusa0 libnautilus0 The following NEW packages will be installed: bonobo libmedusa0 libnautilus0 nautilus 0 packages upgraded, 4 newly installed, 0 to remove and 1 not upgraded. Need to get 8329kB of archives. After unpacking 17.2MB will be used. Do you want to continue? [Y/n] So deciding that at least knowing all dependencies of a port beforehand would help, I tried writing a command for recursive dependencies. The proc action_deps does a lot of stuff, and it's not easy getting just the list of dependencies with no extra output, so I wrote my own "bare" proc that does the actual dependencies, etc., and rdeps that recursively calls it: proc add_to_set {set_var item} { upvar $set_var var if {[lsearch -exact $var $item] == -1} { lappend var $item } } proc actdeps {portname depstype} { array unset portinfo array set portinfo [lindex [mportsearch $portname no exact] 1] #set deps [map {x {lindex [split $x :] end}} $portinfo($depstype)] set deps [] if {[info exists portinfo($depstype)]} { foreach i $portinfo($depstype) { lappend deps [lindex [split $i :] end] } } return $deps } proc rdeps {portname {depth 0}} { global shownports if [info exists shownports] { } else { set shownports [] } add_to_set shownports $portname set depstypes {depends_build depends_lib depends_run} set depstypes_descr {"build" "library" "runtime"} foreach depstype $depstypes depsdecr $depstypes_descr { foreach port [actdeps $portname $depstype] { if {[lsearch $shownports $port] == -1} { puts "[string repeat \t $depth]$port" rdeps $port [expr {$depth + 1}] } } } } proc action_rdeps {action portlist opts} { foreachport $portlist { rdeps $portname } } And "rdeps action_rdeps" in action_array. Yeah, it uses a global variable to avoid printing the same ports again, but it works: ~$ port rdeps subversion expat neon gettext libiconv gperf ncurses ncursesw openssl zlib apr apr-util db44 sqlite3 gawk gmake readline This is not great code, but it does what I want. (It is also the only Tcl I have ever written, so please tell me what I'm doing stupidly.) I was planning to do the same for variants (because I install something and later discover I should have installed one of its dependencies with a different variant), and for uninstall (because it is a real pain to uninstall ports). More specifically, I was planning to (1) make a general (simple) function for getting a specific port's "tree of dependencies" (and/or tree of dependents) and then something to act on it. Uninstall would then be trivial. (2) Also, putting something to return the list of dependencies of a port in the MacPorts API itself. (3) Also, looking at action_deps, it seems to share a lot in common with other functions (searching for ports, etc.), so that part can be cleaned up... Comments? -Shreevatsa From wsiegrist at apple.com Fri Apr 25 13:18:18 2008 From: wsiegrist at apple.com (William Siegrist) Date: Fri Apr 25 13:16:26 2008 Subject: [36285] trunk/base/portmgr/jobs/portfile_lint.pl In-Reply-To: <20080425144601.27C6715E677D@beta.macosforge.org> References: <20080425144601.27C6715E677D@beta.macosforge.org> Message-ID: <503EDCE2-DADA-4916-AA4A-C7E55E64E785@apple.com> This has been installed on the server. Thanks for fixing it. -Bill On Apr 25, 2008, at 7:46 AM, eridius@macports.org wrote: > Revision36285Authoreridius@macports.orgDate2008-04-25 07:46:00 -0700 > (Fri, 25 Apr 2008)Log Message > Make the auto-lint script catch errors too, not just warnings > Modified Paths > ? trunk/base/portmgr/jobs/portfile_lint.pl > Diff > Modified: trunk/base/portmgr/jobs/portfile_lint.pl (36284 => 36285) > --- trunk/base/portmgr/jobs/portfile_lint.pl 2008-04-25 14:42:41 UTC > (rev 36284) > +++ trunk/base/portmgr/jobs/portfile_lint.pl 2008-04-25 14:46:00 UTC > (rev 36285) > @@ -59,7 +59,7 @@ > > sub _lint { > my ($port) = @_; > - my $errors = `$PORTCMD -qc lint`; > + my $errors = `$PORTCMD -qc lint 2>&1`; > > if ($errors) { > _log("Error: $errors "); > _______________________________________________ > macports-changes mailing list > macports-changes@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-changes ---- William Siegrist Mac OS Forge http://macosforge.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080425/67285e71/smime.bin From guglielmo.celata at gmail.com Fri Apr 25 14:43:32 2008 From: guglielmo.celata at gmail.com (Guglielmo Celata) Date: Fri Apr 25 14:40:43 2008 Subject: PHP5 XsltProcessor and apache segfault Message-ID: Sorry for this other post, but I found something else here. http://trac.macports.org/projects/macports/ticket/14063 It seems there is an issue with the libxml2 library in macports, clashing with the native one. The latest version (2.6.31) is the one that crashes. Downgrading to libxml2 2.6.16 libxslt 1.1.12 everything went back to normal. -- Guglielmo Celata microcredito online - http://www.kiva.org/lender/guglielmocelata per una politica trasparente - http://www.openpolis.it -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080425/9d4ec10f/attachment.html From ryandesign at macports.org Fri Apr 25 22:10:46 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri Apr 25 22:07:59 2008 Subject: PHP5 XsltProcessor and apache segfault In-Reply-To: References: Message-ID: <5A6B9D99-3CBD-4701-85F4-80815AC1CAE0@macports.org> Cedric, Have you contacted the developers of libxml regarding this problem? http://trac.macports.org/projects/macports/ticket/14063 Thanks. -Ryan On Apr 25, 2008, at 4:43 PM, Guglielmo Celata wrote: > Sorry for this other post, but I found something else here. > http://trac.macports.org/projects/macports/ticket/14063 > > It seems there is an issue with the libxml2 library in macports, > clashing with the native one. > > The latest version (2.6.31) is the one that crashes. > > Downgrading to > libxml2 2.6.16 > libxslt 1.1.12 > > everything went back to normal. > > > On Apr 25, 2008, at 12:44 PM, Guglielmo Celata wrote: >> I have a problem with the php5 module for apache2, installed under >> osx 10.5 intel >> When executing the attached script, I get the segfault message in >> the apache error log: >> >> [Fri Apr 25 19:17:45 2008] [notice] child pid 95388 exit signal >> Segmentation fault (11) >> >> If the script is executed with the CLI php, then everything works >> fine. >> >> Everything was working with apache, up to few weeks ago. >> I don't understand if this is a macports issue (I made an upgrade >> few weeks ago) or an OSX issue. >> >> This are the involved packages installed on my system: >> libxml2 @2.6.31_0 (active) >> libxslt @1.1.22_0 (active) >> php5 @5.2.5_2+apache2+macosx+mysql5+pear+readline (active) >> apache2 @2.2.8_0+darwin_9 (active) >> >> Attached, there's the complete output of thew port installed command. > From ryandesign at macports.org Fri Apr 25 22:15:17 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri Apr 25 22:12:44 2008 Subject: Recursive dependencies, recursive uninstall, variants In-Reply-To: <7675454e0804251059q75ef6d56mb719640953048431@mail.gmail.com> References: <7675454e0804251059q75ef6d56mb719640953048431@mail.gmail.com> Message-ID: On Apr 25, 2008, at 12:59 PM, Shreevatsa R wrote: > Hi MacPorts developers, > > I was planning to write some non-trivial code before posting to this > list, but I thought I would first check if I was doing anything > stupid. > > I found that the "port deps" command only lists the explicit > dependencies of a port, and not everything that the port actually > depends on ("recursive dependencies"). This meant that often > installing something trivial looking would start pulling in something > enormous that I didn't want to install, and I would have to kill it, > or wait hours. Contrast this to something like Debian's apt (used by > Fink too), which when you try to install something, gives a message > like: > # apt-get install nautilus > Reading Package Lists... Done > Building Dependency Tree... Done > The following extra packages will be installed: > bonobo libmedusa0 libnautilus0 > The following NEW packages will be installed: > bonobo libmedusa0 libnautilus0 nautilus > 0 packages upgraded, 4 newly installed, 0 to remove and 1 not > upgraded. > Need to get 8329kB of archives. After unpacking 17.2MB will be > used. > Do you want to continue? [Y/n] > > So deciding that at least knowing all dependencies of a port > beforehand would help, I tried writing a command for recursive > dependencies. The proc action_deps does a lot of stuff, and it's not > easy getting just the list of dependencies with no extra output, so I > wrote my own "bare" proc that does the actual dependencies, etc., and > rdeps that recursively calls it: > > proc add_to_set {set_var item} { > upvar $set_var var > if {[lsearch -exact $var $item] == -1} { lappend var $item } > } > > proc actdeps {portname depstype} { > array unset portinfo > array set portinfo [lindex [mportsearch $portname no exact] 1] > > #set deps [map {x {lindex [split $x :] end}} $portinfo($depstype)] > set deps [] > if {[info exists portinfo($depstype)]} { > foreach i $portinfo($depstype) { > lappend deps [lindex [split $i :] end] > } > } > return $deps > } > > proc rdeps {portname {depth 0}} { > global shownports > if [info exists shownports] { } else { set shownports [] } > add_to_set shownports $portname > > set depstypes {depends_build depends_lib depends_run} > set depstypes_descr {"build" "library" "runtime"} > > foreach depstype $depstypes depsdecr $depstypes_descr { > foreach port [actdeps $portname $depstype] { > if {[lsearch $shownports $port] == -1} { > puts "[string repeat \t $depth]$port" > rdeps $port [expr {$depth + 1}] > } > } > } > } > > proc action_rdeps {action portlist opts} { > foreachport $portlist { > rdeps $portname > } > } > > And "rdeps action_rdeps" in action_array. Yeah, it uses a global > variable to avoid printing the same ports again, but it works: > > ~$ port rdeps subversion > expat > neon > gettext > libiconv > gperf > ncurses > ncursesw > openssl > zlib > apr > apr-util > db44 > sqlite3 > gawk > gmake > readline > > This is not great code, but it does what I want. (It is also the only > Tcl I have ever written, so please tell me what I'm doing stupidly.) > I was planning to do the same for variants (because I install > something and later discover I should have installed one of its > dependencies with a different variant), and for uninstall (because it > is a real pain to uninstall ports). > More specifically, I was planning to > (1) make a general (simple) function for getting a specific port's > "tree of dependencies" (and/or tree of dependents) and then something > to act on it. Uninstall would then be trivial. > (2) Also, putting something to return the list of dependencies of a > port in the MacPorts API itself. > (3) Also, looking at action_deps, it seems to share a lot in common > with other functions (searching for ports, etc.), so that part can be > cleaned up... > > Comments? Being able to get a recursive list of dependencies would certainly be useful. I wrote a PHP web page [1] to display a graph of this information, because I also wanted to see it. Would be handy to have the main logic in the port command. Should make it faster. [1] http://www.ryandesign.com/tmp/portviz.tar.bz2 From ryandesign at macports.org Sat Apr 26 02:09:17 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat Apr 26 02:06:31 2008 Subject: [36303] trunk/dports/www/yaws/Portfile In-Reply-To: <20080426075505.47EED15ED330@beta.macosforge.org> References: <20080426075505.47EED15ED330@beta.macosforge.org> Message-ID: <5C1E42AA-7178-41F8-92EA-40C80BB26132@macports.org> On Apr 26, 2008, at 2:55 AM, pguyot@kallisys.net wrote: > Revision: 36303 > http://trac.macosforge.org/projects/macports/changeset/36303 > Author: pguyot@kallisys.net > Date: 2008-04-26 00:55:04 -0700 (Sat, 26 Apr 2008) > > Log Message: > ----------- > www/yaws: added yapp variant for yapp application handler > > Modified Paths: > -------------- > trunk/dports/www/yaws/Portfile > > Modified: trunk/dports/www/yaws/Portfile > =================================================================== > --- trunk/dports/www/yaws/Portfile 2008-04-26 07:42:41 UTC (rev 36302) > +++ trunk/dports/www/yaws/Portfile 2008-04-26 07:55:04 UTC (rev 36303) > @@ -36,9 +36,20 @@ > reinplace "s|__PREFIX|${prefix}|g" ${worksrcpath}/src/ > yaws_config.erl > } > > +default_variants +yapp > + > configure.args --prefix=${prefix} \ > --sysconfdir=${prefix}/etc \ > --localstatedir=${prefix}/var > + > +variant yapp description {Yapp application handler} { > + post-build { > + system "cd ${worksrcpath}/applications/yapp && make && make docs" > + } > + post-destroot { > + system "cd ${worksrcpath}/applications/yapp && make install > DESTDIR=${destroot}" > + } > +} Why make it a variant? If it doesn't have extra dependencies, why not just make it all the time? If there is benefit in turning off, but you want it on by default, better to make it a no_yapp variant that turns it off, since there is a bug with user overrides of default_variants not being preserved during upgrades. Should increment port revision so everyone who has the port installed already gets yapp. From ryandesign at macports.org Sat Apr 26 02:35:05 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat Apr 26 02:32:15 2008 Subject: PHP5 XsltProcessor and apache segfault In-Reply-To: References: <5A6B9D99-3CBD-4701-85F4-80815AC1CAE0@macports.org> Message-ID: <6CB789B3-A2FD-4B02-B760-6C9DF775EBFD@macports.org> On Apr 26, 2008, at 3:55 AM, C?dric Luthi wrote: > On Apr 26, 2008, at 7:10 AM, Ryan Schmidt wrote: > >> Have you contacted the developers of libxml regarding this problem? > > Hello, > No, I have not contacted them but I'm not yet sure if they must be > contacted. > After reading this on the ticket: > "A simple php script was correctly executed with the CLI, and a > segmentation fault came out when using the libphp5.so." > > I wonder if libxml2 is the real culprit... > > I unfortunately don't have the time to install php5 and apache with > MacPorts to test myself. Someone thought the problem was that (from what I wrote earlier in the ticket) "/opt/local/lib/libxml2.dylib (version 9.31.0) and /usr/ lib/libxml2.dylib (version 9.16.0 (on Mac OS X 10.4.11)) claim to have the same compatibility version (9.0.0) though they are incompatible because they define the xmlURI struct differently." Maybe under some circumstances the one library gets used at build time but the other one gets used at runtime, causing the crash. I think it is a bug for libxml to modify is public interface but not increase its advertised compatibility version. I can't reproduce the problem with the given sample script in the description at the PHP command line or using the PHP FastCGI module under lighttpd. I'll compile Apache 2 and the PHP Apache module and see if I can get the problem to occur there. -Ryan From raimue at macports.org Sat Apr 26 07:20:13 2008 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Sat Apr 26 07:17:23 2008 Subject: Recursive dependencies, recursive uninstall, variants In-Reply-To: <7675454e0804251059q75ef6d56mb719640953048431@mail.gmail.com> References: <7675454e0804251059q75ef6d56mb719640953048431@mail.gmail.com> Message-ID: <48133A1D.6090904@macports.org> Shreevatsa R wrote: > Hi MacPorts developers, Hi, > I was planning to write some non-trivial code before posting to this > list, but I thought I would first check if I was doing anything > stupid. [snip] > So deciding that at least knowing all dependencies of a port > beforehand would help, I tried writing a command for recursive > dependencies. The proc action_deps does a lot of stuff, and it's not > easy getting just the list of dependencies with no extra output, so I > wrote my own "bare" proc that does the actual dependencies, etc., and > rdeps that recursively calls it: Yes, a --pretend feature is on the wish-list since a long time and would be really nice to have. [snip] > And "rdeps action_rdeps" in action_array. Yeah, it uses a global > variable to avoid printing the same ports again, but it works: > > ~$ port rdeps subversion > expat > neon > gettext > libiconv > gperf > ncurses > ncursesw > openssl > zlib > apr > apr-util > db44 > sqlite3 > gawk > gmake > readline This looks good. Of course the output could be a lot better... And how are you dealing with ports appearing multiple times? E.g. portA depends on portB and portC, and these two depend on portD. If portD depends on a lot of other ports you get a long list - twice. Don't know if that can be improved in the ascii output... But I don't like introducing a new command just for this. This should be port deps --follow-deps as discussed earlier. What I also would like (and I think Ryan would like it, too ;-)) is the possibility to output the dependency tree in the dot language for graphviz. So we could use something like this to get a nice graph: port deps --follow-deps --dot | dot -o depgraph.png Would also be cool to have such graphs on the website. > This is not great code, but it does what I want. (It is also the only > Tcl I have ever written, so please tell me what I'm doing stupidly.) > I was planning to do the same for variants (because I install > something and later discover I should have installed one of its > dependencies with a different variant), and for uninstall (because it > is a real pain to uninstall ports). Not sure what a mean with "variants". port deps currently does not take dependencies into account, because it is reading the PortIndex only. This makes it probably faster but this feature is missing. So to solve this one would have to [mportopen] all ports and their dependencies to get the dependencies list modified by variants. I don't quite understand why you call uninstalling ports a "real pain". What is the problem with that? > More specifically, I was planning to > (1) make a general (simple) function for getting a specific port's > "tree of dependencies" (and/or tree of dependents) and then something > to act on it. Uninstall would then be trivial. > (2) Also, putting something to return the list of dependencies of a > port in the MacPorts API itself. > (3) Also, looking at action_deps, it seems to share a lot in common > with other functions (searching for ports, etc.), so that part can be > cleaned up... Sounds like a good plan! Rainer From jmpp at macports.org Sat Apr 26 20:03:11 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Sat Apr 26 20:00:22 2008 Subject: New MacPorts release and immediate future plans Message-ID: <1146792E-1584-457C-A57F-16FD5F229F8B@macports.org> Evening all developers! First off, I'd like to apologize for being so inactive lately, a somewhat forced hiatus has kept me away from MacPorts, and most of my online life for that matter, for the last couple of months. I understand how that may seem like I've lost interest in the project, and in my PortMgr position, but I can assure you that's not the case. The issues that were holding me back have now been cleared to a large extent so I should be considerably more available from now on. I am glad to tell you that we've had some interesting activity lately, even though it may seem to most of you like things have largely stalled. I can assure you that's not the case either. In the past month those of us who volunteered to be GSoC08 mentors have been working hard to put together our summer plans, and I'm glad to say that things are looking interesting. I am most proud to inform that we received not only a high number of applications (always a good thing), but also some very solid ones from more capable students than we could harbor. As a result will be conducting development with our four alloted students on key areas of the mid to long term future of MacPorts: 1) Logging support, per my proposal at http://trac.macports.org/projects/macports/wiki/LoggingProposal (hopefully, as it is explicitly stated in the proposal itself, this work will help open up the doors to binary packaging done the right way, something that's been debated here quite a bit lately); 2) MacPorts Web Application (a.k.a. MPWA), which among other things will hopefully evolve to process the result of log submissions (task 1 above) to provide real time information of the status of our ports tree; 3) MacPorts Framework, an initiative to endow MacPorts with a high level API written in Cocoa to open up the doors to a myriad of possibilities, including things like a Cocoa GUI 4) Root privileges, to make safer and better use of the powers we're granted through sudo to run in a more secure environment We learned quite a bit from last year's GSoC experience, so this time round we're taking the necessary steps to ensure a proper use of resources and that the deliverables of this work are properly seen through to completion and integration into our shipping product. Now, as for the immediate future of MacPorts, I think we all agree the time is ripe (or more than) for a new quick release that'll incorporate many of the recent enhancements and bug fixes trunk has seen recently. I've been collecting ideas and roadmap suggestions for what should go into this new issue of MacPorts, but I have been away for a while and therefore it's easy for me to miss a thing or to. So I'd love to hear what any of you has to say about a still theoretical 1.6.5 release (what should go in, what should not, etc). And about the release number: I was originally aiming for a small 1.6.1 which never took place, and a lot has happened since but maybe not enough for a 1.7.0. The main issue with these numbers is that we're still not working on a release driven cycle; for that reason mostly, our release numbers are mostly meaningless at present and only indicative of where we feel we are on a very subjective timeline. This is something many have pointed out as in need of fixing, and I'd just like to say that I'm strongly seconding that initiative. We're not making any API incompatible changes at present, so our numbers will still be arbitrary to certain degree. But hopefully the work that will be put into GSoC and other initiatives too will give us enough material to at least conduct a feature-driven release cycle. In any case, I propose that from now on we also try to adopt a schedule for minor, bug fixing releases, even if a loose one, so that after a given number of weeks/months we force ourselves to re-evaluate the state of trunk and the current release branch to asses what is ready for general consumption and/or in need of a broader testing audience. This will also help us fight the perception of a stale project. What should that schedule be? What new features will go into major releases and which ones into minor releases? Hopefully answering those questions will encourage us to put our Trac roadmap to better use, something that has been criticized lately too. For the moment, I propose we do 1.6.5 with bug fixes against what's currently shipping in 1.6.0, including (but not limited to): -) my postflight installer bug (already fixed in the release_1_6 branch); -) what's been done on universal building and choosing of SDK && MDT; -) improved fetching code; -) improved dependency handling; -) improved selfupdate target (my part on this work is done). I'd love to hear feedback on any and all of the topics touched in this mail, but at least on what's relevant for 1.6.5. I'll create an appropriate milestone for this new release so that we can start classifying tickets accordingly. And this is already a bit of a long mail, as usual for me, so I'll cap it here and wait for your feedback, hoping you're not still soar at me for having disappeared! Regards,... -jmpp From ryandesign at macports.org Sun Apr 27 00:31:00 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun Apr 27 00:28:09 2008 Subject: New MacPorts release and immediate future plans In-Reply-To: <1146792E-1584-457C-A57F-16FD5F229F8B@macports.org> References: <1146792E-1584-457C-A57F-16FD5F229F8B@macports.org> Message-ID: <59F11B4B-8A54-4224-B1D5-CE6A978F2A63@macports.org> Welcome back, jmpp. I'm quite relieved to hear from you! I don't believe in these .5 releases for the sake of .5 releases... especially in the third digit. ("System 7.5" sounds cooler than "System 7.2" but "System 7.1.5" doesn't sound that much more impressive than "System 7.1.2".) Either call it 1.7.0 since it includes so much new stuff, or call it 1.6.1 since we're probably releasing from the 1.6 branch. The new release should include the greatly enhanced port lint code which is already trunk, and we should also resolve this port lint ticket before the release: http://trac.macosforge.org/projects/macports/ticket/14799 I would be happy to commit the three patches I attached there if you approve. \r On Apr 26, 2008, at 10:03 PM, Juan Manuel Palacios wrote: > > Evening all developers! > > First off, I'd like to apologize for being so inactive lately, a > somewhat forced hiatus has kept me away from MacPorts, and most of > my online life for that matter, for the last couple of months. I > understand how that may seem like I've lost interest in the > project, and in my PortMgr position, but I can assure you that's > not the case. The issues that were holding me back have now been > cleared to a large extent so I should be considerably more > available from now on. > > I am glad to tell you that we've had some interesting activity > lately, even though it may seem to most of you like things have > largely stalled. I can assure you that's not the case either. In > the past month those of us who volunteered to be GSoC08 mentors > have been working hard to put together our summer plans, and I'm > glad to say that things are looking interesting. > > I am most proud to inform that we received not only a high number > of applications (always a good thing), but also some very solid > ones from more capable students than we could harbor. As a result > will be conducting development with our four alloted students on > key areas of the mid to long term future of MacPorts: > > 1) Logging support, per my proposal at http://trac.macports.org/ > projects/macports/wiki/LoggingProposal (hopefully, as it is > explicitly stated in the proposal itself, this work will help open > up the doors to binary packaging done the right way, something > that's been debated here quite a bit lately); > > 2) MacPorts Web Application (a.k.a. MPWA), which among other things > will hopefully evolve to process the result of log submissions > (task 1 above) to provide real time information of the status of > our ports tree; > > 3) MacPorts Framework, an initiative to endow MacPorts with a high > level API written in Cocoa to open up the doors to a myriad of > possibilities, including things like a Cocoa GUI > > 4) Root privileges, to make safer and better use of the powers > we're granted through sudo to run in a more secure environment > > We learned quite a bit from last year's GSoC experience, so this > time round we're taking the necessary steps to ensure a proper use > of resources and that the deliverables of this work are properly > seen through to completion and integration into our shipping product. > > Now, as for the immediate future of MacPorts, I think we all agree > the time is ripe (or more than) for a new quick release that'll > incorporate many of the recent enhancements and bug fixes trunk has > seen recently. I've been collecting ideas and roadmap suggestions > for what should go into this new issue of MacPorts, but I have been > away for a while and therefore it's easy for me to miss a thing or > to. So I'd love to hear what any of you has to say about a still > theoretical 1.6.5 release (what should go in, what should not, etc). > > And about the release number: I was originally aiming for a small > 1.6.1 which never took place, and a lot has happened since but > maybe not enough for a 1.7.0. The main issue with these numbers is > that we're still not working on a release driven cycle; for that > reason mostly, our release numbers are mostly meaningless at > present and only indicative of where we feel we are on a very > subjective timeline. This is something many have pointed out as in > need of fixing, and I'd just like to say that I'm strongly > seconding that initiative. > > We're not making any API incompatible changes at present, so our > numbers will still be arbitrary to certain degree. But hopefully > the work that will be put into GSoC and other initiatives too will > give us enough material to at least conduct a feature-driven > release cycle. > > In any case, I propose that from now on we also try to adopt a > schedule for minor, bug fixing releases, even if a loose one, so > that after a given number of weeks/months we force ourselves to re- > evaluate the state of trunk and the current release branch to asses > what is ready for general consumption and/or in need of a broader > testing audience. This will also help us fight the perception of a > stale project. > > What should that schedule be? What new features will go into major > releases and which ones into minor releases? Hopefully answering > those questions will encourage us to put our Trac roadmap to better > use, something that has been criticized lately too. > > For the moment, I propose we do 1.6.5 with bug fixes against > what's currently shipping in 1.6.0, including (but not limited to): > > -) my postflight installer bug (already fixed in the release_1_6 > branch); > -) what's been done on universal building and choosing of SDK && MDT; > -) improved fetching code; > -) improved dependency handling; > -) improved selfupdate target (my part on this work is done). > > I'd love to hear feedback on any and all of the topics touched in > this mail, but at least on what's relevant for 1.6.5. I'll create > an appropriate milestone for this new release so that we can start > classifying tickets accordingly. > > And this is already a bit of a long mail, as usual for me, so I'll > cap it here and wait for your feedback, hoping you're not still > soar at me for having disappeared! > > Regards,... > > > -jmpp From afb at macports.org Sun Apr 27 02:21:54 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun Apr 27 02:19:00 2008 Subject: New MacPorts release and immediate future plans In-Reply-To: <1146792E-1584-457C-A57F-16FD5F229F8B@macports.org> References: <1146792E-1584-457C-A57F-16FD5F229F8B@macports.org> Message-ID: Juan Manuel Palacios wrote: > Now, as for the immediate future of MacPorts, I think we all agree > the time is ripe (or more than) for a new quick release that'll > incorporate many of the recent enhancements and bug fixes trunk has > seen recently. I've been collecting ideas and roadmap suggestions > for what should go into this new issue of MacPorts, but I have been > away for a while and therefore it's easy for me to miss a thing or > to. So I'd love to hear what any of you has to say about a still > theoretical 1.6.5 release (what should go in, what should not, etc). There probably needs to be a repackaging of the MacPorts 1.6 installer that includes the correct "postflight" (whether it is called 1.6.0p1 or 1.6.1 doesn't mattter much). Either that, or the Guide/instructions should be changed to include how to set up the PATH variable manually ? But that in itself doesn't need to get any more features, just help out with the initial MacPorts experience... > [...] > We're not making any API incompatible changes at present, so our > numbers will still be arbitrary to certain degree. But hopefully > the work that will be put into GSoC and other initiatives too will > give us enough material to at least conduct a feature-driven > release cycle. The only "API" changes is where a new variable is introduced into the Portfiles, such as the "requires root" setting for running as non- root, or the "license" or "configfiles" fields for making better packages. If these are used in ports, then a base needs to be released to match - at the same time or preferrably earlier. So those would probably still be reasons for doing a 1.7 or 1.8 > In any case, I propose that from now on we also try to adopt a > schedule for minor, bug fixing releases, even if a loose one, so > that after a given number of weeks/months we force ourselves to re- > evaluate the state of trunk and the current release branch to asses > what is ready for general consumption and/or in need of a broader > testing audience. This will also help us fight the perception of a > stale project. Wasn't the problem here that PKG installers of MacPorts base are only made for major releases ? So if there's a bug in say 1.7.0, then it "needs" a 1.8.0 just to fix it. (using patchlevels like 1.6.0p1 would also have worked though) Not sure if the new schedule allows for minor/bugfixes releases too, but otherwise it probably could need some "beta" or "RC" stage for the next installer package ? > What should that schedule be? What new features will go into major > releases and which ones into minor releases? Hopefully answering > those questions will encourage us to put our Trac roadmap to better > use, something that has been criticized lately too. > > For the moment, I propose we do 1.6.5 with bug fixes against > what's currently shipping in 1.6.0, including (but not limited to): > > -) my postflight installer bug (already fixed in the release_1_6 > branch); > -) what's been done on universal building and choosing of SDK && MDT; > -) improved fetching code; > -) improved dependency handling; > -) improved selfupdate target (my part on this work is done). The MDT change is a breaking one for Leopard, since it changes if libraries are built with flat or two-level namespace and such. There were bugs in older versions of glibtool (i.e. before 1.5.26) that caused it to pick the wrong settings, if you didn't explicitly say that you wanted to build for the current native OS version like the new base does (or were already setting a SDK/MDT such as when building Universal Binaries with the 10.4u sdk) So I think the +universal changes should go in 1.7.0 instead, hopefully after some more feedback and even review. The non-root changes like applications_dir and frameworks_dir could probably wait for the new Portfile setting, too. > I'd love to hear feedback on any and all of the topics touched in > this mail, but at least on what's relevant for 1.6.5. I'll create > an appropriate milestone for this new release so that we can start > classifying tickets accordingly. I think it needs a bugfix release (like 1.6.1) from "release_1_6" and eventually a major release (like 1.7.0) from current trunk - preferrably with the remaining items for "universal" (merging two arch builds) and "nonroot" (new setting for ports that *only* work as root, even if properly relocated) implemented. And then start on a 1.8... I think the biggest missing features in MacPorts are binary packages (avoid Xcode) and graphical interface (avoid Terminal), at least when compared to e.g. Fink. But I know that LoggingProposal and MacPorts_Framework are viewed as prerequisites for those two, so that's probably why they'll have to wait until after summer. Then those delivered foundations can be used for the Build Server (PKG) and the Cocoa Application (GUI) "for christmas". --anders From raimue at macports.org Sun Apr 27 07:12:02 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun Apr 27 07:09:08 2008 Subject: New MacPorts release and immediate future plans In-Reply-To: References: <1146792E-1584-457C-A57F-16FD5F229F8B@macports.org> Message-ID: <481489B2.3030900@macports.org> Anders F Bj?rklund wrote: > There probably needs to be a repackaging of the MacPorts 1.6 > installer that includes the correct "postflight" (whether it is > called 1.6.0p1 or 1.6.1 doesn't mattter much). Either that, or the > Guide/instructions should be changed to include how to set up the > PATH variable manually ? But that in itself doesn't need to get any > more features, just help out with the initial MacPorts experience... The guide already includes how to set up PATH manually. > Wasn't the problem here that PKG installers of MacPorts base are only > made for major releases ? So if there's a bug in say 1.7.0, then it > "needs" a 1.8.0 just to fix it. (using patchlevels like 1.6.0p1 would > also have worked though) Not sure if the new schedule allows for > minor/bugfixes releases too, but otherwise it probably could need > some "beta" or "RC" stage for the next installer package ? We did have three release candidates for 1.6.0. The problem might be that nobody really tested it on a clean Mac OS X installation and therefore we did not catch this bug... The main thing was that creating PKG installers is a bit more work to do, especially for all currently supported platforms (Panther, Tiger, Leopard). Last time it took us about a month to get a PKG installer for Panther, this time we should create and upload them before we announce the release. >> What should that schedule be? What new features will go into major >> releases and which ones into minor releases? Hopefully answering >> those questions will encourage us to put our Trac roadmap to better >> use, something that has been criticized lately too. >> >> For the moment, I propose we do 1.6.5 with bug fixes against >> what's currently shipping in 1.6.0, including (but not limited to): I see no sense in skipping 4 versions, let's do either 1.6.1 or 1.7.0. > I think it needs a bugfix release (like 1.6.1) from "release_1_6" and > eventually a major release (like 1.7.0) from current trunk - > preferrably with the remaining items for "universal" (merging two > arch builds) and "nonroot" (new setting for ports that *only* work > as root, even if properly relocated) implemented. And then start on a > 1.8... I think the biggest missing features in MacPorts are binary > packages (avoid Xcode) and graphical interface (avoid Terminal), at > least when compared to e.g. Fink. I don't think we can get rid of Xcode fully, variants allow a lot of combinations and we can't provide binary packages for each and every set of variants. Rainer From shreevatsa.public at gmail.com Sun Apr 27 23:51:36 2008 From: shreevatsa.public at gmail.com (Shreevatsa R) Date: Sun Apr 27 23:48:44 2008 Subject: Recursive dependencies, recursive uninstall, variants In-Reply-To: <48133A1D.6090904@macports.org> References: <7675454e0804251059q75ef6d56mb719640953048431@mail.gmail.com> <7675454e0804251059q75ef6d56mb719640953048431@mail.gmail.com> <48133A1D.6090904@macports.org> Message-ID: <20080428065135.GA23803@ashdown-one-thirty-eight.mit.edu> [Sorry if this gets sent twice; I sent it from the wrong address by mistake so I think the list rejected it.] Hello, I started replying to this and got busy, so excuse any discontinuity below: On Sat, Apr 26, 2008 at 12:15:17AM -0500, Ryan Schmidt wrote: > Being able to get a recursive list of dependencies would certainly be > useful. I wrote a PHP web page [1] to display a graph of this information, > because I also wanted to see it. Would be handy to have the main logic in > the port command. Should make it faster. > > [1] http://www.ryandesign.com/tmp/portviz.tar.bz2 Can't be too sure, this is Tcl after all ;-) I looked at what your PHP code does. I have separated out the different parts of it, and the port command can now (= if it is committed) produce DOT figures. See below. On Sat, Apr 26, 2008 at 04:20:13PM +0200, =?ISO-8859-1?Q?Rainer_M=FCller_ wrote: > Shreevatsa R wrote: >> Hi MacPorts developers, > > Hi, > > This looks good. Of course the output could be a lot better... And how are > you dealing with ports appearing multiple times? E.g. portA depends on > portB and portC, and these two depend on portD. If portD depends on a lot > of other ports you get a long list - twice. Don't know if that can be > improved in the ascii output... That's what I was using the global variable $shownports for -- to avoid displaying, and recursing on, portD after the first time. > But I don't like introducing a new command just for this. This should be > port deps --follow-deps as discussed earlier. Yes, it's too specialised to be a new command. However (more on this later), a general function for getting a port's tree (DAG, actually) of dependencies or dependents, is something that many different commands can use. That is, any command's --follow-deps would be equivalently got by running that command on this list. > What I also would like (and I think Ryan would like it, too ;-)) is the > possibility to output the dependency tree in the dot language for graphviz. > So we could use something like this to get a nice graph: > port deps --follow-deps --dot | dot -o depgraph.png > > Would also be cool to have such graphs on the website. >> I was planning to do the same for variants (because I install >> something and later discover I should have installed one of its >> dependencies with a different variant), and for uninstall (because it >> is a real pain to uninstall ports). > > Not sure what a mean with "variants". port deps currently does not take > dependencies into account, because it is reading the PortIndex only. This > makes it probably faster but this feature is missing. So to solve this one > would have to [mportopen] all ports and their dependencies to get the > dependencies list modified by variants. Oh, I didn't mean dependencies of variants (I know that's a much-wanted feature), I meant variants of dependencies. portA depends on portB, and portB has a useful variant that would not be shown by "port variants portA". I still dislike the idea of variants as "hidden features", but at least I can try unhiding them a bit... > I don't quite understand why you call uninstalling ports a "real pain". > What is the problem with that? ~$ port uninstall portA ---> Unable to portA, the following ports depend on it: ---> portB ---> portC ---> portD ---> portE ---> portF ---> portG ---> portH Error: port uninstall failed: Please uninstall the ports that depend on portA first. [Copy-and-paste the names one-by-one...] ~$ port uninstall portB portC portD portE portF portG portH portA ---> Uninstalling portB ---> Unable to uninstall portC, the following ports depend on it: ---> portD (etc.) [WTF? It's right there in the list, why can't you figure it out?] [Swap portC and portD] ~$ port uninstall portB portD portC portE portF portG portH portA Error: port uninstall failed: Registry error: portB not registered as installed. [Aaargh.] [Repeat many times.] Am I doing it incorrectly? Now, if `port dag --dept-list portA` were guaranteed to return a list of all installed dependents of portA in topologically sorted order, then `port uninstall $(port dag --dept-list portA)` would Just Work. (Of course, I don't care about the syntax, it could be `port uninstall --follow-deps portA`, all I mean is that a reusable function for dependencies or dependents would be useful.) >> More specifically, I was planning to >> (1) make a general (simple) function for getting a specific port's >> "tree of dependencies" (and/or tree of dependents) and then something >> to act on it. Uninstall would then be trivial. >> (2) Also, putting something to return the list of dependencies of a >> port in the MacPorts API itself. >> (3) Also, looking at action_deps, it seems to share a lot in common >> with other functions (searching for ports, etc.), so that part can be >> cleaned up... > > Sounds like a good plan! > > Rainer Here is some code; consider it proof-of-concept. It would be good if someone can tell me what changes to make and what to do to get it committed. This is how it works now (I'm using "dep" for dependencies and "dept" for dependents.) ~$ port dag --dep-list glib2 glib2 pkgconfig gettext expat libiconv ncurses gperf ncursesw ~$ port dag --dept-list glib2 glib2 atk libidl dbus-glib irssi py25-gobject dbus-python25 pango orbit2 shared-mime-info libbonobo gstreamer graphviz gtk2 tcllib libglade2 gtkspell2 py25-gtk gtimelog [This would be different on your system, of course.] ~$ port dag --dep-dot glib2 digraph MacPorts { "pkgconfig" -> "glib2" [style=dotted]; "gettext" -> "glib2" [style=solid]; "libiconv" -> "glib2" [style=solid]; "libiconv" -> "gettext" [style=solid]; "ncurses" -> "gettext" [style=solid]; "expat" -> "gettext" [style=solid]; "gperf" -> "libiconv" [style=dotted]; "ncursesw" -> "ncurses" [style=dashed]; } ~$ port dag --dept-dot glib2 digraph MacPorts { "glib2" -> "py25-gobject" [style=solid]; "glib2" -> "atk" [style=solid]; "glib2" -> "pango" [style=solid]; [... snip ... ] "gtk2" -> "py25-gtk" [style=solid]; "orbit2" -> "libbonobo" [style=solid]; "py25-gtk" -> "gtimelog" [style=solid]; } The last two produce pretty pictures when passed through graphviz. Code follows; I haven't bothered making it into patch format or anything, but it goes into port.tcl: ##################################################################################### proc alldeps {portname} { #Return list of the form {type1 {ports} type2 {ports} ... } array set portinfo [lindex [mportsearch $portname no exact] 1] set alldeps [] foreach type {depends_build depends_lib depends_run} { if {[info exists portinfo($type)]} { #set curdeps [map {x {lindex [split $x :] end}} $portinfo($type)] set curdeps [] foreach i $portinfo($type) { #$i looks like port:gtk2 or bin:tex:texlive lappend curdeps [lindex [split $i :] end] } lappend alldeps $type lappend alldeps $curdeps } } return $alldeps } proc alldepts {portname} { #Return list of dependents, of the form {type1 {ports} type2 {ports} ... } array set depts [] registry::open_dep_map set rawdepts [join [registry::list_dependents $portname]] foreach {this type that} $rawdepts { if {$this == $portname} { lappend depts($type) $that } else { ui_error "Unrecognised entry {{$this} {$type} {$that}} in dependents of $portname" } } return [array get depts] } proc DAGedges {neighfunc portname} { #Given function that returns neighbours of form {type1 {ports} type2 {ports} ... }, #repeatedly call it, and return DAG as {name1 {type {ports} ... } name2 {type {ports} ... }} array set neighbours [] set queue [list $portname] while {[llength $queue] > 0} { set portname [lindex $queue 0] set queue [lrange $queue 1 end] set neighbours($portname) [$neighfunc $portname] foreach {type ports} $neighbours($portname) { foreach port $ports { if {![info exists neighbours($port)]} {lappend queue $port} } } } return [array get neighbours] } proc dotDAG {dag {rev 0}} { #Given a DAG (as above), output DOT format description set dot "digraph MacPorts \{ \n" array set style {depends_build dotted depends_lib solid depends_run dashed port solid lib dashed} #append dot [subst -nocomm {edge [len=2.75]; \n}] #append dot [subst -nocomm {node [fontsize=10]; \n}] foreach {port neighs} $dag { foreach {type ports} $neighs { foreach neighbour $ports { if {$rev} { append dot [subst {"$neighbour" -> "$port"}] } else { append dot [subst {"$port" -> "$neighbour"}] } if [info exists style($type)] { append dot [subst -nocomm { [style=$style($type)]}] } append dot "; \n" } } } append dot "\} \n" return $dot } proc toposortDAG {dag} { #Given a DAG (as above), return a list of nodes in topologically sorted order #Algorithm: Compute indegrees, remove nodes of indegree 0, repeat. #This probably sucks on the Tcl structures we're using; it's probably faster to do DFSes and order by finish time array set neigh $dag array set indegree [] set ret [] foreach {port neighs} $dag { if {![info exists indegree($port)]} {set indegree($port) 0} foreach {type ports} $neighs { foreach neighbour $ports { if {![info exists indegree($neighbour)]} { set indegree($neighbour) 1 } else { incr indegree($neighbour) } } } } while {[array size indegree] > 0} { foreach node [array names indegree] { if {$indegree($node) == 0} { array unset indegree $node lappend ret $node foreach {type ports} $neigh($node) { foreach neighbour $ports { incr indegree($neighbour) -1 } } } } } return $ret } proc action_dag {action portlist opts} { set opt [lindex $opts 0] foreachport $portlist { if {"$opt" == "ports_dag_dep-dot"} { puts [dotDAG [DAGedges alldeps $portname] 1] } elseif {"ports_dag_dept-dot" eq "$opt"} { puts [dotDAG [DAGedges alldepts $portname]] } elseif {"ports_dag_dep-list" == $opt} { puts [toposortDAG [DAGedges alldeps $portname]] } elseif {$opt == "ports_dag_dept-list"} { puts [toposortDAG [DAGedges alldepts $portname]] } else { ui_error "I have no idea what $opt means" } } } ##################################################################################### Thanks, Shreevatsa From raimue at macports.org Mon Apr 28 03:07:29 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon Apr 28 03:04:32 2008 Subject: Recursive dependencies, recursive uninstall, variants In-Reply-To: <20080428064420.GA24558@ashdown-two-fifty-seven.mit.edu> References: <7675454e0804251059q75ef6d56mb719640953048431@mail.gmail.com> <48133A1D.6090904@macports.org> <7675454e0804251059q75ef6d56mb719640953048431@mail.gmail.com> <20080428064420.GA24558@ashdown-two-fifty-seven.mit.edu> Message-ID: <4815A1E1.5090709@macports.org> Shreevatsa R wrote: > On Sat, Apr 26, 2008 at 04:20:13PM +0200, =?ISO-8859-1?Q?Rainer_M=FCller_ wrote: >> Shreevatsa R wrote: >>> Hi MacPorts developers, >> Hi, >> >> This looks good. Of course the output could be a lot better... And how are >> you dealing with ports appearing multiple times? E.g. portA depends on >> portB and portC, and these two depend on portD. If portD depends on a lot >> of other ports you get a long list - twice. Don't know if that can be >> improved in the ascii output... > > That's what I was using the global variable $shownports for -- to avoid > displaying, and recursing on, portD after the first time. Which is a bit unexpected. At least we should mark this port because the real tree is already in the output above. Otherwise one could read this as "portD has no dependencies". >>> I was planning to do the same for variants (because I install >>> something and later discover I should have installed one of its >>> dependencies with a different variant), and for uninstall (because it >>> is a real pain to uninstall ports). [snip] >> I don't quite understand why you call uninstalling ports a "real pain". >> What is the problem with that? > > ~$ port uninstall portA > ---> Unable to portA, the following ports depend on it: > ---> portB > ---> portC > ---> portD > ---> portE > ---> portF > ---> portG > ---> portH > Error: port uninstall failed: Please uninstall the ports that depend on portA first. This already got better in trunk, port uninstall --follow-dependents is possible. > [Copy-and-paste the names one-by-one...] > ~$ port uninstall portB portC portD portE portF portG portH portA > ---> Uninstalling portB > ---> Unable to uninstall portC, the following ports depend on it: > ---> portD (etc.) Oh yes, the topological sort is missing here which should be done automatically. > [WTF? It's right there in the list, why can't you figure it out?] > [Swap portC and portD] > ~$ port uninstall portB portD portC portE portF portG portH portA > Error: port uninstall failed: Registry error: portB not registered as installed. > [Aaargh.] > [Repeat many times.] > > Am I doing it incorrectly? > > Now, if `port dag --dept-list portA` were guaranteed to return a list of all installed > dependents of portA in topologically sorted order, then > `port uninstall $(port dag --dept-list portA)` would Just Work. (Of course, I > don't care about the syntax, it could be `port uninstall --follow-deps portA`, > all I mean is that a reusable function for dependencies or dependents would be > useful.) No need for an extra function, just sort the list for port uninstall in topological order before beginning to uninstall. The real problem here is the implementation which just uses foreachport in the given order from the command line. And maybe don't error out completely if a port is not installed... > Here is some code; consider it proof-of-concept. It would be good if someone > can tell me what changes to make and what to do to get it committed. > > This is how it works now (I'm using "dep" for dependencies and "dept" for > dependents.) > > ~$ port dag --dep-list glib2 > glib2 pkgconfig gettext expat libiconv ncurses gperf ncursesw So why a new target again...? We already have `port deps' and `port dependents' and these two should be improved instead of rewritten with a new name. [Did not have time to try the code yet]. Rainer From rlonstein at pobox.com Mon Apr 28 08:37:28 2008 From: rlonstein at pobox.com (R. Lonstein) Date: Mon Apr 28 08:28:36 2008 Subject: new submissions 14430, 14432 still unassigned Message-ID: <20080428153728.GD59190@beryl.lonsteins.com> In February I submitted two new ports, tickets #14430 and 14432 but they are still unassigned. Before I submit a few more similar ones can someone take a look? Thanks. - Ross From shreevatsa.public at gmail.com Mon Apr 28 10:07:03 2008 From: shreevatsa.public at gmail.com (Shreevatsa R) Date: Mon Apr 28 10:04:16 2008 Subject: Recursive dependencies, recursive uninstall, variants In-Reply-To: <4815A1E1.5090709@macports.org> References: <7675454e0804251059q75ef6d56mb719640953048431@mail.gmail.com> <48133A1D.6090904@macports.org> <7675454e0804251059q75ef6d56mb719640953048431@mail.gmail.com> <20080428064420.GA24558@ashdown-two-fifty-seven.mit.edu> <4815A1E1.5090709@macports.org> Message-ID: <20080428170700.GA23927@ashdown-five-ninety-three.mit.edu> On Mon, Apr 28, 2008 at 12:07:29PM +0200, =?ISO-8859-1?Q?Rainer_M=FCller_ wrote: > Shreevatsa R wrote: >> On Sat, Apr 26, 2008 at 04:20:13PM +0200, =?ISO-8859-1?Q?Rainer_M=FCller_ wrote: >>> Shreevatsa R wrote: >>>> Hi MacPorts developers, >>> Hi, >>> >>> This looks good. Of course the output could be a lot better... And how >>> are you dealing with ports appearing multiple times? E.g. portA depends >>> on portB and portC, and these two depend on portD. If portD depends on a >>> lot of other ports you get a long list - twice. Don't know if that can be >>> improved in the ascii output... >> >> That's what I was using the global variable $shownports for -- to avoid >> displaying, and recursing on, portD after the first time. > > Which is a bit unexpected. At least we should mark this port because the > real tree is already in the output above. Otherwise one could read this as > "portD has no dependencies". Yes, that output format was some random compromise between a plain list format and the fully informative DOT format. (And the new code I sent doesn't have that output format.) So it's not relevant now. >> Now, if `port dag --dept-list portA` were guaranteed to return a list of all installed >> dependents of portA in topologically sorted order, then `port uninstall >> $(port dag --dept-list portA)` would Just Work. (Of course, I >> don't care about the syntax, it could be `port uninstall --follow-deps portA`, >> all I mean is that a reusable function for dependencies or dependents would be >> useful.) > > No need for an extra function, just sort the list for port uninstall in > topological order before beginning to uninstall. The real problem here is > the implementation which just uses foreachport in the given order from the > command line. > > And maybe don't error out completely if a port is not installed... Yes, here is what I think the behaviour of uninstall should be: Since one cannot possibly uninstall without following dependents, make it follow dependents by default. So when given a list of ports, it exhaustively finds all dependents of all of them, and then does a topo-sort on this entire list, informs the user which ports it is going to uninstall, and asks for confirmation (if the list is bigger than the user's original list, say). >> Here is some code; consider it proof-of-concept. It would be good if someone >> can tell me what changes to make and what to do to get it committed. >> >> This is how it works now (I'm using "dep" for dependencies and "dept" for >> dependents.) > > >> ~$ port dag --dep-list glib2 >> glib2 pkgconfig gettext expat libiconv ncurses gperf ncursesw > > So why a new target again...? We already have `port deps' and `port > dependents' and these two should be improved instead of rewritten with a > new name. Sigh. I said above that I don't care about the command, and consider it "proof-of-concept". This code was just to demonstrate that it is possible and easy to have operations work on the entire DAG, and I used a new command because I didn't want to touch existing ones. The reason is: 1. I'm sending code over email for someone to use / comment on, and it's more convenient to paste new code than to indicate modifications to existing code, since I'm not working with version control or anything, 2. The existing commands have a lot of code that shouldn't be in them, such as generic 'searching for ports', and UI, that should rightfully be in another function, etc. I don't want to add to the mess. The actual command that the user sees can be whatever you want; I was just submitting the "functionality" and seeking comments on it. You must realise that my situation is not the same as that of a committer, who can simply do the right thing, clean up code, move it where it belongs, etc. :) Thanks, Shreevatsa From wsiegrist at apple.com Mon Apr 28 11:59:24 2008 From: wsiegrist at apple.com (William Siegrist) Date: Mon Apr 28 11:57:51 2008 Subject: new submissions 14430, 14432 still unassigned In-Reply-To: <20080428153728.GD59190@beryl.lonsteins.com> References: <20080428153728.GD59190@beryl.lonsteins.com> Message-ID: <0383F3EC-7A7C-4DD5-85F3-CB3B1DF995E0@apple.com> On Apr 28, 2008, at 8:37 AM, R. Lonstein wrote: > In February I submitted two new ports, tickets #14430 and 14432 but > they are > still unassigned. Before I submit a few more similar ones can > someone take a > look? I accepted the tickets and will take a look at them in the next day or two. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080428/b61f9990/smime.bin From wsiegrist at apple.com Tue Apr 29 21:02:12 2008 From: wsiegrist at apple.com (William Siegrist) Date: Tue Apr 29 21:00:33 2008 Subject: Trac/SVN Changes in Progress Message-ID: <1516BF9B-69E6-4AD0-958B-C7A52532EFBD@apple.com> [Cross-posting for maximum coverage, please reply-all with care] I'm in the process of migrating to the new auth/trac/svn system for MacPorts. So right now, trac.macports.org should be using shorter URLs (minus the /projects/macports/ portion of the URI), however, you may find that login/logout are broken. For the old, stable behavior, for now, continue to browse via . Once some DNS changes propagate, I can deploy the last bit of the new system which will clean everything up (should happen by the end of the week). Once I declare the move complete, please start filing tickets for anything that doesnt work for you (or for additional improvements you would like to see). Thank you for your patience during our maintenance. ---- William Siegrist Mac OS Forge http://macosforge.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080429/74afaa40/smime.bin From lists-macports at shopwatch.org Wed Apr 30 10:23:26 2008 From: lists-macports at shopwatch.org (Jay Levitt) Date: Wed Apr 30 10:20:20 2008 Subject: HOWTO: Get started, gain macports-foo, make bad first impression Message-ID: <4818AB0E.50702@shopwatch.org> [Note to self: MacBook Pro enter key is very, very close to left-arrow key. Sorry about that.] I don't expect to become a port maintainer, but I do find myself running into port bugs that already have fixes in trunk, or that I know how to fix. If nothing else, I'm usually able to build a package successfully from source, which means that I should, in theory, be able to integrate the latest source into macports. But I have absolutely no idea how to go about incorporating others' fixes, or trying and submitting my own. And the FAQ doesn't have a "how can I get involved" section. Any tips/pointers? For example: I just tried installing jigdo. That port relies on libwww, which is currently broken for some configurations. Ticket #12851 (http://trac.macosforge.org/projects/macports/ticket/12851) fixes this, and it refers to changeset r34520, a patch to trunk/dports/www/libwww/Portfile. I applied that change to my local copy of the Portfile, in /opt/local/var/macports/sources/rsync.macforge.org/release/ports/www/libwww. That didn't make MacPorts happy; now I get: bash-3.2# port clean libwww Portfile changed since last build; discarding previous state. ---> Cleaning libwww bash-3.2# port install libwww ---> Fetching libwww ---> Attempting to fetch patch-configure.diff from http://svn.macports.org/repository/macports/distfiles/libwww ---> Attempting to fetch patch-configure.diff from http://svn.macports.org/repository/macports/distfiles/general/ ---> Attempting to fetch patch-configure.diff from http://svn.macports.org/repository/macports/downloads/libwww Error: Target org.macports.fetch returned: fetch failed Error: Status 1 encountered during processing. Soooo... 1. What's the right way for an end-user-slash-developer to incorporate bug fixes into my local copy? 2. What's the best way for me to contribute when I find problems like this? As an end-user, the current MacPorts site is confusing. Knowing that each port is maintained by some individual (or, often, nobody at all), I'd expect to be able to find a list of ports, click on it, and see the latest version, some info about the port, a list of related bugs, etc. Instead, all the bugs are in a single Trac database. If I go to "Available Ports", and enter "libwww" in the search field, I see "libwww" as one of the two choices. I click on libwww and get... Trac's pretty-print of the Portfile from SVN. So: 3. Are there any ongoing projects to create a better, er, port-al? 4. I saw a discussion about parallel builds, and how you can't enable them by default. Does "port" send any phone-home info about build failures/successes? Is that under consideration? It seems to me that the best solution for this, and for any breaking change, would be to allow end users to opt-in and become part of the macports "build farm". Instead of a yes/no flag for parallel builds, add a third state: experimental. Experimental would build everything in parallel, run the unit tests, and report back to macosforge. If we see it working on enough "supported platforms", we could flip the Big Switch and move that to the stable distribution. In fact, now that I think about it, this could help a lot of the problems I've run into, all of which appear to be "no longer works on the latest OS/hardware/whatever but the port maintainer doesn't run that". Thoughts? Jay Levitt From dluke at geeklair.net Wed Apr 30 11:46:36 2008 From: dluke at geeklair.net (Daniel J. Luke) Date: Wed Apr 30 11:43:26 2008 Subject: HOWTO: Get started, gain macports-foo, make bad first impression In-Reply-To: <4818AB0E.50702@shopwatch.org> References: <4818AB0E.50702@shopwatch.org> Message-ID: <1B8EA38A-D808-4006-AEEC-19D489D533DE@geeklair.net> On Apr 30, 2008, at 1:23 PM, Jay Levitt wrote: > But I have absolutely no idea how to go about incorporating others' > fixes, or trying and submitting my own. And the FAQ doesn't have a > "how can I get involved" section. Any tips/pointers? Have you read the guide? (http://guide.macports.org) > For example: I just tried installing jigdo. That port relies on > libwww, which is currently broken for some configurations. Ticket > #12851 (http://trac.macosforge.org/projects/macports/ticket/12851) > fixes this, and it refers to changeset r34520, a patch to trunk/ > dports/www/libwww/Portfile. That ticket is marked as fixed and checked in in r34520, so you just need to do 'port selfupdate' or 'port sync' to make sure you have the latest Portfile and you'll already have that fix. > 1. What's the right way for an end-user-slash-developer to > incorporate bug fixes into my local copy? it really depends on the workflow you want. One way would be to set up a local portfile repository and put your fixes in there while you test them (the guide describes how to do this), another way would be to check out a copy of the portfiles from svn and point Macports to those portfiles. You can even do what you did earlier and modify the portfile that macports has already put on your machine (although the next selfupdate or sync you do will get rid of your local changes, then) > 2. What's the best way for me to contribute when I find problems > like this? File bugs in trac and assign (or CC) them to the maintainer of the port. It's especially helpful if you've figured out how to fix it and have a patch that you can attach to the bug. If it's for a port that currently doesn't have a maintainer, it would be great if you would be willing to maintain the port! > 4. I saw a discussion about parallel builds, and how you can't > enable them by default. Does "port" send any phone-home info about > build failures/successes? nope > Is that under consideration? I don't think anyone is working on anything like that, there was some discussion in the past, with the takeaway that it would need to be off by default and optionally opt-in if it were something that was even going to be added. > It seems to me that the best solution for this, and for any breaking > change, would be to allow end users to opt-in and become part of the > macports "build farm". Instead of a yes/no flag for parallel > builds, add a third state: experimental. Experimental would build > everything in parallel, run the unit tests, Not ever port has tests available from the upstream, and not every end user has a 'clean' build environment (so this would also require either getting chroot/trace mode/whatever build environment working well enough to make it the default, and probably storing state other than OK/Not OK - since ports could build fine but not work, and it would be difficult to test every port that doesn't already have a comprehensive test suite). > and report back to macosforge. If we see it working on enough > "supported platforms", we could flip the Big Switch and move that to > the stable distribution. There is currently no stable/unstable distinction for portfiles. I think it would be nice to have something like this, where we have some state associated with each port that would give an indication of what systems the port has been successfully built on (and maybe eventually where it works correctly). If we combined it with some way for multiple versions of the portfile to be available to the end-user they could choose to install the 'newest' portfile, the newest one that has been build tested on similar hardware, or an older version. Of course, if we end up getting binary packages working well, we might not need any of this support infrastructure. > In fact, now that I think about it, this could help a lot of the > problems I've run into, all of which appear to be "no longer works > on the latest OS/hardware/whatever but the port maintainer doesn't > run that". > > Thoughts? If you've got the time, it would be great if you would check out the macports code, and try to get (at least some of) your ideas working. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080430/19ec9dfd/PGP.bin From ryandesign at macports.org Wed Apr 30 15:14:06 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Apr 30 15:11:02 2008 Subject: HOWTO: Get started, gain macports-foo, make bad first impression In-Reply-To: <1B8EA38A-D808-4006-AEEC-19D489D533DE@geeklair.net> References: <4818AB0E.50702@shopwatch.org> <1B8EA38A-D808-4006-AEEC-19D489D533DE@geeklair.net> Message-ID: On Apr 30, 2008, at 1:46 PM, Daniel J. Luke wrote: > On Apr 30, 2008, at 1:23 PM, Jay Levitt wrote: > >> But I have absolutely no idea how to go about incorporating >> others' fixes, or trying and submitting my own. And the FAQ >> doesn't have a "how can I get involved" section. Any tips/pointers? > > Have you read the guide? (http://guide.macports.org) > >> For example: I just tried installing jigdo. That port relies on >> libwww, which is currently broken for some configurations. Ticket >> #12851 (http://trac.macosforge.org/projects/macports/ticket/12851) >> fixes this, and it refers to changeset r34520, a patch to trunk/ >> dports/www/libwww/Portfile. > > That ticket is marked as fixed and checked in in r34520, so you > just need to do 'port selfupdate' or 'port sync' to make sure you > have the latest Portfile and you'll already have that fix. Right. Although the repository URL to the dports tree contains "trunk", there are no branches of dports. The one in "trunk" is the only copy, and it's the one all installations of MacPorts sync with. (Well, they sync with an rsync server which mirrors the dports tree from trunk, with up to 30 minutes delay.) >> 1. What's the right way for an end-user-slash-developer to >> incorporate bug fixes into my local copy? For bugs which have been fixed, simply "sudo port selfupdate" or "sudo port sync" to retrieve the changed portfile. The portindex is only regenerated every 12 hours so if e.g. a port version has been updated, you might not see that change in "port outdated" for up to 12 hours. For bugs which have not yet been fixed in the repository, do what Daniel said: > it really depends on the workflow you want. > > One way would be to set up a local portfile repository and put your > fixes in there while you test them (the guide describes how to do > this), another way would be to check out a copy of the portfiles > from svn and point Macports to those portfiles. > > You can even do what you did earlier and modify the portfile that > macports has already put on your machine (although the next > selfupdate or sync you do will get rid of your local changes, then) > >> 2. What's the best way for me to contribute when I find problems >> like this? > > File bugs in trac and assign (or CC) them to the maintainer of the > port. > > It's especially helpful if you've figured out how to fix it and > have a patch that you can attach to the bug. > > If it's for a port that currently doesn't have a maintainer, it > would be great if you would be willing to maintain the port! > >> 4. I saw a discussion about parallel builds, and how you can't >> enable them by default. Does "port" send any phone-home info >> about build failures/successes? > > nope > >> Is that under consideration? > > I don't think anyone is working on anything like that, there was > some discussion in the past, with the takeaway that it would need > to be off by default and optionally opt-in if it were something > that was even going to be added. > >> It seems to me that the best solution for this, and for any >> breaking change, would be to allow end users to opt-in and become >> part of the macports "build farm". Instead of a yes/no flag for >> parallel builds, add a third state: experimental. Experimental >> would build everything in parallel, run the unit tests, > > Not ever port has tests available from the upstream, and not every > end user has a 'clean' build environment (so this would also > require either getting chroot/trace mode/whatever build environment > working well enough to make it the default, and probably storing > state other than OK/Not OK - since ports could build fine but not > work, and it would be difficult to test every port that doesn't > already have a comprehensive test suite). The other problem with parallel builds is that they are not identical each time you run them. The build may succeed 3 times, then fail the 4th. I personally haven't had the time to try to build each of my ports several times with parallel build on to see if they repeatably build correctly. >> and report back to macosforge. If we see it working on enough >> "supported platforms", we could flip the Big Switch and move that >> to the stable distribution. > > There is currently no stable/unstable distinction for portfiles. > > I think it would be nice to have something like this, where we have > some state associated with each port that would give an indication > of what systems the port has been successfully built on (and maybe > eventually where it works correctly). If we combined it with some > way for multiple versions of the portfile to be available to the > end-user they could choose to install the 'newest' portfile, the > newest one that has been build tested on similar hardware, or an > older version. > > Of course, if we end up getting binary packages working well, we > might not need any of this support infrastructure. Sounds nice to me. But how would we learn what port works on what OS / architecture? I had proposed last year the idea of MacPorts automatically sending information back to the mothership regarding what ports people had installed on what OS and what architecture, which could be used to determine which ports actually work, and could also show port popularity. I thought this would make for an interesting front-page www.macports.org display, showing the most popular ports. But several people didn't want MacPorts reporting this information: http://lists.macosforge.org/pipermail/macports-dev/2007-May/001604.html Maybe we should revisit this topic, though like you say, if we get binary packages, then we don't need build success/failure statistics from each user, but only from the build servers. >> In fact, now that I think about it, this could help a lot of the >> problems I've run into, all of which appear to be "no longer works >> on the latest OS/hardware/whatever but the port maintainer doesn't >> run that". >> >> Thoughts? > > If you've got the time, it would be great if you would check out > the macports code, and try to get (at least some of) your ideas > working.