This is the mail archive of the cygwin-apps mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Cygwin 1.7 release (was Re: ??? The library or libraries will be delivered[...])

On Thu, Jun 04, 2009 at 09:06:15AM -0400, Charles Wilson wrote:
>Corinna Vinschen wrote:
>> On Jun  3 16:39, Charles Wilson wrote:
>>> "backwards incompatible" [*] changes 
>I hope it was clear that I wasn't being critical of the fact that there
>were some major changes in cygwin-1.7.  I was just trying to halt the
>"feature creep", since you (Corinna) have said that you plan to release
>cygwin-1.7 in the next 3-4 weeks, if my math is right.  There's barely
>enough time left for one 1-month stabilization period, much less two or
>three.  And, we've just had a disruptive change that's gonna need our
>remaining time-till-release to stabilize.  So...let's not add another
>major change. Modifying the BS sequence used by the cygwin terminal is
>one thing...rewriting the console handling code entirely to exactly
>follow exemplar X (be in Ubuntu's Linux Console, Red Hat's Linux
>Console, xterm, or whathaveyou) is altogether another thing.  Given THIS
>list, we'd barely be able to decide WHICH exemplar to follow in one
>month (then, because they are moving targets, we'd get to argue about
>which epoch's behavior of Red Hat Linux we should match...)  THEN, we
>could get down to the brass tacks of making those changes, and testing
>them. We don't have time between now and $RELEASEDATE to do any of that.
>That's all I'm saying.
>>> 1) dropping support for Win9x
>> Uh oh.
>>> 2) no longer launch native programs from long or virtual CWDs (before,
>>> IIRC cygwin-1.5 would 'fake' the CWD as c:/ or something)
>> This was always a bit weird.  A 'cd /proc' never actually cd'ed to
>> something, so a native Win32 process ended up in the previous cwd.
>> We discussed this on cygwin-developers.
>Ack. Again, I'm not *complaining*, just listing.
>> As for long pathnames, they weren't accessible before at all.
>> <rant>
>> And it's really not my fault 
>Never said it was.  I'm sorry I seem to have hit a nerve. That was
>certainly not my intent.
>>> 3) wide char support (and various existing changes related to LANG
>>> settings in console and other terminal sessions)
>> This turns out to be sort of a nightmare, but I'm still glad I did it.
>Me too. It's just that it's a user-visible behavior change that we (for
>various values of "we") are still trying to tweak just right. Let's not
>add too many more of those, or we'll never make $RELEASEDATE.
>> We now have full wide char support and setting $LANG/etc does really
>> something useful.  I can't imagine how painful it would have been to
>> drag this change along in small steps.
>>> 4) removal of registry usage / new mount table
>> That change only affects how mount points are stored.  The day to day
>> usage is the same, basically.
>...except that didn't you (or cgf, or whoever) remove the 'copy over my
>old registry-based mount points to /etc/fstab' code?  If so, that's
>gonna complicate the 'upgrade path' when we DO release.  Not a *big*
>deal, just one more surprising thing for our users who haven't been
>paying attention to the mailing list. ("Snnnrrrk, what? Huh? I'm awake,
>I'm awake...hey, what's this /etc/fstab thingy?")
>>> 6) [possible] switch to gcc4 as official compiler (with associated
>>> deliberate ABI breakage *without* DLL version number bumps -- see
>>> It's pretty
>>> clear this will happen *eventually*. Whether it happens
>>> before/on/soon-after the 1.7 rollout is still TBD.
>> That's still a sore point.  Dave, is there any chance we can switch
>> to gcc-4 as standard compiler for Cygwin 1.7 within the next 4 weeks?
>Well, I wasn't trying to PUSH, mind you.  There have been delays with
>the whole gcc4 thing, but I've been paying some attention to Dave's
>ongoing tribulations via the binutils and gcc lists, so I know *why*
>there have been delays...
>>> Each time we say "1.7 is a good time to..." and pull the trigger, it's
>>> another month of stabilization.  During that month somebody ELSE has a
>>> bright idea about yet another thing "1.7 would be a good time to...". 
>>> This is not good.
>> Yeah, we should stop right here.  The biggest problem left is the
>> native language support, apparently.  I'm still hoping to get
>> 1.7.1 out of the door end of this month, though.
>Good news!
>> What's left, AFAICS is
>> - The usual bugfixing.
>> - Creating the final version of setup-1.7.exe and replace
>> with it.
>> - Move the old documentation somehwere else, move the new docs to
>>   the old place. (And don't forget to remove the "1.7" subdir from
>>   the URLs in the docs).
>> - Splitting off the union FS for release-2.
>> - New versions of GCC and binutils would be nice.  I'd especially
>>   appreciate if GCC would start to create executables with the TS-aware
>>   flag by default so that the distro is sort of self-healing in terms of
>>   running on Terminal Servers.
>On that note...I've noticed some odd behaviors wrt the dynbase setting
>under Vista.  Sometimes Vista will fail to honor that flag, and I'll
>still get the dreaded "*** unable to remap" message.  While occasionally
> a reboot will fix it, sometimes not.  What's odd, tho, is that
>sometimes I can "fix" it by re-running peflagsall and *removing* the
>dynbase flag (AND rebooting). Then, adding it back (by re-re-running
>peflagsall, and rebooting again) doesn't cause it to break again (at
>least, not immediately). It'll be a week or more before the problem
>shows up again. I haven't spotted any consistent rhyme or reason.
>It's almost as if Vista just needs a kick in the pants by changing the
>last-modified time of all the DLLs.  It's all very strange.
>But...I find myself planning ahead to ALWAYS maintain a cygwin-1.5
>installation for the sole purpose of being able to run the test suites
>of autoconf, automake, and libtool, with their TONS of autotool
>invocations (because running the autotools, esp. automake, is where I
>most often see the "unable to remap" problem).  It takes DAYS of
>constant attendence to run those tests when every five or six tests the
>suite halts due to "unable to remap", during those times when Vista
>decides to start ignoring dynbase.  (Sure, I'll always need to
>eventually run the suite(s) under 1.7, but since I sometimes run the
>test suite a dozen times while iterating bugfixes -- esp. libtool --
>I'll do most of that on 1.5 and then only last endure the 1.7 pain).
>Now, this isn't to blame any of the work that's gone on in cygwin-1.7;
>the fault here seems to lie with Vista. It's just odd that cygwin-1.7
>seems so much more likely to tickle the fault. I'm hoping W7 improves
>the implementation of ASLR (e.g. unlike Vista's "sometimes I feel like
>ignoring the dynbase flag" behavior.)  But if anyone wants to continue
>THIS off-off-topic subthread, pls start YA new thread...I don't believe
>this issue is a release-blocker, or even worth expending any effort on
>at all between now and the release.
>> Am I missing something else?
>It'd be nice if the existing maintainers (if still around) of the
>following packages:
>  expect
>  popt
>  binutils

>  units
>  byacc
>  psutils
>  par
>  xinetd
>  tcltk
>could be persuaded to release updated versions that stop using /usr/man,
>/usr/info, and /usr/doc in favor of /usr/share/man, /usr/share/info, and
>/usr/share/doc.  There may be other naughty packages, but those are the
>ones I see on my system.  But this change is not strictly *necessary*,
>after all.

binutils doesn't use /usr/man, /usr/info, or /usr/doc.

But, regardless, I don't see how this "would be nice" jives with your
concern of unduly delaying the release by adding more things to do
before releasing 1.7.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]