Re: HEADSUP maintainers: Change in openssl package requires change in setup.hint

[Gareth Pearce]

On 25/06/2010 7:02 AM, Yaakov (Cygwin/X) wrote:

On Thu, 2010-06-24 at 11:36 +0200, Corinna Vinschen wrote:
   

So, what we have to do is to convert *ALL* existing package dependencies
from "openssl" to "libopenssl098".  I'm going to do this in the
setup.hint files on cygwin.com, but, please do this in your local copy
of your setup.hint files as well.

As soon as I upgraded to openssl-1.0.0a-1, make sure that you keep your
package dependencies in shape when building a new package.  That means
to change from libopenssl098 to libopenssl100.
 

Do you know yet what the actual DLL names are going to be?  libkio
dlopen()s these instead of linking against them, so I want to fix these
for my next KDE release.

   

However, isn't libcurl3 OBSOLETE, rather than ORPHANED?
 

You are correct; I fixed this in CVS.

   

   apache2  ORPHANED (Max Bowsher)
 

This desperately needs to be ITA'd.  I have a version in Ports if anyone
who actually uses this wants to pick it up:

http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/www/apache2/

   

   cyrus-sasl/libsasl2  ORPHANED (Gareth Pearce)
   cyrus-sasl/libsasl2-develORPHANED (Gareth Pearce)
 

As previously discussed, these actually use libopenssl097.


Yaakov



   
I have no expectation that I will look at repackaging sasl ever - my 
motivation for that package is Long gone.


--Gareth

Re: [ITA] nano package

[Gareth Pearce]

Lapo Luchini wrote:

Lapo Luchini wrote:
  

Hi Gareth,
just a quick question: do you plan to support the current nano-2.0.x
branch in your Cygwin package relases?



Gareth replied privately to me that's ok with him if I adopt the package.

Should anyone take a look at the packaging?

http://cyberx.lapo.it/cygwin/nano/nano-2.0.6-1.tar.bz2
http://cyberx.lapo.it/cygwin/nano/nano-2.0.6-1-src.tar.bz2

Lapo

  

Just confirming the above.

Additionally, if anyone wants any of my other packages they are free to 
do so.  I read the mailing list and will respond to questions about my 
packages (if they don't get eaten by spam filtering or an overzealous 
delete key) but have no plans to update any of them.


--Gareth

RE: [HEADSUP] ALL Maintainers, please reply.

[Gareth Pearce]

Nano 
(Several unstable versions I could consider moving too but wont unless
interest is expressed, also some new stable versions, I guess I should
update.)

Aspell binaries and docs and dev and libaspell but not dictionaries. 
(There is a new version of this which I will upgrade too if any interest is
expressed, but I think it needs new versions of the dictionaries.)

Cyrus-sasl (includes libsasl2)
(Also has a new version which I'll do if anyone is interested; however I am
no longer working for the company which needed this library in cygwin so if
anyone wants to take over maintainership that's fine with me.)
 

Regards,
Gareth

PS, how did I become unsubscribed from cygwin-apps and yet still receive
email from it?

RE: Possible bug with generic build script.

[Gareth Pearce]

> 
> Well, I don't mind adding code that'll do both kinds of copies (using
> "install" in the flat case, and "tar" in the tree case), but the main
> question is how to distinguish between them?  I.e., as you said, does
> "doc/*.html" mean a flat copy or a tree copy?  Does "doc/*.html/" for tree
> copy look too ugly?  Do we ever want to flatten directory structure,
> anyway?  That is, can we always take "doc/*.html" to mean a tree copy?  Or
> do we just have two variables -- "install_docs" and "install_doc_dirs"
> (yuck!)?

If you really want to get ugly - add a 3rd and 4th,
"install_docs_target_base_dir" matching 1 for 1 entries in the above two. Or
stay with 2 and make every second entry the target dir.
Install_docs = "\
ChangeLog ${doc_root}/ \
Doc/ChangeLog* ${doc_root}/doc/ \ 
Doc/annoyingFile ${doc_root}/annoying/SubDir/ \
Doc/*/ImConfused/ ${doc_root}/nowhere/matched/ \
"

The disgusting possibilities are endless :)

On more realistic terms - I am thinking that 'tree copy with wild card
matching' and 'recursive tree copy probably without wild card matching' are
probably the most common concepts.  The 'flattened copy' shouldn't be needed
since theoretically the layout of the original package contents is
'reasonable'.  In my case I used flattened copy because a) it was easier to
do with the existing g-b-s and b) asthetics, having a docs subdir in a
documentation directory just seems wrong.  A) was a much stronger point then
b).

Regards,
Gareth Pearce

RE: Please test: openldap-2.2.17-2/libopenldap2_2_7-2.2.17-2/openldap-devel-2.2.17-2

[Gareth Pearce]

> 
> >>>>> Gareth Pearce writes:
> >>
> >> Hi Gareth,
> >>
> >> can you please *test* the following SASL enabled openldap release:
> >>
> 
> > I would love to, but the links all give me 404
> 
> Okidoki, try this one:


I have successfully used your openldap build to login and query a directory
using in directory SASL Digest-MD5 authentication.

Regards,
Gareth Pearce

RE: Possible bug with generic build script.

[Gareth Pearce]

> 
> Even simpler -- it works for wildcards aiming from a single target
> directory to a single source directory, i.e., it won't magically flatten a
> directory tree for you, you'll have to use "find" for that...
> 
> If you need to copy directory structures using the install_docs mechanism,
> I suppose it could be done with something like the patch below -- give it
> a shot.  You will have to put a "/" after each directory that you want
> copied as a tree.  The flattening is a bit harder, but still doable.
> 

Since you're just passing this list of files to install, install puts them
all in the one folder - hence 'flattening' everything.  The / trick is a
nice way to support recursive folder contents, if that was what you wanted
(my particular case has no need for that, its directory structure is fairly
flat).

In my version, I ended up making a separate install_docs for each target
directory - since there was only 2 target directories I wanted, this was no
real issue.  My original bug report was that wildcards were not working,
that is fixed.

The concept I had which is not addressed is where defining doc/*.html copies
into /usr/share/doc//doc/ rather then /usr/share/doc/ -
However such things are selective, some people might want the later in some
cases others the former.  My own case, I ended up doing both (to separate
main docs from the docs for a specific subprogram).  Not sure if addressing
this issue is worthwhile, there are too many options as to what might be
wanted.

Regards,
Gareth Pearce

RE: Possible bug with generic build script.

[Gareth Pearce]

> 
> On Wed, 13 Oct 2004, Charles Wilson wrote:
> 
> > Igor Pechtchanski wrote:
> >
> > > You're right, it *is* broken.  It was never intended to be used with
> > > subdirectories, so I never tested it.  I'll try to come up with a way
> > > of accomodating subdirs shortly.
> 
> In fact, it shouldn't've worked with wildcards either, the way it was
> written...  Oops.  The new patch should fix it, though -- still waiting on
> the confirmation.

The patch fixes my specific wild card case.

> 
> > I use tar when I need to do that, in my locally-modified gbs's.
> > Something like this:
> >
> > (cd theDocDirInSrcTree; tar cf aSubDir |\
> >tar -C ${instdir}${prefix}/share/doc/${PKG}-${VER} -xvf -)
> >
> > repeat as needed, or use a filelist of some kind instead of aSubDir.
> 
> Hey, neat.  This won't be needed if the filename is a wildcard, but if
> it's just a directory name, this could be useful.  I'm wondering whether
> to require people to explicitly specify wildcards (which will make the
> code clearer anyway), or to allow the use of directory names...  IOW,
> 'aSubDir/*' vs. 'aSubDir'...  I suppose if the tree at aSubDir is more
> than one level deep...

In cyrus-sasl there was two cases I wanted, one where the copying of files
in a wildcard/specified fashion occurred in a way which the resultant
directory structure matched the source and the other where the resultant
directory structure was flattened.  The current patch works for wildcards
aiming into a single target directory.

Regards,
Gareth Pearce

RE: Please test: openldap-2.2.17-2/libopenldap2_2_7-2.2.17-2/openldap-devel-2.2.17-2

[Gareth Pearce]

> 
> Hi Gareth,
> 
> can you please *test* the following SASL enabled openldap release:
> 

I would love to, but the links all give me 404

Regards,
Gareth Pearce

Update: cyrus-sasl 2.1.19-3 (bah!)

[Gareth Pearce]

And now for -3
Fixes all important missing files from libsasl2-devel - that is what I get
for checking whether a package works before I split it into three.
And I updated the inline copies of the setup.hints, no more posting at 3am
for me.

category: Utils
requires: libsasl2 cygwin
sdesc: "The Cyrus SASL API implementation."
ldesc: "The Cyrus SASL library allows for client/server authentication in
conformance with RFC ."
http://www.users.on.net/~gpearce/cyrus-sasl-setup.hint
http://www.users.on.net/~gpearce/cyrus-sasl-2.1.19-3.tar.bz2
http://www.users.on.net/~gpearce/cyrus-sasl-2.1.19-3-src.tar.bz2

category: Libs
requires: libsasl2 libdb4.2 openssl cygwin
external-source: cyrus-sasl
sdesc: "The Cyrus SASL API implementation. (Development files)"
ldesc: "The Cyrus SASL library allows for client/server authentication in
conformance with RFC ."
http://www.users.on.net/~gpearce/libsasl2-devel-setup.hint
http://www.users.on.net/~gpearce/libsasl2-devel-2.1.19-3.tar.bz2

category: Libs
requires: libdb4.2 openssl cygwin
external-source: cyrus-sasl
sdesc: "The Cyrus SASL API implementation. (Runtime library)"
ldesc: "The Cyrus SASL library allows for client/server authentication in
conformance with RFC ."
http://www.users.on.net/~gpearce/libsasl2-setup.hint
http://www.users.on.net/~gpearce/libsasl2-2.1.19-3.tar.bz2

Verified that openldap configure succeeds with this particular set of files.

Please Upload.

Regards,
Gareth Pearce
Security Developer
Panareef Pty. Ltd. (www.panareef.com)

Update: cyrus-sasl 2.1.19 (-2?)

[Gareth Pearce]

Updated packages - these are now correctly linked against libdb4.2 rather
than libdb4.1.  I also updated the setup.hint files.

Just in case -2 versions are preferred for this change, I built them too.

category: Utils
requires: libsasl2 cygwin
sdesc: "The Cyrus SASL API implementation."
ldesc: "The Cyrus SASL library allows for client/server authentication in
conformance with RFC ."
http://www.users.on.net/~gpearce/cyrus-sasl-setup.hint
http://www.users.on.net/~gpearce/cyrus-sasl-2.1.19-1.tar.bz2
http://www.users.on.net/~gpearce/cyrus-sasl-2.1.19-1-src.tar.bz2
http://www.users.on.net/~gpearce/cyrus-sasl-2.1.19-2.tar.bz2
http://www.users.on.net/~gpearce/cyrus-sasl-2.1.19-2-src.tar.bz2 
 
category: Libs
requires: libsasl2 libdb42 openssl cygwin
external-source: cyrus-sasl
sdesc: "The Cyrus SASL API implementation. (Development files)"
ldesc: "The Cyrus SASL library allows for client/server authentication in
conformance with RFC ."
http://www.users.on.net/~gpearce/libsasl2-devel-setup.hint
http://www.users.on.net/~gpearce/libsasl2-devel-2.1.19-1.tar.bz2
http://www.users.on.net/~gpearce/libsasl2-devel-2.1.19-2.tar.bz2 
 
category: Libs
requires: libdb42 openssl cygwin
external-source: cyrus-sasl
sdesc: "The Cyrus SASL API implementation. (Runtime library)"
ldesc: "The Cyrus SASL library allows for client/server authentication in
conformance with RFC ."
http://www.users.on.net/~gpearce/libsasl2-setup.hint
http://www.users.on.net/~gpearce/libsasl2-2.1.19-1.tar.bz2 
http://www.users.on.net/~gpearce/libsasl2-2.1.19-2.tar.bz2

 
Regards,
Gareth Pearce
Security Developer
Panareef Pty. Ltd. (www.panareef.com)

RE: libsasl2 libsasl2-devel setup.hint problems

[Gareth Pearce]

> 
> My mailbox was filled with these this morning.
> 
> - Forwarded message from Cron Daemon -
> 
> upset: *** warning package libsasl2 requires non-existent package libdb42
> upset: *** warning package libsasl2-devel requires non-existent package
> libdb42
> 
> - End forwarded message -
> 
> I've changed the name in the hint files to libdb4.2.

*cringe* - wonder how I missed that.

I wonder if the generic build script could lint setup.hint files based on
cygcheck output - 
And as I say that I discover (courtesy of cygcheck) that the system I built
the updated packages on doesn't even have libdb4.2 installed on it, and
hence undoubtedly the packages are dependent on libdb4.1 (and indeed they
are) - My connection is running Very slow so it'll be a 'little while'
before I can update this system so I can fix this bug.

Guess -2 will be a little bit sooner then I expected.

As a short-term patch maybe someone could change the requires field from
libdb4.2 to libdb4.1?

Gareth

Possible bug with generic build script.

[Gareth Pearce]

While I was packaging cyrus-sasl I ran into an odd issue with the installed
documentation.  I attempted to add doc/*.html to the install_docs variable,
this failed.  Oddly doc/*.fig worked - but there was only one doc/*.fig file
ChangeLog* also worked, and there was only one ChangeLog file.  It looks
like variable expansion occurs at -f ${srcdir}/$f in the for loop, which
looks broken to me (I am not a shell expert).
In the end I changed the contents of install_docs to be all of the form
${srcdir}/ and remove the ${srcdir}/ from the two lines inside the
for loop where they are actually installed.  This fixed the problem,
although now that I look again, I can't remember why.
  
Perhaps someone with some decent shell experience can see the best solution
here?

Regards,
Gareth Pearce

RE: [ITP] cyrus-sasl 2.1.19 (Read for upload?)

[Gareth Pearce]

> Christopher Faylor wrote:
> > On Tue, Oct 12, 2004 at 06:19:52PM +0200, Reini Urban wrote:
> >
> >>+1
> >
> >
> > Ditto.
> >
> +1
> 
> Or was the 'ditto' already enough?

Indeed it was.

Updated packages to satisfy the GTG reviews minor points are now available.

category: Utils
requires: libsasl2 cygwin
sdesc: "The Cyrus SASL API implementation."
ldesc: "The Cyrus SASL library allows for client/server authentication
in conformance with RFC ."
http://www.users.on.net/~gpearce/cyrus-sasl-setup.hint
http://www.users.on.net/~gpearce/cyrus-sasl-2.1.19-1.tar.bz2
http://www.users.on.net/~gpearce/cyrus-sasl-2.1.19-1-src.tar.bz2


category: Libs
requires: libsasl2 libdb42 openssl cygwin
external-source: cyrus-sasl
sdesc: "The Cyrus SASL API implementation. (Development files)"
ldesc: "The Cyrus SASL library allows for client/server authentication
in conformance with RFC ."
http://www.users.on.net/~gpearce/libsasl2-devel-setup.hint
http://www.users.on.net/~gpearce/libsasl2-devel-2.1.19-1.tar.bz2


category: Libs
requires: libdb42 openssl cygwin
external-source: cyrus-sasl
sdesc: "The Cyrus SASL API implementation. (Runtime library)"
ldesc: "The Cyrus SASL library allows for client/server authentication
in conformance with RFC ."
http://www.users.on.net/~gpearce/libsasl2-setup.hint
http://www.users.on.net/~gpearce/libsasl2-2.1.19-1.tar.bz2

Ready for upload?

Regards,
Gareth Pearce
Security Developer
Panareef Pty. Ltd. (www.panareef.com)

RE: [GTG] Re: [ITP] cyrus-sasl 2.1.19

[Gareth Pearce]

I'm certainly willing to make this change, reading the warning at the top of
saslauthd.mdoc left me sceptical as to whether it was a wise course of
action, but I see that man on cygwin handles the file just fine.

> What do you think of also including the nice documentation from
> {srcdir}/doc under /usr/share/doc/cyrus-sasl-2.1.19 and maybe the
> uppercase files from {srcdir}/saslauthd under
> /usr/share/doc/cyrus-sasl-2.1.19/saslauthd ?

Sounds like a good idea.

I will endeavour to have an updated package ready tomorrow.

Regards,
Gareth Pearce
Security Developer
Panareef Pty. Ltd. (www.panareef.com)

[ITP] cyrus-sasl 2.1.19

[Gareth Pearce]

As part of my work at Panareef I will be maintaining cyrus-sasl (and a copy
of openldap linked against it) internally and would like to contribute the
results back to the main cygwin distribution.  If accepted into the
distribution I would hope that the openldap maintainer would release a new
version linked against cyrus-sasl to allow sasl authentication to openldap.

SASL stands for simple authentication and security layer and provides a
pluggable system for authenticating and securing client/server connections.

It needed some help to compile out of the box and didn't produce dlls (and
the static libraries were useless, so I updated libtool/autoconf/automake
and fixed a few makefile/configure bugs.  I have successfully tested the
resultant dlls with openldap.  

category: Utils
requires: libsasl2 cygwin
sdesc: "The Cyrus SASL API implementation."
ldesc: "The Cyrus SASL library allows for client/server authentication
in conformance with RFC ."
http://www.users.on.net/~gpearce/cyrus-sasl-setup.hint
http://www.users.on.net/~gpearce/cyrus-sasl-2.1.19-1.tar.bz2
http://www.users.on.net/~gpearce/cyrus-sasl-2.1.19-1-src.tar.bz2


category: Libs
requires: libsasl2 libdb42 openssl cygwin
external-source: cyrus-sasl
sdesc: "The Cyrus SASL API implementation. (Development files)"
ldesc: "The Cyrus SASL library allows for client/server authentication
in conformance with RFC ."
http://www.users.on.net/~gpearce/libsasl2-devel-setup.hint
http://www.users.on.net/~gpearce/libsasl2-devel-2.1.19-1.tar.bz2


category: Libs
requires: libdb42 openssl cygwin
external-source: cyrus-sasl
sdesc: "The Cyrus SASL API implementation. (Runtime library)"
ldesc: "The Cyrus SASL library allows for client/server authentication
in conformance with RFC ."
http://www.users.on.net/~gpearce/libsasl2-setup.hint
http://www.users.on.net/~gpearce/libsasl2-2.1.19-1.tar.bz2


Regards,
Gareth Pearce
Security Developer
Panareef Pty. Ltd. (www.panareef.com)

RE: Heads-up: aspell-dev marked test

[Gareth Pearce]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Yaakov Selkowitz
> Sent: Monday, 26 July 2004 12:02 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Heads-up: aspell-dev marked test
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Yaakov Selkowitz wrote:
> 
> | Gareth,
> |
> | I just discovered today (the hard way, as usual) that aspell-dev
> | 0.50.3-1 is marked test.  Is there a reason for this?  The corresponding
> | aspell and libaspell15 packages are current, so I would think aspell-dev
> | should be too, right?
> 
> Ping?
Hrmm, I assume I missed the original when I emptied my email box while I was
on holidays.

I don't remember any reasons why aspell-dev should be test still.
I'll have a look at packaging up 0.50.5 'soon' and kill 2 birds with one
stone?

Gareth

RE: Pending Packages List, 2004-02-13

[Gareth Pearce]

> > Package: sgrep 1.92.1-1  [2003-09-15]
> > Package: joe 2.9.8-1  [2003-11-11]
> > Package: aspell-de 0.50.2-1  [2004-01-30]
> > Package: aspell-pl 0.50.2-1  [2004-01-30]
> 
> BTW, the last two above are dictionaries for an existing package -- should
> they need votes?  Is there a way to mark them as vote-exempt, but still
> needing reviews?

The last 2 also actually have all their votes and have been reviewed, only
hold up with that was discussion about internal versioning not matching
external versioning in some places.

> > ITP: tetrix  [2003-09-10]
> > Description: ESR's curses-based version of Tetris
> >HOLD-UPS: No package, nothing to review!
> >
> > ITP: graphviz  [2003-09-25]
> > Description: Open source graph drawing software
> >HOLD-UPS: No package, nothing to review!
> >
> > ITP: subversion 0.30-1  [2003-10-03]
> > Description: Client for Subversion revision control system
> >HOLD-UPS: No package, nothing to review!
> >
> > ITP: GAP  [2003-10-06]
> > Description: a famous group manipulation package
> >HOLD-UPS: Not enough votes (need 3). No package, nothing to review!
> >
> > ITP: ns  [2003-10-18]
> > Description: The Network Simulator - ns-2
> >HOLD-UPS: Not enough votes (need 3). No package, nothing to review!
> 
> These have been on the PPL for ages with no activity.  Should there be a
> timeout?

Perhaps ones which don't get enough votes should time out, but ones which
obtain the required votes before there is even a package, probably should be
left in a 'wanted' list - perhaps after a timeout drop the listing of having
someone who submitted the idea.

I still do intend to package graphviz just waiting for an appropriate amount
of time to spend on it.

Gareth Pearce
PS yes, I changed emails.

Re: [ITP] gnuchess-5.07 - New package for review

[Gareth Pearce]

Jari Aalto wrote:
| Time to relax, so get gnuschess + xboard and start playing:
I vote pro gnuchess and xboard.
I vote pro gnuchess and xboard as well.

Gareth Pearce

_
E-mail just got a whole lot better. New ninemsn Premium. Click here  
http://ninemsn.com.au/premium/landing.asp

RE: [ITP] aspell-de-0.50.2 - German dictionary files for aspell

[Gareth Pearce]

> 
> On 2004-01-30T14:12+0100, Dr. Volker Zell wrote:
> ) wget http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/aspell-
> de/setup.hint
> ) wget http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/aspell-
> de/aspell-de-0.50.2-1-src.tar.bz2
> ) wget http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/aspell-
> de/aspell-de-0.50.2-1.tar.bz2
> 
> When I extract this, I have .README and doc files for aspell-de-0.50-2
> (instead of 0.50.2-1). If that is correct, I can renumber it to 0.50-2 in
> apps.xml and upload, otherwise just let me know when to re-download.
> 

The Original package is 0.50-2
In order to be compatible with cygwin naming conventions the - is converted
to . before adding the cygwin package -1.
I wouldn't think that the use of original package numbering in original
package documentation is worth a patch.

Gareth

RE: [ITP] aspell-pl-0.50.2: Polish dictionary files for aspell

[Gareth Pearce]

> 
> Hi
> 
> I would like to contribute and maintain the aspell-pl package:
> 
>  *  http://aspell.net/  (Homepage)
>  *  http://ftp.gnu.org/gnu/aspell/dict/ (Download location)
> 
> 
>   ! Download size 9 MB 
> 
> Ciao
>   Volker
> 

Official aspell dictionaries definitely get my vote.

Aspell-de +1 as well.

Gareth

RE: doxygen 1.3.5 vs 1.2.18 (?)

[Gareth Pearce]

Yes I've been dealing with some personal issues which mean I've done ...
pretty much nothing lately.  No one should feel like they are waiting on me,
it'll probably be a little while before I redo my doxygen package.  If
someone else does it first, that would be great.  And while graphviz got the
votes, there was never a clear decision on the legal status, and I haven’t
yet done the obvious thing and attempted to follow it up with the graphviz
people themselves.

FWIW I did manage to get upstream to patch the doxygen textmode bug, I just
haven’t done anything since then.

Gareth
PS: I realise there is a new version of aspell, and a beta of nano to
consider - I'll get round to looking at them shortly, I hope!

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Jörg Schaible
> Sent: Wednesday, 21 January 2004 3:15 AM
> To: CygWin-Apps
> Subject: RE: doxygen 1.3.5 vs 1.2.18 (?)
> 
> Lapo Luchini wrote on Tuesday, January 20, 2004 4:26 PM:
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Hi,
> > I'm just curious about work on a "newer" doxygen package: is
> > it under way? there are reasons not to?
> 
> Original maintainer has been disappeared long ago. Gareth Pearce once
> wanted to take over and sent also an ITP for the related graphviz, but
> I've not heard anything from him about these packages for some months,
> too. So ...
> 
> > of course "I don't
> > have time" and/or "1.3 is not a stable branch" are perfectly good
> > reasons ^_^)
> 
> 
> Regards,
> Jörg

RE: sgml-base-1.1

[Gareth Pearce]

> 3. Package openjade and opensp. These don't build with gcc3 yet, so that
> might
> take a while. This would allow users to build cygwin-doc with tools
> available
> from the Cygwin net release (with the possible exception of the info
> manual).

If I remember correctly, I've gotten jade on a gcc3 platform before, the
requisite hacks weren't too evil I think... (was a couple of years back when
I was making gnome work on osf/1 4.0d - using gcc-mainline at the time... so
I don't remember the details - it might have been that I used a different
jade then openjade though...)

Oh and a vote for sgml-base.

Gareth

RE: [ITP] ImageMagick

[Gareth Pearce]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Ronald Landheer-Cieslak
> Sent: Thursday, 4 December 2003 1:04 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [ITP] ImageMagick
> 
> On Wed, Dec 03, 2003 at 11:07:59PM +1100, Gareth Pearce wrote:
> > > -Original Message-
> > > On Behalf Of Corinna Vinschen
> > > Sent: Wednesday, 3 December 2003 10:30 PM
> > > Subject: Re: [ITP] ImageMagick
> > > On Wed, Dec 03, 2003 at 03:27:48AM -0500, Harold L Hunt II wrote:
> > > > I would like to contribute and maintain ImageMagick:
> > >
> > > Yes!<-- This is a vote
> >
> > And I thought with Harold packaging it wouldn't need a vote... or I
> would of
> > already.
> AFAIK, XFree packages don't need votes. I don't think ImageMagick is an
> XFree
> package - is it?

Ahh you are indeed correct. Silly me.

> 
> rlc

RE: [ITP] ImageMagick

[Gareth Pearce]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Corinna Vinschen
> Sent: Wednesday, 3 December 2003 10:30 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [ITP] ImageMagick
> 
> On Wed, Dec 03, 2003 at 03:27:48AM -0500, Harold L Hunt II wrote:
> > I would like to contribute and maintain ImageMagick:
> 
> Yes!<-- This is a vote
> 
> Corinna
> 

And I thought with Harold packaging it wouldn't need a vote... or I would of
already.

> --
> Corinna Vinschen  Please, send mails regarding Cygwin to
> Cygwin Developermailto:[EMAIL PROTECTED]
> Red Hat, Inc.

RE: [Review 2 - Good to go] gd: A graphics library for fast image creation

[Gareth Pearce]

> Hmm... just noticed that you have libgd2 and libgd2-devel... I was under
> the impression that you should stick the DLL version in the libgd
> package name, which you did, but I thought that the DLL version number
> was *not* included in the -devel package name.
> 
> It seems to me that the devel package should be called:
> 
> libgd-devel
> 
> 
> Anyone care to comment on this?

It would be nice to say that versioned devels are never necessary, but
unless the internals of the package are designed so as to be able to coexist
with future version devels (like libgd2 would be), there isn't any point
versioning them, and hence should not be so.

> 
> 
> Harold

RE: [ITP] gd: A graphics library for fast image creation

[Gareth Pearce]

If a vote for gd is a vote towards gnuplot, you have my vote.

> 
> I would like to contribute and maintain the gd package:
> 
>  * http://www.boutell.com/gd/   (Homepage)
>  * http://www.boutell.com/gd/http/  (Download location)
> 
> My goal is to contribute the gnuplot package
> 
>  * http://gnuplot.info/
> 
> which uses the gd library.
> 
> Ciao
>   Volker
> 
> --

RE: Setup and downloading software...

[Gareth Pearce]

> I understand this may not be a very high priority as many people are
> probably using Broadband now, but I know I would appreciate it, and I
> imagine many others would too.  I know this wouldn't really be much of an
> issue except that I've noticed in my downloads that I average between 1.7
> and 2.6 kb/s on my 56k modem, which is about 1/3 of the rate I could
> theoretically get. (Most of my downloads for other sites are around 4 to 6
> kb/sec.) I figure this is because the sites are so busy, and I figure that
> striping the downloads could help to speed some people up to help
> alliviate
> the sites of those users.

Just think for a second and realise that if this was the case, then the
broadband people would be noticing it a lot more.  Striping is much more
likely to help broadband users then it is modem users.  That said, some
mirrors do get overloaded - but 2k/sec would be unusual I suspect.  Btw -
all of the downloads from setup are precompressed - so ensure your comparing
apples with apples when comparing download speeds.  Modems use inbuilt
compression - so non-compressed files will download faster.  3k-sec is (once
you consider overheads) not to far off 30kbit - most 56k modems actually
rarely see connections over 42k (to my knowledge anyway)  - so your actually
more like half rather then 1/3rd. - 'back home' on my 56k modem - 2.6k/sec
on a compressed file would be considered fast.  But then 'back home' has
poor phone lines. - I'm lucky enough to have adsl where I'm living at the
moment - and the mirrors I use for setup - are easily fast enough to handle
a modem user.

Gareth

RE: Maintainers/Packages List, 2003-11-01

[Gareth Pearce]

> This is the list of maintainers and packages as of Saturday, November  1,
> 2003.
> 
> This list is generated using information from a variety of sources,
> including
> the live repository, the package coordinator's records, and software-
> tracking
> sites such as freshmeat.net. Packages that appear to be neglected are
> flagged
> with a triple gunshot ("!!!") and the reason for the flag.
> 

Wow - this is some nice work.

Just a suggestion - a maintainer with *all* packages appearing to be
neglected could get special notice?

Gareth - probably should find some time and put graphviz up for review.

RE: gcc-core installed accidently

[Gareth Pearce]

> 
> Hallo,
> 
> Somoehow setup.exe installed the gcc source package gcc-core for me,
> however I only wanted to install the binaries and it was also not
> listed in the Up-To-Date section after I tried to uninstall the source
> again.  What I did now was to explicit install gcc-core (the source
> package) and then removed it with setup.exe again.
> 
> I cannot say how it happened, there is no other package listed which
> requires gcc-core.
> 
> Any idea?

Its in section misc?

Gareth - is actually asleep.

'check' is in category misc

[Gareth Pearce]

This doesn't really seem appropriate to me.  Devel maybe?

Gareth

RE: Pending Packages List, 2003-10-08

[Gareth Pearce]

> 
> Daniel Reed wrote:
> 
> >ITP: graphviz
> >   HOLD-UPS: Not enough votes (need 2 more). No package, nothing to
> review!
> >
> >
> I use it to create GPG trust relationsships graphs.. I guess it wuold be
> handy to have on (standard) Cygwin.
> Aye.

Additional hold-ups for this one should include - no official determination
of legality - or should I be contacting at&t to decipher that?  I'm not
bothering to actually package it until said determination is made.

> 
> >ITP: subversion 0.30-1
> >   HOLD-UPS: Not enough votes (need 2 more). No package, nothing to
> review!
> >
> >
> I'd like very much to have this one on cygin =)

Ditto.

Gareth

RE: ITP: graphviz (and doxygen?)

[Gareth Pearce]

> > If Debian has put it under non-free it does not meet Debian's poliy for
> main.
> > It's problamy not compatible with GPL or the OpenSource Definition
> > >
> > > For reference:
> > > http://www.research.att.com/sw/tools/graphviz/license/index.html
> > > http://www.research.att.com/sw/tools/graphviz/download.html
> >
> > I could not find the license under OSD Approved Licenses. And it's way
> too
> > longer to get an idea about it without spending several hours with a
> lawyer 8-(
> > http://www.opensource.org/licenses/index.php
> 
> Gareth,
> 
> If all you need in GraphViz is DOT, you may consider distributing VCG
> () instead.  It's
> graph description language is very similar to DOT's, and it's GPL'd.

Hrmm looks interesting, I've had no luck finding an interface to doxygen yet
though, which is the only thing 'I' use dot for.

I think I'll at least package up a new doxygen for now.  Graphviz is still
short on votes ;) - reguardless of its legal status.

RE: ITP: graphviz and doxygen (seperately)

[Gareth Pearce]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Jörg Schaible
> Sent: Friday, 26 September 2003 2:33 AM
> To: [EMAIL PROTECTED]
> Subject: RE: graphviz (and doxygen?)
> 
> Hi Gareth,
> 
> Gareth Pearce wrote on Thursday, September 25, 2003 6:18 PM:
> > Somewhat amusing little bug - the code correctly supports
> > textmode - if the #define had of been in the file with the
> > #ifdef that dependend on it...
> >
> > It appears I have a nice working version, works on
> > text/binary mounts - 'dot' is working with both now too. (I
> > think it was being fed corrupt data
> > before)
> >
> > So shall I package it up?
> 
> sounds great. Personally I would split it up into two separat packages
> (graphviz and doxygen), because Graphviz may be used by other packages or
> applications too and it is only optional to doxygen. Since they are used
> quite often together you may put a dependency for graphviz into the
> doxygen setup.hint file.

Well I was never intending to put them in one - separate original source
tar.gz's files - so putting them together would be crazy.

I am thinking of putting doxygen documentation in a separate package.

I don’t think a dependency is a good idea - if we had suggests - I would,
but until then I'd just leave them separate.  Might mention it in any
announcements about said packages.

Anyway...
Was that a vote for graphviz?

Regards,
Gareth

RE: graphviz (and doxygen?)

[Gareth Pearce]

> >
> > Gareth Pearce wrote on Thursday, September 25, 2003 2:05 PM:
> > >Also - I'm willing to (try to)update (and maintain there after) -
> > >doxygen Preferably with graphviz to go with it.  This is assuming that
> > >the position is open.  I've built 1.3.4 - and run it over a 90thousand
> > >line project - using graphvis 1.10.0 'dot' - haven't noticed anything
> > >odd yet.
> >
> > did you also tried to run it, if your sources and the config are located
> > on a text mount? The old version gave hundreds of errors concerning a
> non-
> > valid font, while the same sources (converted to Unix style) run fine
> from
> > a binary mount.
> 
> I created a textmounted dir /textmount - copied my source files in there.
> I used nano to save as dos, for a couple of source files and for my
> Doxyfile.
> 
> I get no errors from the doxygen run itself - unless I turn HAS_DOT on.
> However the web pages have no pictures.  It looks like its writing the
> pictures to file without setting binary flag.
> 
> I'll see what I can find.

Somewhat amusing little bug - the code correctly supports textmode - if the
#define had of been in the file with the #ifdef that dependend on it...

It appears I have a nice working version, works on text/binary mounts -
'dot' is working with both now too. (I think it was being fed corrupt data
before)

So shall I package it up?

Gareth

RE: please use consistent announce messages

[Gareth Pearce]

> If you are releasing a package, please use an announce message that is
> 
> I don't really care about the case of the message but the case should
> reflect the case of the package and, my personal preference is to
> uppercase the first word of the "New" or "Updated".

*tries to look innocent*

The fact I accidentally capitalised aspell in my last two announcement
attempts wasn't why they disappeared was it?

Gareth

re: graphviz (and doxygen?)

[Gareth Pearce]

> 
> Gareth Pearce wrote on Thursday, September 25, 2003 2:05 PM:
> >Also - I'm willing to (try to)update (and maintain there after) -
> >doxygen Preferably with graphviz to go with it.  This is assuming that
> >the position is open.  I've built 1.3.4 - and run it over a 90thousand
> >line project - using graphvis 1.10.0 'dot' - haven't noticed anything
> >odd yet.
> 
> did you also tried to run it, if your sources and the config are located
> on a text mount? The old version gave hundreds of errors concerning a non-
> valid font, while the same sources (converted to Unix style) run fine from
> a binary mount.

I created a textmounted dir /textmount - copied my source files in there.
I used nano to save as dos, for a couple of source files and for my
Doxyfile.

I get no errors from the doxygen run itself - unless I turn HAS_DOT on.
However the web pages have no pictures.  It looks like its writing the
pictures to file without setting binary flag.

I'll see what I can find.

Gareth
> 
> >To build doxygen I had to force it to link with the system
> >libpng.dll.a instead of its own static libpng.
> 
> IIRC that was because of changes Dimitri made to the png sources. But
> don't ask me what and why ...
> 
> Regards,
> Jörg

ITP: graphviz (and doxygen?)

[Gareth Pearce]

Graphviz, which is the source of the 'dot' program which doxygen can use to
produce some very nice inheritance/collaboration diagrams.  It is more
generally used for the creations of diagrams, using automatic layout, of
directed and undirected graphs.

It 'just about' compiles out of the box, but it is not an application I've
used directly - 'dot' seems to work fine for doxygen though.

One thing to note is that in debian it is distributed under non-free.  So
perhaps someone might like to comment on if the license is valid for
setup.exe distribution.

For reference:
http://www.research.att.com/sw/tools/graphviz/license/index.html
http://www.research.att.com/sw/tools/graphviz/download.html

Also - I'm willing to (try to)update (and maintain there after) - doxygen
Preferably with graphviz to go with it.  This is assuming that the position
is open.  I've built 1.3.4 - and run it over a 90thousand line project -
using graphvis 1.10.0 'dot' - haven't noticed anything odd yet.  To build
doxygen I had to force it to link with the system libpng.dll.a instead of
its own static libpng.

Regards,
Gareth

RE: HEADSUP: Please resend all open ITPs, please review packages

[Gareth Pearce]

> 
> On Thu, Sep 25, 2003 at 10:37:57AM +0200, Corinna Vinschen wrote:
> > The open ITPs I know so far are:
> >
> > Package:gmp-4.1.2-1
> > Sdesc:  GMP is a free library for arbitrary precision
arithmetic
> > Maintainer: Lapo Luchini
> > Votes:  2
> > Reviewed:   yes
> > Open because:   1 vote missing
> > Urls:   http://www.lapo.it/tmp/gmp-4.1.2-1-src.tar.bz2
> > http://www.lapo.it/tmp/gmp-4.1.2-1.tar.bz2
> Did I already vote for this? If not, I'm doing so now :)

Ditto.


Gareth

License restrictions? (graphviz)

[Gareth Pearce]

> > doxygen Ryunosuke Satoh
> 
> I just want to point out, that the astyle maintainer also has the
> ownership of doxygen. The doxygen version does not work correctly on text
> mounts and Ryunosuke confirmed me this lastly (after some private email
> conversation 1 year ago), but he neither build a version with corrected
> open modes nor did he update doxygen to the current version 1.3.x (where x
> is meanwhile 3). So I suppose that doxygen is abandonned too.

Doxygen chatter made me remember something I was interested in maintaining. 
Graphviz, which is the source of the 'dot' program which doxygen can use to
produce some very nice inheritance diagrams.

I guess the main issue I wondered about was whether the at&t 'open source'
licence used is compatible with the practicalities and ethos of the
setup.exe distribution.  Its distributed as part of debian 'non-free' so I
imagine it can't be too bad, but I'm not one to understand legalize all that
well.

Regards,
Gareth

For reference:
http://www.research.att.com/sw/tools/graphviz/license/index.html
http://www.research.att.com/sw/tools/graphviz/download.html

RE: List of package owners

[Gareth Pearce]

> 
> Take it.
> I only wanted to "play" with it to get it working for me any way.
> I'll find something else to contribute.
> Robert
> 

I don't have an express desire to maintain m4 - I only said I would consider
doing it, cause I like to try and be helpful and fill gaps which I can
manage.  M4 looked more on my scale then gcc(heh) - so I'm having a look.

Not to pressure - just wanted to make it clear that I'm not saying I'll
maintain it Yet.  I don't want for there to be a situation where others
aren't offering because I've merely said I'm thinking about it.  But if the
'I'm interested' (which sounded fairly positive) - was just for personal use
then I guess I'm not saying much.

Gareth

RE: List of package owners

[Gareth Pearce]

Robert wrote:
> 
> Sure. I'm interested.
> I already downloaded the package from CVS.
> 

Okay - I'll not bother looking any further into things myself for now.

> 
> Gareth wrote:
> > Hmm despite the apparent lack of upstream development on this one - m4
> is
> > pretty rock solid (compared to astyle at least) ... I'll have a deeper
> look
> > to see if I'm willing to offer on this one.

Chuck wrote:

> 
> Well, actually Gary V. Vaughan has been working hard on m4 all summer.
> If you grab CVS
> 
> cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot/m4 login anonymous
> 
> cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot/m4 co m4
> 
> you'll see that the whole thing has been modularized with plugins.  I
> sent Gary some patches last week and he incorporated them, but there are
> still a number of issues with building it cleanly on cygwin.

Interesting - my preliminary investigation found a version with modularised
plugins "this close to releasing 1.5" - last updated 3 years ago.

Good to hear there's some development again.

Gareth

RE: List of package owners

[Gareth Pearce]

> 
> I suspect that a few packages are also unmaintained.  Is the astyle
> maintainer still around, for instance?

FWIW if the astyle maintainer didn't pipe up I was going to offer to
maintain it in their absence. However a quick investigation shows that
upstream astyle has had no development in over a year - which means no one
for me to push bugs at. (and there are bugs, heheh) - And I don't intend to
become the developer for astyle...

> 
> There are a few packages that lack owners.  The most notable may
> be m4.  Chuck and I exchanged some private email about this last
> week.  Anyone up for maintaining m4?
> 

Hmm despite the apparent lack of upstream development on this one - m4 is
pretty rock solid (compared to astyle at least) ... I'll have a deeper look
to see if I'm willing to offer on this one.

Regards,
Gareth

RE: List of package owners

[Gareth Pearce]

> aspell      Gareth Pearce*
> aspell-dev  Gareth Pearce*
> aspell-doc      Gareth Pearce*
> aspell-en       Gareth Pearce*

Aspell-en is actually RLC
Secondly - I have sent an announce post for aspell (which also covers
aspell-en), but it seems to have disappeared into the ether?  I don't see
any bounce message in my email account.

Regards,
Gareth

> bashRonald Landheer-Cieslak

RE: HEADSUP: test packages

[Gareth Pearce]

> a short `find' shows, that the following packages have "test" releases:
> 
> - gcc test: 3.3.1-1
> - gziptest: 1.3.5-1
> - perltest: 5.8.1-1
> - aspell-dev  test: 0.50.3-1
> - gnupg   test: 1.2.2-2
> - gcc-mingw   test: 20030911-2
> - mc  test: 4.6.0a-20030721-1
> - cmake   test: 1.6.7-2
> - xerces-ctest: 2.3.0-3
> - nasmtest: 0.98.37-2
> - lftptest: 2.6.6-1
> 
> I'd like to see a feedback from the package maintainers, whether the
> test marker is appropriate or it's just a 1.5.x built package which
> is accidentally still marked test.
> 

Aspell-dev is test due to gcc being test and it being a c++ library.

Regards,
Gareth

clisp is in section misc?

[Gareth Pearce]

I don't think everyone wants to install it.

Regards,
Gareth

RE: Aspell ... (ready?)

[Gareth Pearce]

> >AFAIC, we're ready.
> >I'll repeat the URLs for the dictionaries:
> >
> >04be855c088559b4682b5495510234fe *aspell-en-0.51.0-1-src.tar.bz2
> >http://rlc.unsane.co.uk/aspell-en-0.51.0-1-src.tar.bz2
> >33fad88cd4d517596ebab42d368ba750 *aspell-en-0.51.0-1.tar.bz2
> >http://rlc.unsane.co.uk/aspell-en-0.51.0-1.tar.bz2
> >
> >Gareth pointed to the following URLs in
> >http://www.cygwin.com/ml/cygwin-apps/2003-09/msg00176.html:
> >
> >http://www.users.on.net/gpearce/aspell-0.50.3-1-src.tar.bz2
> >http://www.users.on.net/gpearce/aspell-bin-0.50.3-1.tar.bz2
> >http://www.users.on.net/gpearce/aspell-bin.setup.hint
> >http://www.users.on.net/gpearce/aspell-dev-0.50.3-1.tar.bz2
> >http://www.users.on.net/gpearce/aspell-dev.setup.hint
> >http://www.users.on.net/gpearce/aspell-doc-0.50.3-1.tar.bz2
> >http://www.users.on.net/gpearce/aspell-doc.setup.hint
> >http://www.users.on.net/gpearce/libaspell15-0.50.3-1.tar.bz2
> >http://www.users.on.net/gpearce/libaspell15.setup.hint
> >
> >Gareth says in http://www.cygwin.com/ml/cygwin-apps/2003-09/msg00179.html
> >that there's no need to mark them as test, despite the fact that the gcc
> >he used is still marked as such. Personally, I'd mark at least aspell-dev
> >as test, seeing as that contains the files that won't work with the
> current
> >gcc, but it's his call (he's the maintainer, after all :)
> 
> I hate to do this at this late point (and I *really* hate it when people
> do it to me) but I didn't notice the slightly nonstandard practice of
> naming the binary 'aspell-bin'.  I'd like to change that.  Otherwise
> we have a base package which only contains source, which is also
> unusual.  I'd prefer to "mv aspell-{bin-,}0.50.3-1.tar.bz2" and
> put it at the top level of the aspell directory and move everything else
> underneath it.
> 
> Gareth, do you have a problem with that?

I have no problem with either of the above 2 points in theory... both the
rename and the marking of aspell-dev as test. (and adding dependency on
aspell-en - from other email)
In practice there is one niggle, the src package generates
aspell-0.50.3-1.tar.bz2 already - but it's the amalgam of all of the other
binary packages.  It produces aspell-bin.  Fixing this will probably only
take me a couple of minutes (when I get the time say in a couple of days) -
but I don't think that it should be a show stopper for uploading the rest
now.
Renaming the file and changing the hint files are trivial - I'm assuming you
don't need me to upload them again?  If you do want me to do them then I'll
do it whenever I see the reply which will be ... after I sleep probably.

Regards,
Gareth

Re: Aspell ... (ready?)

[Gareth Pearce]

Doh - i forgot gcc 3.3.1 is 'test' - but indeed - if theres Anyone who wants
to develop with libaspell before gcc test version goes real - i think they
can use the test ... no?

I dont really think that aspell needs to be marked as test because of this.

Gareth

> You haven't marked them as "test" while gcc-3.3.1 isn't canonical yet. It
> won't harm (much) I think, but it might if someone wants to go ahead and
> develop something with libaspell..
>
> rlc

Re: Aspell ... (ready?)

[Gareth Pearce]

> > inspired by this hat - I ask ... is there anything stoping us doing the
> > coordinated release of the aspell and dictionary this weekend?  I was
fairly
> > sure that the last available version (which was compiled by rlc not me,
but
> > otherwise was perfectly normal) didnt recieve any aditional feedback.
> >
> > Gareth - the not-quite-just-yet owner of the new-but-not-spiffy aspell
> > maintainership hat.
> Your hat isn't spiffy?
> Anyways, AFAIC, Aspell is ready to roll..
> I just don't remember whether what I put on my site is still there..
> hmm..
> [checking]
> hmm.. no longer there..
> Do you still have them, Gareth, or should I make them available again?

okay - recompiled with gcc 3.3.1 (libaspell is c++ library) - and appearing
all nice and functional. (for me at least)

ready for upload?

http://www.users.on.net/gpearce/aspell-0.50.3-1-src.tar.bz2
http://www.users.on.net/gpearce/aspell-bin-0.50.3-1.tar.bz2
http://www.users.on.net/gpearce/aspell-bin.setup.hint
http://www.users.on.net/gpearce/aspell-dev-0.50.3-1.tar.bz2
http://www.users.on.net/gpearce/aspell-dev.setup.hint
http://www.users.on.net/gpearce/aspell-doc-0.50.3-1.tar.bz2
http://www.users.on.net/gpearce/aspell-doc.setup.hint
http://www.users.on.net/gpearce/libaspell15-0.50.3-1.tar.bz2
http://www.users.on.net/gpearce/libaspell15.setup.hint

Regards,
Gareth

Aspell ... (ready?)

[Gareth Pearce]

> -- 
> 
>++
>| BB |  <-- my spiffy new Cygwin Bash Maintainer Hat ;)
>| AA |
>| SS |
>| HH |
>  +-Cygwin-+
>   | o  o |
>   |  ||  |
>   \ \__/ /
>\/
> 

inspired by this hat - I ask ... is there anything stoping us doing the
coordinated release of the aspell and dictionary this weekend?  I was fairly
sure that the last available version (which was compiled by rlc not me, but
otherwise was perfectly normal) didnt recieve any aditional feedback.

Gareth - the not-quite-just-yet owner of the new-but-not-spiffy aspell
maintainership hat.

Re: [ITP] GMP & NTL libraries

[Gareth Pearce]

>
> I didn't even try to compile them, yet, but being mathematical packages
> I fear not they may not compile.
> So I'm beginning to ask the list if there is interest in those two
> "number theory / big integer" libraries.
>
> http://www.swox.com/gmp/
> http://www.shoup.net/ntl/
>
> (I think I'll compile NTL in the "use GMP for faster base arithmetic"
> method so NTL will depend upon GMP, while GMP should depend on nothing
else)
>
> - --
I imagine gmp should be not too bad - i'll express interest in it since i
think its going to be needed to compile g95 fortran... and ofcourse that its
cool...

Gareth

please upload: nano 1.2.2-1

[Gareth Pearce]

Hi,

nano 1.2.2-1 is ready for distribution
in this release
- FHS conformance
- linked against newer ncurses (screen corruption things may have gone away
as a result)
- built with cygwin 1.5.3
- miscilaneous bug patches in nano itself
files:
http://users.on.net/gpearce/setup.hint

http://users.on.net/gpearce/nano-1.2.2-1.tar.bz2

http://users.on.net/gpearce/nano-1.2.2-1-src.tar.bz2

Regards,
Gareth - will probably have aspell up tommorow.

Re: Test packages, or lack thereof (was It's a snapshot)

[Gareth Pearce]

nano i'll update to 1.2.2 when 1.5.* goes live
aspell is ready and waiting for 1.5 - or was last time i remember...

Gareth
- Original Message - 
From: "Elfyn McBratney" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, August 22, 2003 12:52 PM
Subject: Test packages, or lack thereof (was It's a snapshot)


> Christopher Faylor <[EMAIL PROTECTED]> wrote:
> > If there are no serious issues with this version then I will probably
> > flip the switch and make 1.5.3 the latest, current version of cygwin,
> > switching all of the test versions of packages to be current at that
> > time.
> 
> What's the plan regarding packages that haven't gone into a 'test' phase?
> I haven't even started (well, I'm configuring now) mine.
> 
> Just curious,
> 
> -- Elfyn
> 

Re: Pending package status (20 Jul 2003)

[Gareth Pearce]

Trying to find out everything thats been happening ... my hotmail clogged up
and a whole stack of email didnt get delivered - somewhat of a mess.  It
even deleted some of my older emails - annoying. - in future i'll not keep
any old emails around in hotmail :)

> I'd rather let Gareth take a look at these first before they're put up as
> "available" - he's the maintainer, after all :)

i rebuilt from source package - and things look good. (except i forgot to
install ncurses first so ... i had the funny buggy letter thing again)
>
> So the canonical versions of the Cygwin packages should (IMHO) be
> considered the versions Gareth provided - at least until he canonicalizes
> mine.
I'd say they look fine.

Regards,
Gareth

Re: [UPDATE] Pending package status (11 Jul 2003)

[Gareth Pearce]

back from skiiing - with lots of catching up to do...


> On Fri, 11 Jul 2003, Christopher Faylor wrote:
>
> > On Fri, Jul 11, 2003 at 09:54:06PM -0400, Igor Pechtchanski wrote:
> > >I guess I'll have to become one quickly, for my votes to count...
> >
> > How about coreutils?
> >
> > Or has someone already volunteered for that?
>
> I think Gareth half did. You can have findutils, Igor. ;-)
umm i dont remember this ... - i half volunteered for gcc - but lifes far
too busy for that at the moment.

I should get a look see at the new versions of my aspell packages from rlc -
shortly...

>
> Elfyn
>
> -- 
> Elfyn McBratney, EMCB
> http://www.emcb.co.uk
> [EMAIL PROTECTED]
>
>
>

Re: Pending package status (11 Jul 2003)

[Gareth Pearce]

> > @ Aspell
> >
> > date   : 07 Apr 2003
> > version: 0.50.3-1
> > status : not reviewed
>
> > notes  : http://cygwin.com/ml/cygwin-apps/2003-04/msg00155.html
> >  http://cygwin.com/ml/cygwin-apps/2003-04/msg00356.html
> >  http://cygwin.com/ml/cygwin-apps/2003-06/msg00239.html
>
> The last note mentions that it doesn't work.  Has this been addressed?

I believe what was stated was that it didnt work from within mutt - I
personaly had only tested it from the command line.  (which is where i
personally have used (i|a)spell from in the past)

However I've been busy marking (and before that, without a functioning
internet connection on my windows pc) - and since I had to format my machine
a few weeks back, havent reinstalled my own packages to test the problem
described.
I am away for the next week skiing - but my internet connection is now all
good(wondeful infact) so when I get back I'll give it a go - (or if rlc
wants to give it ago first while I'm gone, by all means) - I actually think
i tested my package with nano as internal speller - but that might be a
figment.

Regards,
Gareth

Re: [UPDATE] Pending package status (25 Jun 2003)

[Gareth Pearce]

(correction)
libaspell is under
http://www-personal.usyd.edu.au/~gpea0679/aspell/libaspell/libaspell15-0.50.3-1.tar.bz2

too many different 'personal website' directory layout formats for me...
and I only have 3.

Gareth

Re: [UPDATE] Pending package status (25 Jun 2003)

[Gareth Pearce]

(correction)
libaspell is under
http://www-personal.usyd.edu.au/~gpea0679/aspell/libaspell/libaspell15-0.50.3-1.tar.bz2

too many different 'personal website' directory layout formats for me...
and I only have 3.

Gareth

Re: [UPDATE] Pending package status (25 Jun 2003)

[Gareth Pearce]

(correction)
libaspell is under
http://www-personal.usyd.edu.au/~gpea0679/aspell/libaspell/libaspell15-0.50.3-1.tar.bz2

too many different 'personal website' directory layout formats for me...
and I only have 3.

Gareth

Re: [UPDATE] Pending package status (25 Jun 2003)

[Gareth Pearce]

(correction)
libaspell is under
http://www-personal.usyd.edu.au/~gpea0679/aspell/libaspell/libaspell15-0.50.3-1.tar.bz2

too many different 'personal website' directory layout formats for me...
and I only have 3.

Gareth

Re: [UPDATE] Pending package status (25 Jun 2003)

[Gareth Pearce]

> > 16. Aspell-en
> >
> > date   : 19 Jun 2003
> > version: 0.51.0-1
> > status : not (yet) reviewed
> > notes  : http://sources.redhat.com/ml/cygwin-apps/2003-06/msg00161.html
> > votes  : 0 (aspell prerequisite)
> > url: http://blytkerchan.chez.tiscali.fr/aspell-en-0.51.0-1.tar.bz2
> >
http://blytkerchan.chez.tiscali.fr/aspell-en-0.51.0-1-src.tar.bz2
>
> I've just been reviewing aspell* . It's looking good, layout wise. But, I
can't
> run aspell as the libaspell package cannot be found (on the server). One
other
> thing you might want to add to the binary package is a spell checker shell
script
> for use in pine or mutt. Linux Aspell does this (/usr/bin/alt_speller.sh?)
and
> you just invoke that script from your MUA.

libaspell is under
http://www-personal.usyd.edu.au/gpearce/aspell/libaspell/libaspell15-0.50.3-1.tar.bz2
aparently one of us got the directory name wrong at some point. - setup.hint
is in the same directory.
ofcourse it would of made sense to put it in the other directory - i just
didnt...
regarding the 'spell checker shell script' idea - I was under the impression
'spell' compatibilty mode was all that is needed.  which i think is just
aspell -a ... - I think in practice that a ispell/spell script which invokes
aspell is an option - and I cant remember at this second whether I included
that.  I'm pretty sure there was one in the src package.  Been a while.

Gareth

Re: Pending package status (25 Jun 2003)

[Gareth Pearce]

8. Aspell

date   : 07 Apr 2003
version: 0.50.3-1
status : not reviewed
notes  : http://cygwin.com/ml/cygwin-apps/2003-04/msg00155.html
 http://cygwin.com/ml/cygwin-apps/2003-04/msg00356.html
votes  : 4 (Christopher, Elfyn, Gerrit and Igor)
url: 
http://www-personal.usyd.edu.au/~gpea0679/aspell/aspell-bin/aspell-bin-0.50.3-1.tar.bz2
 
http://www-personal.usyd.edu.au/~gpea0679/aspell/aspell-bin/setup.hint
 
http://www-personal.usyd.edu.au/~gpea0679/aspell/aspell-doc/aspell-doc-0.50.3-1.tar.bz2
 
http://www-personal.usyd.edu.au/~gpea0679/aspell/aspell-doc/setup.hint
 
http://www-personal.usyd.edu.au/~gpea0679/aspell/aspell-dev/aspell-dev-0.50.3-1.tar.bz2
 
http://www-personal.usyd.edu.au/~gpea0679/aspell/aspell-dev/setup.hint
 
http://www-personal.usyd.edu.au/~gpea0679/aspell/libaspell15/libaspell15-0.50.3-1.tar.bz2
 
http://www-personal.usyd.edu.au/~gpea0679/aspell/libaspell15/setup.hint
 
http://www-personal.usyd.edu.au/~gpea0679/aspell/aspell-0.50.3-1-src.tar.bz2

11. Aspell-en

date   : 19 Jun 2003
version: 0.51.0-1
status : not (yet) reviewed
notes  : http://sources.redhat.com/ml/cygwin-apps/2003-06/msg00161.html
url: http://blytkerchan.chez.tiscali.fr/aspell-en-0.51.0-1.tar.bz2
 http://blytkerchan.chez.tiscali.fr/aspell-en-0.51.0-1-src.tar.bz2
votes  : veto perhaps?
Shouldnt really need votes - since without it aspell itself is pretty 
useless.

Can I encourage a 3rd party to review these two togeather? - multiple 
factors have conspired togeather that I am having difficulty getting the 
chance to do so.

Gareth - ponders if there was a setup.hint for aspell-en

PS - if anyone is holding back on offering to maintain gcc based on the fact 
i suggested i wanted too - dont - it could be a while before i get my time 
back in order and have a chance to do anything again.

_
Hotmail is now available on Australian mobile phones. Go to  
http://ninemsn.com.au/mobilecentral/signup.asp

Re: Unisys patent

[Gareth Pearce]

erm - not to rain on this ... but is it a good idea if the patent has only
expired in america?

Gareth
- Original Message - 
From: "Christopher Faylor" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 20, 2003 3:45 PM
Subject: Re: Unisys patent


> On Fri, Jun 20, 2003 at 01:38:28AM -0400, Charles Wilson wrote:
> >Expires today.
>
> Woo hoo!
>
> >Shall I respin libtiff to include LZW support, and distribute the new
> >LZW-capable libtiff via the cygwin mirror system?
>
> Sure.
>
> cgf
>

Re: Pending package status (11 June 2003)

[Gareth Pearce]

1 vote for aspell-dict *nudge nudge*

Gareth - who does intend one day to stop this sequence of busy weeks so he
can do stuff again.

Re: nano editor : v.1.2.0 released

[Gareth Pearce]

- Original Message -
From: "Christopher Faylor" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, March 17, 2003 5:21 AM
Subject: Re: nano editor : v.1.2.0 released


> On Sun, Mar 16, 2003 at 11:57:38AM +0100, Pavel Tsekov wrote:
> >On Sun, 16 Mar 2003, Gareth Pearce wrote:
> >
> >> A lil slow off the mark ... but here we go...
> >>
> >> http://www-personal.usyd.edu.au/~gpea0679/nano/nano-1.2.0-1.tar.bz2
> >> http://www-personal.usyd.edu.au/~gpea0679/nano/nano-1.2.0-1-src.tar.bz2
> >> http://www-personal.usyd.edu.au/~gpea0679/nano/setup.hint
> >
> >Uploaded. Don't forget to send an announcement to cygwin-announce.
>
> And next time please don't include _update?info?dir in your setup.hint.
> That gets added automatically if needed.  It was misspelled in the
setup.hint
> that was uploaded to sources.redhat.com, resulting in hundreds of messages
in
> my inbox.  I didn't catch this immediately because I was out of town.

ahh damn - sorry bout that - I was here wondering why i hadnt put it in my
1.1.10 setup.hint - now i remember - too long between releases obviously ...
will send announce in a minute or two hopefully..

Gareth

>
> cgf
>

Re: nano editor : v.1.2.0 released

[Gareth Pearce]

A lil slow off the mark ... but here we go...

http://www-personal.usyd.edu.au/~gpea0679/nano/nano-1.2.0-1.tar.bz2
http://www-personal.usyd.edu.au/~gpea0679/nano/nano-1.2.0-1-src.tar.bz2
http://www-personal.usyd.edu.au/~gpea0679/nano/setup.hint

looks ready to go to me ... - it seemingly got compiled with the
crosscompiler... but the resultant package appears to work flawlessly.
(guess i'll look into fixing my copy of the build script some more later)

And unlike 1.1.10 - i dont have a 1.8meg patch due to po files regeneration
differences.

Gareth - experiencing another one of those 'maintainer moments'.

- Original Message -
From: "Gareth Pearce" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, March 10, 2003 6:48 AM
Subject: Re: nano editor : v.1.2.0 released


> My holidays end today, I'll look into stoping being slack and try to
release
> asap.
> 1.1.11/12/pre1/pre2 all had issues - but i havent noticed anything much
> reported back against 1.2.0 on the nano-devel list - so it should be fine.
>
> Gareth Pearce - nano 'maintainer' (for lack of a betterword)
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Monday, March 10, 2003 6:08 AM
> Subject: nano editor : v.1.2.0 released
>
>
> > For users of the editor nano and the Cygwin-supplied version 1.1.10-1:
> there
> > is an update to nano version 1.2.0 available at their site
> > http://www.nano-editor.org/dist/v1.2/nano-1.2.0.tar.gz that seems to
> install
> > oob (configure / make / make install) and works well. To the maintainer:
> is
> > there any possibility, when you have a moment, and if this passes your
> > quality checks, that this update could be incorporated into the Cygwin
> > provision? Fergus
> >
> >
> > --
> > Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
> > Bug reporting: http://cygwin.com/bugs.html
> > Documentation: http://cygwin.com/docs.html
> > FAQ:   http://cygwin.com/faq/
> >
> >
>
> --
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting: http://cygwin.com/bugs.html
> Documentation: http://cygwin.com/docs.html
> FAQ:   http://cygwin.com/faq/
>
>

Re: pdksh package proposal

[Gareth Pearce]

> On Sun, Feb 23, 2003 at 05:39:07PM -, Max Bowsher wrote:
> >Elfyn McBratney wrote:
> >>> Your source package does not conform to 'Method Two', though you
> >>> seem to be convinced that it is.
> >>
> >> Sorry this is totally new to me, I'm going with "Method One". I was a
> >> bit confused but have read the document again since.
> >
> >There seems to be a trend towards Method Two, although I don't remember
any
> >preference being officially declared.
> >
> >Method two does have the advantage that it is a lot clearer how to
exactly
> >reproduce the original packager's build.
> >
> >Perhaps a standard needs to be declared about which method is to be used
for
> >new packages.
>
> It doesn't matter.
>
> cgf

awww comeon!   Dont you just have this craving to go back to the good ol
days where robert/charles/you/me/everyoneelse would argue day after day
about the merits of 3a vs 3b vs 5 vs 8 ...

hmm wait - neither do I.

But can you tell me where i can get a copy of b...

Gareth - will get round to releasing nano 1.2.0 any day now ... really!
(maybe after I get round to testing it first...)

Re: [ITP] par 1.52

[Gareth Pearce]

- Original Message -
From: "Joshua Daniel Franklin" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, February 07, 2003 2:10 PM
Subject: Re: [ITP] par 1.52


> > Runtime requirements:
> >  cygwin-1.3.19 or newer
>
> So this won't work with older dlls?

I was under the impression that making claims you havent verified was not so
good - so many packages have the above kind of thing.
Might be better to write
cygwin (tested with 1.3.19, should work with newer)

*shrug*

Gareth

Re: [Reviewed] Re: xerces-c, xerces-c21, xerces-c-devel, xerces-c-doc 2.1.0-1 av

[Gareth Pearce]

On Sun, 24 Nov 2002, Gareth Pearce wrote:

> Okay i think it looks ready to go ... one non-show stopper point... when
> running the shell script for generating the packages that comes with the 
src
> package - the created src package contains all the object files ... 
missing
> a make clean step i think...

It would be good idea to fix this before releasing - it should be
easy enough for the maintainer. Fixing this issue IMO should not require
another package review.


I have just been thinking back - and i think this was user error on my 
behalf.
The .o files would of been left behind from me manually doing a make in the 
directory previously.   I dont think the script actually runs make in the 
/usr/src/xerces-c-src directory ... Although I am sure abraham can con 
confirm that  - i am in linux trying to download 1.2gig of updates for my 
debian install at the moment ... not fast going with my modem :P

Gareth

_
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail

[Reviewed] Re: xerces-c, xerces-c21, xerces-c-devel, xerces-c-doc 2.1.0-1 available for review/upload

[Gareth Pearce]

Okay i think it looks ready to go ... one non-show stopper point... when
running the shell script for generating the packages that comes with the src
package - the created src package contains all the object files ... missing
a make clean step i think...

works fine - built and ran my main project perfectly.

Smith - ponders how he gained a /usr/i686-pc-cygwin/include directory ...
things are better now its gone :)


- Original Message -
From: "Abraham Backus" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, November 16, 2002 6:51 PM
Subject: xerces-c, xerces-c21, xerces-c-devel, xerces-c-doc 2.1.0-1
available for review/upload


> 1) changed dll naming (cygxerces-c21.dll) and packaging based on the
> suggestions and guidance of Charles Wilson
> 2) patched stricmp/strnicmp bug found by Gareth Pearce
>   Apache bug #14612 GCCDefs clashes with cygwin's string.h for stricmp and
> strnicmp
>   (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14612)
>
> source:
> http://abackus.imagineis.com/release/xerces-c/xerces-c-2.1.0-1-src.tar.bz2
>
> libxerces-c21 (the dll only):
>
http://abackus.imagineis.com/release/libxerces-c21/libxerces-c21-2.1.0-1.tar
> .bz2
>
> xerces-c (docs for the dll, licence, readme, etc.):
> http://abackus.imagineis.com/release/xerces-c/xerces-c-2.1.0-1.tar.bz2
>
> xerces-c-devel (the build-time libraries and includes for linking your app
> with xerces):
>
http://abackus.imagineis.com/release/xerces-c-devel/xerces-c-devel-2.1.0-1.t
> ar.bz2
>
> xerces-c-doc (the html docs for API, etc.):
>
http://abackus.imagineis.com/release/xerces-c-doc/xerces-c-doc-2.1.0-1.tar.b
> z2
>
> Note that if you are reviewing the xerces-c-devel package, it has
> postinstall and preremove scripts that create and clean up symbolic links
so
> that you can put "-lxerces" or "-lxerces-c" on your link line instead of
> "-lxerces-c21".
>
> -Abe
>
> setup.hint files...
>
> libxerces-c21
> 
> sdesc: "Runtime library for a validating XML parser written in a portable
> subset of C++"
> ldesc: "A validating XML parser written in a portable subset of C++.
> Xerces-C++ makes it easy to give your application the ability to read and
> write XML data. A shared library is provided for parsing, generating,
> manipulating, and validating XML documents.
>
> Xerces-C++ is faithful to the XML 1.0 recommendation and many associated
> standards.
>
> The parser provides high performance, modularity, and scalability. Source
> code, samples and API documentation are provided with the parser. For
> portability, care has been taken to make minimal use of templates, no
RTTI,
> no C++ namespaces and minimal use of ifdefs."
> category: Libs
> external-source: xerces-c
> requires: cygwin
> 
>
> xerces-c
> 
> sdesc: "Runtime library for a validating XML parser written in a portable
> subset of C++"
> ldesc: "A validating XML parser written in a portable subset of C++.
> Xerces-C++ makes it easy to give your application the ability to read and
> write XML data. A shared library is provided for parsing, generating,
> manipulating, and validating XML documents.
>
> Xerces-C++ is faithful to the XML 1.0 recommendation and many associated
> standards.
>
> The parser provides high performance, modularity, and scalability. Source
> code, samples and API documentation are provided with the parser. For
> portability, care has been taken to make minimal use of templates, no
RTTI,
> no C++ namespaces and minimal use of ifdefs."
> category: Libs Text
> requires: libxerces-c21
> 
>
> xerces-c-devel
> 
> sdesc: "A validating XML parser written in a portable subset of C++"
> ldesc: "A validating XML parser written in a portable subset of C++.
> Xerces-C++ makes it easy to give your application the ability to read and
> write XML data. A shared library is provided for parsing, generating,
> manipulating, and validating XML documents.
>
> Xerces-C++ is faithful to the XML 1.0 recommendation and many associated
> standards.
>
> The parser provides high performance, modularity, and scalability. Source
> code, samples and API documentation are provided with the parser. For
> portability, care has been taken to make minimal use of templates, no
RTTI,
> no C++ namespaces and minimal use of ifdefs."
> category: Devel
> external-source: xerces-c
> requires: gcc libxerces-c21
> 
>
> xerces-c-doc
> 
&

Re: Pending packages status

[Gareth Pearce]

> > 3. xerces-c
> > [...]
> > reviews: http://www.cygwin.com/ml/cygwin-apps/2002-11/msg9.html
> >  http://sources.redhat.com/ml/cygwin-apps/2002-11/msg00048.html
> >  http://sources.redhat.com/ml/cygwin-apps/2002-11/msg00047.html
> > votes  : 3 (Gerrit, Gareth and Robert)
>
> AFAICS, this package needs just another review after being patched.
> Gareth, are you stepping forward, perhaps?  You had that problem
> which needed the fix...


As I told abraham in off-list communication - I've been busy for a few
days - but this weekend it should happen.
The patch hes used is identical to what i used for personal purposes so its
fine.  I'll download the packages tommorow (on my trusty28.8k) and give them
another once over.  The main issue left from before was that the source
package seemed to be missing things.

Gareth - one more day then 4 months of nothing to do... hmm better fix that.

Re: Re: xerces-c, xerces-c-devel, xerces-c-doc 2.1.0-1 available for review/upload

[Gareth Pearce]

Woops - sorry all...

still a bit brain dead after finishing my thesis...

same with other message eek!

Gareth
- Original Message -
From: "Pavel Tsekov" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "Gareth Pearce" <[EMAIL PROTECTED]>
Sent: Friday, November 08, 2002 12:27 AM
Subject: Fwd: Re: xerces-c, xerces-c-devel, xerces-c-doc 2.1.0-1 available
for review/upload


> Gareth, please keep the discussion on cygwin-apps. I'm forwarding the
> message there.
>
>

Re: xerces-c, xerces-c-devel, xerces-c-doc 2.1.0-2 available for review/upload

[Gareth Pearce]

Sorry about that guys...  I don't like making excuses, so I'll just blame 
it
on the hallucinogenic drugs :)  I'll have a -1 version back there soon and
I'll remove the -2 version.  It'll contain the fix for the problem with the
wrong dll (my tar.incl file still had the libxerces instead of cygxerces).
Also, Gareth mentioned that there is a one line fix patch for xerces-c
2.1.0.  I'd like to get that in as well if I can dig it up.


src/xercesc/dom/impl/DOMDocumentTypeImpl.cpp
line 236 should be
   internalSubset = docImpl->cloneString(internalSubset);

should be pretty obvious when you see it.

Gareth

_
Surf the Web without missing calls! Get MSN Broadband. 
http://resourcecenter.msn.com/access/plans/freeactivation.asp

Re: xerces-c, xerces-c-devel, xerces-c-doc 2.1.0-2 available for review/upload

[Gareth Pearce]

> On Sun, 3 Nov 2002, Gareth Pearce wrote:
>
> > >Anyone wishing to review these packages can point setup.exe to
> > >http://abackus.imagineis.com.
> >
> > I'll definitely review these when i get home ... hopefully they will
solve
> > my xerces-c related problems.
>
> Ping. Have you had a chance to review this package ?

As already posted - I had a chance for a 'quick' review - which found the
current version had the wrong library - Charles has also sent some comments
offlist

he gave the usual split the library into a seperate package suggestion

as well he pointed out that my supposition that the library containing
functions of the same name as stdio functions was a property of libstdc++.a
and shouldnt be a problem.

 (which means i am back to square one with reasons why linking the library
is causing my application to crash where it doesnt otherwise)

Finally I heard today that the 2.1.0 version has a sort of nasty bug in it.
Cant remember offhand what it is, but its a one line patch to fix...

Gareth

Re: xerces-c, xerces-c-devel, xerces-c-doc 2.1.0-2 available for review/upload

[Gareth Pearce]

> >Anyone wishing to review these packages can point setup.exe to
> >http://abackus.imagineis.com.
>
> I'll definitely review these when i get home ... hopefully they will solve
> my xerces-c related problems.
>
> Gareth - still doesnt understand why hes got xerces-c related problems in
> the first place.

Only looked into binary packages since thats what i was after...  will look
into the rest if i have some time...

Okay well xerces-c-2.1.0-2.tar.bz2 - contains libxerces instead of cygxerces
easy fix there...  The rest 'looks' okay

not so good news is
my application which uses xerces-c stil dies horribly in an fopen call.

I tried to make a reduced testcase - but nope  it dosnt like me

I 'dont like' the fact that the  libxerces-c dll appears to contain a stack
of cstdio as 'T' when you nm the non-striped version.  Surely that
potentially can play havoc - all the stdio calls need to be handled by
cygwin1.dll
interestingly NONE of these come from the object files which get linked
togeather...
I am a little worried that g++ --shared is doing silly stuff.


Ofcourse my problem is probably unique - I am special that way...

Gareth

Re: xerces-c, xerces-c-devel, xerces-c-doc 2.1.0-2 available for review/upload

[Gareth Pearce]

I added a patch to follow some recommendations from Gerrit.

1) have the library name be "cygxerces-c2_1_0.dll" rather than 
"libxerces-c2_1_0.dll" (following conventions used by other libraries in 
cygwin).

2) the symlinks created in the build structure during "make" more 
accurately represent the links created during "make install"

3) in "make distclean" and "make clean", libraries and symlinks are removed

http://abackus.imagineis.com/xerces-c/setup.hint
http://abackus.imagineis.com/xerces-c/xerces-c-2.1.0-2.tar.bz2
http://abackus.imagineis.com/xerces-c/xerces-c-2.1.0-2-src.tar.bz2

http://abackus.imagineis.com/xerces-c-devel/setup.hint
http://abackus.imagineis.com/xerces-c-devel/xerces-c-devel-2.1.0-2.tar.bz2

http://abackus.imagineis.com/xerces-c-doc/setup.hint
http://abackus.imagineis.com/xerces-c-doc/xerces-c-doc-2.1.0-2.tar.bz2

Anyone wishing to review these packages can point setup.exe to 
http://abackus.imagineis.com.

I'll definitely review these when i get home ... hopefully they will solve 
my xerces-c related problems.

Gareth - still doesnt understand why hes got xerces-c related problems in 
the first place.




_
Surf the Web without missing calls! Get MSN Broadband. 
http://resourcecenter.msn.com/access/plans/freeactivation.asp

setup readme possibility (was about nano)

[Gareth Pearce]

changing subject title since this is a different topic really.
(Also switch to cygwin-apps since its about setup)


Actually, I haven't installed Cygwin for the first time on a machine, in a 
long while.  Does it popup a dialog to telling the user to modify the PATH 
to include C:\cygwin\bin? If such a dialog exists, it could also mention 
the CYGWIN variable set to "tty".  Just an idea.

I havent used the development setup so I can't say for certain - and I 
havent looked at the setup 'todo' listy thing so its quite possible its been 
suggested before.

But at a guess a patch for dialog saying - read the documentation and 
pointing out where it can be found... might be accepted. (I wont pretend to 
second guess Robert's oppinions here).  Setup does at least now install a 
set of links to the documentation in the start menu (thinking thats probably 
part of the documentation package but couldnt be sure).

Might be more acceptable if this was done by the post-instal script of the 
documentation package (assuming it only told you on first instalation).  
However that sort of thing would conflict with further work towards 
automated instalation.

Prehaps there needs to be some standard set - setup will set up some 
environment variable if its in an automated install - so that the scripts 
can know they cant ask for user interaction and are to assume defaults.

Gareth - rambles.

_
Get faster connections -- switch to MSN Internet Access! 
http://resourcecenter.msn.com/access/plans/default.asp

Re: Doxygen

[Gareth Pearce]

> Good! :) I've downloaded the latest package earlier today and gave it a
> try. It seems to behave well - as far as I can tell and I am not a doxygen
> user. I've tried some of the tests (not all) from
/usr/doc/doxygen-version/exmaples/
> and they seemed to produce the html docs. However one of the tests
> complained that the 'dot' program is not available. I understand that
> this 'dot' is some utility from a package called 'Graphviz'. I don't know
> what it is used for and if it is something that doxygen depends heavily
> on.
'from memory'
dot is an optional extra - you have to specify it in your doxygen.config for
whatever your using it on.  it does produce some 'Very' nice graphs for the
generated documentation if you do specify it, but not an essential.

Gareth

Re: Pending packages status

[Gareth Pearce]

> On Fri, Oct 04, 2002 at 06:25:34AM -0700, Joshua Daniel Franklin wrote:
> >I forgot to mention this earlier, but I also like the idea of the
> >necessary files being in one tar, like this:
> >
>
>http://www.geocities.co.jp/SiliconValley-SanJose/5153/cygwin-package/tmake-
1.8-1-package.tgz
> >
> >Instead of three separate files (.hint, -src.tar.bz2, .tar.bz2). This
> >makes it easier to check out a package. Especially the setup.hint files
have
> >had some CRLF problems.
> >
> >Could this be a new standard?
>
> I think that anyone who uploads the files would rather have them in three
separate
> files.  It's easier to just say "curl -Os http://qwer/wqer.tar.bz2"; three
times than
> to do it once, extract it and copy the result to the correct release
directory.
>

Even the originator of this practice agreed (i think?) this isnt
preferable - hes merely getting around geocities limitations.

Gareth

Re: And one more package, astyle Re: New Package: doxygen-1.2.17

[Gareth Pearce]

>On Tue, Sep 10, 2002 at 09:14:46PM +1000, Gareth Pearce wrote:
> >>>Just a pro-vote - for both - not that i have had a chance to check them
> >>>for quality...
> >Corinna says:
> >>
> >>Why not?
> >
> >ummm because I am a busy boy?  :P - barely get a few minutes spare at
> >all these days, let alone next to my cygwin computer.
>
>Maybe we need to change the approval process so that people actually have
>to try the package before saying "Aye".


Hmmm I was under the impression that for a package to be accepted it needed
a) - someone to check it for packaging.
b) - at least 3 votes saying that it is desired to be seen in the 
distribution.

which so long as person in a) is competant - seems fine to me.

Gareth


_
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

Re: And one more package, astyle Re: New Package: doxygen-1.2.17

[Gareth Pearce]

> On Mon, Sep 09, 2002 at 01:05:42AM +0000, Gareth Pearce wrote:
> >
> >
> > >Hi,
> > >
> > >Here is one more package, astyle.
> >
>http://www.geocities.co.jp/SiliconValley-SanJose/5153/cygwin-package/astyle
-package.tar.gz
> > >
> > >
> > >> >
> >
>http://www.geocities.co.jp/SiliconValley-SanJose/5153/cygwin-package/doxyge
n-package.tar.gz
> > >> > Sorry, my web server refused bz2 extension. Please extract and
check.
> >
> >
> > Oops - emailed offlist by mistake last time.
> >
> > Just a pro-vote - for both - not that i have had a chance to check them
for
> > quality...
>
> Why not?
ummm because I am a busy boy? :P - barely get a few minutes spare at all
these days, let alone next to my cygwin computer.

However, I have used both programs on linux and found them quite useful, so
I wasnt about to let them disapear into no-vote-land.

Gareth

Re: And one more package, astyle Re: New Package: doxygen-1.2.17

[Gareth Pearce]

>Hi,
>
>Here is one more package, astyle.
>http://www.geocities.co.jp/SiliconValley-SanJose/5153/cygwin-package/astyle-package.tar.gz
>
>
> > > 
>http://www.geocities.co.jp/SiliconValley-SanJose/5153/cygwin-package/doxygen-package.tar.gz
> > > Sorry, my web server refused bz2 extension. Please extract and check.


Oops - emailed offlist by mistake last time.

Just a pro-vote - for both - not that i have had a chance to check them for 
quality...

Gareth


_
Send and receive Hotmail on your mobile device: http://mobile.msn.com

Re: GNU emacs 21.2-3 packages available

[Gareth Pearce]

Argh - sorry bad gareth sent copys to authors as well as list.

Gareth - adds to your spam by appologising :P.

_
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

Re: GNU emacs 21.2-3 packages available

[Gareth Pearce]

>On Wed, 2002-08-14 at 00:34, Nicholas Wourms wrote:
> > Robert Collins wrote:
> > >
> > What I mean to say is that, despite one's best efforts, compiled 
>source=20
> > doesn't always behave as one had intended.  Of course it will act as 
>it=20
> > is written, it just may not seem apparent that the way it acts !=3D 
>the=20
> > way you intended it to act.
>
>Now that, that I agree with.
>=20
>
> > >Yes. And it should. You've also prodded me into finding a bug. Thanks.
> > >
> > Why is this behaviour considiered a bug?  It seems quite logical to 
>me.=20
> >  It allows for the usage that Corinna had desired.  Otherwise, there 
>is=20
> > no way to garuntee that updating a package later in the alphabet 
>won't=20
> > trump an earlier update's install.  Pretty handy when you want to fix 
>a=20
> > conflicting package f*$kup.
>
>Because it's actually worse. The cause of the conflicting package f***up
>is setup not checking for conflicts. So that can and will be addressed
>in other fashions.
>
>The reason to make upgrades atomic and done one package at a time is
>to deal with cases like the following:
>A pre-removal script (which *should* trigger on upgrades) may require
>binaries from another package being upgraded. Unless that other package
>is installed again at the time of the pre-removal script triggering, bad
>things will happen.

alphabetical order can still obviously screw this up anyway, no way to work 
this perfectly until the full versioned dependency set comes in - 
pre-removal-depends post-install-depends ... etc.

Hope someone has a nice algorithm for multi-dependency ordering satifaction 
and circular dependency detection.

Gareth - notes that hotmail itself is now broken with respect to pgp mime - 
stupid hotmail.

_
Chat with friends online, try MSN Messenger: http://messenger.msn.com

Re: well ... finally (nano update)

[Gareth Pearce]

> > Please upload when ready.
>
> Done.

Yay!

will send announce in about 11 hours ... yay for sleep and trains and well
everything that make my days so cramped...

Thanks,
Gareth

well ... finally (nano update)

[Gareth Pearce]

I actually managed to upgrade my cygwin instalation and still have time to
give this method 2 stuff ago.

So, introducing nano-1.1.10-1 - the first 'unstable branch' release for
cygwin.

It may be unstable branch, but I have been using it for a while on debian,
and the only bug I have experienced got fixed already.  It compiles OOTB on
cygwin and has survived my use (which isn't very heavy).

The method 2 scripts all seem pretty cool, if someone would like to check my
dependencies that might be an idea.
(wouldn't supprise me at all, if someone thinks the build deps in the readme
were insufficient, since I have little to no idea about those)

Whats New:
Well, just about everything actually.  The list is far, far too long to put
here.
So just read the NEWS in the package itself.

One last thing, is there any interest in a nano-tiny package? - I am not
sure if I would see the point myself, nano is pretty small already.  But if
the interest is there, I will do one.  The current version has everything
other then easter-eggs turned on.


--
# setup.hint
sdesc: "A pico clone text editor with extensions"
ldesc: "nano - A text editor designed as a clone of pico, but rewritten
from scratch to be faster and smaller while having greater functionality"
category: Editors
requires: cygwin libintl2 libiconv2 libncurses6

-
http://extro.ucc.usyd.edu.au/~gpea0679/nano/nano-1.1.10-1-src.tar.bz2
http://extro.ucc.usyd.edu.au/~gpea0679/nano/nano-1.1.10-1.tar.bz2
http://extro.ucc.usyd.edu.au/~gpea0679/nano/setup.hint

Please upload when ready.

Gareth - still supprised that setup downloaded 116% of what he asked for,
pretty impressive.

Re: migrating cygwin-mingw-gcc branch

[Gareth Pearce]

- Original Message -
From: "Danny Smith" <[EMAIL PROTECTED]>
To: "Gareth Pearce" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Saturday, July 27, 2002 3:22 PM
Subject: Re: migrating cygwin-mingw-gcc branch


> >
> > > The merge has happened.
> > > http://gcc.gnu.org/ml/gcc/2002-07/msg01277.html
> >
> > umm - that says the branch is opened, for abi changes.
> > It doesnt mention anything about a merge...
> > Am I missing something?
>
> Sorry, that was misleading. Soon after that, a swag of CVS check-ins hit
the cp
> and libstdc++-v3 directories in 3_2-branch.  Perhaps there are more to
come.

Ahh, okay I made the mistake of assuming gcc-patches was gcc-cvs *stupid me*
I see it now.  They look fairly comprehensive really.

Gareth

Re: gcc-3.2 C++ ABI and packaging c++ libraries [was Re: [ITP]: Berkeley DB v3.1]

[Gareth Pearce]

- Original Message -
From: "Nicholas Wourms" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, July 27, 2002 12:04 AM
Subject: Re: gcc-3.2 C++ ABI and packaging c++ libraries [was Re: [ITP]:
Berkeley DB v3.1]


> Gareth Pearce wrote:
>
> >
> >>B)If possible, I'd like to know what the tentative plan might be for the
> >>gcc-3.x release.  Are we going to stick with gcc-3.1.1 for awhile or are
> >>we going to dive into gcc-3.2?  In either case, roughly when would you
> >>like to have the new gcc go gold?
> >>
> >'read the message list archives' *snicker*
> >
> I don't know what's so damned funny, because he never *really* stated
> his intentions.  I don't need to read the archives, because I assure you
> I have been following the discussion.  He made a reference to the gcc
> announcment and said "maybe we should wait", but that doesn't say much
> to me.  How long are we going to wait?  Are we going to go with the
> initial release of gcc-3.2 or will we wait until gcc-3.2.1?  Further
> discussion was somewhat debateble, but certainly it was not clear or
> concise on where he stands.  Perhaps the message he stated this in never
> got delivered to my mailbox...

*snicker*
as usual ... sarcasm use on the only email list in which sarcasm is more
common then cabbages with hens teeth growing on them, fails.
>
> >
> >I am pretty sure that decision looked pretty strong on Chris waiting for
the
> >branch re-naming/abi fix checkin and releasing 3.2 instead of 3.1.1 ever
> >going past test.  Should be sometime next week hopefully ... since the
gcc
> >types said they were going to do the branch renaming as soon as 3.1.1 was
> >out ... and that is RSN. (ummm ofcourse i might of missed italready , I
> >delete most of the gcc mail without reading it)
> >
> Even you are expressing some reservation on saying what will happen, so
> again, my point was to recieve further clarification from management so
> that I can make "informed" decisions regarding my packages.

*chuckle* - You asked for Tentative plans ... and yet want definite answers.
Ofcourse to me, it doesnt seem tentative at all, my 'pretty sure' was merely
memory of the original discussion being a bit flaky.
Then again I also follow the gcc list somewhat and know that
a) - changing ABI is extreme pain - changing it twice is twice the pain.
b) - gcc 3.2 is rsn (so easily worth the wait)
c) - gcc 3.1 branch is recieveing no further development, so staying with
that is a dead end. (or requires Chris to backport 3.2 patches, wherever
they conflict with the new ABI code changes)
d) - gcc 3.2 release will be 3.1.1 with 'Only' abi changes.
I should of included this in my last email ... too late now though...

Ofcourse its all moot now, since Chris has gone and confirmed everything
to the last detail.

Gareth.

Re: migrating cygwin-mingw-gcc branch

[Gareth Pearce]

- Original Message -
From: "Danny Smith" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, July 27, 2002 3:06 PM
Subject: Re: migrating cygwin-mingw-gcc branch


> >
> > I would like to get this into cygwin ASAP, too, Danny.  If you add it to
> > the existing 3.1 branch, it will be copied over to the 3.2 branch
> > automatically.
> >
> > I haven't missed a message wrt the ABI compatibility merge have I?
> > We're still waiting for that, right?
>
> The merge has happened.
> http://gcc.gnu.org/ml/gcc/2002-07/msg01277.html

umm - that says the branch is opened, for abi changes.
It doesnt mention anything about a merge...
Am I missing something?

Gareth

Re: migrating cygwin-mingw-gcc branch

[Gareth Pearce]

> I haven't missed a message wrt the ABI compatibility merge have I?
> We're still waiting for that, right?

If you have, so have I. (and I been paying more attention then usual). But
then again I am not subscribed to gcc-patches. hmm nope - nothing there yet.

Gareth

Re: mingw and other gotchas in gcc 3.1

[Gareth Pearce]

>
>"egor duda" <[EMAIL PROTECTED]> wrote:
> > Btw, libstdc++ in gcc 3.* is configured so that classes in std::
> > namespace are not visible unless one specify std:: via 'using' or
> > explicitly. I feel this can be the problem that will make most
>noise.
> > Cygwin setup is just one example of program affected. I have a patch
> > that should work with both 2.95.3 and 3.*, and can post it if you're
> > interested.
>
>As I understood this (that's a disclaimer), if you include the
>"legacy" headers, i.e. , you get the names in the global
>namespace and it's only if you include the "new" headers, i.e. ,
>that you need the std:: qualifier or a "using" declaration. Of course,
>people may now be using the new headers without then using the std::
>qualifier, since gcc 2.95.3 allows this. But they're wrong already :-)
>(not that that ever stopped someone complaining).
>
>Or have they abandoned the legacy headers altogether?

not sure about 3.1 - but in 3.2 you get stacks of warnings if you use legacy 
headers... really big multi line ones so you cant possibly miss them.

Actually i am fairly sure they are in 3.1... been a while since i compiled 
something with anything other then 3.2 :P

Gareth

_
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

Re: [ITP]: Berkley DB v2

[Gareth Pearce]

>Gareth Pearce wrote:
>
>>>packages>
>>
>>Hmmm depending on release order seems rather dubious to me...
>>Would it not be better to have the symlink installed by postinstall script 
>>that checks if there is an existing symlink and only replacing it if the 
>>version of the one its pointing too is less then the one being installed?
>
>
>What if I *want* to revert to an older version?
in that case - 'no matter what' (as far as I can see) - your either going to 
have to remove the packages associated with the newer versions - or take the 
whole thing into your own hands and refix the links every time a new 
revision of a db packages comes out... (please note i could be talking junk 
for all i know here) (okay so it would be as easy as rerunning a script - 
but still :P - for all i know you could make it so the script by default as 
setup runs it does what i suggest - and when passed a force parameter or 
something it ignores version checking)
In the current system - if you want to patch db2 - release a new db2 - your 
going to have to release db3 and db4 as Well - in order to have everyones 
symlinks working nicely? (this is probably the nit that bothers me most)

>
>
>>same postinstall for all db packages - will work when a new db comes along 
>>(assuming that you are using some standard in versioned libs) - and doesnt 
>>rely on instalation order (which in my mind sounds sort of easy to break).
>
>
>Probably.  But the postinstall scripts are all there.  So, you can manually 
>re-execute:
>
>/etc/postinstall/libdb3.3-devel.sh.done
>
>and assert the "current" links to the 3.3 version, or 4.0, or whatever.

really depends how often you want to have to tell people to do this I am 
thinking... - whats the law - make the commonest case the easiest? (hmmm 
thinking hoffman coding in the perl 6 reg exp thiny i read for no reason)

>
>>(hmmm would need a postuninstall script to chose highest remaining one to 
>>link it too as well)
>
>
>Probably so, but the logic gets tricky.  I think this one can be tabled 
>until it becomes an issue.  Under the current scheme, there are two fixes 
>if you uninstall (the latest) db-devel:
>   1) reinstall (the latest minus one) db-devel
>   2) execute /etc/postinstall/libdb(thelatestminusone)-devel.sh.done 
>manually.
>
>This will probably be so rare a problem, that I believe these two options 
>are sufficient.

same 2 options would be under my system - or postinstall script... *shrug*
>
>--Chuck

well its not me who has to handle the requests 'why is my db install 
broken?'
so I dont realy mind :P (not you either :P)

I dont think it will be quite as rare - but i certainly dont have close to 
the same level of experience as a maintainer as you.


Gareth

_
Send and receive Hotmail on your mobile device: http://mobile.msn.com

Re: SETUP: new setup.ini with md5 sums crashes setup 2.192.2.24 on W98SE

[Gareth Pearce]

Just a question... are you using the latest setup off the web page? - I
think I rememebr chris faylor mentioning something about putting up a new
version of setup which at least ignores the md5's ...
rather then the yet-to-be-ready version which will actually pay attention to
them.

Regards,
Gareth
- Original Message -
From: "Ton van Overbeek" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, May 03, 2002 6:38 PM
Subject: SETUP: new setup.ini with md5 sums crashes setup 2.192.2.24 on
W98SE


> This started happening today.
>
> When I try to 'Install from Internet' from my normal mirror
> (http://ftp-stud.fth-esslingen.de) Setup starts downloading
> setup.ini and then crashes with the following error:
>   SETUP caused a general protection fault
>   in module USER.EXE at: 0004:5ff0.
>
> Tried with some other mirrors: same crash.
> One mirror succeeded (ftp://ftp.easynet.be).
> Investigating the differences it turned out that the setup.ini
> from ftp.easynet.be does not have the md5sums yet, the other
> crashing mirrors have setup.ini with md5sums included.
>
> Is this W9x specific or is it also happening on NT/2K/XP ?
>
> Regards,
>
> Ton van Overbeek
>

RE: ITP: netpbm

[Gareth Pearce]

>
>
>
> > -Original Message-
> > From: Earnie Boyd [mailto:[EMAIL PROTECTED]]
> > Sent: Saturday, April 27, 2002 6:03 AM
>
> > As for the # of executables in the /bin directory, isn't
> > there a limit to the number of files and/or directory entries
> > in any one directory on win32?
>
>As has already been said, not past the root. However directory search
>time is O(N) on FAT, vs (IIRC) O(logN) on NTFS. So directories with many
>files leads to signficcantly longer lookup times - and thas when the
>filename is known!.

My experience - on ntfs ... i have a directory of approx 10thousand 5 minute 
log files of me playing telnet based muds ... *snicker*
i can grep them all (each about 10-20k) in a few minutes ... (9 grep 
commands because command line expansion limitations :P) - really preformance 
drop is not that noticible.  Except in one area.
cd'ing to the directory in the first place - can take a minute or more, 
subsequent cd's are fast, but it seems like its caching all the filenames in 
the directory for faster access.

Anyway ... theres a 'pseudo-data-point'

Regards,
Gareth




_
Chat with friends online, try MSN Messenger: http://messenger.msn.com

Re: cygwin port of Pine

[Gareth Pearce]

Interest here as well,

one question though, could pico be packaged up as a seperate package and 
pine be made to depend on it? (not that anyone would want pico when theres 
nano *cough* :P)

Gareth - the definitely not biased nano maintainer (who will release a new 
version ... soon ... really)

>
>Thumbs up from me.
>
>cheers,
>-Matt
>
>
> > Hello,
> >
> >   I am sending this message, because I have built Pine for cygwin, and I
> > would like to know if the cygwin community is interested in distributing
> > this package. I would maintain the package, that's not a problem at all.
> > The Pine developers team also approves that I do this job (including
> > redistribution of the binary), so the only missing part would be to know
> > if you are interested in including this package.
>
>
>


_
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

Re: Setup - Idea...

[Gareth Pearce]

>
> Ok, I'll be the religious one.  If a package is removed from setup.ini
> then setup should leave previously installed versions alone.  If a
> package needs to be removed due to serious conflicts with Cygwin then a
> null package can be created to remove the conflicting files.  Then at a
> later date the null package can be deleted.
>
> Note: A null package is one with just an obligatory
> /usr/doc/cygwin/-README that explains the removal decision.

This 'feature' I hadnt considered - it implements all the abilities that I
was thinking might be needed...
So therefore my post was useless afterall! :) (well besides me learning
something potentially useful at some point in the future)

Gareth

Re: Setup - Idea...

[Gareth Pearce]

> On Thu, 2002-01-24 at 22:35, Gareth Pearce wrote:
> > Hi ... I am going out on a limb here and assume that this feature hasnt
been
> > suggested before. (ummm yeah I know I should of checked the message
lists -
> > I am prepared to shoot myself if I am wrong :P)
>
> I'm not sure if it's been suggested, but I don't think its a good thing
> - IMO when a package is removed, setup should leave it installed, until
> the user requests that it be removed.
I agree - 'except' - where not removing it is almost certain to cause pain
and suffering.

I think I can see this being possible - but ummm maybe its really more an
extension of 'conflicts with' - and so when conflicts get added it can be
done then...
(like cygwin conflicts with regex - which it doesnt I am
hoping/guessing/havent seen any eveidence yet - but in a similar
circumstance prehaps it would)

Gareth

Setup - Idea...

[Gareth Pearce]

Hi ... I am going out on a limb here and assume that this feature hasnt been
suggested before. (ummm yeah I know I should of checked the message lists -
I am prepared to shoot myself if I am wrong :P)

Having just read Corinna's announcement that regex was going to be removed.
I was thinking that prehaps there should be the ability to create an entry
in setup.ini - which will cause setup to default to uninstall for a given
package.  Not sure if in this case it would be the best idea - but prehaps
there are other circumstances where it would it might come in useful in the
future.

If theres interest - I can probably steal enough time to write a patch (umm
I - *hope*)

Gareth - is sorely tempted to try and give BIND ago for maintainership -
since its requested so much :P ... wonder if people complaining about it not
working would mind 'I aint got a clue - I just maintaining this for lack of
a maintainer' on a regular basis ;)

hmm still need to decide between nano 1.0.8 and 1.1.5 as well.

Re: new policy for packages

[Gareth Pearce]

- Original Message -
From: "Robert Collins" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, January 11, 2002 9:03 PM
Subject: new policy for packages


> I want to suggest that the following become policy:
>
> No new packages are accepted that require non-packaged prerequisites.
>
> i.e. using rpm which was raised on cygwin@ recently,
> until db 3.2 is packaged and maintained by 'someone', rpm is not
> acceptable as a package.
>
> Thoughts?

This makes sense to me - however I was wondering to what extent.
1. no packages which have run-time dependencies on non-packaged.
2. no packages which have Build time dependencies on non-packaged during
'standard' compile.
3. as 2 but even if the code distributes an 'internal' copy.
4. no packages which can have build time dependencies on non-packaged with
an additional configure flag or similar.


1. seems a relatively obvious requirement ... but postgresSQL doesnt follow
it by the sounds of things.
2. is what I would think best at first - but
3. would drive people towards seting up fuller library support basis then we
have at the moment?  Also since the library might need cygwin specific
patches - avoids 5 different packages with different levels of problems
because of different levels of successful patching of the included
libraries.
4. seems way over the top to me ... so I didnt put anything stricter in my
list.  But maybe someone out there would think this good.  (mainly cause
nano fails this one :P - it can be built with slang by configure option - a
few other things too i think)

Another requirement consideration - which I am unsure if would be wanted -
but thought I might put it up for discussion.
All 'library' style packages must provide dynamic link libraries (if
possible?).

I was considering looking at packaging up slang or a few other things - but
thought that not providing dynamic libs would be the wrong move to take, and
due to lack of experience in making 'good' dynamic libraries on my behalf -
decided I would put it off, (prehaps hoping someone else would do it)

my pi/2 cents (rounded).

Gareth

nano updated - 1.0.7

[Gareth Pearce]

I have uploaded my update to nano 1.0.7 to
http://www-personal.usyd.edu.au/~gpea0679/nano/

This version compiles completely OOTB without even the LIBS=-lintl in front
of make or configure...
It also installs the locale files into the correct directory now
Spell checker should now work less buggy like.
and apparently some of the translations have been updated.

Will announce if someone puts it up - will fix if someone points out I have
been stupid :)

Gareth

Re: Restructuring gettext

[Gareth Pearce]

>Okay, I've uploaded and announced the new gettext packages:
>   gettext-0.10.40-1
>   libintl1-0.10.40-1
>   libintl-0.10.38-3
>
>I also updated the setup.hint files on the server for the following
>packages:
>
>wget   mutt   nano   vim   sharutils
>
>The maintainers of those packages should make a note of this; the next
>time they rebuild, they will depend on libintl1 instead of libintl.

I am going to release nano 1.0.7 after christmas (on holidays right now or I 
would release it tommorow) which fixes a few things including locale being 
installed in the wrong directory - it also compiles completely without 
modification straight from the box - got my lil problems fixed at the source 
:)

anyway ... until 1.1.5 or so (which should be my next release after 1.0.7 I 
think) and both versions are recompiled to depend on libintl1 I assume my 
setup.hint will have to depend on Both libintl and libintl1 correct?

or should I do something else?

Gareth

_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.