April 2007 - macports-dev - lists.macosforge.org

Re: [23516] trunk/dports/x11/XFree86/Portfile
by Yves de Champlain 03 Apr '07

03 Apr '07

Le 07-04-03 à 12:46, Mark Duling a écrit : > macports-dev(a)lists.macosforge.org on Tuesday, April 3, 2007 at 9:30 AM > -0800 wrote: >> Revision >> [ http://trac.macosforge.org/projects/macports/changeset/23516 ]23516 >> Author >> yves(a)macports.org >> Date >> 2007-04-03 09:30:46 -0700 (Tue, 03 Apr 2007) >> >> Log Message >> >> Make a more complete check : >> for Apple X11 with or without X11SDK (ticket:6188) >> for Apple X11SDK without X11 (ticket:10238) >> Also good for ticket:1551 > > Great. Can any of the other three related to XFree be closed? > > http://trac.macosforge.org/projects/macports/ticket/2102 This one is about Xorg. Xorg 7.2 supports GNU Hurd and Windows but still not darwin ... I wonder if we should not dump it altogether. Maybe do the same for Xfree86_44 ? > http://trac.macosforge.org/projects/macports/ticket/3073 Don't know, I haven't tried. But it looks like a very weird idea to me. I mean, what can it give except loads of problems ? But I'm still young and naive ... > http://trac.macosforge.org/projects/macports/ticket/5065 Closed. I did not think it was still open, never was a good idea anyway. Thanks yves

2 2

Re: [23516] trunk/dports/x11/XFree86/Portfile
by markd＠macports.org 03 Apr '07

03 Apr '07

macports-dev(a)lists.macosforge.org on Tuesday, April 3, 2007 at 9:30 AM -0800 wrote: >Revision >[ http://trac.macosforge.org/projects/macports/changeset/23516 ]23516 >Author >yves(a)macports.org >Date >2007-04-03 09:30:46 -0700 (Tue, 03 Apr 2007) > >Log Message > >Make a more complete check : >for Apple X11 with or without X11SDK (ticket:6188) >for Apple X11SDK without X11 (ticket:10238) >Also good for ticket:1551 Great. Can any of the other three related to XFree be closed? http://trac.macosforge.org/projects/macports/ticket/2102 http://trac.macosforge.org/projects/macports/ticket/3073 http://trac.macosforge.org/projects/macports/ticket/5065 Mark

1 0

Re: [23511] trunk/dports/x11/XFree86
by markd＠macports.org 03 Apr '07

03 Apr '07

macports-dev(a)lists.macosforge.org on Tuesday, April 3, 2007 at 5:50 AM -0800 wrote: >Revision >[ http://trac.macosforge.org/projects/macports/changeset/23511 ]23511 >Author >yves(a)macports.org >Date >2007-04-03 05:50:24 -0700 (Tue, 03 Apr 2007) > >Log Message > >XFree86 4.6.0 with joyful enhancements like : > >* warn about a pre-existing Apple X11 installation before even fetching >the sources. >* include freetype and security patches from fink Nice! Will it detect when Apple's X11 is installed *without* X11DSK? Or the reverse, which I think is the purpose of this proposed solution in Trac. http://trac.macosforge.org/projects/macports/attachment/ticket/10238/patch-… Mark

2 1

Re: [23503] trunk/dports/gnome
by Randall Wood 03 Apr '07

03 Apr '07

can you put a note (even if only in comments) about why you are splitting libgtkhtml into versioned ports into the Portfile? On 3 Apr 2007, at 04:24, source_changes(a)macosforge.org wrote: > Revision 23503 Author mas(a)macports.org Date 2007-04-03 01:24:52 > -0700 (Tue, 03 Apr 2007) Log Message NEW: libgtkhtml312 3.12.2 > Added Paths > trunk/dports/gnome/libgtkhtml312/ > trunk/dports/gnome/libgtkhtml312/Portfile > Diff > Added: trunk/dports/gnome/libgtkhtml312/Portfile (0 => 23503) --- > trunk/dports/gnome/libgtkhtml312/Portfile (rev 0) +++ trunk/dports/ > gnome/libgtkhtml312/Portfile 2007-04-03 08:24:52 UTC (rev 23503) @@ > -0,0 +1,25 @@ +# $Id$ +PortSystem 1.0 +name libgtkhtml312 +version > 3.12.2 +description GTK HTML rendering engine. +long_description > GtkHTML is a lightweight HTML rendering/printing/editing \ + > engine. It was originally based on KHTMLW, part of the \ + KDE > project, but is now being developed independently. +maintainers > mas(a)macports.org +categories gnome +platforms darwin +homepage > http://www.gnome.org/ +master_sites gnome:sources/gtkhtml/3.12/ > +distname gtkhtml-${version} +use_bzip2 yes + +checksums rmd160 > c8445d3e8893c0d99da1d153e984d5f567ff1a08 + +depends_lib \ + > lib:gailutil:gail \ + port:libgnomeui \ + port:dbus \ + port:dbus- > glib + +configure.env GMSGFMT=${prefix}/bin/msgfmt Property changes > on: trunk/dports/gnome/libgtkhtml312/Portfile > ___________________________________________________________________ > Name: svn:keywords + Id Name: svn:eol-style + native > _______________________________________________ > macports-changes mailing list > macports-changes(a)lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-changes Randall Wood rhwood(a)mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."

2 1

Re: [23505] trunk/dports/gnome/libgtkhtml312/Portfile
by Randall Wood 03 Apr '07

03 Apr '07

Thank you. On 3 Apr 2007, at 04:38, source_changes(a)macosforge.org wrote: > Revision 23505 Author mas(a)macports.org Date 2007-04-03 01:38:54 > -0700 (Tue, 03 Apr 2007) Log Message explain why the versioned port > is required, as requested by Randall Wood Modified Paths > trunk/dports/gnome/libgtkhtml312/Portfile > Diff > Modified: trunk/dports/gnome/libgtkhtml312/Portfile (23504 => > 23505) --- trunk/dports/gnome/libgtkhtml312/Portfile 2007-04-03 > 08:28:24 UTC (rev 23504) +++ trunk/dports/gnome/libgtkhtml312/ > Portfile 2007-04-03 08:38:54 UTC (rev 23505) @@ -4,8 +4,13 @@ > version 3.12.2 description GTK HTML rendering engine. > long_description GtkHTML is a lightweight HTML rendering/printing/ > editing \ - engine. It was originally based on KHTMLW, part of the > \ - KDE project, but is now being developed independently. + > engine. libgtkhtml312 contains the last version of \ + libgtkhtml > that contains the previous printing API. \ + It is required for > some ports that have not yet \ + switched to the new API or cannot > do so for some \ + reason, and would break with the current > version of \ + libgtkhtml3. Several versions of libgtkhtml can \ > + co-exist on the same machine. maintainers mas(a)macports.org > categories gnome platforms darwin > _______________________________________________ > macports-changes mailing list > macports-changes(a)lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-changes Randall Wood rhwood(a)mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."

1 0

[11712] update bazaar-ng to 0.15
by Adam Mercer 03 Apr '07

03 Apr '07

Hi I've submitted a ticked updating the bazaar-ng port to the recently released 0.15. Could someone with commit access please review and commit this? http://trac.macports.org/projects/macports/ticket/11712 Cheers Adam

2 2

linking to a library within destroot directory
by markd＠macports.org 02 Apr '07

02 Apr '07

What can we do when an app wants to link to a library that is part of the app distro and within the destroot directory? So that after installation the app won't give a "Library not loaded" message because it is trying to find it in the now non-existent destroot directory. Mark

2 3

Hacking in Universal -- Don't!
by Landon Fuller 02 Apr '07

02 Apr '07

I received a bug report about the zlib port not working -- it was modified to use private API in an attempt to hack in Universal support. The port, which I originally wrote in 2003, went from this: http://trac.macports.org/projects/macports/browser/trunk/dports/ archivers/zlib/Portfile?rev=23414 to this: http://trac.macports.org/projects/macports/browser/trunk/dports/ archivers/zlib/Portfile?rev=22776 This is not an improvement! The port is literally twice as long, but more importantly, it *FAILS* on different versions of MacPorts because it uses MacPorts-private undocumented API calls. I believe we need a very straight-forward policy: - Do not use undocumented, private API in Portfiles. This will cause breakage and make the system entirely unmaintainable. - If making a Portfile "Universal" complicates the Portfile, then you need to patch the software, not the port. -landonf

3 3

Why are we doing releases again?
by Jordan K. Hubbard 02 Apr '07

02 Apr '07

OK, I'm sure what I'm about to say will identify me as a total kill- joy who also somehow doesn't remember the bad old days of base/ instability or synchronization issues between base/ and dports/, but please just take it as a given that I DO remember those problems and still feel compelled, given some of the more negative trade-offs I've been seeing, to make the following statement anyway: I don't think MacPorts should be doing releases. Why? Because I think they're premature for the project in general (given where it is in terms of resources and technology), I think they're largely arbitrary in what they're able (or willing) to promise to users and I think that they tend to create more problems than they solve as users attempt to follow the releases for base/ but still want to effectively follow ToT for dports/, leading to something which looks more like FrankenPorts than a genuinely coherent and stable branch. What's worse is the fact that these "releases" are highly misleading in the sense that a "release" for any other software product is something that enjoys not just a "freeze" period but some sort of quality control and testing which ensures that all the respective pieces actually hang together and there aren't any really egregious problems with the product on the date that it ships. MacPorts, on the other hand, does not have any sort of testing infrastructure to guarantee (or hell, even KNOW) that a significant majority of the ports are working at that particular time or that base/ and dports/ synchronization problems have not broken things in various dusty corners of the ports collection. This is why I say that the MacPorts project itself is simply not release-ready; it's more like a project going through its early Alpha stages where "be careful, you might cut yourself!" is about the best advice any user can be given. Of course, we could attempt to dodge the issue here and claim that releases were really only for base/ and dports was the uncharted territory, but that would be silly given that if you add up every single line (of anything) in base/, you're looking at 156,000 lines of Makefiles, C, Tcl and other miscellaneous goop whereas for dports, that number is over 713,000 lines. If anything needs release control, it's dports/, and one possibly helpful analogy would be to suppose that Mac OS X was released every time xnu looked stable enough, never mind everything else that depended on xnu. "Not really our problem", the Mac OS X engineers might say. "People will certainly tell us if Mail, Final Cut Pro or various 3rd party are completely hosed and we can always fix that in the next release." That would sure be a lot easier (and I could spend the bulk of the year on Maui instead of worrying about the bulk of the bugs I worry about) but it wouldn't be a release. 1.4, despite all the hard work people have put into it, is also not a release. Neither was 1.3, or 1.2, or anything that DarwinPorts/ MacPorts has done. They've been fingers stuck in the wind and a highly subjective attempt to decide "what would be a good time" without the benefit of any actual end-to-end testing or regression analysis. If that's all they were, I also probably wouldn't say anything, figuring "ah, what the heck, let the kids have their fun!", but I'm noticing more and more that these pseudo-releases are also a drain on productivity and end up spending cycles doing merges and trying to figure out how to change the behavior of things in base/ in ways that might effects many different ports, even when those improvements are worthwhile. My proposal is that work continue on ToT and this premature notion of releases be dropped until MacPorts is truly ready to run through all of its ports and figure out what's broken and what's not. Speculative development can still be done on branches and need not perturb ToT until all the pieces are ready to come together, but ToT should simply be the commonly-advancing front of MacPorts and if something is broken, a user who tracks it can generally be assured of a fix (either in base/ or dports/ as applicable) simply by keeping their tree up to date and waiting 24 hours. As I've also implied in the previous paragraph, I don't think releases are a bad idea *eventually*, I just don't think it's something MacPorts should be doing until it substantially improves its technology to the point where the general health of MacPorts, and I do mean all the ports and possibly even "their popular variants" are testable. - Jordan

1 0

Only 8 ports that now depend upon DarwinPortsStartup
by markd＠macports.org 01 Apr '07

01 Apr '07

FYI, there are only 8 ports left that depend upon DarwinPortsStartup. databases/mysql gnome/gdm mail/fetchmail mail/mailman net/junkbuster net/net-snmp net/throttled www/abyss Mark

4 3