January 2008 - macports-dev - lists.macosforge.org

Re: [33591] branches/release_1_6/base/portmgr/dmg/postflight
by Ryan Schmidt 31 Jan '08

31 Jan '08

On Jan 31, 2008, at 00:36, jmpp(a)macports.org wrote: > Revision: 33591 > http://trac.macosforge.org/projects/macports/changeset/33591 > Author: jmpp(a)macports.org > Date: 2008-01-30 22:36:50 -0800 (Wed, 30 Jan 2008) > > Log Message: > ----------- > > Seems like the source of all my pains is Installer.app, which > aparently limits the environment I run under in some way > and forces SHELL to /bin/sh always (even if I run as a login shell, > it just doesn't seem to be possible to get to the > user's info), rendering useless the `case` routine that tries to > determine the shell I need to tweak. > > As a lame workaround, I'm going to glob for *sh to match /bin/sh > and thus still write my settings to the common profile file, > leaving all those *csh users out there a bit in dispair. Could you read the user's real shell like this? USHELL="$(nicl . -read /users/rschmidt shell | sed 's/^shell: //'')"

4 8

Re: [MacPorts] #14104: pv 1.1.0 upgrade/build failure
by Ryan Schmidt 31 Jan '08

31 Jan '08

On Jan 31, 2008, at 09:54, MacPorts wrote: > #14104: pv 1.1.0 upgrade/build failure > --------------------------------- > +------------------------------------------ > Reporter: meissnem(a)gmail.com | Owner: > ryandesign(a)macports.org > Type: defect | Status: new > Priority: Normal | Milestone: Port Bugs > Component: ports | Version: 1.6.0 > Resolution: | Keywords: pv upgrade build > failure > --------------------------------- > +------------------------------------------ > Comment (by meissnem(a)gmail.com) > > The post-patch is needed on Leopard -- that's my primary system > and I can > confirm it. > > I got my hands on a 10.4.11 system myself and confirmed what you > found, so > I'm attaching an updated patch. > > As an aside, it sure would be nice to have a 10.3, 10.4, and 10.5 > machine > available to maintainers for testing... or if not maintainers then at > least committers! That could be nice... but has some complications. First, getting funds and getting machines. I suppose three Mac minis could be found for cheap (ideally five: three PowerPC OSes, two Intel ones). Then, probably each committer would need their own user account with their own MacPorts installation, so as not to step on one another's toes. And then there's the problem that not all ports can install without root access, which none of the commiters would likely have on these testing boxes.

2 1

Re: [33591] branches/release_1_6/base/portmgr/dmg/postflight
by Juan Manuel Palacios 31 Jan '08

31 Jan '08

On Jan 31, 2008, at 2:06 AM, jmpp(a)macports.org wrote: > Revision > 33591 > Author > jmpp(a)macports.org > Date > 2008-01-30 22:36:50 -0800 (Wed, 30 Jan 2008) > Log Message > > Seems like the source of all my pains is Installer.app, which > aparently limits the environment I run under in some way > and forces SHELL to /bin/sh always (even if I run as a login shell, > it just doesn't seem to be possible to get to the > user's info), rendering useless the `case` routine that tries to > determine the shell I need to tweak. > > As a lame workaround, I'm going to glob for *sh to match /bin/sh and > thus still write my settings to the common profile file, > leaving all those *csh users out there a bit in dispair. Please disregard this, r33592 explains why. -jmpp

1 0

Re: [33588] trunk/dports/security/cracklib
by Ryan Schmidt 31 Jan '08

31 Jan '08

On Jan 30, 2008, at 19:01, June Tate-Gans wrote: > On Wed, Jan 30, 2008 at 5:42 PM, Ryan Schmidt wrote: > >> In this diff, it's hard to see what functional changes you made, >> because you also reformatted the whitespace of the file. In the >> future, could you please commit whitespace changes in a separate >> revision from functional changes? Thanks. > > Absolutely. The trick in this case, though, was that I literally > ripped out most of the original portfile, so a diff was actually > rather insufficient to show what it was I did. I will keep this in > mind the next time I send out a revision, though -- I know how painful > diffs can be. My apologies for the additional eye-strain. > >> It's not necessary to set the extract.suffix to .tar.gz since that's >> the default already. > > Noted. I'll remove that from the portfile. > >> You shouldn't define a "largedict" variant, then use >> "default_variants +largedict" to enable it always. This makes it >> difficult for the user to disable this functionality, should they >> want to. (The user can "sudo port install cracklib -largedict" but >> next time they want to "sudo port upgrade" the +largedict variant >> will be selected again.) Rather, you should write the port so that >> this is the default functionality, and then define a "no_largedict" >> variant to disable it. > > Mm. I thought about this for a while before submitting the patch. > Thing is, cracklib's functionality is severely reduced without that > dictionary, and it seemed to be the upstream maintainer's intention to > include it, which is why it is the default. Your idea makes quite a > lot of sense, though, and I will include it soon. FYI: the macports > guide doesn't mention anything about the upgrade issue you mentioned > above in the variants section, which is why I didn't consider that > aspect. The guide mentions it here: http://guide.macports.org/#reference.variants.user-selected "Due to a bug in the current MacPorts base default_variants shouldn't be used at the moment as they cause problems while upgrading ports." >> The largedict variant has the path /opt/local hardcoded into the >> portfile. MacPorts might be installed into a different prefix so the >> variable ${prefix} should always be used instead. > > Greh -- thought I managed to nix most of those. I'll fix that in the > next revision. My apologies. > > Thanks for the human-linting -- it was quite informative. =o) What can I say, I like keeping an eye on the commit mails. :)

2 1

Re: [33586] trunk/dports/security
by Ryan Schmidt 31 Jan '08

31 Jan '08

On Jan 30, 2008, at 17:06, ecronin(a)macports.org wrote: > +destroot { > + xinstall -d -m 0755 ${destroot}/${prefix}/share/cracklib > + xinstall -m 0644 ${worksrcpath}/${name} ${destroot}/${prefix}/ > share/cracklib > +} There should not be a slash between ${destroot} and ${prefix} because ${prefix} already begins with a slash.

1 0

Re: [33588] trunk/dports/security/cracklib
by Ryan Schmidt 31 Jan '08

31 Jan '08

In this diff, it's hard to see what functional changes you made, because you also reformatted the whitespace of the file. In the future, could you please commit whitespace changes in a separate revision from functional changes? Thanks. It's not necessary to set the extract.suffix to .tar.gz since that's the default already. You shouldn't define a "largedict" variant, then use "default_variants +largedict" to enable it always. This makes it difficult for the user to disable this functionality, should they want to. (The user can "sudo port install cracklib -largedict" but next time they want to "sudo port upgrade" the +largedict variant will be selected again.) Rather, you should write the port so that this is the default functionality, and then define a "no_largedict" variant to disable it. The largedict variant has the path /opt/local hardcoded into the portfile. MacPorts might be installed into a different prefix so the variable ${prefix} should always be used instead. On Jan 30, 2008, at 17:21, ecronin(a)macports.org wrote: > Revision: 33588 > http://trac.macosforge.org/projects/macports/changeset/33588 > Author: ecronin(a)macports.org > Date: 2008-01-30 15:21:42 -0800 (Wed, 30 Jan 2008) > > Log Message: > ----------- > Update to 2.8.12 and set new maintainer. Closes #14100 > > Modified Paths: > -------------- > trunk/dports/security/cracklib/Portfile > > Removed Paths: > ------------- > trunk/dports/security/cracklib/files/ > > Modified: trunk/dports/security/cracklib/Portfile > =================================================================== > --- trunk/dports/security/cracklib/Portfile 2008-01-30 23:11:30 UTC > (rev 33587) > +++ trunk/dports/security/cracklib/Portfile 2008-01-30 23:21:42 UTC > (rev 33588) > @@ -1,3 +1,5 @@ > +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: > nil; c-basic-offset: 4 -*- > +# vim:fenc=utf-8:filetype=tcl:et:sw=4:ts=4:sts=4 > # $Id$ > > PortSystem 1.0 > @@ -2,42 +4,43 @@ > > -name cracklib > -version 2.7 > -categories security > -maintainers nomaintainer > -description A ProActive Password Sanity Library > -long_description CrackLib is a library containing a C function > (well, \ > - lots of functions really, but you only need to use \ > - one of them) which may be used in a passwd-like \ > - program. The idea is simple: try to prevent users \ > - from choosing passwords that could be guessed by \ > - Crack by filtering them out, at source. > -homepage http://www.crypticide.com/users/alecm/ > -master_sites http://www.crypticide.com/users/alecm/security/ > -distname ${name},${version} > -checksums md5 0c84ad7413d9dd3e5c2eaa5f97d53c4a > -platforms darwin > +name cracklib > +version 2.8.12 > +categories security > +maintainers theonelab.com:june > +description A ProActive Password Sanity Library > +long_description CrackLib is a library containing a C function > (well, \ > + lots of functions really, but you only need to > use \ > + one of them) which may be used in a passwd- > like \ > + program. The idea is simple: try to prevent > users \ > + from choosing passwords that could be guessed > by \ > + Crack by filtering them out, at source. > > -patchfiles patch-Makefile.diff \ > - patch-cracklib-Makefile.diff \ > - patch-util-Makefile.diff \ > - patch-util-mkdict.diff > -post-patch { > - file copy ${filespath}/cracklib.3 ${worksrcpath}/cracklib > - file copy ${filespath}/mkdict.1 ${worksrcpath}/util > - file copy ${filespath}/teststr.1 ${worksrcpath}/util > -} > +homepage http://sourceforge.net/projects/cracklib/ > +platforms darwin > +depends_lib port:gettext > +default_variants +largedict > > -configure { > - reinplace "s|@PREFIX@|${prefix}|g" \ > - ${worksrcpath}/util/mkdict.1 \ > - ${worksrcpath}/util/teststr.1 > +master_sites sourceforge > +checksums md5 580346fa1012f9d9769192f49d3801fa \ > + sha1 0a77b21366cfbad675e6e44642026c89b87f41ce \ > + rmd160 91649e66c3ce491b2ebea6135eaa6ba4705ffb58 \ > + > +extract.suffix .tar.gz > + > +configure.args-append --without-python > + > +variant largedict { > + depends_build port:cracklib-words > + destroot.target-append dict-local > } > > -build.args PREFIX=${prefix} VERSION=${version} > -destroot.args PREFIX=${prefix} VERSION=${version} > -post-destroot { > - set docPath "${prefix}/share/doc/${name}" > - xinstall -d -m 0755 ${destroot}${docPath} > - xinstall -m 0644 ${worksrcpath}/README ${destroot}${docPath} > +post-build { > + if {[variant_isset largedict]} { > + file copy /opt/local/share/cracklib/cracklib-words $ > {worksrcpath}/dicts > + } > + > + file attributes ${worksrcpath}/util/cracklib-format - > permissions 0755 > } > > +test.run yes > +test.cmd make > +test.target check

1 0

Re: [33525] trunk/dports/python/py25-gsl/Portfile
by William Siegrist 30 Jan '08

30 Jan '08

Do you want any of the mailing lists emailed as well when errors are found? -Bill On Jan 29, 2008, at 7:21 PM, Ryan Schmidt wrote: > On Jan 29, 2008, at 12:59, William Siegrist wrote: > >> On Jan 29, 2008, at 6:29 AM, Ryan Schmidt wrote: >> >>> * "port lint" should be run by the Subversion repository in a post- >>> commit hook and any problems found emailed to the committer and >>> the maintainer: >>> >>> http://trac.macosforge.org/projects/macports/ticket/12594#comment:4 >> >> I can add `port lint` to the post-commit for any Portfiles if you >> want. > > That would be great. Should I file you a ticket for that? > >> I dont see a way to get only the list of maintainers from port, but >> I can always grep/regexp to get them from `port info`? I seem to >> remember a better way though. > > Get the port's maintainers (comma-space separated) like this: > > port -q info --maintainer $PORT > > Then you'll have to filter that to exclude nomaintainer(a)macports.org > and openmaintainer(a)macports.org. > > `port lint` currently always exits with status 0, even if it finds > something wrong with the portfile. This is unfortunate. However, an > acceptable workaround for now would be to run: > > port -q lint $PORT > > This will only produce output if there are problems in the port. And > only in that case should the email be sent. > ---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist(a)apple.com 408 862 7337

1 0

MacPorts as non-root (and non-admin)
by Anders F Björklund 30 Jan '08

30 Jan '08

The old request of being able to run MacPorts as non-root resurfaced, something that isn't supported at the moment... Most ports do install under the configurable ${prefix} (and ${x11prefix} for some of the optional X11 ports), but there are also a bunch that are hardcoding the (admin) locations of /Applications/MacPorts and /Library/Frameworks. So the Mac OS X tree (macosx.mtree) probably also needs a prefix added, so that they would instead install under ~/Applications and ~/Library, when running as non-admin ? (and probably default to ~/Library/Tcl for macports1.0) As a first step, I added* two parameters to configure: --with-applications-dir and --with-frameworks-dir It also needs a new Portfile setting added somewhere: a flag for "this port requires root/admin priviledges" It would be set for things like servers or extensions, that really *needs* root in order to run properly... Possibly tying in with the "startupitem.type none", http://lists.macosforge.org/pipermail/macports-dev/2006-October/ 000136.html Then the above two variables could go in as something like: ${destroot.applications} ${destroot.frameworks} --anders * http://trac.macosforge.org/projects/macports/changeset/33499

2 1

64-bit versions of some ports
by Ryan Schmidt 30 Jan '08

30 Jan '08

The ability for MacPorts to build 64-bit versions of ports was discussed a little while ago, but I don't think there was any resolution. Let's try again. Paulo Moura wrote to me because users of his swi-prolog port have requested this (requires dependencies gmp and readline to be 64-bit too): On Jan 30, 2008, at 05:30, Paulo Moura wrote: > Some time ago, I posted to the mailing list a message about 64 bits > variants but received no reply. Maybe you're able to provide me > some feedback on this issue. I would like to add 64 bits variants > to some port such as "readline" and "gmp". Is my understanding > (please correct me if I'm wrong) that 64 bits and 32 bits versions > of the same library co-exist peacefully. The reason I'm asking is > that some SWI-Prolog users are asking for a 64 bits variant. In > order to provide this 64 bits variant I need first to have 64 bits > variants in-place for all the libraries SWI-Prolog depend on. And Randy Melder requested this for my mysql5 port (probably requires 64-bit openssl and zlib): On Jan 28, 2008, at 12:35, Randy Melder wrote: > Is this a 64bit compile, or 32? I seems the 32bit compiles have > problems with allocating memory above 2GB. From the previous discussion, I remember that we (or rather mww) started by changing the +universal variant to build all 4 versions (2 architectures each of 32-bit and 64-bit) but this was problematic because many ports failed to build out of the box as 64-bit, and there was no clear upgrade path for those who already had 2- architecture universal variants installed, and it was said that 64- bit versions of most ports don't make sense anyway (aren't faster, or possibly are even slower). But it seems like we want to be able to do this for selected ports. Suppose we say we want to define a new variant called +64bit. Let's figure out what we want that to do. Are we asking for a way to build a 64-bit local-architecture binary instead of a 32-bit local- architecture binary (e.g. x86_64 only)? or in addition to a 32-bit local-architecture binary by installing both into separate paths (e.g. ${prefix}/lib and ${prefix}/lib64 -- I don't think this is the Mac way)? or in addition to a 32-bit local-architecture binary by making a single fat binary (e.g. i386 and x86_64 in one file)? What if the user selects +universal in addition to +64bit? How will we handle that? I saw some commits fly by (by afb) about the universal support in base. Was this something to do with making the universal_archs array configurable? If so, is that user-configurable or port-configurable? The above is really just babbling to demonstrate that I don't know what to do about this problem. Maybe someone else can be smarter for me and figure it out.

2 2

tetex/texlive dependencies
by John Owens 30 Jan '08

30 Jan '08

Howdy, new committer here, happy to be on board! For several years I've been using tetex successfully. But as it's no longer updated, I'm happy to move to the new texlive port. It was tricky to install texlive because of tetex (getting tetex deactivated and texlive activated was ugly). But more importantly, now that texlive is installed, there's lots of other ports that still depend on tetex that want to use tetex, such as: $ port deps bibtex2html bibtex2html has build dependencies on: ocaml bibtex2html has runtime dependencies on: teTeX Is there any way that we can have some sort of 'virtual' TeX port that either recognizes tetex or texlive, or otherwise convince ports that depend on tetex that texlive is good enough? JDO

10 15