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

Don't clear the Version field
by Ryan Schmidt 18 Aug '07

18 Aug '07

Nox, In bugs like this one... http://trac.macports.org/projects/macports/ticket/12496 ...you've removed the value of the Version field. I'd like to ask you not to do so. It's useful to know what version of MacPorts a user had when they encountered a given bug.

2 3

New port submissions
by Simon Ruderich 18 Aug '07

18 Aug '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, could you please add these ports to macports. They both build and work fine for me PowerPC and Intel. + http://trac.macports.org/projects/macports/ticket/12324 + http://trac.macports.org/projects/macports/ticket/12463 (please apply the patch only partly, look at my comments; thanks) If you could also try to build and test them it would be very nice. Thanks for your help, Simon - -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGxvH6YRX4BO+zMikRCnwKAJsFOKRV8btPR09DljitdNyeO6KzzQCaAuG5 RopOszr1pheypYpx79ZPB0I= =wtbW -----END PGP SIGNATURE-----

1 0

Re: mtree violation check: no files matched glob pattern
by Ryan Schmidt 17 Aug '07

17 Aug '07

On Aug 14, 2007, at 09:47, spambox(a)neuf.fr wrote: > Ryan Schmidt-24 wrote: > >> I'd say installing into /Applications/MacPorts should not be >> considered an mtree violation. Check this out: > > Hi, > > I don't know if it's related but i just got this trying to install > ghostscript : > > ---> Staging ghostscript into destroot > Error: violation by /opt/local/man > Error: Target org.macports.destroot returned: mtree violation! > Error: Status 1 encountered during processing. > > I did not get that when I installed gimp of ImageMagick. Let's keep discussion on the mailing list please. Use the Reply To All feature when you reply. The problem I reported was a problem in the mtree checker. It has been fixed in trunk and in the release_1_5 branch and will be included in the next version of MacPorts after 1.5.1. At that time, mtree violations will also become warnings instead of fatal errors, to give us time to clean up the existing ports. The error you reported in ghostscript is unrelated, but I'm not sure how to fix it and need assistance from the list: The ghostscript port install these items which violate the mtree: /opt/local/man/de/man1/dvipdf.1 /opt/local/man/de/man1/eps2eps.1 /opt/local/man/de/man1/font2c.1 /opt/local/man/de/man1/gsnd.1 /opt/local/man/de/man1/pdf2dsc.1 /opt/local/man/de/man1/pdf2ps.1 /opt/local/man/de/man1/pdfopt.1 /opt/local/man/de/man1/printafm.1 /opt/local/man/de/man1/ps2ascii.1 /opt/local/man/de/man1/ps2pdf.1 /opt/local/man/de/man1/ps2pdf12.1 /opt/local/man/de/man1/ps2pdf13.1 /opt/local/man/de/man1/ps2ps.1 /opt/local/man/de/man1/wftopfa.1 /opt/local/man/man1/dvipdf.1 /opt/local/man/man1/eps2eps.1 /opt/local/man/man1/font2c.1 /opt/local/man/man1/gs.1 /opt/local/man/man1/gslp.1 /opt/local/man/man1/gsnd.1 /opt/local/man/man1/pdf2dsc.1 /opt/local/man/man1/pdf2ps.1 /opt/local/man/man1/pdfopt.1 /opt/local/man/man1/pf2afm.1 /opt/local/man/man1/pfbtopfa.1 /opt/local/man/man1/printafm.1 /opt/local/man/man1/ps2ascii.1 /opt/local/man/man1/ps2epsi.1 /opt/local/man/man1/ps2pdf.1 /opt/local/man/man1/ps2pdf12.1 /opt/local/man/man1/ps2pdf13.1 /opt/local/man/man1/ps2pdfwr.1 /opt/local/man/man1/ps2ps.1 /opt/local/man/man1/wftopfa.1 I thought I could fix this by adding this directive: configure.args --mandir=${prefix}/share/man When I do that, the mtree violation disappears, but also all of the above files do not get installed. They don't get installed in $ {prefix}/share/man; they don't get installed anywhere. Why? I'm using MacPorts built from the release_1_5 branch r27780 which includes the new fixes to the mtree checker.

2 2

MacPorts 1.5.2 in Version menu in Trac
by Ryan Schmidt 17 Aug '07

17 Aug '07

Please add "1.5.2" to the Version menu in Trac. Currently we must choose between "1.5.1" and "1.6.0".

1 0

Docs blurb about the registry
by markd＠macports.org 17 Aug '07

17 Aug '07

I'd like to put some simple descriptive text about the MacPorts registry in the new guide in "MacPorts Internals". I know that a new registry is under development, but I don't even know where the current "flat" one is. Where is it? And if there isn't any docs on that (other than the API description in the guide), if anyone could give a short description of what MacPorts uses the registry for that would be great too, assuming there are things beyond the obvious that it does. Also, the new guide is rapidly approaching what I think is a rough sort of completeness. Another day or two and I think I'll be ready to stop making major changes for the time being. It isn't perfect, but I think it is more useful than the legacy guide now, and far more accessible. I think we could link it at the top level of the wiki and delete the InstallingMacPorts wiki entry any time. Mark

1 0

moving "macports1.0" to ${prefix}
by Anders F Björklund 16 Aug '07

16 Aug '07

For MacPorts 1.6, it might be a good idea to consider moving "macports1.0" from the current @TCL_PACKAGE_DIR@ directory to the @prefix_expanded@/share/macports/Tcl directory, in order to make the MacPorts installation self-contained within the designated prefix ? If the "macports1.0" module needs to be in the system's Tcl package directory in order for other (inferior) software to find it, then can't this be accomplished by setting up a symbolic link ? e.g. /Library/Tcl/macports1.0 -> /opt/local/share/macports/Tcl/macports1.0 --anders

5 11

PortIndex Regen Failure on Thursday 2007-08-16 at 15:30:00
by mp-user＠geeklair.net 16 Aug '07

16 Aug '07

svn: PROPFIND request failed on '/repository/macports/trunk' svn: PROPFIND of '/repository/macports/trunk': Could not resolve hostname `svn.macports.org': No address associated with nodename (http://svn.macports.org) Updating the dports tree from http://svn.macports.org/repository/macports/trunk/dports failed.

1 0

Re: Default variants
by N_Ox 16 Aug '07

16 Aug '07

Le 16 août 07 à 15:19, Yves de Champlain a écrit : > > Le 07-08-16 à 08:49, N_Ox a écrit : > >> >> Le 16 août 07 à 13:47, Rainer Müller a écrit : >> >>> N_Ox wrote: >>>> >>>> Le 14 août 07 à 19:58, N_Ox a écrit : >>>> >>>>> >>>>> Le 12 août 07 à 05:28, N_Ox a écrit : >>>>> >>>>>> From what I've understood, the problem with default variants >>>>>> is that >>>>>> if we do something like `port foo -bar` and that foo has >>>>>> `default_variants +bar`, if an upgrade of foo is released, >>>>>> then `port >>>>>> upgrade foo` will enable bar variant because variant disabling >>>>>> are >>>>>> not saved and `default_variants +bar` will be evaluated. >>>>>> >>>>>> Is this really a problem? >>>>>> Can't we use the magic of the TCL interpreter and ignore the >>>>>> call to >>>>>> default_variants procedure in upgrade variant? >>>>>> >>>>>> These were my $0.02 for tonight... >>>>>> ...I'll now take my pills and go to bed :p >>>>>> >>>>> >>>>> Another problem with default_variants are variant conflicts. >>>>> Something among those lines: >>>>> >>>>> variant apache2 {...} >>>>> variant apache conflicts apache2 {...} >>>>> default_variants +apache2 >>>>> >>>>> and this port command: >>>>> port install +apache >>>>> >>>>> would produce an error because that would select apache and >>>>> apache2. >>>>> >>>>> So here is my idea: let's create a new block named >>>>> variant_group, or >>>>> variant_choice, or even both. >>>>> >>>>> variant_(group|choice) webserver { >>>>> variant apache2 {...} >>>>> variant apache {...} >>>>> } >>>>> >>>>> variant_group would tell us that we _can_ enable support for _one_ >>>>> webserver, namely apache or apache2. >>>>> variant_choice would tell us that we _must_ enable support for >>>>> _one_ >>>>> webserver, namely apache or apache2. >>>>> >>>>> That's all for today. >>>>> Regards, >>>>> >>>> >>>> Almost all... >>>> I've forgotten something: >>>> >>>> default_variants +apache2 and port install +apache would not >>>> fail and >>>> would automagically select apache instead of +apache2. >>> >>> No one commented on this yet, so I will do start the discussion. >>> I think >>> this is a very reasonable idea to group variants to make it >>> easier to >>> implement choices. I also remember that we have some port having a >>> choice between gnutls and openssl, so this is really a common use >>> case. >>> But there is still the need to record disabled default variants >>> in order >>> for this to work. >>> >>> Rainer >> >> As I've said in the very first mail of this discussion, I don't >> think recording disabled default variants is really a problem. >> The only case it is one is during upgrade, and what I've said >> should fix that. > > It should also be noted that > > port install foo -bar > > will fail as -bar is not a recognized option. > > yves > I've never had problem with that. And you can always type `port install -- -foo`, I think. -- Anthony Ramine, the infamous MacPorts Trac slave. nox(a)macports.org

2 1

Re: libexec directory?
by N_Ox 16 Aug '07

16 Aug '07

Le 16 août 07 à 15:12, Anders F Björklund a écrit : > N_Ox wrote: > >>> I'm curious what is the logic for having two separate directories >>> one named "libexec" and the other named "bin"? >> >> From porthier(7): >> libexec/ system daemons & system utilities >> (executed by >> other programs) > > Also noteworthy is that "libexec" is a UNIX/BSD standard, and that > it isn't in the Linux Filesystem Hierarchy Standard (FHS). Thus, on > some distributions (e.g. RedHat) you'll find the programs in their > upstream location of "libexec" and on other distributions (e.g. > Debian) you'll find the programs randomized between "lib/$name" and > "sbin". Quite intriguing... > > If you're into that sort of thing, you can also find out the > differences between "sbin" and "bin". Or "/usr" and "/usr/local". > > --anders > Reply To All is your friend ;) -- Anthony Ramine, the infamous MacPorts Trac slave. nox(a)macports.org

1 0

Default variants
by N_Ox 16 Aug '07

16 Aug '07

From what I've understood, the problem with default variants is that if we do something like `port foo -bar` and that foo has `default_variants +bar`, if an upgrade of foo is released, then `port upgrade foo` will enable bar variant because variant disabling are not saved and `default_variants +bar` will be evaluated. Is this really a problem? Can't we use the magic of the TCL interpreter and ignore the call to default_variants procedure in upgrade variant? These were my $0.02 for tonight... ...I'll now take my pills and go to bed :p -- Anthony Ramine, a lazy french student. nox(a)macports.org

3 6