Web lists-archives.com

Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.2

On 2019-01-30 13:29, Corinna Vinschen wrote:
> On Jan 30 20:01, Corinna Vinschen wrote:
>> On Jan 30 19:53, Corinna Vinschen wrote:
>>> On Jan 30 11:47, Brian Inglis wrote:
>>>> On 2019-01-30 10:31, Corinna Vinschen wrote:
>>>>> On Jan 30 09:11, Brian Inglis wrote:
>>>>>> On 2019-01-30 07:03, Corinna Vinschen wrote:
>>>>>>> I uploaded a new Cygwin test release 3.0.0-0.2
>>>>>>> It also changes the output of uname(2) for newly built applications.
>>>>>>> Applications built so far (that includes uname(1) from coreutils)
>>>>>>> will still print the old uname output.  The new format allows for longer
>>>>>>> strings.  Compare:
>>>>>>> Upcoming new uname content:
>>>>>>>   sysname:  CYGWIN_NT-10.0-17763   or  CYGWIN_NT-10.0-17763-WOW64
>>>>>>>   release:  3.0.0-335.x86_64       or  3.0.0-335.x86_64.snap
>>>>>>>   version:  2019-01-29 19:23 UTC   Build time in UTC
>>>>>> Re: "(*) It would really be nice not having to ask for these
>>>>>> infos every time." may want to append
>>>>>> HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/UBR to uname
>>>>>> -s sysname to show the patch levels of installed builds, as
>>>>>> there appears to be substantial differences between editions
>>>>>> and service models.
>>>> [...]
>>>> $ cmd /c ver
>>>> Microsoft Windows [Version 10.0.17134.523]
>>>> and save asking those who don't know that, in case the revision
>>>> makes a difference.  Insider build feature sets bump the builds,
>>>> and patch sets bump those revisions; up to base releases with
>>>> known feature sets, builds, and revisions; then patch Tuesdays
>>>> bump those revisions higher; so you can tell if installs are
>>>> Insider, base, or patched.
>>> I'm not so sure this makes sense from a Cygwin perspective.  We're
>>> interested in the major releases introducing changing and/or new
>>> functionality.  The monthly updates don't do that so they have no
>>> meaning to us.
>>> I just wonder if we should replace the build number with the ReleaseId
>>> (i.e. 17763 vs. 1809), but that excludes the fast lane updates from
>>> being visible.
>> On second thought there's also the format discrepancy.  Right now the
>> new uname crates the version string like "10.0-17763", but it might be
>> better to use "10.0.17763", replacing the dash with a dot, to follow
>> more closely the OS layout.  On third thought it seems prudent to
>> print either
>>   10.0-1809{-WOW64}
>> or
>>   10.0.17763.253{-WOW64}
>> Hmm.  The second form appears to make the most sense, actually.
> But then again, no OS before W10 printed that info, e.g.:
>   Microsoft Windows [Version 6.3.9600]
> We also have to make sure we're not breaking scripts, especially
> autoconf etc., so on forth thought, I'll rather stick to the current
> format.

I have zero problems with your previous considerations and decisions, but as
some new features now also require WSL installed to work, should there be some
such indication from uname e.g. +WSL where -WOW would appear?

Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple