Re: [Fink-devel] Apple's X11

[Chris Dolan]

On Tuesday, January 7, 2003, at 01:44  PM, Ben Hines wrote:


The user install download link at 
http://www.apple.com/macosx/x11/download/ is broken currently. The SDK 
posted there won't help anyone, its just libraries and headers.

For those who want to try it out later, when the download works.

dpkg -r --force-depends xfree86-base
dpkg -r --force-depends xfree86-base-shlibs
http://www.apple.com/macosx/x11/  >
http://www.apple.com/macosx/x11/download/  >
fink install system-xfree86

Hopefully it'll work, dont have the full installer from apple yet.

-Ben

Worked great for me.  Thank, Ben.

Chris



---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] New Apple's X11

[Chris Dolan]

On Tuesday, January 7, 2003, at 02:49  PM, Xavier HUMBERT wrote:


Apple is about to relase a X11 environment for Jaguar. Seems promising,
with tight integration within Aqua. 

I think a "placeholder" package would be convenient. Has someone began
to do that ? If not, I'll try to do it.


You're about 10 posts behind, Xavier.  :-)

Let me take this opportunity to mention one little complication I found 
a worked around: Apple's .pkg install doesn't overwrite your existing 
.xinitrc (a good thing, I think) so you need to add "exec quartz-wm" 
manually to get their WM.

Chris



---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] perl 5.8 thoughts and testing

[Chris Dolan]

Sorry to join this discussion late...

On Friday, January 10, 2003, at 09:49  PM, Benjamin Reed wrote:


So the subject of perl 5.8 came up again on #fink, and I started 
taking a look at what we had.  Chris Dolan put together a great 
package for perl 5.8, but it has one problem -- it still puts 
everything in /sw/lib/perl5 just like our 5.6 packages.  The problem 
is perl 5.6 modules are not binary-compatible with perl 5.8, and 
having it put things in the same place makes it very difficult to 
determine what needs to be upgraded and what doesn't.

No, that's not right at all.  As I discussed with rangerrick on the 
submission tracker, Perl already HAS a standard for dealing with binary 
incompatible modules.  Apple stupidly overrode that mechanism and we've 
been dealing with it ever since.

By default, Perl creates a 5.6.0 and site_perl/5.6.0 or 5.8.0 and 
site_perl/5.8.0 directory beneath the lib/perl5 dir.  The .info file I 
created last summer(?) did exactly that.  It had several other flaws, 
but incompatibility with the 5.6.0 distro was not one of them.  Just 
try that .info file and you'll see.

The solution I came up with was to make the new perl install to 
/sw/lib/perl directory instead.  On top of that, I've changed things 
around so that we are using another handy feature of recent perl 
versions -- a "vendor" tree, that allows us to make a separate 
directory for fink-installed packages (as compared to packages that 
joe blow installs on the command-line with CPAN).  This will make 
diagnosing problems easier in the long-run, because packages that are 
installed by end-users on their own will be compartmentalized away 
from supported, official fink perl modules.  We could even have fink 
warn if there's any files in site_lib at all.

With the exception of the /sw/lib/perl dir (no! it should be 
/sw/lib/perl5!), this is good, and is very similar to what I advocated 
to rangerrick.  We should think carefully about where we want the 
user-installed packages to go.  In /sw?  in /usr/local?  Somewhere else?

So what we end up with is:

- old perl modules:
  /sw/lib/perl5


Yes.


- official stuff that comes with perl:
  /sw/lib/perl/5.8(/darwin)?


No.  /usr/lib/perl5/5.8.0{,/darwin} as per the perl default


- stuff that's installed by users in the fink tree (bad!)
  /sw/lib/perl/5.8/site_perl(/darwin)?


/usr/lib/perl5/site_perl/5.8.0


- stuff that's installed by fink packages:
  /sw/lib/perl/5.8/vendor_perl(/darwin)?


OK, how about /sw/lib/perl5/fink_perl/5.8.0


I've made a preliminary patch to fink that looks for /sw/lib/perl and 
/sw/bin/perl.  If they exist, they use the perl -V:vendor* variables 
to determine where perl modules should go (in case future fink perls 
move things around a bit).

The lib/perl/5.8 lets us separate things out for future binary 
incompatibilities, as well.

Well *at least* it should be 5.8.0, not 5.8.


As far as an upgrade path, the biggest issue is determining how to 
make sure that things get upgraded as soon as perl is upgraded.

The actual upgrade process should be easy, we would do something like:

  find /sw/lib/perl5 -type f | xargs dpkg -S | awk -F: '{ print $1 }' 
| sort | uniq

...and take the output of that as the list of things that need 
rebuilding.

Oh, I guess add "| grep -v fink" to that.  

One of the biggest issues to handle will be packages that have to do 
their own thing in info files.  There are a number of perl modules 
that do "perl Makefile.PL blah blah" rather than use "Type: perl", 
which will obviously have the wrong path and will be unavailable to 
perl 5.8 (since 5.8 is now configured to *not* look in /sw/lib/perl5 
to avoid conflicts).

So in short, it appears the technical part is going to be easier than 
it looked at first, but the upgrade path is going to be difficult to 
coordinate.  Perhaps it would be best to do something like this:
>

The perl package has a pre-install script that checks /sw/lib/perl5 to 
see if there's anything left.  If there is, it bombs, and points you 
at a "upgrade-perl-modules.sh" script that will do everything at once. 
 Once it's been done, future perl package releases would work just 
fine.

Does that make sense?


Hmm, no.  I think that perl 5.6.0 and 5.8.0 should happily coexist.  
That's the way it works on every unix platform except OSX.  Just 
because Apple screwed this up doesn't mean we should, too.

I, for example, run 5.6.0 with mod_perl (since Apple's mod_perl distro 
is hard-coded to their 5.6.0 release) and 5.8.0 for everything else.  
There is absolutely no need to make the users change their 5.6.0 setup 
to get 5.8.0 functionality.

Chris



---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] perl 5.8 thoughts and testing

[Chris Dolan]

On Sunday, January 12, 2003, at 12:49  PM, David R. Morrison wrote:


A couple of comments on this thread:

1) Fred Sanchez wrote a revised darwin.sh for perl in the fall, which 
was
accepted into the perl tree.  I believe that it essentially implements
what Chris did.  We should follow it.  (Links to the document were in 
my
previous post.)

Cool, I didn't know about Fred's work.  I'll have to look at that.


2) By convention, the user-modifiable portion of the Fink tree is 
/sw/etc.
So I think we should create /sw/etc/perl/5.6.0 and /sw/etc/perl/5.8.0 
and
symlink them back into the /sw/lib/perl trees that we are making.  That
way perl finds them, but users only write to /sw/etc.

I agree with Randall that this is not a good idea.  While it may differ 
from standard perl, I prefer what I stated earlier:
  /sw/lib/perl5/$version/- core perl modules
  /sw/lib/perl5/fink_perl/$version/  - fink-installed perl modules
  /sw/lib/perl5/site_perl/$version/  - user-installed perl modules

This has the advantage that directory heirarchy for the core and user 
perl modules are exactly as they would be on Linux, BSD, etc.  The 
fink_perl would be the exception from the norm, but IMO, that's OK 
because fink IS the exception from the norm.

However, I will happily defer to better ideas from Randall.  :-)

3) We are going to need separate Fink packages for 5.6 perl modules and
5.8 perl modules.  We are going to need a way to build a 5.6 perl 
module
when 5.8 is installed, and vice versa.  Seems to me that we'll probably
have binaries called /sw/bin/perl56 and /sw/bin/perl58, and that those
will be called by name when the perl module is compiled.  (So these
packages may have "BuildDepends: perl56" or "BuildDepends: perl58".)

No, as Randall said, the default perl install already creates these 
with the full version number.  The one questionable thing is whether 
/sw/bin/perl should be created or not.  IMO, it should be like ccache: 
it only overwrites the big one (cc in cccache's case, perl in 
perl5.8.0's case) if the user agrees.  And, to preempt another possible 
discussion, /usr/bin/perl should *not* be touched at all, except by the 
user him/herself.  We agreed on that latter point many months back.

You might have a "jumbo" perl mod package for Fink which built both a 
5.6
version and a 5.8 version, so that whichever perl the user was using,
he or she got the correctly compiled module.

Maybe...  But that would depend on both and removal would get nasty.  
It would have to be a virtual package which simply depended on both the 
5.6.0 and 5.8.0 versions of the module.

In general, though, I think that we may simply have to have multiple 
versions of every module.  I don't think that's entirely a bad thing.  
Presumably, it will be minimal work for a maintainer to do both, since 
for most modules the only change will be to replace some 6s with some 
8s.  And if the module does change more significantly than that, well, 
then we did indeed need to have multiple versions of the .info file.

Or perhaps there should be a way for .info files to depend on each 
other?  *cringe*

Chris



---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] perl 5.8 thoughts and testing

[Chris Dolan]

On Sunday, January 12, 2003, at 09:33  PM, Kyle Moffett wrote:

On Sunday, Jan 12, 2003, at 20:34 US/Eastern, Carsten Klapp wrote:


Hi All,

Aside from these directory name issues I have a start on some perl 
5.8 info files based on a perl 5.8  info file from the submission 
tracker. The modules I found so far which need to be recompiled 
simply have a new info file identical to the old one but with a 
build/depends on the new perl. Take a look in the 
experimental/carstenklapp cvs dir.
Some modules are 100% perl code, and for the most part they can be 
built and installed in the 5.6.0 and 5.8.0 directories without 
changes. (IE only install destination command is changed) For these 
modules we just copy the files between 5.6.0 and 5.8.0 dirs.

I have a few questions:
 * How will this work with dependency tracking?  Will those pure-perl 
modules depend
   only on perl >= 5.6.0 instead of perl = 5.6.0 and perl = 5.8.0?
 * What happens when 5.8.1 comes out?  Will those be multi-version 
packages be revised
   to add files to another version dir?  What if the 5.8.1 revision of 
a module ceases
   to support 5.6.0?  (not likely, I admit)
 * How do I remove the 5.6.0 cruft someday without nuking my 5.8.0 
modules?
 * What if a future version of a given module switches from pure-perl 
to XS for speed's
   sake?  I guess the splitoff mechanism supports this point...

It is my understanding that not all perl modules need to be 
recompiled for 5.8, only binary XS modules. (I really don't know what 
XS means and I have no idea how to tell if a module works or not 
without recompiling unless there is an error using it). Anyway this 
would mean a lot of the perl mods in fink should still work with the 
new perl without needing a recompile.
Any module that compiles C or C++ code should be considered XS (There 
may be one or two that aren't, but those are the minority)  Otherwise, 
unless specified by the module author, it should work on both > versions.


As reported by "perldoc perlhist", there have been 4 binary 
incompatible Perl releases since July 1998: 5.005 (7/1998), 5.6.0 
(3/2000), 5.6.1 (4/2001), and 5.8.0 (7/2002).  I think one release per 
year is not too steep for module maintainers (flame me if this is naive 
-- I only maintain one package right now!).  Especially if we start 
dropping the old ones, or decide to not support 5.6.1.

Chris



---
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Spam on this list...

[Chris Dolan]

If my vote counts, mark it down as an emphatic no.  Making things more 
cumbersome for humans is not a good way to deal with spam.  I use 
SpamAssassin on my mailserver and the *only* Fink spam I've ever seen 
is when someone on the list has hit reply-all on a spam message.  
Pressure on SF.net is a much better solution.

Chris

On Monday, June 9, 2003, at 05:25  PM, Max Horn wrote:

Yo folks,

sadly we are getting more and more spam on this list. I have to wonder 
if we after all should make it "moderated" like fink-users, too (that 
essentially means that only members can post to the list; non-member 
will have to be approved by the list admin).
I am not exactly fond of the idea, but until SF.net puts their spam 
filters in place (they are working on it, but I have no clue when they 
will be available), that's the best thing I can do about the spam. 
What do people think? Can we still accept the spam level we have, or 
is it too much?

It's not that I am eager to do this, but I'd like to at least know 
what people think.

Cheers,

Max



---
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] new user branch

[Chris Dolan]

Am I missing something?

I don't understand why you have a Pass field at all.  Default passwords  
are evil, and are an obvious route for attackers.  Perhaps Pass should  
be a flag to indicate that Fink should prompt the user for a password?   
That's still rotten, IMHO, but infinitely better than having default  
passwords.

The usual procedure is to use "*" as the crypted password for daemon  
accounts, indicating that nobody may log in using that account  
directly.  IIRC, a blank password crypt usually means that no password  
is required for login, yes?  That would be very bad.

Chris

On Monday, August 11, 2003, at 09:36  AM, TheSin wrote:

I have started a new fink branch to auto add and remove users/groups.   
I'd like to vote on the field style for this.

Type 1:
User: <<
Name: postfix
Desc: Postfix User
Pass: password
Shell: /usr/bin/false
Home: %p/var/mail
<<
Group: <<
Name: postfix
Desc: SMTP group
Pass: password
<<
or type 2:

User: postfix:Postfix User:password:/usr/bin/false:%p/var/mail
Group: postfix:SMTP Group:password
in both cases password can be left out to auto gen one.  in the first  
case just leave the whole tag out in the second leave it blank so user  
would be

name:desc::shell:home

shell can also be left out and will default to /usr/bin/false



---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/ 
direct;at.aspnet_072303_01/01
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
[EMAIL PROTECTED], 294-7900, 211 S Paterson, Madison WI 53703


---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] user and group handling

[Chris Dolan]

On Monday, August 11, 2003, at 02:17  PM, TheSin wrote:

also there will no longer be a random gen password, it will be a crypt 
pass or it will be blank which will mean a locked user which will be 
most common.
Sorry to beat this point to death, but I feel quite strongly that there 
should never be a password on any daemon accounts.  Even an encrypted 
or hashed password is still a default password, and a default password 
is a backdoor for entry.

Because you can always sudo from a user account, or simply su from the 
root account, there should never be a need for a Fink package to supply 
a password or even prompt for one.

If you can think of a case where a password on an autogenerated account 
would ever be needed, please let me know and I'll concede the point.  
But I can't think of a time a password has been needed for a non-user 
account on any Unix system I've ever administered.

Chris



---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Re: Fink-devel digest, Vol 1 #1188 - 12 msgs

[Chris Dolan]

On Saturday, October 11, 2003, at 11:51  PM, Kaben Nanlohy wrote:

On Sat, 11 Oct 2003, Benjamin Reed wrote:

User-mode fink is useful to a very small part of the fink population,
Not so. At work I lack root on many of the *nix boxes I use, so I
regularly build and install the stuff I need in ~/local.  A package
manager like fink would be a godsend for this purpose.
I have not yet heard anyone mention the best reason for user-mode fink: 
trust problems.  Do you really want to be running a ton of shell 
scripts and makefiles as root?  Not me.  I'd rather compile and build 
.debs as a regular user and only do the final install step as root.

Chris



---
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Re: Fink-devel digest, Vol 1 #1188 - 12 msgs

[Chris Dolan]

Very well stated, Benjamin.  I agree with you completely.
Chris
On Sunday, October 12, 2003, at 11:49  AM, Benjamin Reed wrote:

Chris Dolan wrote:

I have not yet heard anyone mention the best reason for user-mode 
fink: trust problems.  Do you really want to be running a ton of 
shell scripts and makefiles as root?  Not me.  I'd rather compile and 
build .debs as a regular user and only do the final install step as 
root.
Sure, I'm not arguing that.  I'm arguing the need to do it 
immediately.  I agree it's safer to not do anything as root.  I 
disagree that it's as easy as people are making it sound.  If it was, 
we'd have it already.

When I say "user-mode fink is useful to a very small part of the fink 
population", what I mean is it's really only desired by people who are 
both sysadmins and users of fink.

It's not like fink is making you be root for the day-to-day use of 
fink packages, it's only for installing new software, which for 99% of 
fink's users, is a fairly rare occasion.  I agree it's a nice-to-have, 
I disagree it's worth rushing into it without thinking about all the 
ways it affects how the fink packaging process works.

There's only so many times I can say "I don't have anything against it 
but now isn't the time."  If you want to implement it, do it.  Don't 
just make a patch and say "it works for me."  Build a lot of packages 
and see what breaks.  Find out *why* it breaks, and find out how to 
fix that.  In a month, when we have a panther bindist and things have 
slowed a bit, come back and show the code and make your case.

2 weeks before the panther release is not the time to come to us and 
say "oh, by the way, I think we should make sweeping changes to the 
way fink builds and installs packages."

=)

--
Benjamin Reed a.k.a. Ranger Rick -- http://ranger.befunk.com/
gpg: 6401 D02A A35F 55E9 D7DD  71C5 52EF A366 D3F6 65FE
"Emacs is a nice operating system, but I prefer UNIX."
  -- Tom Christiansen



---
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] User mode Fink

[Chris Dolan]

On Sunday, October 12, 2003, at 08:25  PM, Greg Novak wrote:

--- Chris Dolan <[EMAIL PROTECTED]> wrote:
I have not yet heard anyone mention the best reason for user-mode 
fink:
trust problems.  Do you really want to be running a ton of shell 
scripts
and makefiles as root?  Not me.  I'd rather compile and build .debs 
as a
regular user and only do the final install step as root.
I don't think this holds water.  If you don't trust the people writing 
the
scripts, what's to stop them from patching the software to do something
malicious while it's building (as a regular user) and then doing nasty
stuff after the software is installed as root?
It's not just maliciousness, it's accidents too -- perhaps even more 
the latter!  Take for example the recent cases found on the list of 
packages that accidentally did some of their "make install" into /sw 
instead of the /sw/src/... sandbox because of a %p instead of %i.  
Building as non-root would block this from wreaking havoc.

Ideally, I want to do the highly unpredictable "build" step as me, and 
the much more predictable "install" from .deb as root.  That's similar 
to how I install manually: ./configure; make; sudo make install, but 
even better since even make install is non-root.  That's similar to how 
RPMs are built for RedHat.  Even Perl's CPANPLUS is moving in that 
direction, I think.  You just don't need root's power to do the build, 
so why risk accidents?  All it takes is one instance of the following 
to to ruin your day when you're root.

clean:
rm -r *.o build /* *~
Chris



---
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Still >500 packages not moved from 10.2 tree, need help

[Chris Dolan]

I maintain three of those (skycal, socat and sswf) but am still on 
10.2.8.  I'll be happy to resume maintainership when I upgrade, but in 
the meantime porting assistance would be appreciated.  socat and skycal 
are pretty simple.

Chris

On Monday, April 19, 2004, at 06:46  PM, Ben Hines wrote:

Still > 500 pkgs show 'not moved' from 10.2-gcc3.3 to 10.3. A number 
of these are obsolete, but many are not. Anyone with commit access 
feel free to move over anything that works. (I usually start them out 
in the 10.3 tree with the new filename format, but be sure to fix any 
references to the patch file in the info) If a maintainer no longer 
desires to maintain a package they can remove their names from the 
maintainer line once it is in the 10.3 tree, but the package should 
still be moved. (with a 'None' maintainer)

list:

http://homepage.mac.com/bhines/finknotmoved.html

-Ben

--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, 211 S Paterson Suite 260, Madison WI 53703


PGP.sig
Description: This is a digitally signed message part

[Fink-devel] Shared binary-darwin-powerpc directories

[Chris Dolan]

I'm hoping someone else has already solved this problem more elegantly  
that I did...

Several machines in my office run Fink.  I want to be able to share  
.deb files that any of machine builds to save compile time on other  
machines.

My hack solution so far:
 * make directories  
{unstable,stable,local}/{main,crypto}/binary-darwin-powerpc on a shared  
volume (SMB in my case, but it shouldn't matter)
 * copy any .debs built so far on the local disk to the shared volume
 * delete local directories  
/sw/fink/dists/{unstable,stable,local}/{main,crypto}/binary-darwin- 
powerpc and replace with symlinks to the above directories
 * alias fink to "fixupdebs.pl ; /sw/bin/fink"
where fixupdebs.pl is a very short script that repairs the symlinks in  
/sw/fink/debs (it recurses through the shared volume looking for .deb  
files and symlinks them if a link does not already exist)

What this accomplishes:
 * any freshly built .deb files get written to the shared volume in the  
appropriate binary-darwin-powerpc directories
 * any instance of fink rebuilds the local /sw/fink/debs dir before  
running.  This is needed so you can know if anyone else has built  
something since you last ran fink.  Note that in my case, the debs dir  
cannot be stored on the server because OSX can't build symlinks on SMB  
volumes.

Thoughts?
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, 211 S Paterson Suite 260, Madison WI 53703


PGP.sig
Description: This is a digitally signed message part

Re: [Fink-devel] validating BuildDependsOnly

[Chris Dolan]

 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, 211 S Paterson Suite 260, Madison WI 53703


PGP.sig
Description: This is a digitally signed message part

Re: [Fink-devel] ignoring /usr/local, was: Re: [Fink-users] Problems compiling libwmf-0.2.8.2-4

[Chris Dolan]

On Oct 3, 2004, at 3:50 PM, Martin Costabel wrote:
Kevin Horton wrote:
[]
I agree 100% that the default behavior should be to not touch 
/usr/local.  But, if I understand correctly, none of the Apple 
supplied software should be in /usr/local.  This would only be other 
user installed software.  If the fink team can't find a way to make 
Fink ignore /usr/local when building things, then an optional, user 
selectable behavior to automatically temporarily move /usr/local out 
of the way appears to be better than the current situation.
It seems a shame to throw out  a potentially useful improvement 
purely on philosophical grounds.  If this change truly could cause 
serious problems, then it is a bad idea.  But let's at least discuss 
what those problems could be before we throw the idea out.
There is no simple solution to this problem. Maybe none at all.
Moving /usr/local is a very bad solution for me, since that would break 
GPGMail while fink is running.  Plus, /usr/local/ is not the only 
problem.  User-installed files in /Library/Perl has similar issues 
since some Makefile.PL scripts check if modules are installed.


Could chroot help us out in this situation?  Could we mount /sw and 
/usr (and others?) somewhere and just access those dirs?  I'm sure this 
must have been discussed on fink-devel before...


Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, 313 W Beltline Hwy Suite 41, Madison WI 53713


PGP.sig
Description: This is a digitally signed message part

[Fink-devel] Specific version ranges

[Chris Dolan]

I'm working on XML::Xerces, a Perl module that interfaces with the 
Apache Xerces-C XML parsing library.  The Perl module is hard-coded to 
work against a specific version of the XML library.  That is, 
XML::Xerces 2.5.0.x works ONLY with Xerces-C 2.5.0.

What's the best way to express this in the .info?  What I'd like to say 
is:
  Depends: xerces-c (= 2.5.0-*)
or
  Depends: xerces-c (>= 2.5.0-1 && << 2.5.1-1)
or even
  Depends: xerces-c (2.5.0-1 <= %v << 2.5.1-1)
or
  Depends: xerces-c (>= 2.5.0-1), xerces-c (<< 2.5.1-1)
But I don't think any of those are valid syntax (it's hard to determine 
without actually trying them).

Is this possible with the current fink?  So far my best workaround has 
been to hardcode the version into the name of the parent library.  That 
is, I have xerces-c23.info and xml-xerces-c23-pm.info that are aligned 
on v2.3.0.

Is there a way I could use Conflicts to work around this?
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, 1435 E Main St, Madison WI 53703


PGP.sig
Description: This is a digitally signed message part

[Fink-devel] CompileScript no-op messages

[Chris Dolan]

When a package has nothing to compile, we are expected to include a 
CompileScript that does a no-op and returns a true value.  Maintainers 
usually implement this via something like "echo Nothing to compile", 
but there is a wide range of solutions for this.  I ran the following 
commands to get the full list:

egrep -hr CompileScript: /sw/fink/10.3/unstable/*/finkinfo | egrep -vi 
'make|build' | sort -u

Below is the list of all no-ops I gleaned from that output.  I propose 
that we standardize on
  CompileScript: /usr/bin/true
or the following reasons
  * less verbose (it's a no-op after all)
  * doesn't emit any unnecessary English text (in case 
internationalization matters here)

If the community does not support /usr/bin/true, then at very least we 
should standardize on agreed verbiage for the echo.

Chris
CompileScript: /usr/bin/true
CompileScript: echo
CompileScript: echo ""
CompileScript: echo "Compile phase: nothing to do."
CompileScript: echo "No Compile Script"
CompileScript: echo "No compile necessary"
CompileScript: echo "No compile needed"
CompileScript: echo "No compile needed."
CompileScript: echo "No compile script"
CompileScript: echo "No configuration or compilation necessary."
CompileScript: echo "Nothing is compiled in this section."
CompileScript: echo "Nothing to be done for compile"
CompileScript: echo "Nothing to be done."
CompileScript: echo "Nothing to compile"
CompileScript: echo "Nothing to compile."
CompileScript: echo "Nothing to compile..."
CompileScript: echo "Nothing to do ..."
CompileScript: echo "Nothing to do for Compile"
CompileScript: echo "Nothing to do for compile"
CompileScript: echo "Nothing to do in this section."
CompileScript: echo "Nothing to do"
CompileScript: echo "Nothing to do."
CompileScript: echo "Nothing to do..."
CompileScript: echo "Unpacking..."
CompileScript: echo "moving files..."
CompileScript: echo "no CompileScript needed"
CompileScript: echo "no compilation needed"
CompileScript: echo "no compile needed"
CompileScript: echo "no compile script "
CompileScript: echo "no compile script"
CompileScript: echo "no compile script"
CompileScript: echo "no compiling needed"
CompileScript: echo "none needed"
CompileScript: echo "none"
CompileScript: echo "nothing to compile ..."
CompileScript: echo "nothing to compile"
CompileScript: echo "nothing to do"
CompileScript: echo "we compile in the install phase"
CompileScript: echo 'No assembly required!'
CompileScript: echo 'nothing to compile'
CompileScript: echo No compilation necessary.
CompileScript: echo None
CompileScript: echo no compilation
CompileScript: echo none
CompileScript: true
CompileScript: true
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software 
(http://www.media-landscape.com/) and partners in the revolutionary 
Croquet project (http://www.opencroquet.org/)


PGP.sig
Description: This is a digitally signed message part

[Fink-devel] Handy script for looking up Perl module MD5s

[Chris Dolan]

Developers,
Below is a simple Perl script that I use to look up MD5 values for Perl 
module distributions on CPAN.  I thought others might find it useful, 
particularly when upgrading existing .info files.  I like to use this 
script because it fetches the CHECKSUMS file from the root CPAN server. 
 It depends on libwww-pm and file-slurp-pm.

Chris
---
Example:
% cat module-scandeps-pm.info
Package: module-scandeps-pm
Version: 0.51
Revision: 1
Source: mirror:cpan:authors/id/A/AU/AUTRIJUS/Module-ScanDeps-%v.tar.gz
Source-MD5: 5fc35c473d7d33818bc061c098fb5f6a
Type: perl
[snip]
% perl getmd5.pl module-scandeps-pm.info
Reading module-scandeps-pm.info
Retrieving http://www.cpan.org/authors/id/A/AU/AUTRIJUS/CHECKSUMS
Evaling http://www.cpan.org/authors/id/A/AU/AUTRIJUS/CHECKSUMS
Fetching record for Module-ScanDeps-0.51.tar.gz
Old MD5: 5fc35c473d7d33818bc061c098fb5f6a
New MD5: 5fc35c473d7d33818bc061c098fb5f6a
-
#!/usr/bin/perl -w
use strict;
use LWP::Simple qw(get);
use File::Slurp;
my $SERVER = "http://www.cpan.org/";;
my $file = shift || die "Syntax: $0 \n";
print "Reading $file\n";
$_ = read_file($file);
# extract .info fields as a hash.  Doesn't support multiline fields
my %info = /^([\w\-]+): *(.*)$/gm;
my $src = $info{Source};
$src =~ s/mirror:cpan:/$SERVER/;
$src =~ s/([^\/]*)$/CHECKSUMS/;
my $dist = $1;
$dist =~ s/%v/$info{Version}/g;
print "Retrieving $src\n";
my $cksum = get($src) || die "Failed\n";
print "Evaling $src\n";
eval $cksum;
($@ || !$cksum) && die "Failed\n";
print "Fetching record for $dist\n";
my $record = $cksum->{$dist} || die "Failed\n";
print "Old MD5: ".$info{"Source-MD5"}."\n";
print "New MD5: ".$record->{md5}."\n";
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software 
(http://www.media-landscape.com/) and partners in the revolutionary 
Croquet project (http://www.opencroquet.org/)


PGP.sig
Description: This is a digitally signed message part

Re: [Fink-devel] need some help with packaging

[Chris Dolan]

On Jan 17, 2005, at 5:42 PM, Chris Zubrzycki wrote:
On Jan 17, 2005, at 5:17 PM, Manuel Hendel wrote:
I'm trying to package pflogsumm for fink. The pflogsumm package just 
contains a perl script and a manpage, there is nothing to compile, 
just copy the the two files to the right place.
CompileScript: echo "Nothing to compile"
I recommend instead:
  CompileScript: /usr/bin/true
This avoids excess verbosity and makes localization easier.
See my earlier post on this topic:
  http://sourceforge.net/mailarchive/message.php?msg_id=10116957
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software 
(http://www.media-landscape.com/) and partners in the revolutionary 
Croquet project (http://www.opencroquet.org/)


PGP.sig
Description: This is a digitally signed message part

Re: [Fink-devel] Re: what's up with perl modules

[Chris Dolan]

On Jan 19, 2005, at 11:43 AM, Blair Zajac wrote:
Manuel Hendel wrote:
Shell I just add a line to the description which says that you have 
to install Date::Calc via cpan?
mhe


I would just take the time out to make a Dalc::Calc Fink module.
You will need to also create a package for Bit::Vector, and since 
Bit::Vector builds a shared library, you'll need to use an Info2 .info 
format to handle different Perl versions.  And because Date::Calc 
depends upon Bit::Vector, Date::Calc will also need to be an Info2 
.info format with package names like data-calc-pm581.

A good package to look at is test-data-pm.info, which has a similar 
dependency on a Perl package with a shared library.
Here's a first cut at date-calc-pm.info.  I've run out of time to do 
the rest (i.e. create carp-clan-pm.info and bit-vector-pm.info) but 
those others should be easier because they don't need the 
%type_pkg[perl] since they don't have XS modules.  If someone takes 
over my initial effort, please email me, and (of course) change the 
Maintainer line.

Chris
Info2: <<
Package: date-calc-pm%type_pkg[perl]
Version: 5.4
Revision: 1
Type: perl (5.8.0 5.8.1 5.8.4)
Description: Gregorian calendar date calculations
License: Artistic
Maintainer: Chris Dolan <[EMAIL PROTECTED]>
Homepage: http://search.cpan.org/dist/Date-Calc
Depends: perl%type_pkg[perl]-core, carp-clan-pm, bit-vector-pm
Source: mirror:cpan:authors/id/S/ST/STBEY/Date-Calc-%v.tgz
Source-MD5: 7ae34972694127e8f1c9a2af1c24585b
UpdatePOD: true
DocFiles: Artistic.txt CHANGES.txt CREDITS.txt MANIFEST README.txt
Splitoff: <<
 Package: %N-man
 Depends: %N (= %v-%r)
 Conflicts: %{Ni}580-man, %{Ni}581-man, %{Ni}584-man
 Replaces: %{Ni}580-man, %{Ni}581-man, %{Ni}584-man
 Files: share/man
 DocFiles: Artistic.txt CHANGES.txt CREDITS.txt MANIFEST README.txt
<<
<<

--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software 
(http://www.media-landscape.com/) and partners in the revolutionary 
Croquet project (http://www.opencroquet.org/)


PGP.sig
Description: This is a digitally signed message part

Re: [Fink-devel] Re: what's up with perl modules

[Chris Dolan]

Manuel Hendel wrote:
Shell I just add a line to the description which says that you have 
to install Date::Calc via cpan?
OK, never mind my previous email.  I've now built and submitted 
packages for carp-clan-pm, bit-vector-pm, and date-calc-pm.  Manuel, if 
you would be willing to download my .info files from the package 
tracker and try them out, I'd appreciate it.  Once these are accepted 
to Fink, you can simply add
  Depends: date-calc-pm580 | date-calc-pm581 | date-calc-pm584
to your package.

Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software 
(http://www.media-landscape.com/) and partners in the revolutionary 
Croquet project (http://www.opencroquet.org/)


PGP.sig
Description: This is a digitally signed message part

Re: [Fink-devel] Re: what's up with perl modules

[Chris Dolan]

On Jan 20, 2005, at 10:07 PM, Daniel Macks wrote:
On Thu, Jan 20, 2005 at 09:58:25PM -0600, Chris Dolan wrote:
...  Once these are accepted
to Fink, you can simply add
  Depends: date-calc-pm580 | date-calc-pm581 | date-calc-pm584
to your package.
Seems like that's just asking for trouble. If I have two perl versions
installed and date-calc-pmXXX in only one of them, how do you know the
perl your pkg happens to use is the one that has Date::Calc? You are
(re)creating a "date-calc-pm placeholder" package, a practice we
abolished (in practice, and by at-least-unofficial policy).
Good point.  I had not realized that pflogsumm was a perl program 
itself.  In that case, it MUST be %type_pkg[perl] versioned to sync 
with date-calc-pm%type_pkg[perl].  I should have realized that...

This does raise an interesting (but irrelevent to pflogsumm) question.  
How should a non-perl package depend on a versioned perl package?  Does 
the non-perl package need to depend on a particular version of perl, 
say 5.8.1?  Does it then need to explicitly call perl5.8.1 when 
invoking its dependent libraries?

Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software 
(http://www.media-landscape.com/) and partners in the revolutionary 
Croquet project (http://www.opencroquet.org/)


PGP.sig
Description: This is a digitally signed message part

[Fink-devel] Perl variants -- problem and proposed solution

[Chris Dolan]

--- The problem ---
When a perl module is declared a variant, the .info file contains a 
line like this:

  Type: perl (5.8.0 5.8.1)
The following questions arise for new modules:
 * Which versions should I include in the list?
 * When should the list change?  And who should change them?
I assert that the former question is often answered by cargo cult: 
maintainers just copy the choices made by other maintainers.  I did a 
quick test to see what choices people have made so far:

 % cd /sw/fink/10.3/unstable/main/finkinfo/libs/perlmods
 % egrep -rh 'Type: *perl *\(' . | sort -u
 % egrep -rh 'Type: *perl' . | sort -u
Type: perl
Type: perl (5.6.0 5.6.1 5.8.0 5.8.1 5.8.4 5.8.5)
Type: perl (5.6.0 5.6.1 5.8.0 5.8.1 5.8.4)
Type: perl (5.6.0 5.8.0 5.8.1 5.8.4)
Type: perl (5.6.0 5.8.0 5.8.1)
Type: perl (5.6.0 5.8.1)
Type: perl (5.8.0 5.8.1 5.8.4)
Type: perl (5.8.0 5.8.1)
Type: perl (5.8.1 5.8.4 5.8.6)
Type: perl (5.8.1 5.8.4)
Type: perl (5.8.1)
Type: perl 5.6.0
Type: perl 5.8.0
Type: perl 5.8.1
Type: perl(5.6.0 5.6.1 5.8.0 5.8.1 5.8.4 5.8.5)
Type: perl(5.6.0 5.8.0 5.8.1 5.8.4)
Type: perl(5.6.0)
Type: perl(5.6.1 5.8.0 5.8.1 5.8.4)
Type: perl(5.8.1)
Some of these are clearly out of date.  For example, Fink doesn't even 
support Perl 5.8.5, and we don't support Perl 5.6.1 in 10.3 (at least 
there isn't a package for it that I can find).  Most are missing 5.8.6, 
which is in unstable right now.

--- Proposed solution ---
I propose that we add a new percent expansion that looks like 
%{allperlversions} [I'm open to alternate suggestions] that expands to 
the list of all perl versions that Fink currently supports.  This would 
let maintainers implicitly declare, "I expect that this module should 
work on any version of Perl".  When new versions of Perl get added to 
Fink, no perlmods need to be updated.  On the other hand, if a 
maintainer knows that a module only works for certain versions of Perl, 
that maintainer can set an explicit list just as we do now.

If this is deemed to be good idea, I'd be happy to write the patch.
--- Switchover process ---
A nice feature of this solution is that no existing package will break. 
 Maintainers can switch over to using %{allperlversions} at their 
leisure.

--- Open questions ---
The major open question is how %{allperlversions} gets populated.  Is 
it hardcoded into PkgVersion.pm?  Or does Fink scan the package list 
for perl5xx-core and system-perl5xx at runtime?

Chris
--
Chris Dolan, Software Developer, www.chrisdolan.net
Public key: http://www.chrisdolan.net/public.key


PGP.sig
Description: This is a digitally signed message part

Re: [Fink-devel] Perl variants -- problem and proposed solution

[Chris Dolan]

Good points.  I withdraw the proposal.
Daniel, do you recommend that non-variant Perl modules must also be 
tested against all Fink-supported versions of Perl?

Chris
On Feb 14, 2005, at 9:05 AM, Daniel Macks wrote:
On Sat, Feb 12, 2005 at 09:34:59PM -0600, Chris Dolan wrote:
--- The problem ---
When a perl module is declared a variant, the .info file contains a
line like this:
  Type: perl (5.8.0 5.8.1)
The following questions arise for new modules:
 * Which versions should I include in the list?
 * When should the list change?  And who should change them?
[maintainers list all kinds of combinations]
Some of these are clearly out of date.  For example, Fink doesn't even
support Perl 5.8.5, and we don't support Perl 5.6.1 in 10.3 (at least
there isn't a package for it that I can find).  Most are missing 
5.8.6,
which is in unstable right now.

--- Proposed solution ---
I propose that we add a new percent expansion that looks like
%{allperlversions} [I'm open to alternate suggestions] that expands to
the list of all perl versions that Fink currently supports.  This 
would
let maintainers implicitly declare, "I expect that this module should
work on any version of Perl".  When new versions of Perl get added to
Fink, no perlmods need to be updated.  On the other hand, if a
maintainer knows that a module only works for certain versions of 
Perl,
that maintainer can set an explicit list just as we do now.
In an ideal world, people actually *test* packages, at least that they
compile, before committing them. Making new perl-variants
automatically spring into existence with the new perl is added removes
that step. Also, autogenerating the Type:perl subtype list does not
remove the burden of manually editing other parts of the .info where
these values are explicitly enumerated. That's because perl-variant
modules need to have the concept of exclusivity for the -man
splitoff. You'd have to somehow encode that into the Conflicts and
Replaces fields.
  Conflicts: ${Ni}%{all-versions}-man
but somehow have that be expanded as a comma distribution operator.
That means each pkg has to know the full subtype list, something it
currently does not IIRC. That's gonna be quite a feat, since there's
no guarantee that all variants are contained in the same .info.
But actually, it's not "all versions of it" where "it" is the -man
splitoff: the multiple types are an attribute of the parent package,
and there is only one variant of the splitoff in each one. So you'd
need the splitoff to inherit the parent's subtype list--no big deal if
the parent already knows it.
Programming challenge aside, that means adding a new perlXXX pkg,
which autovivifies all these perlmod packages causes massive policy
breakage. Conflicts is hardcoded into the .deb, so the presence or
absense of different perlXXX packages will cause different users to
get different Conflicts for a given pkg-version at different times. A
given pkg-version *must* have a static replaces/conflicts field, so I
don't think there's any getting around having to manually enter the
perl subtypes into those fields. Having Type autogenerated but
Conflicts/Replaces means adding a new perlXXX-core will create a
complete collection of broken *-pmXXX packages until all their C/R are
manually adjusted.
vasi and I actually discussed this a few nights ago on #fink, and
buried the idea even further, so I may as well keep typing...
We really *don't* want Conflicts to give exclusivity among "all
currently-exising subtypes", but actually among all subtypes that have
*ever* existed for that pkg. We don't want to carry all obsolete
perlXXX-core indefinitely, but we also don't want to break upgrade
paths. Say I have perlXXX and foo-pmXXX (and -man) installed.  Now a
new perlXXY is added and perlXXX is removed from the pkg repository; I
install perlXXY. Thanks to 'fink -b', I don't have to rebuild
everyhting myself: I just download the prebuilt foo-pmXXY, but if that
.deb came from a machine without perlXXX, its -man contains no
Conflicts for the one I have installed.
The major open question is how %{allperlversions} gets populated.  Is
it hardcoded into PkgVersion.pm?  Or does Fink scan the package list
for perl5xx-core and system-perl5xx at runtime?
Hardcoded into fink core means one has to coordinate a new fink
release every time one wants to alter the set of perlXXX-core packages
we have. That's a bit too much Central Party package management for my
taste, and no reason to add yet another user and fink-release
headache. Runtime perlXXX-core determination is broken by policy and
function.
dan
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software 
(http://www.media-landscape.com/) and partners in the revolutionary 
Croquet project (http://www.opencroquet.org/)


PGP.sig
Description: This is a digitally signed message part

[Fink-devel] Accessibility

[Chris Dolan]

I'm currently helping a local blind/deaf user get started with Fink.  
We're hoping to port the Linux BRLTTY braille translator to OSX, but 
this is new territory for me and this user is new to OSX, so we're 
learning things like the cmdline installer for DMGs, etc.  Has anyone 
else explored this territory?  Apple's accessibility page 
(http://www.apple.com/accessibility/) is interesting, but not very 
helpful.

Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software 
(http://www.media-landscape.com/) and partners in the revolutionary 
Croquet project (http://www.opencroquet.org/)


PGP.sig
Description: This is a digitally signed message part

Re: [Fink-devel] Accessibility

[Chris Dolan]

On Feb 14, 2005, at 11:04 AM, Chris Dolan wrote:
I'm currently helping a local blind/deaf user get started with Fink.  
We're hoping to port the Linux BRLTTY braille translator to OSX, but 
this is new territory for me and this user is new to OSX, so we're 
learning things like the cmdline installer for DMGs, etc.  Has anyone 
else explored this territory?  Apple's accessibility page 
(http://www.apple.com/accessibility/) is interesting, but not very 
helpful.

Chris
The response to this was not quite deafening, so let me try a different 
tack...

I helped a blind/deaf user get started with Fink, and he loves it.  He 
wrote up a mini-HOWTO for other people to get started with Fink without 
a mouse or monitor.  I'm looking for a volunteer to help me get that 
document formatted for the website.

Thanks,
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software 
(http://www.media-landscape.com/) and partners in the revolutionary 
Croquet project (http://www.opencroquet.org/)


PGP.sig
Description: This is a digitally signed message part

Re: [Fink-devel] Accessibility

[Chris Dolan]

Cool, thanks for the enthusiastic replies, all!  I'll coordinate with 
Alexander to get the instructions posted.  In the meantime, could I get 
another volunteer with a fresh Mac to try out the instructions and see 
if they work as expected?  The HOWTO is inline below.

Note: I didn't write this or even try it yet (don't have a clean mac 
handy right now...) but I have a few comments:
  * The usage of "ls -F | cat" is to avoid the columnar output from ls.
  * The instructions describe how to install Fink from source.  There's 
probably a way to do a DMG install with the "installer" command, but I 
haven't tried that yet.

Chris
INSTALLING FINK FROM THE COMMAND LINE
You will need to enable Remote Login from the GUI. Then you can use the
username and password you have established to ssh from another system on
your network.
OSX is installed without the Xcode developer tools. Fink needs
those, so your
first order of business is to install them. Insert Mac OSX Install Disk
1. then type the following commands. The "ls -F |cat" commands are
convenient to see what you are doing and to copy file and directory
names.
cd /Volumes
ls -F |cat
cd "Mac OS X Install Disc 1"
ls -F |cat
cd "Xcode Tools"
ls -F |cat
sudo installer -verbose -pkg Developer.mpkg -target /
A lot of stuff will flash by on the screen. When the prompt returns do:
cd
On your other system, go to http://fink.sourceforge.net/ and download
fink-0.7.1-full.tar.gz, or whatever the latest release is. Copy this to
your home directory on the Mac using scp. then
tar xfz fink-0.7.1-full.tar.gz
cd fink-0.7.1-full
./bootstrap.sh
Follow the onscreen directions. In most cases you will want to accept
the default, but you may want to specify your continent and the closest
mirror.
Fink will download, compile and install a basic system. This may take a
while. When it is done, type
source /sw/bin/init.sh
Now you may want to install some of your favorite
applications. For example:
sudo -s
apt-get update
apt-get install nano
apt-get install lynx
apt-get install mutt
.....
exit
Do NOT leave sudo -s running when you don't need it!
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software 
(http://www.media-landscape.com/) and partners in the revolutionary 
Croquet project (http://www.opencroquet.org/)


PGP.sig
Description: This is a digitally signed message part

[Fink-devel] Re: dists/10.3/unstable/main/finkinfo/libs/perlmods archive-zip-pm.info,1.1,1.2

[Chris Dolan]

Dan,
Thanks for pointing that out.  I had not sufficiently thought through 
the consequences of dropping support for 5.8.0.  I'll add back the 
Replaces/Conflicts in my various packages as you suggested.

Good news about the perl man versioning, too.  I approve of the idea.  
I'm guessing installing a version of Perl will also add a profile.d 
entry to append a perl-versioned dir to the init.[c]sh manpath?

Chris
On Feb 28, 2005, at 9:55 PM, Daniel Macks wrote:
Chris Dolan committed:
 * change perl variant list to 581,584,586 (the ones I can test 
easily)
Testing is good! However, we have to be careful not to break upgrade
paths when removing perl-versions. When a Type: perl subtype "XXX" is
removed from the .info repository, users may still have that package's
foo-pmXXX* set installed. That means we need to keep the various
Replaces/Conflicts against that once-but-no-longer-present XXX set in
whatever XXY sets remain.
OTOH, we've cooked up a new filysystem layout for perl modules that
will mean all the man3 for all perl-versions of a -pmXXX can
coexist. That will mean the -man splitoff will no longer be needed for
most perlmod packages. Details to follow when we finish figuring them
out:)
In the mean time...
Chris Dolan committed (snipping throughout the diff)
--- archive-zip-pm.info 18 Jan 2005 07:04:44 -  1.1
+++ archive-zip-pm.info 24 Feb 2005 03:33:24 -  1.2
 Version: 1.14
-Revision: 1
-Type: perl (5.8.0 5.8.1 5.8.4)
+Revision: 2
+Type: perl (5.8.1 5.8.4 5.8.6)
  Package: %N-man
- Conflicts: %{Ni}580-man, %{Ni}581-man, %{Ni}584-man
- Replaces: %{Ni}580-man, %{Ni}581-man, %{Ni}584-man
+ Conflicts: %{Ni}581-man, %{Ni}584-man, %{Ni}586-man
+ Replaces: %{Ni}581-man, %{Ni}584-man, %{Ni}586-man
Need to keep %{Ni}580-man in those fields, since that package did
exist at one point.
dan
--
Chris Dolan, Software Developer, www.chrisdolan.net
Public key: http://www.chrisdolan.net/public.key


PGP.sig
Description: This is a digitally signed message part

Re: [Fink-devel] Questions about maintainer mode and non maintainer mode

[Chris Dolan]

Actually, bash vs. zsh is not relevent here.  The error Michèle is 
reporting is that the rebuild is trying to run fink.conf for some odd 
reason.  fink.conf is a config file, not a shell script.executed.

Chris
On Mar 3, 2005, at 8:23 AM, Robert T Wyatt wrote:
What if you are using bash instead of zsh?
At 8:11 AM +0100 3/3/05, Michèle Garoche wrote:
Is this right? It does not seem to change anything. Tested with dia 
after removing the source in /sw to be sure curl is called. What it 
does is rebuild dia, install it and then try to execute each line in 
fink.conf as shell lines:
[~]% Verbose: 3
zsh: command not found: Verbose:
[127][17] Jeudi 03/03/2005 07:58:13 CET +0100
[~]% SelfUpdateMethod: cvs
zsh: command not found: SelfUpdateMethod:
etc., etc.

--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software 
(http://www.media-landscape.com/) and partners in the revolutionary 
Croquet project (http://www.opencroquet.org/)


PGP.sig
Description: This is a digitally signed message part

Re: [Fink-devel] Re: dists/10.3/unstable/main/finkinfo/sci r-base.info,1.10,1.11

[Chris Dolan]

On Mar 7, 2005, at 1:21 AM, Daniel Macks wrote:
jswhit committed:
Log Message:
fixed PreRmScript
===
RCS file: 
/cvsroot/fink/dists/10.3/unstable/main/finkinfo/sci/r-base.info,v
--- r-base.info	16 Jan 2005 02:55:00 -	1.10
+++ r-base.info	6 Mar 2005 13:15:29 -	1.11
@@ -1,3 +1,3 @@
 Package: r-base
 Version: 2.0.1
-Revision: 2
+Revision: 3
@@ -36,5 +36,5 @@
  ln -fs %p/Applications/R.app /Applications/Fink/R.app
<<
 PreRmScript: <<
- /bin/rm -f /Applications/Fink/R.app
+ /bin/rm -rf /Applications/Fink/R.app
<<
I wonder if this pkg would be a good candidate for the new AppBundles
.info field.
dan
Looking over the AppBundles code in cvs, it appears to support 
InstallScript and PostInstScript, but I see no mention of AppBundle in 
the PreRmScript.  Is this feature incomplete, or is that a bug?

For those of you who (like me) were not familiar with AppBundles, 
here's a synopsis in pseudocode:

if Appbundles tag exists
   add to default PostInstScript:
  create /Applications/Fink/
   foreach file.app in AppBundles
  add to default InstallScript:
 copy file.app to %i/Applications
 fix up file.app
  add to default PostInstScript:
 symlink %p/Applications/file.app to /Applications/Fink/file.app
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software 
(http://www.media-landscape.com/) and partners in the revolutionary 
Croquet project (http://www.opencroquet.org/)


PGP.sig
Description: This is a digitally signed message part

Re: [Fink-devel] Varianted "License" Field

[Chris Dolan]

On May 6, 2005, at 4:07 AM, Daniel Macks wrote:
Any thoughts about a syntax like:
  License: (cond1) Lic1, (cond2) Lic2, ..., (condN) LicN, LicX
where cond* are each usual condional syntax and Lic* are each standard
License types? The result is the Lic of the first true cond
encountered in the list. A final non-conditional LicX would be
required, and would be the fallback if none of the cond* hit, so we'd
never accidentally have a License be blank. It'd be up to the
Maintainer to order the conds so that the most restrictive license is
picked for a given variant.
For example:
  Package: foo-%type_raw[crypto]
  Type: crypto (ssl tls)
  License: (%type_raw[crypto] = ssl) Restrctive, GPL
for a program "foo" that can use different crypto back-ends and whose
own program is GPL would apply Restrictive to foo-ssl but GPL to the
other variant.
dan
That looks nice to me.  However, for consistency with the Depends field 
and the like, could the condition be after the license?

Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software 
(http://www.media-landscape.com/) and partners in the revolutionary 
Croquet project (http://www.opencroquet.org/)


PGP.sig
Description: This is a digitally signed message part

Re: [Fink-devel] Varianted "License" Field

[Chris Dolan]

On May 6, 2005, at 2:47 PM, Daniel Macks wrote:
I think I've been quite consistent putting the conditional expression
*before* the thing the conditional controls.
  Depends: (%type_pkg[perl] < 581) time-hires-pm (>= 1.50-1)
  ConfigureParams: (%type_pkg[ssl]) --with-ssl
Note that the versioning requirement of time-hires-pm is not a
condition of that package being included as a dependency, but rather
is a detail of the dependency (an always-present modifier of the
packagename).
dan
Ahh, you're right of course.  I was confusing the variant conditionals 
and the version conditionals.

Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software 
(http://www.media-landscape.com/) and partners in the revolutionary 
Croquet project (http://www.opencroquet.org/)


PGP.sig
Description: This is a digitally signed message part

Re: [Fink-devel] soap-lite-pm

[Chris Dolan]

Koen,

The /sw/bin files should go in a -bin splitoff.  See 
spreadsheet-writeexcel-pm.info for a simple example.  Note that there 
should perhaps also be a -man splitoff.


Chris


On Jun 27, 2005, at 5:13 PM, Koen van der Drift wrote:


Hi,

During the installation of soap-lite-pm586, I got an error for some 
conflicting files that were already installed by soap-lite-pm581:


/sw/bin/SOAPsh.pl
/sw/bin/SOAPsh.pl
sw/bin/XMLRPCsh.pl

So I edited the .info file (there is no maintainer listed) and changed 
the Replaces field from:


Replaces: soap-lite-pm (<= 0.55-1), soap-lite-pm%type_pkg[perl], 
soap-lite-ssl-pm%type_pkg[perl]


to:

Replaces: soap-lite-pm (<= 0.55-1), %{Ni}560, %{Ni}580, %{Ni}581, 
%{Ni}586


Installation now went fine, however, the validation of the .deb file 
failed for the same three files:


Warning: File in a perl-versioned package is neither versioned nor in 
a versioned directory.

  Offending file: /sw/bin/SOAPsh.pl

I guess those three files should not be in /sw/bin, but somewhere else.

So I have two questions:
1. Is the change of the Replaces field the correct one?
2. Where should the three files in /sw/bin go to?

I don't mind to take over the package and will commit the changes 
after I fixed the validation problem.



cheers,

- Koen.



---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel


--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software 
(http://www.media-landscape.com/) and partners in the revolutionary 
Croquet project (http://www.opencroquet.org/)


PGP.sig
Description: This is a digitally signed message part

Re: [Fink-devel] ssl packages in main/

[Chris Dolan]

On Aug 21, 2005, at 4:43 PM, Benjamin Reed wrote:

I've made a "system-openssl-dev" package that will allow packagers  
to force the use of the system OpenSSL rather than the fink- 
provided one. I'm going to be using it for KDE and a few other  
things to get rid of the hell that is the ssl/non-ssl split, and  
the accompanying license craziness.


Since apple's openssl is provided with the OS, it should be OK to  
distribute binaries linked this way.


Ben,

Two questions:

1) Does this mean that we can set
  Depends: openssl097-dev | system-openssl-dev
and start putting SSL-dependent .info files in main/finkinfo?

2) If I build an SSL-dependent package against system-openssl-dev and  
later install openssl097-shlibs the package will remain linked  
against the system openssl, right?  Could that be a problem?


Chris

--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)




---
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Pod::Perldoc

[Chris Dolan]

A Perl module I'm trying to package depends on Pod::Perldoc v3.14.   
Earlier versions of that module are provided by the core Perl (e.g.  
v3.13 is in Perl 5.8.6 and v3.10 is in Perl 5.8.1), however our Perl  
packages (e.g. perl581.info) do not list pod-perldoc-pm in the  
Provides area.


If I do package pod-perldoc-pm v3.14:
 * Do we need to update perl58x.info to add Provides/Conflicts for  
pod-perldoc-pm?

 * Does my package need to Conflict with perl581-core?
 * Does my package need to be Perl-versioned?

I *should* be able to figure this out on my own, but I get so  
confused when overriding system packages and dealing with Conflicts...


Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)




---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very

own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Pod::Perldoc

[Chris Dolan]

On Sep 27, 2005, at 10:52 AM, Daniel Macks wrote:


On Tue, Sep 27, 2005 at 10:20:15AM -0500, Chris Dolan wrote:


A Perl module I'm trying to package depends on Pod::Perldoc v3.14.
Earlier versions of that module are provided by the core Perl (e.g.
v3.13 is in Perl 5.8.6 and v3.10 is in Perl 5.8.1), however our Perl
packages (e.g. perl581.info) do not list pod-perldoc-pm in the
Provides area.

If I do package pod-perldoc-pm v3.14:
 * Do we need to update perl58x.info to add Provides/Conflicts for
pod-perldoc-pm?
 * Does my package need to Conflict with perl581-core?
 * Does my package need to be Perl-versioned?


...
perlXXX-core is installed in a separate location from where packaged
perl modules go (%p/lib/perl5-core instead of %p/lib/perl5), so no
Conflicts or Replaces is necessary here.
...


Aha!  I forgot that the perlXXX-core have their own install  
locations.  That solves the issue for any .pm files.  However, the  
pod-perldoc-pm package I'm creating also includes /sw/bin/perldoc in  
a -bin splitoff.   /sw/bin/perldoc is provided by perl581, so I guess  
that splitoff will have to Conflict, right?


For now I'm punting.  I managed to get AnnoCPAN::Perldoc to work  
against the Pod::Perldoc v3.13 that comes with Perl 5.8.6 instead of  
truly needing v3.14.


FUTURE NOTE: I request that the next time anyone is touching  
perlXXX.info, they please add a provides for pod-perldoc-pm with the  
version numbers specified at the top of this message.  That's very  
low priority for now.


Thanks!

Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)




---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Newer version of Storable.pm

[Chris Dolan]

I'm trying to package a Perl module that requires a newer version of  
Storable.pm than the one that comes with Tiger (v2.14 vs. v2.13).   
The missing feature I need is the ability to store weak references.   
Does anyone foresee problems with a new storable-pm.info?  I believe  
Fink does not care strongly which version it uses, but since this is  
an implied Essential package, I thought I should ask.


Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)




---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Re: Fink binary distributions

[Chris Dolan]

On Nov 5, 2005, at 4:55 AM, Dave Vasilevsky wrote:

When it comes to a system to perform the builds on, we don't really  
have anything at this point. A build box should ideally be a very  
clean system, since we don't want any .debs to be accidentally  
polluted. Also, we'd have to be careful it's under the control of  
trusted people, since there's a security risk with distributing  
binaries. Something to think about once we get sufficient work done  
on buildfink.


Here's a brainstorm for a distributed bindist creation solution:

How about an 'upload' flag in fink.conf that developers can turn on.   
After a successful build, fink would compute a hash (perhaps MD5) of  
a resulting .deb and report that hash to a server.  If that MD5 is  
not previously known, the .deb is uploaded.  Otherwise, a "vote" for  
that .deb's hash is recorded in the developer's name.  When a .deb  
gets enough votes from trusted developers, it's made public as a binary.


Requiring multiple votes with matching hash before adding to bindist  
solves these problems:
 1) don't have to trust just one developer to make bindist since  
results are checked against others
 2) less worry about a weird setting on a single build box making  
bad .debs

 3) don't need dedicated hardware for bindist

[One small worry would be the hash.  There are known ways to create  
MD5 collisions.  But given that the .deb is created from a .info, I  
think it would be really hard to create a .info that repeatably  
created a compromisable .deb.]


What would be needed to implement this?
 - social decisions
   * how many votes needed to trigger an addition of .deb to bindist
   * weighting for developer votes  (e.g. Dave Morrison's vote  
counts much more than Chris Dolan's)

 - server
   * list of developers who can vote (same as committer list?)
   * a vote database
   * write-only .deb upload location (write once, no overwrite!)
   * auto update of apt binary list files when sufficient votes arrive
 - client
   * code to support new upload setting
   * code to submit vote and .deb after build
   * more frequent fetch of apt binary lists since they'll be  
updated constantly


Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)




---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Re: Fink binary distributions

[Chris Dolan]

On Nov 5, 2005, at 5:45 PM, Alexander K. Hansen wrote:


A problem opposite to the one that you mentioned also occurs:
building on different machines with different packages that solve the
same virtual dependency (e.g. Xorg vs. Apple's X11) will generally
result in more than one MD5 for the same package.


Hmm... Then, wouldn't that be a problem for bindist in general?
Chris
--  
Chris Dolan, Software Developer, Clotho Advanced Media Inc.

608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)




---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] How to determine required dependencies?

[Chris Dolan]

On Nov 9, 2005, at 9:51 PM, Trevor Harmon wrote:

Unfortunately, I don't know of any such tool for Java packages,  
which is what I've mainly been submitting to Fink. Same problem  
with Perl, Python, and so on. Anybody know of otool equivalents for  
these languages?


For Perl, the best tools are Module::Depends::Intrusive for unpacked  
tar.gz packages and Module::ScanDeps for installed software.   
Luckily, the Perl community has a strong culture of carefully listing  
all dependencies in Makefile.PL or Build.PL or META.yml.  The latter  
is the best source, since it's a document not code, but it has not  
yet been widely adopted in the community.


I have a mkpkg.pl script in experimental/chrisdolan that looks up  
Perl modules on CPAN and tries to build .info files for them using  
metadata from the files included in the tarball.


Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)




---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] How to determine required dependencies?

[Chris Dolan]

On Nov 9, 2005, at 9:51 PM, Trevor Harmon wrote:

Unfortunately, I don't know of any such tool for Java packages,  
which is what I've mainly been submitting to Fink. Same problem  
with Perl, Python, and so on. Anybody know of otool equivalents for  
these languages?


More good advice for finding dependencies: look at other projects and  
see what they did.  Check what Debian lists as dependencies, check  
darwinports, check BSD ports, check RedHat RPMs, etc.  If they have a  
dependency listed and you don't, first see if Apple provides that  
dependency with the OS.  If not, make sure to satisfy it in  
your .info file.


These urls allow you to browse the dependency list for any package  
provided by their respective systems:

  Debian:
http://www.us.debian.org/distrib/packages#search_packages
  DarwinPorts:
http://darwinports.opendarwin.org/
  BSD ports:
http://www.freebsd.org/cgi/ports.cgi
  RPM:
http://rpmfind.net/linux/rpm2html/search.php

Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)




---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] ntop 1.1-23

[Chris Dolan]

[Writing to fink-devel because ntop is unmaintained]

I'm running ntop 1.1-23 compiled from unstable with a recent Fink  
from CVS on 10.4.3.  Everything works except the keystrokes.  I can't  
type "q" to exit.   All of my keystrokes instead get buffered and are  
echoed in the Terminal after I Ctrl-C to exit ntop and return to tcsh  
or bash (I tried it under both).  I'm running ntop with no cmdline  
arguments.  I tried "fink rebuild ntop" but that didn't change anything.


Any ideas?  ntop uses ncurses, but I have the latest version of that  
from Fink and I haven't heard anyone else complaining about it...


Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)




---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] mac-growl-pm586: fix it or I'll kill it

[Chris Dolan]

Despite a crash during "make test", it installed OK for me (last week  
from unstable on 10.4) after I installed mac-glue-pm, but I didn't  
look into it closely enough to see the cause.  To look for bad files  
I ran this:


% locate Growl.pm
/sw/lib/perl5/5.8.6/Mac/Growl.pm
/sw/lib/perl5/Fink/Notify/Growl.pm

% locate growl | grep -v PreferencePane
/sw/fink/10.3/unstable/main/finkinfo/libs/perlmods/mac-growl-pm.info
/sw/fink/10.3/unstable/main/finkinfo/libs/perlmods/mac-growl-pm.patch
/sw/fink/10.4-transitional/unstable/main/binary-darwin-powerpc/libs/ 
perlmods/mac-growl-pm586_0.7-10_darwin-powerpc.deb
/sw/fink/10.4-transitional/unstable/main/finkinfo/libs/perlmods/mac- 
growl-pm.info

/sw/fink/debs/mac-growl-pm586_0.7-10_darwin-powerpc.deb
/sw/share/doc/mac-growl-pm586
/sw/share/doc/mac-growl-pm586/Changes
/sw/share/doc/mac-growl-pm586/README
/sw/share/podfiles/5.8.6/perllocal.mac-growl-pm586.pod
/sw/var/lib/dpkg/info/mac-growl-pm586.list
/sw/var/lib/dpkg/info/mac-growl-pm586.postinst
/sw/var/lib/dpkg/info/mac-growl-pm586.postrm

So, nothing Growl-related in /System for me.  I looked over the .info  
and I can't see any mistakes.  I can't see how it could have  
installed anything into /System, unless it's Mac::Glue's fault.  I  
see in Mac::Growl's Makefile.PL that it is trying to copy files into  
$Mac::Glue::Common::MACGLUEDIR but ONLY if you are running Mac::Glue  
older than v1.24.  Perhaps mac-growl-pm needs to depend on mac-glue- 
pm >= 1.24?


Chris

On Jan 16, 2006, at 3:15 PM, Martin Costabel wrote:


Could someone for whom mac-growl-pm586 builds and works please fix it?

On October 8 2005 I sent en error report to fink-users with CC to  
the maintainer (thesin). Nothing happened except that someone  
(Daniel Johnson) said that it built for him.


Today the same error is reported on the beginners list. When I  
wanted to check the situation, it crashed for me in the same way,  
and not only that:


*It still installs - during the build phase! - things into /System/ 
Library/.*


I think this is such an outrageous behavior that the package, if it  
is not fixed soon, needs to be scrapped.


--
Martin



---
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
searching your log files as easy as surfing the  web.  DOWNLOAD  
SPLUNK!

http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel


--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)





---
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
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] mac-growl-pm586: fix it or I'll kill it

[Chris Dolan]

On Jan 16, 2006, at 4:12 PM, Daniel Macks wrote:


On Mon, Jan 16, 2006 at 03:00:59PM -0700, TheSin wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

and BTW this is why I won't dep on mac-glue-pm(version)

[/sw/fink/dists/local/main/finkinfo]$ fink install mac-growl-pm586
Information about 5271 packages read in 2 seconds.
The following package will be installed or updated:
mac-growl-pm586
The following 9 additional packages will be installed:
freezethaw-pm mac-appleevents-simple-pm586 mac-apps-launch-pm586
mac-carbon-pm586 mac-errors-pm mac-glue-pm586 mldbm-pm perl581-core
time-epoch-pm

I don't want perl-core581.  So for now we wait for a proper fix.


Yo, this means there's something wrong in one of the deps. Shouldn't
be that hard to find which -pm586 accidentally has the wrong
perlXXX-core, or which perl-unversioned package is either bugged (or
worse, needs to be perl-varianted but isn't).

dan


Perhaps it's mldbm-pm.info (which is needed by mac-glue-pm)?   
Everything else appears to be versioned properly.  But on 10.4,  
storable-pm is a virtual package, so it shouldn't be installing 5.8.1...


% grep Depends mldbm-pm.info
Depends: storable-pm | perl580-core | perl581-core, freezethaw-pm

Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)





---
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
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] mac-growl-pm586: fix it or I'll kill it

[Chris Dolan]

Koen,

What version of mac-glue do you have installed?

Is it possible it's an Xcode 2.2 problem?  I'm still on 2.1 and have  
had minimal problems with mac-glue and mac-growl.


Chris

On Jan 17, 2006, at 5:00 PM, Koen van der Drift wrote:



On Jan 17, 2006, at 10:17 AM, TheSin wrote:

okay it worked better then I thought, the new glues are made in / 
sw and in the deb.  now I'll commit it and see if the 2% that had  
bad tests get working.



I'm afraid not here, still getting a test error :(


...
Writing Makefile for Mac::Growl
make
cp lib/Mac/Growl.pm blib/lib/Mac/Growl.pm
cp lib/Mac/Glue/glues/GrowlHelperApp blib/lib/Mac/Glue/glues/ 
GrowlHelperApp
cp lib/Mac/Glue/glues/GrowlHelperApp.pod blib/lib/Mac/Glue/glues/ 
GrowlHelperApp.pod

Manifying blib/man3/Mac::Growl.3pm
Manifying blib/man3/Mac::Glue::glues::GrowlHelperApp.3pm
Making glue for '/Library/PreferencePanes/Growl.prefPane/Contents/ 
Resources/GrowlHelperApp.app'
Created and installed App glue for 'GrowlHelperApp.app,  
v0.7.2' (GrowlHelperApp)

make test
PERL_DL_NONLAZY=1 /usr/bin/perl5.8.6 "-MExtUtils::Command::MM" "-e"  
"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/Mac-Growlok 1/11 ERROR  PerlObjCBridge:  
convertPerlToObjC(): Referenced thingy not blessed
 ERROR  PerlObjCBridge: convertArg() for index 2:  
convertPerlToObjC() failed
 ERROR  PerlObjCBridge: sendObjcMessage: Error converting  
argument 1 for message "iconForFile:"
 ERROR  PerlObjCBridge: error sending message iconForFile:  
at /System/Library/Perl/Extras/5.8.6/darwin-thread-multi-2level/ 
PerlObjCBridge.pm line 230,  line 1.

# Looks like you planned 11 tests but only ran 1.
# Looks like your test died just after 1.
t/Mac-Growldubious
Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 2-11
Failed 10/11 tests, 9.09% okay
Failed Test   Stat Wstat Total Fail  Failed  List of Failed
-- 
-

t/Mac-Growl.t  255 6528011   20 181.82%  2-11
Failed 1/1 test scripts, 0.00% okay. 10/11 subtests failed, 9.09%  
okay.

make: *** [test_dynamic] Error 2
### execution of make failed, exit code 2
Failed: phase compiling: mac-growl-pm586-0.7-12 failed



Package manager version: 0.24.99.cvs
Distribution version: 0.8.0.cvs
OS X 10.4.4
XCode 2.2.1


- 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
searching your log files as easy as surfing the  web.  DOWNLOAD  
SPLUNK!
http://sel.as-us.falkag.net/sel? 
cmd=lnk&kid=103432&bid=230486&dat=121642

___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel


--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)





---
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
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] CVS "chill" over

[Chris Dolan]

On Feb 18, 2006, at 1:25 PM, David R. Morrison wrote:


The packages which have not (yet) been brought forward to 10.4 are:

(unstable tree)
xerces-c23


This package is mine but I would like to abandon it.  It's outdated  
and never worked very well in the first place.  I think it would be  
best to just remove it until such a time as someone wants to  
resurrect it brand-new.


Chris

--
Chris Dolan, Software Developer, http://www.chrisdolan.net/
Public key: http://www.chrisdolan.net/public.key
vCard: http://www.chrisdolan.net/ChrisDolan.vcf





---
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
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Re: [PR] Fink is about to change, are you going to be part of it? Help us build the Fink Developer Network!

[Chris Dolan]

On Mar 19, 2006, at 4:24 PM, David H. wrote:

The things you mention are one area where I would agree with you.  
However,
there are other things tied into this, which are far better handled  
by a
cooperation. For example the Fink Logo has to be owned by  
"someone". The
individual ideas and ideas that are in the Fink package manager  
might be
something we wish to protect in the future. The name "Fink" might  
be protected
in the future and other things that are simply better handled by a  
body that
does not belong to a single individual. As we believe that Fink  
belongs to the
community we would like the things that "belong to Fink" also  
belong to a
"legal" community. The Board of directors is such a community in my  
humble

opinion.


Another good example would be finkmirrors.net.  I think all would  
agree that we'd be better off if an organization owned and managed  
that domain rather than burdening an individual with that  
responsibility.


Chris



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Machine readable package list?

[Chris Dolan]

Is there a machine-readable list of all packages and versions  
provided by current Fink?  The data obviously exists in a database on  
pdb.finkproject.org but short of scraping HTML or fetching CVS, I  
can't figure out how to access that list.


Background:

There's a Perl library called Module::Packaged (http:// 
search.cpan.org/dist/Module-Packaged/) which collects the versions of  
CPAN modules packaged by various OS distributions.  For example,  
given the CPAN module Archive::Any, you can learn that the current  
versions are:

  cpan:   1.08
  debian: 1.03
  gentoo: 1.05
etc.  I'm working with the author to get Fink packages added to his  
list.  My current solution is a cron-driven CVS pull and hackish  
parse of the info files in main/finkinfo/lib/perlmods/*-pm*.info and  
crypto/finkinfo/*-pm*.info.  I'd like to create a more elegant  
solution, if feasible.


Thanks,
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)





---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Machine readable package list?

[Chris Dolan]

On Mar 20, 2006, at 3:50 PM, Daniel Macks wrote:


How "all packages and versions" do you mean? For example, I can do

  fink list -t \*-pm\* | cut -f2,3

to get a list of the highest available version of all perlmodule
packages, or just 'cut -f2' it and feed it to

  fink dumpinfo -fpackage,allversions

to get a list of all versions of each of them present in my active
Trees. But those only get what is available "now" (stable+unstable at
last selfupdate), not what's in the binary distro nor what older
versions may have been present before (i.e., if someone hasn't
selfupdated in a while) and only sees the distro (10.4-transitional,
for example) that I am running (10.3 may have a lower version, maybe
10.4 doesn't have it at all).

The scripts that populate the MySQL database that feeds the web PDB
aren't much more sophisticated than that, actually...they just use the
lower-level perl functions that 'fink list' use under-the-hood instead
of using the 'fink' command. To get the data from the different trees
and distros, they actually rewrite the local fink.conf and dists/
symlink (and store those values in the MySQL tables along with the
package data).

dan


By "all packages and versions", I probably overstated.  I'm really  
just looking for the most current state (meaning probably 10.4/ 
{stable,unstable}) but if 10.3, etc. is trivially accessible I'll use  
that too.


Yes, "fink list" data are indeed exactly what I'm seeking, but the  
numbers need to be accessible to a non-Mac and Macs that don't have  
Fink installed.  I can do "fink list" or the equivalent on my own  
machine and upload the data to my own website via cron, but I was  
hoping to find something a little more "official".


Perhaps someone could add a cron to PDB that just dumps the MySQL  
database to a .bz2 file daily?  Or the regular PDB process could dump  
that file?  Or does a file like that already exist and I just  
overlooked it?


Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)





---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Machine readable package list?

[Chris Dolan]

On Mar 20, 2006, at 5:50 PM, Daniel Macks wrote:


In order to 'fink list', the only things you need are the pure perl
parts...don't need a full local fink installation or compiled dpkg and
other support binaries. Until recently, the web PDB database update
script was running on a linux box on which we did not have root
access.


Good point!


Perhaps someone could add a cron to PDB that just dumps the MySQL
database to a .bz2 file daily?  Or the regular PDB process could dump
that file?


Seems reasonable (and generally useful too)...the update is driven by
cron, so it'd be easy to dump the whole db after updating it. Here's
"mysqldump" of the "package" database:

 http://pdb.finkproject.org/pdb/full_dump_2006-03-20_23:35.sql.bz2

Is that what you need?


Wow, it's huge.  Yes, it will do fine, unless you are worried about  
the bandwidth usage.  Hopefully it will be a rarely accessed file.



I don't know much about mysqldump, but I do know that our databases
are password-protected. Is there a way to have mysqldump read the
password from a file so we don't have to hard-code it in Yet Another
Place in our scripts? Alternately, is there a way to do the dump using
mysql commands (since we already have a generic way to "run mysql
commands using the password")?


You could easily parse the password out of your PHP file like so:

  #!/bin/csh
  set file = "db.inc.php"
  set out = "packages.sql.bz2"
  set db_name = `perl -0 -ne'/\$db_name\s*=\s*\"([^\"]+)/&&print $1'  
$file`
  set db_user = `perl -0 -ne'/\$db_user\s*=\s*\"([^\"]+)/&&print $1'  
$file`
  set db_passwd = `perl -0 -ne'/\$db_passwd\s*=\s*\"([^\"]+)/&&print  
$1' $file`

  mysqldump -u $db_user -p$db_passwd $db_name packages | bzip2 >! $out

Alternatively, making a CSV file is pretty easy in Perl, even by hand:

  use DBI;
  my %dbvars;
  # Parse DB info out of the PHP file
  open my $fh, '<', 'db.inc.php' or die;
  while (<$fh>) {
 if (/\$db_(name|user|passwd)\s*=\s*[\'\"]([^\'\"]+)/) {
$dbvars{$1} = $2;
 }
  }
  close $fh;
  # Dump the database to comma-separated fields
  my $dbh = DBI->connect("DBI:mysql:database=$dbvars{name}",
 $dbvars{user}, $dbvars{passwd});
  my $sth = $dbh->prepare('select * from packages');
  $sth->execute();
  # Print header row first
  print join(',', map {$dbh->quote($_)} @{$sth->{NAME}}), "\n";
  while (my $row = $sth->fetchrow_arrayref) {
 print join(',', map {$dbh->quote($_)} @$row), "\n";
  }


An even cooler alternative would be an SQLite file that I could  
download.  If that's appealing, I would be quite happy to write an  
exporter for you.


Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)





---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] cvs update warnings

[Chris Dolan]

On Mar 21, 2006, at 8:48 AM, Jack Howarth wrote:

Is anyone else seeing the following warnings on a cvs fink- 
selfupdate

of 10.4 today?

cvs update: -m wrapper option is not supported remotely; ignored

I haven't seen this one before.
Jack


Yes, I'm seeing that message in multiple SourceForge projects, so I  
assume it's their fault.  It seems harmless so far.


Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)





---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] scanpackages bombs if apt cache dir is missing (workaround)

[Chris Dolan]

While trying to clear up some disk space, I mistakenly deleted the  
contents of /sw/var/cache (meant to empty /sw/var/ccache).  After  
that, I found that scanpackages failed with this error, among others:

   E: Archive directory /sw/var/cache/apt/archives/partial is missing.

The trivial workaround was

   sudo mkdir -p /sw/var/cache/apt/archives/partial

It certainly seems reasonable that apt should auto-create that  
directory as needed.
Chris

-- 
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)



-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] sudo + PERL5LIB hack

[Chris Dolan]

I'd like to share a trick I made up tonight:

   sudo env PERL5LIB=$PERL5LIB perl some_program.pl

This trick is needed because, as of 10.4.9, sudo no longer passes  
$PERL5LIB for security reasons, as most Fink users probably know by  
now.  Specifically, I'm using that hack for psync because  
MacOSX::File is not installed in the system library.

Chris

--
Chris Dolan, Equilibrious LLC, http://equilibrious.net/
Public key: http://chrisdolan.net/public.key
vCard: http://chrisdolan.net/ChrisDolan.vcf




-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] soap-lite-pm downgraded upstream

[Chris Dolan]

On Jun 21, 2007, at 1:36 PM, Koen van der Drift wrote:

>>
>> On Wed, Jun 20, 2007 at 08:14:28PM -0400, Koen van der Drift wrote:
>>> Hi,
>>>
>>> Just noticed that the current version of soap-lite-pm in fink, which
>>> I maintain, is not available anymore on cpan (http:// 
>>> search.cpan.org/
>>> dist/SOAP-Lite/). The package database lists version 0.69, but only
>>> 0.60a is listed on cpan.
>>>
>>> Is it ok to downgrade the package in fink, or will that create
>>> problems, eg with the bindist?
>>
>> Downgrading can be problematic for users who have already installed
>> the "new" version...technically you'd want the downgraded version to
>> be *higher* than the new one, so that they "upgrade" to the "current
>> version in fink". Probably use Epoch:1 and a higher Revision on the
>> new old-version .info.
>>
>> However, I think 0.69 (and 0.67 and 0.68) are on fink's master- 
>> mirrors
>> pool, so users can just get it from there. All depends *why* the
>> upstream author downgraded so substantially.
>>
>
> I have mailed the developer and asked him which version we can use.
> For now I'll leave it at 0.69.
>
> - Koen.

FYI, this was due to a bug in CPAN.  CPAN recently introduced a  
feature to prevent people from hijacking namespaces and it was a  
little too aggressive for community-maintained libraries like SOAP- 
Lite.  It should be all better now.

Chris


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] unison packages

[Chris Dolan]

On Sep 28, 2007, at 2:04 PM, Alexey Zakhlestin wrote:

> I think, that I read, somewhere, that 2.27 is protocol-compatible with
> 2.13… (though I may be wrong)

The changelog is here:
   http://www.seas.upenn.edu/~bcpierce/unison//download/releases/beta/ 
unison-2.27.29-manual.html#news
and does not mention anything protocol-related.

FWIW, I've been using Fink's 2.13.16-1004 daily with many different  
configs and have had no problems.  I endorse a move to stable.

Chris
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] wait for new fink?

[Chris Dolan]

Could someone summarize the bug, or post a link to the IRC logs for 
those of us who have no idea what you are talking about?  :-)

Thanks,
Chris

On 11/22/02 5:27 PM, Max Horn wrote:
At 11:28 Uhr -0500 22.11.2002, David R. Morrison wrote:


There was considerable discussion on #fink the other night of a bug in
the package manager which causes some installs to fail.

I'm just about finished building the 0.5.0 distro; should I wait for
this to get fixed before I release?



The problem is: a full fix requires major changes to the dependency 
code, and probably will introduce other regression. Plus I am not sure 
if I will get to actually working on it this weekend, it's possible that 
I only can work on it the weekend after, as I have to finish two papers 
and do some other work. And even if I implemented it this weekend, we 
would have to test it extensively for at least a week

So, if we wait for a new fink package manager release, then we have to 
delay 0.5.0 for at least a week, if not 2 or 3.


Max



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] phpwebstats up for fink

[Chris Dolan]

Max Horn wrote:
> At 20:52 Uhr -0800 02.12.2002, Ben Hines wrote:
> 
>> Please look for any broken pages on the fink site, I had a couple
>> issues with paths for the db include files, but I think its fixed now.
>>
>> And here are the stats:
>>
>> http://fink.sourceforge.net/pws/
>>
>> This phpwebstats app is still pretty alpha. Its homepage is
>> http://phpwebstats.sourceforge.net/
> 
> Err, I am not sure I like this accesible to everybody, openly. In fact I
> think the pages shoudl be secured by a password.
> 
> Max

Agreed.  Although the stats are pretty generic and anonymized, the
referer log in particular is too invasive to be posting to the public.
 People typically expect that their web behavior will not be publicized
to the world.  The Fink site does not have a good reason to deviate from
this expectation, IMO.

That said, I find the stats interesting.
Chris



---
This SF.net email is sponsored by: Microsoft Visual Studio.NET 
comprehensive development tool, built to increase your 
productivity. Try a free online hosted session at:
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel