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

Re: [32730] trunk/dports/net
by Ryan Schmidt 12 Jan '08

12 Jan '08

On Jan 12, 2008, at 14:00, ecronin(a)macports.org wrote: > Revision: 32730 > http://trac.macosforge.org/projects/macports/changeset/32730 > Author: ecronin(a)macports.org > Date: 2008-01-12 12:00:48 -0800 (Sat, 12 Jan 2008) > > Log Message: > ----------- > New port. Closes #13619 [snip] > +configure {} You should use "use_configure no" instead of "configure {}"

1 0

Re: [32635] trunk/dports/games/lincity-ng/Portfile
by Ryan Schmidt 12 Jan '08

12 Jan '08

On Jan 10, 2008, at 01:11, pguyot(a)kallisys.net wrote: > @@ -27,6 +28,7 @@ > depends_lib lib:libX11.6:XFree86 \ > lib:libxml2:libxml2 \ > bin:sdl-config:libsdl \ > + port:pkgconfig \ > lib:libsdl_mixer:libsdl_mixer \ > lib:libsdl_image:libsdl_image \ > lib:libsdl_ttf:libsdl_ttf \ pkgconfig does not provide any libraries. pkgconfig should be listed as a build dependency, not a library dependency.

4 4

Re: epochs and the guide
by markd＠macports.org 12 Jan '08

12 Jan '08

>or an example of how MacPorts does it, see port:543 (in proc >get_outdated_ports). In pseudo-code, it says roughly: > > if current_epoch != available_epoch > use epoch as basis for comparison > else if current_version != available_version > use version as basis for comparison > else > use revision as basis for comparison > >This means that an epoch should never be removed, since if the epoch >is different, it will always be used as the basis for comparison when >listing outdated ports. > >Some of the basis for confusion might come from macports.tcl:1923 (in >proc upgrade), where the pseudo-code is roughly: > > if current_version != available_version > use version as basis for comparison > else > use revision as basis for comparison > if current_epoch < available_epoch > upgrade anyway > >Now that I've read it more thoroughly, this code actually *does* allow >the epoch to be removed--eventually, once the updated version has been >pushed out to everyone. > >Hrm. > >In other words, it seems that a port in which the epoch has been >removed could still be upgraded (with e.g. `port upgrade active`), but >would not be listed as outdated (and would not be upgraded with `port >upgrade outdated`). > >That's actually a bit of a mess and might deserve its own topic of >discussion. For now, I think it should be stated that an epoch cannot >be removed; this is the only case in which we can currently guarantee >consistent behavior. > >At the same time, we should change MacPorts' behavior to be >consistent. I think the method from port(1) is better than the one >from macports.tcl, since it's the only one in which we can guarantee >upgrades correctly--even if it does force an extra line of cruft to >hang around in Portfiles with epochs (all 20 of 'em!) Chris, I changed the text to this based on what you said about current behavior. Let me know if it needs adjusting. ---------- An epoch is not needed for most ports. If an epoch is used it must never be decreased or removed even when a port's version is updated; this would cause port version comparisons to be incorrect since epochs take precedence over versions once epochs have been used. ---------- Mark

2 1

Re: [32715] epochs and the guide / was .. portfile-keywords.xml
by markd＠macports.org 12 Jan '08

12 Jan '08

>On Jan 11, 2008, at 16:51, markd(a)macports.org wrote: > >> - <para>If an epoch is used it must must never be >> decreased or reset >> - to zero, because this would always cause a port version >> comparison >> - to be incorrect after a port upgrade.</para> >> + <para>An epoch is not needed for most ports. If an epoch >> is used it >> + must never be decreased without updating the port's >> version number; >> + this will cause port version comparisons to be >> incorrect.</para> > >I was led to believe that an epoch should never be decreased, ever, >once it has been added to a portfile, even if the port's version is >increased. I understood that the epoch takes precedence over the >version. Do you have new information to the contrary? I don't think the FreeBSD Porter's handbook states it clearly, some parts I'd interpret as agreeing with your understanding and other parts seem to say otherwise. But then I don't know for sure that MacPorts works the same anyway. http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-… I think discussion from someone (I forget who) some time ago made me to think otherwise so I changed it when revising the section. But I'm not really sure. If could someone could find out one way or another it would be great to know for sure and document it. Mark

2 1

Call for help testing release_1_6's revamped postflight script
by Juan Manuel Palacios 11 Jan '08

11 Jan '08

As some of you may have seen, I've been improving the postflight script in the release_1_6 branch with the feedback I've received so far, plus some other relevant fixes/improvements. I've tested it locally on both virgin and customized accounts, extensively, and have found it to work reliably so far. Nevertheless, we all know a single workstation is no high quality measure ;-) so I'd like to openly call for wider testing in case I'm missing bugs that my environment is not surfacing. If you're up for it, please grab the script off this URL [1] and take it for a hard ride on whatever environment you can think of. I've tried to bullet-proof it for straight forward functionality in a default environment and to be as polite and non-disruptive as possible in a non-default one. For those of you wondering what I'm considering as a default environment, have a read at: http://guide.macports.org/#installing.binary.postflight.details That, plus the fact that I only do it for bash and tcsh shells, and the latter only as legacy support for Jaguar and previous accounts (Maun Suang, can we add a note about this to the guide section above?). I'm somewhat considering removing such support because tweaking tcsh configuration file has proven a tad difficult: 1) It's not easy to invoke a non-interactive, login tcsh shell session. In a nutshell, so far it has proven impossible for me. This limits my ability to properly test the environment to figure out what I need to add and what I don't, which takes me onto 2) below 2) It's not clear to me whether I should write to ~/.tchsrc, ~/.cshrc or ~/.login (I've heard solid claims for all of them), barring my inability to properly test the environment; 3) barring 2), the form of the settings to be written varies ("set foo = bar" Vs. "setenv foo bar"); 4) I'm by no means a tcsh user, so all I can do is *guess* the best approach in unpleasant tcsh debugging sessions ;-) In my various instances of 4), plus very kind help from both Eric Hall and Wilfredo Sanchez at times, have lead me to a combination of ~/.tcshrc with "setenv foo bar" statements, which I think works fairly well. But still, I'd love some experienced tcsh using eyes if available to shed some more light on this aspect of the script (thinking a bit more about it, resolving 1) above would probably solve this entire problem). So, without any further ado, I'd appreciate as much help I can get in testing this script and, in case of failure, getting detailed reports if possible. Success reports are also of course welcomed! Regards,... -jmpp [1] http://trac.macports.org/projects/macports/browser/branches/release_1_6/bas…

1 0

Can someone commit? (gtkglext, gwyddion, qucs)
by Rolf Würdemann 11 Jan '08

11 Jan '08

First: #13624 (http://trac.macosforge.org/projects/macports/ticket/13624) (Update of the Portfile for gtkglext, so it runs on Leopard also) after that: #13737 (http://trac.macosforge.org/projects/macports/ticket/13737) (Update of gwyddion, so gwyddion works on leoparf also (depend on #13624) If this both updates are commited, tickets: #13560 (http://trac.macosforge.org/projects/macports/ticket/13560) and #13517 (http://trac.macosforge.org/projects/macports/ticket/13517) can also be closed (dealing with same issues, so no commits of them please;) if you have some spare time after this, it would be fine to commit #13826 (http://trac.macosforge.org/projects/macports/ticket/13826) which is an update of qucs to 0.0.13 ;) If there is anything whch denies to Portfiles from getting committed, please let me know ;) Reg's Rolf -- Security is an illusion - Datasecurity twice Rolf Würdemann - private: rowue(a)digitalis.org - office: rowue(a)crew-gmbh.de GnuPG fingerprint: 7383 348F 67D1 CD27 C90F DDD0 86A3 31B6 67F0 D02F jabber: rowue(a)digitalis.org 2F66A061 89BCA1A0 AD654827 6FD037FF 53C3E932

1 0

How embarrasing!
by Juan Manuel Palacios 11 Jan '08

11 Jan '08

Warning: violation by /opt/local/man Warning: MacPorts violates the layout of the ports-filesystems! Warning: Please fix or indicate this misbehavior (if it is intended), it will be an error in future releases! Do you think it's safe to remove the ${prefix}/man symlink to $ {prefix}/share/man in MacPorts sources? Or do we have to bite the bullet and "destroot.violate_mtree yes"-justify ourselves to remove the warning? -jmpp

5 5

Re: Different dmgs for different felines
by Rainer Müller 10 Jan '08

10 Jan '08

Ryan Schmidt wrote: > Rainer, would you prefer for us to distribute 5 different disk images of > MacPorts then -- Panther PowerPC, Tiger PowerPC, Tiger Intel, Leopard > PowerPC, Leopard Intel? A disk image with four architectures will be around four times bigger than it needs to be... Why should anybody want to download a large file if 3/4 are useless data and just occupy disk space? > Apple wants developers to make universal binaries so that users don't > need to care what kind of processor they have. Other Mac developers are > making universal binaries. We should too. And we already do. We just > have separate images for Panther, Tiger and Leopard right now. And I'd > like to unify that as well so that we end up with a single downloadable > for our software, like most other Mac developers already have. So why does Apple not just provide a interface to strip uneeded architectures right on installing? Instead, they copy useless data. I don't understand this... At least one can do it himself and remove them with ditto. > We already had several cases where users downloaded the Leopard MacPorts > disk image, installed it on Tiger, and of course it didn't work. So > distributing a single disk image which works everywhere is simpler for > users. [Those stupid users should learn to read...] But if you download an universal disk image; after the first selfupdate, which you normally do after install to get a newer minor version, you will end up with a single architecture - the one of your system. Why should disk images distribute a different version than selfupdate? I don't want to debate over support universal building for ports, somebody might need it. And I don't want to say that universal in general is bad. Rainer

4 6

g95, Open MPI, HDF4, tcl-nap
by Takeshi Enomoto 10 Jan '08

10 Jan '08

Hi, It would be nice if someone could commit those tickets. Build failure of g95, in particular, is affetting a number of other ports. I submitted hdf4 and tcl-nap about a month ago. Thanks in advance, Takeshi g95: fixes libiconv problem <http://trac.macosforge.org/projects/macports/ticket/13841> Open MPI: Xgrid support <http://trac.macosforge.org/projects/macports/ticket/13819> HDF4.2r2 <http://trac.macosforge.org/projects/macports/ticket/13603> tcl-nap-6.4.0 <http://trac.macosforge.org/projects/macports/ticket/13605>

1 0

Re: [32618] trunk/dports/science/molden/Portfile
by Ryan Schmidt 10 Jan '08

10 Jan '08

On Jan 9, 2008, at 09:22, jochen(a)macports.org wrote: > Revision: 32618 > http://trac.macosforge.org/projects/macports/changeset/32618 > Author: jochen(a)macports.org > Date: 2008-01-09 07:22:00 -0800 (Wed, 09 Jan 2008) > > Log Message: > ----------- > follow upstream stealth update > > Modified Paths: > -------------- > trunk/dports/science/molden/Portfile > > Modified: trunk/dports/science/molden/Portfile > =================================================================== > --- trunk/dports/science/molden/Portfile 2008-01-09 14:28:28 UTC > (rev 32617) > +++ trunk/dports/science/molden/Portfile 2008-01-09 15:22:00 UTC > (rev 32618) > @@ -13,15 +13,15 @@ > > name molden > version 4.6 > -revision 2 > +revision 3 > categories science graphics > maintainers openmaintainer jochen > master_sites ftp://ftp.cmbi.ru.nl/pub/molgraph/molden > distname molden${version} > dist_subdir molden-${version}_${revision} > -checksums md5 b52d66fc61f3d85abba94e36c14b5d85 \ > - sha1 2faeea9f970d5430ab0d2863a7f59c1780c56d3e \ > - rmd160 c21b9359e30f24942baa6e3b0dd412c793e3ad17 > +checksums md5 f2d929fe96ab85a3f994557140f5dcbe \ > + sha1 04cc6e32c1c8a79e54c02cfacdcddee4a64d08dc \ > + rmd160 f11735e616afb7e6de7bd94bc8782068a9fb47bf Anyone who still has the old distfile on their hard drive will now experience a checksum error when attempting to upgrade this port. You should change the dist_subdir so that this problem does not happen. Please add something like dist_subdir ${distname}/${version}_${revision} to the portfile. This can then be removed at the next real version update (or left in, if this developer is prone to making stealth updates).

2 3