RE: 4.3.0 Cygwin 1.3.x build and packaging nearly done
David Fraser wrote: Harold L Hunt II wrote: So, my question for the community is whether anyone wants me to post the 4.3.0 release as the new stable release and make another build for Cygwin 1.5.1 and post that as the test release. Or, would everyone rather that I wait and just make the 1.5.1 version the new stable release when 1.5.1 is done? I kind of like the idea of making a 4.3.0 Cygwin 1.3.x release, since that will allow us to identify which new bugs (and there will always be new bugs) are caused by XFree86 4.3.0 and which are caused by Cygwin 1.5.1. Well, what do you all think? Harold I think it would be great to have the 4.3.0 on Cygwin 1.3.x, the sooner the better! Agreed. J. === Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other commitment through the use of this email. Experian Limited (registration number 653331). Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
RE: [XFree86-4.2.0] Now that we have an improved ld, please makelibXt a shared library.
On Fri, 1 Aug 2003, Ralf Habacker wrote: _XInherit: jmp (*xyz) where xyz is the address of the image allocation table, in which the address of the real function address is stored. So using *(long *)((long)_XInherit+2) in a client dll for comparing gives the real function address. _XtInherit is now used in initialisation of static structures. So any substitute must not contain terms which value is only known at runtime. This includes return values of function and memory access (which includes variables and your example). bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: 4.3.0 Cygwin 1.3.x build and packaging nearly done
I haven't got time to make a formal release announcement, but I just
uploaded all of the 4.3.0 packages. They should start showing up on
mirrors within a few hours.
Note that all fonts packages {fcyr, fenc, fnts, fscl, f100} have not had
their version numbers changed. You will not automatically receive the
new fonts if you already have them installed. If you have trouble with
the fonts, please try the reinstall option for the font packages in
Cygwin's setup.exe.
I ask that the first few testers report their results to the mailing
list as soon as they can. I am sure I made a mistake somewhere.
Note: This release depends on Cygwin 1.3.x and is a preparation release
for Cygwin 1.5.1.
Harold
Updated on sourceware: XFree86-[base,bin,doc,etc,fsrv,html,jdoc,lib,man,nest,prog,prt,ps,vfb,xserv,xwinclip]-4.3.0-1
The XFree86-[base,bin,doc,etc,fsrv,html,jdoc,lib,man,nest,prog,prt,ps,vfb,xserv,xwinclip]-4.3.0-1 packages have been updated in the Cygwin distribution. There were no Cygwin-specific changes in this release. This is a release to synchronize with the XFree86 4.3.0.1 release. A note about fonts: The font packages *have* been updated to the 4.3.0.1 fonts, however, the font package versions have not been changed. Leaving the font package versions unchanged means that users with 4.2.0 fonts already installed will not have to download the new fonts, which are very large, while new installations will get the new fonts. Anyone is free to reinstall the fonts packages, which will cause the newer packages (with the same version number, mind you) to be downloaded and installed. The 4.2.0 fonts are compatible with the 4.3.0.1 XFree86 release; only in extremely limited situations would someone absolutely need the 4.3.0.1 fonts. Those people know who they are and are on their own for identifying themselves. I have no further information about what scenarios, if any, would require the 4.3.0.1 fonts to be installed. I have downloaded and tested the packages. Everything seemed to work fine. No need to report your results to the list unless you run into trouble. -- Harold Hunt 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. Save it and run setup, answer the questions and pick up 'XFree86-xserv' from the 'XFree86' category. You may need to click the Full button if it doesn't show up. Note that downloads from sources.redhat.com (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update. In the US, ftp://archive.progeny.com/cygwin/ is a reliable high bandwidth connection. In Japan, ftp://ftp.u-aizu.ac.jp/pub/gnu/gnu-win32/ is usually up-to-date. In DK, http://mirrors.sunsite.dk/cygwin/ is usually up-to-date. If one of the above doesn't have the latest version of this package you can either wait for the site to be updated or find another mirror. Please send questions or comments to the Cygwin/XFree86 mailing list at: [EMAIL PROTECTED] . If you want to subscribe go to: http://cygwin.com/lists.html I would appreciate if you would use this mailing list rather than emailing me directly. This includes ideas and comments about the setup utility or Cygwin/XFree86 in general. If you want to make a point or ask a question the Cygwin/XFree86 mailing list is the appropriate place.
Setup bug --- probably already reported and fixed, of course
http://www.msu.edu/~huntharo/xwin/cygwin-setup-161pct.png I just uploaded XFree86 4.3.0 packages this morning. Some of the mirrors have gotten the updated setup.ini and packages already, while others have not. In setup I have selected three mirrors: archive.progeny.com mirrors.rcn.net planetmirror.com The problem is that at least one of these mirrors has the updated setup.ini file, as the 4.3.0-1 XFree86 packages are listed and selected for installation. However, when setup downloads the packages it is not associating the actual file it is retrieving with the setup.ini from that site, thus it thinks that it is retrieving a 3293k XFree86-bin-4.3.0-1.tar.bz2 file while it is actually retrieving a roughly 13 MB file. When setup reaches the size of the file that it thinks it is downloading, the % complete continues to grow above 100% (see link for screenshot at the top of the email). When the file is finished, setup reports that the download was incomplete and asks if I would like to try again. I am sure that this has already been reported, yelled about, and fixed or refused. So, let me point out that I have absolutely no stock in whether this ever gets fixed, I am not asking anyone to fix it, I am simply reporting it so that such weirdness is fresh on the minds of people downloading the new XFree86 packages. Of course, this could be due to some entirely unrelated problem, probably caused by me, in which case we can all ignore that I ever said anything. I will notify the lists in such an event ;) Harold
Re: Setup bug --- probably already reported and fixed, of course
FYI --- In further testing, archive.progeny.com is the mirror that has not been updated yet. Selecting only archive.progeny.com gives me the warning about setup.ini being older than when I last installed Cygwin. Selecting only mirrors.rcn.net does not give such a warning and correctly indicates that the XFree86-bin tarball is roughly 10500 KiB and downloads it and all other tarballs with no problems. Thus, this does not so far appear to be entirely my fault. Harold
Re: XFree86-bin,etc 4.3.0-1 broken?
Specify one mirror only when downloading. Notice that some mirrors do not have 4.3.0-1 yet, so mixing updated mirrors and out of date mirrors causes problems. See this message I wrote describing the problem: http://cygwin.com/ml/cygwin-xfree/2003-08/msg8.html Harold Andrew Grimm wrote: Did my usual morning ritual of downloading everything new, and got the Download Incomplete - Try Again? error. This only occurred downloading the packages listed in the subject. Tried on four mirrors, same error everywhere. Are the packages perhaps broken? Sorry if this is just a case of magically managing to hose myself by downloading a package while its getting updated on the mirror or something like that. -Andy
Re: XWin -multiwindows problem
Harold, Thanks - I get the same log output using 16 and 8 bit. I don't have other choices with the driver I'm using. Both systems have ATI graphics cards of type Rage 128. The working system has a specific monitor (Hitachi 751), while the non-working one is using Plug-and-Pray with a NEC 77F. If you think it's worthwhile I can play with the 98 configuration. Terry --- Harold wrote: Try changing the display depth on the problem machine from 32 bits to 24, 16, or 15 bits. In fact, try each one of those depths if the first one you try doesn't work. Report your results to the mailing list please. Harold terry wrote: I have successfully setup a Win98se system with CygWin using startxwin.bat from a download a couple of weeks ago (Perhaps if it had been difficult, I would know better how to deal with this problem :) ). I am attempting to do the same on another system with almost identical hardware, also using Win98se. The significant difference between the systems is that the successful system has a 19 monitor @1600x1200 while the problem system has a 17 monitor @1024x768. I have not modified startxwin.bat, and everything works fine 'non-multiwindow'. I cannot determine how to deal with the error in the XWin log below. Many thanks for any help. terry ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1024 h 768 winInitializeDefaultScreens - Returning OsVendorInit - Creating bogus screen 0 (EE) Unable to locate/open config file InitOutput - Error reading config file winDetectSupportedEngines - Windows 95/98/Me winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 0017 InitOutput - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 winSetEngine - Multi Window = ShadowGDI winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits per pixel winCreateBoundingWindowWindowed - User w: 1024 h: 768 winCreateBoundingWindowWindowed - Current w: 1024 h: 768 winAdjustForAutoHide - Original WorkArea: 0 0 768 1024 winAdjustForAutoHide - Taskbar is auto hide winAdjustForAutoHide - Found LEFT auto-hide taskbar winAdjustForAutoHide - Adjusted WorkArea: 0 1 768 1024 winCreateBoundingWindowWindowed - WindowClient w 1023 h 768 r 1023 l 0 b 768 t 0 winCreateBoundingWindowWindowed - Returning winAllocateFBShadowGDI - Creating DIB with width: 1023 height: 768 depth: 32 winAllocateFBShadowGDI - Dibsection width: 1023 height: -768 depth: 32 size image: 3142656 winAllocateFBShadowGDI - Shadow blit failure winFinishScreenInitFB - Could not allocate framebuffer winScreenInit - winFinishScreenInit () failed Fatal server error: InitOutput - Couldn't add screen 0
Re: XWin -multiwindows problem
Terry, In this case I think you need to try to install the drivers directly from your video card manufacturer on the non-working system and see if that helps. On the other hand, if the manufacturer drivers are installed on the system that does not work while the other has the default MS drivers, then the manufacturer drivers might be the problem. Note that non-multiwindow mode on both computers will use DirectDraw, which has its own seperate driver, while multiwindow mode on both computers will use the GDI drivers. These drivers are distinct, so problems with one won't necessarily cause problems with the other. Oddly enough, upgrading to DX 9.x might install some fresh drivers that could fix your problem. Give those things a try and let us know what happens. Harold terry wrote: Harold, Thanks - I get the same log output using 16 and 8 bit. I don't have other choices with the driver I'm using. Both systems have ATI graphics cards of type Rage 128. The working system has a specific monitor (Hitachi 751), while the non-working one is using Plug-and-Pray with a NEC 77F. If you think it's worthwhile I can play with the 98 configuration. Terry --- Harold wrote: Try changing the display depth on the problem machine from 32 bits to 24, 16, or 15 bits. In fact, try each one of those depths if the first one you try doesn't work. Report your results to the mailing list please. Harold terry wrote: I have successfully setup a Win98se system with CygWin using startxwin.bat from a download a couple of weeks ago (Perhaps if it had been difficult, I would know better how to deal with this problem :) ). I am attempting to do the same on another system with almost identical hardware, also using Win98se. The significant difference between the systems is that the successful system has a 19 monitor @1600x1200 while the problem system has a 17 monitor @1024x768. I have not modified startxwin.bat, and everything works fine 'non-multiwindow'. I cannot determine how to deal with the error in the XWin log below. Many thanks for any help. terry ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1024 h 768 winInitializeDefaultScreens - Returning OsVendorInit - Creating bogus screen 0 (EE) Unable to locate/open config file InitOutput - Error reading config file winDetectSupportedEngines - Windows 95/98/Me winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 0017 InitOutput - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 winSetEngine - Multi Window = ShadowGDI winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits per pixel winCreateBoundingWindowWindowed - User w: 1024 h: 768 winCreateBoundingWindowWindowed - Current w: 1024 h: 768 winAdjustForAutoHide - Original WorkArea: 0 0 768 1024 winAdjustForAutoHide - Taskbar is auto hide winAdjustForAutoHide - Found LEFT auto-hide taskbar winAdjustForAutoHide - Adjusted WorkArea: 0 1 768 1024 winCreateBoundingWindowWindowed - WindowClient w 1023 h 768 r 1023 l 0 b 768 t 0 winCreateBoundingWindowWindowed - Returning winAllocateFBShadowGDI - Creating DIB with width: 1023 height: 768 depth: 32 winAllocateFBShadowGDI - Dibsection width: 1023 height: -768 depth: 32 size image: 3142656 winAllocateFBShadowGDI - Shadow blit failure winFinishScreenInitFB - Could not allocate framebuffer winScreenInit - winFinishScreenInit () failed Fatal server error: InitOutput - Couldn't add screen 0
Re: Updated on sourceware:XFree86-[base,bin,doc,etc,fsrv,html,jdoc,lib,man,nest,prog,prt,ps,vfb,xserv,xwinclip]-4.3.0-1
Harold L Hunt II wrote: There were no Cygwin-specific changes in this release. This is a release to synchronize with the XFree86 4.3.0.1 release. Some comments on bugs which are now fixed: - xkbcomp can now be used on textmode mounts. Xwin loads the keymap as binary files too. - some syntax errors in xkb layout definitions are now fixed (esp. in us_intl) The us_intl layout which includes the alt-gr mappings is _not_ included in the release. I hope to have it sent to xfree.org until 4.4 is out. bye ago NP: Deine Lakaien - Generators -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: XFree86-bin,etc 4.3.0-1 broken?
Specify one mirror only when downloading. Notice that some mirrors do not have 4.3.0-1 yet, so mixing updated mirrors and out of date mirrors causes problems. See this message I wrote describing the problem: http://cygwin.com/ml/cygwin-xfree/2003-08/msg8.html Harold *sheepish look* Sorry, I should have investigated better before sending the question in. I was able to download 4.3.0-1 from the other site you mentioned without any problems. Unfortunately in the end I had to reinstall 4.2.0 because WindowMaker is rather freaked out by 4.3.0, which I suppose is to be expected until (if?) it gets updated for the new X release. Thanks, Andy
Re: XFree86-bin,etc 4.3.0-1 broken?
Andrew, You aren't a -multiwindow guy yet? Harold Andrew Grimm wrote: Specify one mirror only when downloading. Notice that some mirrors do not have 4.3.0-1 yet, so mixing updated mirrors and out of date mirrors causes problems. See this message I wrote describing the problem: http://cygwin.com/ml/cygwin-xfree/2003-08/msg8.html Harold *sheepish look* Sorry, I should have investigated better before sending the question in. I was able to download 4.3.0-1 from the other site you mentioned without any problems. Unfortunately in the end I had to reinstall 4.2.0 because WindowMaker is rather freaked out by 4.3.0, which I suppose is to be expected until (if?) it gets updated for the new X release. Thanks, Andy
PATCH: Constrained sizing support in -multiwindow mode
The multiwindow manager does presently not respect the hints that apps like xterm or emacs give as to valid window sizes. This can cause xterm to have ugly leftover smudges on the right edge of the window and other minor little annoyances. The attached DIFF -U3 patch against test93 adds support to automatically validate the sizes of windows while you're sizing them, just like you find in most X11 window managers. I've tested it locally and it seems to work just fine under W2K, but I'd like to confirm that it performs properly under XP where the window decorations (which it needs to take into account) are different... -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com constrainsize.diff.bz2 Description: BZip2 compressed data
Re: XFree86 fonts from 4.2.0 to 4.3.0
Harold L Hunt II wrote: Can anyone think of any changes to the font packages between 4.2.0 and 4.3.0 that would require me to repackage and distribute 4.3.0 font sets? If not, I would really like to just leave the current 4.2.0 fonts in place since it will save most people from downloading between 15 and 50 MB of the same stuff. Of course, the version numbers will look a little funny, but I think most users would be pleased that they didn't have to download the fonts again. Of course, if anyone knows otherwise, please speak up now so I don't make a terrible mistake. I know they added a couple more TTF fonts and a few more OTF fonts (mostly non-latin glyphs tho). You might also want to check the XFree cvsweb as I'm pretty sure they made some changes to the generic bdf fonts as well. Cheers, Nicholas
Re: XFree86-bin,etc 4.3.0-1 broken?
Harold L Hunt II wrote: Andrew, You aren't a -multiwindow guy yet? I don't know about him, but some of us do prefer to have a full window manager to operate in. However, I'm sure there are many who like to have a rootless X, and thus multiwin suits them fine. It would be sorta nice, though, if the window managers could be relinked/bumped to current versions. Thanks Harold for all your hard work, we appreciate it. Cheers, Nicholas
RE: [RFC]: Breaking out fontconfig and freetype into seperate packages
From: Nicholas Wourms Subject: [RFC]: Breaking out fontconfig and freetype into seperate packages Harold, Would you be against having someone else maintain the freetype2 fontconfig packages external of XFree86 sources? There are a couple of reasons for wanting this: I'd like this to happen. I would like to (but never actually have) contribute a couple of packages that use freetype but not X.
Re: Packaging question
David, The standard XFree86 packages do things differently. We are following that standard. Harold Fries, David D wrote: Debian puts lib*.so libraries in a lib package, and lib*.a packages in a dev package. Specifically xlibs and xlibs-dev althought the xlibs-dev would have include files as well. -Original Message- From: Harold L Hunt II [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2003 11:32 AM To: cygx Subject: Packaging question We should be putting bin/*.dll in the bin package and lib/*.a in the prog package, correct? Currently we are putting both bin/*.dll and lib/*.a in bin. Putting the DLLs in bin is correct because you need the shared libraries in order to run, which is why lib/*.so are put in bin on other platforms. Putting the *.a link files in the prog package would seem correct as well, since they are only needed to compile new programs and should be grouped together with the headers in prog as on other platforms. Any comments? Harold
Re: [RFC]: Breaking out fontconfig and freetype into seperate packages
Nicholas, Can you explain to me what fontconfig and freetype2 are, specifically? Do they consist of a couple libraries and some executables? How many files are involved in a package that contains them? Are any of their libraries linked to from within the standard XFree86 distribution? The reason I ask these questions is that I am all for splitting out fontconfig and freetype2, as long as I can cleanly exclude them from the packaging scripts and if I don't have to do too much recompiling when new fontconfig/freetype2 packages are released. Answer those questions and we can think about it. Harold Nicholas Wourms wrote: Harold, Would you be against having someone else maintain the freetype2 fontconfig packages external of XFree86 sources? There are a couple of reasons for wanting this: 1)Freetype fontconfig aren't necessarily X libraries and they don't specifically require X. Some non-X packages are starting to use it, and others will follow in the future. Also, it is possible that one could link them to a hybrid w32api/cygwin gui application. 2)XFree86 is notorious for lagging behind the current releases, especially in respect to fontconfig. 3)Most all of the major linux vendors do this, and have been doing it for quite some time now. 4)It means less work and less to download each time there's an update to some other XFree86 library or binary. I've been tracking current sources and have working packaging scripts for both. If you are interested, I'd be willing to do an ITP in cygwin-apps, having them target the /usr prefix as opposed to /usr/X11R6. Also, I'd like to do an ITP for ttmkfdir, but I'll hold off on that until we get this request squared away. Cheers, Nicholas
'Wrong' dll names in 4.3.0-1 packages - breaks all 3rd party X apps
In the 4.3.0-1 packages all dll's are named cygxxx-n.dll instead of libxxx.dll. All 3rd party apps look for e.g. libX11.dll, libICE.dll etc. For now the only workaround is to copy each cygxxx-n.dll to the corresponding libxxx.dll in /usr/X11R6/bin. Harold, could you please issue a 4.3.0-2 version with the 'right' dll names? Ton van Overbeek
Re: 'Wrong' dll names in 4.3.0-1 packages - breaks all 3rd party X apps
On Sat, Aug 02, 2003 at 03:58:46AM +0200, Ton van Overbeek wrote: In the 4.3.0-1 packages all dll's are named cygxxx-n.dll instead of libxxx.dll. All 3rd party apps look for e.g. libX11.dll, libICE.dll etc. That's interesting. What third party apps would be specifically linking to cygwin-xfree DLLs? cgf
Re: 'Wrong' dll names in 4.3.0-1 packages - breaks all 3rd partyX apps
Ton van Overbeek wrote: In the 4.3.0-1 packages all dll's are named cygxxx-n.dll instead of libxxx.dll. All 3rd party apps look for e.g. libX11.dll, libICE.dll etc. For now the only workaround is to copy each cygxxx-n.dll to the corresponding libxxx.dll in /usr/X11R6/bin. Harold, could you please issue a 4.3.0-2 version with the 'right' dll names? Ton van Overbeek Ton, No. Older X apps will need to be recompiled for 4.3.0. This is a change that needed to happen. In the meantime, you can keep the old DLLs in the same directory and it will allow older X apps to run side by side with new X apps. This is a painful change, but it needs to happen. Harold
Re: 'Wrong' dll names in 4.3.0-1 packages - breaks all 3rd partyX apps
On Sat, Aug 02, 2003 at 04:24:30AM +0200, Ton van Overbeek wrote: Christopher Faylor wrote: That's interesting. What third party apps would be specifically linking to cygwin-xfree DLLs? Examples: gs.exe (ghostscript), xdvi.exe (from TeTeX), fvwm etc. Ok. I think your use of the term third party is incorrect in this case, then. Harold Hunt wrote: No. Older X apps will need to be recompiled for 4.3.0. This is a change that needed to happen. In the meantime, you can keep the old DLLs in the same directory and it will allow older X apps to run side by side with new X apps. Understood. But when you upgrade via setup.exe the old dll's are removed. Maybe we need a separate lib package with the 4.2 libraries for the old apps. There is no way to get both the old and new dll's installed simultaneously using setup.exe. Hmm. If these packages are built against cygwin-1.5.1, they should be marked as test packages. It doesn't look like they are. Am I missing something, Harold? -- Please use the resources at cygwin.com rather than sending personal email. Special for spam email harvesters: send email to [EMAIL PROTECTED] and be permanently blocked from mailing lists at sources.redhat.com
Re: 'Wrong' dll names in 4.3.0-1 packages - breaks all 3rd partyXapps
Christopher Faylor wrote: Hmm. If these packages are built against cygwin-1.5.1, they should be marked as test packages. It doesn't look like they are. Am I missing something, Harold? -- Yes, I changed the plan to make a 1.3.x release of XFree86 4.3.0 before the 1.5.1 release. The idea here is to help is differentiate between 1.5.1 bugs and 4.3.0 bugs. The whole point of applications needing to be recompiled is going to be moot as soon as Cygwin 1.5.1 is released, since they will all have to be recompiled anyway. Harold
Re: PATCH: Constrained sizing support in -multiwindow mode
Earle, This is great! Just yesterday, while investigating the crashing upon copying a large amount of text, I was resizing xterm to make it really large and noticed that the window quite often got a size that chopped off the last line of text or left a gap after the last line of text. I wondered if it had something to do with hints... sure enough, it did :) Thanks for the patch, Harold Earle F. Philhower, III wrote: The multiwindow manager does presently not respect the hints that apps like xterm or emacs give as to valid window sizes. This can cause xterm to have ugly leftover smudges on the right edge of the window and other minor little annoyances. The attached DIFF -U3 patch against test93 adds support to automatically validate the sizes of windows while you're sizing them, just like you find in most X11 window managers. I've tested it locally and it seems to work just fine under W2K, but I'd like to confirm that it performs properly under XP where the window decorations (which it needs to take into account) are different...
Updated on sourceware: XFree86-xserv-4.3.0-2
The XFree86-xserv-4.3.0-2 package has been updated in the Cygwin distribution. Changes: 1) winmultiwindowwm.c, winmultiwindowclass.h, winmultiwindowwndproc.c - Automatically validate the sizes of windows while you're sizing them, just like you find in most X11 window managers.. (Earle F. Philhower III) -- Harold Hunt 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. Save it and run setup, answer the questions and pick up 'XFree86-xserv' from the 'XFree86' category. You may need to click the Full button if it doesn't show up. Note that downloads from sources.redhat.com (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update. In the US, ftp://archive.progeny.com/cygwin/ is a reliable high bandwidth connection. In Japan, ftp://ftp.u-aizu.ac.jp/pub/gnu/gnu-win32/ is usually up-to-date. In DK, http://mirrors.sunsite.dk/cygwin/ is usually up-to-date. If one of the above doesn't have the latest version of this package you can either wait for the site to be updated or find another mirror. Please send questions or comments to the Cygwin/XFree86 mailing list at: [EMAIL PROTECTED] . If you want to subscribe go to: http://cygwin.com/lists.html I would appreciate if you would use this mailing list rather than emailing me directly. This includes ideas and comments about the setup utility or Cygwin/XFree86 in general. If you want to make a point or ask a question the Cygwin/XFree86 mailing list is the appropriate place.
Re: Setup bug --- probably already reported and fixed, of course
Harold L Hunt II wrote: http://www.msu.edu/~huntharo/xwin/cygwin-setup-161pct.png I just uploaded XFree86 4.3.0 packages this morning. Some of the mirrors have gotten the updated setup.ini and packages already, while others have not. In setup I have selected three mirrors: archive.progeny.com mirrors.rcn.net planetmirror.com The problem is that at least one of these mirrors has the updated setup.ini file, as the 4.3.0-1 XFree86 packages are listed and selected for installation. However, when setup downloads the packages it is not associating the actual file it is retrieving with the setup.ini from that site, thus it thinks that it is retrieving a 3293k XFree86-bin-4.3.0-1.tar.bz2 file while it is actually retrieving a roughly 13 MB file. When setup reaches the size of the file that it thinks it is downloading, the % complete continues to grow above 100% (see link for screenshot at the top of the email). When the file is finished, setup reports that the download was incomplete and asks if I would like to try again. I am sure that this has already been reported, yelled about, and fixed or refused. So, let me point out that I have absolutely no stock in whether this ever gets fixed, I am not asking anyone to fix it, I am simply reporting it so that such weirdness is fresh on the minds of people downloading the new XFree86 packages. Of course, this could be due to some entirely unrelated problem, probably caused by me, in which case we can all ignore that I ever said anything. I will notify the lists in such an event ;) Boy that Harold is quite a b*stard. He comes through here, complaining about this and that. Who needs him! Oh... is this on the list??? Eh-hem. Ah, let me rephrase. ;-) Thanks Harold for this report. Actually, I think this has been reported before somewhat recently but there wasn't allot of information about the cause. So I think the link you've suggested between the packages and the setup.ini files is quite useful. I'm redirecting this discussion to cygwin-apps, since it's the list which discusses setup issues. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746
Re: Setup bug --- probably already reported and fixed, of course
Robert Collins wrote: On Sat, 2003-08-02 at 01:30, Harold L Hunt II wrote: FYI --- In further testing, archive.progeny.com is the mirror that has not been updated yet. Selecting only archive.progeny.com gives me the warning about setup.ini being older than when I last installed Cygwin. Selecting only mirrors.rcn.net does not give such a warning and correctly indicates that the XFree86-bin tarball is roughly 10500 KiB and downloads it and all other tarballs with no problems. Thus, this does not so far appear to be entirely my fault. When you updated the X tarballs, did you bump the version number for the tarballs? (i.e. did they have -unique- file names compared to the existing tarballs?) Cheers, Rob Yes, I bumped the versions from, for example: XFree86-xserv-4.2.0-44.tar.bz2 to: XFree86-xserv-4.3.0-1.tar.bz2 Harold
Recent upgrade of xfree-xserv: missing DLLs
I just upgraded this morning from XFree86-xserv-4.3.0-1 to 4.3.0-2, jumped immediately into xdvi, and got a missing DLL message, specifically libice.dll. Unfortunately reverting to 4.3.0-1 did not recover things: I get the same message. I am not totally certain the two events (upgrade, message) are related: yesterday there was a massive upgrade of other parts of the XFree86 provision. Any connection? Fergus
