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

Fwd: [35353] tinyca2 Lint Report
by Landon Fuller 26 Mar '08

26 Mar '08

I'd like to formally request that these new style guideline be removed from port lint -- there's nothing wrong with the port. This kind of style pedantry wastes everyone's time. It doesn't matter. The last thing I need is an e-mail about it. I didn't place newline between the $Id: $ tag and the PortSystem line: # $Id: Portfile 35353 2008-03-25 18:13:44Z landonf(a)macports.org $ PortSystem 1.0 I named my patch file 'patch-tinyca2'. -landonf Begin forwarded message: > From: noreply(a)macports.org > Date: March 25, 2008 11:13:49 AM PDT > To: landonf(a)macports.org > Subject: [35353] tinyca2 Lint Report > > Portfile: tinyca2 > > > Warning: Line 2 should be a newline (after RCS tag) > Warning: Patchfile patch-tinyca2 does not follow the source patch > naming policy "patch-*.diff" > > >

6 16

NEW PORT: ipv6calc
by Cyril Bellot 26 Mar '08

26 Mar '08

Could someone have a look at this new port proposal : http://trac.macosforge.org/projects/macports/ticket/14611 Thanks

1 1

Erlang category?
by Landon Fuller 25 Mar '08

25 Mar '08

Any votes for/against creating an Erlang category, to match the Python/ Ruby/etc categories? First port I'd like to add is eunit 2.0 (erlang unit test library). -landonf

2 1

how to change makefile for osx ppc
by Marc Manthey 25 Mar '08

25 Mar '08

hello experts, sorry for crossposting , while i got no reply on xcode and several others told me to ask here. I like to test 2 programms , one is a multicast daemon , the other a toolset , on my macintosh osx ppc leopard machine. <http://unfix.org/projects/ecmh/ > i try to compile the avalable sources with "make" which gave me the following errors mini:ecmh-2005.02.09 mini$ make dist if [ -f configure-stamp ]; then debian/rules clean; fi; rm -f mtrace6.o mtrace6 cd ..; tar -zclof ecmh_2005.02.09.tar.gz ecmh-2005.02.09 tar: Semantics of -l option will change in the future releases. tar: Please use --one-file-system option instead. cd ..; tar -jclof ecmh_2005.02.09.tar.bz2 ecmh-2005.02.09 tar: Semantics of -l option will change in the future releases. tar: Please use --one-file-system option instead. # Copy the changelog debian/rules binary dh_testdir make[1]: dh_testdir: Command not found make[1]: *** [configure-stamp] Error 127 make: *** [deb] Error 2 thats the "makefile" <http://pastebin.com/d441d1ffb> cd into the main folder autoconf ./configure --prefic=/usr/local Sorry that should have been: ./configure --prefix=/usr/local make this does not work too thanks for any hints and pointers Marc -- "You see, all the problems in the world are created by those who want 'perfection.' " Sri Sri Ravi Shankar Les Enfants terribes - research and deployment jabber :mini@stattfernsehen.com blog: http://www.let.de ipv6 http://www.stattfernsehen.com/matrix

2 1

Re: [35275] trunk/dports
by Thomas Reifferscheid 25 Mar '08

25 Mar '08

Dear James, I dont feel well with your changes. It will make life even harder for submitters to the ticket database choosing the right maintainer. Regarding "automated ticket assignment to maintainers" your changes will make it harder for trac itself. How to solve this, have a port <=> maintainer map at a secret hidden place? Kind regards Thomas jberry(a)macports.org wrote: > > Revision > 35275 <http://trac.macosforge.org/projects/macports/changeset/35275> > Author > jberry(a)macports.org > Date > 2008-03-23 08:54:42 -0700 (Sun, 23 Mar 2008) > > > Log Message > > obfuscate my maintainer email addresses

5 7

Re: [35256] trunk/base/src/port1.0/portdistfiles.tcl
by Rainer Müller 24 Mar '08

24 Mar '08

wsiegrist(a)apple.com wrote: > Revision: 35256 > http://trac.macosforge.org/projects/macports/changeset/35256 > Author: wsiegrist(a)apple.com > Date: 2008-03-22 15:18:17 -0700 (Sat, 22 Mar 2008) > > Log Message: > ----------- > added checksum display and an early exit when master_sites is not provided > > Modified Paths: > -------------- > trunk/base/src/port1.0/portdistfiles.tcl Just that you are aware of it, there is already a `port mirror` target which may do the same or similar things. Maybe it could just be extended? I want to note this to avoid code duplication or something like this... Also, I think you forgot to add 'distfiles' to the action_array in port/port.tcl. Otherwise it will not be usable with `port distfiles`. Rainer PS: Sorry for sending this twice, Bill. I used an not subscribed email address...

2 3

destroot and (build && destroot) yield different results
by Marcus Calhoun-Lopez 24 Mar '08

24 Mar '08

A few days ago, I submitted a ticket outlining situations in which it takes two runs of the port command for correct installation (http://trac.macosforge.org/projects/macports/ticket/14687 ). Is this a known behavior? I have attempted to track down the problem myself, but it has been slow going as I am not well versed in either Tcl or the MacPorts code base. Can anyone offer suggestions as to which parts of the MacPorts code to look at to determine why "port destroot" and "port build && port destroot" might have different results? Thank you, Marcus

2 2

Architectural proposal
by Michelangelo 24 Mar '08

24 Mar '08

Hello, I've been thinking about this proposal for the whole day; William has suggested me to write it here, to hear directly from you, to hear your feedbacks and, most thing important for me, your objections. Ah! I was about to forget, my name's Michelangelo De Simone, I'm very pleased to meet you all.:) Synopsis MacPortsDaemon (“MaPoD”) is an additional layer above the existing MacPorts utilities and API that provides asynchronous access to MacPorts functionalities (and new ones) to upper layer clients. It’s based on a pluggable architecture. Visionary scenarios Mike (limited user) wants to use an Adium version built on his own, to accomplish that he launches a MacPorts/MaPoD client, search for Adium in the search box, once he has found it he chooses to build and install it. The client confirms the action to Mike and giving him a notification that his version of Adium will be delivered directly into his ~/ Applications folder once the build process is over. The client becomes immediatly available for new commands. Amanda (limited user) already built Cyberduck but she needs it no more and then she decides to uninstall it. To accomplish that Amanda launches a MacPorts/MaPoD client, search for installed apps, once she has found Cyberduck she select it and mark it for removal. Her client confirms the action and becomes immediatly available for new commands. John (administrator on his own system) decides that Mike and Amanda need Gimp, so he decides to build and install it in order to let Amanda and Mike use it. To do that he launches a MacPorts/MaPoD client, search for Gimp; once he has found it he tells the client to install Gimp system wide, for users to use it. His client confirms the action and becomes immediatly available for new commands. Amanda (limited user) needs Gimp, so she starts looking for it with her MacPorts/MaPoD client and asks the client to build and install it. Client notifies Amanda that Gimp is already being built because of John choice to deploy it system wide and that she we’ll be able to use in some time; MacPorts/MaPoD will notify her with a Growl notification when Gimp will be ready to be used. Mike (limted user) asks himself how to remove objects and “stuff” produced by MacPorts/MaPoD and finds out that there’s no reason to be concerned about because MacPorts/MaPoD mantains itself scheduling maintance operations at the right time. Amanda (limted user) worries about tree sync and tries to manually update it using her client but it notifies her that the latest sync has been done automatically by MacPorts/MaPoD itself yesterday night. MaPoD Architecture Overview MaPoD aims to provide MacPorts additional features applying de- coupling among actual and future software components. See pic here: http://snipurl.com/22dyy The whole architecture of MaPoD shall be developed as a system service (LaunchDaemon), letting the clients at the upper layer request services asynchronously (“Build Adium, notify me when you are done”); users could also benefit from scheduled/automatic maintance operations such as self-update, application upgrades, tree syncs, objects cleanup. MaPoD Core ‘s task is to accomplish basic functionalities, wrapping those already provided by MacPorts’ port and adding them mechanism such scheduling, permission managment, event notifications (“Adium succesfully built by John”). No user on the system should sudo to build an app for his own use. MaPoD Interface is the real glue between MaPoD/MacPorts and GUI. Clients and MaPoD are completely loosly coupled because MaPod Interface provides a neutral way for them to communicate. Third party MacPorts developers could develop plugins to extend core functionalities (“Build Adium, notify me when you are done with a Growl notification” or “Build Adium, notify me when you are done with an email to jdoe(a)apple.xn--com-9o0a) Conclusions With the appropriate choices any user on the same system, even limited ones, would see a full-featured MacPorts “distribution”; any user will have the possibility to search, install (from source or normal binary), remove his application with no touch to MacPorts at all. System administrator would also benefit from a fine grained permission system (“Do not let Mike build Adium” or “John can build and install only between 3pm and 9pm”). MacPorts installation would be “piloted” by MaPoD itself, so there will be no need to sudo-run it for occasional users. It’s clean, it’s “secure” (you know, Santa believes in security...:)). Whis this architecture possibilities are endless: how long would be needed to develop a plugin to mirror the tree among multiple nodes? How long to develop a web client and an adapter to manage the same build on multiple nodes? Obviuosly MacPorts core should never be used by users/clients, preferring MaPoD way to accomplish tasks. Back to the ground, there is much effort to spend and many issues to solve; first of all: how should MaPoD be launched, with whose privileges and permissions? Which technology should be used to develop all this stuff? Obj-C or C++ would be either good choices, once a good threading model has been decided (NSThread in 10.5 is a slightly forced choice). What about dependencies overlap? To respect decoupling how should MaPoD interface expose its own services? Stream/Socket interface? -- // Et quid amabo nisi quod rerum enigma est?

5 5

Re: [35247] trunk/dports/net/heimdal/Portfile
by Rainer Müller 22 Mar '08

22 Mar '08

landonf(a)macports.org wrote: > Revision: 35247 > http://trac.macosforge.org/projects/macports/changeset/35247 > Author: landonf(a)macports.org > Date: 2008-03-21 21:45:53 -0700 (Fri, 21 Mar 2008) > > Log Message: > ----------- > Put heimdal in a seperate prefix. No other ports depend on it, it conflicts with the system kerberos. > Shame, since it's so much nicer than the included MIT kerberos. This port needs destroot.violate_mtree yes as it now installs outside the usual mtree layout. Rainer

1 0

Re: Guidance needed for fixing gnome
by Thomas Reifferscheid 21 Mar '08

21 Mar '08

I made some progress. All the details are in Ticket 14729 [1]. Next thing is to do it with a portgroup. Do you think we can use it 1:1? [1]: http://trac.macosforge.org/projects/macports/ticket/14729 Randall Wood wrote: > On Thu, Mar 20, 2008 at 9:48 PM, Thomas Reifferscheid > <reiffert(a)macports.org> wrote: > >> Hi, >> >> please help me to improve the gnome situation and validate Ticket 14729 [1] >> to be correct. >> >> How should we proceed here? >> > > I think that the best (long term) way to succeed would be to create a > gnome portgroup that provides port with some generic mechanism to > discover the schema files that need installation and do it > auto-magically. >

1 0