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