Re: [Fink-devel] Re: fink cocoa tool

2006-01-07 Thread Koen van der Drift
Thanks for all the input. Give me a couple of days, and I'll see what I can do :) - Koen. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes s

Re: [Fink-devel] Re: fink cocoa tool

2006-01-07 Thread Kevin Horton
On 7 Jan 2006, at 16:44, Koen van der Drift wrote: I now have an unpolished working version that can load and edit info files and validate the info and corresponding .deb file. Just thinking aloud about more possibilites. Probably a cvs commit button. And I guess also a build/rebuild button

[Fink-devel] Re: Re: fink cocoa tool

2006-01-07 Thread Rogue Marechal
On Sat, 07 Jan 2006 16:44:41 -0500, Koen van der Drift wrote: > I now have an unpolished working version that can load and edit info > files and validate the info and corresponding .deb file. > > Just thinking aloud about more possibilites. Probably a cvs commit > button. And I guess also a b

Re: [Fink-devel] Re: fink cocoa tool

2006-01-07 Thread Koen van der Drift
On Jan 6, 2006, at 1:22 PM, Rogue Marechal wrote: Hi - I would definitely be interested in such a tool and more than happy to test. I now have an unpolished working version that can load and edit info files and validate the info and corresponding .deb file. Just thinking aloud about mor

[Fink-devel] Re: dists/10.4-transitional/unstable/main/finkinfo/gnome gtkmm2.info,1.2,1.3 librsvg2-mozilla.info,1.4,1.5 librsvg2.info,1.7,1.8 gnopernicus.info,1.4,1.5

2006-01-07 Thread Martin Costabel
Daniel Macks wrote: Update of /cvsroot/fink/dists/10.4-transitional/unstable/main/finkinfo/gnome In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv6381/10.4-transitional/unstable/main/finkinfo/gnome Modified Files: gtkmm2.info librsvg2-mozilla.info librsvg2.info gnopernicus.info Log Mes

Re: [Fink-devel] Re: Use of explicit interpretters in packaging scripts

2006-01-07 Thread Trevor Harmon
On Jan 5, 2006, at 7:07 PM, Chris Zubrzycki wrote: I am against this. If policy says the -e is needed, and a package doesn't, it's a bug. But there is no policy on this; at least, I couldn't find any in the packaging documentation. And even if there were, wouldn't it be easier to enforce