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

Re: Website redesign (was Re: Please clear up DarwinPort/MacPorts confusion)
by Juan Manuel Palacios 11 Apr '07

11 Apr '07

Replying quickly to just a single comment, as I haven't been able to keep up with the thread lately: On Apr 11, 2007, at 3:34 PM, Ryan Schmidt wrote: > > I'd say this list is fine. There's only the dev and the users list. > Actually I'd like to move this discussion to the dev list entirely. First off, the discussion is currently split between the two lists (which I realize is my fault to begin with for having cross-posted when I began the thread), so concentrating it on a single one is a good thing. But other than the users list being of higher volume and messages tend to get lost easily (which I know it's something I can fix locally with a good mail client ;-), I believe this thread pertains more to the development of the project than to user support, which is what users@ is for. I think we can all agree that the people we want involved in our documentation should at least have some notions of programming/MacPorts development, at least enough to know there's a dev@ mailing list and to want to subscribe to it ;-) Signal to noise ratio on users@ is lower, I believe. So lets keep it on dev@, please. -jmpp

1 0

Re: Website redesign (was Re: Please clear up DarwinPort/MacPorts confusion)
by Ryan Schmidt 11 Apr '07

11 Apr '07

On Apr 9, 2007, at 22:58, Mark Duling wrote: > I think that is a good idea. I share Landon's concerns but I am > also a > little apprehensive of ditching DocBook altogether, because of its > flexibility in getting different outputs. But I am aware that we > hve to > do something to get better docs. I could if I chose keep a parallel > version in DocBook format, strange as that sounds. But before much of > anything will likely get written we're going to have to get a > documentation strategy mapped out. If we get people together that are > interested they could talk it out and present options. As it is, > talking > about docs on the mailing list doesn't work because few people on > the list > are interested. > > On the other hand, if it turns out we have or want few people that are > able and willing to work on documentation and we don't allow > everyone to > edit them, then it doesn't make that much difference what > technology we > use. I'd like to be a lead on the documentation team, and it would > probably be easiest for me personally to just use DocBook. I could > coordinate wiith and even show a few others how to use xxe if they > like, > or if they prefer just to send updates and contributions to me I > could do > it. I'm not trying to backtrack on the Wiki commitment, but I > suppose it > is *possible* that we won't have that many documentation > contributors and > if so we could go to a lot of work and not get any better docs u > til later > down the road, when we might need something that the wiki won't do > anyway. > Perhaps not, I'm just thinking aloud and wondering if kicking the > technical decisions down the road and getting to work on content > might be > a faster route to better docs right now. But i'm happy to go with a > consensus. I may just being paranoid about a new method. Thoughts? > > One last thing. Juan, what would you like to see changed in the > current > InstallingMacPorts wiki page? I wasn't sure what you wanted to see > happen > there. I'm still not voting one way or another w.r.t. wiki vs. docbook. But I will note that the formatting of the old DarwinPorts manual was fairly beautiful, while what comes out of a wiki isn't always. I share Landon's concern that wiki-based documentation often seems, indefinably, to be of lesser quality than other documentation. Things like the Subversion Book ( http://www.svnbook.org ) make a very good impression on me. I believe they use docbook as well. But probably the main reason that book is of high quality is that it is written, or at least checked, by editors. Anybody can contribute by sending patches to the mailing list, but the editors are there to watch every change and fix any wording weirdness before it ever gets into the sources. And that's very useful. But I'm not sure if we have anyone here willing to act as such an editor for the new MP docs. But, if we go with something other than wiki for the MP docs, then I'm not sure what the function of the wiki is. For example, InstallingMacPorts is surely a topic that should be covered in sufficient detail in the MP docs, and if the docs aren't wiki-based, then we surely don't need a wiki page describing the same thing.

4 3

1.4.1 release
by Juan Manuel Palacios 11 Apr '07

11 Apr '07

Evening everyone! So the 1.4.0 release is finally completed after much delay (my bad, my apologies!), and now we're already moving up to 1.4.1. Tonight I did quite some merging into the release_1_4 branch of some of the work that has been happening on trunk, but not all of it. I'm currently leaving out: 1) r23242: Ignoring SSL certificates; 2) r23098, r23125, r23238, r23248, 23362 and 23552: "New options for configure flags (C|CPP|CXX|LD)FLAGS and logic to handle that and backward compatibility." per Paul's commit log (original and subsequent commits); 3) r23246, r23249 and r23291: New -I${prefix}/include and -L${prefix}/lib compile time flags; 4) r23549, 23550 and r23553: Moving port tests into a test subfolder in order to portindex them; 5) Universal variant. On the one hand, I can't find my commit log mails for the work on the universal variant, so I'd appreciate it if someone could annotate my list with the proper revision numbers; and on the other hand, I'm not sure if 2) and 3) can be split like that, so (Paul) do correct me if I'm wrong. In any case, I'd like to discuss which of those changesets we're going to be including in 1.4.1, so everyone should feel free to ventilate all the pro's and con's about each of them, if any. We should, however, keep in mind that 1.4.1 is meant to be a minor, bug fixing release over 1.4.0 and therefore should not try to offer big and probably still experimental new features like the universal variant, in my opinion; 1.5 seems to me like more appropriate for that. But, again, I'm willing to be proven otherwise. Regards,... -jmpp

5 6

launchctl script for dbus
by Mike Alexander 11 Apr '07

11 Apr '07

The launchctl script generated in /opt/local/etc/LaunchDaemons/org.macports.dbus/dbus.wrapper is invalid. The port file needs to be changed to quote the parameters to startupitem.start and startupitem.stop and to provide the --system parameter to startupitem.restart. The attached patch seems to fix the problem, perhaps someone could apply it, assuming you don't see anything wrong with it. -- Mike Alexander mta(a)umich.edu Ann Arbor, MI PGP key ID: BEA343A6

3 2

Website redesign (was Re: Please clear up DarwinPort/MacPorts confusion)
by Juan Manuel Palacios 10 Apr '07

10 Apr '07

On Apr 6, 2007, at 2:45 PM, Sean Fulton wrote: >> > > That's all fine and good but I want jump in the pile-on and say that > the site and documentation need some serious attention. Having > outdated docs in SVN is less than ideal. > > Now that 1.4 is out will there be some effort to providing useful > documentation? Do the project leads need volunteers to help? I'm > willing. > At first I thought about saying "Ooohh, we so *totally* need volunteers to clean-up/improve our site!!", but then I asked myself "improve *how* and *what* exactly?" I think it's pretty clear to everyone that we need a major website and documentation overhaul (that said with my MacPorts Manager hat on!), so I'd say that before we do any minor and possibly random rearrangements and/or cleanups here and there, one thing we need to do, as a team and as openly as possible, is to discuss what we would like to see in a new website (including everything: welcoming portal, downloads section, documentation section, headlines, trac integration, per ports page, etc...). I've been thinking about bootstrapping this discussion and putting forth some initial ideas into the mix, and maybe even asking (inviting) some of the WebKit folks to give us a hand with the redesign (they obviously have a thing for websites ;-); but other than that, we as a team don't have much of a roadmap with respect to our site, admittedly and unfortunately. I'll bring the subject up with the other managers and MacOSForge admin personnel to at least get an initial feeling of what we can do (not only resource wise but also with respect to some guidelines we have to stick by), and will post again on the subject when I get a clearer idea. I think it's wise to ask everyone with either a dire stray need for a new site (because the current one sucks!) and/or the appreciated willingness to help, to wait until such time for us to better coordinate all our efforts toward defined and *specific* goals (other than the vague "we need a new site!"). Thanks to all for your patience! In the mean time, two documents I would like to work on (and could frankly use some help with like *now*), are: http://trac.macosforge.org/projects/macports/wiki/InstallingMacPorts http://trac.macosforge.org/projects/macports/wiki/TracTicketing The first one was edited not long ago, but I haven't had a chance to go over it. In any case, the installation page we had back on the OpenDarwin site was pretty good and I think we could re-use some of the material that was there (in svn, trunk/www/getdp). The second one deals with the guidelines for filing trac tickets, and needs revising in view of our new roadmap and milestones; I promised I'd deliver that document a couple of weeks ago but I've been so up to my neck that I only managed to complete the 1.4.0 release just some days ago! If you, Sean, or anyone else reading is willing to help me with these two docs, at least, don't hesitate to contact me to coordinate work. Thanks in advance for your offer! Regards to all and thanks again for your patience and for coping until now with out *cough* excuse *cough* for a website! -jmpp

5 8

Re: [23788] trunk/dports/aqua/macsword/Portfile
by Juan Manuel Palacios 10 Apr '07

10 Apr '07

On Apr 9, 2007, at 8:49 PM, source_changes(a)macosforge.org wrote: > > > Log Message > Fix app bundle path for newer Xcodes. > > Modified Paths > • trunk/dports/aqua/macsword/Portfile > ---snip--- > > destroot { > xinstall -d -m 0755 ${destroot}/Applications/MacPorts > - system "cp -R ${worksrcpath}/build/MacSword.app \ > + system "cp -R ${worksrcpath}/build/Deployment/MacSword.app \ > ${destroot}/Applications/MacPorts" > } Shouldn't these paths and Xcode settings be handled through the Xcode PortGroup? -jmpp

3 3

BUG: macsword-1.1.3 install failure
by Jonathan Hohle 10 Apr '07

10 Apr '07

I don't seem to have permission to open a new ticket, so I'll submit this the old fashioned way. I apologize if this is inappropriate. MacSword install fails with: ---> Staging macsword into destroot Error: Target com.apple.destroot returned: shell command "cp -R /opt/ local/var/db/dports/build/ _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dp orts_aqua_macsword/work/macsword/build/MacSword.app /opt/local/var/ db/dports/build/ _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dp orts_aqua_macsword/work/destroot/Applications/MacPorts" returned error 1 Command output: cp: /opt/local/var/db/dports/build/ _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dp orts_aqua_macsword/work/macsword/build/MacSword.app: No such file or directory Error: Status 1 encountered during processing. I would appreciate it if someone with the appropriate privileges would create a ticket, or just patch the Portfile. The Patch follows: diff -ru macsword/Portfile macsword-modified/Portfile --- macsword/Portfile 2007-04-09 06:02:21.000000000 -0700 +++ macsword-modified/Portfile 2007-04-09 06:03:28.000000000 -0700 @@ -47,7 +47,7 @@ destroot { xinstall -d -m 0755 ${destroot}/Applications/MacPorts - system "cp -R ${worksrcpath}/build/MacSword.app \ + system "cp -R ${worksrcpath}/build/Deployment/MacSword.app \ ${destroot}/Applications/MacPorts" }

2 1

Re: Website redesign (was Re: Please clear up DarwinPort/MacPorts confusion)
by Juan Manuel Palacios 09 Apr '07

09 Apr '07

On Apr 9, 2007, at 11:19 AM, Paul Beard wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On Apr 9, 2007, at 2:22 AM, Ryan Schmidt wrote: > >> Do we want to do that? Admittedly wikis are easier to edit. But >> wasn't the docbook format chosen for a reason? To those who remember: >> What was that reason? Does it still apply? > > I think that was a reason I didn't/couldn't contribute to the docs a > long time ago, IIRC. There was a reason for docbook, but it was one of > those "the best is the enemy of the good" moments. Docbook is great is > everyone can use it, but choosing a format that is mostly used by > coders means that its use might be limited to coders whose time might > be better spent coding. Mere civilians like myself can more easily add > to the project if we don't set up barriers to entry like that. Dockbook was chosen as the original format for the guide because of the myriad of formats we could output to from a single xml based source tree, at that time we were thinking about having html, pdf and who-knows-what-else incarnations of our guide. But the times have changed and I think we're well served with the dynamism of Wiki based documentation now and all that it has to offer (collaboration from non-coders certainly being high on the list). Therefore, hack on the Wiki everyone, says I! I've been promising to look at our trac permissions and adapt them to our current needs, so I'll try to get that done first so that a wider base can effectively contribute. In the mean time, as I first said in this thread, I'm very interested in seeing some work done on the TrackTicketing and InstallingMacPorts documents, I'm finding myself quite out of time these days to delve into them, so I'd appreciate it if anyone could give a hand (I believe they are of high priority, feel free to toss any other one into the mix). There are drafts for both of them up at our Wiki already, and all you ("you", the reader in general, not necessarily the ones on the headers of this message specifically ;-) need to do to improve the latter is merge what's already there with what we had on our OpenDarwin site, here in svn: http://trac.macports.org/projects/macports/browser/trunk/www/getdp/ index.php As for the former, TrackTicketing guidelines, there's no draft I can point you to to get an idea of what I have in mind for it... all of it is, as you may have guessed, in my mind ;-) So if you do want to work on it feel free to contact me personally so that we can talk it over. Regards to all! -jmpp

1 0

readline issue
by Paul Guyot 09 Apr '07

09 Apr '07

Hi folks, We cannot simply autoconf for readline for the following reasons: (a) readline comes with two incompatible APIs. (b) Apple's gcc reads /usr/local/include before /usr/include (c) Apple's ld reads /usr/lib/libreadline.dylib before /usr/local/lib/ libreadline.a when provided with -L/usr/local/lib (d) some users have an incompatible version of readline in /usr/local. In other words, if you install the incompatible version of readline available in ticket 10651 in /usr/local, I think you cannot compile *and* link the following piece of code without redefining completely the list of system includes, with -nostdinc. Which is the beginning of a nightmare. https://svn.macosforge.org/projects/macports/ticket/10651 #include <stdio.h> # include <readline/readline.h> int main(void) { void* ptr = (void*) rl_username_completion_function; return 0; } or this one: #include <stdio.h> # include <readline/readline.h> int main(void) { void* ptr = (void*) username_completion_function; return 0; } I think it's time to wonder why we autoconf for readline (and other stuff). At some point we decided that MacPorts (then darwinports) was to support MacOS X only. (I was against this decision, but here we are today; and considering that I no longer can install MacPorts on linux boxes I have access to, I would favor the use or more MacOS X technologies). Should we simply drop the autoconf options for readline? Should we just determine what's the API version of readline installed in /usr/? Should we keep users whining they cannot install MacPorts because they have a readline in /usr/local? Vincent: before you comment on this, I must say that I am not taking into consideration the C*_PATH and LIBRARY_PATH problem. In fact, I do not care about it at all, I am concerned by end-users not people with a Ph.D. in computer science who are wise enough to know that if they set these variables, it might break things and they need to unset them before compiling base/ :) Paul

3 2

Current freetype2 (2.3.3) breaks compatibility w/other packages
by Adam Nohejl 09 Apr '07

09 Apr '07

Hello, The current freetype package contains version 2.3.3, while some other packages still need the pre-2.2.0 FreeType with exposed internals and therefore fail to build with the current version of FreeType. For instance libsdl_ttf (see http://freetype.org/freetype2/ freetype-2.2.0.html for more info). As I'm new to MacPorts I don't know what would be the proper solution: Is there a way to make specific packages dependent on specific versions of other packages? (Probably not.) Would be a separate package for that version needed? (Not very nice.) However, as far as I can tell the current state makes some packages simply unusable. Please excuse my lack of deeper knowledge and experience with MacPorts and package management in general. I hope I'll be more helpful next time I come across a problem. Happy Easter, -- Adam

3 3