Re: [Fink-devel] Should I try and integrate a newer version of mutt in fink?

2005-08-09 Thread Clemence Magnien
On Tue, Aug 09, 2005 at 09:45:09PM -0500, Corey Halpin wrote:
> On 2005-08-09, Clemence Magnien wrote:
> > when you say you have such a version of mutt, do you refer to the patched
> > version? Anyway, if I understand correctly that means you have a working
> > mutt.info file for one version or the other.
> 
>  I've got an info file for mutt 1.5.9 that uses header caching.
>  
> http://cvs.sourceforge.net/viewcvs.py/fink/experimental/crhalpin/mutt-ssl.info?rev=1.1&view=auto
> 
> > Do you think one of us should try and propose it as an official package
> > description? Or should we (I?) try and make all the four versions I
> > mentioned above before that?
> 
>Well, I'm not sure what the point would really be of providing more than
> -ssl and non-ssl versions of mutt.  If people don't want the header
> caching, then they can disable it in .muttrc.  Or rather, they can not
> enable it.  :-)

My mistake, I misremembered the way I installed mutt. I thought that
this version only did header caching for mails in /var/spool/mail or
something like that, and that you needed to patch it for it to do
_IMAP_ header caching. So indeed there is no point to what I said above.

 
> > Or should we wait for an answer from the maintainer? I really don't
> > know what is the policy in this kind of situation.
> 
>   Typically if the maintainer is gone AWOL, someone else can adopt the
> package.  I emailed the maintainer on 6/19/05, and have yet to get a
> response.  Has anyone else on the list heard from Christian Swinehart
> recently?
> 
>   fink-core: if not, should we consider mutt orphaned?
>   If so, I'd be willing to adopt it, provided nobody else wants it.

My own email to then maintainer dates from june, 5, 2005.
As I said, I'd be willing but not wanting since I fear I would be
incompetent.

Cheers,
Clemence

> 
> crh



-- 
Ce qui se concoit bien s'exprime clairement.
-
http://www.crea.polytechnique.fr/personnels/fiches/magnien.htm
01 55 55 86 27



---
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


Re: [Fink-devel] Should I try and integrate a newer version of mutt in fink?

2005-08-09 Thread Corey Halpin
On 2005-08-09, Daniel Macks wrote:
> How do these efforts complement or overlap with the muttng package
> loitering in the submissions queue:
> 
> http://sourceforge.net/tracker/?group_id=17203&atid=414256&func=detail&aid=1227723
 
  This .info is for the mutt from mutt.org, not from the forked version at
http://mutt-ng.berlios.de/.  So I don't think there's a lot of overlap,
since these are distinct (but related) programs.

  I'd think that it would be worthwhile for fink to provide a more recent
version of the mutt.org mutt as well as mutt-ng.  At least until mutt-ng
Takes Over The World.

crh


pgpaCnEVYipNS.pgp
Description: PGP signature


Re: [Fink-devel] Should I try and integrate a newer version of mutt in fink?

2005-08-09 Thread Daniel Macks
On Tue, Aug 09, 2005 at 09:45:09PM -0500, Corey Halpin wrote:
> On 2005-08-09, Clemence Magnien wrote:
> > when you say you have such a version of mutt, do you refer to the patched
> > version? Anyway, if I understand correctly that means you have a working
> > mutt.info file for one version or the other.
> 
>  I've got an info file for mutt 1.5.9 that uses header caching.
>  
> http://cvs.sourceforge.net/viewcvs.py/fink/experimental/crhalpin/mutt-ssl.info?rev=1.1&view=auto

How do these efforts complement or overlap with the muttng package
loitering in the submissions queue:

http://sourceforge.net/tracker/?group_id=17203&atid=414256&func=detail&aid=1227723

dan

-- 
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks



---
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] Re: Fink-devel digest, Vol 1 #2019 - 3 msgs

2005-08-09 Thread William Scott

zsh 4.2.5-11 is still broken because of this, BTW.


>1. Re: zsh for 10.4 (Daniel E. Macks)
> Message: 1
> To: fink-devel@lists.sourceforge.net
> From:  "Daniel E. Macks" <[EMAIL PROTECTED]>
> Date: Mon, 8 Aug 2005 03:10:46 + (UTC)
> Subject: [Fink-devel] Re: zsh for 10.4
>
> Peter O'Gorman <[EMAIL PROTECTED]> said:
> >
> > poll() did not exist on Mac OS X 10.2 and earlier, on 10.3 it was
> > implemented in an emulation library and implemented in terms of select(),
> > with Mac OS X 10.4 we finally got a real poll(), but it unfortunately has
> > some bugs which make it difficult to use. If they want to change their
> > configure, I'd suggest ignoring poll() on darwin totally.
>
> I just added a chapter about 10.4 to Fink's porting page, including a
> note about this bug (and also some other 10.3/10.4 differences).
> Pogma (or anyone) feel free to add more things to that doc.
>
> dan
>
> --
> Daniel Macks
> [EMAIL PROTECTED]
> http://www.netspace.org/~dmacks



---
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


Re: [Fink-devel] Should I try and integrate a newer version of mutt in fink?

2005-08-09 Thread Corey Halpin
On 2005-08-09, Clemence Magnien wrote:
> when you say you have such a version of mutt, do you refer to the patched
> version? Anyway, if I understand correctly that means you have a working
> mutt.info file for one version or the other.

 I've got an info file for mutt 1.5.9 that uses header caching.
 
http://cvs.sourceforge.net/viewcvs.py/fink/experimental/crhalpin/mutt-ssl.info?rev=1.1&view=auto

> Do you think one of us should try and propose it as an official package
> description? Or should we (I?) try and make all the four versions I
> mentioned above before that?

   Well, I'm not sure what the point would really be of providing more than
-ssl and non-ssl versions of mutt.  If people don't want the header
caching, then they can disable it in .muttrc.  Or rather, they can not
enable it.  :-)

> Or should we wait for an answer from the maintainer? I really don't
> know what is the policy in this kind of situation.

  Typically if the maintainer is gone AWOL, someone else can adopt the
package.  I emailed the maintainer on 6/19/05, and have yet to get a
response.  Has anyone else on the list heard from Christian Swinehart
recently?

  fink-core: if not, should we consider mutt orphaned?
  If so, I'd be willing to adopt it, provided nobody else wants it.

crh


pgpN76xcAqfug.pgp
Description: PGP signature


[Fink-devel] Procedure for creating a new daemon user?

2005-08-09 Thread Brendan Cully
Hi,

I would like to package up icecast2 to run under its own UID, but I
can't seem to find anything in the packaging manual about how I ought
to install a new user. I poked around a few existing packages but the
ones I found seem to have their users included in the core passwd-fink
file. Is there any other approach? I was tempted to just add an entry
in the 300+ range, but that's probably not 100% kosher.

Thanks,
-b



---
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


Re: [Fink-devel] Should I try and integrate a newer version of mutt in fink?

2005-08-09 Thread Clemence Magnien
On Sat, Aug 06, 2005 at 10:20:21AM -0500, Corey Halpin wrote:
> On 2005-08-06, Clemence Magnien wrote:
> > So, what is your advice? Should I try to do it or not?
> > I think the first point is not that important, since there are
> > probably tons of other new functionalities that work very well,
> > but I'm more concerned with the second.
> > 
> > If you do think I should try, I have another question: the version
> > I use is patched so that it does header caching for IMAP mailbox.
> > What should I do about this? Integrate the patch in the package,
> > or not integrate it, or make two versions, one with and one without
> > the patch? (with ssl and non-ssl versions of each...).
>  
>   I have such a version of mutt in my experimental.  It might be a good
> starting point.  :-)
>   I also emailed the mutt maintainer and didn't get any response.

Hi,

when you say you have such a version of mutt, do you refer to the patched
version? Anyway, if I understand correctly that means you have a working
mutt.info file for one version or the other. Do you think one of us
should try and propose it as an official package description? Or should
we (I?) try and make all the four versions I mentioned above before that?
Or should we wait for an answer from the maintainer? I really don't
know what is the policy in this kind of situation.

Cheers,
Clemence

-- 
Ce qui se concoit bien s'exprime clairement.
-
http://www.crea.polytechnique.fr/personnels/fiches/magnien.htm
01 55 55 86 27



---
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


Re: [Fink-devel] 10.4 tree question

2005-08-09 Thread David R. Morrison


On Aug 8, 2005, at 10:44 AM, Martin Costabel wrote:

Lacking instructions on how to run my own 10.4 tree and therefore  
how to find real problems with it,


Martin: I am making some instructions, but will have to wait until SF  
finishes their scheduled upgrade of CVS services.



I am at the stage of imagining problems:


Here is what I have found in my experimental version of the 10.4 tree.



Concerning C++ code libraries in the future 10.4 tree, IIUC there  
will be two non-intersecting subtrees ("T4" and "T3"), the first  
one compiled with g++-4.0, the other one with g++-3.3.


Actually, there will be three, since a small handful of programs  
still need g++-3.1.


Ideally T3 will be empty, but right now it cannot be, because any  
library that is or has to be compiled with g++-3.3 will force  
anything linked to it to belong to this subtree.


This is true, up to a point.  I have found that in some cases, either  
the linking in question doesn't use the c++-library from the  
dependent package, or the symbol mangling is apparently *not*  
incompatible.  So sometimes, a package using g++-3.3 can depend on  
some packages which use g++-4.0 (or vice versa).


Since Apple X11 is compiled with gcc-3.3, at least anything linked  
with libGLU will belong to T3, and this means among other things  
qt3, kde and anything related, probably also xfree86 and xorg.


I've compiled qt3 under g++-4.0, and used this qt3 to compile kde  
under g++-3.3, with no apparent problems.


Probably, though, we should use g++-3.3 for xfree86 and xorg so that  
fink's versions have the same linker properties as Apple's versions.


Getting more paranoiac, I notice that a lot of libraries in /System/ 
Library/Frameworks and some in /usr/lib are C++ code, too, so  
anything linked to Frameworks will need to be in T3. Example libapt- 
pkg.3.2.dylib (C++), linked to CoreFoundation (no C++(?)), linked  
to /usr/lib/libicucore.A.dylib (C++).


I have compiled apt under g++-4.0 with no problems.



My question is: Is it clear how strictly transitive this has to be,  
for example does apt have to be built with g++-3.3? Also, if there  
exists a binary that is linked to two C++ libraries, one of them in  
T3, does this mean the other one has to be in T3, too? Or will this  
binary be eliminated from the 10.4 tree, or will we just live with  
a certain (hopefully low) level of breakage?


The FSF has told us that libraries may be incompatible, but has not  
spelled out the conditions under which the libraries *are*  
incompatible.  So although the general rules are a good starting  
place, I think we can deviate from them when experiments prove that  
it is OK to do so.


  -- Dave



---
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