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

Re: MacPorts Web App (mpwa) online for initial testing.
by Yves de Champlain 16 May '07

16 May '07

Le 07-05-15 à 14:23, Michael Jackson a écrit : > > On May 15, 2007, at 10:42 AM, James Berry wrote: > >> The MacPorts Web App (mpwa) is online for some initial testing at >> http://db.macports.org/ >> >> This is the start of a vision for a more comprehensive online >> repository for ports. Please see some of my sketchy documentation at: >> >> http://svn.macports.org/repository/macports/users/jberry/mpwa/doc/ >> design.txt >> and http://svn.macports.org/repository/macports/users/jberry/mpwa/ >> doc/portpkg-design.txt >> >> To quote from the design document, my goals for mpwa are: >> >> Goals: >> >> - Develop a network-reachable port storage mechanism >> >> - Allow for ad-hoc submission of new ports/revisions by any user >> >> - Since users may submit ports and make them available, port >> availability >> is not held up for review by committers. Committers may provide >> special status >> to approved ports. >> >> - All submissions and versions should always remain network >> reachable >> so that old versions may be installed and/or reviewed. >> >> - Allow for storage of meta information with such a submission: >> - Submitter >> - Comments by various users >> - Build status >> - (potentially binaries) >> - etc. >> >> - Allow for promotion of such a submission to a special status >> (stable, whatever) >> by the port maintainer or other official personnel. >> >> Note that what is visible today is not a complete implementation. >> The following things are implemented, for the most part: >> >> - port submit, to submit a port to the repository. >> - autosubmit, a script I've been running which auto submits svn >> checkins after they've been given a chance to stabilize. >> - mpwa web frontend to browse and view ports and port information. >> >> The following is not yet implemented: >> >> - A handler for the application/vnd.macports.portpkg mime-type to >> make it easy to download and use a given portpkg. >> - Any sort of local support for ports by http: url. >> - port get, to get a particular port and use it locally >> - Any remote indexing or query support >> - User accounts >> - User created tags >> - Signing of submissions by submitters >> - Support for dependencies >> - Nicer css design and information layout. >> >> Your feedback or help on the project is desired. In particular, if >> somebody want so put in a little work on the css and templates, >> that would be great. >> >> James > > James, > > Looks great! Can't wait to see this up and running. I would be more > than willing to help out on the design/css layout if I had some > mockups or some kind of idea where to go with it. It's already up and running, and looks great ! yves

3 2

Soliciting feedback on variant description syntax and reporting
by James Berry 16 May '07

16 May '07

I checked into base last night (http://trac.macosforge.org/projects/ macports/changeset/25147), some code to support variant descriptions. The syntax I chose was the following: variant myvariant description "This variant does this and that" { configure.args-append --do-this --do-that } I'd love to get feedback both on the syntax. The syntax is a little bit different because it requires quoting of the description string -- something we don't often use in portfiles. Please give feedback on whether you like this, or whether we should use a syntax like this: variant myvariant { configure.args-append --do-this --do-that } variant_description myvariant This variant does this and that (which doesn't need quoting of the description). Secondly, in order to emit the description in port info, I expanded the variant section to show a single variant per line, which makes info a bit longer. Please let me know if you like this, or if we should limit ourselves to showing variant descriptions in "port variants" instead. Thanks for your input on these important matters ;) James

4 6

Can I remove a port that's been obsolete for 4 years?
by Boey Maun Suang 16 May '07

16 May '07

Hi, I just wanted to check that it would be okay for me to remove the rb- drb port because: * the author of the code says on his/her website [1] that it is obsolete as of ruby 1.8, which was committed to our tree 4 years ago [2]; and * the port is unmaintained. Any naysayers? Kind regards, Maun Suang [1] http://www2a.biglobe.ne.jp/~seki/ruby/download.html [2] http://trac.macports.org/projects/macports/changeset/3482 -- Boey Maun Suang (Boey is my surname) Email: boeyms at macports dot org

1 0

Re: [25234] trunk/base/src/port/port.1
by Jyrki Wahlstedt 16 May '07

16 May '07

On 16.5.2007, at 9.55, source_changes(a)macosforge.org wrote: > Revision 25234 Author eridius(a)macports.org Date 2007-05-15 23:55:26 > -0700 (Tue, 15 May 2007) Log MessageUpdate the documentation on > sync and selfupdate to mention the subversion updating > behaviourModified Paths > trunk/base/src/port/port.1 > Diff > Modified: trunk/base/src/port/port.1 (25233 => 25234)--- trunk/base/ > src/port/port.1 2007-05-16 06:48:05 UTC (rev 25233) +++ trunk/base/ > src/port/port.1 2007-05-16 06:55:26 UTC (rev 25234) @@ -309,6 > +309,12 @@ from the MacPorts rsync server. To update you would > normally do: .Pp .Dl "sudo port -d sync" +.Pp +If any of the dports > tree(s) uses a file: URL that points to a local subversion working > copy, +.Ic sync +will perform an +.Ic "svn update" +on the working > copy with the user set to the owner of the working copy. .Ss > outdated List the installed ports that need upgrading. .Ss upgrade > @@ -394,6 +400,10 @@ installing the newest infrastructure > available. To update you would typically do: .Pp .Dl "sudo port -d > selfupdate" +.Pp +See +.Ic sync +for more information about > updating dports tree(s). .Ss help Displays a summary of all > available actions and port command syntax on stdout. .Sh DEVELOPER > TARGETS > _______________________________________________ To me this comment does not describe the situation correctly (the document says, how it should be, not how it is). I use normally 'sudo port selfupdate' or 'sudo port sync', the result is that the subversion working copy owned by me will be tainted by files owned not by me, thereby preventing me updating. I am happy, if I really am wrong! PS This is easy to fix (use chown before svn up), an annoyance nevertheless! ! ! Jyrki Wahlstedt ! skype:jyrkiwahlstedt ! http://www.wahlstedt.fi/jyrki/ ! ! Our life is no dream; but it ought to become one and perhaps will. ! PGP key ID: 0x139CC386 fingerprint: F355 B46F 026C B8C1 89C0 A780 6366 EFD9 139C C386

2 1

MacPorts v1.4.40 released for self update
by James Berry 16 May '07

16 May '07

Here's the change log: James Release 1.4.40 (7-May-2007, tagged at r24909 by jberry): - Note the bump in version naming. To leave ourselves lots of room in our versioning scheme, we've jumped from 1.4.3 to 1.4.40. The floating point represenation as reported by port version (1.440) will still be the same; we're just interpreting it differently. - variable tracing now works in a much better way and handles unsets properly. Similarly, ${option}-delete now works better. Depends validation no longer attempts to validate when the variable is unset. Additionally, the validation now actually validates each depspec instead of simply finding a single spec within the list that works (ticket #11868, eridius r24678). - macports infrastructure now easier to use from scripts. ui_prefix and ui_channels have default implementations, and all arguments to dportinit are now optional (ticket #11837, eridius r24460). - ln now accepts combined flags (ex. ln -sf foo bar) (eridius r24452) - default_variants now handles multiple values correctly (ticket #11828, eridius r24450). - ln uses new symlink command so it can create symlinks that point to files that don't actually exist (eridius r24444). - New bare-bones Pextlib command `symlink source target` (ticket #11840, eridius r24444). - delete reimplemented using fs-traverse (eridius r24435). - fs-traverse now uses the fts(3) family of functions instead of readdir/opendir. This fixes a couple behavioral oddities, and makes deleting during traversal work on 10.3 (ticket #11839, eridius r24423). - fs-traverse now takes a list of targets rather than a variable number of arguments (ticket #11836, eridius r24410). - Fixed a potential crasher in fs-traverse when showing error message (ticket #11827, eridius r24396, thanks sfiera). - Fixed a bug where livecheck failed on ports that do not define a homepage (ticket #11818, pguyot r24319). - Added the downloads section of our repo to the macports mirrors list (jmpp r24278). - Fixed a bug with the archive mode introduced with r23238 change (1.4.1) (pguyot r24273). - Trace mode now take dependencies into account when executing the activate phase. This fixes an unwanted warning when activating ports that depend on teTeX (pguyot r24199). - Support for mpwa submit through "port submit". This work is in progress. (jberry) - Expose autoconf XAR variable as portutil::autoconf::xar_path. (r24194). - Start to build portpkg.xar and meta data, hijacking Kevin's portsubmit.tcl. (r24195-24196). - Revise error messages in port image activation to use syntax that matches port(1). (jberry r24543, r24548). - Create new interp variable prefix_frozen, which is available to port phases even when the Portfile redefines prefix. (jberry r24848-r24849) - Search for prefix-relative commands in prefix_frozen rather than prefix. Affects port submit (xar) and port fetch (svn). (jberry r24849) - Always create a ~/.macports user directory if it doesn't yet exist. (jberry r24831) - Move port(1) readline history file to ~/.macports/history (jberry r24832, r24843)

4 6

RFU: optpp 2.4
by Mark Moll 15 May '07

15 May '07

Can someone please commit this port update?: http://trac.macports.org/projects/macports/ticket/11889 -- Mark

1 0

MacPorts Web App (mpwa) online for initial testing.
by James Berry 15 May '07

15 May '07

The MacPorts Web App (mpwa) is online for some initial testing at http://db.macports.org/ This is the start of a vision for a more comprehensive online repository for ports. Please see some of my sketchy documentation at: http://svn.macports.org/repository/macports/users/jberry/mpwa/doc/ design.txt and http://svn.macports.org/repository/macports/users/jberry/mpwa/ doc/portpkg-design.txt To quote from the design document, my goals for mpwa are: Goals: - Develop a network-reachable port storage mechanism - Allow for ad-hoc submission of new ports/revisions by any user - Since users may submit ports and make them available, port availability is not held up for review by committers. Committers may provide special status to approved ports. - All submissions and versions should always remain network reachable so that old versions may be installed and/or reviewed. - Allow for storage of meta information with such a submission: - Submitter - Comments by various users - Build status - (potentially binaries) - etc. - Allow for promotion of such a submission to a special status (stable, whatever) by the port maintainer or other official personnel. Note that what is visible today is not a complete implementation. The following things are implemented, for the most part: - port submit, to submit a port to the repository. - autosubmit, a script I've been running which auto submits svn checkins after they've been given a chance to stabilize. - mpwa web frontend to browse and view ports and port information. The following is not yet implemented: - A handler for the application/vnd.macports.portpkg mime-type to make it easy to download and use a given portpkg. - Any sort of local support for ports by http: url. - port get, to get a particular port and use it locally - Any remote indexing or query support - User accounts - User created tags - Signing of submissions by submitters - Support for dependencies - Nicer css design and information layout. Your feedback or help on the project is desired. In particular, if somebody want so put in a little work on the css and templates, that would be great. James

1 0

Re: Track who installed what ports on what OS and on what
by Ryan Schmidt 14 May '07

14 May '07

On May 13, 2007, at 22:06, Norman MacIntyre wrote: > That is a bad idea. What purpose would it serve other > than collecting statistics and curiosity? > > Let me know when you do this so I can immediately use > only fink. I see! Well, that's two people vehemently opposed so far. :) Interesting. For comparison, it's far from unprecedented for programs to send statistical information to their developers when they check for updates. The popular text editors BBEdit and TextWrangler from Bare Bones Software do this, for example, as does the venerable dock utility DragThing. As I recall, they all ask for the user's permission before doing so, and explain exactly what data is sent; we could do that too. Even Software Update sends Apple a list of the Apple software you have installed, so that it can deliver to you a list of applicable updates. And it does that without your permission, and it's on by default, too. The purpose for collecting this data is obvious: it allows the developers to learn what kinds of machines and OS versions their users are using, which can help the developers decide where to focus their resources. In the case of MacPorts, it's fairly obvious that we will have PowerPC users running 10.3.x and 10.4.x and Intel users on 10.4.x. Maybe some 10.5.x testers too. What's less obvious is what ports people are using. And by collecting that information, we would not only help the port authors learn which of their ports are actually getting used, but also help users gauge a port's reliability. If a user is interested in a port and sees that hundreds of others have successfully installed it, there's a good chance it works. If nobody has installed it, or nobody with the user's processor architecture or OS version has installed it, there may be problems. If I wasn't clear before, I should also clarify that no personal information about the user would be stored -- username, email address, IP address: none of that. And it is not the intention to display a list of any individual user's active ports, only to sum up totals of active ports. However, I have to admit the system would need to store the lists of the users' active ports in order to compute the totals. And maybe that's a concern, since the information could be obtained by determined individuals with access. Perhaps I should explain what led to my initial email. In working on a redesign for the MacPorts web site, I thought it would be nice to include a box of popular ports in a sidebar, like so: My data here is clearly made up, but it illustrates the idea. If we tracked who installed what ports and on what processor, we could generate an accurate graph of the above, and similarly for OS versions. What I didn't do in the example above, but what I would want to do, is show only "interesting" ports. I would say ports like pkg-config and apr-util aren't "interesting" because they're merely dependencies of other ports. You wouldn't install apr-util just by itself; apr- util isn't the end goal. Other larger ports like apache2 are the end goal, and that's the kind of port I would show in the graph. If I could find a good way to identify the "interesting" ports. But perhaps this entire graph isn't so interesting, ultimately. Presumably if you're looking at MacPorts, you have a specific software package in mind that you're wanting to install, and don't need a graph of what everyone else is installing. I guess I was thinking of something like Apple's Dashboard widget download site, where they show you a list of today's top widget downloads. Same idea. If we don't do this graph, I would still like some extra info on the MacPorts home page, something to show new users what they can do with MacPorts. Something to draw them in. Maybe just a list of the most recently updated ports and their versions would do. That would be easier, too, since I can already pull that information from the repository.

3 2

Postgresql82 port installation location weirdness
by Randall Wood 14 May '07

14 May '07

Why is the postgresql82 port installed in the file locations its installed in? It is spread out strangely, and this making me pull some black magic to get a port that depends on it working, that I would rather not do. It installs the following data in the following places: --sysconfdir=${prefix}/etc/${name} \ --bindir=${prefix}/lib/${name}/bin \ --libdir=${prefix}/lib/${name} \ --includedir=${prefix}/lib/${name}/include/${name} \ I am porting an autoconf-based package (libgda3) that detects postgres database libraries in /path/to/postgres/lib and is fairly inflexible about this. I would like to suggest that maybe we need to create a space in $ {prefix} where ports that need to be installed in a private namespace can be installed there, such as ${prefix}/port In the case of postgresql82, this would mean installing in ${prefix}/port/ postgresql82 (although I would leave the conf dir where it is at) Randall Wood rhwood(a)mac.com http://shyramblings.blogspot.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."

3 2

Re: [25098] trunk/base/src/darwinports1.0/darwinports.tcl
by Randall Wood 14 May '07

14 May '07

Don't you need to create ~/.macports with rwe (700), so that the user can at least cd into it and edit preference files in it? On 13 May 2007, at 20:20, source_changes(a)macosforge.org wrote: > Revision 25098 Author jberry(a)macports.org Date 2007-05-13 17:20:27 > -0700 (Sun, 13 May 2007) Log MessageIf we need to create > ~/.macports, create it as 600, with ownership of the enclosing > directory.Modified Paths > trunk/base/src/darwinports1.0/darwinports.tcl > Diff > Modified: trunk/base/src/darwinports1.0/darwinports.tcl (25097 => > 25098)--- trunk/base/src/darwinports1.0/darwinports.tcl 2007-05-14 > 00:09:58 UTC (rev 25097) +++ trunk/base/src/darwinports1.0/ > darwinports.tcl 2007-05-14 00:20:27 UTC (rev 25098) @@ -224,6 > +224,7 @@ } } + proc dportinit {{up_ui_options {}} {up_options {}} > {up_variations {}}} { if {$up_ui_options eq ""} { array set > ui_options {} @@ -269,7 +270,12 @@ # Ensure that the macports user > directory exists set darwinports::macports_user_dir [file normalize > $darwinports::autoconf::macports_user_dir] - file mkdir > $macports_user_dir + if { ![file exists $macports_user_dir] } { + # > If not, create it with ownership of the enclosing directory, rw by > the user only + file mkdir $macports_user_dir + file attributes > $macports_user_dir -permissions u=rw,go= + file attributes > $macports_user_dir -owner [file attributes "$macports_user_dir/.." - > owner] + } # Configure the search path for configuration files set > conf_files "" > _______________________________________________ > macports-changes mailing list > macports-changes(a)lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-changes Randall Wood rhwood(a)mac.com http://shyramblings.blogspot.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."

2 1