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

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

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

lynx port
by Daniel J. Luke 01 Apr '07

01 Apr '07

Does anyone else have build problems with the lynx port? (I haven't done any looking into it yet ...): . -I../src -I../WWW/Library/Implementation -O2 -c ./LYCharSets.c ./LYCharSets.c: In function 'HTMLGetEntityUCValue': ./LYCharSets.c:878: error: 'unicode_entities' undeclared (first use in this function) ./LYCharSets.c:878: error: (Each undeclared identifier is reported only once ./LYCharSets.c:878: error: for each function it appears in.) make[1]: *** [LYCharSets.o] Error 1 make: *** [all] Error 2 -- Daniel J. Luke +========================================================+ | *---------------- dluke(a)geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+

6 13

Re: [23415] trunk/dports/archivers/zlib/Portfile
by markd＠macports.org 31 Mar '07

31 Mar '07

macports-dev(a)lists.macosforge.org on Saturday, March 31, 2007 at 10:25 AM -0800 wrote: >Revision >[ http://trac.macosforge.org/projects/macports/changeset/23415 ]23415 >Author >landonf(a)macports.org >Date >2007-03-31 10:25:27 -0700 (Sat, 31 Mar 2007) > >Log Message > >Claiming ownership of my port entirely. > Are there ports where you are listed maintainer that you shouldn't be? I think to be sure someone respects your maintainership, you should make sure that you are only listed as maintainer one ones you really actively maintain. I really wan't aware you were still active and I supposed there were a bunch of ports that you used to maintain and currently didn't but never formally relinquished. For example, I just updated openldap days ago and you are listed as maintainer. But there have been 3 verifiable bugs filed against it for ages and the port was pretty outdated. In my view, MacPorts only keeps functioning because of the efforts of a few that sometimes need to bend the rules with some judgement, because there aren't enough people concerned with fixing bugs that we can reasonably expect those people to adhere to all the rules we set up. If we had more people doing it we could more closely adhere to the standards we've setup. A bureaucratic system with few people doesn't work very well when those few have to choose between getting things done for others and maximizing their volunteer time. I'm not criticizing or complaining, I'm just saying how things appear to me because, frankly, I bend the rules a lot because I don't see another way right now. The project seems to have more users than it once did and tickets are opened faster, but it doesn't seem like there are many responsive maintainers so that we rely on a few consistent bug chasers and committers that sometimes bend the rules to keep from getting swamped by tickets. Mark

4 4

Re: Finding a port's dependencies
by Elias Pipping 31 Mar '07

31 Mar '07

>>> I forget again: is there an easy way to tell if any >>> ports depend on those? >> >> yes, there is: >> >> $grep :cairo-devel */*/Portfile > > I'll put this in the FAQ. Would it be useful to make the port > command do > this in a future revision? > > Mark I've put together a script to search for dependents. Here's what it does: * works on ports that aren't currently installed * supports both the (bin|lib):foo:name and the port:name syntax * matches the exact name [1] (searching for ncurses does not bring up results for ncursesw) * supports regexp [2] (e.g. searching for "ncursesw?") * finds dependencies that hide in variants * finds dependencies that hide in comments (yet to be gotten rid of) setup: the script needs to be run from within the dports folder. invocation: foo.sh ncursesw? ==== foo ==== #! /bin/sh # room for customization SED=/usr/bin/sed GREP=/usr/bin/grep $GREP -E "(port|(lib|bin):[^:]+):$1([\t ]|$)" */*/Portfile | $SED "s=/ Portfile:.*==g" ==== bar ==== [1] http://paste.lisp.org/display/39008/raw [2] http://paste.lisp.org/display/39008,1/raw Regards, Elias

1 1

Re: [23415] trunk/dports/archivers/zlib/Portfile
by Landon Fuller 31 Mar '07

31 Mar '07

On Mar 31, 2007, at 11:20 AM, Mark Duling wrote: > macports-dev(a)lists.macosforge.org on Saturday, March 31, 2007 at > 10:25 AM > -0800 wrote: >> Revision >> [ http://trac.macosforge.org/projects/macports/changeset/23415 ]23415 >> Author >> landonf(a)macports.org >> Date >> 2007-03-31 10:25:27 -0700 (Sat, 31 Mar 2007) >> >> Log Message >> >> Claiming ownership of my port entirely. >> > Are there ports where you are listed maintainer that you shouldn't > be? I > think to be sure someone respects your maintainership, you should make > sure that you are only listed as maintainer one ones you really > actively > maintain. I really wan't aware you were still active and I > supposed there > were a bunch of ports that you used to maintain and currently > didn't but > never formally relinquished. For example, I just updated openldap > days > ago and you are listed as maintainer. But there have been 3 > verifiable > bugs filed against it for ages and the port was pretty outdated. I'm pretty sure I'm still active =) http://trac.macports.org/projects/macports/search?q=landonf&changeset=on Of the three OpenLDAP bugs, the only bug actually assigned to me was an enhancement request. It was opened prior to trac ever sending e- mail, and so I never actually saw the bug. The port wasn't significantly outdated -- I was intentionally was tracking the 2.2.x branch. That said, I saw the bug that you filed on Wednesday, and it all looked fine. I had planned on addressing it this weekend, but you beat me to it. > In my view, MacPorts only keeps functioning because of the efforts > of a > few that sometimes need to bend the rules with some judgement, because > there aren't enough people concerned with fixing bugs that we can > reasonably expect those people to adhere to all the rules we set > up. If > we had more people doing it we could more closely adhere to the > standards > we've setup. A bureaucratic system with few people doesn't work > very well > when those few have to choose between getting things done for > others and > maximizing their volunteer time. > > I'm not criticizing or complaining, I'm just saying how things > appear to > me because, frankly, I bend the rules a lot because I don't see > another > way right now. The project seems to have more users than it once > did and > tickets are opened faster, but it doesn't seem like there are many > responsive maintainers so that we rely on a few consistent bug > chasers and > committers that sometimes bend the rules to keep from getting > swamped by > tickets. I agree that the maintainer flag should be considered a mutex -- I certainly don't have time to keep tabs on updates and bugs every single port I maintain. However, I do think discretion is a must -- if you're white-space reformatting the entire port, doubling it in length and complexity, and adding dependence on undocumented private functions, something is probably wrong -- especially when it's something like zlib, which is a hugely important system dependency. -landonf

1 0

Request to check that there is a bug in building cook
by Boey Maun Suang 31 Mar '07

31 Mar '07

Hi everyone, I was just wondering if other people would be able to test for me whether or not there is indeed a bug in the current version of cook in dports, or whether I'm just missing something. When I build it, I get: gcc -Ifile_check -Icommon -g -O2 -c \ file_check/file_check.c file_check/file_check.c:31: error: static declaration of 'limit' follows non-static declaration file_check/file_check.h:29: error: previous declaration of 'limit' was here make: *** [file_check/file_check.o] Error 1 MacPorts: 1.4.0 os: Mac OS X 10.4.9 arch: intel The attached patch eliminates this error, but though I'm fairly confident that this is a bug, the patch is an appropriate fix and that it should be reported upstream, I'm not completely sure. Any advice that you may have would be appreciated. Kind regards, Maun Suang -- Boey Maun Suang (Boey is my surname) Mobile: +61 403 855 677 Email: boeyms(a)fastmail.fm

1 0

freetype
by Jann Röder 31 Mar '07

31 Mar '07

Is there a reason why we still have the old freetype version 2.1.10 in macports although 2.3.2 is available by now ? Or is it that simply nobody has updated it, yet ? Jann

3 4

committer responsibilities
by markd＠macports.org 31 Mar '07

31 Mar '07

I think that when people commit updates, they should make a quick scan of the trac list to see if there are tickets open that the commit may close. I think it is reasonable to expect people to do that, but that is not hapenning, nor has it ever happened for many committers. Even a comment saying "didn't check if it fixed anything, but updated it -good luck" sort of comments if you don't have time for more is all I'm asking for. It would be a big help. Treating it as someone else's problem even to look at trac before or after committing is just not being a responsible community member in my view. </end-of-scolding :)> Mark

3 3

fftw-3-single
by Takeshi Enomoto 30 Mar '07

30 Mar '07

Hi, I'd be happy to hear from those have knowledge to suggest a fix. <http://trac.macosforge.org/projects/macports/ticket/11613> fftw-3-sigle does not build on my MacBook Pro. I should fix this because I am the maintainer of fftw-3 and I need this for GDL. But the error below is beyond my ability. gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I. -I.. -I../simd -O3 -fomit- frame-pointer -malign-double -fstrict-aliasing -ffast-math - march=pentiumpro -D_THREAD_SAFE -MT trig.lo -MD -MP -MF .deps/ trig.Tpo -c trig.c -o trig.o /var/tmp//ccMMtwDn.s:99:operands given don't match any known 386 instruction /var/tmp//ccMMtwDn.s:100:operands given don't match any known 386 instruction /var/tmp//ccMMtwDn.s:132:operands given don't match any known 386 instruction /var/tmp//ccMMtwDn.s:134:operands given don't match any known 386 instruction /var/tmp//ccMMtwDn.s:167:operands given don't match any known 386 instruction /var/tmp//ccMMtwDn.s:168:operands given don't match any known 386 instruction make[2]: *** [trig.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2

5 10