* Updated: 1.7.0-33 (New method to logon without password ... with password) @ 2008-11-26 12:44 Corinna Vinschen 2008-12-05 11:07 ` Updated: 1.7.0-34 (...and a plea) Corinna Vinschen 0 siblings, 1 reply; 17+ messages in thread From: Corinna Vinschen @ 2008-11-26 12:44 UTC (permalink / raw) To: cygwin-developers, cygwin-apps 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Updated: 1.7.0-34 (...and a plea) 2008-11-26 12:44 Updated: 1.7.0-33 (New method to logon without password ... with password) Corinna Vinschen @ 2008-12-05 11:07 ` Corinna Vinschen 2008-12-05 13:06 ` Chris Sutcliffe ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: Corinna Vinschen @ 2008-12-05 11:07 UTC (permalink / raw) To: cygwin-apps, cygwin-developers 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Updated: 1.7.0-34 (...and a plea) 2008-12-05 11:07 ` Updated: 1.7.0-34 (...and a plea) Corinna Vinschen @ 2008-12-05 13:06 ` Chris Sutcliffe 2008-12-05 14:07 ` Corinna Vinschen 2008-12-05 17:00 ` Charles Wilson 2008-12-05 13:59 ` Eric Blake 2008-12-08 17:02 ` Christopher Faylor 2 siblings, 2 replies; 17+ messages in thread From: Chris Sutcliffe @ 2008-12-05 13:06 UTC (permalink / raw) To: cygwin-apps, cygwin-developers > 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Updated: 1.7.0-34 (...and a plea) 2008-12-05 13:06 ` Chris Sutcliffe @ 2008-12-05 14:07 ` Corinna Vinschen 2008-12-05 17:00 ` Charles Wilson 1 sibling, 0 replies; 17+ messages in thread From: Corinna Vinschen @ 2008-12-05 14:07 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Updated: 1.7.0-34 (...and a plea) 2008-12-05 13:06 ` Chris Sutcliffe 2008-12-05 14:07 ` Corinna Vinschen @ 2008-12-05 17:00 ` Charles Wilson 1 sibling, 0 replies; 17+ messages in thread From: Charles Wilson @ 2008-12-05 17:00 UTC (permalink / raw) To: CygWin-Apps 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Updated: 1.7.0-34 (...and a plea) 2008-12-05 11:07 ` Updated: 1.7.0-34 (...and a plea) Corinna Vinschen 2008-12-05 13:06 ` Chris Sutcliffe @ 2008-12-05 13:59 ` Eric Blake 2008-12-05 14:09 ` Corinna Vinschen 2008-12-08 17:02 ` Christopher Faylor 2 siblings, 1 reply; 17+ messages in thread From: Eric Blake @ 2008-12-05 13:59 UTC (permalink / raw) To: cygwin-apps -----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----- ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Updated: 1.7.0-34 (...and a plea) 2008-12-05 13:59 ` Eric Blake @ 2008-12-05 14:09 ` Corinna Vinschen 0 siblings, 0 replies; 17+ messages in thread From: Corinna Vinschen @ 2008-12-05 14:09 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Updated: 1.7.0-34 (...and a plea) 2008-12-05 11:07 ` Updated: 1.7.0-34 (...and a plea) Corinna Vinschen 2008-12-05 13:06 ` Chris Sutcliffe 2008-12-05 13:59 ` Eric Blake @ 2008-12-08 17:02 ` Christopher Faylor 2008-12-08 17:15 ` Corinna Vinschen 2 siblings, 1 reply; 17+ messages in thread From: Christopher Faylor @ 2008-12-08 17:02 UTC (permalink / raw) To: cygwin-apps, cygwin-developers 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Updated: 1.7.0-34 (...and a plea) 2008-12-08 17:02 ` Christopher Faylor @ 2008-12-08 17:15 ` Corinna Vinschen 2008-12-08 18:01 ` Christopher Faylor 0 siblings, 1 reply; 17+ messages in thread From: Corinna Vinschen @ 2008-12-08 17:15 UTC (permalink / raw) To: cygwin-apps, cygwin-developers 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Updated: 1.7.0-34 (...and a plea) 2008-12-08 17:15 ` Corinna Vinschen @ 2008-12-08 18:01 ` Christopher Faylor 2008-12-08 18:15 ` Corinna Vinschen 0 siblings, 1 reply; 17+ messages in thread From: Christopher Faylor @ 2008-12-08 18:01 UTC (permalink / raw) To: cygwin-apps, cygwin-developers 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Updated: 1.7.0-34 (...and a plea) 2008-12-08 18:01 ` Christopher Faylor @ 2008-12-08 18:15 ` Corinna Vinschen 2008-12-08 19:56 ` Christopher Faylor 0 siblings, 1 reply; 17+ messages in thread From: Corinna Vinschen @ 2008-12-08 18:15 UTC (permalink / raw) To: cygwin-apps, cygwin-developers 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Updated: 1.7.0-34 (...and a plea) 2008-12-08 18:15 ` Corinna Vinschen @ 2008-12-08 19:56 ` Christopher Faylor 2008-12-09 10:19 ` Corinna Vinschen 0 siblings, 1 reply; 17+ messages in thread From: Christopher Faylor @ 2008-12-08 19:56 UTC (permalink / raw) To: cygwin-apps, cygwin-developers 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Updated: 1.7.0-34 (...and a plea) 2008-12-08 19:56 ` Christopher Faylor @ 2008-12-09 10:19 ` Corinna Vinschen 2008-12-09 13:48 ` Corinna Vinschen 0 siblings, 1 reply; 17+ messages in thread From: Corinna Vinschen @ 2008-12-09 10:19 UTC (permalink / raw) To: cygwin-apps, cygwin-developers 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Updated: 1.7.0-34 (...and a plea) 2008-12-09 10:19 ` Corinna Vinschen @ 2008-12-09 13:48 ` Corinna Vinschen 2008-12-09 14:47 ` Brian Dessent 0 siblings, 1 reply; 17+ messages in thread From: Corinna Vinschen @ 2008-12-09 13:48 UTC (permalink / raw) To: cygwin-apps, cygwin-developers 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Updated: 1.7.0-34 (...and a plea) 2008-12-09 13:48 ` Corinna Vinschen @ 2008-12-09 14:47 ` Brian Dessent 2008-12-09 14:59 ` Corinna Vinschen 2008-12-09 15:02 ` Christopher Faylor 0 siblings, 2 replies; 17+ messages in thread From: Brian Dessent @ 2008-12-09 14:47 UTC (permalink / raw) To: Corinna Vinschen; +Cc: cygwin-apps, cygwin-developers 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Updated: 1.7.0-34 (...and a plea) 2008-12-09 14:47 ` Brian Dessent @ 2008-12-09 14:59 ` Corinna Vinschen 2008-12-09 15:02 ` Christopher Faylor 1 sibling, 0 replies; 17+ messages in thread From: Corinna Vinschen @ 2008-12-09 14:59 UTC (permalink / raw) To: cygwin-apps, cygwin-developers 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Updated: 1.7.0-34 (...and a plea) 2008-12-09 14:47 ` Brian Dessent 2008-12-09 14:59 ` Corinna Vinschen @ 2008-12-09 15:02 ` Christopher Faylor 1 sibling, 0 replies; 17+ messages in thread From: Christopher Faylor @ 2008-12-09 15:02 UTC (permalink / raw) To: cygwin-apps, Corinna Vinschen, cygwin-developers 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2008-12-09 15:02 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-11-26 12:44 Updated: 1.7.0-33 (New method to logon without password ... with password) Corinna Vinschen 2008-12-05 11:07 ` Updated: 1.7.0-34 (...and a plea) Corinna Vinschen 2008-12-05 13:06 ` Chris Sutcliffe 2008-12-05 14:07 ` Corinna Vinschen 2008-12-05 17:00 ` Charles Wilson 2008-12-05 13:59 ` Eric Blake 2008-12-05 14:09 ` Corinna Vinschen 2008-12-08 17:02 ` Christopher Faylor 2008-12-08 17:15 ` Corinna Vinschen 2008-12-08 18:01 ` Christopher Faylor 2008-12-08 18:15 ` Corinna Vinschen 2008-12-08 19:56 ` Christopher Faylor 2008-12-09 10:19 ` Corinna Vinschen 2008-12-09 13:48 ` Corinna Vinschen 2008-12-09 14:47 ` Brian Dessent 2008-12-09 14:59 ` Corinna Vinschen 2008-12-09 15:02 ` Christopher Faylor
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).