Updated: 1.7.0-33 (New method to logon without password ... with password)

Updated: 1.7.0-33 (New method to logon without password ... with password)

[Corinna Vinschen]

Hi,

I just uploaded a cygwin-1.7.0-33 release which contains the new feature
explained below.

For a long time we have the feature that you can use ssh or rsh or
cron without password.  But all methods which don't use a password have
a major drawback:  The user token has no credentials which allow the
usual simple network access without additional hassle.  This makes, for
instance, automated remote scripting which need network access a rather
painful experience.

Interix, OTOH, has a command called `regpwd', which allows to specify a
password for the current user, which then is stored in some hidden,
obfuscated area in the registry (HKLM\SECURITY\Policy\Secrets).  This
same area in the registry is also used by the OS to store passowrds of
accounts running Windows services.

The latest changes I applied today add this ability to Cygwin as well.
I'm only disappointed that it took me so long because the LSA functions
to access this area are documented since ages and I've read the LSA docs
a lot.  Oh well.

When a privileged process calls setuid/seteuid, Cygwin now first checks
if a password has been stored for the uid given as argument.  It checks
in two locations, the one maintained by Cygwin as well as the one
maintained by Interix.  So, if your account has already a password
stored by Interix' regpwd, you can just use it in Cygwin.  If a password
is found, it's used in a call to LogonUser.  If this call succeeds, the
token is used to switch the user context and you get all your usual
network access "for free"(*).  Otherwise Cygwin falls back to the other
methods, LSA authentication using Cygwin's LSA authentication DLL, or
using NtCreateToken as last resort.

To store a password in the registry, use the new -R/--reg-store-pwd
option to passwd(1).  Note that storing a password in the registry this
way is a privileged operation.  It's only accessible to Administrators.
When a normal user wants to store a password in the registry this way,
a workaround is necessary.  The workaround is cygserver running as
privileged service.  So, when cygserver is running, even a normal user
can enter his/her password with

  bash$ CYGWIN=server passwd -R

I also added the changes to passwd to the docs (which I uploaded to
http://cygwin.com/1.7/cygwin-ug-net.html and
http://cygwin.com/1.7/cygwin-ug-net/cygwin-ug-net.html), but there's
still a lot missing in the ntsec documentation.  Sorry about that.


Have fun,
Corinna


(*) "for free" isn't quite right, of course.  You're giving up on
    security.  The passwords are stored two-way encrypted in a registry
    area only accessible to admins and the system.  The Cygwin password
    is accessible only for local admins, not from remote as is the
    Interix password.  However, if somebody gets admin access to your
    machine, you lost.  OTOH, if somebody got admin access to your
    machine anyway, you probably have other, more pressing problems.

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Re: Updated: 1.7.0-34 (...and a plea)

[Corinna Vinschen]

Hi,

I just uploaded a cygwin-1.7.0-34 release which contains mostly bug
fixes to the IP resolver lib, signal handling and handling of special
characters in registry paths, the latter actually a missing forward 
port of a functionality already available in 1.5.25.

Additionally this release contains a change to the opendir/readdir
family of functions.  Thanks to Christian Franke it now supports the
d_type field in struct dirent returned by readdir.  Supported are
all values known from Linux, but actually used are just DT_DIR, DT_FILE,
and DT_UNKNOWN right now.  Any other flag would probably slow down
the readdir code unnecessarily.

As it is now, find and ls built with d_type support will be already much
faster scanning directories recursively.

Good news on the documentation side.  I finally finished the ntsec
documentation for 1.7.  See

  http://cygwin.com/1.7/cygwin-ug-net.html and
  http://cygwin.com/1.7/cygwin-ug-net/cygwin-ug-net.html

On the not so bright side, I'm a bit disappointed that only few
maintainers are actually rebuilding their applications for 1.7.  All
applications will probably profit at least from the now long pathnames
up to 32K.  And many network related applications will profit from IPv6
support and the new getaddrinfo family of functions.

With the http://cygwin.com/setup-1.7.exe tool you can easily install two
different Cygwin trees on the same machine for quite some time now.
They don't interact with each other neither in a good nor in a bad way.
You can even run them in parallel in two different console windows
without any bad interaction.  Isn't that a good reason to start porting
to 1.7?

Btw., does anything speak against opening Cygwin up for public testing
on the Cygwin main list?


Have fun,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Re: Updated: 1.7.0-34 (...and a plea)

[Chris Sutcliffe]

> On the not so bright side, I'm a bit disappointed that only few
> maintainers are actually rebuilding their applications for 1.7.  All
> applications will probably profit at least from the now long pathnames
> up to 32K.  And many network related applications will profit from IPv6
> support and the new getaddrinfo family of functions.

For the packages I maintain (w32api, mingw-runtime, hexedit, astyle) I
didn't think there would be much of an impact between 1.5 and 1.7.  If
there is some benefit, please let me know and I will build 1.7
versions of these packages.  Is there a naming convention or something
I should use, since I assume using the same name / version as the 1.5
binaries may cause a problem?

Chris

-- 
Chris Sutcliffe
http://emergedesktop.org

Re: Updated: 1.7.0-34 (...and a plea)

[Corinna Vinschen]

On Dec  5 08:05, Chris Sutcliffe wrote:
> > On the not so bright side, I'm a bit disappointed that only few
> > maintainers are actually rebuilding their applications for 1.7.  All
> > applications will probably profit at least from the now long pathnames
> > up to 32K.  And many network related applications will profit from IPv6
> > support and the new getaddrinfo family of functions.
> 
> For the packages I maintain (w32api, mingw-runtime, hexedit, astyle) I
> didn't think there would be much of an impact between 1.5 and 1.7.  If
> there is some benefit, please let me know and I will build 1.7

w32api and mingw-runtime won't be affected since they don't rely on
Cygwin.  Also packages only containing shell or perl or python scripts
won't be affected, usually, nor are packages only containing MingW
binaries.

For all packages containing Cygwin binaries, first check if they
use filename buffers and rely on PATH_MAX.  If so -> rebuild.

Do they use socket functionality and do they use either getaddrinfo/
getnameinfo, or would they even use IPv6 if available?  If so -> rebuild.

If none of the above, see in the list of new 1.7 features below and
check if your apps would profit from any of that if rebuild.  If so,
it would be nice to rebuild, though not exactly necessary.

> versions of these packages.  Is there a naming convention or something
> I should use, since I assume using the same name / version as the 1.5
> binaries may cause a problem?

There's no new naming convention.  For the time being (that is, as long
as the 1.5 distro is still the current release), the 1.7 packages should
have different, possible bigger subversion numbers than their 1.5
counterparts, like this:

  1.5 release:   foo-3.5.8-33
  1.7 release:   foo-3.5.8-34

Next update:

  1.5 release:   foo-3.5.8-35
  1.7 release:   foo-3.5.8-36

Ther will be a time hopefully in the next few months, where we will
release 1.7 and you can happily stop supporting 1.5 at all.  It will
be on a pure voluntary basis for the maintainers.

Ok, see the list of changes in 1.7 below.  For any questions, please
have a look in the new docs at 

  http://cygwin.com/1.7/cygwin-ug-net.html and
  http://cygwin.com/1.7/cygwin-ug-net/cygwin-ug-net.html

If the docs don't answer the question, it's too special and will be
answered on the mailing list, or the new documentation is lacking and
needs more text.  Please be aware that we don't have a new FAQ yet.  It
will probably also need some major revamp, but to date it's not quite
clear what *will* be frequently asked questions related to 1.7 :}


Corinna


=== LIST OF CHANGES IN 1.7: ===

OS releated changes:
--------------------

- Windows 95, 98 and Me are not supported anymore.  The new DLL will
  not run on any of these systems.

File Access related changes:
----------------------------

- Mount points are no longer stored in the registry.  Use /etc/fstab
  and /etc/fstab.d/$USER instead.  Mount points created with mount(1)
  are only local to the current session and disappear when the last
  Cygwin process in the session exits.

- PATH_MAX is now 4096.  Internally, path names can be as long as the
  underlying OS can handle (32K).
  
- UTF-8 filenames are supported now.  So far, this requires to set
  the environment variable CYGWIN to contain "codepage:utf8". but this
  will likely disappear at one point.  The setting of $LANG or $LC_CTYPE
  will be used instead.

- struct dirent now supports d_type, filled out with DT_REG or DT_DIR.
  All other file types return as DT_UNKNOWN for performance reasons.

- The CYGWIN environment variable options "ntsec" and "smbntsec" have
  been replaced by the per-mount option "acl"/"noacl".

- The CYGWIN environment variable option "ntea" has been removed without
  substitute.

- The CYGWIN environment variable option "check_case" has been removed
  in favor of real case-sensitivity on file systems supporting it.

- Creating filenames with special DOS characters '"', '*', ':', '<',
  '>', '|' is supported.

- Creating files with special DOS device filename components ("aux",
  "nul", "prn") is supported.

- File name are case sensitive if the OS and the underlying file system
  supports it.  Works on NTFS and NFS.  Does not work on FAT and Samba
  shares.  Requires to change a registry key (see the user's guide).
  Can be switched off on a per-mount base.

- Due to the above changes, managed mounts have been removed. 

- unlink(2) and rmdir(2) try very hard to remove files/directories even
  if they are currently accessed or locked.  This is done by utilizing
  the hidden recycle bin directories and marking the files for deletion.

- rename(2) rewritten to be more POSIX conformant.

- Add st_birthtim member to struct stat.

- File locking is now advisory, not mandatory anymore.  The fcntl(2) and
  the new lockf(2) APIs create and maintain locks with POSIX semantics,
  the flock(2) API creates and maintains locks with BSD semantics.
  POSIX and BSD locks are independent of each other.

- Implement atomic O_APPEND mode.

- Handle NTFS native symlinks available since Vista/2008 as symlinks
  (but don't create Vista/2008 symlinks due to unfortunate OS restrictions).

- Recognize NFS shares and handle them using native mechanisms.
  Recognize and create real symlinks on NFS shares.  Get correct
  stat(2) information and set real mode bits on open(2), mkdir(2)
  and chmod(2).

- Recognize Netapp DataOnTap drives and fix inode number handling.

- Recognize Samba version beginning with Samba 3.0.28a using the new
  extended version information negotiated with the Samba developers.

- List servers of all accessible domains and workgroups in // instead of
  just the servers in the own domain/workgroup.

- Support Linux-like extended attributes ([fl]getxattr, [fl]listxattr,
  [fl]setxattr, [fl]removexattr).

- New file conversion API for conversion from Win32 to POSIX path and
  vice versa (cygwin_conv_path, cygwin_create_path, cygwin_conv_path_list).

- New openat family of functions: openat, faccessat, fchmodat, fchownat,
  fstatat, futimesat, linkat, mkdirat, mkfifoat, mknodat, readlinkat, renameat,
  symlinkat, unlinkat.

- Other new APIs: posix_fadvise, posix_fallocate, funopen, fopencookie,
  open_memstream, fmemopen, fdopendir.

Network related changes:
------------------------

- New implementation for blocking sockets and select on sockets which
  is supposed to allow POSIX-compatible sharing of sockets between
  threads and processes.

- send/sendto/sendmsg now send data in 64K chunks to circumvent an
  internal buffer problem in WinSock (KB 201213).

- IPv6 support.  New API getaddrinfo, getnameinfo, freeaddrinfo,
  gai_strerror, in6addr_any, in6addr_loopback.  On IPv6-less systems,
  replacement functions are available for IPv4.  On systems with IPv6
  enabled, the underlying WinSock functions are used.  While I tried
  hard to get the functionality as POSIXy as possible, keep in mind that
  a *fully* conformant implementation of getaddrinfo and other stuff is
  only available starting with Windows Vista/2008.

- Resolver functions (res_init, res_query, res_search, res_querydomain,
  res_mkquery, res_send, dn_comp, dn_expand) are now part of Cygwin.
  Applications don't have to link against minires anymore.  Actually,
  this *is* the former libminires.a.

- rcmd is now implemented inside of Cygwin, instead of calling the
  WinSock function.  This allows rsh(1) usage on Vista/2008, which
  dropped this function from WinSock.

- Define multicast structures in netinet/in.h.  Note that fully
  conformant multicast support is only available beginning with Vista/2008.

- Improve get_ifconf.  Redefine struct ifreq and subsequent datastructures
  to be able to keep more information.  Support SIOCGIFINDEX, SIOCGIFDSTADDR
  and the Cygwin specific SIOCGIFFRNDLYNAM.  Support real interface flags
  on systems supporting them.

- Other new APIs: bindresvport, bindresvport_sa, iruserok_sa, rcmd_af,
  rresvport_af.  getifaddrs, freeifaddrs, if_nametoindex, if_indextoname,
  if_nameindex, if_freenameindex.

- Add /proc/net/if_inet6.

Device related changes:
-----------------------

- Reworked pipe implementation which uses overlapped IO to create
  more reliable interruptible pipes and fifos.

- Reworked pipe handling for better speed and better support for signal
  processing.

- The CYGWIN environment variable option "binmode" has been removed.

- Improved fifo handling.

- Detect when a stdin/stdout which looks like a pipe is really a tty.
  Among other things, this allows a debugged application to recognize that
  it is using the same tty as the debugger.

- Support UTF-8 in console window.

- Support up to 64 serial interfaces using /dev/ttyS0 - /dev/ttyS63.

- Support up to 128 raw disk drives /dev/sda - /dev/sddx.

- New API: posix_openpt.

Other POSIX related changes:
----------------------------

- Implement pthread_kill(thread, 0) as per POSIX.

- New API for POSIX IPC:
  Named semaphores: sem_open, sem_close, sem_unlink.
  Message queues: mq_open, mq_getattr, mq_setattr, mq_notify, mq_send,
  mq_timedsend, mq_receive, mq_timedreceive, mq_close, mq_unlink.
  Shared memory: shm_open, shm_unlink.

- Only declare expected functions in <strings.h>, don't include <string.h>
  from here.

- New APIs: asnprintf, dprintf, _Exit, vasnprintf, vdprintf, confstr,
  posix_madvise, posix_memalign, exp10, exp10f, pow10, pow10f, lrint,
  lrintf, rint, rintf, llrint, llrintf, llrintl, lrintl, rintl insque,
  remque, sys_sigabbrev, strcasestr, stpcpy, stpncpy, wcpcpy, wcpncpy,
  wcstol, wcstoll, wcstoul, wcstoull, wcsxfrm.

Security related changes:
-------------------------

- Getting a domain user's groups is hopefully more bulletproof now.

- Cygwin now comes with a real LSA authentication package.  This must
  be manually installed by a privileged user using the /bin/cyglsa-config
  script.  The advantages and disadvantages are noted in
  http://cygwin.com/ml/cygwin-developers/2006-11/msg00000.html

- Cygwin now allows to store and use user passwords in a hidden area of
  the registry.  This is tried first when Cygwin is called by privileged
  processes to switch the user context.  This allows, for instance,
  ssh public key sessions with full network credentials to access shares
  on other machines.

- The mkpasswd and mkgroup tools have changed behaviour and a couple of
  new options to ease consistent usage in multi-machine or multi-domain
  environments.

Miscellanous:
-------------

- Fallout from the long path names: If the current working directory is
  longer than 260 bytes, or if the current working directory is a virtual
  path (like /proc, /cygdrive, //server), don't call native Win32 programs
  since they don't understand these paths.

- On the first usage of a DOS path (C:\foo, \\foo\bar), the Cygwin DLL
  emits a scary warning that DOS paths shouldn't be used.  There's also
  the new CYGWIN=nodosfilewarning setting to disable that.

- Allow environment of arbitrary size instead of a maximum of 32K.

- Don't force uppercase environment when started from a non-Cygwin process.
  Except for certain Windows and POSIX variables which are always uppercased,
  preserve environment case.  Switch back to old behaviour with the new
  CYGWIN=upcaseenv setting.

- Detect and report a missing DLL on process startup.

- Add /proc/registry32 and /proc/registry64 paths to access 32 bit and
  64 bit registry on 64 bit systems.

- Align /proc/cpuinfo more closly to Linux content.

- Optimized strstr and memmem implementation.

- Remove backwards compatibility with old signal masks (some *very* old
  programs which use signal masks may no longer work correctly).

- Numerous bug fixes.

- Probably a couple of entirely new bugs.


-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Re: Updated: 1.7.0-34 (...and a plea)

[Charles Wilson]

Chris Sutcliffe wrote:

> For the packages I maintain (w32api, mingw-runtime, hexedit, astyle) I
> didn't think there would be much of an impact between 1.5 and 1.7.  If
> there is some benefit, please let me know and I will build 1.7
> versions of these packages.  Is there a naming convention or something
> I should use, since I assume using the same name / version as the 1.5
> binaries may cause a problem?

Corinna has been using a paired approach for openssh (e.g. simultaneous
releases of -5 for cygwin-1.5 and -6 for cygwin-1.7, followed by -7/-8,
etc.)

For autotools, I "jumped" to the next multiple of 10 for the new -1.7
series of releases, reserving (e.g.) -3 to -9 for any future updates to
the packages for -1.5. However, in those particular cases I do NOT
expect any additional releases for -1.5 anyway, so -3 to -9 most likely
will be forever "empty".

But yeah, using the same release number for different -1.5 and -1.7
packages is just asking for trouble.

--
Chuck

Re: Updated: 1.7.0-34 (...and a plea)

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Corinna Vinschen on 12/5/2008 4:07 AM:
> As it is now, find and ls built with d_type support will be already much
> faster scanning directories recursively.

I'm already in the process of rebuilding findutils and coreutils to pick
this up.  Unfortunately, readline/bash tab-completion don't currently use
d_type, so it doesn't reap the benefits without more effort on my part.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkk5M6QACgkQ84KuGfSFAYCtigCfVU6BvRkYCJm74lHM5xf1movN
nngAoM6FKJYqdpiGGQ5E0FjUyq/UftLq
=8DYz
-----END PGP SIGNATURE-----

Re: Updated: 1.7.0-34 (...and a plea)

[Corinna Vinschen]

On Dec  5 06:59, Eric Blake wrote:
> According to Corinna Vinschen on 12/5/2008 4:07 AM:
> > As it is now, find and ls built with d_type support will be already much
> > faster scanning directories recursively.
> 
> I'm already in the process of rebuilding findutils and coreutils to pick
> this up.  Unfortunately, readline/bash tab-completion don't currently use
> d_type, so it doesn't reap the benefits without more effort on my part.

You're one of the maintainers who very quickly offered 1.7 packages,
so you're off the hook anyway :)

Btw., thanks for doing this!  Stuff like bash, coreutils and findutils
are really crucial parts of the distro and if they support the latest
features, that's worth a lot.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Re: Updated: 1.7.0-34 (...and a plea)

[Christopher Faylor]

On Fri, Dec 05, 2008 at 12:07:33PM +0100, Corinna Vinschen wrote:
>Btw., does anything speak against opening Cygwin up for public testing
>on the Cygwin main list?

I think it is a good idea but I'd like to start tracking 1.7.x like a
normal release and increasing the x with each new release.  That will
allow us to figure out problems from source code more easily.

I don't think there is any reason for people to start rebuilding their
packages now either.  That will happen over time when 1.7.x is finally
adopted.

Do we want to start using bugzilla for tracking bugs?

cgf

Re: Updated: 1.7.0-34 (...and a plea)

[Corinna Vinschen]

On Dec  8 12:01, Christopher Faylor wrote:
> On Fri, Dec 05, 2008 at 12:07:33PM +0100, Corinna Vinschen wrote:
> >Btw., does anything speak against opening Cygwin up for public testing
> >on the Cygwin main list?
> 
> I think it is a good idea but I'd like to start tracking 1.7.x like a
> normal release and increasing the x with each new release.  That will
> allow us to figure out problems from source code more easily.

I thought we stick to 1.7.0 until we create the first actual release in
which case we bump the version to 1.7.1.  After that we bump every time
again, as in earlier releases.

> I don't think there is any reason for people to start rebuilding their
> packages now either.  That will happen over time when 1.7.x is finally
> adopted.

Btw., when 1.7 is adopted, we will have to make release-2 an independent
directory again, right?  Otherwise we will still pull in new 1.5 packages
which will have inferior features.

> Do we want to start using bugzilla for tracking bugs?

Eeek!


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Re: Updated: 1.7.0-34 (...and a plea)

[Christopher Faylor]

On Mon, Dec 08, 2008 at 06:16:15PM +0100, Corinna Vinschen wrote:
>On Dec  8 12:01, Christopher Faylor wrote:
>> On Fri, Dec 05, 2008 at 12:07:33PM +0100, Corinna Vinschen wrote:
>> >Btw., does anything speak against opening Cygwin up for public testing
>> >on the Cygwin main list?
>> 
>> I think it is a good idea but I'd like to start tracking 1.7.x like a
>> normal release and increasing the x with each new release.  That will
>> allow us to figure out problems from source code more easily.
>
>I thought we stick to 1.7.0 until we create the first actual release in
>which case we bump the version to 1.7.1.  After that we bump every time
>again, as in earlier releases.

Does it really matter?  I've never been a big fan of tracking versions
outside of CVS.  There is a rationale for tracking the version bump
since we can figure out what 1.7.1 relates to but not 1.7.0-39.  We
could CVS tag each release with a '-39' but we currently only do that
sporadically as needed.

>> I don't think there is any reason for people to start rebuilding their
>> packages now either.  That will happen over time when 1.7.x is finally
>> adopted.
>
>Btw., when 1.7 is adopted, we will have to make release-2 an independent
>directory again, right?  Otherwise we will still pull in new 1.5 packages
>which will have inferior features.

I think that when 1.7 is adopted

release-2 -> release
release -> release-deprecated

and we make setup.exe changes to accommodate that.

cgf

Re: Updated: 1.7.0-34 (...and a plea)

[Corinna Vinschen]

On Dec  8 13:00, Christopher Faylor wrote:
> On Mon, Dec 08, 2008 at 06:16:15PM +0100, Corinna Vinschen wrote:
> >On Dec  8 12:01, Christopher Faylor wrote:
> >> On Fri, Dec 05, 2008 at 12:07:33PM +0100, Corinna Vinschen wrote:
> >> >Btw., does anything speak against opening Cygwin up for public testing
> >> >on the Cygwin main list?
> >> 
> >> I think it is a good idea but I'd like to start tracking 1.7.x like a
> >> normal release and increasing the x with each new release.  That will
> >> allow us to figure out problems from source code more easily.
> >
> >I thought we stick to 1.7.0 until we create the first actual release in
> >which case we bump the version to 1.7.1.  After that we bump every time
> >again, as in earlier releases.
> 
> Does it really matter?

Not in a technical sense.  It's just the idea that the first official
release shouldn't be 1.7.24.  1.7.1 sounds much more neat :)

> >Btw., when 1.7 is adopted, we will have to make release-2 an independent
> >directory again, right?  Otherwise we will still pull in new 1.5 packages
> >which will have inferior features.
> 
> I think that when 1.7 is adopted
> 
> release-2 -> release
> release -> release-deprecated
> 
> and we make setup.exe changes to accommodate that.

I was just going to agree but ... does that work?  The idea is that
people still using an old setup will get the old release.  Since
"release" is fixed in old versions of setup, it might be more feasible
to stick to release-2 or to use something along the lines you suggested
at one point, like, say, "release-nt".


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Re: Updated: 1.7.0-34 (...and a plea)

[Christopher Faylor]

On Mon, Dec 08, 2008 at 07:16:51PM +0100, Corinna Vinschen wrote:
>On Dec  8 13:00, Christopher Faylor wrote:
>> On Mon, Dec 08, 2008 at 06:16:15PM +0100, Corinna Vinschen wrote:
>> >On Dec  8 12:01, Christopher Faylor wrote:
>> >> On Fri, Dec 05, 2008 at 12:07:33PM +0100, Corinna Vinschen wrote:
>> >> >Btw., does anything speak against opening Cygwin up for public testing
>> >> >on the Cygwin main list?
>> >> 
>> >> I think it is a good idea but I'd like to start tracking 1.7.x like a
>> >> normal release and increasing the x with each new release.  That will
>> >> allow us to figure out problems from source code more easily.
>> >
>> >I thought we stick to 1.7.0 until we create the first actual release in
>> >which case we bump the version to 1.7.1.  After that we bump every time
>> >again, as in earlier releases.
>> 
>> Does it really matter?
>
>Not in a technical sense.  It's just the idea that the first official
>release shouldn't be 1.7.24.  1.7.1 sounds much more neat :)
>
>> >Btw., when 1.7 is adopted, we will have to make release-2 an independent
>> >directory again, right?  Otherwise we will still pull in new 1.5 packages
>> >which will have inferior features.
>> 
>> I think that when 1.7 is adopted
>> 
>> release-2 -> release
>> release -> release-deprecated
>> 
>> and we make setup.exe changes to accommodate that.
>
>I was just going to agree but ... does that work?  The idea is that
>people still using an old setup will get the old release.  Since
>"release" is fixed in old versions of setup, it might be more feasible
>to stick to release-2 or to use something along the lines you suggested
>at one point, like, say, "release-nt".

Ah, right.  I wasn't thinking that people who had the old release might not
want to update.  Too bad we didn't have a mechanism in setup.exe to provide
a warning to people before updating.

So, release-2 becomes a first-class directory, setup.exe -> setup-deprecated.exe
setup-1.7 -> setup.exe?

cgf

Re: Updated: 1.7.0-34 (...and a plea)

[Corinna Vinschen]

On Dec  8 14:55, Christopher Faylor wrote:
> On Mon, Dec 08, 2008 at 07:16:51PM +0100, Corinna Vinschen wrote:
> >On Dec  8 13:00, Christopher Faylor wrote:
> >> I think that when 1.7 is adopted
> >> 
> >> release-2 -> release
> >> release -> release-deprecated
> >> 
> >> and we make setup.exe changes to accommodate that.
> >
> >I was just going to agree but ... does that work?  The idea is that
> >people still using an old setup will get the old release.  Since
> >"release" is fixed in old versions of setup, it might be more feasible
> >to stick to release-2 or to use something along the lines you suggested
> >at one point, like, say, "release-nt".
> 
> Ah, right.  I wasn't thinking that people who had the old release might not
> want to update.  Too bad we didn't have a mechanism in setup.exe to provide
> a warning to people before updating.
> 
> So, release-2 becomes a first-class directory, setup.exe -> setup-deprecated.exe
> setup-1.7 -> setup.exe?

Sounds good to me.

Apropos package rebuild.  The only package which really bugs me is the
orphaned cygwin-doc package.  I guess I will havea try in rebuilding
a new one, even though I still don't get how to create the pdf docs.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Re: Updated: 1.7.0-34 (...and a plea)

[Corinna Vinschen]

On Dec  9 11:20, Corinna Vinschen wrote:
> On Dec  8 14:55, Christopher Faylor wrote:
> > On Mon, Dec 08, 2008 at 07:16:51PM +0100, Corinna Vinschen wrote:
> > >On Dec  8 13:00, Christopher Faylor wrote:
> > >> I think that when 1.7 is adopted
> > >> 
> > >> release-2 -> release
> > >> release -> release-deprecated
> > >> 
> > >> and we make setup.exe changes to accommodate that.
> > >
> > >I was just going to agree but ... does that work?  The idea is that
> > >people still using an old setup will get the old release.  Since
> > >"release" is fixed in old versions of setup, it might be more feasible
> > >to stick to release-2 or to use something along the lines you suggested
> > >at one point, like, say, "release-nt".
> > 
> > Ah, right.  I wasn't thinking that people who had the old release might not
> > want to update.  Too bad we didn't have a mechanism in setup.exe to provide
> > a warning to people before updating.
> > 
> > So, release-2 becomes a first-class directory, setup.exe -> setup-deprecated.exe
> > setup-1.7 -> setup.exe?
> 
> Sounds good to me.

Uh, I just remembered something I forgot so far.  We don't even need two
setup.exe versions.  Setup-1.7 decides which setup ini file to use
dependent on the Windows version.  NTs get setup-2.ini, 9Xes get
setup.ini.  It even changes its layout a bit.  For instance, for 9Xes
you still get the choice of text/bin mounts, for NTs you don't.  So we
really only need a single setup.exe in future, AFAICS :)


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Re: Updated: 1.7.0-34 (...and a plea)

[Brian Dessent]

Corinna Vinschen wrote:

> Uh, I just remembered something I forgot so far.  We don't even need two
> setup.exe versions.  Setup-1.7 decides which setup ini file to use
> dependent on the Windows version.  NTs get setup-2.ini, 9Xes get
> setup.ini.  It even changes its layout a bit.  For instance, for 9Xes
> you still get the choice of text/bin mounts, for NTs you don't.  So we
> really only need a single setup.exe in future, AFAICS :)

Right, and since the 'release/' part is all in the .ini file anyway
setup.exe doesn't actually need to be changed at all to do the
switchover, it can be controlled entirely on sourceware just by telling
upset which release dir goes with which ini file.

Here's my question: Do we really need to inflict this 8.7GB of churn[1]
on every mirror just for what seems to me to be a cosmetic reason for
wanting the directory name to be "release/"?  Can't we just say that
release-2/ is now what the dir is called and move on?  In other words,
the switchover procedure would be "mv setup-1.7.exe setup.exe".

Users who continue to use an old setup.exe would still get the 1.5
distro until they redownload it, but that's okay because you need the
new setup.exe to cope with 1.7 changes anyway so that's a feature not a
bug.  Users who do redownload setup.exe will get the right one
predicated on whether they're running NT or not.

Brian

[1]:
[briand@sourceware ~/ftp]$ du -hs release release-2
5.2G    release
3.5G    release-2

Re: Updated: 1.7.0-34 (...and a plea)

[Corinna Vinschen]

On Dec  9 06:46, Brian Dessent wrote:
> Corinna Vinschen wrote:
> > Uh, I just remembered something I forgot so far.  We don't even need two
> > setup.exe versions.  Setup-1.7 decides which setup ini file to use
> > dependent on the Windows version.  NTs get setup-2.ini, 9Xes get
> > setup.ini.  It even changes its layout a bit.  For instance, for 9Xes
> > you still get the choice of text/bin mounts, for NTs you don't.  So we
> > really only need a single setup.exe in future, AFAICS :)
> 
> Right, and since the 'release/' part is all in the .ini file anyway
> setup.exe doesn't actually need to be changed at all to do the
> switchover, it can be controlled entirely on sourceware just by telling
> upset which release dir goes with which ini file.
> 
> Here's my question: Do we really need to inflict this 8.7GB of churn[1]
> on every mirror just for what seems to me to be a cosmetic reason for
> wanting the directory name to be "release/"?  Can't we just say that
> release-2/ is now what the dir is called and move on?  In other words,
> the switchover procedure would be "mv setup-1.7.exe setup.exe".

Maybe the discussion looked a bit strange but that was actually
what Chris and I already had agreed upon :)  The other point was that
release-2 needs to become an entire separated directory instead of
a unionfs, that's what Chris meant by saying to make release-2 a
first-class dir.  So it's not *only* a "mv setup-1.7.exe setup.exe".


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Re: Updated: 1.7.0-34 (...and a plea)

[Christopher Faylor]

On Tue, Dec 09, 2008 at 06:46:53AM -0800, Brian Dessent wrote:
>Corinna Vinschen wrote:
>
>> Uh, I just remembered something I forgot so far.  We don't even need two
>> setup.exe versions.  Setup-1.7 decides which setup ini file to use
>> dependent on the Windows version.  NTs get setup-2.ini, 9Xes get
>> setup.ini.  It even changes its layout a bit.  For instance, for 9Xes
>> you still get the choice of text/bin mounts, for NTs you don't.  So we
>> really only need a single setup.exe in future, AFAICS :)
>
>Right, and since the 'release/' part is all in the .ini file anyway
>setup.exe doesn't actually need to be changed at all to do the
>switchover, it can be controlled entirely on sourceware just by telling
>upset which release dir goes with which ini file.
>
>Here's my question: Do we really need to inflict this 8.7GB of churn[1]
>on every mirror just for what seems to me to be a cosmetic reason for
>wanting the directory name to be "release/"?  Can't we just say that
>release-2/ is now what the dir is called and move on?  In other words,
>the switchover procedure would be "mv setup-1.7.exe setup.exe".

I was thinking of the people who have been conditioned to think that
they should download from the release area if they want to get the
latest packages.  There is many years worth of expectations there and I
think it's worth a little mirror churning.

cgf