Re: please add a find-the-fastest-mirror-automatically feature to setup.exe
On Fri, May 23, 2008 10:03 pm, Soren Andersen wrote: On Fri, 23 May 2008 12:23:13 -0400 Chris Sutcliffe [EMAIL PROTECTED] wrote: Setup.exe is a great tool, but could you please add a find-the-fastest-mirror-automatically feature? That would require making a connection attempt to every entry in setup's list, which would be rather counter-productive I would think. Yes, it would (and annoying, etc...). However, I can envision a compromise solution in which Setup.exe looks for a file, a la unix user rc files, and if found reads the address of the preferred host to use from that file. Caching the result of a one-time burst of pings, in other words. Something like /etc/setup/last-mirror, perhaps? :)
Re: Putting my packages up for adoption
On Wed, April 30, 2008 3:27 am, Corinna Vinschen wrote: According to Max Bowsher on 4/29/2008 4:47 PM: | Farewell, of sorts, and thanks everyone for helping make Windows a nice | place to be the past many years! Sad ACK. I've marked all your packages as orphaned now. Would not a farewell gold star be appropriate?
Re: perl-5.9.5
On Wed, June 20, 2007 6:39 pm, Reini Urban wrote: I almost have that ready, I just wait for some of my cygwin patches upstream. With current blead (5.9.5) I get now the same number of failing tests as with 5.8 ../lib/Net/Ping/t/500_ping_icmp.t21 50.00% 2 being the only leftover. How should we name it so that users can experiment with that? Side-by-side to perl-5.8.8 Since 5.9.5 is basically a beta 5.10.0, I would actually make it a test version of a new perl5.10 package (so perl5.10-5.9.5-1). When 5.10.0 is released, the package would be updated to perl5.10-5.10.0-1 and move to current. I also enabled -DDEBUGGING, esp. for the new regex engine. Different routines with DEBUGGGING enabled are swapped in when you do use re debug, so that shouldn't be necessary. Note that DEBUGGING on vs. off are not binary-compatible, so once you pick a state, you're stuck with it unless you want to make people recompile XS modules they've built.
Re: [ITP] perl-5.8.8
On Tue, June 19, 2007 7:24 pm, Reini Urban wrote: I want to it take over from Gerrit. Thank you so much. If it were up to me, you'd get three gold stars. Please try to test it. It's a really weird build system. But I'm quite happy with this 5.8.8 http://rurban.xarch.at/software/cygwin/release/perl/perl-5.8.8-1.tar.bz2 http://rurban.xarch.at/software/cygwin/release/perl/perl-5.8.8-1-src.tar.b z2 http://rurban.xarch.at/software/cygwin/release/perl/perl_manpages/perl_ma npages-5.8.8-1.tar.bz2 setup.hint's attached (unchanged) Failed Test Stat Wstat Total Fail Failed List of Failed -- - ../ext/IPC/SysV/t/ipcsysv.t 1 25616 32 200.00% 1-16 ../ext/IPC/SysV/t/msg.t 012?? ?? % ?? ../ext/IPC/SysV/t/sem.t 012?? ?? % ?? ../lib/Net/Ping/t/500_ping_icmp.t21 50.00% 2 op/magic.t 581 1.72% 27 op/taint.t 012 238 178 74.79% 150-238 25 tests and 262 subtests skipped. Failed 6/996 test scripts, 99.40% okay. 107/117806 subtests failed, 99.91% okay. I think all of those but the Net::Ping are due to cygserver not running (or server not in CYGWIN). And Net::Ping tends to have obscure problems that vary from system to system. I also have a test version for perl-5.9.4 ready, but I'll wait a bit to get some patches in, until Rafaël announces the 5.9.5 release. -- There shouldn't be major changes between now and 5.9.5, so it wouldn't hurt at all to grab http://public.activestate.com/pub/apc/perl-current-snap/perl-current-latest.tar.bz2 for a test version.
Re: fortune-1.99.1-2
On Wed, Oct 04, 2006 at 12:24:18PM +0200, Corinna Vinschen wrote: On Sep 11 19:10, Buchbinder, Barry (NIH/NIAID) [E] wrote: http://sourceware.org/ml/cygwin-apps/2006-01/msg00113.html Is it time to remove the test designation? I removed the test, curr and prev lines from setup.hint. Thanks.
Re: Maintainer searched
On Tue, Jun 13, 2006 at 12:36:46PM +0200, Corinna Vinschen wrote: On May 4 18:06, Yitzchak Scott-Thoennes wrote: On Wed, May 03, 2006 at 10:24:19PM +0200, wrote: Hello, there is not enough time to maintain all my packages. Who wants to maintain one or more of my packages, maybe Yaakov wants to take over some of the GTK+ related packages? Then there are some more major packages which really require a maintainer with more time than I have (i.e. GCC, Perl). If it's ok with you, I'll take perl. Since there hasn't been much movement lately, I tracked which of Gerrit's packages have been actually taken over. As I see it now, the following packages remain to be taken over, please correct me if I missed something: antiword check Yaakov S? db* Max Bowsher? enscript exif expat Max Bowsher? freeglut gcc*Dave Korn? gconf2 gnutls* indent jasper libdb* libexif* libfpx libgnutls11 libmng libopencdk8 libtasn1 libwmf libxml2*Yaakov S? libxslt Yaakov S? opencdk openjade opensp perl,perl_manpages Yitzchak Scott-Thoennes? I'd like to ask Yaakov, Max, Dave and Yitzchak, are you taking over, or are you still considering to take over? It would be nice to have that sorted out. Unless Gerrit objects (and he seems to have stopped responding to mail, so that seems unlikely) I'm taking over. I should have a release of perl 5.8.8 ready soon.
Re: Maintainer searched
On Wed, May 03, 2006 at 10:24:19PM +0200, Gerrit P. Haase wrote: Hello, there is not enough time to maintain all my packages. Who wants to maintain one or more of my packages, maybe Yaakov wants to take over some of the GTK+ related packages? Then there are some more major packages which really require a maintainer with more time than I have (i.e. GCC, Perl). If it's ok with you, I'll take perl.
(ATTN: binutils maintainer) Re: cygwin ld --out-implib treats informational message as warning
Can cygwin binutils be updated to include this patch? Thanks. On Fri, Jan 27, 2006 at 05:26:37PM +, Nick Clifton wrote: Hi Yitzchak, 2006-01-27 Yitzchak Scott-Thoennes [EMAIL PROTECTED] * pe-dll.c (pe_dll_generate_implib): Issue Creating library file: as informational message, not warning Approved and applied. Cheers Nick PS. We might as well leave the message in for now. I see no reason for the linker not to be informative if the user has requested it.
Re: The purpose of /etc/default ?
On Wed, Feb 08, 2006 at 06:29:40PM +0200, Jari Aalto wrote: The package contributors guide http://cygwin.com/setup.html Is silent about /etc/defaults. As is FHS 2.3. I don't even see any discussion of /etc/defaults on the FHS discussion list. /usr/share/foo/ may be a more appropriate place, depending on whether you view these files as configuration files (since their content is that of a configuration file) or data files (since they aren't actually *used* as configuration files, just compared to the live conf file and potentially copied to become the live configuration file). In Debian this directory has specific meaning: http://www.debian.org/doc/debian-policy/ch-opersys.html 9.3 System run levels and init.d scripts 9.3.2 Writing the scripts Often there are some variables in the init.d scripts whose values control the behaviour of the scripts, and which a system administrator is likely to want to change. As the scripts themselves are frequently conffiles, modifying them requires that the administrator merge in their changes each time the package is upgraded and the conffile changes. To ease the burden on the system administrator, such configurable values should not be placed directly in the script. Instead, they should be placed in a file in /etc/default, which typically will have the same base name as the init.d script. This extra file should be sourced by the script when the script runs. What does /etc/defaults mean under Cygwin? This should be documented in the package contributors guide as well. I think debian is on firmer ground than cygwin in putting files in /etc/defaults since they are sourced extensions of the real configuration files.
Re: g-b-s patch: upstream patch list
On Mon, Jan 30, 2006 at 10:45:10AM -0500, Igor Peshansky wrote: 2006-01-30 Eric Blake ebb9atbyu.net * templates/generic-build-script: Add ability to apply upstream patches, listed in CYGWIN-PATCHES/upstream_patches.lst. Now, for the upstream patches functionality, I think it would be easier if I actually posted my changes and we could compare on-list. I'll clean them up and post them in the next couple of days. FWIW, when I looked at this, it looked easiest just to apply the patches in unpack().
Re: Heads-up: G-B-S changes (bash, logging)
On Sat, Jan 28, 2006 at 03:43:43PM -0500, Igor Peshansky wrote: I've just committed a change that turns off logging functionality in the generic-build-script by default. Um, why?
please upload fortune-1.99.1-2
http://zipcon.net/~sthoenna/fortune/fortune-1.99.1-2-src.tar.bz2 http://zipcon.net/~sthoenna/fortune/fortune-1.99.1-2.tar.bz2 http://zipcon.net/~sthoenna/fortune/setup.hint setup.hint: sdesc: Print a random, perhaps interesting, adage; may contain offsensive material category: Games requires: cygwin libiconv2 test: 1.99.1-2 curr: 1.99.1-1 prev: 1.8-2
Re: please upload fortune-1.99.1-2
On Mon, Jan 16, 2006 at 10:58:15AM +0100, Corinna Vinschen wrote: On Jan 16 00:08, Yitzchak Scott-Thoennes wrote: http://zipcon.net/~sthoenna/fortune/fortune-1.99.1-2-src.tar.bz2 http://zipcon.net/~sthoenna/fortune/fortune-1.99.1-2.tar.bz2 http://zipcon.net/~sthoenna/fortune/setup.hint Uploaded. I'm curious, why is this marked as test? 1. Because I built it with a recent snapshot, so it requires a snapshot or 1.5.19 (which I hope will come soon...) 2. In case building with the generic build script causes any problems, I wanted people to have the option of keeping the 1.99.1-1 version, but I didn't want that to be prev, since the older version is a lot faster, and there may be some people still wanting to use it. After a while, I'd like 1.99.1-2 to replace 1.99.1-1 as curr.
some comments on the generic build script
I'd like some feedback on changes I made to the gbs for
fortune-1.99.1-2.
--- gbs.sh 2006-01-15 17:46:43.875859200 -0800
+++ fortune-1.99.1-2.sh 2006-01-15 22:26:48.129188800 -0800
@@ -66,6 +66,8 @@
fi
export src_orig_pkg=${topdir}/${src_orig_pkg_name}
+export debian_patch=fortune-mod_1.99.1-3.diff.gz
+export debian_patch_name=${topdir}/$debian_patch
# determine correct names for generated files
export src_pkg_name=${FULLPKG}-src.tar.bz2
@@ -179,7 +184,8 @@
# change this if the original package was not tarred
# or if it doesn't unpack to a correct directory
unpack() {
- tar xv${opt_decomp}f $1
+ tar xv${opt_decomp}f $1 \
+ zcat $debian_patch_name | patch -p0
}
mkdirs() {
@@ -349,6 +352,7 @@
if [ -e ${src_orig_pkg}.sig ] ; then \
cp ${src_orig_pkg}.sig ${srcinstdir}/ ; \
fi \
+ cp ${debian_patch_name} ${srcinstdir}/${debian_patch} \
cp $0 ${srcinstdir}/`basename $0` \
name=$0 text=SCRIPT sigfile \
if [ ${SIG} -eq 1 ] ; then \
@@ -195,7 +201,7 @@
unpack ${src_orig_pkg} \
cd ${topdir} \
if [ -f ${src_patch} ] ; then \
-patch -Z -p0 ${src_patch} ;\
+patch -p0 ${src_patch} ;\
fi \
mkdirs \
if [ -f ${topdir}/${log_pkg_name} ] ; then \
These hunks include what are basically upstream patches and keep/regenerate
my patches separately.
The last hunk was needed because the debian patch file has no
timestamps, so patch complained about the timestamp being not as
expected for files in both it and my patch.
Would it be worthwhile doing s/debian_/upstream_/ and folding the
other hunks in to the regular version, with the zcat|patch and cp
omitted if the variable isn't set?
@@ -127,6 +129,9 @@
THANKS \
TODO \
USAGE \
+ Offensive \
+ cookie-files \
+ debian \
export install_docs=`for i in ${install_docs}; do echo $i; done | sort -u`
export test_rule=check
These are added install_docs. debian includes
debian/{README.Debian,README.Debian.offensive,changelog,copyright}. At
first, I had debian/ \, because there seemed to be code to support
that, but it included two copies of the files in the binary tarball,
one under /usr/share/doc/fortune-1.99.1 and one under
/usr/share/doc/fortune-1.99.1/debian. This seemed a little odd.
Another minor issue was that install_docs has NOTES, which picked up
the Notes file (which I wanted), but stored it with the name all in
caps. Is there an easy way in bash to go through a list of filenames
and set the capitalization the way it actually is on disk?
@@ -203,16 +209,12 @@
tar xvjf ${topdir}/${log_pkg_name}
fi )
}
+# fortune isn't autoconfusticated, just make objdir - srcdir symlinks
conf() {
(cd ${objdir} \
- CFLAGS=${MY_CFLAGS} LDFLAGS=${MY_LDFLAGS} \
- ${srcdir}/configure \
- --srcdir=${srcdir} --prefix=${prefix} \
- --exec-prefix='${prefix}' --sysconfdir=${sysconfdir} \
- --libdir='${prefix}/lib' --includedir='${prefix}/include' \
- --mandir='${prefix}/share/man' --infodir='${prefix}/share/info' \
- --libexecdir='${sbindir}' --localstatedir=${localstatedir} \
- --datadir='${prefix}/share' 21 | tee ${configurelogfile} )
+ (cd ${srcdir} find * -type d) | xargs mkdir -p \
+ (for dir in `find`; do find ${srcdir}/$dir -maxdepth 1 -type f | xargs ln -s
-t $dir; done) \
+ touch ${configurelogfile} )
}
reconf() {
(cd ${topdir} \
No configure, so I just made symlinks under objdir for all the files
under srcdir (except toplevel directories starting with .).
Would it make sense to include something like that in the regular
version whenever there's no configure file?
@@ -222,7 +224,7 @@
}
build() {
(cd ${objdir} \
- make CFLAGS=${MY_CFLAGS} 21 | tee ${makelogfile} )
+ make 21 | tee ${makelogfile} )
}
check() {
(cd ${objdir} \
The Makefile set a lot of important stuff in CFLAGS= (including -O2)
which this overrode. Is this a common problem? Should I have patched
the Makefile to use a different variable name and include CFLAGS in it?
@@ -250,6 +252,7 @@
find ${instdir}${prefix}/share/info -name *.info | xargs -r gzip -q ; \
fi \
if [ -d ${instdir}${prefix}/share/man ] ; then \
+true breaks cause unstr.8 is symlink to strfile.8 || \
find ${instdir}${prefix}/share/man -name *.1 -o -name *.3 -o \
-name *.3x -o -name *.3pm -o -name *.5 -o -name *.6 -o \
-name *.7 -o -name *.8 | xargs -r gzip -q ; \
Took me a while to figure out why this was breaking things. I have
these:
-rw-r--r-- 1 sthoenna None 11485 Jan 15 22:27 ./man6/fortune.6
-rw-r--r-- 1 sthoenna None 7512 Jan 15 22:27 ./man8/strfile.8
lrwxrwxrwx 1 sthoenna None 9 Jan 15 22:27 ./man8/unstr.8 - strfile.8
and when gzip tried to compress unstr.8, strfile.8 was no longer there
(having become strfile.8.gz), causing the whole build process to stop.
Any easy fixes to suggest?
@@ -331,7 +334,7 @@
unpack ${src_orig_pkg} \
mv ${BASEPKG} ../${BASEPKG}-orig \
cd ${topdir} \
- diff -urN -x '.build' -x '.inst' -x
findutils maintainer: setup.hint lost?
Last I checked findutils had: curr: 4.2.25-2 prev: 20041227-1 test: 4.2.27-1 Now I see: curr: 20041227-1 prev: 4.2.27-1 as if the test: line were gone and 20041227 is assumed to be curr because it's greater than 4.
Re: findutils maintainer: setup.hint lost?
Subject should have been setup.hint test: lost? On Tue, Jan 17, 2006 at 01:10:42AM -0500, Christopher Faylor wrote: On Mon, Jan 16, 2006 at 09:52:37PM -0800, Yitzchak Scott-Thoennes wrote: Last I checked findutils had: curr: 4.2.25-2 prev: 20041227-1 test: 4.2.27-1 Now I see: curr: 20041227-1 prev: 4.2.27-1 as if the test: line were gone and 20041227 is assumed to be curr because it's greater than 4. Since 20041227-1 was my last release, I've taken the liberty of removing it. So, this should no longer be a problem. Thanks. And thanks for 1.5.19.
Re: Please upload: perl-Tk-804.027-4
On Thu, Jan 12, 2006 at 04:40:43PM -0600, Yaakov S (Cygwin Ports) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please upload: ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/perl-Tk-804.027-4-src.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/perl-Tk-804.027-4.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/setup.hint Please update the setup.hint as well. Hmm, is --enable-auto-image-base working right? Some of these are in what I thought was system-reserved space above 6800: Tk/Canvas/Canvas.dll ImageBase 681c Tk/Compound/Compound.dll ImageBase 6fc8 Tk/Entry/Entry.dll ImageBase 6454 Tk/Event/Event.dll ImageBase 6258 Tk/HList/HList.dll ImageBase 6490 Tk/InputO/InputO.dll ImageBase 6644 Tk/IO/IO.dll ImageBase 62a4 Tk/JPEG/JPEG.dll ImageBase 7020 Tk/Listbox/Listbox.dll ImageBase 6900 Tk/Menubutton/Menubutton.dll ImageBase 63a0 Tk/Mwm/Mwm.dll ImageBase 625c Tk/NBFrame/NBFrame.dll ImageBase 69ac Tk/Pixmap/Pixmap.dll ImageBase 6cf4 Tk/PNG/PNG.dll ImageBase 6bbc Tk/Scale/Scale.dll ImageBase 6fc4 Tk/Scrollbar/Scrollbar.dll ImageBase 67e8 Tk/Text/Text.dll ImageBase 70a0 Tk/TixGrid/TixGrid.dll ImageBase 69c8 Tk/Tk.dll ImageBase 7028 Tk/TList/TList.dll ImageBase 6c14 Tk/WinPhoto/WinPhoto.dll ImageBase 6f94 Tk/X/X.dll ImageBase 6cb4 Tk/Xlib/Xlib.dll ImageBase 6578
is there a standard way to get the g-b-s to apply multiple patches?
I'm working on updating the fortune package and switching to use the generic build script, but I'd like to have the source package to have the original source, the current debian patches, and a separate patch file with my patches. The debian package maintainer is also the maintainer of the upstream source, but he isn't updating that, just letting the debian patches get bigger and bigger over time. I'd like my patches to be distinguishable from what's standard.
Re: [ITP] updated: lighttpd-1.4.8-1 [Was: lighttpd on cygwin?]
On Wed, Jan 11, 2006 at 11:37:39PM -0700, Verse X wrote: Lapo Luchini wrote: Does this means that it fails to load to you as it conflicts with other DLLs? Yes, but only in certain cases and situations -- not in general. Whose fault is it? My ld.exe? No, ld still defaults to --disable-auto-image-base. Should I add a rebase in the building script? No, just LDFLAGS=-Wl,--enable-auto-image-base ./configure ... when configuring. Brian I'm new to this mailing list, and don't undertand what's going on here. Did Jan send Lapo some source patches, whereup Lapo built a lighttpd package, which he posted to http://www.lapo.it/cygwin/lighttpd-1.4.8-1.tar.bz2 (etc), and which people subsequently have problem using because of ImageBase 1000? And then Brian suggested that Lapo rebuild with some additional linker flags? This is how I sense the conversation went, although I couldn't figure out who Christopher is and what he meant by uploaded. My interest in this is simple: I would like to have the lastest lighttpd, with fastcgi, working under Cygwin. Using the tarball from www.lapo.it, I can install it successfully, but when I tried running it, I get this error ... 2006-01-11 23:33:19: (/home/lapo/packaging/tmp/lighttpd-1.4.8/src/mod_fastcgi.c.1209) --- fastcgi spawning port: 0 socket /tmp/lighttpd-socket current: 0 / 10 C:\cygwin\usr\sbin\lighttpd.exe (1072): *** unable to remap C:\cygwin\lib\lighttpd\mod_indexfile.dll to same address as parent(0x3F) != 0x97 9 [main] lighttpd 2224 fork_parent: child 1072 died waiting for dll loading If you guys can get this working, I think a LOT of people will be very thankful. I know I will :-) I feel my efforts at watching imagebases in incoming upload requests have been vindicated now :)
Re: [ITP] updated: lighttpd-1.4.8-1 [Was: lighttpd on cygwin?]
Sorry, my previous response was inadvertently sent before I was done. On Wed, Jan 11, 2006 at 11:37:39PM -0700, Verse X wrote: Lapo Luchini wrote: Does this means that it fails to load to you as it conflicts with other DLLs? Yes, but only in certain cases and situations -- not in general. Whose fault is it? My ld.exe? No, ld still defaults to --disable-auto-image-base. Should I add a rebase in the building script? No, just LDFLAGS=-Wl,--enable-auto-image-base ./configure ... when configuring. Brian I'm new to this mailing list, and don't undertand what's going on here. Note the description of this list from http://cygwin.com/lists.html: cygwin-apps: a subscriber-only list for discussing packaging issues regarding applications that are distributed with the Cygwin DLL. If you are maintaining or volunteering to maintain one of the packages that is distributed with the Cygwin net releases you should be subscribed to this list. This list is intended for discussing solutions. It is not (with one exception) for bug reports, it would be nice, or how do I type of musings. Do not subsccribe to this mailing list to ask questions about packages. Use the main cygwin mailing list for that. Did Jan send Lapo some source patches, whereup Lapo built a lighttpd package, which he posted to http://www.lapo.it/cygwin/lighttpd-1.4.8-1.tar.bz2 (etc), and which people subsequently have problem using because of ImageBase 1000? Lapo posted his message and gave the URL so his lighttpd package could be inspected preparatory to being included in the cygwin distribution. I noted a potential problem with how the dlls were built, though unfortunately not until after Lapo's package was uploaded by Christopher. I didn't actually try the package and have a problem. And then Brian suggested that Lapo rebuild with some additional linker flags? Yes, to correct the potential problem I noted. This is how I sense the conversation went, although I couldn't figure out who Christopher is and what he meant by uploaded. He's one of the folks who helpfully updates packages on the sourceware server where the cygwin distribution is kept. He was saying he had uploaded the package from Lapo's url to the server from whence it will get mirrored and become available via cygwin's setup.exe program. Also, see: http://cygwin.com/acronyms/#CGF
Re: [ITP] updated: lighttpd-1.4.8-1 [Was: lighttpd on cygwin?]
On Fri, Jan 06, 2006 at 12:48:08PM +0100, Lapo Luchini wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pre-amble (cygwin upload data): I produced some updated packages: URLs: http://www.lapo.it/cygwin/lighttpd-1.4.8-1.tar.bz2 The dll's in this package have ImageBase 1000.
Re: Security advisory: perl (CVE-2005-3962)
On Thu, Dec 29, 2005 at 09:55:16AM +0100, Gerrit P. Haase wrote: Corinna schrieb: On Dec 9 13:51, Yaakov S (Cygwin Ports) wrote: Gerrit, Perl is vulnerable to format string programming errors, that could be exploited to execute arbitrary code. Patch: http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/dev-lang/perl/files/perl-exp_intwrap.patch Gerrit? Ping? Ah, yes. Will revisit this issue today. The offical patch: http://search.cpan.org/CPAN/authors/id/N/NW/NWCLARK/sprintf-5.8.7.patch There were also a few subsequent patches to printf stuff, not directly related to the above security advisory, and a fix to Sys::Syslog which IIRC was.
Re: using --enable-auto-image-base
On Thu, Dec 22, 2005 at 07:55:06AM +0100, Gerrit P. Haase wrote: Yitzchak Scott-Thoennes wrote: On Mon, Dec 19, 2005 at 03:44:48AM -0800, Yitzchak Scott-Thoennes wrote: It had sounded like there was consensus that -Wl,--enable-auto-image-base should be used to build all dlls. Right now, we're a long way away from that goal: Should I have marked this in the subject Attention all maintainers? I didn't want to do so not knowing for sure that the consensus was as above. It is default now in libtool to include this flag, so all packages using libtool will be transfered automatically (if the latest libtool is used) and I think that it is not that imortant to convert all older packages. Most frequently reported problems are with perl, python and other packages with lot of modules, also openssl was often a problem. Openssl uses a unique base address for libcrypto but not for libssl, maybe both should use it? IMO important candidates are Apache/Apache2, perlTk and Ruby. I don't understand why perlTk doesn't has random base addresses, it should use ld2 as linker when building (but obviously it wasn't used). Perhaps he built it with an older release of perl?
Re: using --enable-auto-image-base
On Wed, Dec 21, 2005 at 11:06:59PM -0800, Brian Dessent wrote: Gerrit P. Haase wrote: perlTk and Ruby. I don't understand why perlTk doesn't has random base addresses, it should use ld2 as linker when building (but obviously it wasn't used). The reported problem with perl/tk had nothing to do with the perl/tk DLLs, it was a problem with cygz.dll needing rebasing. Right, but Gerrit has perl set to build all module dlls with auto image base, yet the new perl-Tk distribution doesn't have it set.
lock package option for setup (was: Re: Inconvenient ghostscript and transfig dependences)
On Wed, Dec 21, 2005 at 10:57:42AM -0500, Igor Pechtchanski wrote: On Wed, 21 Dec 2005, Yitzchak Scott-Thoennes wrote: On Tue, Dec 20, 2005 at 07:24:56PM -0500, Larry Hall (Cygwin) wrote: Sorry but there is currently no way to represent either/or dependencies via setup.exe (PTC). That said, there's no reason that you can't override setup.exe and not install gs-no-X11. If you know that's what you want, then you should feel free to do so. If your gripe is that setup.exe will try to install gs-no-X11 each time you run it, you should feel free to manually edit /etc/setup/install.db to include the package name and an impossibly high version number to fool setup.exe into thinking you already have a version installed that is more current than what it has available to it. This keeps getting advocated, but in my testing it does *not* work. If you have found otherwise, or see somewhere in the source for setup where this is supposedly implemented, please give some detailed information. But AFAICT, setup seems to have no concept of higher/lower version numbers, nor do I see how setup *could* understand the variety of version numbers out there. Which is higher, 20030307 or 1.875? 2.5.4a or 2.5.4? 2.8.0 or 2.10.1? These all involve assumptions that may or may not be true. Yes, you're correct. I've also been occasionaly guilty of recommending this option, and it indeed does not work. The code in setup.exe only checks for version equality, so if you have installed != current, current will be selected, even if installed is higher (for some definition of higher). It might be quicker (and easier) to implement a lock package option in installed.db, so that locked packages never get upgraded, even if their version is not the same as curr. http://cygwin.com/acronyms/#PTC (which I will provide eventually, though someone else is welcome to beat me to it). Vague thoughts... Maybe have each package to have Keep (that is, locked), Curr, and Exp options that get stored in installed.db, with Curr being the default, and add a Default radio button to the set at the top in setup.exe. But if the user selects Keep, Curr, or Exp in setup, that overrides the saved per-package stuff. I can't think of a clean way to allow setting things to Keep, etc., though; for now at least being able to hand edit installed.db would be great.
libjpeg62 source missing?
setup.ini says: setup-timestamp: 1135015205 ... @ libjpeg62 sdesc: A library for manipulating JPEG image format files (runtime) ldesc: The jpeg package contains a library of functions for manipulating JPEG images, as well as simple client programs for accessing the libjpeg functions. Libjpeg client programs include cjpeg, djpeg, jpegtran, rdjpgcom and wrjpgcom. Cjpeg compresses an image file into JPEG format. Djpeg decompresses a JPEG file into a regular image file. Jpegtran can perform various useful transformations on JPEG files. Rdjpgcom displays any text comments included in a JPEG file. Wrjpgcom inserts text comments into a JPEG file. category: Graphics Libs requires: cygwin version: 6b-11 install: release/jpeg/libjpeg62/libjpeg62-6b-11.tar.bz2 63560 c72c38cdace80478b318e968f8f9cee5 Where's the source?
Re: using --enable-auto-image-base
On Thu, Dec 22, 2005 at 04:20:51AM +0100, Gerrit P. Haase wrote: Yitzchak Scott-Thoennes wrote: Gerrit P. Haase: expat freeglut jasper libcroco06 libdb4.2 libdb4.3 libexif10 openjade OpenSP There are new DB, Expat and OpenSP releases on the way, no need to rebuild the older version IMO. I will do in case of DB if there are problems reported. Hmm, I'll take a look if there are newer releases of Exif, Jasper, Freeglut or Libcroco available. Openjade contains DLLs? Doesn't it use OpenSP as backend? Hmm, probably there will be an update once OpenSP is ready. Anyway, openjade is just an application, does anyone link to its library? Further down you'll see openjade: usr/bin/cygogrove-0.dll usr/bin/cygospgrove-0.dll usr/bin/cygostyle-0.dll But if nothing uses the dlls, there's no problem :)
Re: using --enable-auto-image-base
On Mon, Dec 19, 2005 at 03:44:48AM -0800, Yitzchak Scott-Thoennes wrote: It had sounded like there was consensus that -Wl,--enable-auto-image-base should be used to build all dlls. Right now, we're a long way away from that goal: Should I have marked this in the subject Attention all maintainers? I didn't want to do so not knowing for sure that the consensus was as above.
using --enable-auto-image-base
It had sounded like there was consensus that -Wl,--enable-auto-image-base should be used to build all dlls. Right now, we're a long way away from that goal: Maintainers of packages containing non-auto-image-based dlls (actually, dlls with ImageBase of 1000 or less; some packages not listed may actually not use --enable-auto-image-base): (Maintainers are as listed in Corinna's 6th summary, except for packages that didn't appear in that summary). no maintainer: libsmi libxerces-c24 libxerces-c25 lighttpd naim Alan Hourihane: xorg-x11-bin-dlls Andre Bleau: opengl Brian Ford: lesstif Charles Wilson: libbz2_1 libgeotiff1 ? libltdl6 (I have 1.9f_20041024-1; setup.ini now shows no files ?) libpng10 libpng12 libproj0 libtiff5 mingw-libbz2_1 mingw-zlib zlib Christopher Faylor: tcltk Corinna Vinschen: file libao2 libFLAC++5 libFLAC7 libogg0 libOggFLAC++2 libOggFLAC3 libspeex1 libvorbis0 libvorbisenc2 libvorbisfile3 openssl openssl097 ruby Dr. Volker Zell: compface libEMF1 libgd2 libopenldap2 libopenldap2_2_7 t1lib t1lib-x11 XmHTML Gareth Pearce: libsasl2 Gerrit P. Haase: expat freeglut jasper libcroco06 libdb4.2 libdb4.3 libexif10 openjade OpenSP Harold L Hunt II: cppunit libfontconfig1 libGraphicsMagick0 libMagick6 libXft1 libXft2 Xaw3d James R. Phillips: fftw3 lapack Jan Nieuwenhuizen: libguile16 libkpathsea3 libkpathsea4 lilypond Lapo Luchini: gmp tidy Max Bowsher: apache2 libneon24 OBSOLETE (Charles Wilson): cygipc (though obsolete, this package still contains files ?) Peter A. Castro: zsh Reini Urban: clamav mhash Robert Richter: apache Volker Quetschke: libgcrypt libgpg-error Yaakov S: glib gtk+ libaudiofile0 libglade2 libgnomecanvas2 libwnck libIDL2 ORBit2 ORBit2-devel perl-Tk startup-notification List of dll's by package (when a package contains some dll's that may have been built with --enable-auto-image-base, those are indicated by auto:) ORBit2: usr/bin/cygORBit-2-0.dll usr/bin/cygORBit-imodule-2-0.dll usr/bin/cygORBitCosNaming-2-0.dll ORBit2-devel: usr/lib/orbit-2.0/Everything_module.dll OpenSP: usr/bin/cygosp-4.dll Xaw3d: usr/X11R6/bin/cygXaw3d-7.dll XmHTML: usr/X11R6/bin/cygXmHTML-0.dll apache: usr/bin/libhttpd.dll usr/lib/apache/libproxy.dll usr/lib/apache/mod_access.dll usr/lib/apache/mod_actions.dll usr/lib/apache/mod_alias.dll usr/lib/apache/mod_asis.dll usr/lib/apache/mod_auth.dll usr/lib/apache/mod_auth_anon.dll usr/lib/apache/mod_autoindex.dll usr/lib/apache/mod_cern_meta.dll usr/lib/apache/mod_cgi.dll usr/lib/apache/mod_digest.dll usr/lib/apache/mod_dir.dll usr/lib/apache/mod_env.dll usr/lib/apache/mod_example.dll usr/lib/apache/mod_expires.dll usr/lib/apache/mod_headers.dll usr/lib/apache/mod_imap.dll usr/lib/apache/mod_include.dll usr/lib/apache/mod_info.dll usr/lib/apache/mod_log_agent.dll usr/lib/apache/mod_log_config.dll usr/lib/apache/mod_log_forensic.dll usr/lib/apache/mod_log_referer.dll usr/lib/apache/mod_mime.dll usr/lib/apache/mod_mime_magic.dll usr/lib/apache/mod_negotiation.dll usr/lib/apache/mod_rewrite.dll usr/lib/apache/mod_setenvif.dll usr/lib/apache/mod_speling.dll usr/lib/apache/mod_status.dll usr/lib/apache/mod_unique_id.dll usr/lib/apache/mod_userdir.dll usr/lib/apache/mod_usertrack.dll usr/lib/apache/mod_vhost_alias.dll apache2: usr/bin/cyghttpd2core.dll usr/lib/apache2/mod_access.so usr/lib/apache2/mod_actions.so usr/lib/apache2/mod_alias.so usr/lib/apache2/mod_asis.so usr/lib/apache2/mod_auth.so usr/lib/apache2/mod_auth_anon.so usr/lib/apache2/mod_auth_dbm.so usr/lib/apache2/mod_auth_digest.so usr/lib/apache2/mod_autoindex.so usr/lib/apache2/mod_cern_meta.so usr/lib/apache2/mod_cgi.so usr/lib/apache2/mod_dav.so usr/lib/apache2/mod_dav_fs.so usr/lib/apache2/mod_dir.so usr/lib/apache2/mod_env.so usr/lib/apache2/mod_expires.so usr/lib/apache2/mod_ext_filter.so
Re: [ITP] perl-Tk
On Thu, Dec 01, 2005 at 02:05:00PM -0600, Yaakov S (Cygwin Ports) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I wrote: Due to popular request, I would like to ITP Perl/Tk: ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/perl-Tk-804.027-3-src.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/perl-Tk-804.027-3.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/setup.hint This generated a lot more discussion than I anticipated, but no conclusive review. Gerrit, do you still have questions about the test suite, or is this GTG? At the risk of being...repetitive, could you name this package perl-Tk-X?
Re: setup installs packages without displaying it
On Sat, Nov 26, 2005 at 04:43:35AM +0100, Gerrit P. Haase wrote: Brian Dessent wrote: 3. Create a dummy package with version 99.999 or something so that setup will always think that what you have installed is newer than anything available. I think this could be as simple as just editing /etc/setup/installed.db to contain a line such as autoconf autoconf-99.999-1.tar.bz2 0, without actually creating a package. This is an intresting hint, thanks. Where in the source does setup do version comparisons?
Re: [ITP] perl-Tk
On Sun, Nov 20, 2005 at 12:34:33AM -0500, Charles Wilson wrote:
Yitzchak Scott-Thoennes wrote:
Hence the suggestion of using the features provided by the
alternatives package. Am I correct in assuming this works even for
dynamically loaded dlls?
No. It works for .so's on Linux, because the Linux loader understands
symlinks. Cygwin piggybacks on the Window Runtime Loader, which does
NOT understand symlinks (nor shortcuts!). Because alternatives relies
entirely on symlinks, it doesn't work for DLLs on windows.
WJFFM (perhaps you missed the dynamically?):
$ cat mydll.c
#include stdio.h
void hello(void)
{
printf (Hello World!\n);
}
$ gcc -Wall -shared -o mydll.dll mydll.c
$ ln -s mydll.dll mydllalternate.dll
$ cat myprog.c
#include dlfcn.h
int main(int argc, char **argv)
{
void *dlh = dlopen(mydllalternate.dll, RTLD_NOW);
void (*dls)(void) = dlsym(dlh, hello);
dls();
return 0;
}
$ gcc -Wall -o myprog.exe myprog.c
$ ./myprog.exe
Hello World!
Re: [ITP] perl-Tk
On Sun, Nov 20, 2005 at 11:50:53AM -0800, Brian Dessent wrote: Yitzchak Scott-Thoennes wrote: void *dlh = dlopen(mydllalternate.dll, RTLD_NOW); That's because dlopen() is a Cygwin function that understands things like LD_LIBRARY_PATH and posix paths. But if you use it you are not using the windows runtime loader, at least not directly. If you try your sample above using LoadLibrary it will fail. Anyway, I'm satisfied that alternatives could be used with perl extension dlls.
Re: [ITP] perl-Tk
On Fri, Nov 18, 2005 at 12:40:28PM -0600, Yaakov S (Cygwin Ports) wrote: Yitzchak Scott-Thoennes wrote: At the risk of incurring Corinna's wrath, I second the request. I'd like to see someone submit an X-less perl-Tk package too, with support in both for alternatives. Here are the issues: 1) Two ports of perl-Tk, one X11 and one Win32, *will* collide with each other, and may lead to more confusion from the end users. Hence the suggestion of using the features provided by the alternatives package. Am I correct in assuming this works even for dynamically loaded dlls? 2) Since 804.xxx, the Win32 build has been broken on Cygwin, whereas the X11 build works with a minor patch (to fix an assumption that Cygwin is using Win32). I've found Nick Ing-Simmons to be helpful before; has anyone actually let him know there's a problem? 3) The fact that tcltk is Win32 (as stated numerous times in the past, the reason being to support insight) does not mean that perl-Tk need be Win32 as well. 4) Even regarding tcltk, there's been discussion recently on finding a way to make the primary installation Unix/X11 and a secondary Win32 version for insight. Considering all the above, I found it most feasible to package *one* perl-Tk, based on X11, and I have yet to see a convicing argument otherwise. I wasn't trying to volunteer you to produce a non-X11 package; I just would like to have it be possible to create one later. When I get a few other things finished I make take a stab at it myself.
Re: [ITP] perl-Tk
On Fri, Nov 18, 2005 at 08:11:03AM +0100, Reini Urban wrote: Yaakov S (Cygwin Ports) schrieb: Due to popular request, I would like to ITP Perl/Tk: ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/perl-Tk-804.027-3-src.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/perl-Tk-804.027-3.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/setup.hint Can we have a -X in the name please, to make it clear that this is NOT the native version. I was just fighting again with the native version yesterday, but didn't succeed yet. Wonder what broke that since 804.025 At the risk of incurring Corinna's wrath, I second the request. I'd like to see someone submit an X-less perl-Tk package too, with support in both for alternatives. category: Perl X11 requires: cygwin crypt libXft2 libfontconfig1 libfreetype26 libjpeg62 libpng12 perl xorg-x11-base zlib sdesc: Perl interface for Tk (X11) ldesc: Complete Perl interface for Tk, built against Cygwin/X. -- Reini Urban http://phpwiki.org/
Re: New application proposal - git-core SCM
On Tue, Nov 01, 2005 at 11:03:07AM -0500, Christopher Faylor wrote: I don't know about the others but I don't think we want to have two competing versions of mutt in the distribution. I don't see mutt-ng in any linux distro either so it would need to be voted on anyway. I disagree; a very brief google on mutt-ng tells me it would reasonable to offer it as an alternative to vanilla mutt. Oh, and: http://packages.debian.org/experimental/mail/mutt-ng
Re: New application proposal - git-core SCM
On Wed, Nov 02, 2005 at 09:38:56AM +0100, Tim O'Callaghan wrote: On Tue, Nov 01, 2005 at 07:49:57PM +0100, Reini Urban wrote: $ cpan String::ShellQuote works out of the box. $ pmq String::ShellQuote 1.03/usr/lib/perl5/site_perl/5.8/String/ShellQuote.pm cygwin doesn't package each and every perl package. Fair enough. I'll add this to the the git post-install script. Not sure that's a good idea, since cpan String::ShellQuote will fetch files from the internet (are there other post-installs that do this?). Also, if cpan has never been used before, it will go into a lengthy configuration dialog to set up CPAN::Config. It would be better to include with your package a git-core-config script and document that it needs to be run before using git-core.
Re: HEADSUP: pcre security announcement
On Wed, Sep 07, 2005 at 09:22:37AM -0400, Igor Pechtchanski wrote: On Wed, 7 Sep 2005, Corinna Vinschen wrote: On Sep 7 08:47, Igor Pechtchanski wrote: On Wed, 7 Sep 2005, Corinna Vinschen wrote: First of all, many many thank for taking over. This is definitely worth a gold star. GR! Huh, did I miss something? ;-) BTW, should Alan Hourihane get a few as well? Er... didn't he get them already? D'oh! Igor Speaking of D'oh's, you seem to have given me the gold stars that were due Yaakov S :)
Re: Please upload: perl-libwin32-0.26-1
On Tue, Sep 20, 2005 at 06:56:44PM +0200, Corinna Vinschen wrote: On Sep 18 12:16, Reini Urban wrote: Please upload into perl: http://xarch.tu-graz.ac.at/publ/cygwin/release/perl-libwin32/perl-libwin32-0.26-1.tar.bz2 790765 d9e9278eb21dae1c2da0983e93acc900 http://xarch.tu-graz.ac.at/publ/cygwin/release/perl-libwin32/perl-libwin32-0.26-1-src.tar.bz2 718845 2ec0772ce228c2ad07d356768d34a2b0 Uploaded. perl-libwin32-0.191-4 can remain as prev, the rest deleted Done. Corinna Looks like setup.hint will need to explicitly give curr: and prev: @ perl-libwin32 sdesc: Perl extensions for using the Win32 API ldesc: Perl extensions for using the Win32 API. Included modules: Win32CORE, Win32API::File, Win32API::Net, Win32API::Registry, ChangeNotify, Clipboard, Console, Event, EventLog, File, FileSecurity, IPC, Internet, Job, Mutex, NetAdmin, NetResource, ODBC, OLE, PerfLib, Pipe, Process, Registry, Semaphore, Service, Shortcut, Sound, TieRegistry and WinError. category: System Libs requires: perl cygwin crypt version: 0.191-4 install: release/perl/perl-libwin32/perl-libwin32-0.191-4.tar.bz2 1179120 0d34ca5470a62cc190786bde5e238ab1 source: release/perl/perl-libwin32/perl-libwin32-0.191-4-src.tar.bz2 761933 ec3d0f37dde421edb761c780fe5338cf [prev] version: 0.26-1 install: release/perl/perl-libwin32/perl-libwin32-0.26-1.tar.bz2 790765 d9e9278eb21dae1c2da0983e93acc900 source: release/perl/perl-libwin32/perl-libwin32-0.26-1-src.tar.bz2 718845 2ec0772ce228c2ad07d356768d34a2b0
Re: Please upload: perl-libwin32-0.26-1
On Sun, Sep 18, 2005 at 04:23:17PM +0200, Reini Urban wrote: Gerrit P. Haase schrieb: Reini Urban wrote: ... properly rebased via gbs, though the general gbs solution to do a automatic rebase is quite hard. interested parties can see steps rebase1 and rebase2 in http://xarch.tu-graz.ac.at/publ/cygwin/release/perl-libwin32/perl-libwin32-0.26-1.sh Isn't ld2 used which uses the current perlld wrapper: $command =$CC -shared -o $dllname; $command .= -Wl,--output-def=$libname$DEF_EXT if $DEF_EXT; $command .= -Wl,--output-exp=$libname$EXP_EXT if $EXP_EXT; $command .= -Wl,--out-implib=$libname.dll$LIB_EXT if $LIB_EXT; $command .= -Wl,--export-all-symbols if $EXPORT_ALL; $command .= -Wl,--enable-auto-import -Wl,--stack,8388608; # always $command .= -Wl,--enable-auto-image-base; # always Yes, but doing it explicitly is IMHO better. How so? If user-built perl modules aren't getting -enable-auto-image-base set, that's a problem. If they are, why do you need to rebase?
Re: [HEADSUP] ALL Maintainers, please reply.
On Thu, Sep 15, 2005 at 06:45:37PM +0200, Corinna Vinschen wrote: Mails in the last couple of weeks indicate that we have lost one or the other maintainer without getting any notice from them. Since we have a couple of packages which haven't been updated for a good amount of time, there's apparently a need to find out, which packages are still maintained and which have lost their maintainer on the way. So, ALL maintainers of Cygwin packages, please reply to this mail within the next six weeks, including a list of ALL packages you maintain. This survey will run until 2005-10-31. I will ping every week, so you have a bit of time. However, if you don't reply until 2005-10-31, your packages will be up for grabs. Which means, they will disappear from the Cygwin net distribution if nobody wants to take over maintainership. I maintain: fortune I hope there will be an interval (a month?) between declaring packages up for grabs and actually removing them.
Re: [HEADSUP] ALL Maintainers, please reply.
On Thu, Sep 15, 2005 at 08:34:15PM +0200, Gerrit P. Haase wrote: Corinna Vinschen wrote: including a list of ALL packages you maintain. GConf2 OpenSP antiword atk* check db* libdb* enscript exif libexif* expat freeglut gcc* glib2* gnome-vfs2 gnutls* libgnutls11 gtk2-x11* indent intltool jasper lcms libart_lgpl libcroco libcroco06 libfpx libgnome2 libgnomeui2 libmng libtasn1 libwmf libxml2* libxslt opencdk openjade pango* perl perl_manpages Have I missed one? If anyone is interested to take over one or more packages feel free to do so, just drop me a note in my inbox. There are also packages in my private repository which could be taken, i.e. Gnome desktop related packages are done by Yaakov and me and there are at least 100 packages needed to run Gnome, not counted the bindings (Perl/C++/Python/Java/...) and applications. What do the *'s mean?
uncaught exceptions in setup
I've downloaded the new setup (2.510.2.2) and am trying to run it and getting uncaught exceptions like: Fatal Error: Uncaught Exception Thread: DialogProc Type: 9Exception Message: Package validation failure for file://C:\setup\cygwin/http%3a%2f%2fmirrors.rcn.net%2fpub%2fsourceware%2fcygwin/release/x11/fontconfig/libfontconfig-devel/libfontconfig-devel-2.2.2-1.tar.bz2 AppErrNo: 1 I would really prefer not to have to rename things I've already downloaded and installed just to download new stuff.
Re: uncaught exceptions in setup
On Sun, Sep 11, 2005 at 07:49:36AM -0700, Brian Dessent wrote: Yitzchak Scott-Thoennes wrote: I would really prefer not to have to rename things I've already downloaded and installed just to download new stuff. I'm really not sure why it's complaining now where it wasn't before. I don't remember touching any of that code. Forgot to mention I used -no-md5 before. In the setup.log.full, are there details as to why it's complaining? A file length mismatch? Sorry, meant to include this earlier. setup.log.full: 2005/09/11 11:25:06 Starting cygwin install, version 2.510.2.2 2005/09/11 11:25:06 Current Directory: C:\setup\cygwin 2005/09/11 11:25:06 Changing gid to Users 2005/09/11 11:25:06 Could not open service McShield for query, start and stop. McAfee may not be installed, or we don't have access. 2005/09/11 11:25:09 source: download 2005/09/11 11:25:10 Selected local directory: C:\setup\cygwin 2005/09/11 11:25:10 net: Direct get_url_to_membuf http://sources.redhat.com/cygwin/mirrors.lst getUrlToStream http://sources.redhat.com/cygwin/mirrors.lst 2005/09/11 11:25:13 site: http://mirrors.rcn.net/pub/sourceware/cygwin get_url_to_membuf http://mirrors.rcn.net/pub/sourceware/cygwin/setup.bz2 getUrlToStream http://mirrors.rcn.net/pub/sourceware/cygwin/setup.bz2 INVALID PACKAGE: file://C:\setup\cygwin/http%3a%2f%2fmirrors.rcn.net%2fpub%2fsourceware%2fcygwin/release/X11/xorg-x11-fsrv/xorg-x11-fsrv-6.8.1.0-1.tar.bz2 - Size mismatch: Ini-file: 185935 != On-disk: 185787 2005/09/11 11:25:50 mbox fatal: Fatal Error: Uncaught Exception Thread: DialogProc Type: 9Exception Message: Package validation failure for file://C:\setup\cygwin/http%3a%2f%2fmirrors.rcn.net%2fpub%2fsourceware%2fcygwin/release/X11/xorg-x11-fsrv/xorg-x11-fsrv-6.8.1.0-1.tar.bz2 AppErrNo: 1 2005/09/11 11:25:52 Ending cygwin install I guess this exception should just be removed, and let the md5 check handle it. IMO it should either behave as if the file isn't there or ignore the mismatch.
Re: Bug in setup 2.510.1.2
On Wed, Sep 07, 2005 at 02:59:46PM -0700, Brian Dessent wrote: Andr? Bleau wrote: Sorry to rain on the parade, but the new version of setup has a serious bug; it crashes when checking the integrity of .bz2 files. Works fine for me. Fatal Error: Uncaught Exception Thread: DialogProc Type: 9Exception Message: Package validation failure for file://E:\CygwinDownload/http%3a%2f%2fmirrors.rcn.net%2fpub%2fsourceware%2fcygwin/release/cmake/cmake-1.8.3-1.tar.bz2 AppErrNo: 1 Setup doesn't have great error recovery abilities, unfortunately. This error means that the file in your local cache has the wrong size, compared to what setup.ini says it should be. You should find more info in the log file. Currently setup just bails when it finds a corrupt package like this. You should delete the corrupt file as a workaround. This is one of the many files 2.510.2.2 complained about for me. The file isn't corrupt; I'm guessing cmake-1.8.3-1.tar.bz2 was uploaded more than once and some of us are lucky enough (not!) to have the older one.
Re: [PATCH] Re: missing sh.exe in coreutils
On Mon, Aug 15, 2005 at 11:20:41AM -0400, Igor Pechtchanski wrote: On Mon, 15 Aug 2005, Brian Dessent wrote: However, I just noticed something that will make life a lot easier - it sets the CYGWINROOT environment variable when running a script. This means that we should be able to just have a single .bat file containing @copy /y %CYGWINROOT$\bin\bash.exe %CYGWINROOT%\bin\sh.exe This needs testing, but it should work. Yep, it should (if you replace the '$' by a '%' in the first '%CYGWINROOT$' :-D). And assuming the user hasn't mounted /bin somewhere other than %CYGWINROOT%\bin. But I'm guessing if that were the case other parts of setup.exe would break anyway.
Re: [octave] packaging bug! (was: Re: man, info fail me in cygwin 1.5.18)
On Sun, Aug 14, 2005 at 12:33:33PM +0200, Gerrit P. Haase wrote: Rolf Maier wrote: If I type 'info man' I get multiple listings to help on fftw3 and Octave, and nothing else. Can anyone tell me what might have happened, and hence what I need to fix? Manually run /etc/postinstall/update-info-dir.sh.done
Re: RFC: update-alternatives
On Sat, Jun 18, 2005 at 04:06:25PM -0400, Charles Wilson wrote: (2) Red Hat (Fedora 4) + complete rewrite in C, no perl dependency + work-a-like to original Debian version - as is, requires libintl and libiconv which are not in Base ?? I thought they were (if only as dependencies), since bash uses them: $ cygcheck /usr/bin/bash.exe C:/cygwin/bin/bash.exe C:/cygwin/bin\cygwin1.dll C:\WINDOWS\System32\ADVAPI32.DLL C:\WINDOWS\System32\ntdll.dll C:\WINDOWS\System32\KERNEL32.dll C:\WINDOWS\System32\RPCRT4.dll C:/cygwin/bin\cygintl-3.dll C:/cygwin/bin\cygiconv-2.dll C:\WINDOWS\System32\USER32.dll C:\WINDOWS\System32\GDI32.dll Or is that just bash 3.0 that does that?
Re: how to automatically install all local packages
On Wed, May 18, 2005 at 03:04:34PM +0100, Max Bowsher wrote: Tod Courtney wrote: I appreciate both of your helpful replies. I guessed there would be ways to 'trick' the setup using configuration files and looked a little bit, but hadn't figured out how to do it. I understand both of your answers and will consider them if my patch (see next) takes some time to be accepted. I did determine how to change the setup code in order to set the initial installation mode to 'install' instead of 'default'. Once I found the place, it turned out to be a very small change. Basically I added a new command line option '-I, --install' that installs all available patches, rather than only installing the 'default' patches. The patch is included below. This patch is relative to the HEAD version, but the same patch can be applied to the current release code without any changes. From what I could tell, posting the patch to this list is the appropriate first step to its possible inclusion in the code. I hope the patch can be included, as it will be very helpful to me and my user base, and seems to have a very small probability of introducing problems. If there is a better way to submit this patch, please let me know. The patch submission is fine. However, I disagree with the concept of the patch. In the general case, an 'install all' feature will be almost never useful, since the Cygwin distribution contains so many packages that it is almost impossible to want to use every one. I have to disagree with this disagreement. Having to muck about editing setup.ini shouldn't be necessary. Installing all downloaded packages from a local directory should be easy. Furthermore, although setup doesn't explicitly implement it (yet) it is possible for packages to conflict with others - we even have a pair of packages for which this is the case: only one of tetex-tiny and tetex-base should ever be installed at a time. Is that documented? I don't use tetex, but have both installed :) How would a package that requires a tetex installation list it's requirement? I see several packages that require tetex-tiny. package tetex's ldesc seems to contradict you: This is teTeX, a TeX distribution for UNIX compatible systems. This virtual tetex package will install tetex-bin and tetex-tiny, the minimal working teTeX setup. It is advised to install tetex-base too. As I understand it, your use case is that you need a set of packages to default to Install. Since you already need to produce a custom setup.ini, it should be very easy for you to ensure that each of your packages in in either the Base or Misc category, which will cause setup to behave as you want, right now, without a patch. Is there a reason why this technique is not more useful than a command line option? AFAIK, the only need for a custom setup.ini is to change the category. You ideally should be able to do a Download Without Installing of selected packages and just save the Local Package Directory to cd with the full setup.ini as is, and then run setup in a mode to install everything available.
Re: Setup - Hiding ZZZRemovedPackages?
On Fri, May 06, 2005 at 10:13:56PM -0700, Brian Dessent wrote: Harold L Hunt II wrote: Would it be possible to hide the ZZZRemovedPackages category when in Category view, without changing the dependency logic regarding this category? Yes, in fact I've been meaning to bring this up. In terms of the end user, there should be no reason at all for them to see those packages, and I think it would be a good idea in general to remove them from sight entirely. The only worry I have is that if someone still has an ancient version of a package installed, they would no longer see it even though it's installed. Of course, if they just ran setup and accepted all the defaults they would get the new version of the package, without having to see them to select them. But I do wonder about those users (and I know they're out there) that insist on running 3 year old versions of some packages. I was thinking about making it a checkbox at the bottom of the dialog, that said Hide obsolete packages and defaults to checked. If the user unchecks it they would get the same display they get now. IMO it's less visual clutter just to show the category than to add a checkbox. Automatically unhide it if the user has anything other than the current version of any of the packages? Also, would it be possible to sort this category to the bottom of the list in all other views and ignore it when calculating the width to use for the Categories column? Currently the Categories column is too wide and scrunches the Package column because of the length of the ZZZRemovedPackages category name. If this is really a big issue, maybe make it ZZZRemoved instead? There aren't all that many hint files to change. That would be another way of doing it. I'm not sure how easy or hard it would be to make them sort down to the bottom though. And I'd prefer to get rid of them entirely.
Re: Update: perl-Win32-GUI, perl-libwin32
On Sat, Feb 12, 2005 at 11:56:14PM +0100, Gerrit P. Haase wrote: Reini Urban wrote: I would like to maintain perl-Win32-GUI, the Win32-platform native graphical user interface toolkit for perl, and I want to take over maintainership for perl-libwin32. We need a current perl-5.8.6 build. What about the changes we talk about in PM, are they still needed? Well, just tell me if I need to integrate the patches and release an update of perl *now* or if it may wait for another two weeks? Keep in mind that 5.8.7 should be out in about 4 weeks.
Re: new package: mined text editor
On Thu, Feb 10, 2005 at 08:56:03PM -0500, Christopher Faylor wrote: On Fri, Feb 11, 2005 at 02:31:07AM +0100, Gerrit P. Haase wrote: [EMAIL PROTECTED] wrote: If I remember correctly, I would have to wait until the package shows up in the distribution (being uploaded by you or some other kind maintainer) and then send a message to cygwin-announce, right? Uploaded. I removed the '@ mined' line from the setup.hint;) And, in the interests of space, I removed the 70 extra lines of inappropriate text from ldesc. This field isn't supposed to be an advertisement for the package it is supposed to be a more verbose description. I had no idea it was this big that when someone complained about the length of this field. How big is too big? Could http://cygwin.com/setup.html be modified to say?
Re: bsdgames
On Tue, Jan 18, 2005 at 12:03:01AM -0700, Warren Young wrote: Yitzchak Scott-Thoennes wrote: I'd leave out ones that are already packaged elsewhere (banner, wtf, fortune, etc.) or ones that don't build easily. I don't see people wanting 'just' fortune, or 'just' wtf. More likely, a person will be making a decision about whether they want their Cygwin installation to include entertainment options or not. How big is a complete bsdgames binary package for Cygwin? Leaving out banner, factor, fortune, robots, and wtf, which we already have in other packages, and dm, hunt, and monop which have build problems, the tarball is about 750k.
Re: bsdgames
On Tue, Jan 18, 2005 at 10:31:07AM +0100, Corinna Vinschen wrote: On Jan 18 00:03, Warren Young wrote: Yitzchak Scott-Thoennes wrote: I'd leave out ones that are already packaged elsewhere (banner, wtf, fortune, etc.) or ones that don't build easily. I don't see people wanting 'just' fortune, or 'just' wtf. More likely, a person will be making a decision about whether they want their Cygwin installation to include entertainment options or not. As long as it doesn't collide with the robots package we already have, it's ok. Cygwin's robots is a clone of the System V version, the BSD version is a bit boring and with a pretty small playfield. I'd rather keep System V robots. Or we could rename BSD robots to bsdrobots. I would just leave robots out. One thing I note is that the package by default puts the binaries in /usr/games, in accordance with FHS 2.2 and 2.3 (I didn't look at any earlier versions of FHS). Is this what we want? If so, fortune and robots at least should also be there. If we use /usr/games, should it be added to people's path?
Re: Packaging Conundrum
On Mon, Jan 17, 2005 at 02:04:41PM -0800, James R. Phillips wrote: Hi, Upstream for the newly added epstool package (Russell Lang) has asked via private email whether the CYGWIN-PATCHES subdir of a cygwin source package would really be required, if he modified the package makefile to include make targets for cygwin source and binary distributions. In essence, the question is whether a patches subdir is required if there really are no patches required to build either the source or the binary distribution. My guess is that such a subdir should always exist, containing at a minimum the setup.hint file. But I'm not really certain. Anyone have the answer for this? IIRC http://cygwin.com/setup.html says the (required) cygwin-specific readme goes there?
bsdgames
Is there any interest in a bsdgames package? Most of the games to compile with very little in the way of modifications needed. If so, ought it to be all one package, or one per game?
Re: bsdgames
On Mon, Jan 17, 2005 at 11:21:24PM -0500, Christopher Faylor wrote: On Mon, Jan 17, 2005 at 07:59:10PM -0800, Yitzchak Scott-Thoennes wrote: Is there any interest in a bsdgames package? Most of the games to compile with very little in the way of modifications needed. If so, ought it to be all one package, or one per game? How are they packaged elsewhere? Debian has a bsdgames package (http://packages.debian.org/unstable/source/bsdgames) and a bsdgames-nonfree package (http://packages.debian.org/unstable/games/bsdgames-nonfree) where the latter has games that have modification or commercial distribution restrictions (I think just rogue). I also see rpms out there with the games all in one. The games are: adventure: the original adventure by Crowther and Woods arithmetic: arithmetic quiz/speed test atc:air traffic control backgammon: backgammon banner: display a message in big letters battlestar: adventure game on a battlestar bcd:outputs text in an antique form boggle: boggle caesar: reads fortunes from the game fortune, also some internet posts canfield: curses-based solitaire countmail: tell you how much new mail you have cribbage: cribbage dab:dots and boxes dm: dungeon master, regulates games playing factor: factor a number fish: go fish fortune:displays a random silly message gomoku: gomoku hack: exploring the Dungeons of Doom hangman:guess the word before it is too late hunt: hunt each other in a maze (multiplayer -- great) mille: mille borne against the computer monop: monopoly morse: output morse code number: output the English text for a number phantasia: interterminal fantasy game pig:output text in Pig Latin pom:display the phase of the moon ppt:outputs text in another antique form primes: generate primes quiz: random knowledge tests rain: attempts to create a rain drop effect (best at 9600 baud) random: random lines from a file or random numbers robots: well... avoid the robots sail: sail your ship into battle snake: grab the cash and avoid the snake and exit tetris: tetris trek: We come in peace, shoot to kill. It's worse than that, he's dead Jim. Ye cannot change the laws of physics. It's life Jim, but not as we know it. There's Klingons on the starboard bow ... wargames: would you like to play a game? worm: eat the numbers without running into anything worms: random worms scurrying across your screen wtf:translate acronyms, e.g. wtf is WTF wump: hunt the wumpus I'd leave out ones that are already packaged elsewhere (banner, wtf, fortune, etc.) or ones that don't build easily. Note that some of the games require dictionaries in /usr/share/dict/. I'd have to look more into how to possibly package dictionaries.
Re: fortune-1.99.1
On Thu, Jan 13, 2005 at 10:16:39AM +0100, Reini Urban wrote: Yitzchak Scott-Thoennes: All debian version 1.99.1-1 patches to the data files have been applied (see http://packages.debian.org/unstable/source/fortune-mod), including spelling changes and removal of a number of Deutsch quotes. = german quotes please. Deutsch would be a person. I'll take your word for it, but http://en.wikipedia.org/wiki/German_language lies then. That text is also in the readme; I'll upload a new version in a little bit.
Re: fortune-1.99.1
On Thu, Jan 13, 2005 at 12:43:12PM +0100, Corinna Vinschen wrote: On Jan 13 11:19, Reini Urban wrote: Yitzchak Scott-Thoennes schrieb: On Thu, Jan 13, 2005 at 10:16:39AM +0100, Reini Urban wrote: Yitzchak Scott-Thoennes: All debian version 1.99.1-1 patches to the data files have been applied (see http://packages.debian.org/unstable/source/fortune-mod), including spelling changes and removal of a number of Deutsch quotes. = german quotes please. Deutsch would be a person. I'll take your word for it, but http://en.wikipedia.org/wiki/German_language lies then. German is complicated and full of traps. Maybe you mixed that with dutch? Dutch quotes (as adjective) would be ok. ... but wouldn't mean the same, of course, because that would be too easy. Keep it in English please. Deutsch would be incorrect in this context anyway. *If* you want to use it, say deutsche quotes, but that's bad English ;-) I'm wondering if we should add a WARNING: Contains potentially offensive texts(*) to the sdesc in setup.hint. Not that I like the idea, but it seems appropriate to avoid more discussion on the list. What do you think? Oh, yes, the package itself looks ok to me. I'll upload it after you, Yitzchak, have said a word about the sdesc. How about: sdesc: Print a random selection from a database of adages, some offensive category: Games requires: cygwin libiconv2
Re: fortune-1.99.1
On Thu, Jan 13, 2005 at 11:22:06AM -0500, Igor Pechtchanski wrote: On Thu, 13 Jan 2005, Yitzchak Scott-Thoennes wrote: On Thu, Jan 13, 2005 at 12:43:12PM +0100, Corinna Vinschen wrote: On Jan 13 11:19, Reini Urban wrote: Yitzchak Scott-Thoennes schrieb: On Thu, Jan 13, 2005 at 10:16:39AM +0100, Reini Urban wrote: Yitzchak Scott-Thoennes: All debian version 1.99.1-1 patches to the data files have been applied (see http://packages.debian.org/unstable/source/fortune-mod), including spelling changes and removal of a number of Deutsch quotes. = german quotes please. Deutsch would be a person. I'll take your word for it, but http://en.wikipedia.org/wiki/German_language lies then. German is complicated and full of traps. Maybe you mixed that with dutch? Dutch quotes (as adjective) would be ok. ... but wouldn't mean the same, of course, because that would be too easy. Keep it in English please. Deutsch would be incorrect in this context anyway. *If* you want to use it, say deutsche quotes, but that's bad English ;-) I'm wondering if we should add a WARNING: Contains potentially offensive texts(*) to the sdesc in setup.hint. Not that I like the idea, but it seems appropriate to avoid more discussion on the list. What do you think? Oh, yes, the package itself looks ok to me. I'll upload it after you, Yitzchak, have said a word about the sdesc. How about: sdesc: Print a random selection from a database of adages, some offensive category: Games requires: cygwin libiconv2 I like Corinna's suggestion of adding may contain offensive material instead, just to emphasize that offensive material in default fortunes is not a regular occurrence, and is a bug. Ok. I just didn't want to make it too long, but I see a number of packages have lengths 80. Corinna, please use the following, or your wording, or adjust however you want: sdesc: Print a random, hopefully interesting, adage; may contain offsensive material category: Games requires: cygwin libiconv2 That said, is there a reason your setup.hint doesn't have an ldesc? I couldn't think of what to say? Almost 10% of packages don't have one.
Re: fortune-1.99.1
On Thu, Jan 13, 2005 at 09:15:13AM -0800, Yitzchak Scott-Thoennes wrote: Corinna, please use the following, or your wording, or adjust however you want: sdesc: Print a random, hopefully interesting, adage; may contain offsensive material category: Games requires: cygwin libiconv2 Oops, changed it to German in the cygwin specific README but didn't update the reverse patch. Will re-upload the source tarball now.
fortune-1.99.1
A new version of fortune, based on the debian 1.99.1-1 release
is available at:
http://www.efn.org/~sthoenna/fortune-1.99.1-1.tar.bz2
http://www.efn.org/~sthoenna/fortune-1.99.1-1-src.tar.bz2
http://www.efn.org/~sthoenna/setup.hint
Setup hint:
sdesc: Print a random, hopefully interesting, adage
category: Games
requires: cygwin libiconv2
Even though the new upstream version is now named fortune-mod, not
fortune, I've chosen to keep the package name as just fortune in
case it is later decided to break it up into separate packages
fortune-mod, fortunes, fortunes-off, etc. ala debian.
Although the upstream Makefile now puts the strfile and unstr
utilities in /usr/bin, I've kept them in /usr/sbin where the previous
cygwin version put them; let me know if you think they should go in
/usr/bin instead, or if any other packaging changes are wanted.
N.B. the source and patch contain offensive material in plaintext.
Does the following release announcement look ok? :
Achilles: Don't tell me you believe in fortune-telling!
Tortoise: No...but they say it works even if you don't believe in it.
-- GEB, Hofstadter
I've made a new version of fortune available for installation.
As of version 1.99.1-1, the fortune database has been reorganized and
recategorized. See /usr/share/doc/fortune-1.99.1/{cookie-files,Offensive}.
If you happen across offensive fortunes in the supposedly unoffensive
files, report them to cygwin@cygwin.com and they will be moved if
appropriate. You will get faster response if you also take the time
to file a debian bug report (see README.Debian.offensive in
/usr/share/doc/fortune-1.99.1/debian). If you want to audit the
fortune files for offensiveness, do *not* report your results to
cygwin@cygwin.com; instead, pester the upstream maintainer (see
http://www.redellipse.net/code/fortune).
All debian version 1.99.1-1 patches to the data files have been
applied (see http://packages.debian.org/unstable/source/fortune-mod),
including spelling changes and removal of a number of Deutsch quotes.
(Debian provides several language specific fortune datafile packages
that are as yet not distributed in cygwin.)
Removed use of recode, since the recode library seems to have problems;
instead use fake recode functions using iconv. The problems with iconv
that led to fortune changing to recode are somewhat mitigated by using
iconv's transliteration option. This should be a temporary measure.
For a brief description of this package, and a listing of the files it
contains, see http://cygwin.com/packages/ .
To update your installation, click on the Install Cygwin now link on
the http://cygwin.com/ web page. This downloads setup.exe to your
system. setup.exe is the utility that cygwin uses to install and
update its packages.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want to unsubscribe from the cygwin-announce mailing list, look
at the List-Unsubscribe: tag in the email header of this message.
Send email to the address specified there. It will be in the format:
[EMAIL PROTECTED]
If you need more information on unsubscribing, start reading here:
http://sources.redhat.com/lists.html#unsubscribe-simple
Please read *all* of the information on unsubscribing that is available
starting at the above URL.
