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

One commit = one change
by Ryan Schmidt 06 Mar '07

06 Mar '07

Dear MacPorts committers, I've seen a lot of commits to portfiles that do more than one thing. For example, a commit that updates the port to a new version, adds a new variant, and changes the indentation of the entire file. This makes it incredibly difficult to see what actually changed, and I would very much appreciate it if we could get into the habit of committing each logical change separately. For example, if you want to change the indentation of the file, do only that, then commit it, with a log message that says you're changing the whitespace. If you want to upgrade to a new version, do just that, and commit it with an appropriate log message. If you want to add a variant, do that, and commit it. This way it is much easier to look through the Subversion log and especially the diffs and see what was changed and why. If you do it all at once in a single commit, especially whitespace changes which like to affect every line, it's very difficult to see what was really changed, and this hinders people like me who are trying to learn more about MacPorts, portfiles, and compiling software in general. Hand in hand with the idea of one change per commit is the idea of accurate log messages. Your Subversion log message should say exactly what you changed. Don't omit anything! Just looking at some of the recent commits to the repository: http://trac.macports.org/projects/macports/changeset/22590 The log message says the port was updated to a new version, but also the maintainer was changed, which IMHO should have been a separate commit. http://trac.macports.org/projects/macports/changeset/22583 This revision updates the port version, changes the maintainer, changes whitespace, and adds the livecheck feature. I would have preferred separate commits, but at least the log does say that all of that was done. http://trac.macports.org/projects/macports/changeset/22543 The log message here says that livecheck was added, but also the software version was increased, which the log didn't say. http://trac.macports.org/projects/macports/changeset/22515 The whitespace of most of the file was changed, the maintainer was changed, the configure args were changed, and some patches were added, though it doesn't say why or what issue they were supposed to fix. I don't mean to be singling anybody out with the above commits; they're just some apt recent examples I found. I also should point out that I do most certainly thank all the MacPorts committers, since I am very much benefitting from all your hard work. But I not only use MacPorts to install software on my machine, I also like reading the portfiles to see how things were done, and especially, looking through the changes that were made to portfiles, and to read about why those changes were done. This is where one-change-per-commit and accurate (and, where appropriate, even detailed) log messages are so important, which is why I bring it up.

6 5

NEW: p5-xml-checker p5-eval p5-ipe
by Bob Zimmermann 06 Mar '07

06 Mar '07

Three new tickets submitted, at http://trac.macosforge.org/projects/ macports/ticket/11486 , http://trac.macosforge.org/projects/macports/ ticket/11485 and http://trac.macosforge.org/projects/macports/ticket/ 11484 . http://trac.macosforge.org/projects/macports/ticket/11486 depends on the first two. These are the first in a series of bioinformatics tools I'll be submitting. I submitted http://trac.macosforge.org/projects/macports/ticket/ 11485 with the wrong priority and subject line, but I couldn't find how to edit the ticket. Must it be assigned to me in order to edit the ticket? Thanks, Bob Zimmermann

1 0

sqlobject 0.8.0
by Giulio Eulisse 06 Mar '07

06 Mar '07

Ciao, I've updated the sqlobject port to 0.8.0 in my private area. What's the preferred way of submitting a patch? Is there any "port" command that creates the patch for me? Is the "port submit" command supported at all? Ciao, Giulio

2 2

build glib2 universal binary on PPC
by Isaac Huang 06 Mar '07

06 Mar '07

The glib2 configure script makes conclusions about endianness and atomic operations from host cpu type, and generates headers with such assumptions inside. I've searched this list and someone said glib2 needed a patch for this. But I couldn't find this patch, and I also lack enough knowledge about glib2 to fix it myself. Any hint or suggestion is appreciated. BTW, I don't have an Intel Mac so I can't build and lipo. Thanks, Isaac -- Regards, Isaac () ascii ribbon campaign - against html e-mail /\ - against microsoft attachments

3 6

Re: How to contribute (was: (no subject))
by Bob Zimmermann 06 Mar '07

06 Mar '07

Thanks for the informative post. I have an additional question: If I have multiple interdependent ports that I want to submit, should I submit them all in a single ticket or just make multiple tickets, each of which refers to its dependent tickets? Thanks, Bob > On Feb 23, 2007, at 19:14, Mark Dymek wrote: > > > Hi i would like to become a Developer/Contributer to macports how > > do i get started? In other words how do i find out which projects > > are not being done by someone or should i just look over the > > current projects and see one i like or should i just submit my own > > thing to you guys and see if you like it and want to include it? I > > know you are still transferring over from darwinports but i can't > > seem to find any documentation on either of the two sites that > > gives specific instructions to people who want to become part of > > the team. Any help would be appreciated thanks a lot. > > If you would like to write new portfiles or update existing ones, you > can do so locally, then submit a patch to a new ticket in Trac. Then > send a message to this list with the ticket URL and a committer will > evaluate the ticket and hopefully commit the change. Portfiles are > written in a language called tcl, but it's not hard to learn, and the > easiest way is probably to just look at some of the existing > portfiles to see how they do things. > > You can also help by looking through the open tickets, seeing which > don't have patches already, and writing and attaching the patches, > then informing the list which tickets you've done this for. > > Even finding open tickets that already have patches, that just > haven't been committed yet, and alerting the list about these can be > helpful. If you can first try the patch out locally and verify that > it fixes whatever the issue is, that's even better. > > You can find ports that are abandoned by looking for the maintainer > set to nomaintainer at macports.org, like this: > > $ port echo maintainer:nomaintainer at macports.org > > I currently see over a thousand unmaintained ports. If you see one in > the list that you would like to maintain, you can alert the list or a > committer and we can make you the maintainer. Then you can submit > updates to the port as above, and other users of that port will know > to contact you when they have questions or requests. > > Commit access can be granted to people who have made several positive > contributions. Generally you should be the maintainer of several > ports already before you request commit access. > > If you would like to develop the core MacPorts code, you can make > local changes and submit a patch to a new ticket in Trac, just like > with the ports, and then one of the core MacPorts code developers can > review your changes. I'm not sure if there's a current roadmap of > desired future changes at this point. If there is, that would be the > place to look for ideas for contributions.

2 1

libgmalloc bug
by Salvatore Domenick Desiano 05 Mar '07

05 Mar '07

I'm not sure if this is a libgmalloc bug, a gcc bug, or a iostream bug, but I just spent 20 hours boiling a crash in opencv down to ten lines of code. Can somebody else on a MacBook Pro run the following and see if they get a seg fault? Input from a PPC based processor also welcome. If this is a problem, I'm not even sure how to go back and fix the OpenCV port, but if it's not, but at least I'll know I'm working on a real problem. So frustrating! Thanks! -- Sal smile. cat > bug.cpp #include <iostream> void test () { for(unsigned i = 1; i < 3; ++i ) { std::cout << "HELLO"; } } int main (int argn, char * argv) { test(); return 0; } ^D g++ -Wall -fomit-frame-pointer -O1 -o bug bug.cpp setenv DYLD_INSERT_LIBRARIES /usr/lib/libgmalloc.dylib ./bug -------------- Salvatore Domenick Desiano Doctoral Candidate Robotics Institute Carnegie Mellon University

2 3

Re: macports: diff 1.3.2 - 1.4.0 (after paul's variant addition)
by Juan Manuel Palacios 05 Mar '07

05 Mar '07

On Feb 26, 2007, at 7:45 AM, Elias Pipping wrote: > Here's the current diff. > > Paul's changes are of course undocumented as of yet. > > Regards, > > Elias Pipping Thanks for the diff Elias, much appreciated! I just read it all and I can assert all changes listed in it between trunk (now 1.4 branch) and the 1.3.2 sources are accounted for (except for Paul's work on the universal variant, which is only in trunk and not in the 1.4 release branch -- adn I don't think we should include it, still too experimental--). Regards,... -jmpp

1 0

Messages with non-ASCII characters displayed with UTF-8 sequences
by Vincent Lefevre 05 Mar '07

05 Mar '07

For those who are in non-UTF-8 locales and use non-English locales (with messages containing non-ASCII characters, such as accented characters) and wonder if something gets wrong with these messages: On my machine, all these messages suddenly appeared with undecoded UTF-8 sequences, and I took me some time to find out what the cause was: the new version of m4 (1.4.8b_1), that supplies a file /opt/local/lib/charset.alias whose effect is to regard any charset as UTF-8! I've reported the bug: http://trac.macosforge.org/projects/macports/ticket/11474 -- Vincent Lefèvre <vincent(a)vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

2 1

Just say no to +universal
by James Berry 05 Mar '07

05 Mar '07

I'm quite distressed by the concept of too much work (and too much ugly code) going into building +universal variants of ports. I'd like to see people refrain from completely bastardizing portfiles in order to support universal builds. Let's be reasonable: the case for universal builds is fringe. We don't have easy ways to transport binary ports between systems, and it's not in general a safe thing to do. I'd much rather see: - Smaller, cleaner, more maintainable portfiles and no universal. - Work on binary packages and a build/distribution system that could deliver the pre-built port for a given architecture. Let's not see more ugliness like the universal variant in the OpenSSL port, please! (Feel free to chime in on this issue, all who care...) James

7 13

tbz or tbz2
by Blair Zajac 05 Mar '07

05 Mar '07

I was messing around with the portarchivetype option today and tried to set it to tbz2 according to ports.conf, but the resulting files, while ending in .tbz2, were not: /opt/local/var/db/dports/packages/darwin/i386/coreutils-6.7_1+with_default_names.i386.tbz2: POSIX tar archive So the code looks a little fragile in that it does regex matching on the names to determine which archiver and compressor to use. It also doesn't cover misspelled settings So a couple of things: 1) Should we decide on a standard tbz or tbz2? We should have the documentation match the code. 2) Have to code check for all valid types instead of trying regexps on them? Thanks, Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies <blair(a)orcaware.com> Subversion training, consulting and support http://www.orcaware.com/svn/

2 2