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

Re: [30750] trunk/www/includes/common.inc
by Ryan Schmidt 06 Nov '07

06 Nov '07

On Nov 5, 2007, at 23:18, source_changes(a)macosforge.org wrote: > Revision: 30750 > http://trac.macosforge.org/projects/macports/changeset/30750 > Author: jmpp(a)macports.org > Date: 2007-11-05 21:18:07 -0800 (Mon, 05 Nov 2007) > > Log Message: > ----------- > > Add a long-ago-suggested-by-Ryan header() to field to includes/ > common.inc to force serving of all our webpages as application/xhtml > +xml documents I did? Gosh, I'm forgetful. > (Ryan, any reason why you orginally suggested "'(...) charset=' . > $encoding" rather than plain "'(...) charset=$encoding'"?) My personal PHP code style is to avoid putting variables inside double-quoted strings. In fact I try to avoid double-quoted strings in general, favoring single-quoted strings where possible. But feel free to use whatever style gives you the most joy. :) > Modified Paths: > -------------- > trunk/www/includes/common.inc > > Modified: trunk/www/includes/common.inc > =================================================================== > --- trunk/www/includes/common.inc 2007-11-06 05:11:45 UTC (rev 30749) > +++ trunk/www/includes/common.inc 2007-11-06 05:18:07 UTC (rev 30750) > @@ -43,6 +43,7 @@ > # Page header > function print_header($title, $encoding) { > global $MPWEB; > + header("Content-Type: application/xhtml+xml; charset=$encoding"); > echo "<?xml version=\"1.0\" encoding=\"$encoding\"?>\n"; > ?> > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http:// > www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

2 1

excel data import on Mac OS X
by Denis Tkachov 06 Nov '07

06 Nov '07

I am looking for a way to import data from excel on Mac OS X. Development platform - c++ (xcode). Can anybody point me to the way how it may by done on Mac OS? Any help is appreciated. Best regards, Denis -- View this message in context: http://www.nabble.com/excel-data-import-on-Mac-OS-X-tf4758841.html#a13609260 Sent from the MacPorts - Developer mailing list archive at Nabble.com.

2 1

Re: [30677] trunk/dports/security/authforce
by Ryan Schmidt 06 Nov '07

06 Nov '07

On Nov 3, 2007, at 15:38, source_changes(a)macosforge.org wrote: > --- trunk/dports/security/authforce/Portfile 2007-11-03 20:15:07 > UTC (rev 30676) > +++ trunk/dports/security/authforce/Portfile 2007-11-03 20:38:14 > UTC (rev 30677) > @@ -22,6 +22,9 @@ > configure.args --mandir=${prefix}/share/man --infodir=${prefix}/ > share/info > configure.cppflags-append "-L${prefix}/lib" > configure.cflags-append "-no-cpp-precomp -flat_namespace - > undefined suppress -lintl -L${prefix}/lib" > + > +patchfiles patch-http.c > + FYI: The patchfile should be named "patch-http.c.diff". "port lint" has some other recommendations for this portfile as well: $ sudo port lint Password: ---> Verifying Portfile for authforce Warning: Line 2 should be a newline (after RCS tag) Warning: Line 3 should be a newline (after PortSystem) Warning: Line 16 has trailing whitespace before newline Warning: Line 24 has trailing whitespace before newline Warning: Line 32 has trailing whitespace before newline Warning: Patchfile patch-http.c does not follow the source patch naming policy "patch-*.diff" ---> 0 errors and 6 warnings found. $

3 4

Re: [30721] use_parallel_build / portfile-phase.7.xml
by markd＠macports.org 05 Nov '07

05 Nov '07

Mark Duling writes: >One question about "use_parallel_build". Do you think that keyword >relates to a phase, or should it be considered a "global keyword"? I >thought perhaps "global", or do you consider it specifically related to >the build phase? I thought parallelism applied more generally to the >port overall. But if that were true, I suppose the name would be >"use_parallel_install" or some such, so if you could comment on that it >might clarify it. If I had followed the recent thread I suppose I would >know this, but I didn't. > >I also have to say that I struggled to come up with an organizing >principle for keywords, and I'm not entirely sure that separating them >into "global" (those relating to the port as a whole and not primarily >related to a phase) and "phase" (those relating to a particular phase) is >the best way. Perhaps there is a better way, but I haven't hit upon it >yet. So I just wanted to ask if you think given that distinction, if >portfile-phase is the best place for use_parallel_build. And if you have >an opinion on whether that distinction is adequate or not, I'd welcome >your comments on that as well. Okay, I looked at the thread and I see that "use_parallel_build" does indeed relate specifically to the build phase. I should have done that before sending the email. Sorry. I gotta stop trying to think in the morning without caffeine. :) Perhaps I was influenced by my recollections that some ports stop installing outside of the build phase until another port is finished installing. At least I think I've seen this. If that is so and a ports hangs at activate or another phase until another port completes, it seems like parallel building still wouldn't get parallel installs. Mark

3 3

Re: [30721] use_parallel_build / portfile-phase.7.xml
by markd＠macports.org 05 Nov '07

05 Nov '07

macports-dev(a)lists.macosforge.org writes: >Revision >[ http://trac.macosforge.org/projects/macports/changeset/30721 ]30721 >Author >mww(a)macports.org >Date >2007-11-05 10:01:13 -0800 (Mon, 05 Nov 2007) > >Log Message > >use_bzip2 default to 'no'; >document 'use_parallel_build'; > > >Modified Paths > > [ >fcp://@bubbs.biola.edu,%235000280/Mailbox/%23233592931#trunkdocnewmanxmlportfilephase7xml >]trunk/doc-new/man/xml/portfile-phase.7.xml Hi Markus, Thanks again for your diligent work to keep the docs up-to-date. It is much appreciated. One question about "use_parallel_build". Do you think that keyword relates to a phase, or should it be considered a "global keyword"? I thought perhaps "global", or do you consider it specifically related to the build phase? I thought parallelism applied more generally to the port overall. But if that were true, I suppose the name would be "use_parallel_install" or some such, so if you could comment on that it might clarify it. If I had followed the recent thread I suppose I would know this, but I didn't. I also have to say that I struggled to come up with an organizing principle for keywords, and I'm not entirely sure that separating them into "global" (those relating to the port as a whole and not primarily related to a phase) and "phase" (those relating to a particular phase) is the best way. Perhaps there is a better way, but I haven't hit upon it yet. So I just wanted to ask if you think given that distinction, if portfile-phase is the best place for use_parallel_build. And if you have an opinion on whether that distinction is adequate or not, I'd welcome your comments on that as well. Mark

1 0

#13046: Please check and commit that patch
by Christian Aust 05 Nov '07

05 Nov '07

Hi all, #13046 is a pretty annoying, although minor bug with MacPort's OpenSSH port. There's a patch available, but appearantly there's nobody working on it right now. (It has been assigned to jmpp(a)macports.org) Can somebody please have a look at it and commit the patch if appropriate? Kind regards, Christian -- Christian Aust mailto:christian@wilde-welt.de icq: 84500990 - AIM, MSN, GTalk: datenimperator skype:datenimperator

2 2

Re: Speed up build phase with "make -j"
by Weissmann Markus 05 Nov '07

05 Nov '07

On 28.10.2007, at 23:52, js wrote: > On 10/29/07, Anders F Björklund <afb(a)macports.org> wrote: >>>> Note that some ports will fail to build, when using "make -j 2" >>> >>> What causes the build erorr? is it for bad Makefile or problem of >>> "-j" >>> option itself? >> >> Bad makefiles, usually missing dependencies. > > So, in a way, using -j encourage us to find wrong makefiles:) Well, if you're lucky -- parallel builds get non-deterministic, so software _may_ build correctly. You may (!) even end up with a successful build that created "bad" installations with misbehaving software; An intermediate step that makes changes to a file may get scheduled after the last step compiles an object file from this file; this way you might get a successful build but w/o the changes from step 2. Those are extremely hard to trace bugs and maintainers might reject bug reports if builds got made parallel this way -- after all they cannot reproduce failing builds due to the non-determinism. I'd rather encourage a mechanism for port that provides a mechanism for port authors to know how many processors there are and to enable parallel builds if they know this to work. Perhaps a switch "use_parallel_build [yes|no]" that will add "-j 2*CPUS" to build.args. -Markus --- Markus W. Weissmann http://www.mweissmann.de/

6 19

Re: [30677] trunk/dports/security/authforce
by Ryan Schmidt 04 Nov '07

04 Nov '07

On Nov 4, 2007, at 16:54, Mark Grimes wrote: > On Nov 4, 2007, at 13:42, Ryan Schmidt wrote: > >> On Nov 4, 2007, at 03:31, Mark Grimes wrote: >> >>> On Nov 4, 2007, at 1:04 AM, Ryan Schmidt wrote: >>> >>>> On Nov 3, 2007, at 15:38, source_changes(a)macosforge.org wrote: >>>> >>>>> --- trunk/dports/security/authforce/Portfile 2007-11-03 >>>>> 20:15:07 UTC (rev 30676) >>>>> +++ trunk/dports/security/authforce/Portfile 2007-11-03 >>>>> 20:38:14 UTC (rev 30677) >>>>> @@ -22,6 +22,9 @@ >>>>> configure.args --mandir=${prefix}/share/man --infodir=$ >>>>> {prefix}/share/info >>>>> configure.cppflags-append "-L${prefix}/lib" >>>>> configure.cflags-append "-no-cpp-precomp -flat_namespace - >>>>> undefined suppress -lintl -L${prefix}/lib" >>>>> + >>>>> +patchfiles patch-http.c >>>>> + >>>> >>>> >>>> FYI: The patchfile should be named "patch-http.c.diff". "port >>>> lint" has some other recommendations for this portfile as well: >>>> >>>> >>>> $ sudo port lint >>>> Password: >>>> ---> Verifying Portfile for authforce >>>> Warning: Line 2 should be a newline (after RCS tag) >>>> Warning: Line 3 should be a newline (after PortSystem) >>>> Warning: Line 16 has trailing whitespace before newline >>>> Warning: Line 24 has trailing whitespace before newline >>>> Warning: Line 32 has trailing whitespace before newline >>>> Warning: Patchfile patch-http.c does not follow the source patch >>>> naming policy "patch-*.diff" >>>> ---> 0 errors and 6 warnings found. >>>> $ >>> >>> Aside from the strange "mandated" naming conventions, port lint >>> is suggesting (as warnings) that diff -p -u is insufficient, >>> which I find a little disturbing. Is there an alternative set of >>> diff flags that will make lint happy? >> >> I don't really understand. What is strange about the naming >> conventions? And what do you mean "diff -p -u is insufficient"? >> What does diff have to do with lint? > > You said lint had other suggestions aside from the .diff and I'm > saying this patch is made with diff -p -u so I am assuming all > these suggestions (lint warnings) can be dismissed. Ah, I see. The port has no maintainer. I thought maybe you were its maintainer; I didn't look closely enough. In any case, I wanted to point out to you the patchfile naming situation, and rather than just state it, I wanted to show you (and others) how you can learn of this yourself (by using "port lint" before committing). In this case "port lint" also showed other errors unrelated to the changes you made, and if you were the maintainer, you might want to take care of those too. But since the port has no maintainer I went ahead and made the whitespace changes in r30700.

1 0

#13080 update devel/bazaar-ng to use python25 portgroup
by Adam Mercer 04 Nov '07

04 Nov '07

Hi Can someone with commit access please take a look at ticket #13080 [1] which updates the bazaar-ng port to use the python25 portgroup? Cheers Adam [1] <http://trac.macports.org/projects/macports/ticket/13080>

2 1

Re: [30677] trunk/dports/security/authforce
by Ryan Schmidt 04 Nov '07

04 Nov '07

On Nov 4, 2007, at 03:31, Mark Grimes wrote: > On Nov 4, 2007, at 1:04 AM, Ryan Schmidt wrote: > >> On Nov 3, 2007, at 15:38, source_changes(a)macosforge.org wrote: >> >>> --- trunk/dports/security/authforce/Portfile 2007-11-03 20:15:07 >>> UTC (rev 30676) >>> +++ trunk/dports/security/authforce/Portfile 2007-11-03 20:38:14 >>> UTC (rev 30677) >>> @@ -22,6 +22,9 @@ >>> configure.args --mandir=${prefix}/share/man --infodir=${prefix}/ >>> share/info >>> configure.cppflags-append "-L${prefix}/lib" >>> configure.cflags-append "-no-cpp-precomp -flat_namespace - >>> undefined suppress -lintl -L${prefix}/lib" >>> + >>> +patchfiles patch-http.c >>> + >> >> >> FYI: The patchfile should be named "patch-http.c.diff". "port >> lint" has some other recommendations for this portfile as well: >> >> >> $ sudo port lint >> Password: >> ---> Verifying Portfile for authforce >> Warning: Line 2 should be a newline (after RCS tag) >> Warning: Line 3 should be a newline (after PortSystem) >> Warning: Line 16 has trailing whitespace before newline >> Warning: Line 24 has trailing whitespace before newline >> Warning: Line 32 has trailing whitespace before newline >> Warning: Patchfile patch-http.c does not follow the source patch >> naming policy "patch-*.diff" >> ---> 0 errors and 6 warnings found. >> $ > > Aside from the strange "mandated" naming conventions, port lint is > suggesting (as warnings) that diff -p -u is insufficient, which I > find a little disturbing. Is there an alternative set of diff flags > that will make lint happy? I don't really understand. What is strange about the naming conventions? And what do you mean "diff -p -u is insufficient"? What does diff have to do with lint?

1 0