Re: More fault tolerant rebase (was Re: libtcl8.5.dll collides with Cygwin DLL by default)
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. Thanks, Jason
Re: libtcl8.5.dll collides with Cygwin DLL by default
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. If I was more ambitious, I'd make this a settable option, maybe in a linker file, but that's something for the future. cgf
Re: automake 1.11.2 ?
On 3/25/2012 2:40 AM, Yaakov (Cygwin/X) wrote: > On 2012-03-24 22:12, Yaakov Selkowitz wrote: >> Chuck, >> >> In the last few weeks I have seen a few packages which require >> automake-1.11.2. Any chance you could update this soon? > > Actually, make that 1.11.3. > >> Oh, and ping on the libpng security updates? Ack. -- Chuck
Re: libtcl8.5.dll collides with Cygwin DLL by default
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. And, thanks for not bcc'ing me this time. cgf
Re: Can I help with missing Cygwin man pages?
On Mar 26 10:49, 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? The next step would be to prepare a Cygwin man pages package from the files from man-pages-3.32-14.fc16.noarch. See http://cygwin.com/setup.html for how to create a package. Btw., the Linux man-pages package contains not only the Opengroup man pages, but also the Linux specifc man pages. For a start I think it would make sense to include only the Opengroup man pages. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: parrot depends on opengl
Reini, Ping? Are you not with us anymore? On Mar 19 10:54, Corinna Vinschen wrote: > Reini, Ping? > > On Mar 14 18:47, Corinna Vinschen wrote: > > On Mar 12 16:13, Corinna Vinschen wrote: > > > Hi Reini, > > > > > > I just noticed that parrot is the only package in the distro which still > > > depends on the Win32-GUI opengl package, rather than the X11 OpenGL > > > libraries. Shouldn't that be fixed? > > > > Parrot also has a dependency to openssl, rather than to libopenssl098. > > Since I'm going to update openssl to 1.0.1, I've changed that on > > cygwin.com. > > > 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
Chris? Ping? On Mar 19 18:52, Corinna Vinschen wrote: > On Mar 19 12:52, Christopher Faylor wrote: > > On Mon, Mar 19, 2012 at 10:59:09AM +0100, Corinna Vinschen wrote: > > >Chris? Ping? > > > > > >On Mar 15 10:12, Corinna Vinschen wrote: > > >> On Mar 14 20:50, Yaakov (Cygwin/X) wrote: > > >> > On 2012-03-08 03:12, Corinna Vinschen wrote: > > >> > >The assumption that the Cygwin DLL has a given size and will never > > >> > >change is flawed. How are we supposed to add new functionality if the > > >> > >DLL has to stick at a certain size? And even using another GCC can > > >> > >easily change the size of the DLL, given changes in code generation. > > >> > > > >> > Improving rebase is great, but should something be done to fix > > >> > compute_dll_image_base(), perhaps change the base to 0x6180 to > > >> > give plenty of room for Cygwin? > > >> > > >> I think that's a good idea. But 0x6180 is a bit much, I think. The > > >> most important factor for the bigger size of the Cygwin DLL was the > > >> raise of the cygheap from 512K to 2 Megs. This won't happen anymore for > > >> a loong time. Therefore, 0x6160 should be more than enough for > > >> a while. That gives us another 2 Megs for other DLLs. > > >> > > >> What do you think, Chris? Is that worth a new binutils? > > > > I saw the comment. I've never looked at the code in question so I didn't > > have a ready answer. > > I think a new binutils would be a good thing, with the start address in > ld/emultempl/pe.em, function compute_dll_image_base, changed from > 0x6130 to 0x6150 or 0x6160 so that the default base for DLLs > doesn't potentially colide with the bigger cygheap. > > Looking once more into that, I think 0x6150 is sufficient. In > 1.7.11 the end address of the cygheap is 0x6148, it's size 0x20f000, > in the most recent snapshot it's 0x6148 as well, it's size 0x20e000. > That means, if we choose 0x6150, we have still 184K room for > extension. Since we don't raise the size of the cygheap anymore, that > should be more than enough for a while... > > > 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)
Jason? Ping? On Mar 19 18:59, Corinna Vinschen wrote: > On Mar 19 12:59, Jason Tishler wrote: > > Corinna, > > > > 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. > > > Thanks, > Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: RM: spamprobe
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. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Can I help with missing Cygwin man pages?
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
Re: RFU: pngcrush-1.7.26
2012-03-26 00:38 "Yaakov (Cygwin/X)" : | On 2012-03-25 03:29, Jari Aalto wrote: | | > New upstream release: | > | > wget --recursive --no-host-directories --cut-dirs=3 \ | > http://cante.net/~jaalto/tmp/cygwin/pngcrush/pngcrush-1.7.26+20120223+gitb6d8931-1-src.tar.bz2 \ | > http://cante.net/~jaalto/tmp/cygwin/pngcrush/pngcrush-1.7.26+20120223+gitb6d8931-1.tar.bz2 \ | > http://cante.net/~jaalto/tmp/cygwin/pngcrush/setup.hint | | Uploaded. Can any previous versions be removed? Yes, Jari
Re: RFU: pngquant 1.7.2-1
2012-03-26 00:39 "Yaakov (Cygwin/X)" | On 2012-03-25 04:58, Jari Aalto wrote: | | > New upstream release: | > | > wget --recursive --no-host-directories --cut-dirs=3 \ | > http://cante.net/~jaalto/tmp/cygwin/pngquant/pngquant-1.7.2-1-src.tar.bz2 \ | > http://cante.net/~jaalto/tmp/cygwin/pngquant/pngquant-1.7.2-1.tar.bz2 \ | > http://cante.net/~jaalto/tmp/cygwin/pngquant/setup.hint | | Uploaded. Can any previous versions be removed? Yes. Likewise for the others too. Jari
Re: RFU: wcd 5.2.1-1
2012-03-26 00:39 "Yaakov (Cygwin/X)" : | On 2012-03-25 06:24, Jari Aalto wrote: | | > New upstream release: | > | > wget --recursive --no-host-directories --cut-dirs=3 \ | > http://cante.net/~jaalto/tmp/cygwin/wcd/setup.hint \ | > http://cante.net/~jaalto/tmp/cygwin/wcd/wcd-5.2.1-1-src.tar.bz2 \ | > http://cante.net/~jaalto/tmp/cygwin/wcd/wcd-5.2.1-1.tar.bz2 | | Uploaded. Can any previous versions be removed? Yes, Jari
Re: Mingw64 and Cygwin: header and libs layout
2012/3/25 Corinna Vinschen: > And why should this be done? It doesn't look as if Microsoft will ever > generate autoconf'ed, target-specific headers in different directories > and Mingw64 strives to create platform headers in as most compatible as > possible. Kai, what do you say Well, for the platform headers - and this is all we are talking about here AFAIU - it isn't to be expected that there are differences between native-windows gcc version or Cygwin-gcc version, which can't be covered by simple type-abstraction. In general the psdk in cygwin is required for linking, and in some situation also for building. And of course it is obvious that C-runtime parts of headers and lib have not to be installed in shared location. This doesn't make any sense to mix them. > And then, if we stick to the assumption that the platform headers will > be target dependent at one point, How would you like to solve that for > the Cygwin gcc? Introducing /usr/include/w64api? As dir or as symlink? Platform headers (at least that one for Windows) aren't target dependent in general. I think it would be even more a major flaw, if we would introduce such a difference. >> >> headers for w32api aren't huge in terms of disk space (5.5M), so just >> >> having >> >> duplicates in the appropriate places wouldn't be that bad. It's what >> >> happens >> >> every time you build libwhatever for both your native system and a >> >> cross-target anyway. > In that case you *have* to make a target specific headers assumption, > otherwise you have a break in the systematics. And then, again, how do > you let the gcc compiler access the target headers? By creating two > subdirs under /usr/include, w32api and w64api? Yes, these target-specific assumptions in gcc caused in the past already enough pain for none-in-souirceware-tree targets. I really would love if we could avoid such and infrastructural assumptions valid only for one target. I see no good reason to make for 32-bit/64-bit (well, we might get in near future even ARM support in platform-headers) platform environment two different directories. It just makes it more likely that headers from one getting incompatible to the other-one. Also it makes a multilib-scenario (if ever desired for Cygwin) much harder. That import-libaries (plus additional objects in imports) of platform-sdk have to be placed in different lib-folders (lib32/lib64) is as obvious as the built of the platform-libraries are requiring an native windows-compiler. The platform-headers (without the DDK and the direct-x specific extensions) are about 10 MB, nevertheless I agree that in modern times of huge HDD-capacities a double installation of them isn't that worse as it was in the past. > Corinna Regards, Kai
Re: [SECURITY] gnutls
> Yaakov writes: > A security vulnerability has just been announced for gnutls (CVE-2012-1573). > This can be fixed by updating to 2.12.18. Yaakov can you update your p11-kit package. I could use it in a new gnutls build. checking for P11_KIT... configure: error: Package requirements (p11-kit-1 >= 0.11) were not met: Requested 'p11-kit-1 >= 0.11' but version of p11-kit is 0.9 Ciao Volker
