From msavory1 at nzbox.com Thu Sep 4 19:00:57 2008 From: msavory1 at nzbox.com (Mike Savory) Date: Thu, 4 Sep 2008 19:00:57 -0700 Subject: Port iso-codes Message-ID: <326B671C-EA5E-4925-A8FB-2E2DFF310013@nzbox.com> Hi all Trying to upgrade iso-codes $ sudo port upgrade iso-codes ---> Fetching iso-codes ---> Attempting to fetch iso-codes-3.2.tar.bz2 from http://distfiles.macports.org/iso-codes/ ---> Attempting to fetch iso-codes-3.2.tar.bz2 from ftp://pkg-isocodes.alioth.debian.org/pub/pkg-isocodes/ ---> Attempting to fetch iso-codes-3.2.tar.bz2 from http://svn.macports.org/repository/macports/distfiles/iso-codes ---> Attempting to fetch iso-codes-3.2.tar.bz2 from http://svn.macports.org/repository/macports/distfiles/general/ ---> Attempting to fetch iso-codes-3.2.tar.bz2 from http://svn.macports.org/repository/macports/downloads/iso-codes Error: Target org.macports.fetch returned: fetch failed Error: Unable to upgrade port: 1 Looking at each of these macport sites the first ones have revision 3.1 but not 3.2 The last two are broken. And the non Macport site does seem to actually have the file ftp://pkg-isocodes.alioth.debian.org/pub/pkg-isocodes/iso-codes-3.2.tar.bz2 although my fetch fails maybe a double passive ftp issue... It looks like 3.3 is available here now anyway, so the portfile should be upgraded for that as well as fixing the mirroring... I'll try and open a ticket Mike From msavory1 at nzbox.com Thu Sep 4 19:11:46 2008 From: msavory1 at nzbox.com (Mike Savory) Date: Thu, 4 Sep 2008 19:11:46 -0700 Subject: Documentation In-Reply-To: <326B671C-EA5E-4925-A8FB-2E2DFF310013@nzbox.com> References: <326B671C-EA5E-4925-A8FB-2E2DFF310013@nzbox.com> Message-ID: <09373877-F9D6-461E-A978-21070D364E43@nzbox.com> Hi In http://guide.macports.org/#installing.x11.settings It refers to /etc/X11/xinit/xinitrc On my 10.5.4 system /etc/X11 does not exist Mike From wsiegrist at apple.com Thu Sep 4 20:09:28 2008 From: wsiegrist at apple.com (William Siegrist) Date: Thu, 04 Sep 2008 20:09:28 -0700 Subject: Port iso-codes In-Reply-To: <326B671C-EA5E-4925-A8FB-2E2DFF310013@nzbox.com> References: <326B671C-EA5E-4925-A8FB-2E2DFF310013@nzbox.com> Message-ID: On Sep 4, 2008, at 7:00 PM, Mike Savory wrote: > Hi all > > Trying to upgrade iso-codes > > $ sudo port upgrade iso-codes > ---> Fetching iso-codes > ---> Attempting to fetch iso-codes-3.2.tar.bz2 from http://distfiles.macports.org/iso-codes/ > ---> Attempting to fetch iso-codes-3.2.tar.bz2 from ftp://pkg-isocodes.alioth.debian.org/pub/pkg-isocodes/ > ---> Attempting to fetch iso-codes-3.2.tar.bz2 from http://svn.macports.org/repository/macports/distfiles/iso-codes > ---> Attempting to fetch iso-codes-3.2.tar.bz2 from http://svn.macports.org/repository/macports/distfiles/general/ > ---> Attempting to fetch iso-codes-3.2.tar.bz2 from http://svn.macports.org/repository/macports/downloads/iso-codes > Error: Target org.macports.fetch returned: fetch failed > Error: Unable to upgrade port: 1 > > Looking at each of these macport sites the first ones have revision > 3.1 but not 3.2 > > The last two are broken. > The last 2 are a fallback when the actual sites do not have the file so that maintainers can stash distfiles in the repo for people to get. Its expected that most ports do not have distfiles in the repo. > And the non Macport site does seem to actually have the file > > ftp://pkg-isocodes.alioth.debian.org/pub/pkg-isocodes/iso-codes-3.2.tar.bz2 > > although my fetch fails maybe a double passive ftp issue... > > It looks like 3.3 is available here now anyway, so the portfile should > be upgraded for that as well as fixing the mirroring... > > The mirroring is not broken. The distfile mirror server cannot mirror via FTP. So ports with only FTP master_sites will never be mirrored automatically. This is a restriction due to where the server lives and cannot be changed. I have manually placed both v3.2 and v3.3 onto the mirror so people can get the files if FTP does not work for them either. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080904/225b4230/attachment.bin From blair at orcaware.com Thu Sep 4 20:16:31 2008 From: blair at orcaware.com (Blair Zajac) Date: Thu, 04 Sep 2008 20:16:31 -0700 Subject: Port iso-codes In-Reply-To: References: <326B671C-EA5E-4925-A8FB-2E2DFF310013@nzbox.com> Message-ID: <48C0A48F.6010801@orcaware.com> William Siegrist wrote: > On Sep 4, 2008, at 7:00 PM, Mike Savory wrote: > > The mirroring is not broken. The distfile mirror server cannot mirror > via FTP. So ports with only FTP master_sites will never be mirrored > automatically. This is a restriction due to where the server lives and > cannot be changed. > > I have manually placed both v3.2 and v3.3 onto the mirror so people can > get the files if FTP does not work for them either. Sounds like that location and the location where I work both block FTP. So is there a place/way we can have a mirror for FTP sites? That seems to be one of the nice features is a FTP->http proxy of sorts. Regards, Blair From wsiegrist at apple.com Thu Sep 4 20:28:31 2008 From: wsiegrist at apple.com (William Siegrist) Date: Thu, 04 Sep 2008 20:28:31 -0700 Subject: Port iso-codes In-Reply-To: <48C0A48F.6010801@orcaware.com> References: <326B671C-EA5E-4925-A8FB-2E2DFF310013@nzbox.com> <48C0A48F.6010801@orcaware.com> Message-ID: On Sep 4, 2008, at 8:16 PM, Blair Zajac wrote: > William Siegrist wrote: >> On Sep 4, 2008, at 7:00 PM, Mike Savory wrote: >> The mirroring is not broken. The distfile mirror server cannot >> mirror via FTP. So ports with only FTP master_sites will never be >> mirrored automatically. This is a restriction due to where the >> server lives and cannot be changed. >> I have manually placed both v3.2 and v3.3 onto the mirror so people >> can get the files if FTP does not work for them either. > > Sounds like that location and the location where I work both block > FTP. So is there a place/way we can have a mirror for FTP sites? > That seems to be one of the nice features is a FTP->http proxy of > sorts. > Someone could provide a mirror that is located in an FTP-friendly network. Or maintainers of FTP-only ports could host them on HTTP long enough for the mirror to get a copy. We should get away from putting binaries in the SVN repo, though that is the simplest path to HTTP hosting for this purpose. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080904/a054666d/attachment.bin From msavory1 at nzbox.com Thu Sep 4 20:57:17 2008 From: msavory1 at nzbox.com (Mike Savory) Date: Thu, 4 Sep 2008 20:57:17 -0700 Subject: Port iso-codes In-Reply-To: <48C0A48F.6010801@orcaware.com> References: <326B671C-EA5E-4925-A8FB-2E2DFF310013@nzbox.com> <48C0A48F.6010801@orcaware.com> Message-ID: <9C48B983-572D-4B14-A502-6ED77CA655CE@nzbox.com> Hi I was able to FTP it to my Mac using Fetch, however macports was unable to automatically fftp it. I don't think it is a network location issue but a macports active/passive mode capability issue (such that Fetch could get it from the same location). Mike On Sep 4, 2008, at 8:16 PM, Blair Zajac wrote: > William Siegrist wrote: >> On Sep 4, 2008, at 7:00 PM, Mike Savory wrote: >> The mirroring is not broken. The distfile mirror server cannot >> mirror via FTP. So ports with only FTP master_sites will never be >> mirrored automatically. This is a restriction due to where the >> server lives and cannot be changed. >> I have manually placed both v3.2 and v3.3 onto the mirror so people >> can get the files if FTP does not work for them either. > > Sounds like that location and the location where I work both block > FTP. So is there a place/way we can have a mirror for FTP sites? > That seems to be one of the nice features is a FTP->http proxy of > sorts. > > Regards, > Blair > From markd at macports.org Fri Sep 5 14:12:28 2008 From: markd at macports.org (markd at macports.org) Date: Fri, 05 Sep 2008 14:12:28 -0700 Subject: Documentation Message-ID: >Hi > >In http://guide.macports.org/#installing.x11.settings > >It refers to /etc/X11/xinit/xinitrc > >On my 10.5.4 system /etc/X11 does not exist > >Mike Hi Mike, I corrected the x11 section in r39807. Thanks for pointing it out. Not sure how long it takes for the changes to appear on the website, but for 10.5 you don't need to edit xinitrc (which moved). Also, X11 shouldn't be launched from the dock anymore from what I understand. Mark From ramercer at gmail.com Fri Sep 5 21:57:18 2008 From: ramercer at gmail.com (Adam Mercer) Date: Fri, 5 Sep 2008 23:57:18 -0500 Subject: [39807] trunk/doc-new/guide/xml/installing.xml In-Reply-To: <20080905210618.3037531426D@beta.macosforge.org> References: <20080905210618.3037531426D@beta.macosforge.org> Message-ID: <799406d60809052157u3670c312wc9d7b1756970c462@mail.gmail.com> On Fri, Sep 5, 2008 at 4:06 PM, wrote: > + Before launching an X11 application, you must open a terminal window > + and start an xterm session. > > + %%xterm > + > + After the X11 session window opens, you may launch X11 apps from > + another terminal window. See + linkend="installing.x11.settings">Optional X11 Settings if you wish > + to launch X11 applications from an X11 session window. This just confuses me as if X is configured correctly, in Leopard, then you don't need to run xterm prior to running any X based app - X will automagically start when required. Cheers Adam From ryandesign at macports.org Mon Sep 8 02:10:13 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 8 Sep 2008 04:10:13 -0500 Subject: [39807] trunk/doc-new/guide/xml/installing.xml In-Reply-To: <20080905210618.3037531426D@beta.macosforge.org> References: <20080905210618.3037531426D@beta.macosforge.org> Message-ID: On Sep 5, 2008, at 4:06 PM, markd at macports.org wrote: > Revision: 39807 > http://trac.macports.org/changeset/39807 > Author: markd at macports.org > Date: 2008-09-05 14:06:16 -0700 (Fri, 05 Sep 2008) > Log Message: > ----------- > Fix the X11 section to work with 10.5. > > Modified Paths: > -------------- > trunk/doc-new/guide/xml/installing.xml > > Modified: trunk/doc-new/guide/xml/installing.xml > =================================================================== > --- trunk/doc-new/guide/xml/installing.xml 2008-09-05 19:53:59 UTC > (rev 39806) > +++ trunk/doc-new/guide/xml/installing.xml 2008-09-05 21:06:16 UTC > (rev 39807) > @@ -38,19 +38,18 @@ > > Click Install to install > X11. > > - > - > - Drag the /Applications/Utilities/X11 filename> icon > - to your dock ?you must open X11 before launching an X11 > - application. > - > The instruction to put X11 in the Dock never made much sense to me; an application does not need to be in the Dock for me to be able to open it. However, the instruction to open X11 before trying to run an X11 app is very necessary on Tiger and earlier, and should do no harm on Leopard and later. > - If you're using Mac OS X 10.3 then you can download the X11 > - installer from the Apple - url="http://apple.com/support/downloads/ > x11formacosx.html">download > - page. I wish you would not remove information about how to install X11 on Panther. > + Before launching an X11 application, you must open a > terminal window > + and start an xterm session. Really? Why? If X11 is open, it shouldn't matter if an xterm is open or not. > + %% xterm userinput> > + > + After the X11 session window opens, you may launch X11 > apps from > + another terminal window. See + linkend="installing.x11.settings">Optional X11 Settings > if you wish > + to launch X11 applications from an X11 session window. > + > > X11 and the X11SDK (from Xcode Tools) are both > required for X11 > apps. To verify the presence of both, check for files > @@ -66,18 +65,8 @@ > Optional X11 Settings > > To launch X11 applications directly from an X11 window > (instead of > - a terminal window), you need to have the MacPorts paths > imported into > - X11 sessions when they are opened. This is a two step > process. > - > - First, tell X11 about the ~/.profile filename> file > - that will be created after you install MacPorts. Do this by > editing the > - file /etc/X11/xinit/xinitrc and adding > this line > - near the top. > - > - source ~/.profile > - > - Now finish the process by making subsequent X11 > sessions opened > - using the menu bar respect your .profile > + a regular terminal window), you need to make it so X11 > sessions opened > + using the menu bar respect your .~profile > file. So.... these new instructions are now correct, for all versions of Mac OS X? From markd at macports.org Mon Sep 8 09:15:09 2008 From: markd at macports.org (markd at macports.org) Date: Mon, 08 Sep 2008 09:15:09 -0700 Subject: [39807] trunk/doc-new/guide/xml/installing.xml Message-ID: >The instruction to put X11 in the Dock never made much sense to me; >an application does not need to be in the Dock for me to be able to >open it. Isn't it funny how no one complains until a change is made. Did you not think of suggesting an improvement for .... what 2 years? Every part of the guide that I've done is my best shot with knowledge at the time and if my knowledge is shallow on that topic, as it is with X11, it is merely a starting point. I am always anxious to get better info. > >However, the instruction to open X11 before trying to run an X11 app >is very necessary on Tiger and earlier, and should do no harm on >Leopard and later. So if it makes no sense to launch X11 from the dock for pre-10.5, how do you advise doing it? > >> - If you're using Mac OS X 10.3 then you can download the X11 >> - installer from the Apple > - url="http://apple.com/support/downloads/ >> x11formacosx.html">download >> - page. > >I wish you would not remove information about how to install X11 on >Panther. > >> + Before launching an X11 application, you must open a >> terminal window >> + and start an xterm session. > >Really? Why? If X11 is open, it shouldn't matter if an xterm is open >or not. What we need is less questions and more answers. How should it be? > >So.... these new instructions are now correct, for all versions of >Mac OS X? No, they never have been, and you said anything about it or made suggestions on it. Maybe I could from what I've learned in the past 2 days if you'd supplied a suggestion on the best way to launch X11, but you didn't. If I knew how to make instructions correct for all versions I would. Do you? Someone has already mentioned that launching x11 was not necessary on 10.5 and I didn't realize that. Can I assume that you think having instructions that work on the version of the OS that is the latest *and has the most users* (right now) is important? That's what I think and I have no idea if you agree or not from your comments. That is not the only goal, but it is the first one. The previous instructions referred to file in a location where it no longer resides on 10.5, and the editing of which is no longer necessary and that's a big problem. The guide's x11 section has not met that goal I learned just days ago and tried to correct it, yet perhaps you've known it for at least months and not been concerned, and I can't even tell by your comments that you are very concerned still. Throwing out cryptic questions and frequently demands of various sorts to the doc team may not be any more fruitful than with port or other developers. I think Markus used to say "Do you have a patch?" I'm not trying to be a jerk, I'm just saying getting good info is hard to find and that is the problem with the guide, not that I have such different ideas from you. I think I could accomadate your concerns well enough, and I'd love to, if I had enough information. I'm pretty reasonable on my better days. :) Mark From matteo.tesser at gmail.com Wed Sep 10 10:18:08 2008 From: matteo.tesser at gmail.com (matteo tesser) Date: Wed, 10 Sep 2008 19:18:08 +0200 Subject: libgc Message-ID: <6db9529f0809101018j21d0e183w24200b0ba90e9df1@mail.gmail.com> Hi! Sorry if this is not the correct mailinglist but I would like to know if the package libgc (bohem garbage collector) will be inserted into macports or if is possible to install this package on macs (and where to obtain it) Thanks, Matteo From jmr at macports.org Wed Sep 10 10:46:36 2008 From: jmr at macports.org (Joshua Root) Date: Thu, 11 Sep 2008 03:46:36 +1000 Subject: libgc In-Reply-To: <6db9529f0809101018j21d0e183w24200b0ba90e9df1@mail.gmail.com> References: <6db9529f0809101018j21d0e183w24200b0ba90e9df1@mail.gmail.com> Message-ID: <48C807FC.3050101@macports.org> matteo tesser wrote: > Hi! > Sorry if this is not the correct mailinglist but I would like to know > if the package libgc (bohem garbage collector) will be inserted into > macports or if is possible to install this package on macs (and where > to obtain it) It's in MacPorts. The port is called boehmgc. - Josh From lists-macports at shopwatch.org Fri Sep 12 06:36:48 2008 From: lists-macports at shopwatch.org (Jay Levitt) Date: Fri, 12 Sep 2008 09:36:48 -0400 Subject: Identifying portname in a bug? Message-ID: <48CA7070.5060007@shopwatch.org> Is there any way to search for bugs in a specific port? I think the current answer is "no", unless the portname happens to be a usefully unique word. I'm running into a bug building "file", and I have no idea how to search for other such bugs. Is it easy to add custom fields to Trac? Is this something that could be done if only a volunteer (say, me) were to re-triage a bunch of bugs, or to research how to add fields in the first place? I feel like, in general, the MacPorts site could use more information about "the such-and-such" port. Right now, there's really no such concept, other than the listing of Portfiles. Would others want such a thing, and if so, what's a good place to start working? Jay Levitt From lists-macports at shopwatch.org Fri Sep 12 06:40:05 2008 From: lists-macports at shopwatch.org (Jay Levitt) Date: Fri, 12 Sep 2008 09:40:05 -0400 Subject: Building file 4.26: duplicate symbol? Message-ID: <48CA7135.4030309@shopwatch.org> The MacPorts "file" port has no maintainer, and is still at 4.25, although file 4.26 has been released (http://www.darwinsys.com/file/). I'd be happy to try my hand at maintaining the port, but I can't actually seem to build the thing. So this isn't a MacPorts question, per se, but I'm hoping someone has run into this while building other not-designed-for-Mac software. I've asked on the "file" list, but there's very little volume there, and I don't know if any of the authors even has a Mac. The problem: When building file 4.26, on OS X 10.5.4 Leopard, I get a duplicate symbol error from ld. I don't know enough about object modules to debug unaided, but if someone can let me know how to troubleshoot this, I'm happy to dig further. 4.25 builds fine on the same machine; 4.26 builds on my Fedora machine. I also tried: make distclean autoreconf ./configure make but the same thing happened. There's an interesting bug at http://issues.sxemacs.org/show_bug.cgi?id=42 which may be related; apparently Apple's gcc does something different with inlines and C99? My C-fu is rusty (and predates C99). The error: ld: duplicate symbol _li in .libs/apprentice.o and .libs/magic.o Toolchain (copyrights snipped): macpro% gcc --version i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5465) macpro% ld -v @(#)PROGRAM:ld PROJECT:ld64-77 macpro% m4 --version GNU M4 1.4.6 macpro% make --version GNU Make 3.81 The full configure/make output: macpro% ./configure checking for a BSD-compatible install... /opt/local/bin/ginstall -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /opt/local/bin/gmkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for builtin ELF support... yes checking for ELF core file support... yes checking for file formats in man section 5... no checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking whether gcc and cc understand -c and -o together... yes checking for a BSD-compatible install... /opt/local/bin/ginstall -c checking whether ln -s works... yes checking build system type... i386-apple-darwin9.4.0 checking host system type... i386-apple-darwin9.4.0 checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ld used by gcc... /usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld checking if the linker (/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld) is GNU ld... no checking for /usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for xlf... no checking for f77... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for xlf90... no checking for f90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... no checking for g95... no checking for xlf95... no checking for f95... no checking for fort... no checking for ifort... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for ftn... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 196608 checking command to parse /usr/bin/nm -p output from gcc object... rm: conftest.dSYM: is a directory rm: conftest.dSYM: is a directory rm: conftest.dSYM: is a directory rm: conftest.dSYM: is a directory ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip rm: conftest.dSYM: is a directory rm: conftest.dSYM: is a directory checking if gcc static flag works... rm: conftest.dSYM: is a directory yes checking if gcc supports -fno-rtti -fno-exceptions... rm: conftest.dSYM: is a directory no checking for gcc option to produce PIC... -fno-common checking if gcc PIC flag -fno-common works... rm: conftest.dSYM: is a directory yes checking if gcc supports -c -o file.o... rm: conftest.dSYM: is a directory yes checking whether the gcc linker (/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin9.4.0 dyld checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool rm: conftest.dSYM: is a directory rm: conftest.dSYM: is a directory checking for ld used by g++... /usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld checking if the linker (/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld) is GNU ld... no checking whether the g++ linker (/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fno-common checking if g++ PIC flag -fno-common works... rm: conftest.dSYM: is a directory yes checking if g++ supports -c -o file.o... rm: conftest.dSYM: is a directory yes checking whether the g++ linker (/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin9.4.0 dyld checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking for ANSI C header files... (cached) yes checking whether sys/types.h defines makedev... yes checking for sys/wait.h that is POSIX.1 compatible... yes checking for stdint.h... (cached) yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking for stdint.h... (cached) yes checking for inttypes.h... (cached) yes checking for unistd.h... (cached) yes checking utime.h usability... yes checking utime.h presence... yes checking for utime.h... yes checking wchar.h usability... yes checking wchar.h presence... yes checking for wchar.h... yes checking wctype.h usability... yes checking wctype.h presence... yes checking for wctype.h... yes checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking getopt.h usability... yes checking getopt.h presence... yes checking for getopt.h... yes checking err.h usability... yes checking err.h presence... yes checking for err.h... yes checking sys/mman.h usability... yes checking sys/mman.h presence... yes checking for sys/mman.h... yes checking for sys/stat.h... (cached) yes checking for sys/types.h... (cached) yes checking sys/utime.h usability... no checking sys/utime.h presence... no checking for sys/utime.h... no checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking zlib.h usability... yes checking zlib.h presence... yes checking for zlib.h... yes checking for an ANSI C-conforming const... yes checking for off_t... yes checking for size_t... yes checking for struct stat.st_rdev... yes checking whether struct tm is in sys/time.h or time.h... time.h checking for tm_zone in struct tm... yes checking for tzname... yes checking for tm_isdst in struct tm... yes checking for daylight... yes checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... no rm: conftest.dSYM: is a directory checking for _LARGEFILE_SOURCE value needed for large files... no rm: conftest.dSYM: is a directory checking for mbstate_t... yes checking for uint8_t... yes checking for uint16_t... yes checking for uint32_t... yes checking for int32_t... yes checking for uint64_t... yes checking for int64_t... yes checking for long long... yes checking size of long long... 8 checking for gcc compiler warnings... yes checking for mmap... yes checking for strerror... yes checking for strndup... no checking for strtoul... yes checking for mbrtowc... yes checking for mkstemp... yes checking for utimes... yes checking for utime... yes checking for wcwidth... yes checking for strtof... yes checking for getopt_long... yes checking for asprintf... yes checking for vasprintf... yes checking for gzopen in -lz... yes configure: creating ./config.status config.status: creating Makefile config.status: creating src/Makefile config.status: creating magic/Makefile config.status: creating tests/Makefile config.status: creating doc/Makefile config.status: creating python/Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands macpro% make make all-recursive Making all in src /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC='"/usr/local/share/file/magic"' -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT magic.lo -MD -MP -MF .deps/magic.Tpo -c -o magic.lo magic.c mkdir .libs gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC=\"/usr/local/share/file/magic\" -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT magic.lo -MD -MP -MF .deps/magic.Tpo -c magic.c -fno-common -DPIC -o .libs/magic.o gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC=\"/usr/local/share/file/magic\" -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT magic.lo -MD -MP -MF .deps/magic.Tpo -c magic.c -o magic.o >/dev/null 2>&1 mv -f .deps/magic.Tpo .deps/magic.Plo /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC='"/usr/local/share/file/magic"' -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT apprentice.lo -MD -MP -MF .deps/apprentice.Tpo -c -o apprentice.lo apprentice.c gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC=\"/usr/local/share/file/magic\" -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT apprentice.lo -MD -MP -MF .deps/apprentice.Tpo -c apprentice.c -fno-common -DPIC -o .libs/apprentice.o apprentice.c: In function 'load_1': apprentice.c:1699: warning: 'slen' may be used uninitialized in this function gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC=\"/usr/local/share/file/magic\" -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT apprentice.lo -MD -MP -MF .deps/apprentice.Tpo -c apprentice.c -o apprentice.o >/dev/null 2>&1 mv -f .deps/apprentice.Tpo .deps/apprentice.Plo /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC='"/usr/local/share/file/magic"' -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT softmagic.lo -MD -MP -MF .deps/softmagic.Tpo -c -o softmagic.lo softmagic.c gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC=\"/usr/local/share/file/magic\" -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT softmagic.lo -MD -MP -MF .deps/softmagic.Tpo -c softmagic.c -fno-common -DPIC -o .libs/softmagic.o softmagic.c: In function 'mcopy': softmagic.c:848: warning: format '%zu' expects type 'size_t', but argument 3 has type 'uint32_t' gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC=\"/usr/local/share/file/magic\" -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT softmagic.lo -MD -MP -MF .deps/softmagic.Tpo -c softmagic.c -o softmagic.o >/dev/null 2>&1 mv -f .deps/softmagic.Tpo .deps/softmagic.Plo /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC='"/usr/local/share/file/magic"' -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT ascmagic.lo -MD -MP -MF .deps/ascmagic.Tpo -c -o ascmagic.lo ascmagic.c gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC=\"/usr/local/share/file/magic\" -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT ascmagic.lo -MD -MP -MF .deps/ascmagic.Tpo -c ascmagic.c -fno-common -DPIC -o .libs/ascmagic.o gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC=\"/usr/local/share/file/magic\" -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT ascmagic.lo -MD -MP -MF .deps/ascmagic.Tpo -c ascmagic.c -o ascmagic.o >/dev/null 2>&1 mv -f .deps/ascmagic.Tpo .deps/ascmagic.Plo /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC='"/usr/local/share/file/magic"' -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT compress.lo -MD -MP -MF .deps/compress.Tpo -c -o compress.lo compress.c gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC=\"/usr/local/share/file/magic\" -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT compress.lo -MD -MP -MF .deps/compress.Tpo -c compress.c -fno-common -DPIC -o .libs/compress.o gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC=\"/usr/local/share/file/magic\" -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT compress.lo -MD -MP -MF .deps/compress.Tpo -c compress.c -o compress.o >/dev/null 2>&1 mv -f .deps/compress.Tpo .deps/compress.Plo /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC='"/usr/local/share/file/magic"' -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT is_tar.lo -MD -MP -MF .deps/is_tar.Tpo -c -o is_tar.lo is_tar.c gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC=\"/usr/local/share/file/magic\" -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT is_tar.lo -MD -MP -MF .deps/is_tar.Tpo -c is_tar.c -fno-common -DPIC -o .libs/is_tar.o gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC=\"/usr/local/share/file/magic\" -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT is_tar.lo -MD -MP -MF .deps/is_tar.Tpo -c is_tar.c -o is_tar.o >/dev/null 2>&1 mv -f .deps/is_tar.Tpo .deps/is_tar.Plo /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC='"/usr/local/share/file/magic"' -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT readelf.lo -MD -MP -MF .deps/readelf.Tpo -c -o readelf.lo readelf.c gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC=\"/usr/local/share/file/magic\" -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT readelf.lo -MD -MP -MF .deps/readelf.Tpo -c readelf.c -fno-common -DPIC -o .libs/readelf.o gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC=\"/usr/local/share/file/magic\" -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT readelf.lo -MD -MP -MF .deps/readelf.Tpo -c readelf.c -o readelf.o >/dev/null 2>&1 mv -f .deps/readelf.Tpo .deps/readelf.Plo /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC='"/usr/local/share/file/magic"' -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT print.lo -MD -MP -MF .deps/print.Tpo -c -o print.lo print.c gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC=\"/usr/local/share/file/magic\" -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT print.lo -MD -MP -MF .deps/print.Tpo -c print.c -fno-common -DPIC -o .libs/print.o gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC=\"/usr/local/share/file/magic\" -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT print.lo -MD -MP -MF .deps/print.Tpo -c print.c -o print.o >/dev/null 2>&1 mv -f .deps/print.Tpo .deps/print.Plo /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC='"/usr/local/share/file/magic"' -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT fsmagic.lo -MD -MP -MF .deps/fsmagic.Tpo -c -o fsmagic.lo fsmagic.c gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC=\"/usr/local/share/file/magic\" -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT fsmagic.lo -MD -MP -MF .deps/fsmagic.Tpo -c fsmagic.c -fno-common -DPIC -o .libs/fsmagic.o gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC=\"/usr/local/share/file/magic\" -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT fsmagic.lo -MD -MP -MF .deps/fsmagic.Tpo -c fsmagic.c -o fsmagic.o >/dev/null 2>&1 mv -f .deps/fsmagic.Tpo .deps/fsmagic.Plo /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC='"/usr/local/share/file/magic"' -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT funcs.lo -MD -MP -MF .deps/funcs.Tpo -c -o funcs.lo funcs.c gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC=\"/usr/local/share/file/magic\" -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT funcs.lo -MD -MP -MF .deps/funcs.Tpo -c funcs.c -fno-common -DPIC -o .libs/funcs.o gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC=\"/usr/local/share/file/magic\" -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT funcs.lo -MD -MP -MF .deps/funcs.Tpo -c funcs.c -o funcs.o >/dev/null 2>&1 mv -f .deps/funcs.Tpo .deps/funcs.Plo /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC='"/usr/local/share/file/magic"' -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT apptype.lo -MD -MP -MF .deps/apptype.Tpo -c -o apptype.lo apptype.c gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC=\"/usr/local/share/file/magic\" -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT apptype.lo -MD -MP -MF .deps/apptype.Tpo -c apptype.c -fno-common -DPIC -o .libs/apptype.o gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC=\"/usr/local/share/file/magic\" -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT apptype.lo -MD -MP -MF .deps/apptype.Tpo -c apptype.c -o apptype.o >/dev/null 2>&1 mv -f .deps/apptype.Tpo .deps/apptype.Plo /bin/sh ../libtool --tag=CC --mode=link gcc -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -no-undefined -version-info 1:0:0 -o libmagic.la -rpath /usr/local/lib magic.lo apprentice.lo softmagic.lo ascmagic.lo compress.lo is_tar.lo readelf.lo print.lo fsmagic.lo funcs.lo apptype.lo -lz gcc -dynamiclib -o .libs/libmagic.1.0.0.dylib .libs/magic.o .libs/apprentice.o .libs/softmagic.o .libs/ascmagic.o .libs/compress.o .libs/is_tar.o .libs/readelf.o .libs/print.o .libs/fsmagic.o .libs/funcs.o .libs/apptype.o -lz -install_name /usr/local/lib/libmagic.1.dylib -Wl,-compatibility_version -Wl,2 -Wl,-current_version -Wl,2.0 ld: duplicate symbol _li in .libs/apprentice.o and .libs/magic.o collect2: ld returned 1 exit status make[2]: *** [libmagic.la] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 The only debugging step I know: macpro% nm src/.libs/apprentice.o | grep _li 0000cc40 S _li macpro% nm src/.libs/magic.o | grep _li 000029f8 S _li (NB: this symbol does not appear in either .o on my Fedora machine, although "li" (no underscore) appears in both, as a [C]ommon symbol) From raimue at macports.org Fri Sep 12 06:42:54 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri, 12 Sep 2008 15:42:54 +0200 Subject: Identifying portname in a bug? In-Reply-To: <48CA7070.5060007@shopwatch.org> References: <48CA7070.5060007@shopwatch.org> Message-ID: <48CA71DE.2070807@macports.org> Jay Levitt wrote: > Is there any way to search for bugs in a specific port? I think the current > answer is "no", unless the portname happens to be a usefully unique word. > I'm running into a bug building "file", and I have no idea how to search for > other such bugs. > > Is it easy to add custom fields to Trac? Is this something that could be > done if only a volunteer (say, me) were to re-triage a bunch of bugs, or to > research how to add fields in the first place? The field was already added recently. But it is not used in older bugs. So it would help if only anyone editing a bug would populate this field as well. Rainer From florian.ebeling at gmail.com Fri Sep 12 06:46:10 2008 From: florian.ebeling at gmail.com (Caspar Florian Ebeling) Date: Fri, 12 Sep 2008 15:46:10 +0200 Subject: Identifying portname in a bug? In-Reply-To: <48CA7070.5060007@shopwatch.org> References: <48CA7070.5060007@shopwatch.org> Message-ID: <5cbbe4ae0809120646m4e1467c2u135443c0971409db@mail.gmail.com> On Fri, Sep 12, 2008 at 3:36 PM, Jay Levitt wrote: > Is there any way to search for bugs in a specific port? I think the current > answer is "no", unless the portname happens to be a usefully unique word. > I'm running into a bug building "file", and I have no idea how to search for > other such bugs. there is only the convention to put the port name as the first part of the summary field. That's often not followed though. It's put down in the guide: http://guide.macports.org/#project.tickets.guidelines > Is it easy to add custom fields to Trac? Is this something that could be > done if only a volunteer (say, me) were to re-triage a bunch of bugs, or to > research how to add fields in the first place? > > I feel like, in general, the MacPorts site could use more information about > "the such-and-such" port. Right now, there's really no such concept, other > than the listing of Portfiles. Would others want such a thing, and if so, > what's a good place to start working? there is mpwa, or the MacPorts Web App, a rails application of which I don't know the status. And I for one would definitely want such a thing and are happy that somebody suggest it as well. Florian -- Florian Ebeling florian.ebeling at gmail.com From florian.ebeling at gmail.com Fri Sep 12 06:48:02 2008 From: florian.ebeling at gmail.com (Caspar Florian Ebeling) Date: Fri, 12 Sep 2008 15:48:02 +0200 Subject: Identifying portname in a bug? In-Reply-To: <48CA71DE.2070807@macports.org> References: <48CA7070.5060007@shopwatch.org> <48CA71DE.2070807@macports.org> Message-ID: <5cbbe4ae0809120648h207db72dnf60342eb427fd3c5@mail.gmail.com> > The field was already added recently. But it is not used in older bugs. > So it would help if only anyone editing a bug would populate this field > as well. oh, yes, sorry, so I missed that and my information was stale. Florian -- Florian Ebeling florian.ebeling at gmail.com From lists-macports at shopwatch.org Fri Sep 12 11:45:06 2008 From: lists-macports at shopwatch.org (Jay Levitt) Date: Fri, 12 Sep 2008 14:45:06 -0400 Subject: Identifying portname in a bug? In-Reply-To: <5cbbe4ae0809120648h207db72dnf60342eb427fd3c5@mail.gmail.com> References: <48CA7070.5060007@shopwatch.org> <48CA71DE.2070807@macports.org> <5cbbe4ae0809120648h207db72dnf60342eb427fd3c5@mail.gmail.com> Message-ID: <48CAB8B2.6060904@shopwatch.org> Caspar Florian Ebeling wrote: >> The field was already added recently. But it is not used in older bugs. >> So it would help if only anyone editing a bug would populate this field >> as well. > > oh, yes, sorry, so I missed that and my information was stale. ...so you can see why I think it ought to be a more visible field... :) Suggestions for new ticket entry: 1. Upon entering a new ticket, I do see the "port" field, but it's dead last, after "keywords" and even "CC". I'd put it next to "component", since "port" is a subcategory of the "ports" component. 2. Ideally, "port" should be two fields: port name, and port version. Sure, we can establish a convention, but software's much better at that than humans. I'd like to be able to search for all bugs on the postgresql port, or only bugs reported on the latest version. 3. Does trac allow an arbitrary validation script to run? If so, we could check that the portname was, in fact, the name of a valid port. 4. "Version" should then change to "MacPorts" version. 5. For extra bonus UI points, "portname" and "port version" should be unselectable until component=ports. 6. Make the portname field required on the form for all new tickets, and (I think) for updates to all existing tickets. Argument against the latter: "I just want to provide some helpful information! I shouldn't have to do data entry." Counterargument: "From a philosophically pure standpoint, you're right. From a pragmatic standpoint, it's just asking for information you already know: the name of the port. And it helps us all." I know nothing about Trac, so what I'm suggesting might be easy or hard. If it's hard, but you like the idea, I'll volunteer to do the legwork. For reports: Add the portname and port version fields to the existing columns in the default reports; right now, they show "component" but not "port". For existing tickets: I think I could write a script that goes through trac as an HTTP client (or is there a REST API?), pulls the portname out of the summary, and moves it into the portname and version fields. You'd want to turn off that trac-tickets feed while it was running, though, at least for tickets modified by me.. Other: The "ports.php" search page should link to the bug reports for that port. I think that all these would help make individual ports "first class citizens" of MacPorts, which will in turn make it easier for users to report bugs, and maintainers to fix them. What do you all think? Jay From dluke at geeklair.net Fri Sep 12 12:01:56 2008 From: dluke at geeklair.net (Daniel J. Luke) Date: Fri, 12 Sep 2008 15:01:56 -0400 Subject: Port iso-codes In-Reply-To: References: <326B671C-EA5E-4925-A8FB-2E2DFF310013@nzbox.com> <48C0A48F.6010801@orcaware.com> Message-ID: <72BCF832-6959-49EE-A178-B3F54FFDE822@geeklair.net> On Sep 4, 2008, at 11:28 PM, William Siegrist wrote: > Someone could provide a mirror that is located in an FTP-friendly > network. Or maintainers of FTP-only ports could host them on HTTP > long enough for the mirror to get a copy. Or we could do some sort of ftp->http gateway for the macosforge machines (perhaps something as simple as a remote shell on another host that could download the file to a temp location that available for http). I have a host we could use, if you're interested. -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080912/20b92ba7/attachment.bin From wsiegrist at apple.com Fri Sep 12 13:01:02 2008 From: wsiegrist at apple.com (William Siegrist) Date: Fri, 12 Sep 2008 13:01:02 -0700 Subject: Identifying portname in a bug? In-Reply-To: <48CAB8B2.6060904@shopwatch.org> References: <48CA7070.5060007@shopwatch.org> <48CA71DE.2070807@macports.org> <5cbbe4ae0809120648h207db72dnf60342eb427fd3c5@mail.gmail.com> <48CAB8B2.6060904@shopwatch.org> Message-ID: <067BAE96-5D55-4C4B-B5EA-4AF0358E2B1D@apple.com> On Sep 12, 2008, at 11:45 AM, Jay Levitt wrote: > Caspar Florian Ebeling wrote: >>> The field was already added recently. But it is not used in older >>> bugs. >>> So it would help if only anyone editing a bug would populate this >>> field >>> as well. >> >> oh, yes, sorry, so I missed that and my information was stale. > > ...so you can see why I think it ought to be a more visible > field... :) > > Suggestions for new ticket entry: > > 1. Upon entering a new ticket, I do see the "port" field, but it's > dead > last, after "keywords" and even "CC". I'd put it next to > "component", since > "port" is a subcategory of the "ports" component. > > 2. Ideally, "port" should be two fields: port name, and port > version. Sure, > we can establish a convention, but software's much better at that than > humans. I'd like to be able to search for all bugs on the > postgresql port, > or only bugs reported on the latest version. > I'm +1 for #1 and #2, if no one else objects, please file a ticket against server/hosting with these. > 3. Does trac allow an arbitrary validation script to run? If so, we > could > check that the portname was, in fact, the name of a valid port. > This is already covered by the original Port field ticket, which is a work in progress: http://trac.macports.org/ticket/15210 > 4. "Version" should then change to "MacPorts" version. > This is non-trivial (changing a core Trac field). I also feel that the fact that it lists version numbers for MacPorts makes it fairly obvious. Perhaps making the versions show "MacPorts 1.6.0" etc would help? I dont think its that big of a deal though. That being said, it _is_ possible, so if other people agree go ahead and file a ticket against server/hosting. > 5. For extra bonus UI points, "portname" and "port version" should be > unselectable until component=ports. > I think its possible to have other components relate to ports, (a base bug specific to a port, or portgroup, etc). So I dont think its worth the engineering effort to pull this off. > 6. Make the portname field required on the form for all new tickets, > and (I > think) for updates to all existing tickets. Argument against the > latter: "I > just want to provide some helpful information! I shouldn't have to > do data > entry." Counterargument: "From a philosophically pure standpoint, > you're > right. From a pragmatic standpoint, it's just asking for > information you > already know: the name of the port. And it helps us all." This would be implemented the same way as #3 above. So if you want to comment on that ticket to request that it also be "required" when component=ports, and optional otherwise, I think I can do that. So I'm +1 on this item when component=ports. > > > I know nothing about Trac, so what I'm suggesting might be easy or > hard. If > it's hard, but you like the idea, I'll volunteer to do the legwork. > Its a standard Trac v0.11 setup, feel free to contribute plugins. > For reports: > > Add the portname and port version fields to the existing columns in > the > default reports; right now, they show "component" but not "port". > Good catch, I never went back and added it. Please file a ticket for all applicable reports to include the port field. > For existing tickets: > > I think I could write a script that goes through trac as an HTTP > client (or > is there a REST API?), pulls the portname out of the summary, and > moves it > into the portname and version fields. You'd want to turn off that > trac-tickets feed while it was running, though, at least for tickets > modified by me.. > I can just do it at the SQL level and avoid all the notification mess. If you want to write something up, our Trac is backed by PostgreSQL v8.2. Go ahead and lump this into the ticket for #3 and #6 > Other: > > The "ports.php" search page should link to the bug reports for that > port. > ports.php is in the repo, seems trivial to add a link to "/query? port=" or whatever it would be. This should be a separate ticket, but still server/hosting. Any committer should be able to do this though. "For bonus points" an attached patch would be great. :) Thanks -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080912/1424bc75/attachment.bin From wsiegrist at apple.com Fri Sep 12 13:10:45 2008 From: wsiegrist at apple.com (William Siegrist) Date: Fri, 12 Sep 2008 13:10:45 -0700 Subject: Port iso-codes In-Reply-To: <72BCF832-6959-49EE-A178-B3F54FFDE822@geeklair.net> References: <326B671C-EA5E-4925-A8FB-2E2DFF310013@nzbox.com> <48C0A48F.6010801@orcaware.com> <72BCF832-6959-49EE-A178-B3F54FFDE822@geeklair.net> Message-ID: On Sep 12, 2008, at 12:01 PM, Daniel J. Luke wrote: > On Sep 4, 2008, at 11:28 PM, William Siegrist wrote: >> Someone could provide a mirror that is located in an FTP-friendly >> network. Or maintainers of FTP-only ports could host them on HTTP >> long enough for the mirror to get a copy. > > Or we could do some sort of ftp->http gateway for the macosforge > machines (perhaps something as simple as a remote shell on another > host that could download the file to a temp location that available > for http). > > I have a host we could use, if you're interested. The server just uses the built in mirror command, so that would have to be modified to check for some sort of FTP_PROXY env variable. Then your box would proxy from http to ftp? -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080912/13250f3c/attachment.bin From dluke at geeklair.net Fri Sep 12 13:24:29 2008 From: dluke at geeklair.net (Daniel J. Luke) Date: Fri, 12 Sep 2008 16:24:29 -0400 Subject: Port iso-codes In-Reply-To: References: <326B671C-EA5E-4925-A8FB-2E2DFF310013@nzbox.com> <48C0A48F.6010801@orcaware.com> <72BCF832-6959-49EE-A178-B3F54FFDE822@geeklair.net> Message-ID: <5B883765-99AA-4B42-8BB0-BDA1BCD64F23@geeklair.net> On Sep 12, 2008, at 4:10 PM, William Siegrist wrote: > On Sep 12, 2008, at 12:01 PM, Daniel J. Luke wrote: >> On Sep 4, 2008, at 11:28 PM, William Siegrist wrote: >>> Someone could provide a mirror that is located in an FTP-friendly >>> network. Or maintainers of FTP-only ports could host them on HTTP >>> long enough for the mirror to get a copy. >> >> Or we could do some sort of ftp->http gateway for the macosforge >> machines (perhaps something as simple as a remote shell on another >> host that could download the file to a temp location that available >> for http). >> >> I have a host we could use, if you're interested. > > The server just uses the built in mirror command, so that would have > to be modified to check for some sort of FTP_PROXY env variable. > Then your box would proxy from http to ftp? My initial thought would be to have the process on the macosforge machine do a remote shell command to get my box to pull the file into an area that I set up to be served via http. Then I would probably cron up something to remove any files there after a few days. Alternatively, I could write a CGI (or find one?) that does the ftp fetch and serves up the file via http. -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080912/1813927d/attachment-0001.bin From 0x62_0x6c_0x62 at pobox.com Fri Sep 12 13:29:48 2008 From: 0x62_0x6c_0x62 at pobox.com (Bryan Blackburn) Date: Fri, 12 Sep 2008 14:29:48 -0600 Subject: Building file 4.26: duplicate symbol? In-Reply-To: <48CA7135.4030309@shopwatch.org> References: <48CA7135.4030309@shopwatch.org> Message-ID: <20080912202948.GG672@ninagal.withay.com> On Fri, Sep 12, 2008 at 09:40:05AM -0400, Jay Levitt said: [...] > > When building file 4.26, on OS X 10.5.4 Leopard, I get a duplicate symbol > error from ld. I don't know enough about object modules to debug unaided, > but if someone can let me know how to troubleshoot this, I'm happy to dig > further. > Looks like the issue is in src/file.h, specifically it defines struct level_info, and creates a pointer to that struct '*li'. Since file.h is included in multiple files, you get the dup symbol error. Removing the *li gets it to build fine here; patch that does so is attached. Simply removing it seems okay since the variable isn't actually used anywhere. Bryan [...] -------------- next part -------------- --- src/file.h.orig 2008-07-26 09:03:55.000000000 -0600 +++ src/file.h 2008-09-12 14:21:26.000000000 -0600 @@ -302,7 +302,7 @@ int last_match; int last_cond; /* used for error checking by parse() */ #endif -} *li; +}; struct magic_set { struct mlist *mlist; struct cont { From wsiegrist at apple.com Fri Sep 12 13:44:55 2008 From: wsiegrist at apple.com (William Siegrist) Date: Fri, 12 Sep 2008 13:44:55 -0700 Subject: Port iso-codes In-Reply-To: <5B883765-99AA-4B42-8BB0-BDA1BCD64F23@geeklair.net> References: <326B671C-EA5E-4925-A8FB-2E2DFF310013@nzbox.com> <48C0A48F.6010801@orcaware.com> <72BCF832-6959-49EE-A178-B3F54FFDE822@geeklair.net> <5B883765-99AA-4B42-8BB0-BDA1BCD64F23@geeklair.net> Message-ID: On Sep 12, 2008, at 1:24 PM, Daniel J. Luke wrote: > On Sep 12, 2008, at 4:10 PM, William Siegrist wrote: >> On Sep 12, 2008, at 12:01 PM, Daniel J. Luke wrote: >>> On Sep 4, 2008, at 11:28 PM, William Siegrist wrote: >>>> Someone could provide a mirror that is located in an FTP-friendly >>>> network. Or maintainers of FTP-only ports could host them on HTTP >>>> long enough for the mirror to get a copy. >>> >>> Or we could do some sort of ftp->http gateway for the macosforge >>> machines (perhaps something as simple as a remote shell on another >>> host that could download the file to a temp location that >>> available for http). >>> >>> I have a host we could use, if you're interested. >> >> The server just uses the built in mirror command, so that would >> have to be modified to check for some sort of FTP_PROXY env >> variable. Then your box would proxy from http to ftp? > > > My initial thought would be to have the process on the macosforge > machine do a remote shell command to get my box to pull the file > into an area that I set up to be served via http. Then I would > probably cron up something to remove any files there after a few days. > > Alternatively, I could write a CGI (or find one?) that does the ftp > fetch and serves up the file via http. > So have the mirror subcommand check for an env var being set that tells it that FTP isnt available, and then "curl http://server/fetch?url= ". We also add your server as a default site the same way distfiles.macports.org is, so the mirror server will get this file on the next try? A 3 day expiration on distfiles seems reasonable since retries happen daily. You'll probably want this server to limit /fetch to our IP range so its not an open proxy. And it might be better to pass the portname instead, though that would require your end to get a fresh checkout/ update before fetching since this process runs during post-commit. I believe the code for this part of the post-commit is in the repo under portmgr/jobs. This does seem a bit over-engineered. I would like to have a way for committers to add files to the mirror (via web form), but I need to be careful with the security model for that, so I havnt worked out the details for it yet. Maybe we should wait for a simple web form instead of doing this relaying or files. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080912/acee8eb2/attachment.bin From dluke at geeklair.net Fri Sep 12 13:57:57 2008 From: dluke at geeklair.net (Daniel J. Luke) Date: Fri, 12 Sep 2008 16:57:57 -0400 Subject: Port iso-codes In-Reply-To: References: <326B671C-EA5E-4925-A8FB-2E2DFF310013@nzbox.com> <48C0A48F.6010801@orcaware.com> <72BCF832-6959-49EE-A178-B3F54FFDE822@geeklair.net> <5B883765-99AA-4B42-8BB0-BDA1BCD64F23@geeklair.net> Message-ID: On Sep 12, 2008, at 4:44 PM, William Siegrist wrote: > This does seem a bit over-engineered. I would like to have a way > for committers to add files to the mirror (via web form), but I need > to be careful with the security model for that, so I havnt worked > out the details for it yet. Maybe we should wait for a simple web > form instead of doing this relaying or files. That works for me. We can revisit if that ends up being a bigger issue for you (and/or if you ever are able to ftp from the mirror machine(s)). -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080912/f9fb934f/attachment.bin From lists-macports at shopwatch.org Fri Sep 12 16:28:56 2008 From: lists-macports at shopwatch.org (Jay Levitt) Date: Fri, 12 Sep 2008 19:28:56 -0400 Subject: Identifying portname in a bug? In-Reply-To: <067BAE96-5D55-4C4B-B5EA-4AF0358E2B1D@apple.com> References: <48CA7070.5060007@shopwatch.org> <48CA71DE.2070807@macports.org> <5cbbe4ae0809120648h207db72dnf60342eb427fd3c5@mail.gmail.com> <48CAB8B2.6060904@shopwatch.org> <067BAE96-5D55-4C4B-B5EA-4AF0358E2B1D@apple.com> Message-ID: <48CAFB38.80207@shopwatch.org> William Siegrist wrote: > On Sep 12, 2008, at 11:45 AM, Jay Levitt wrote: >> Suggestions for new ticket entry: [summarized] [1. Move "port" next to "component" on entry form] [2. Separate "port" into "portname" and "port version"] > I'm +1 for #1 and #2, if no one else objects, please file a ticket > against server/hosting with these. Will do, pending discussion. >> 3. Does trac allow an arbitrary validation script to run? If so, we >> could >> check that the portname was, in fact, the name of a valid port. >> > > This is already covered by the original Port field ticket, which is a > work in progress: > > http://trac.macports.org/ticket/15210 Cool. I should've been clearer about "arbitrary"; I meant as in "Could I contribute something in Ruby, cuz I ain't learned Python yet." I think Trac plugins can only be Python eggs. (It's really hard to find discussions ABOUT Trac on Google; you get everyone's Trac site instead.) Oh well. >> 4. "Version" should then change to "MacPorts" version. >> > > This is non-trivial (changing a core Trac field). I also feel that the > fact that it lists version numbers for MacPorts makes it fairly obvious. > Perhaps making the versions show "MacPorts 1.6.0" etc would help? I dont > think its that big of a deal though. That being said, it _is_ possible, > so if other people agree go ahead and file a ticket against server/hosting. Ugh, not worth it then.. I was just being all symmetrical. I -1 myself. >> 5. For extra bonus UI points, "portname" and "port version" should be >> unselectable until component=ports. >> > > I think its possible to have other components relate to ports, (a base > bug specific to a port, or portgroup, etc). So I dont think its worth > the engineering effort to pull this off. That makes sense. [6. Require portname for new tickets and for editing existing ones] > So I'm > +1 on this item when component=ports. OK, I'll add that to the ticket. [Add portname/version fields to reports] I'll file a ticket. >> I think I could write a script that goes through trac as an HTTP >> client (or is there a REST API?), pulls the portname out of the summary, and >> moves it into the portname and version fields. You'd want to turn off that >> trac-tickets feed while it was running, though, at least for tickets >> modified by me.. > > I can just do it at the SQL level and avoid all the notification mess. > If you want to write something up, our Trac is backed by PostgreSQL > v8.2. Go ahead and lump this into the ticket for #3 and #6 Great. I'll set up a Trac early next week to play with the schema. >> Other: >> >> The "ports.php" search page should link to the bug reports for that port. >> > > ports.php is in the repo, seems trivial to add a link to > "/query?port=" or whatever it would be. This should be a > separate ticket, but still server/hosting. Any committer should be able > to do this though. "For bonus points" an attached patch would be great. :) OK! I ain't learned much PHP either, but I think I can hack an href out of it :) Thanks for the quick response and encouragement. I just knew there was a way I could put off working on my real project. Jay From jmr at macports.org Fri Sep 12 16:44:43 2008 From: jmr at macports.org (Joshua Root) Date: Sat, 13 Sep 2008 09:44:43 +1000 Subject: Port iso-codes In-Reply-To: References: <326B671C-EA5E-4925-A8FB-2E2DFF310013@nzbox.com> <48C0A48F.6010801@orcaware.com> <72BCF832-6959-49EE-A178-B3F54FFDE822@geeklair.net> Message-ID: <48CAFEEB.1040100@macports.org> William Siegrist wrote: > On Sep 12, 2008, at 12:01 PM, Daniel J. Luke wrote: > >> On Sep 4, 2008, at 11:28 PM, William Siegrist wrote: >>> Someone could provide a mirror that is located in an FTP-friendly >>> network. Or maintainers of FTP-only ports could host them on HTTP >>> long enough for the mirror to get a copy. >> >> Or we could do some sort of ftp->http gateway for the macosforge >> machines (perhaps something as simple as a remote shell on another >> host that could download the file to a temp location that available >> for http). >> >> I have a host we could use, if you're interested. > > The server just uses the built in mirror command, so that would have to > be modified to check for some sort of FTP_PROXY env variable. Fetch should respect FTP_PROXY. If not, that's a bug. - Josh From wsiegrist at apple.com Fri Sep 12 17:13:45 2008 From: wsiegrist at apple.com (William Siegrist) Date: Fri, 12 Sep 2008 17:13:45 -0700 Subject: Identifying portname in a bug? In-Reply-To: <48CAFB38.80207@shopwatch.org> References: <48CA7070.5060007@shopwatch.org> <48CA71DE.2070807@macports.org> <5cbbe4ae0809120648h207db72dnf60342eb427fd3c5@mail.gmail.com> <48CAB8B2.6060904@shopwatch.org> <067BAE96-5D55-4C4B-B5EA-4AF0358E2B1D@apple.com> <48CAFB38.80207@shopwatch.org> Message-ID: On Sep 12, 2008, at 4:28 PM, Jay Levitt wrote: > William Siegrist wrote: >> On Sep 12, 2008, at 11:45 AM, Jay Levitt wrote: >>> >>> 3. Does trac allow an arbitrary validation script to run? If so, >>> we could >>> check that the portname was, in fact, the name of a valid port. >>> >> This is already covered by the original Port field ticket, which is >> a work in progress: >> http://trac.macports.org/ticket/15210 > > Cool. I should've been clearer about "arbitrary"; I meant as in > "Could I contribute something in Ruby, cuz I ain't learned Python > yet." I think Trac plugins can only be Python eggs. (It's really > hard to find discussions ABOUT Trac on Google; you get everyone's > Trac site instead.) Oh well. > Yes, its a little tough, but Trac's Trac is at http:// trac.edgewall.org/. So this is a good place to start: http://trac.edgewall.org/wiki/TracDev/PluginDevelopment Basically, there is a list of component extension points that you can implement (like Interfaces or Hooks in other languages). So a plugin can get a chance to run code on every page load, ticket change, wiki rendering, whatever. And yes, its all Python (v2.5 in our case). Thanks for filing the tickets -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080912/385bd574/attachment-0001.bin From wsiegrist at apple.com Fri Sep 12 17:39:33 2008 From: wsiegrist at apple.com (William Siegrist) Date: Fri, 12 Sep 2008 17:39:33 -0700 Subject: Port iso-codes In-Reply-To: <48CAFEEB.1040100@macports.org> References: <326B671C-EA5E-4925-A8FB-2E2DFF310013@nzbox.com> <48C0A48F.6010801@orcaware.com> <72BCF832-6959-49EE-A178-B3F54FFDE822@geeklair.net> <48CAFEEB.1040100@macports.org> Message-ID: <99D0C2AF-A912-4A5C-99A1-327E8D132298@apple.com> On Sep 12, 2008, at 4:44 PM, Joshua Root wrote: > William Siegrist wrote: >> On Sep 12, 2008, at 12:01 PM, Daniel J. Luke wrote: >> >>> On Sep 4, 2008, at 11:28 PM, William Siegrist wrote: >>>> Someone could provide a mirror that is located in an FTP-friendly >>>> network. Or maintainers of FTP-only ports could host them on HTTP >>>> long enough for the mirror to get a copy. >>> >>> Or we could do some sort of ftp->http gateway for the macosforge >>> machines (perhaps something as simple as a remote shell on another >>> host that could download the file to a temp location that available >>> for http). >>> >>> I have a host we could use, if you're interested. >> >> The server just uses the built in mirror command, so that would >> have to >> be modified to check for some sort of FTP_PROXY env variable. > > Fetch should respect FTP_PROXY. If not, that's a bug. > Oops. I didnt mean to use a real environment variable. I just used FTP_PROXY as an example name for this custom setup. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080912/35c15e06/attachment.bin From ryandesign at macports.org Sat Sep 13 15:43:15 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 13 Sep 2008 17:43:15 -0500 Subject: Port iso-codes In-Reply-To: References: <326B671C-EA5E-4925-A8FB-2E2DFF310013@nzbox.com> <48C0A48F.6010801@orcaware.com> <72BCF832-6959-49EE-A178-B3F54FFDE822@geeklair.net> <5B883765-99AA-4B42-8BB0-BDA1BCD64F23@geeklair.net> Message-ID: <8528343F-5B8B-43A6-A2CC-4FA80201B277@macports.org> On Sep 12, 2008, at 3:57 PM, Daniel J. Luke wrote: > We can revisit if that ends up being a bigger issue for you (and/or > if you ever are able to ftp from the mirror machine(s)). William, could you explain why the mirror machine can't FTP? That seemed to me to be one of the major benefits of having a mirror -- to provide via http the distfiles that are only available on ftp servers. From ryandesign at macports.org Sat Sep 13 16:06:06 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 13 Sep 2008 18:06:06 -0500 Subject: Identifying portname in a bug? In-Reply-To: <48CAB8B2.6060904@shopwatch.org> References: <48CA7070.5060007@shopwatch.org> <48CA71DE.2070807@macports.org> <5cbbe4ae0809120648h207db72dnf60342eb427fd3c5@mail.gmail.com> <48CAB8B2.6060904@shopwatch.org> Message-ID: <8BA59D8F-B99D-47AB-830D-7CA275D91D94@macports.org> On Sep 12, 2008, at 1:45 PM, Jay Levitt wrote: > Caspar Florian Ebeling wrote: > >>> The field was already added recently. But it is not used in older >>> bugs. >>> So it would help if only anyone editing a bug would populate this >>> field >>> as well. >> >> oh, yes, sorry, so I missed that and my information was stale. > > ...so you can see why I think it ought to be a more visible > field... :) > > Suggestions for new ticket entry: > > 1. Upon entering a new ticket, I do see the "port" field, but it's > dead > last, after "keywords" and even "CC". I'd put it next to > "component", since > "port" is a subcategory of the "ports" component. Somewhat indifferent. It could perhaps be placed better, but I would hope anyone filling out a bug report would examine all fields regardless of where on the screen they are. > 2. Ideally, "port" should be two fields: port name, and port > version. Sure, > we can establish a convention, but software's much better at that than > humans. I'd like to be able to search for all bugs on the > postgresql port, > or only bugs reported on the latest version. Not in favor. Tickets can be filed against multiple ports (like a bug that applies e.g. to php4 and php5 and php5-devel, or to py- setuptools and py25-setuptools). Requiring a version in this case could be confusing. If you required entering versions for all ports, how would you search on that? I'd rather encourage users to enter the version number into the ticket description. > 3. Does trac allow an arbitrary validation script to run? If so, > we could > check that the portname was, in fact, the name of a valid port. Not in favor, for the reason above. > 4. "Version" should then change to "MacPorts" version. Indifferent. As William said, the versions listed make it clear these are MacPorts versions. > 5. For extra bonus UI points, "portname" and "port version" should be > unselectable until component=ports. Not in favor. People often file bugs as port bugs, when in fact they are base bugs that are exposed by certain ports. It's useful to list the port name, even after changing the ticket to a base bug, so that people searching for bugs about that port will find the base bug and won't file a duplicate. > 6. Make the portname field required on the form for all new > tickets, and (I > think) for updates to all existing tickets. Argument against the > latter: "I > just want to provide some helpful information! I shouldn't have to > do data > entry." Counterargument: "From a philosophically pure standpoint, > you're > right. From a pragmatic standpoint, it's just asking for > information you > already know: the name of the port. And it helps us all." Not in favor. Sometimes you don't know what port is responsible for the problem. People often file bugs against, say, ImageMagick, when in fact the bug is with one of its dependencies. Sometimes people don't provide enough information in the bug report to identify which port is responsible, in which case we don't know how to fill in the port field. Also, sometimes people file base bugs and forget to classify it as a base bug; they classify it as a port bug. Then they'd run into an error about the port field being required. They might realize they need to switch the classification to base bugs, or they might fill garbage into the port field, or they might get frustrated and abandon the bug report entirely, which we don't want. That's the problem with more required fields. They can annoy and even drive away the people you need most -- the ones who are telling you about problems in your software. I'm in favor of fewer fields, not more. For example, I don't like that we have duplication between "type" (defect, enhancement), "milestone" (base bugs, base enhancements, port bugs, port enhancements) and "component" (base, ports). > The "ports.php" search page should link to the bug reports for that > port. Sure. That's a nice idea. MPWA should link to port bug reports too. > I think that all these would help make individual ports "first class > citizens" of MacPorts, which will in turn make it easier for users > to report > bugs, and maintainers to fix them. > > What do you all think? I think by definition, ports are already first class citizens in MacPorts -- I'd consider them the only first class citizens we have, since MacPorts is all about ports (what else?). But I won't deny that the MacPorts web presence could still be improved. From wsiegrist at apple.com Sat Sep 13 22:41:25 2008 From: wsiegrist at apple.com (William Siegrist) Date: Sat, 13 Sep 2008 22:41:25 -0700 Subject: Port iso-codes In-Reply-To: <8528343F-5B8B-43A6-A2CC-4FA80201B277@macports.org> References: <326B671C-EA5E-4925-A8FB-2E2DFF310013@nzbox.com> <48C0A48F.6010801@orcaware.com> <72BCF832-6959-49EE-A178-B3F54FFDE822@geeklair.net> <5B883765-99AA-4B42-8BB0-BDA1BCD64F23@geeklair.net> <8528343F-5B8B-43A6-A2CC-4FA80201B277@macports.org> Message-ID: <38D87595-7939-4BCA-84EC-F784E7346F8D@apple.com> On Sep 13, 2008, at 3:43 PM, Ryan Schmidt wrote: > On Sep 12, 2008, at 3:57 PM, Daniel J. Luke wrote: > >> We can revisit if that ends up being a bigger issue for you (and/or >> if you ever are able to ftp from the mirror machine(s)). > > William, could you explain why the mirror machine can't FTP? > > That seemed to me to be one of the major benefits of having a mirror > -- to provide via http the distfiles that are only available on ftp > servers. > > IT security policy for that part of the Apple network. MPWA is supposed to be the solution by providing more maintainer functionality, one function being a way to upload distfiles to the mirror. But the MPWA work for GSoC didnt happen, so we're not any closer to that. Eventually, either MPWA will provide this, or I will separately, its just not high on my priority list. I ended up setting up the mirror before MPWA since it was better than nothing. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080913/9fd41784/attachment.bin From ryandesign at macports.org Mon Sep 15 00:30:22 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 15 Sep 2008 02:30:22 -0500 Subject: [39179] trunk/dports/games/rrgbis In-Reply-To: <88CAAADB-4339-4D61-8D19-225359477B58@macports.org> References: <20080811143823.5F5ED1DB0DE@beta.macosforge.org> <88CAAADB-4339-4D61-8D19-225359477B58@macports.org> Message-ID: <2838EDC1-258E-40CD-BA5E-77FC7BB4415D@macports.org> On Aug 12, 2008, at 01:24, Ryan Schmidt wrote: > On Aug 11, 2008, at 09:38, simon at macports.org wrote: > >> Revision: 39179 >> http://trac.macosforge.org/projects/macports/changeset/ >> 39179 >> Author: simon at macports.org >> Date: 2008-08-11 07:38:21 -0700 (Mon, 11 Aug 2008) >> Log Message: >> ----------- >> games/rrgbis: Updated to 1.11. >> >> Modified Paths: >> -------------- >> trunk/dports/games/rrgbis/Portfile > > [snip] > >> -use_configure no >> +configure { >> + system "cd ${worksrcpath}/src/FTGL; ${configure.env} ./ >> configure ${configure.pre_args}" >> +} > > [snip] > > Why override the configure phase? Why not just: > > configure.dir ${worksrcpath}/src/FTGL > > (warning: untested) I've tested it now. It works fine. Committed: http://trac.macports.org/changeset/39979 From krischik at users.sourceforge.net Mon Sep 15 04:03:23 2008 From: krischik at users.sourceforge.net (Martin Krischik) Date: Mon, 15 Sep 2008 13:03:23 +0200 Subject: Command output: Warning: Unknown argument: -AppleLanguages Message-ID: <5E844A84-34E6-40F1-B186-D702B7A10113@users.sourceforge.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I try to create some "mdmg" packages but I get the following - rather strange message: - ---------------------------- +./Build_GCC.command:18> port mdmg gcc43 +ada - ---> Creating pkg for gcc43-4.3.2 - ---> Creating pkg for gmp-4.2.2 Error: Target org.macports.pkg returned: shell command "PMResourceLocale=English /Developer/Applications/Utilities/ PackageMaker.app/Contents/MacOS/PackageMaker -AppleLanguages "(English)" --root /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_devel_gmp/work/destroot --out /opt/local/ var/macports/build/_Developer_work_gnuada_MacPorts_ports_lang_gcc43/ work/gcc43-4.3.2.mpkg/Contents/Packages/gmp-4.2.2.pkg --resources / opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_devel_gmp/work/pkg_resources --title "gmp-4.2.2" --info /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_devel_gmp/work/Info.plist --target 10.3 -- domain system --id org.macports.gmp" returned error 1 Command output: Warning: Unknown argument: -AppleLanguages Warning: Unknown argument: (English) ERROR: The specified root is invalid: /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_devel_gmp/work/destroot - ---> Creating pkg for libiconv-1.12 Error: Target org.macports.pkg returned: shell command "PMResourceLocale=English /Developer/Applications/Utilities/ PackageMaker.app/Contents/MacOS/PackageMaker -AppleLanguages "(English)" --root /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_textproc_libiconv/work/destroot --out /opt/ local/var/macports/build/ _Developer_work_gnuada_MacPorts_ports_lang_gcc43/work/gcc43-4.3.2.mpkg/ Contents/Packages/libiconv-1.12.pkg --resources /opt/local/var/ macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_textproc_libiconv/work/pkg_resources -- title "libiconv-1.12" --info /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_textproc_libiconv/work/Info.plist --target 10.3 --domain system --id org.macports.libiconv" returned error 1 Command output: Warning: Unknown argument: -AppleLanguages Warning: Unknown argument: (English) ERROR: The specified root is invalid: /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_textproc_libiconv/work/destroot - ---> Creating pkg for mpfr-2.3.1 Error: Target org.macports.pkg returned: shell command "PMResourceLocale=English /Developer/Applications/Utilities/ PackageMaker.app/Contents/MacOS/PackageMaker -AppleLanguages "(English)" --root /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_devel_mpfr/work/destroot --out /opt/local/ var/macports/build/_Developer_work_gnuada_MacPorts_ports_lang_gcc43/ work/gcc43-4.3.2.mpkg/Contents/Packages/mpfr-2.3.1.pkg --resources / opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_devel_mpfr/work/pkg_resources --title "mpfr-2.3.1" --info /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_devel_mpfr/work/Info.plist --target 10.3 -- domain system --id org.macports.mpfr" returned error 1 Command output: Warning: Unknown argument: -AppleLanguages Warning: Unknown argument: (English) ERROR: The specified root is invalid: /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_devel_mpfr/work/destroot - ---> Creating disk image for gcc43-4.3.2 - ---------------------------- Am I doing something wrong or it it just a warning to ignore? Martin - -- - -- Martin Krischik krischik at users.sourceforge.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFIzkD7ijwKaHyem9cRAlXGAJ46qhbnASXIB0W6t1zzXcK4AzU2sACfYvOh Br4l/Qu/Xx6P86RI7ZNPyR4= =0a7s -----END PGP SIGNATURE----- From afb at macports.org Mon Sep 15 04:22:43 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 15 Sep 2008 13:22:43 +0200 Subject: Command output: Warning: Unknown argument: -AppleLanguages In-Reply-To: <5E844A84-34E6-40F1-B186-D702B7A10113@users.sourceforge.net> References: <5E844A84-34E6-40F1-B186-D702B7A10113@users.sourceforge.net> Message-ID: Martin Krischik wrote: > I try to create some "mdmg" packages but I get the following - rather > strange message: ... > Am I doing something wrong or it it just a warning to ignore? You don't seem to be doing anything wrong, after all you were just trying to use it by giving a command... This workaround warning you can ignore: > Command output: Warning: Unknown argument: -AppleLanguages > Warning: Unknown argument: (English) Just PackageMaker.app being stupid, as usual. This fatal error, however, you cannot: > ERROR: The specified root is invalid: /opt/local/var/macports/build/ The usual cause for this is root being *gone*. See http://trac.macports.org/ticket/10881 and do verify that the directories mentioned actually exist on disk and are not empty ? If they are missing, then force the destroot on each dependency and disable the autoclean feature to avoid it happening again. --anders From ryandesign at macports.org Mon Sep 15 15:50:44 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 15 Sep 2008 17:50:44 -0500 Subject: [39976] trunk/dports/lang/slime/Portfile In-Reply-To: <20080915055814.F0225366B56@beta.macosforge.org> References: <20080915055814.F0225366B56@beta.macosforge.org> Message-ID: On Sep 15, 2008, at 00:58, easieste at macports.org wrote: > Revision: 39976 > http://trac.macports.org/changeset/39976 > Author: easieste at macports.org > Date: 2008-09-14 22:58:14 -0700 (Sun, 14 Sep 2008) > Log Message: > ----------- > Fixed problem where a "port build" and then "port install" wouldn't > work by setting build variables at the top level. > +set slime_emacs_binary [ > + if { [regexp carbon [join [registry_installed emacs]]] || > [ variant_isset app ] } { > + list "/Applications/MacPorts/Emacs.app/Contents/MacOS/Emacs" > + } else { > + list "${prefix}/bin/emacs" > + } > +] > + > +set slime_site_lisp_dir [ > + if {[ variant_isset app ]} { > + list "${destroot}/Applications/MacPorts/Emacs.app/ > Contents/Resources/site-lisp/slime" > + } else { > + list "${destroot}${prefix}/share/emacs/site-lisp/slime" > + } > +] Ah, but you can't do it this way. This relies on emacs or emacs-app being installed. But it might not yet be installed at the time the user runs "port info" or "port variants" or "port fetch" or "port checksum" or "port deps" or "portindex" which will cause an error, like it's doing for the PortIndexRegen.sh script now: http://lists.macosforge.org/pipermail/macports-changes/2008-September/ 020930.html From somaen at pvv.ntnu.no Mon Sep 15 16:38:12 2008 From: somaen at pvv.ntnu.no (=?ISO-8859-1?Q?Einar_Johan_S=F8m=E5en?=) Date: Tue, 16 Sep 2008 01:38:12 +0200 Subject: Mirror at PVV at NTNU in Norway Message-ID: <9E569A86-4619-4FF8-B8A8-FCA836A169F9@pvv.ntnu.no> We at PVV are currently working on setting up a mirror-server for various OSS-projects, since we got a nice new server recently. Does Macports needs a new mirror? Details: Internet-connection: 1000 Mbps (direct uninett-connection) Location: Trondheim, Norway. Uptime: No guarantees, as this is server is maintained as volunteer work, but we have a quite good track-record. Native IPv6 support, and should also be fine with pulling from FTP. If you are interested, let me know. Einar Johan T. S?m?en somaen at pvv.ntnu.no PVV Member. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080916/8a8876f1/attachment.html From wsiegrist at apple.com Mon Sep 15 17:03:58 2008 From: wsiegrist at apple.com (William Siegrist) Date: Mon, 15 Sep 2008 17:03:58 -0700 Subject: Mirror at PVV at NTNU in Norway In-Reply-To: <9E569A86-4619-4FF8-B8A8-FCA836A169F9@pvv.ntnu.no> References: <9E569A86-4619-4FF8-B8A8-FCA836A169F9@pvv.ntnu.no> Message-ID: <635BBC36-D6C4-4C6B-9385-6C12DEB99BB3@apple.com> On Sep 15, 2008, at 4:38 PM, Einar Johan S?m?en wrote: > We at PVV are currently working on setting up a mirror-server for > various OSS-projects, since we got a nice > new server recently. Does Macports needs a new mirror? > > Details: > Internet-connection: 1000 Mbps (direct uninett-connection) > Location: Trondheim, Norway. > Uptime: No guarantees, as this is server is maintained as volunteer > work, but we have a quite good track-record. > Native IPv6 support, and should also be fine with pulling from FTP. > > If you are interested, let me know. > Thanks for the email Einar... To recap a few things discussed on IRC: 1. jberry will need to handle the DNS. I suggest ..distfiles.macports.org and similarly for rsync.macports.org. Then we just need to add the new entry to the mirror group? 2. This server will be able to fetch distfiles from FTP servers, so this is nice in light of our recent thread about the iso-codes port. This means they cant just rsync files from distfiles.macports.org, but I pointed Einar at for some sample scripts for daily and svn-based mirroring. 3. We'll want a wiki page listing mirrors and a quick rundown of changing sources.conf to use a closer portfile/rsync mirror. Or if Josh want to port his ping timing to rsync selection, the users in Europe should get the benefits automatically and a mirror list is less vital. Perhaps if sources.conf has the default "rsync:// rsync.macports.org" do ping timing, if its anything else, respect what the user has set. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080915/e4ff68ca/attachment.bin From evenson at panix.com Tue Sep 16 00:11:23 2008 From: evenson at panix.com (Mark Evenson) Date: Tue, 16 Sep 2008 09:11:23 +0200 Subject: [39976] trunk/dports/lang/slime/Portfile In-Reply-To: References: <20080915055814.F0225366B56@beta.macosforge.org> Message-ID: Ryan Schmidt wrote: [?] > > Ah, but you can't do it this way. This relies on emacs or emacs-app being installed. But it might not yet be installed at the time the user runs "port info" or "port variants" or "port fetch" or "port checksum" or "port deps" or "portindex" which will cause an error, like it's doing for the PortIndexRegen.sh script now: > > http://lists.macosforge.org/pipermail/macports-changes/2008-September/020930.html Reverted [1] to previous buggy behavior (stuffing global variable assignment in 'configure'). [1]: http://trac.macports.org/changeset/39992 Does anybody have a suggestion how to implement the right behavior without breaking things? I need to set some Portfile specific variables conditionally (like where to install the Elisp files based on which emacs is installed, which Emacs binary to use to byte-compile files). If I set these variables in the 'configure' section, then if a user does a two step port installation (like a 'port build' followed by a 'port install') the variables are not set in the second invocation (because 'configure' is already marked as having been executed). Any suggestions? I supposed I could define a slime Portfile specific procedure, executing this explicitly before each phase that I need the variables set. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." From jmr at macports.org Tue Sep 16 05:42:03 2008 From: jmr at macports.org (Joshua Root) Date: Tue, 16 Sep 2008 22:42:03 +1000 Subject: Mirror at PVV at NTNU in Norway In-Reply-To: <635BBC36-D6C4-4C6B-9385-6C12DEB99BB3@apple.com> References: <9E569A86-4619-4FF8-B8A8-FCA836A169F9@pvv.ntnu.no> <635BBC36-D6C4-4C6B-9385-6C12DEB99BB3@apple.com> Message-ID: <48CFA99B.6010304@macports.org> William Siegrist wrote: > 3. We'll want a wiki page listing mirrors and a quick rundown of > changing sources.conf to use a closer portfile/rsync mirror. Or if Josh > want to port his ping timing to rsync selection, the users in Europe > should get the benefits automatically and a mirror list is less vital. > Perhaps if sources.conf has the default "rsync://rsync.macports.org" do > ping timing, if its anything else, respect what the user has set. I think the sync target would need some work to support choosing from a list of possible sources. Multiple sources can be listed, but currently they are *all* used. So it gets a little complicated since you'd need both lists of sources from which you want to choose one, and lists of sources where you want to pull from all of them. I'm in favour of the wiki page and a comment in sources.conf. - Josh From krischik at users.sourceforge.net Tue Sep 16 09:31:41 2008 From: krischik at users.sourceforge.net (Martin Krischik) Date: Tue, 16 Sep 2008 18:31:41 +0200 Subject: Zip and tar.gz Message-ID: <354B170B-425A-43C4-BC23-B46E096873D6@users.sourceforge.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have run into a little problem when creating a a Portfile and I wonder if there is a solution to it. The program I try to port consists of 2 archive: 1) The primary program which comes a .tar.gz file 2) Some supplemental files which comes as a .zip file. With "use_zip yes" the .tar.gz file can't be expanded and without the zip file can't be expanded. So I am kind of snookered. Any way out? Martin PS: for RPM based packages I used the following shell function which always worked without fail: function Unpack () # {{{1 { local in_File=${1}; local in_Dir=${2}; local Retval=1; if test -z ${in_Dir} || test ! -d ${in_Dir} then case "${in_File}" in (*.tgz|*.tar.gz) tar --extract --gzip --file "${in_File}"; ;; (*.tar.bz2) tar --extract --bzip2 --file "${in_File}"; ;; (*.zip) unzip -oq "${in_File}" -d "${in_Dir}" ;; esac; Retval=0; fi; return ${Retval}; } # }}}1 - -- Martin Krischik krischik at users.sourceforge.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFIz99tijwKaHyem9cRAkQhAKCv3xMlZWSU9DGnQY8mF3gLrC+gGACcDyCv Yn+G68YAyiuSX7685crtd3Q= =zsjr -----END PGP SIGNATURE----- From jmr at macports.org Tue Sep 16 09:50:41 2008 From: jmr at macports.org (Joshua Root) Date: Wed, 17 Sep 2008 02:50:41 +1000 Subject: Zip and tar.gz In-Reply-To: <354B170B-425A-43C4-BC23-B46E096873D6@users.sourceforge.net> References: <354B170B-425A-43C4-BC23-B46E096873D6@users.sourceforge.net> Message-ID: <48CFE3E1.5010501@macports.org> Martin Krischik wrote: > Hi, > > I have run into a little problem when creating a a Portfile and I > wonder if there is a solution to it. > > The program I try to port consists of 2 archive: > > 1) The primary program which comes a .tar.gz file > 2) Some supplemental files which comes as a .zip file. > > With "use_zip yes" the .tar.gz file can't be expanded and without the > zip file can't be expanded. So I am kind of snookered. Any way out? You'll need to extract one of them in a post-extract section. See fontforge, for example. - Josh From krischik at users.sourceforge.net Tue Sep 16 11:48:25 2008 From: krischik at users.sourceforge.net (Martin Krischik) Date: Tue, 16 Sep 2008 20:48:25 +0200 Subject: Zip and tar.gz In-Reply-To: <48CFE3E1.5010501@macports.org> References: <354B170B-425A-43C4-BC23-B46E096873D6@users.sourceforge.net> <48CFE3E1.5010501@macports.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 16.09.2008 um 18:50 schrieb Joshua Root: > Martin Krischik wrote: >> Hi, >> >> I have run into a little problem when creating a a Portfile and I >> wonder if there is a solution to it. >> >> The program I try to port consists of 2 archive: >> >> 1) The primary program which comes a .tar.gz file >> 2) Some supplemental files which comes as a .zip file. >> >> With "use_zip yes" the .tar.gz file can't be expanded and without the >> zip file can't be expanded. So I am kind of snookered. Any way out? > > You'll need to extract one of them in a post-extract section. See > fontforge, for example. > Thanks - that worked. Martin - -- Martin Krischik krischik at users.sourceforge.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFIz/96ijwKaHyem9cRAlCnAJ9IqGfboWNEnYqFNhA+7Ki86aoqfwCcDJTM I7MBZ8CuF90mD/LQ9NsjI5Q= =Tupn -----END PGP SIGNATURE----- From krischik at users.sourceforge.net Tue Sep 16 11:48:25 2008 From: krischik at users.sourceforge.net (Martin Krischik) Date: Tue, 16 Sep 2008 20:48:25 +0200 Subject: Zip and tar.gz In-Reply-To: <48CFE3E1.5010501@macports.org> References: <354B170B-425A-43C4-BC23-B46E096873D6@users.sourceforge.net> <48CFE3E1.5010501@macports.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 16.09.2008 um 18:50 schrieb Joshua Root: > Martin Krischik wrote: >> Hi, >> >> I have run into a little problem when creating a a Portfile and I >> wonder if there is a solution to it. >> >> The program I try to port consists of 2 archive: >> >> 1) The primary program which comes a .tar.gz file >> 2) Some supplemental files which comes as a .zip file. >> >> With "use_zip yes" the .tar.gz file can't be expanded and without the >> zip file can't be expanded. So I am kind of snookered. Any way out? > > You'll need to extract one of them in a post-extract section. See > fontforge, for example. > Thanks - that worked. Martin - -- Martin Krischik krischik at users.sourceforge.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFIz/96ijwKaHyem9cRAlCnAJ9IqGfboWNEnYqFNhA+7Ki86aoqfwCcDJTM I7MBZ8CuF90mD/LQ9NsjI5Q= =Tupn -----END PGP SIGNATURE----- From jjstickel at vcn.com Wed Sep 17 12:48:25 2008 From: jjstickel at vcn.com (Jonathan Stickel) Date: Wed, 17 Sep 2008 13:48:25 -0600 Subject: minor bug in octave-[forge] ports Message-ID: <48D15F09.9080605@vcn.com> I think there is a minor bug in the octave-[forge] ports, specifically when deactivating (or uninstalling). The octave package database file is not updated with the fact that the package has been removed. A simple repeat of the command currently called in "post-activate" would suffice, but there does not seem to be a "post-deactivate" feature implemented in Macports. Any chance this feature could be implemented? If not, any suggestions for a workaround? Jonathan From 0x62_0x6c_0x62 at pobox.com Wed Sep 17 14:22:07 2008 From: 0x62_0x6c_0x62 at pobox.com (Bryan Blackburn) Date: Wed, 17 Sep 2008 15:22:07 -0600 Subject: minor bug in octave-[forge] ports In-Reply-To: <48D15F09.9080605@vcn.com> References: <48D15F09.9080605@vcn.com> Message-ID: <20080917212207.GN551@ninagal.withay.com> On Wed, Sep 17, 2008 at 01:48:25PM -0600, Jonathan Stickel said: > I think there is a minor bug in the octave-[forge] ports, specifically > when deactivating (or uninstalling). The octave package database file > is not updated with the fact that the package has been removed. A > simple repeat of the command currently called in "post-activate" would > suffice, but there does not seem to be a "post-deactivate" feature > implemented in Macports. Any chance this feature could be implemented? > If not, any suggestions for a workaround? There's been a ticket for that for some time: Other than that, I think the only alternative is to mention, during installation, the need to run something when uninstalling. Bryan > > Jonathan From ryandesign at macports.org Wed Sep 17 22:36:08 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 18 Sep 2008 00:36:08 -0500 Subject: [40026] trunk/dports/perl/p5-datetime-timezone/Portfile In-Reply-To: <20080918052440.3BCE337D9AD@beta.macosforge.org> References: <20080918052440.3BCE337D9AD@beta.macosforge.org> Message-ID: Don't forget to increase the epoch when you increase the version in a way that is affected by issue 11873: http://trac.macports.org/ticket/11873 On Sep 18, 2008, at 00:24, ryandesign at macports.org wrote: > Revision: 40026 > http://trac.macports.org/changeset/40026 > Author: ryandesign at macports.org > Date: 2008-09-17 22:24:39 -0700 (Wed, 17 Sep 2008) > Log Message: > ----------- > p5-datetime-timezone: increase epoch so MacPorts considers "80" to > be larger than "7904", since #11873 has not yet been resolved > > Modified Paths: > -------------- > trunk/dports/perl/p5-datetime-timezone/Portfile > > Modified: trunk/dports/perl/p5-datetime-timezone/Portfile > =================================================================== > --- trunk/dports/perl/p5-datetime-timezone/Portfile 2008-09-18 > 03:29:54 UTC (rev 40025) > +++ trunk/dports/perl/p5-datetime-timezone/Portfile 2008-09-18 > 05:24:39 UTC (rev 40026) > @@ -4,7 +4,7 @@ > PortGroup perl5 1.0 > > perl5.setup DateTime-TimeZone 0.80 > -epoch 1 > +epoch 2 > maintainers narf_tm openmaintainer > description Time zone object base class and factory > long_description This class is the base class for all > time zone \ From ryandesign at macports.org Fri Sep 19 14:47:20 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 19 Sep 2008 16:47:20 -0500 Subject: [40056] trunk/base/src In-Reply-To: <20080919024247.806DE383469@beta.macosforge.org> References: <20080919024247.806DE383469@beta.macosforge.org> Message-ID: <95998655-E24E-4367-A366-6D5EC4182744@macports.org> On Sep 18, 2008, at 9:42 PM, toby at macports.org wrote: > Revision: 40056 > http://trac.macports.org/changeset/40056 > Author: toby at macports.org > Date: 2008-09-18 19:42:46 -0700 (Thu, 18 Sep 2008) > Log Message: > ----------- > Stop setting MACOSX_DEPLOYMENT_TARGET Why? (Could you please edit your log message to explain?) svn propedit --revprop -r40056 svn:log http://svn.macports.org/ repository/macports From ryandesign at macports.org Fri Sep 19 14:53:30 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 19 Sep 2008 16:53:30 -0500 Subject: [40060] trunk/base In-Reply-To: <20080919032023.55DE43837EE@beta.macosforge.org> References: <20080919032023.55DE43837EE@beta.macosforge.org> Message-ID: <46F1184D-0F5A-4464-A5E1-0795902CE6FB@macports.org> On Sep 18, 2008, at 10:20 PM, toby at macports.org wrote: > Revision: 40060 > http://trac.macports.org/changeset/40060 > Author: toby at macports.org > Date: 2008-09-18 20:20:22 -0700 (Thu, 18 Sep 2008) > Log Message: > ----------- > handle _ in arch name (x86_64) > > Modified Paths: > -------------- > trunk/base/aclocal.m4 > trunk/base/configure > > Modified: trunk/base/aclocal.m4 > =================================================================== > --- trunk/base/aclocal.m4 2008-09-19 03:14:25 UTC (rev 40059) > +++ trunk/base/aclocal.m4 2008-09-19 03:20:22 UTC (rev 40060) > @@ -821,7 +821,7 @@ > CFLAGS_LIBCURL=$($CURL_CONFIG --cflags) > # Due to a bug in dist, --arch flags are improperly supplied by > curl-config. > # Get rid of them. > - LDFLAGS_LIBCURL=$($CURL_CONFIG --libs | [sed 's/-arch [A-Za-z0-9] > * //g']) > + LDFLAGS_LIBCURL=$($CURL_CONFIG --libs | [sed 's/-arch [A-Za-z0-9_] > * //g']) > > AC_SUBST(CFLAGS_LIBCURL) > AC_SUBST(LDFLAGS_LIBCURL) > > Modified: trunk/base/configure > =================================================================== > --- trunk/base/configure 2008-09-19 03:14:25 UTC (rev 40059) > +++ trunk/base/configure 2008-09-19 03:20:22 UTC (rev 40060) > @@ -12019,7 +12019,7 @@ > CFLAGS_LIBCURL=$($CURL_CONFIG --cflags) > # Due to a bug in dist, --arch flags are improperly supplied by > curl-config. > # Get rid of them. > - LDFLAGS_LIBCURL=$($CURL_CONFIG --libs | sed 's/-arch [A-Za-z0-9] > * //g') > + LDFLAGS_LIBCURL=$($CURL_CONFIG --libs | sed 's/-arch [A-Za-z0-9_] > * //g') I realize you're just fixing existing code, but were you actually still running into this situation (--arch flags supplied by curl- config)? The curl port no longer puts --arch flags in curl-config [1] and using "/usr/bin/curl-config --libs" on Mac OS X 10.4.11 on PowerPC and Intel I don't see any --arch flags in Apple's curl either. I didn't test Leopard however. [1] http://trac.macports.org/ticket/15116 From jmr at macports.org Mon Sep 22 03:55:42 2008 From: jmr at macports.org (Joshua Root) Date: Mon, 22 Sep 2008 20:55:42 +1000 Subject: dep_map duplicate removal script In-Reply-To: <489C8522.7020407@macports.org> References: <489C8522.7020407@macports.org> Message-ID: <48D779AE.40408@macports.org> Joshua Root wrote: > To fully resolve the issues with duplicate dependency map entries > reported in , I've attached a > small script that will remove existing duplicates. It should be run by > the postflight script in future MP binary packages, and on selfupdate > too if we can figure out a way of doing that. I've now committed this script to trunk, and it will run during 'make install'. Once the MacPorts port is updated so it adds the script to the .dmg resources, it will be run in postflight too. Testing appreciated. :-) - Josh From raimue at macports.org Mon Sep 22 05:10:44 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 22 Sep 2008 14:10:44 +0200 Subject: [MacPorts] howto/MAMP modified In-Reply-To: <20080922084033.8144D2808A@relay14.apple.com> References: <20080922084033.8144D2808A@relay14.apple.com> Message-ID: <48D78B44.6030104@macports.org> MacPorts wrote: > Changed page "howto/MAMP" by ryandesign at macports.org from 76.244.68.113* > Page URL: > Diff URL: > Revision 19 > Comment: revert incorrect change to root password setting instructions > > -------8<------8<------8<------8<------8<------8<------8<------8<-------- > Index: howto/MAMP > ========================================================================= > --- howto/MAMP (version: 18) > +++ howto/MAMP (version: 19) > @@ -110,9 +110,10 @@ > Set the MySQL `root` password (it's currently empty): > > {{{ > -mysqladmin5 -u root password -p > -}}} > -This will ask for a new password for the MySQL `root` user. > +mysqladmin5 -u root -p password > +}}} > + > +where `` is your new desired root password. I see the old command failed with: mysqladmin5: Too few arguments to change password And if I remember correctly it was me who put it there to make the process more secure. Seems like I misunderstood how '-p' works. Typing in passwords directly on the shell prompt is not a good idea for security reasons. It will get saved in the shell history and is visible to all other users on the same machine in the list of running processes. And the new command is also not absolutely correct. '-p' tells mysqladmin5 to prompt for the old password (which is empty on initial installation), so it will easily confuse users as they have to leave the "Enter your password" prompt empty. Maybe it would be better to advice something like this (taken from [1]): Terminal 1: $ mysqld_safe5 --skip-grant-tables Terminal 2: $ mysql5 mysql> UPDATE mysql.user SET Password=PASSWORD('foo') WHERE User='root'; mysql> FLUSH PRIVILEGES; Although this way the password still ends up in .mysql_history, but at least it is not exposed to everyone. I think the first method described in [1] using an init-file is most secure, but is a bit complicated. The official install instructions [2] also use something like this method. Or we decide that the current instructions are safe enough for home users (which mostly only have one user on their system), but add a note about security and that it should not be used on multi-user systems, including a link to [2]. Rainer [1] http://dev.mysql.com/doc/refman/5.0/en/resetting-permissions.html#resetting-permissions-unix [2] http://dev.mysql.com/doc/refman/5.0/en/default-privileges.html From ryandesign at macports.org Mon Sep 22 12:01:53 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 22 Sep 2008 14:01:53 -0500 Subject: [MacPorts] howto/MAMP modified In-Reply-To: <48D78B44.6030104@macports.org> References: <20080922084033.8144D2808A@relay14.apple.com> <48D78B44.6030104@macports.org> Message-ID: On Sep 22, 2008, at 7:10 AM, Rainer M?ller wrote: > MacPorts wrote: >> Changed page "howto/MAMP" by ryandesign at macports.org from >> 76.244.68.113* >> Page URL: >> Diff URL: > action=diff&version=19> >> Revision 19 >> Comment: revert incorrect change to root password setting >> instructions >> >> -------8<------8<------8<------8<------8<------8<------8<------8<---- >> ---- >> Index: howto/MAMP >> ===================================================================== >> ==== >> --- howto/MAMP (version: 18) >> +++ howto/MAMP (version: 19) >> @@ -110,9 +110,10 @@ >> Set the MySQL `root` password (it's currently empty): >> >> {{{ >> -mysqladmin5 -u root password -p >> -}}} >> -This will ask for a new password for the MySQL `root` user. >> +mysqladmin5 -u root -p password >> +}}} >> + >> +where `` is your new desired root password. > > I see the old command failed with: > mysqladmin5: Too few arguments to change password > And if I remember correctly it was me who put it there to make the > process more secure. I remember you making the change, but at the time I didn't think about it further or try the revised instructions. It's been so long since I set up my own MySQL servers that I forgot the specifics. > Seems like I misunderstood how '-p' works. The "-p" refers to the current password. For any MySQL command that needs a username and password, you can either use "-p" (no space between "-p" and the current password) to supply your current password on the command line, or just use "-p" with no password, and you'll be prompted to enter your current password. But the mysqladmin program still requires you to provide the new password on the command line. > Typing in passwords directly on the shell prompt is not a good idea > for > security reasons. It will get saved in the shell history and is > visible > to all other users on the same machine in the list of running > processes. I tend to agree, however I consulted "man mysqladmin" and I did not see any alternative to supplying the new password on the command line. It was not listed as an optional parameter. > And the new command is also not absolutely correct. '-p' tells > mysqladmin5 to prompt for the old password (which is empty on initial > installation), so it will easily confuse users as they have to > leave the > "Enter your password" prompt empty. In what way is the command not correct now? I tested it and it works. If I type: mysqladmin5 -u root -p password foo then mysqladmin will prompt me for the current root password, and then set the root password to "foo". I added a clarifying sentence: http://trac.macports.org/wiki/howto/MAMP?action=diff&version=20 > Maybe it would be better to advice something like this (taken from > [1]): > > Terminal 1: > $ mysqld_safe5 --skip-grant-tables > > Terminal 2: > $ mysql5 > mysql> UPDATE mysql.user SET Password=PASSWORD('foo') WHERE > User='root'; > mysql> FLUSH PRIVILEGES; > > Although this way the password still ends up in .mysql_history, but at > least it is not exposed to everyone. > > I think the first method described in [1] using an init-file is most > secure, but is a bit complicated. The official install instructions > [2] > also use something like this method. > > Or we decide that the current instructions are safe enough for home > users (which mostly only have one user on their system), but add a > note > about security and that it should not be used on multi-user systems, > including a link to [2]. > > Rainer > > [1] > http://dev.mysql.com/doc/refman/5.0/en/resetting- > permissions.html#resetting-permissions-unix > [2] http://dev.mysql.com/doc/refman/5.0/en/default-privileges.html It would probably be fine to leave the current instructions, but add a note about why it is insecure, and add a reference to the MySQL documentation for those who need more security. IMHO the MySQL distribution provides the mysqladmin program to do this, so it's reasonable to tell the user to use that. From ryandesign at macports.org Fri Sep 26 13:58:03 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 26 Sep 2008 15:58:03 -0500 Subject: [40228] trunk/dports/lang/scala/Portfile In-Reply-To: <20080926172306.24D883F872E@beta.macosforge.org> References: <20080926172306.24D883F872E@beta.macosforge.org> Message-ID: <74224801-A5C2-4A6D-B0F9-5D2E5CEDCEA9@macports.org> On Sep 26, 2008, at 12:23, blair at macports.org wrote: > Revision: 40228 > http://trac.macports.org/changeset/40228 > Author: blair at macports.org > Date: 2008-09-26 10:23:04 -0700 (Fri, 26 Sep 2008) > Log Message: > ----------- > New upstream 2.7.2.RC2 release of Scala. > > Modified Paths: > -------------- > trunk/dports/lang/scala/Portfile > > Modified: trunk/dports/lang/scala/Portfile > =================================================================== > --- trunk/dports/lang/scala/Portfile 2008-09-26 14:40:59 UTC (rev > 40227) > +++ trunk/dports/lang/scala/Portfile 2008-09-26 17:23:04 UTC (rev > 40228) > @@ -3,8 +3,7 @@ > PortSystem 1.0 > > name scala > -version 2.7.1 > -revision 1 > +version 2.7.1.99.2.7.2.2 If one makes use of the epoch variable, then this kind of version munging isn't necessary, is it? Today you would have set the version to "2.7.2.RC2". And at a later time when 2.7.2 final is released, you would set the version to "2.7.2" and increase the epoch. Right? From blair at orcaware.com Fri Sep 26 15:29:25 2008 From: blair at orcaware.com (Blair Zajac) Date: Fri, 26 Sep 2008 15:29:25 -0700 Subject: [40228] trunk/dports/lang/scala/Portfile In-Reply-To: <74224801-A5C2-4A6D-B0F9-5D2E5CEDCEA9@macports.org> References: <20080926172306.24D883F872E@beta.macosforge.org> <74224801-A5C2-4A6D-B0F9-5D2E5CEDCEA9@macports.org> Message-ID: <48DD6245.9010406@orcaware.com> Ryan Schmidt wrote: > On Sep 26, 2008, at 12:23, blair at macports.org wrote: > >> Revision: 40228 >> http://trac.macports.org/changeset/40228 >> Author: blair at macports.org >> Date: 2008-09-26 10:23:04 -0700 (Fri, 26 Sep 2008) >> Log Message: >> ----------- >> New upstream 2.7.2.RC2 release of Scala. >> >> Modified Paths: >> -------------- >> trunk/dports/lang/scala/Portfile >> >> Modified: trunk/dports/lang/scala/Portfile >> =================================================================== >> --- trunk/dports/lang/scala/Portfile 2008-09-26 14:40:59 UTC (rev >> 40227) >> +++ trunk/dports/lang/scala/Portfile 2008-09-26 17:23:04 UTC (rev >> 40228) >> @@ -3,8 +3,7 @@ >> PortSystem 1.0 >> >> name scala >> -version 2.7.1 >> -revision 1 >> +version 2.7.1.99.2.7.2.2 > > If one makes use of the epoch variable, then this kind of version > munging isn't necessary, is it? > > Today you would have set the version to "2.7.2.RC2". And at a later time > when 2.7.2 final is released, you would set the version to "2.7.2" and > increase the epoch. Right? Right, but I don't plan on increasing the epoch every time though. Blair From ryandesign at macports.org Fri Sep 26 16:50:05 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 26 Sep 2008 18:50:05 -0500 Subject: [40228] trunk/dports/lang/scala/Portfile In-Reply-To: <48DD6245.9010406@orcaware.com> References: <20080926172306.24D883F872E@beta.macosforge.org> <74224801-A5C2-4A6D-B0F9-5D2E5CEDCEA9@macports.org> <48DD6245.9010406@orcaware.com> Message-ID: On Sep 26, 2008, at 17:29, Blair Zajac wrote: > Ryan Schmidt wrote: > >> On Sep 26, 2008, at 12:23, blair at macports.org wrote: >> >>> Revision: 40228 >>> http://trac.macports.org/changeset/40228 >>> Author: blair at macports.org >>> Date: 2008-09-26 10:23:04 -0700 (Fri, 26 Sep 2008) >>> Log Message: >>> ----------- >>> New upstream 2.7.2.RC2 release of Scala. >>> >>> Modified Paths: >>> -------------- >>> trunk/dports/lang/scala/Portfile >>> >>> Modified: trunk/dports/lang/scala/Portfile >>> =================================================================== >>> --- trunk/dports/lang/scala/Portfile 2008-09-26 14:40:59 UTC (rev >>> 40227) >>> +++ trunk/dports/lang/scala/Portfile 2008-09-26 17:23:04 UTC (rev >>> 40228) >>> @@ -3,8 +3,7 @@ >>> PortSystem 1.0 >>> >>> name scala >>> -version 2.7.1 >>> -revision 1 >>> +version 2.7.1.99.2.7.2.2 >> >> If one makes use of the epoch variable, then this kind of version >> munging isn't necessary, is it? >> >> Today you would have set the version to "2.7.2.RC2". And at a >> later time >> when 2.7.2 final is released, you would set the version to "2.7.2" >> and >> increase the epoch. Right? > > Right, but I don't plan on increasing the epoch every time though. You don't need to increase the epoch every time you update the version; only every time you update the version in a way that MacPorts wouldn't otherwise detect -- like when updating from a release candidate to a final version. That's not so bad, is it? And it has the advantage of giving the user the correct version number in "port info" and "port installed" and wherever else. From db.evans at gmail.com Fri Sep 26 16:50:24 2008 From: db.evans at gmail.com (David Evans) Date: Fri, 26 Sep 2008 16:50:24 -0700 Subject: [MacPorts] #16661: neither pango nor pango-devel are compatible with cairo@1.8.0_0 In-Reply-To: <063.a752848da3da32a706e0ebd30fb91845@macports.org> References: <054.07b3c059965b8c59c899da85ca5c31af@macports.org> <063.a752848da3da32a706e0ebd30fb91845@macports.org> Message-ID: <48DD7540.8030808@gmail.com> MacPorts wrote: > #16661: neither pango nor pango-devel are compatible with cairo at 1.8.0_0 > ---------------------------------+------------------------------------------ > Reporter: db.evans at gmail.com | Owner: ryandesign at macports.org > Type: defect | Status: closed > Priority: High | Milestone: Port Bugs > Component: ports | Version: 1.6.0 > Resolution: fixed | Keywords: pango cairo > Port: pango, pango-devel | > ---------------------------------+------------------------------------------ > Changes (by ryandesign at macports.org): > > * status: assigned => closed > * resolution: => fixed > > > Comment: > > Updated pango to 1.22.0 in r40239. Thanks for the report, and sorry for > the inconvenience. > No problem at all. Thanks for the quick updates. From jmr at macports.org Sun Sep 28 14:04:18 2008 From: jmr at macports.org (Joshua Root) Date: Mon, 29 Sep 2008 07:04:18 +1000 Subject: curl timeouts Message-ID: <48DFF152.4030509@macports.org> Would there be any problem with reducing _CURL_MINIMUM_XFER_TIMEOUT and _CURL_CONNECTION_TIMEOUT in pextlib1.0/curl.c? Some FTP servers seem to sometimes do something that leaves curl waiting for the full 15 minutes while receiving no data. Or better yet, does anyone know how we could work around such servers? - Josh From 0x62_0x6c_0x62 at pobox.com Sun Sep 28 20:34:51 2008 From: 0x62_0x6c_0x62 at pobox.com (Bryan Blackburn) Date: Sun, 28 Sep 2008 21:34:51 -0600 Subject: curl timeouts In-Reply-To: <48DFF152.4030509@macports.org> References: <48DFF152.4030509@macports.org> Message-ID: <20080929033451.GM533@ninagal.withay.com> On Mon, Sep 29, 2008 at 07:04:18AM +1000, Joshua Root said: > Would there be any problem with reducing _CURL_MINIMUM_XFER_TIMEOUT and > _CURL_CONNECTION_TIMEOUT in pextlib1.0/curl.c? Some FTP servers seem to > sometimes do something that leaves curl waiting for the full 15 minutes > while receiving no data. > If I'm reading the curl API docs right [1], the combination of xfer_timeout and xfer_speed (which are CURLOPT_LOW_SPEED_TIME and CURLOPT_LOW_SPEED_LIMIT, respectively, in libcurl) are what would need tweaking. Seems like 1KB/s for 10 minutes would be way too long to wait, maybe drop the xfer_timeout to 1-2 minutes at most would be better. The connection_timeout should be definitely shorter too (for me, I'd like to see it 10-15 seconds, but others might want to be more patient). Note that there's a typo in the pextlib1.0/curl.c comment about xfer_speed, it is actually (according to the libcurl docs) bytes per second, not bits... The better solution would be either expose these values to macports.conf or have a high speed/low switch setting that selects sane values for them. Bryan [1] - > Or better yet, does anyone know how we could work around such servers? > > - Josh From hircus at macports.org Mon Sep 29 17:49:11 2008 From: hircus at macports.org (Michel Salim) Date: Mon, 29 Sep 2008 20:49:11 -0400 Subject: [40228] trunk/dports/lang/scala/Portfile In-Reply-To: References: <20080926172306.24D883F872E@beta.macosforge.org> <74224801-A5C2-4A6D-B0F9-5D2E5CEDCEA9@macports.org> <48DD6245.9010406@orcaware.com> Message-ID: On Fri, Sep 26, 2008 at 7:50 PM, Ryan Schmidt wrote: >> Right, but I don't plan on increasing the epoch every time though. > > You don't need to increase the epoch every time you update the > version; only every time you update the version in a way that > MacPorts wouldn't otherwise detect -- like when updating from a > release candidate to a final version. That's not so bad, is it? And > it has the advantage of giving the user the correct version number in > "port info" and "port installed" and wherever else. > Any reason we don't tag the pre-release data into the release number instead? That way it can be scala-2.7.2-0.rc2.1 -- assuming the release number is allowed to be non-integral, of course. Regards, -- michel salim ? http://hircus.jaiku.com/ IUCS ? msalim at cs.indiana.edu Fedora ? salimma at fedoraproject.org MacPorts ? hircus at macports.org From ryandesign at macports.org Mon Sep 29 22:45:17 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 30 Sep 2008 00:45:17 -0500 Subject: [40228] trunk/dports/lang/scala/Portfile In-Reply-To: References: <20080926172306.24D883F872E@beta.macosforge.org> <74224801-A5C2-4A6D-B0F9-5D2E5CEDCEA9@macports.org> <48DD6245.9010406@orcaware.com> Message-ID: <372F43AE-C543-4223-BF98-7F4F48E344D6@macports.org> On Sep 29, 2008, at 7:49 PM, Michel Salim wrote: >>> Right, but I don't plan on increasing the epoch every time though. >> >> You don't need to increase the epoch every time you update the >> version; only every time you update the version in a way that >> MacPorts wouldn't otherwise detect -- like when updating from a >> release candidate to a final version. That's not so bad, is it? And >> it has the advantage of giving the user the correct version number in >> "port info" and "port installed" and wherever else. > > Any reason we don't tag the pre-release data into the release number > instead? That way it can be scala-2.7.2-0.rc2.1 -- assuming the > release number is allowed to be non-integral, of course. My reason against that would be the desire to have the same version number in the port as the developers themselves use to describe their software. In this case, the developers of scala call it "2.7.2.RC2", not "2.7.2-0.rc2.1" or "2.7.1.99.2.7.2.2". When you say "release number", if you mean the port's revision field, then sorry, the revision must be an integer. From ryandesign at macports.org Mon Sep 29 23:16:58 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 30 Sep 2008 01:16:58 -0500 Subject: [40328] trunk/dports/textproc/sphinx/Portfile In-Reply-To: <20080929161958.B703B42DD29@beta.macosforge.org> References: <20080929161958.B703B42DD29@beta.macosforge.org> Message-ID: On Sep 29, 2008, at 11:19 AM, brett at macports.org wrote: > Revision: 40328 > http://trac.macports.org/changeset/40328 > Author: brett at macports.org > Date: 2008-09-29 09:19:58 -0700 (Mon, 29 Sep 2008) > Log Message: > ----------- > add postgresql83 option for sphinx > > Modified Paths: > -------------- > trunk/dports/textproc/sphinx/Portfile > > Modified: trunk/dports/textproc/sphinx/Portfile > =================================================================== > --- trunk/dports/textproc/sphinx/Portfile 2008-09-29 16:19:35 UTC > (rev 40327) > +++ trunk/dports/textproc/sphinx/Portfile 2008-09-29 16:19:58 UTC > (rev 40328) > @@ -20,6 +20,7 @@ > distfiles sphinx-${version}.tar.gz > checksums sha1 0f82e56a9181b3aeaeef65e9ba82fbf6fbe632d6 > > +depends_lib-append port:mysql5 > configure.args --mandir=${prefix}/share/man \ > --datadir=${prefix}/share/doc \ > --with-mysql-includes=${prefix}/include/mysql5/mysql \ > @@ -27,9 +28,17 @@ > > test.run yes > > -variant postgres description {Enable PostgeSQL support} { > +variant postgres description {Enable PostgreSQL support for old > PgSQL 8.2} { > depends_lib-append port:postgresql82 > configure.args-append --with-pgsql > configure.args-append --with-pgsql-includes=${prefix}/ > include/postgresql82 > configure.args-append --with-pgsql-libs=${prefix}/lib/ > postgresql82 > } > + > +variant postgresql83 description {Enable PostgreSQL support for > newer PgSQL v8.3} { > + depends_lib-append port:postgresql83 > + configure.args-append --with-pgsql > + configure.args-append --with-pgsql-includes=${prefix}/ > include/postgresql83 > + configure.args-append --with-pgsql-libs=${prefix}/lib/ > postgresql83 > + configure.args-delete --with-mysql-includes > +} Is this correct? You added a global mysql5 dependency which seems to match with the global --with-mysql-includes configure argument. But in the postgresql83 variant you delete the configure argument but don't delete the dependency? And in the postgres variant you don't delete either of them. From jberry at macports.org Tue Sep 30 09:18:00 2008 From: jberry at macports.org (James Berry) Date: Tue, 30 Sep 2008 09:18:00 -0700 Subject: Important: MacPorts PortMgr Changes Message-ID: As many of you know, MacPorts is loosely governed by the "PortMgr" team, which is currently made up of three people: Markus Weissmann, Juan Manual Palacios, and James Berry. We each love MacPorts, and hope to see it continue to prosper and grow in the future. And we want to continue to contribute to the success of MacPorts as our time and professional lives allow in the future. But we each also have other significant professional and personal commitments that have made it difficult for us to put what we feel is an appropriate amount of time, energy, and enthusiasm into MacPorts in recent months and years, to the extent that we feel that additional day-to-day leadership is needed to ensure continued success and growth for the MacPorts project. So we want to propose some ideas to get new leadership blood into MacPorts, while retaining the systemic knowledge and continuity that our continued presence can allow. We therefore want to put the following plan forward for community comment (and hopefully, thereafter, implementation): (1) That the MacPorts community elect a new slate of PortMgr individuals, probably three people, to continue to guide day-to-day MacPorts operations and direction. (2) That the three of us move into an Elder-council ("advisory board", "trustees", "steering committee", etc), which will continue to help out and give guidance as needed, and watch over the long-term health of MacPorts assets such as domains and finances. The idea for the Elder council is based on our experience in the last several years. We've hesitated to make changes to PortMgr because we didn't want to disrupt continuity, but that has meant that PortMgr has stagnated as year-by-year changes in our lives affected our respective abilities to effectively govern day to day. We (collectively) need the ability to make swifter more responsive changes at the PortMgr level, while also ensuring the longer term continuity of the community and the infrastructure it relies on. We propose that PortMgr members be appointed by the community and have full control of all day-to-day operations of MacPorts. The Elder council will give advice and help to PortMgr members as requested, or as they see fit, but will not have the ability to replace or remove PortMgr members: that responsibility lies with the community. The Elder council might from time to time add or remove its own members: it's primary function is to oversee the long-term health and direction of the project, including long-term assets such as finances and domains. We also see the Elder council as a broader group from which PortMgr can draw for help if its members become temporarily preoccupied with life. We have asked Jordan Hubbard, the father of MacPorts, to join us on the Elder Council, and he has given his tentative acceptance. We'd like to ask for community comment on this plan, following which we hope to call for new PortMgr nominations and election in the coming weeks. We believe that successful nominees for the portmgr positions will have demonstrated an active participation in the MacPorts community, will have the technical and organizational skills to help lead and direct the project, and will have the time, energy, and experience to make and inspire great contributions to the project. The PortMgr team: Markus, Juan, and James From ernest.prabhakar at gmail.com Tue Sep 30 10:04:35 2008 From: ernest.prabhakar at gmail.com (Ernest Prabhakar) Date: Tue, 30 Sep 2008 10:04:35 -0700 Subject: Important: MacPorts PortMgr Changes In-Reply-To: References: Message-ID: <77DCB885-D950-4FD0-87BF-EE69B064768A@gmail.com> Sounds like a good plan. +1 On Sep 30, 2008, at 9:18 AM, James Berry wrote: > As many of you know, MacPorts is loosely governed by the "PortMgr" > team, which is currently made up of three people: Markus Weissmann, > Juan Manual Palacios, and James Berry. > > We each love MacPorts, and hope to see it continue to prosper and grow > in the future. And we want to continue to contribute to the success of > MacPorts as our time and professional lives allow in the future. > > But we each also have other significant professional and personal > commitments that have made it difficult for us to put what we feel is > an appropriate amount of time, energy, and enthusiasm into MacPorts in > recent months and years, to the extent that we feel that additional > day-to-day leadership is needed to ensure continued success and growth > for the MacPorts project. > > So we want to propose some ideas to get new leadership blood into > MacPorts, while retaining the systemic knowledge and continuity that > our continued presence can allow. We therefore want to put the > following plan forward for community comment (and hopefully, > thereafter, implementation): > > (1) That the MacPorts community elect a new slate of PortMgr > individuals, probably three people, to continue to guide day-to-day > MacPorts operations and direction. > > (2) That the three of us move into an Elder-council ("advisory board", > "trustees", "steering committee", etc), which will continue to help > out and give guidance as needed, and watch over the long-term health > of MacPorts assets such as domains and finances. > > The idea for the Elder council is based on our experience in the last > several years. We've hesitated to make changes to PortMgr because we > didn't want to disrupt continuity, but that has meant that PortMgr has > stagnated as year-by-year changes in our lives affected our respective > abilities to effectively govern day to day. We (collectively) need the > ability to make swifter more responsive changes at the PortMgr level, > while also ensuring the longer term continuity of the community and > the infrastructure it relies on. > > We propose that PortMgr members be appointed by the community and have > full control of all day-to-day operations of MacPorts. The Elder > council will give advice and help to PortMgr members as requested, or > as they see fit, but will not have the ability to replace or remove > PortMgr members: that responsibility lies with the community. The > Elder council might from time to time add or remove its own members: > it's primary function is to oversee the long-term health and direction > of the project, including long-term assets such as finances and > domains. We also see the Elder council as a broader group from which > PortMgr can draw for help if its members become temporarily > preoccupied with life. > > We have asked Jordan Hubbard, the father of MacPorts, to join us on > the Elder Council, and he has given his tentative acceptance. > > We'd like to ask for community comment on this plan, following which > we hope to call for new PortMgr nominations and election in the coming > weeks. > > We believe that successful nominees for the portmgr positions will > have demonstrated an active participation in the MacPorts community, > will have the technical and organizational skills to help lead and > direct the project, and will have the time, energy, and experience to > make and inspire great contributions to the project. > > The PortMgr team: Markus, Juan, and James > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From pmagrath at macports.org Tue Sep 30 10:46:16 2008 From: pmagrath at macports.org (Paul Magrath) Date: Tue, 30 Sep 2008 18:46:16 +0100 Subject: Important: MacPorts PortMgr Changes In-Reply-To: References: Message-ID: <0FF4A7F6-56C8-42E5-9EAA-A544A7C1DF6D@macports.org> Not sure about the name but I love the idea. It'd be great to have a shorter release cycle between 1.x MacPorts releases. Paul. On 30 Sep 2008, at 17:18, James Berry wrote: > As many of you know, MacPorts is loosely governed by the "PortMgr" > team, which is currently made up of three people: Markus Weissmann, > Juan Manual Palacios, and James Berry. > > We each love MacPorts, and hope to see it continue to prosper and grow > in the future. And we want to continue to contribute to the success of > MacPorts as our time and professional lives allow in the future. > > But we each also have other significant professional and personal > commitments that have made it difficult for us to put what we feel is > an appropriate amount of time, energy, and enthusiasm into MacPorts in > recent months and years, to the extent that we feel that additional > day-to-day leadership is needed to ensure continued success and growth > for the MacPorts project. > > So we want to propose some ideas to get new leadership blood into > MacPorts, while retaining the systemic knowledge and continuity that > our continued presence can allow. We therefore want to put the > following plan forward for community comment (and hopefully, > thereafter, implementation): > > (1) That the MacPorts community elect a new slate of PortMgr > individuals, probably three people, to continue to guide day-to-day > MacPorts operations and direction. > > (2) That the three of us move into an Elder-council ("advisory board", > "trustees", "steering committee", etc), which will continue to help > out and give guidance as needed, and watch over the long-term health > of MacPorts assets such as domains and finances. > > The idea for the Elder council is based on our experience in the last > several years. We've hesitated to make changes to PortMgr because we > didn't want to disrupt continuity, but that has meant that PortMgr has > stagnated as year-by-year changes in our lives affected our respective > abilities to effectively govern day to day. We (collectively) need the > ability to make swifter more responsive changes at the PortMgr level, > while also ensuring the longer term continuity of the community and > the infrastructure it relies on. > > We propose that PortMgr members be appointed by the community and have > full control of all day-to-day operations of MacPorts. The Elder > council will give advice and help to PortMgr members as requested, or > as they see fit, but will not have the ability to replace or remove > PortMgr members: that responsibility lies with the community. The > Elder council might from time to time add or remove its own members: > it's primary function is to oversee the long-term health and direction > of the project, including long-term assets such as finances and > domains. We also see the Elder council as a broader group from which > PortMgr can draw for help if its members become temporarily > preoccupied with life. > > We have asked Jordan Hubbard, the father of MacPorts, to join us on > the Elder Council, and he has given his tentative acceptance. > > We'd like to ask for community comment on this plan, following which > we hope to call for new PortMgr nominations and election in the coming > weeks. > > We believe that successful nominees for the portmgr positions will > have demonstrated an active participation in the MacPorts community, > will have the technical and organizational skills to help lead and > direct the project, and will have the time, energy, and experience to > make and inspire great contributions to the project. > > The PortMgr team: Markus, Juan, and James > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From ryan_ware at me.com Tue Sep 30 11:48:46 2008 From: ryan_ware at me.com (Ware, Ryan R) Date: Tue, 30 Sep 2008 11:48:46 -0700 Subject: Important: MacPorts PortMgr Changes In-Reply-To: References: Message-ID: <44210D5F-8BC8-476B-8D1F-19577F6120E6@me.com> I can't say that I've been a part of this community for very long. However, I think some of my experience speaks to this. First off, Thanks to Markus, Juan and James for the job they've done in getting Macports to where it is now. I was mentally comparing my experience with Macports to the efforts I had to go through when I first started using LinuxPPC. While Macports had the whole MacOS X infrastructure to build off of, it was still much easier to install and use even given that. If the three of you that make up the PortMgr feel that the project is languishing because you can't spend enough time on it, I can't think of anyone more qualified to make that judgement. This seems like a reasonable approach that will allow the community to still have access to your expertise, yet still allow you to focus on the demands in your personal lives. It also allows people to step in to the day-to-day roles that you've been filling. The only addition that I see which could be made to the plan would be to also define how the role of the PortMgr and Elder-councilor gets replaced in the future in the case where people need to move on. Ryan On Sep 30, 2008, at 9:18 AM, James Berry wrote: > As many of you know, MacPorts is loosely governed by the "PortMgr" > team, which is currently made up of three people: Markus Weissmann, > Juan Manual Palacios, and James Berry. > > We each love MacPorts, and hope to see it continue to prosper and grow > in the future. And we want to continue to contribute to the success of > MacPorts as our time and professional lives allow in the future. > > But we each also have other significant professional and personal > commitments that have made it difficult for us to put what we feel is > an appropriate amount of time, energy, and enthusiasm into MacPorts in > recent months and years, to the extent that we feel that additional > day-to-day leadership is needed to ensure continued success and growth > for the MacPorts project. > > So we want to propose some ideas to get new leadership blood into > MacPorts, while retaining the systemic knowledge and continuity that > our continued presence can allow. We therefore want to put the > following plan forward for community comment (and hopefully, > thereafter, implementation): > > (1) That the MacPorts community elect a new slate of PortMgr > individuals, probably three people, to continue to guide day-to-day > MacPorts operations and direction. > > (2) That the three of us move into an Elder-council ("advisory board", > "trustees", "steering committee", etc), which will continue to help > out and give guidance as needed, and watch over the long-term health > of MacPorts assets such as domains and finances. > > The idea for the Elder council is based on our experience in the last > several years. We've hesitated to make changes to PortMgr because we > didn't want to disrupt continuity, but that has meant that PortMgr has > stagnated as year-by-year changes in our lives affected our respective > abilities to effectively govern day to day. We (collectively) need the > ability to make swifter more responsive changes at the PortMgr level, > while also ensuring the longer term continuity of the community and > the infrastructure it relies on. > > We propose that PortMgr members be appointed by the community and have > full control of all day-to-day operations of MacPorts. The Elder > council will give advice and help to PortMgr members as requested, or > as they see fit, but will not have the ability to replace or remove > PortMgr members: that responsibility lies with the community. The > Elder council might from time to time add or remove its own members: > it's primary function is to oversee the long-term health and direction > of the project, including long-term assets such as finances and > domains. We also see the Elder council as a broader group from which > PortMgr can draw for help if its members become temporarily > preoccupied with life. > > We have asked Jordan Hubbard, the father of MacPorts, to join us on > the Elder Council, and he has given his tentative acceptance. > > We'd like to ask for community comment on this plan, following which > we hope to call for new PortMgr nominations and election in the coming > weeks. > > We believe that successful nominees for the portmgr positions will > have demonstrated an active participation in the MacPorts community, > will have the technical and organizational skills to help lead and > direct the project, and will have the time, energy, and experience to > make and inspire great contributions to the project. > > The PortMgr team: Markus, Juan, and James > _______________________________________________ > macports-users mailing list > macports-users at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-users From adambyrtek at gmail.com Tue Sep 30 12:03:05 2008 From: adambyrtek at gmail.com (Adam Byrtek) Date: Tue, 30 Sep 2008 21:03:05 +0200 Subject: [PATCH] Inheritance of macports.conf configuration files In-Reply-To: <670d23ff0808220121g1ebe7680of841f988dfc5fc28@mail.gmail.com> References: <670d23ff0808220121g1ebe7680of841f988dfc5fc28@mail.gmail.com> Message-ID: <670d23ff0809301203g4e1cef41p67aac56c89395fbe@mail.gmail.com> There had been no response to my previous post (quoted below), so I decided to try again. Could one of the MacPorts maintainers take a look at the patch, please? This is actually quite a trivial change that will make the user configuration much more convenient. Best regards Adam Byrtek On Fri, Aug 22, 2008 at 10:21 AM, Adam Byrtek wrote: > I've made a tweak in handling of macports.conf configuration file, now > the global file defines defaults and user configuration can just > override parts of it. More information can be found in this thread on > macports-users: > http://lists.macosforge.org/pipermail/macports-users/2008-August/011273.html > > The actual patch is available here: > http://trac.macports.org/ticket/16329 > > A similar problem had been raised on this list a year ago, bus as far > as I know didn't result in a patch: > http://lists.macosforge.org/pipermail/macports-dev/2007-April/001373.html > > I'm looking forward for reviewing and applying the patch if you find it valid. > > Best regards, > Adam Byrtek > From jkh at apple.com Tue Sep 30 12:32:02 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Tue, 30 Sep 2008 12:32:02 -0700 Subject: Important: MacPorts PortMgr Changes In-Reply-To: References: Message-ID: On Sep 30, 2008, at 9:18 AM, James Berry wrote: > We have asked Jordan Hubbard, the father of MacPorts, to join us on > the Elder Council, and he has given his tentative acceptance. First, let me thank James, Markus and Juan for having both the insight and the courage to recognize their own life-induced limitations and put the project ahead of any personal attachments they may feel. That is a less common virtue than one might think, so I raise my hat to them for taking this step and for the degree of thought and care they so clearly put into this message! Second, I do fervently hope that their "call for volunteers" is not met with the sound of crickets chirping because this project really does need leadership to get to the next phase of its development - milestones like binary packages [available from macports.org], regular builds and associated regression testing, and further improvements to some of the more advanced technologies (at least by comparison to the make-based ports collections we're all familiar with) which underlie MacPorts. There is still a lot of untapped potential in the current design, and the next generation of leadership for MacPorts will have a lot to do with how much energy and focus is applied to these sorts of challenges, so if you're one of the regular faces we see around here (or even someone who's not so regular, but would like to be and sincerely feels they have the time and energy required), please, step up! Finally, I'd like to correct one small misperception, as flattering as it is, which is that I'm the "Father" of MacPorts. Landon Fuller really deserves that distinction, if any single individual does, and I think it's more accurate to refer to me as the "Godfather" of MacPorts since I got the project initially created and funded, and you can see my fingerprints here and there in the design (usually as a result of cornering Landon in his office and waving my arms until he gave in on some point), but Landon is the guy who put all the pieces together and actually coded version 1.0. From that point forward, we also owe a debt of gratitude to a number of non-Apple people (and they know who they are) for taking things much, much further and making sure that the baby we left on the community's doorstep did not subsequently die from exposure and neglect [OK, that's a HORRIBLE analogy, but I'm known for those, so I'll just leave it at that]. Thank you portmgr, and thank you macports volunteers! We at Apple will, in turn, continue to contribute where we can by keeping the infrastructure up and running, but it's really up to the community (that's you) at this point, so I really hope people will step into these rather large shoes and make the most of the opportunity to further organize and promote the wealth of open source offerings for Mac OS X! - Jordan From ernest.prabhakar at gmail.com Tue Sep 30 12:35:47 2008 From: ernest.prabhakar at gmail.com (Ernest Prabhakar) Date: Tue, 30 Sep 2008 12:35:47 -0700 Subject: Important: MacPorts PortMgr Changes In-Reply-To: References: Message-ID: <4E4D385D-7888-4DBC-88D6-87E44BAD7FB0@gmail.com> Hi Jordan, On Sep 30, 2008, at 12:32 PM, Jordan K. Hubbard wrote: > I think it's more accurate to refer to me as the "Godfather" of > MacPorts > since I got the project initially created and funded, and you can see > my fingerprints here and there in the design > so I really hope people will step into these rather large shoes and > make the most of the > opportunity to further organize and promote the wealth of open source > offerings for Mac OS X! If you're the Godfather of Macports, then I guess that's an offer we can't refuse. :-) -- Ernie P. (not running for PortMgr :-) From brett at macports.org Tue Sep 30 15:43:19 2008 From: brett at macports.org (Brett Eisenberg) Date: Tue, 30 Sep 2008 15:43:19 -0700 Subject: [40328] trunk/dports/textproc/sphinx/Portfile In-Reply-To: References: <20080929161958.B703B42DD29@beta.macosforge.org> Message-ID: <3F18B6EA-EEEA-4696-8450-1CE73E4D3EF1@macports.org> I agree it's an awkward scenario; those changes were actually a user submitted patch, but I reviewed and considered the issues you're pointing out. While it's impossible to anticipate all usecases, it seems that Sphinx's userbase is almost entirely mysql-exclusive, so the general ideas in that patch are likely the correct. I'm about to push an updated version, but obviously supporting all possible variants (mysql5, mysql5+postgresql83, postgresql83 by itself, etc) is both impractical and silly. I'll monitor feedback about the port, and try to make sure it's meeting the actual users needs. b On Sep 29, 2008, at 23:16 , Ryan Schmidt wrote: > > On Sep 29, 2008, at 11:19 AM, brett at macports.org wrote: > >> Revision: 40328 >> http://trac.macports.org/changeset/40328 >> Author: brett at macports.org >> Date: 2008-09-29 09:19:58 -0700 (Mon, 29 Sep 2008) >> Log Message: >> ----------- >> add postgresql83 option for sphinx >> >> Modified Paths: >> -------------- >> trunk/dports/textproc/sphinx/Portfile >> >> Modified: trunk/dports/textproc/sphinx/Portfile >> =================================================================== >> --- trunk/dports/textproc/sphinx/Portfile 2008-09-29 16:19:35 UTC >> (rev 40327) >> +++ trunk/dports/textproc/sphinx/Portfile 2008-09-29 16:19:58 UTC >> (rev 40328) >> @@ -20,6 +20,7 @@ >> distfiles sphinx-${version}.tar.gz >> checksums sha1 0f82e56a9181b3aeaeef65e9ba82fbf6fbe632d6 >> >> +depends_lib-append port:mysql5 >> configure.args --mandir=${prefix}/share/man \ >> --datadir=${prefix}/share/doc \ >> --with-mysql-includes=${prefix}/include/mysql5/mysql \ >> @@ -27,9 +28,17 @@ >> >> test.run yes >> >> -variant postgres description {Enable PostgeSQL support} { >> +variant postgres description {Enable PostgreSQL support for old >> PgSQL 8.2} { >> depends_lib-append port:postgresql82 >> configure.args-append --with-pgsql >> configure.args-append --with-pgsql-includes=${prefix}/include/ >> postgresql82 >> configure.args-append --with-pgsql-libs=${prefix}/lib/ >> postgresql82 >> } >> + >> +variant postgresql83 description {Enable PostgreSQL support for >> newer PgSQL v8.3} { >> + depends_lib-append port:postgresql83 >> + configure.args-append --with-pgsql >> + configure.args-append --with-pgsql-includes=${prefix}/ >> include/postgresql83 >> + configure.args-append --with-pgsql-libs=${prefix}/lib/ >> postgresql83 >> + configure.args-delete --with-mysql-includes >> +} > > Is this correct? > > You added a global mysql5 dependency which seems to match with the > global --with-mysql-includes configure argument. But in the > postgresql83 variant you delete the configure argument but don't > delete the dependency? And in the postgres variant you don't delete > either of them. > > > > !DSPAM:48e1c3e0299683780313872! > From jberry at macports.org Tue Sep 30 20:04:19 2008 From: jberry at macports.org (James Berry) Date: Tue, 30 Sep 2008 20:04:19 -0700 Subject: [PATCH] Inheritance of macports.conf configuration files In-Reply-To: <670d23ff0809301203g4e1cef41p67aac56c89395fbe@mail.gmail.com> References: <670d23ff0808220121g1ebe7680of841f988dfc5fc28@mail.gmail.com> <670d23ff0809301203g4e1cef41p67aac56c89395fbe@mail.gmail.com> Message-ID: <43FA131A-B1B7-4B75-A58E-57D38360F858@macports.org> Adam, Thanks for the patch. This looks good to me. Does anybody have a use case where inheritance is not the right thing here? James On Sep 30, 2008, at 12:03 PM, Adam Byrtek wrote: > There had been no response to my previous post (quoted below), so I > decided to try again. Could one of the MacPorts maintainers take a > look at the patch, please? This is actually quite a trivial change > that will make the user configuration much more convenient. > > Best regards > Adam Byrtek > > > On Fri, Aug 22, 2008 at 10:21 AM, Adam Byrtek > wrote: >> I've made a tweak in handling of macports.conf configuration file, >> now >> the global file defines defaults and user configuration can just >> override parts of it. More information can be found in this thread on >> macports-users: >> http://lists.macosforge.org/pipermail/macports-users/2008-August/011273.html >> >> The actual patch is available here: >> http://trac.macports.org/ticket/16329 >> >> A similar problem had been raised on this list a year ago, bus as far >> as I know didn't result in a patch: >> http://lists.macosforge.org/pipermail/macports-dev/2007-April/001373.html >> >> I'm looking forward for reviewing and applying the patch if you >> find it valid. >> >> Best regards, >> Adam Byrtek >> > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2761 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080930/19daad4a/attachment.bin From raimue at macports.org Tue Sep 30 20:13:15 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 01 Oct 2008 05:13:15 +0200 Subject: [PATCH] Inheritance of macports.conf configuration files In-Reply-To: <670d23ff0809301203g4e1cef41p67aac56c89395fbe@mail.gmail.com> References: <670d23ff0808220121g1ebe7680of841f988dfc5fc28@mail.gmail.com> <670d23ff0809301203g4e1cef41p67aac56c89395fbe@mail.gmail.com> Message-ID: <48E2EACB.1000008@macports.org> Adam Byrtek wrote: > There had been no response to my previous post (quoted below), so I > decided to try again. Could one of the MacPorts maintainers take a > look at the patch, please? This is actually quite a trivial change > that will make the user configuration much more convenient. Sometimes macports-dev is not so responsive and everybody seems busy. Good that you sent out the reminder, I just forgot about this patch already. +1 on applying the patch. Rainer