NetBSD의 라이센스는 애초에 캘리포니아 버클리 대학에서 BSD에 사용했던 4조항짜리 라이센스였습니다. 이중 세번째 조항(일명 advertising cluase)이 해당 소프트웨어의 모든 광고 자료에 저작권자의 이름을 명시해야한다고 하고 있는데, 여기저기서 소스를 가져온 대규모 오픈 소스 프로젝트에서는 이 조항이 현실적으로 지키기 어려워서 불평이 많았습니다. 그 결과 캘리포니아 버클리 대학을 비롯, 많은 프로젝트에서 해당 조항을 삭제한 3조항짜리 라이센스로 변경했지만, NetBSD는 4조항 라이센스를 고수해왔습니다. 하지만 이번에 시대의 요구에 부합하기 위해 말썽많은 세번째 조항을 삭제하고, 더 나아가 사실상 실효성이 거의 없는 마지막 조항마저도 삭제한 2조항짜리 라이센스로 변경했습니다. 아마도 CVS나 source-changes 메일링 리스트를 자주 보시는 분들이라면 최근 얼마간 NetBSD 소스의 라이센스가 대부분 변경된 것을 아셨을겁니다. NetBSD의 소스에 기반한 프로젝트를 진행하시는 분들께는 라이센스를 지키는데에 있어서 성가신 부담 하나가 사라진 반가운 소식입니다. 이제 NetBSD는 저작권과 라이센스만 명시하면 어떤 용도로든 자유롭게 사용할 수 있는 소프트웨어가 되었습니다.
‘개발’에 관한 글모음
최근 몇달간 NetBSD CVS가 상당히 바쁘게 돌아가고 있습니다. 메일링 리스트에 연일 새로운 기능과 그 성능에 대한 얘기가 끊이질 않는군요. 대부분은 별도 브랜치를 만들어 구현해오던 것들인데, 최근들어 -current로 통합이 되었습니다. 굵직한 것들로는 멀티프로세서에서의 성능 개선과 새 malloc 등이 있었는데, 이번주에는 Mindaugas Rasiukevicius씨가 만든 새로운 스케쥴러도 통합이 되었네요. 이것도 최근 추세에 따라 MySQL SysBench 결과가 올라왔습니다. 쓰레드가 하나인 경우에는 기존의 스케쥴러(SCHED_4BSD, 빨간색)와 별 차이가 없지만, 쓰레드가 많아지면 새 스케쥴러(SCHED_M2, 연두색)가 무려 50%나 더 많은 트랜잭션을 처리할 수 있습니다. 연이은 벤치마크 결과를 보고 있으니 제 데스크탑도 어서 프로세서가 여러개 달린 놈으로 바꿔야만 할 것 같은 생각이 듭니다.
프로그램 수행시 malloc(3)만큼 많이 불리는 함수도 많지 않습니다. 아주 간단한 프로그램이 아닌 다음에야 메모리를 할당은 거의 필수죠. 대부분의 프로그램에서 쉴새없이 메모리를 할당하고 해제하는 일을 반복하다보니, 효율적으로 메모리를 관리한다는게 쉬운 일이 아닙니다. malloc이 하는 일은 겉으로는 빈 메모리 찾아서 돌려주는 단순한 작업처럼 보이지만, 실제로는 장기적으로 메모리를 쓰는데에 문제가 없도록 온갖 뒷치닥거리를 해야만 합니다. 특히나 프로세서도 여러개이고 쓰레드도 여러개가 함께 돌아가는 상황이 되다보면 malloc이 얼마나 일을 잘 하느냐가 전체 시스템의 성능에 큰 영향을 주게 됩니다. malloc이 제 몫을 못할 경우 얼마나 치명적인지 Andrew Doran씨의 벤치마크 결과를 보면 잘 알 수 있습니다. 파란 선과 분홍색 선을 비교해보세요. 둘 다 Linux 2.6.21인데, 하나는 glibc에 있는 malloc을 그대로 쓴 것이고, 다른 하나는 구글에서 만든 thread-caching malloc을 쓴 것입니다. glibc의 malloc으로는 쓰레드 수가 늘어남에 따라 처리할 수 있는 트랜잭션 수도 증가하다가, 쓰레드가 프로세서보다 많아지면 갑자기 불안한 모습을 보이면서 최고 성능의 60% 수준으로 주저앉고 맙니다. 그러나 tcmalloc을 쓰게 되면 이런 문제가 전혀 없고, 쓰레드 수가 늘어나더라고 일정한 성능을 유지합니다.
FreeBSD에서도 malloc이 병목이 되는 상황이 종종 발생하자, 작년 BSDCan에서 Jason Evans씨가 발표한 jemalloc으로 바꾸어버렸습니다. jemalloc에 대한 자세한 내용은 Evans씨의 논문에 잘 나와있습니다.
NetBSD는 그동안 다중 프로세서 지원이 워낙 미흡했기에 malloc이 병목이 될 기회조차 없었는데, 이번에 Andrew Doran씨가 다중 프로세서에서의 성능을 크게 향상시키면서 며칠 전 malloc도 jemalloc으로 교체해버렸습니다. 이제 NetBSD-current에서는 jemalloc을 기본으로 사용하며, 혹시라도 이전의 malloc을 계속 쓰려면 USE_JEMALLOC을 no로 설정해주어야 합니다. Kris Kennaway씨의 벤치마크 결과를 보면 jemalloc을 쓴 경우(보라색)가 안 쓴 경우(파란색)보다 약 30% 정도 성능이 향상된 것으로 나옵니다.
아직 4.0도 나오지 않았는데, 벌써부터 5.0이 탐이 나네요. 
며칠 전 Andrew Doran씨가 NetBSD-current의 SysBench 결과를 리눅스, FreeBSD, OpenBSD와 비교한데에 이어 Jaime Fournier씨가 솔라리스와 비교한 결과를 공개했습니다. 읽기만 한 경우랑 읽기와 쓰기를 모두 한 경우를 나누어서 비교를 했는데요, 역시나 NetBSD-current가 더 나은 성능을 보여주고 있습니다. 읽기만 한경우 전반적으로 솔라리스에 비해 40%정도 더 많은 트랜잭션을 처리하고, 읽기와 쓰기를 모두 한 경우는 두 운영 체제가 대체로 비슷하지만 클라이언트 수가 12-20개인 구간을 제외하고는 NetBSD가 근소하게나마 우세하군요. 이번 비교는 클라이언트 수가 50개일때까지(지난번은 20개까지) 시도해 본 것인데, 클라이언트 수가 늘면서 성능이 상당히 완만하게 떨어지는 것으로 보아 리눅스처럼 일정 수(15개) 이상에서 불규칙한 행태를 보이는 일도 없는 것 같습니다. 뛰어난 결과를 만들어낸 Andrew Doran씨에게 찬사를 보냅니다.
NetBSD 재단에서는 얼마전 멀티프로세서에서의 성능을 개선하기 위해 Andrew Doran씨를 정식으로 고용하여 NetBSD 개발에 전념할 수 있도록 한 바 있습니다. 그 Doran씨가 오늘 tech-kern 메일링 리스트에 그간의 성과를 보여주는 벤치마크 결과를 올렸습니다. MySQL의 sysbench 결과인데요, 기존의 NetBSD에 비해 괄목할만한 성능 향상을 보여줍니다.
NetBSD 3.0까지만 해도 멀티프로세서의 경우(연두색)가 프로세서가 하나인 경우(분홍색)보다 성능이 더 떨어지는 어처구니없는 상황이었습니다만, NetBSD-current에서는 프로세서 하나(파란색)로도 3.0보다 20% 정도 더 많은 트랜잭션을 처리하는데다가, 멀티프로세서(빨간색)로 가면 거의 세 배 가까운 트랜잭션을 처리해내고 있습니다.
더 재미있는 것은 다른 운영 체제와 비교한 결과입니다. 다음 그림을 보시죠.
처음 그림과 마찬가지로 빨간 선이 멀티프로세서에서 NetBSD-current를 쓰는 경우입니다. 클라이언트 쓰레드가 어느 정도 이상이 되면 대략 초당 450개 정도의 트랜잭션을 처리합니다. OpenBSD에서 성능 최적화에는 그다지 신경을 쓰지 않음은 잘 알려져 있으므로 같은 조건의 OpenBSD 4.1(하늘색)이 겨우 100개만을 처리하는 것은 별로 놀랍지 않습니다만, FreeBSD-current(파란색)도 NetBSD-current의 2/3인 300개에 못 미치는 성능을 보여주네요. 리눅스 2.6.21의 경우(연두색)도 흥미롭습니다. 클라이언트 쓰레드가 10개 미만인 경우에는 NetBSD보다 많이 쳐집니다. 특히 단일 클라이언트인 경우 NetBSD에서 초당 125개 정도의 트랜잭션을 처리할 수 있는 반면, 리눅스는 50개를 간신히 넘는 수준이네요. 하지만 클라이언트 수가 10개를 넘어가면서 상황이 뒤바뀝니다. 대략 클라이언트 17개까지는 리눅스가 조금 낫습니다. 문제는 18개 이상인 경우인데요, NetBSD의 경우는 그래프가 평평한 것이 클라이언트 수가 더 늘더라도 꾸준히 400 이상은 유지할 것으로 보입니다. 하지만 리눅스는 들쭉날쭉 예측 불능의 상태로 빠져들면서 성능도 저하됩니다. 다른 분의 말에 따르면 캐쉬와 관련된 문제로 저런 제멋대로의 상황으로 빠져드는 것 같다는군요. 더 많은 수의 클라이언트에 대해서도 벤치마크를 해 보았더라면 확실히 알 수 있었을텐데 좀 아쉽습니다.
어쨌든 NetBSD의 성능이 대폭 향상되어 다른 운영 체제와 견주어도 월등히 낫거나 비슷한 수준이므로, 5.0을 기대해봐도 좋을 것 같습니다(4.0은 언제?). 그동안 NetBSD 재단에 기부를 하신 분들께서도 기부하신 돈이 제대로 쓰이고 있음을 확인할 수 있는 기회가 되겠네요. 앞으로 이러한 기회를 더 많이 가질 수 있도록 현재 진행중인 기금 조성 캠페인에도 많은 참여 부탁드립니다. (이번 캠페인은 5만불을 목표로 하고 있고, 현재까지 만이천불 정도가 모였습니다.)
얼마전 발표된 새 GPL을 놓고 여기저기서 말이 많습니다. 리눅스 커널을 비롯한 여러 프로젝트에서 기존 버젼의 GPL과 새 버젼의 장단점을 따져보느라 바쁜 것 같은데요, 언뜻 보기에는 이 논쟁과 별 상관이 없어보이는 NetBSD에서도 이 문제를 진지하게 생각해봐야 할 필요가 있습니다. 비록 NetBSD의 커널을 비롯한 대부분의 코드가 BSD 라이센스를 따르고 있지만, 몇몇 툴들은 아직 GNU 소프트웨어에 의존하고 있습니다. 그렇다면 그 소프트웨어들이 GPLv3을 따르게 될 경우, 지금처럼 NetBSD에 해당 소프트웨어들을 포함한채로 사용해도 아무 영향이 없을까요?
이 질문에 답을 하려면 먼저 GPLv2와 GPLv3의 차이를 알아야합니다. 문제는 그게 그리 쉽지 않다는거죠. GPLv3는 이전 버젼에 비해 보다 많은 조건들을 담고 있는데다가, (법과 그리 친하지 않은 일반인들에게는) 그다지 직관적이지 못한 용어들을 사용하고 있어서, 읽고 이해하기가 만만치 않습니다. 저 역시 그걸 읽고 해석을 내릴만한 역량은 안되므로, NetBSD에 영향을 줄 소지가 있는 점만을 얘기해보겠습니다.
문제의 발단은 티보에서 자사의 하드웨어에 자사의 소프트웨어만을 돌릴 수 있게 하면서 비롯되었습니다. GPLv2에 따르면 GPL 소프트웨어를 고쳐서 쓰고 있는 티보는 그 소스를 공개할 의무가 있지만, 정작 티보의 고객 입장에서는 소스를 보고 뭔가 고쳐서 돌려본다던지 하는 일은 할 수 없는 것이죠. 이 점을 FSF에서는 고객의 “자유”를 침해하는 것으로 간주하고, 새 GPL에는 그걸 명시적으로 금지하는 조항을 추가했습니다. 그러나 달리 보면 이 조항은 오히려 하드웨어를 만드는 티보의 “자유”를 제한한다는 점에서 FSF의 자유는 “시키는대로 해라”라는 의미의 자유(Free as in “do as I say”)라고 조롱을 받고, 리누스까지 나서서 “위선자“라고 혹평을 해서 좀 시끄러웠죠. FSF가 저작권자인 소프트웨어에 어떤 라이센스를 적용할지야 전적으로 FSF의 마음이고, 리눅스 커널이나 그밖의 GPLv2 프로젝트들은 해당 프로젝트에서 알아서 할 사안이니, 여기서 누가 옳고 그르고를 논하지는 않겠습니다. 다만 NetBSD의 입장에서는 새로운 조항이 소프트웨어의 이용 범위를 제한할 수 있다는 점이 중요합니다.
티보가 아니어도, 특정 하드웨어에서 동작하는 소프트웨어가 변경되는 것을 방지해야만 하는 경우가 있습니다. 보안이 중요한 환경이라면 허가받지 않은 프로그램이 동작한다는건 심각한 위협이 될 수 있죠. 일례로, 미국에서는 연방 정보 처리 표준이라는 지침을 정해두고 있는데, 그 중 하나인 FIPS PUB 140-2를 보면 바뀐 소프트웨어가 실행되는 것을 명시적으로 금지하고 있습니다. 즉, GPLv3 소프트웨어를 탑재하는 것이 마음대로 소프트웨어를 바꿔서 구동할 수 있어야 한다는 것을 의미한다면, 그 장비는 FIPS PUB 140-2를 준수해야하는 환경에서는 쓸 수 없게 됩니다.
NetBSD는 애초부터 누구나 아무 제한없이 쓸 수 있는 운영 체제를 목표로 하고 있는 만큼, 추가적인 제약을 가하는 GPLv3 소프트웨어를 쓰는 것은 프로젝트의 목표에 정면으로 위배됩니다. 그러므로 현재 NetBSD에 포함된 GPLv2 소프트웨어들이 GPLv3로 간다면, 그 소프트웨어들을 새 버젼으로 바꾸기는 어려울겁니다. 아마도 마지막 GPLv2 버젼을 유지하면서 점차 BSD 라이센스로 대체해나가야 하지 않을까요? 어차피 GPL에서 완전히 자유로운 운영 체제를 만드는 것이 장기적인 목표이므로, 어쩌면 GPLv3의 발표가 그 일정을 좀더 앞당기는 구실을 할 지도 모르겠습니다. 다만 Jem Matzan의 말처럼 GPLv3가 정말로 GNU의 쇠락을 가져오는 계기가 될 지는 좀 더 지켜봐야 할 것 같습니다.
(이 글은 제 개인적인 견해이며, NetBSD 재단의 공식 입장과는 무관합니다.)
좀 늦은 감이 있지만 2007년의 첫번째 NetBSD 상황 보고서가 나왔습니다. 기능적인 측면의 변화는 다음과 같습니다.
- uGuru 하드웨어 시스템 모니터 지원
- 일광 절약 시간제 변경
- ASUS AI Booster ACPI 하드웨어 모니터 지원
- DRM/DRI 지원
- 경량 프로세스 스케쥴링 개선
- On Demand Clock Modulation 지원
- IPv4의 Fast Forward 지원을 IPv6로도 확대
- curses 라이브러리의 아시아권 문자 지원
개인적으로 반가운 것은 마지막 두 항목입니다. IPv6의 Fast Forward 지원은 FAST_IPSEC과 더불어 IPv4와 IPv6의 기능상 차이를 거의 없앴다는 점에서 의미가 있습니다. curses 라이브러리에서 아시아권 문자를 쓸 수 있게 된건 더 말할 필요도 없겠죠. 새 curses 라이브러리의 한국어 테스트는 yui님께서 해 주셨습니다.
이 외에도 pkgsrcCon이나 구글의 Summer of Code 프로젝트 등의 굵직한 소식이 많이 있습니다. 자세한 내용은 전문을 참조하시기 바랍니다.
닥북 문서를 출력용 PDF로 변환하는 방법은 몇가지가 있습니다. 닥북이 SGML이던 시절에는 주로 JadeTeX을 통해 텍으로 조판하는 방법을 썼습니다. 하지만 XML로 바뀐 후에는 XML의 전통적인 문서 변환 방식인 XSLT를 사용하서 FO 형식의 문서를 만들고, 이를 다시 FOP처럼 FO를 PDF로 바꿔주는 도구를 이용하는 것이 “공식” 방법이 되었습니다. 문제는 그렇게 생성한 PDF의 품질이 그다지 좋지 않다는 겁니다. 일차적인 문제는 FO를 만드는 스타일시트가 그다지 미적인 측면에 신경을 쓰지 않았다는 것이고, FO를 PDF로 변환하는 도구 역시 적어도 공개된 것들중에는 아직 쓸만한 것이 없습니다. 결국 닥북을 기본 문서 형식으로 채택하고 있는 많은 프로젝트들이 여전히 JadeTeX에 의존하고 있는 상황입니다. KTUG분들 덕분에 최근에는 한글 문서도 처리할 수 있게 되었고요. 그러나 JadeTeX은 SGML에 기반하고 있어, 스타일시트로 별로 인기없는 DSSSL을 써야만 한다는 것이 큰 단점이죠. 조금만 결과물의 모양을 바꾸려고 해도 DSSSL을 고쳐야 하는데, 이쪽은 XSLT에 비해 사용자도 많지 않고, 소프트웨어도 그리 활발히 개발되고 있지 않아서 도움을 구하기가 어렵습니다.
결국 NetBSD에서는 한국어판 NetBSD 사용 안내서를 만들면서 닥북 XML에 직접 XSLT 스타일시트를 적용해서 LaTeX 파일을 만들고, 거기서 dhucs로 PDF를 만드는 방법을 택했습니다. NetBSD 프로젝트의 CVS 저장소에서 htdocs 모듈을 받으면 make 명령만으로 PDF 파일을 생성할 수 있습니다. 보다 일반적인 환경에서 이 방법을 사용하려면 다음과 같이 하면 됩니다.
먼저 몇가지 소프트웨어를 설치해야 합니다.
- XSLT 처리기 — XML 파일에 XSLT 스타일시트를 적용해서 다른 형태로 바꿔줍니다. 이 글에서는 libxslt에 포함된 xsltproc를 쓰고 있지만, 다른 XSLT 처리기도 사용 가능할겁니다. 대부분의 BSD와 리눅스에서 패키지로 설치 가능합니다. 맥오에스텐에는 기본으로 포함되어 있습니다.
- db2latex-0.8pre1 — 닥북 파일로부터 LaTeX 파일을 얻기 위한 스타일시트입니다. 0.8pre1이 최신 버젼입니다.
- Hangul-ucs — UTF-8로 인코딩된 한글 LaTeX 문서를 처리하는 패키지입니다. 설치 방법은 KTUG을 참조하세요.
libxslt나 Hangul-ucs는 쓰고 계신 운영 체제에서 패키지로 제공하는 것이 있다면 그걸 설치하는 것이 제일 간단합니다. 하지만 db2latex은 pkgsrc를 쓰는 환경이 아니라면 설치하기 전에 고쳐줘야 할 것이 있습니다. db2latex은 2004년 이후로 개발이 안 되고 있어서 최근 버젼의 소프트웨어와 사용하면 충돌하는 부분이 좀 있습니다. 한글 처리를 위해서 바꿔줘야 하는 것들도 있고요. 대부분은 별도의 XSL 파일을 하나 만들어 쓰는 것으로 해결이 됩니다만, 템플릿 하나를 없애야 하는 것이 있어서 이건 db2latex 소스 자체에서 고쳐줘야 합니다. db2latex의 xsl/qandaset.mod.xsl에서 question.answer.label이란 템플릿을 찾아서 지워주세요. pkgsrc에 포함된 패치를 적용하셔도 됩니다.
다음은 db2latex의 설정을 바꾸어주는 XSL 파일을 만들 차례입니다. 이 파일을 만드는 가장 간단한 방법은 NetBSD 사용자 안내서용으로 만들어 놓은 것을 가져다 필요한 부분만 바꾸는 겁니다. 맨 앞에 보면 처음으로 나오는 xsl:import에서 db2latex 스타일시트를 불러옵니다.
<xsl:import href="http://db2latex.sourceforge.net/xsl/docbook.xsl"/>
XML 카탈로그가 제대로 되어 있어서 URL을 보고 설치된 파일을 찾아오는 경우라면 그냥 놔둬도 되지만, 그렇지 않은 경우라면 URL이 실제 파일 위치를 가리키도록 바꿔주세요.
<xsl:import href="file:///path/to/db2latex/xsl/docbook.xsl"/>
조금 아래에 보면 dhucs와 관련된 LaTeX 명령들을 정의하고 있는데요, dhucs의 특정 옵션을 사용해야 한다거나 다른 LaTeX 패키지를 쓸 일이 있으면 그 부분에 추가해주시면 됩니다. 변환하고자 하는 닥북 문서의 최상위 요소가 article이면 latex.article.preamble.pre와 latex.article.preamble.post를, book이면 latex.book.preamble.pre와 latex.book.preamble.post를 고쳐주세요. 나중에 생성된 LaTeX 파일을 보시면 쉽게 감이 오실 겁니다.
이제 LaTeX 파일을 생성할 준비가 되었습니다. 이 단계는 보통 XSLT 스타일시트를 적용할때와 같습니다. xsltproc 명령을 쓰면 다음과 같이 합니다.
% xsltproc -o docbook.tex default-tex.xsl docbook.xml
default-tex.xsl은 좀전에 만들어준 XSL 파일이고, docbook.xml이 한글 닥북 문서입니다. docbook.tex은 새로 만들 LaTeX 파일입니다. 생성된 LaTeX 파일을 latex 명령으로 처리해서 PDF를 생성하면 됩니다.
pkgsrc팀이 오늘(16일)부터 제4사분기 pkgsrc 안정 브랜치 준비에 들어갑니다. 여느때처럼 벌크 빌드에서 문제가 있는 패키지들을 고치는 것 외에, 이번엔 특별한 이벤트가 준비되어 있습니다. 그동안 몇차례의 NetBSD Hackathon의 성공에 고무되어 pkgsrc팀에서도 Hackathon을 개최하려고 합니다. 기간은 이번 동결의 끝무렵인 12월 27, 28, 29일입니다. 연말에 다른 약속이 없으신 분들은 irc.freenode.net의 #pkgsrc로 오셔서 그동안 pkgsrc에 쌓였던 불만(?)도 털어놓고, pkgsrc 개발자들과도 만나서 함께 버그 잡기에 동참해주세요.
맥에서 Gtk 애플리케이션 쓰기에서 언급했던 패치를 정식으로 pkgsrc에 커밋했습니다. 지난번에는 몇몇 프로그램이 죽어버리는 문제가 있었는데, 이제는 안정성면에서는 별 문제가 없는 것 같습니다. 대부분의 Gtk 애플리케이션이 정상적으로 작동합니다. 그림은 graphics/gimp24에 있는 Gimp 2.3을 맥에서 X11을 띄우지 않고 돌리고 있는 화면입니다. 다만 메뉴를 마우스로 조작할 경우 입력을 제대로 다루지 못하는 문제가 있더군요. 부메뉴를 택할때에는 마우스를 클릭한채로 드래그해야만 합니다(몇 번 하면 익숙해 집니다 . 사실 graphics/gimp24까지 빌드하려면 아직 devel/libgnomeui나 devel/gail 등에 손봐야 할 곳이 좀 있습니다. pkgsrc에 그냥 넣어버릴 수도 있지만, 우선은 GNOME 버그질라에 보고를 하고 그쪽 반응을 봐서 제대로 된 패치를 넣는 것이 나을 것 같아서 아직 커밋하지 않았습니다(패치는 GNOME 버그질라의 382923, 382925, 382929번 버그를 보세요). 의존성이 복잡하지 않은 다른 패키지들(graphics/gqview나 news/pan 등)은 문제없이 빌드가 됩니다. 직접 빌드해보시려면 mk.conf에 다음을 추가하시고 graphics/glitz부터 다시 빌드하시면 됩니다.
PKG_DEFAULT_OPTIONS+=-x11 quartz
GDK 수준에서 추상화를 아주 잘 해놓아서 일부 몰지각한 GNOME 라이브러리들(X11 함수를 마구 불러쓰는…)만 손을 봐 주면 맥에서 아예 GNOME 환경을 꾸미는 것도 가능할 것 같네요.
Gimp.app에서 한 것처럼 Platypus를 잘 쓰면 필요한 라이브러리를 모두 한데 묶어서 pkgsrc 없이도 동작하는 별도의 맥 애플리케이션으로 만들 수 있을텐데, 관심 있으신 분 안 계신가요? 
(12월 8일) 패치를 전부pkgsrc에 추가했습니다. 이제 pkgsrc만으로 맥에서 Gimp를 빌드할 수 있습니다.