Re: Update: perl-Win32-GUI, perl-libwin32

2005-04-19 Thread Reini Urban
Corinna Vinschen schrieb:
On Apr 18 21:36, Reini Urban wrote:
What about perl-Win32-GUI?
I didn't realize that there was another package to upload due to your
unnecessary long email (g!).  Now, if you resend the links together
with a so far missing setup.hint file?
http://xarch.tu-graz.ac.at/publ/cygwin/release/perl-Win32-GUI/perl-Win32-GUI-1.0-2.tar.bz2 
http://xarch.tu-graz.ac.at/publ/cygwin/release/perl-Win32-GUI/perl-Win32-GUI-1.0-2-src.tar.bz2
http://xarch.tu-graz.ac.at/publ/cygwin/release/perl-Win32-GUI/setup.hint


--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
http://phpwiki.org/


Re: Update: perl-Win32-GUI, perl-libwin32

2005-04-19 Thread Corinna Vinschen
On Apr 19 08:11, Reini Urban wrote:
 http://xarch.tu-graz.ac.at/publ/cygwin/release/perl-Win32-GUI/perl-Win32-GUI-1.0-2.tar.bz2
  
 http://xarch.tu-graz.ac.at/publ/cygwin/release/perl-Win32-GUI/perl-Win32-GUI-1.0-2-src.tar.bz2
 http://xarch.tu-graz.ac.at/publ/cygwin/release/perl-Win32-GUI/setup.hint

Thanks, uploaded.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:cygwin@cygwin.com
Red Hat, Inc.


Re: Please upload: doxygen v1.4.2-20050410 (3nd take)

2005-04-19 Thread Corinna Vinschen
Is that ready to upload now?

Corinna

On Apr 15 16:51, Hans W. Horn wrote:
 Max,
 
 Max Bowsher wrote:
 Hans W. Horn wrote:
 I've uploaded another cut of doxygen v142 src  binary packages to
 http://www.smithii.com/files/cygwin/hans/, addressing more
 concerns/suggestions raised by Max Bowsher.
 In particular:
 1. removing pdf manual
 2. including upstream source tarball
 3. package naming issues
 [...]

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:cygwin@cygwin.com
Red Hat, Inc.


Re: Please upload: doxygen v1.4.2-20050410 (3nd take)

2005-04-19 Thread Max Bowsher
Corinna Vinschen wrote:
Is that ready to upload now?
No.
I'll reply to Hans' last mail with detail.
Max.


Re: Please upload: doxygen v1.4.2-20050410 (3nd take)

2005-04-19 Thread Max Bowsher
Hans W. Horn wrote:
Max,
Max Bowsher wrote:
Package naming still incorrect.
It should be:
doxygen-1.4.2_20050410-1.tar.bz2
doxygen-1.4.2_20050410-1-src.tar.bz2
Fixed.
No, still wrong. You didn't read what I said carefully enough.
You *need* to understand:
Filenames are expected to be EXACTLY:
NAME-VERSION-RELEASE.tar.bz2
NAME-VERSION-RELEASE-src.tar.bz2
VERSION is anything which begins with a digit, and does not contain a '-'.
RELEASE is a simple integer, starting at 1, incremented if there is a need 
to release a new Cygwin package of the same upstream version.


Also, please could you briefly describe the purpose and origin of the
following parts of the patch:
+++ doxygen_1.4.2-20050410/addon/doxywizard/version.cpp 1969-12-31
16:00:00.0 -0800
addon/doxywizard/version.cpp is created during the build and removed 
during
a 'make distclean'. The upstream version I was diffing against, must not
have been made 'distclean'.
I haved removed the offending file from the upstream version I am diffing
against!
OK.
+++ doxygen_1.4.2-20050410/doc/language.doc 2005-04-12
08:19:02.941256000 -0700
+++ doxygen_1.4.2-20050410/doc/translator_report.txt 2005-04-12
08:19:05.404798400 -0700
+++ doxygen_1.4.2-20050410/examples/example.tag 2005-04-15
08:12:16.622246400 -0700
These files are touched during a 'make install_docs'. diffs seem to be
meaningless! Is there a way to exclude them from the patch file (I mean
automatically)?
diff --help | fgrep exclude
The Cygwin-specific readme should be wrapped to remain within 80
columns.
Fixed! But, please, take a look at doxygen-1.2.18.README and tell me how
many chars per line you see!
And, by the way, the previous doxygen-1.2.18 version did ship with a pdf
version of its manual
A fresh start is a wonderful time to fix old bugs.
Max.


Package making guidelines question

2005-04-19 Thread Max Bowsher
When a packager follows a pseudo-Method 2 approach, using a home-grown 
script not based on generic-build-script, how closely must the naming and 
behaviour of the script follow the official template?

What degree of automation is required in terms of setup?
Do we require that the included script be capable of rebuilding the packages 
entirely by itself, or is it permissible to require manual tar, patch, etc., 
commands first?

Max.


Request for pkg-config update

2005-04-19 Thread Max Bowsher
Pkg-config maintainer, please could we have an update?
Current is 0.17.2, Cygwin package is 0.15.0.
The new release fixes some minor syntax glitches in pkg.m4, which the 
current autoconf package warns about loudly.

Thanks,
Max.


Which package is required to build LexYacc in cygwin [gcc -ll]

2005-04-19 Thread Krisakorn Rerkrai
Hi all,
 I tried to make my parser under Cygwin environment. It works well 
under the Linux but I have to do it also in Cygwin. It cannot find gcc 
-ll command:
This is my result:

gcc l.uql.c y.uql.c -o uql -ll
/usr/lib/gcc/i686-pc-cygwin/3.4.1/../../../../i686-pc-cygwin/bin/ld: 
cannot find -ll
collect2: ld returned 1 exit status
make: *** [uql] Error 1

Does anybody know which package is required to build my application?
Any help would be appriciated.
Krisakorn


Re: Which package is required to build LexYacc in cygwin [gcc -ll]

2005-04-19 Thread Corinna Vinschen
On Apr 19 13:51, Krisakorn Rerkrai wrote:
 Hi all,
  I tried to make my parser under Cygwin environment. It works well 
 under the Linux but I have to do it also in Cygwin. It cannot find gcc 
 -ll command:
 This is my result:
 
 gcc l.uql.c y.uql.c -o uql -ll
 /usr/lib/gcc/i686-pc-cygwin/3.4.1/../../../../i686-pc-cygwin/bin/ld: 
 cannot find -ll
 collect2: ld returned 1 exit status
 make: *** [uql] Error 1
 
 Does anybody know which package is required to build my application?
 Any help would be appriciated.

Wrong mailing list.  Please ask these questions on [EMAIL PROTECTED]


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:cygwin@cygwin.com
Red Hat, Inc.


RE: Vital information for anyone debugging setup.exe

2005-04-19 Thread Dave Korn
Original Message
From: Reini Urban
Sent: 18 April 2005 20:14

 Dave Korn schrieb:
NO!   NO!!!   NOOOo !!1!!!
 
 FOR GOD'S SAKE WHATEVER YOU DO DON'T USE INSIGHT
  ONLY EVER USE COMMAND-LINE GDB
 AAARRRGRGH  MY EYES
 
 HA!
 

  Do you know how many windows there are by the time that each of three .ini
files have been read to the 100% mark?

  Do you know how slowly each one of those windows closes when there's
hundreds of them?

  I manually clicked away every single one of them because I wasn't sure if
I'd be able to reproduce the error or not, so once I'd got it I didn't want
to let it go.  It was late at night and my judgement may have been impaired
by sleep-deprivation!


 Nevertheless I still prefer insight over gdb.
 You just have to turn off those misdirected dialog popups, which should
 be logfile entries.

  Yes, I kind of deduced that do you know what the syntax is to turn
them off, by any chance?

ObTopic:
  Oh, it's time to repost that do-the-dll-last patch again, with more
tidyups and generally finalised.  Will get to it shortly.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today



Re: Package making guidelines question

2005-04-19 Thread Igor Pechtchanski
On Tue, 19 Apr 2005, Max Bowsher wrote:

 When a packager follows a pseudo-Method 2 approach, using a home-grown
 script not based on generic-build-script, how closely must the naming and
 behaviour of the script follow the official template?

I don't think there is a particular set of requirements on this, but at
the very least, when extracted by setup.exe to /usr/src, the script should
not produce a name conflict with either other source packages or, more
importantly, previous versions of the sources for the same package, which
leaves very little room for variation in naming.

 What degree of automation is required in terms of setup?
 Do we require that the included script be capable of rebuilding the
 packages entirely by itself, or is it permissible to require manual tar,
 patch, etc., commands first?

Behavior-wise, the script should, IMO, at the very least provide a way of
creating a patched source directory.  I don't think having full automation
is (or should be) a requirement.  As long as the package README is clear
on what steps are needed, it's ok to require manual steps towards the
build.

Again, I don't set the policy for these things, so the above is just my
opinion.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT


ANNOUNCEMENT NEEDED! (was Re: Please upload: Apache-1.3.33-1)

2005-04-19 Thread Christopher Faylor
On Mon, Apr 18, 2005 at 08:23:40PM +0200, Robert Richter wrote:
Hi all,

please upload a new Apache-1.3.33 package available here:

http://www.fast4ward.de/cygwin/release/apache/apache-1.3.33-1-src.tar.bz2
http://www.fast4ward.de/cygwin/release/apache/apache-1.3.33-1.tar.bz2
http://www.fast4ward.de/cygwin/release/apache/setup.hint

Release focus: Update from version 1.3.29

The Apache package contains the mod_ssl EAPI patch but no additional module
extensions. These are part of further releases.

Since this package is a replacement of an older version, I do not think this
release increases the risk of conflicts with an upcoming Apache2 package.

Robert,
Is there some problem with sending out a release announcement for this package?
I assumed that you were stepping up to be the maintainer of apache 1.3.  That
means that you need to send an announcement and, then, you will need to
subsequently start replying to problems in the cygwin mailing list.

I don't think I performed the due diligence to discover if you were really
volunteering to be a full-time maintainer for apache 1.3.  Was I mistaken in
assuming that you were?

cgf


Please upload: doxygen-1.4.2_20050410-1 (n'th take)

2005-04-19 Thread Hans W. Horn
Alright,
Max Bowsher wrote:
No, still wrong. You didn't read what I said carefully enough.
You *need* to understand:
Filenames are expected to be EXACTLY:
NAME-VERSION-RELEASE.tar.bz2
NAME-VERSION-RELEASE-src.tar.bz2
I guess I never appreciated the subtle naming convention used for cygwin
packages. Honestly, my impression was that names go all over the map.
Fixed (I think).
+++ doxygen_1.4.2-20050410/doc/language.doc +++
doxygen_1.4.2-20050410/doc/translator_report.txt +++
doxygen_1.4.2-20050410/examples/example.tag
These files are touched during a 'make install_docs'.
Excluded offending diffs from patch.
Same url (http://www.smithii.com/files/cygwin/hans/):
-rw-r--r-- 1 32237 ross 2273644 Apr 19 11:58 
doxygen-1.4.2_20050410-1-src.tar.bz2
-rw-r--r-- 1 32237 ross 1999837 Apr 19 11:58 
doxygen-1.4.2_20050410-1.tar.bz2
-rw-r--r-- 1 32237 ross 183 Apr 19 11:58 md5.sum
-rw-r--r-- 1 32237 ross 353 Apr 19 11:58 setup.hint

H. 



Re: Please upload: doxygen-1.4.2_20050410-1 (n'th take)

2005-04-19 Thread Christopher Faylor
On Tue, Apr 19, 2005 at 10:30:12AM -0700, Hans W. Horn wrote:
Max Bowsher wrote:
No, still wrong.  You didn't read what I said carefully enough.  You
*need* to understand:
Filenames are expected to be EXACTLY:
NAME-VERSION-RELEASE.tar.bz2
NAME-VERSION-RELEASE-src.tar.bz2

I guess I never appreciated the subtle naming convention used for cygwin
packages. Honestly, my impression was that names go all over the map.

NAME-VERSION-RELEASE is subtle?

That's interesting.

cgf


Re: Please upload: doxygen-1.4.2_20050410-1 (n'th take)

2005-04-19 Thread Hans W. Horn
It's only subtle, until you've digested that in this notation RELEASE is a 
cygwin version attribute and VERSION is an upstream version attribute (which 
on its own may already use a similar naming convention, such as 
doxygen-1.4.2-20050410).
Confused the hell out of me!

H.
Christopher Faylor wrote:
On Tue, Apr 19, 2005 at 10:30:12AM -0700, Hans W. Horn wrote:
Max Bowsher wrote:
No, still wrong.  You didn't read what I said carefully enough.  You
*need* to understand:
Filenames are expected to be EXACTLY:
NAME-VERSION-RELEASE.tar.bz2
NAME-VERSION-RELEASE-src.tar.bz2
I guess I never appreciated the subtle naming convention used for
cygwin packages. Honestly, my impression was that names go all over
the map.
NAME-VERSION-RELEASE is subtle?
That's interesting.
cgf 



Re: Please upload: doxygen-1.4.2_20050410-1 (n'th take)

2005-04-19 Thread Christopher Faylor
On Tue, Apr 19, 2005 at 10:42:04AM -0700, Hans W. Horn wrote:
It's only subtle, until you've digested that in this notation RELEASE is a 
cygwin version attribute and VERSION is an upstream version attribute 
(which on its own may already use a similar naming convention, such as 
doxygen-1.4.2-20050410).
Confused the hell out of me!

http://cygwin.com/setup.html#naming seems pretty clear to me.

Anyway, doxygen-1.4.2-20050410 is not using a similar naming convention.
It is a version number with a dash in it.  The - is not a release
and it should be pretty clear that it can't be a cygwin release given
the above URL.

cgf


RE: Vital information for anyone debugging setup.exe

2005-04-19 Thread Gary R. Van Sickle
[snip]
 
  Nevertheless I still prefer insight over gdb.
  You just have to turn off those misdirected dialog popups, which 
  should be logfile entries.
 
   Yes, I kind of deduced that do you know what the syntax 
 is to turn them off, by any chance?

I think he's talking about doing a search-n-replace on the setup source.

-- 
Gary R. Van Sickle
 



RE: Vital information for anyone debugging setup.exe

2005-04-19 Thread Dave Korn
Original Message
From: Gary R. Van Sickle
Sent: 19 April 2005 19:05

 [snip]
 
 Nevertheless I still prefer insight over gdb.
 You just have to turn off those misdirected dialog popups, which
 should be logfile entries.
 
   Yes, I kind of deduced that do you know what the syntax
 is to turn them off, by any chance?
 
 I think he's talking about doing a search-n-replace on the setup source.

  It would probably be easier simpler and quicker to find the messagebox
call in the insight source (most of which is just tcl/tk scripting after
all) and comment it out.

  Actually it should probably be properly removed and sent upstream as a
patch.  Opening a fresh window per log message is just plain wrong on pretty
much any host or target I can imagine.  One window with debug messages
scrolling up, yes; one window, that blocks execution until it is clicked
away, maybe; one window, that simply overwrites it's message with each new
debug message as it arrives, ok; but opening window after window after
window without limit?

  Debug messages just don't belong in dialog boxes.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today



Re: Request for pkg-config update

2005-04-19 Thread Charles Wilson
Max Bowsher wrote:
Pkg-config maintainer, please could we have an update?
Current is 0.17.2, Cygwin package is 0.15.0.
Thanks.  Development seemed stalled for so long I thought it was dead. 
I'll roll an update out soon.

--
Chuck


Re: Vital information for anyone debugging setup.exe

2005-04-19 Thread Brian Dessent
Dave Korn wrote:

   It would probably be easier simpler and quicker to find the messagebox
 call in the insight source (most of which is just tcl/tk scripting after
 all) and comment it out.

Perhaps you missed my other reply:

 Heh, you noticed that too... I googled for a way to disable the popups,
 but found nothing.  I just comment out the OutputDebugString() call in
 msg() when using insight.

Comment out that one line and they're gone...

Brian