Re: RFU (test): libfltk-1.3
On 2012-03-27 16:13, A.R. Burgers wrote: wget http://members.quicknet.nl/ar.burgers/cygwin17/fltk.tar.bz2 tar jxvf fltk.tar.bz2 will recreate the dist Uploaded, and marked libfltk-devel and libfltk-doc 1.3 as test. Yaakov
Re: RFU (test): libfltk-1.3
Op 26-3-2012 4:19, Yaakov (Cygwin/X) schreef: * Please use "fltk" for PN instead of libfltk as you did for 1.1. Because the fltk package was empty, only associated with the source, I hoped to get rid of that by creating a libfltk1.3 package that has both the dll-s and the source. That apparently doesn't fly, I reverted to fltk. * PV is vague. Either it should be 1.3.0 for the stable version or e.g. 1.3.0.9296 for the latest 1.3.x snapshot. fixed * The -devel and -doc packages are reversed; replace the PKG_* lines with: PKG_NAMES="libfltk1.3 libfltk-devel libfltk-doc" libfltk1_3_CONTENTS="usr/bin/*-1.3.dll" libfltk_devel_CONTENTS="--exclude=doc etc/ usr/bin/fltk-config usr/bin/fluid.exe usr/include usr/lib/ usr/share/" libfltk_doc_CONTENTS="usr/share/doc/" Fixed * Please install libXinerama-devel when rebuilding, which will add a dependency on libXinerama1. I had this installed, and the dll refered to Xinerama dll, but it was missing from the dependency list. libXext was missing from that as well. Thanks for your feedback, much appreciated. wget http://members.quicknet.nl/ar.burgers/cygwin17/fltk.tar.bz2 tar jxvf fltk.tar.bz2 will recreate the dist tar jtvf fltk.tar.bz2: fltk/ fltk/fltk-1.3.1.9285-1-src.tar.bz2 fltk/fltk-1.3.1.9285-1.tar.bz2 fltk/libfltk-devel/ fltk/libfltk-devel/libfltk-devel-1.3.1.9285-1.tar.bz2 fltk/libfltk-devel/setup.hint fltk/libfltk-doc/ fltk/libfltk-doc/libfltk-doc-1.3.1.9285-1.tar.bz2 fltk/libfltk-doc/setup.hint fltk/libfltk1.3/ fltk/libfltk1.3/libfltk1.3-1.3.1.9285-1.tar.bz2 fltk/libfltk1.3/setup.hint fltk/setup.hint
Re: libtcl8.5.dll collides with Cygwin DLL by default
On Mon, Mar 26, 2012 at 01:25:05PM -0400, Christopher Faylor wrote: >On Mon, Mar 26, 2012 at 12:33:01PM -0400, Christopher Faylor wrote: >>On Mon, Mar 26, 2012 at 06:19:08PM +0200, Corinna Vinschen wrote: >>>Chris? Ping? >> >>I am aware that you want a change. I will get to it when I get to it. > >To add a little more detail: the reason I didn't just roll a new >binutils and dust my hands together over a job well done is because I >don't like the idea of needing to release a new version of binutils just >to update a constant in the source. I was considering having binutils >look at cygwin1.dll automatically but that is hardly foolproof. I've >finally decided that I'll modify --enable-auto-image-base to accept a >number to use as the base. Then there will always be a workaround when >cygwin1.dll grows in size. A new binutils has been uploaded. Documentation has been updated for the added functionality. cgf
cygport: question about dodoc
Is there a simple way to use dodoc to copy a whole directory (and its
subdirectories) into /usr/share/doc/${PN}?
Currently I have an example in which I want to achieve the effect of
dodir /usr/share/doc/${PN}
cp -r ${S}/manual/ ${D}/usr/share/doc/${PN}
In this example, "manual" has a subdirectory "en", which contains some
files and a subdirectory "images". The only way I could see to do this
using dodoc is:
docinto manual/en
dodoc ${S}/manual/en/*
docinto manual/en/images
dodoc ${S}/manual/en/images/*
I was hoping for something simpler, like
dodoc ${S}/manual/
but that doesn't work.
Ken
Re: RFU: python-crypto 2.5-1
On Mar 27 16:56, Jari Aalto wrote: > > New upstream release: > > wget --recursive --no-host-directories --cut-dirs=3 \ > > http://cante.net/~jaalto/tmp/cygwin/python-crypto/python-crypto-2.5-1-src.tar.bz2 > \ > > http://cante.net/~jaalto/tmp/cygwin/python-crypto/python-crypto-2.5-1.tar.bz2 > \ > http://cante.net/~jaalto/tmp/cygwin/python-crypto/setup.hint Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
RFU: python-crypto 2.5-1
New upstream release: wget --recursive --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/python-crypto/python-crypto-2.5-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/python-crypto/python-crypto-2.5-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/python-crypto/setup.hint Jari
Re: Can I help with missing Cygwin man pages?
On 3/26/2012 10:49 AM, Wayne Newberry wrote: > I've noticed some scattered posts about missing Cygwin man pages. > I'm willing to help, but I'm not sure what I would be getting into. > I'm a technical writer, so I might need some help to get started and > to understand how to proceed. > Based on some advice, I've downloaded and extracted the > man-pages-3.32-14.fc16.noarch RPM and I'm comparing the man2, man3, > and man5 directories for Cygwin and this RPM. > I believe that these directories are the appropriate places to start. > What's the next step? > Thanks, > Wayne > Wayne, I can help. Contact me by private email, and we'll work it out. There are lots of problems with 'man' "pages", besides just omissions; most especially page and section headers which foul up 'makewhatis', 'apropos', and 'whatis'. I have various tools that identify and fix problems, as well as templates; and I'll be happy to supply templates, and syntax (groff) editing. To all, How do we get upstream developers to fix their man pages, if we supply the corrections? This seems especially difficult since a variety of base formats are used, including: * nroff/troff/man macros (groff) * nroff/troff w/o man macros * DocBook * Other XML/XSLT-based formats * "Standard" HTML/CSS * "Standard" plain text * ... Lee
Re: [SECURITY] lighttpd
On 2012-03-27 06:01, Lapo Luchini wrote: Yaakov (Cygwin/X) wrote: The attached .cygport and patch WFM. Do these not work for you? Nope, it's just the same as the 1.4.28 as found on CygPorts repository (and trivially-updated to 1.4.30). Didn't report it yet because I hadn't the time to check it on a different box, but here it goes: % cygport lighttpd-1.4.30-1 prep build Preparing lighttpd-1.4.30-1 Unpacking source lighttpd-1.4.30.tar.xz *** Info: applying patch 1.4.28-no-undefined.patch: patching file src/Makefile.am Hunk #1 succeeded at 89 (offset 1 line). Preparing working source directory *** Info: applying patch lighttpd-1.4.30-1.cygwin.patch: patching file CYGWIN-PATCHES/README patching file CYGWIN-PATCHES/setup.hint Compiling lighttpd-1.4.30-1 autoreconf-2.68: Entering directory `.' autoreconf-2.68: configure.ac: not using Gettext autoreconf-2.68: running: aclocal --force -I m4 autoreconf-2.68: configure.ac: tracing autoreconf-2.68: running: libtoolize --copy --force libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' autoreconf-2.68: running: /usr/bin/autoconf-2.68 --force configure.ac:1: error: possibly undefined macro: dnl If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:57: error: possibly undefined macro: AC_CHECK_HEADERS configure.ac:71: error: possibly undefined macro: AC_DEFINE configure.ac:108: error: possibly undefined macro: AC_CHECK_LIB configure.ac:112: error: possibly undefined macro: AC_MSG_ERROR autoreconf-2.68: /usr/bin/autoconf-2.68 failed with exit status: 1 *** ERROR: autoreconf failed Then something is wrong with your installation or environment. I'll need your `cygcheck -srv' output. Yaakov
Re: [SECURITY] lighttpd
Yaakov (Cygwin/X) wrote: >> PS: my Win7 cygwin needs rebaseall very very often. Still didn't check >> it through. > > BLODA? Windows Defender, but I de-activated the online scan and (wrongly?) hoped this de-activated the hook. It probably doesn't, I'll try disabling the service as suggested in the ML, but in the meantime I'm using a VirtualBox+WinXP as a Cygwin build-box (BTW it's quite slower than real hardware, of course, but "feels" even slower than other Windows-native stuff that runs in there; didn't check in deep yet). > The attached .cygport and patch WFM. Do these not work for you? Nope, it's just the same as the 1.4.28 as found on CygPorts repository (and trivially-updated to 1.4.30). Didn't report it yet because I hadn't the time to check it on a different box, but here it goes: % cygport lighttpd-1.4.30-1 prep build >>> Preparing lighttpd-1.4.30-1 >>> Unpacking source lighttpd-1.4.30.tar.xz *** Info: applying patch 1.4.28-no-undefined.patch: patching file src/Makefile.am Hunk #1 succeeded at 89 (offset 1 line). >>> Preparing working source directory *** Info: applying patch lighttpd-1.4.30-1.cygwin.patch: patching file CYGWIN-PATCHES/README patching file CYGWIN-PATCHES/setup.hint >>> Compiling lighttpd-1.4.30-1 autoreconf-2.68: Entering directory `.' autoreconf-2.68: configure.ac: not using Gettext autoreconf-2.68: running: aclocal --force -I m4 autoreconf-2.68: configure.ac: tracing autoreconf-2.68: running: libtoolize --copy --force libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' autoreconf-2.68: running: /usr/bin/autoconf-2.68 --force configure.ac:1: error: possibly undefined macro: dnl If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:57: error: possibly undefined macro: AC_CHECK_HEADERS configure.ac:71: error: possibly undefined macro: AC_DEFINE configure.ac:108: error: possibly undefined macro: AC_CHECK_LIB configure.ac:112: error: possibly undefined macro: AC_MSG_ERROR autoreconf-2.68: /usr/bin/autoconf-2.68 failed with exit status: 1 *** ERROR: autoreconf failed -- Lapo Luchini - http://lapo.it/
Re: RM: spamprobe
On Mar 26 09:56, Eric Blake wrote: > On 03/25/2012 02:25 PM, Christopher Faylor wrote: > > On Sun, Mar 25, 2012 at 01:19:09PM +0300, Jari Aalto wrote: > >> Please remove spamprobe: > >> > >>- No longer compiles with latest libdb > >>- Blocks libpng12 to libpng14 upgrade on Cygwin > >>- There are alternatives > > > > I created an empty package and moved the category to "_obsolete". > > Jari, please send an announcement mail declaring that the package is > obsolete. I agree. And, Jari, please keep an eye on the main list. There's a message concerning one of your packages. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: More fault tolerant rebase (was Re: libtcl8.5.dll collides with Cygwin DLL by default)
On Mar 26 21:44, Jason Tishler wrote: > Corinna, > > On Mon, Mar 26, 2012 at 06:15:59PM +0200, Corinna Vinschen wrote: > > Jason? Ping? > > > > On Mar 19 18:59, Corinna Vinschen wrote: > > > On Mar 19 12:59, Jason Tishler wrote: > > > > On Mon, Mar 19, 2012 at 10:57:41AM +0100, Corinna Vinschen wrote: > > > > > Jason? Ping? > > > > > > > > I looked through the patch and it seems OK. ATM, that's the best > > > > I can do. Let me know when to release a new package. > > > > > > Thanks for looking. I've applied the patch and I think it would be > > > helpful to get a new release ASAP, so we can start automating > > > rebasing from setup. > > I just released rebase-4.1.0-1. Sorry for the delay. No worries and thank you. I'll upload the _autorebase package now and then we'll see if that works as expected for all (or at least most) people. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: libtcl8.5.dll collides with Cygwin DLL by default
On Mar 26 13:25, Christopher Faylor wrote: > On Mon, Mar 26, 2012 at 12:33:01PM -0400, Christopher Faylor wrote: > >On Mon, Mar 26, 2012 at 06:19:08PM +0200, Corinna Vinschen wrote: > >>Chris? Ping? > > > >I am aware that you want a change. I will get to it when I get to it. > > To add a little more detail: the reason I didn't just roll a new > binutils and dust my hands together over a job well done is because I > don't like the idea of needing to release a new version of binutils just > to update a constant in the source. I was considering having binutils > look at cygwin1.dll automatically but that is hardly foolproof. I've > finally decided that I'll modify --enable-auto-image-base to accept a > number to use as the base. Then there will always be a workaround when > cygwin1.dll grows in size. Sounds good. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
