* setup 2.883 release candidate - please test @ 2017-12-11 21:11 Jon Turney 2017-12-12 6:53 ` Steven Penny 2017-12-15 0:32 ` Achim Gratz 0 siblings, 2 replies; 8+ messages in thread From: Jon Turney @ 2017-12-11 21:11 UTC (permalink / raw) To: The Cygwin Mailing List, cygwin-apps A new setup release candidate is available at: https://cygwin.com/setup/setup-2.883.x86.exe (32 bit version) https://cygwin.com/setup/setup-2.883.x86_64.exe (64 bit version) Please test and report problems to cygwin@cygwin.com. If no regressions are discovered in the next week or so, it will be promoted to release. This is not the place for setup feature requests. Changes compared to 2.882: - Various improvements to behaviour after a download error - Don't fatal() on unexpected early window messages (Addresses: https://cygwin.com/ml/cygwin/2017-07/msg00428.html) - Remove support for installing from a local directory which doesn't contain a setup.ini file - Make 'System Proxy Settings' the default (for new installations) on the 'Select Connection Type' page, rather than 'Direct' - Fix reading and writing of the "extrakeys" user setting. Maybe -U/-u does something useful now? - Pressing enter in the URL textbox on the "Choose Download Site(s)" page now does 'Add', rather than 'Next' - Pressing enter in the search textbox on the "Select Packages" page now causes the search to be performed, rather than 'Next' - Fix concatenating depends: from each version description section - Bullet-proof the way we remove empty categories - If more than one download site is used, we now require downloading setup.ini from all of them to succeed, rather than just one of them. - Various code rearrangements and simplifications Thanks to Ken Brown for several of these changes. -- 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: setup 2.883 release candidate - please test 2017-12-11 21:11 setup 2.883 release candidate - please test Jon Turney @ 2017-12-12 6:53 ` Steven Penny 2017-12-12 14:15 ` Ken Brown 2017-12-15 0:32 ` Achim Gratz 1 sibling, 1 reply; 8+ messages in thread From: Steven Penny @ 2017-12-12 6:53 UTC (permalink / raw) To: cygwin On Mon, 11 Dec 2017 18:46:30, Jon Turney wrote: > A new setup release candidate is available at: > > https://cygwin.com/setup/setup-2.883.x86.exe (32 bit version) > https://cygwin.com/setup/setup-2.883.x86_64.exe (64 bit version) > > Please test and report problems to cygwin@cygwin.com. If no regressions > are discovered in the next week or so, it will be promoted to release. Here is an old issue - say you go to install a package, but your download is corrupt. You get this: --------------------------- Cygwin Setup --------------------------- Package file wget has a corrupt local copy, please remove and retry. --------------------------- OK --------------------------- *Then setup closes*. This is not right. If the archive is missing, or if the archive fails the SHA check, *then the file should be redownloaded by setup*, and SHA check run again. With the current system, setup exits, then the user has to navigate to where the problem file is, for example: C:\http%3a%2f%2fcygwin.mirror.constant.com%2f\x86_64\release\wget then delete the problem file, then restart setup. I cant see why setup shouldnt just automate all of this. Also here is a new issue - on the "Select Connection Type" page - "Use System Proxy Settings" is the first choice, and by default the selected choice. "Direct Connection" should be the first choice, and by default the selected choice. -- 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: setup 2.883 release candidate - please test 2017-12-12 6:53 ` Steven Penny @ 2017-12-12 14:15 ` Ken Brown 2017-12-13 4:09 ` Steven Penny 0 siblings, 1 reply; 8+ messages in thread From: Ken Brown @ 2017-12-12 14:15 UTC (permalink / raw) To: cygwin On 12/11/2017 7:26 PM, Steven Penny wrote: > On Mon, 11 Dec 2017 18:46:30, Jon Turney wrote: >> A new setup release candidate is available at: >> >>   https://cygwin.com/setup/setup-2.883.x86.exe   (32 bit version) >>   https://cygwin.com/setup/setup-2.883.x86_64.exe (64 bit version) >> >> Please test and report problems to cygwin@cygwin.com. If no >> regressions are discovered in the next week or so, it will be promoted >> to release. > > Here is an old issue - say you go to install a package, but your > download is > corrupt. No, a corrupt download is not what causes this. The error actually happens before downloading starts. See below. > You get this: > >   --------------------------- >   Cygwin Setup >   --------------------------- >   Package file wget has a corrupt local copy, please remove and retry. >   --------------------------- >   OK   --------------------------- > > *Then setup closes*. This is not right. If the archive is missing, or if > the > archive fails the SHA check, *then the file should be redownloaded by > setup*, > and SHA check run again. With the current system, setup exits, then the > user has > to navigate to where the problem file is, for example: > > C:\http%3a%2f%2fcygwin.mirror.constant.com%2f\x86_64\release\wget > > then delete the problem file, then restart setup. I cant see why setup > shouldnt > just automate all of this. Here's the situation that leads to this error: You've finished selecting the packages you want to install, and setup is checking to see which ones need to be downloaded. It finds one that's already in the local cache directory, so it doesn't need to be downloaded. But this local version doesn't match the information in setup.ini. So setup bails out and tells you to fix the problem. How can setup possibly automate this? It doesn't know where the corrupt local tarball came from. For example, suppose you sometimes build packages yourself for testing or debugging. You keep them in your local repository, and you also upload them to a private repository on the internet so that you can easily install them on a different computer. You make a change and rebuild the package, but you forget to replace all copies of it. setup can't know which version is the correct one. And it certainly shouldn't be deleting your files because it thinks they're corrupt. [This used to happen to me fairly often, but I finally got in the habit of deleting all local copies after making a change.] > Also here is a new issue - on the "Select > Connection > Type" page - "Use System Proxy Settings" is the first choice, and by > default the > selected choice. "Direct Connection" should be the first choice, and by > default > the selected choice. I wouldn't describe this as a "new issue". It's a deliberate change, which was announced in the message you replied to. The commit message for the change explains the rationale: commit b05caf6f9b366b64845fd918cba6425185f64053 Author: Jon Turney <jon.turney@dronecode.org.uk> Date: Thu Nov 16 15:50:44 2017 +0000 Make 'System Proxy Settings' the default, rather than 'Direct' Make 'System Proxy Settings' the default, rather than 'Direct', and re-order the network connection options so that option is first. If you don't need a proxy, the system proxy setting should be for direct connection, anyhow. So, at the moment, this is just a button you're supposed to know you need to press to make it work, when you are behind a proxy. This setting is persisted (as 'net-method'), so this change only effects new installations. Ken -- 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: setup 2.883 release candidate - please test 2017-12-12 14:15 ` Ken Brown @ 2017-12-13 4:09 ` Steven Penny 2017-12-13 5:21 ` Vince Rice 0 siblings, 1 reply; 8+ messages in thread From: Steven Penny @ 2017-12-13 4:09 UTC (permalink / raw) To: cygwin On Tue, 12 Dec 2017 08:04:09, Ken Brown wrote: > How can setup possibly automate this? It doesn't know where the corrupt > local tarball came from. For example, suppose you sometimes build > packages yourself for testing or debugging. You keep them in your local > repository, and you also upload them to a private repository on the > internet so that you can easily install them on a different computer. > You make a change and rebuild the package, but you forget to replace all > copies of it. setup can't know which version is the correct one. And > it certainly shouldn't be deleting your files because it thinks they're > corrupt. No, this is not right. If you are building packages yourself, then you should have a custom setup.ini to match, example: http://matzeri.altervista.org/x86_64 so that in any case, setup.ini has the final say of what a correct archive is, via the SHA512. If a file in the local repo doesnt match either because: - file size 0 - file size less than proper size because of interrupted download - SHA mismatch because of custom build said file should be removed and redownloaded by setup.exe. if you are building custom archives, then you should also be making custom setup.ini. -- 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: setup 2.883 release candidate - please test 2017-12-13 4:09 ` Steven Penny @ 2017-12-13 5:21 ` Vince Rice 2017-12-13 7:50 ` cyg Simple 0 siblings, 1 reply; 8+ messages in thread From: Vince Rice @ 2017-12-13 5:21 UTC (permalink / raw) To: The Cygwin Mailing List > On Dec 12, 2017, at 6:12 PM, Steven Penny wrote: > > On Tue, 12 Dec 2017 08:04:09, Ken Brown wrote: >> How can setup possibly automate this? It doesn't know where the corrupt local tarball came from. For example, suppose you sometimes build packages yourself for testing or debugging. You keep them in your local repository, and you also upload them to a private repository on the internet so that you can easily install them on a different computer. You make a change and rebuild the package, but you forget to replace all copies of it. setup can't know which version is the correct one. And it certainly shouldn't be deleting your files because it thinks they're corrupt. > > No, this is not right. If you are building packages yourself, then you should > have a custom setup.ini to match, example: > > http://matzeri.altervista.org/x86_64 > > so that in any case, setup.ini has the final say of what a correct archive is, > via the SHA512. If a file in the local repo doesnt match either because: > > - file size 0 > - file size less than proper size because of interrupted download > - SHA mismatch because of custom build > > said file should be removed and redownloaded by setup.exe. if you are building > custom archives, then you should also be making custom setup.ini. Where is that stated as a requirement? I don't see it anywhere, and I don't agree that it should be one. Ken is correct on this, IMO. -- 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: setup 2.883 release candidate - please test 2017-12-13 5:21 ` Vince Rice @ 2017-12-13 7:50 ` cyg Simple 2017-12-13 14:33 ` Ken Brown 0 siblings, 1 reply; 8+ messages in thread From: cyg Simple @ 2017-12-13 7:50 UTC (permalink / raw) To: cygwin On 12/12/2017 10:06 PM, Vince Rice wrote: >> On Dec 12, 2017, at 6:12 PM, Steven Penny wrote: >> >> On Tue, 12 Dec 2017 08:04:09, Ken Brown wrote: >>> How can setup possibly automate this? It doesn't know where the corrupt local tarball came from. For example, suppose you sometimes build packages yourself for testing or debugging. You keep them in your local repository, and you also upload them to a private repository on the internet so that you can easily install them on a different computer. You make a change and rebuild the package, but you forget to replace all copies of it. setup can't know which version is the correct one. And it certainly shouldn't be deleting your files because it thinks they're corrupt. >> >> No, this is not right. If you are building packages yourself, then you should >> have a custom setup.ini to match, example: >> >> http://matzeri.altervista.org/x86_64 >> >> so that in any case, setup.ini has the final say of what a correct archive is, >> via the SHA512. If a file in the local repo doesnt match either because: >> >> - file size 0 >> - file size less than proper size because of interrupted download >> - SHA mismatch because of custom build >> >> said file should be removed and redownloaded by setup.exe. if you are building >> custom archives, then you should also be making custom setup.ini. > > Where is that stated as a requirement? I don't see it anywhere, and I don't agree that it should be one. Ken is correct on this, IMO. Both are correct views of operation. Steve could provide patches to allow a toggle for which logic to use with the default being what occurs now. -- cyg Simple -- 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: setup 2.883 release candidate - please test 2017-12-13 7:50 ` cyg Simple @ 2017-12-13 14:33 ` Ken Brown 0 siblings, 0 replies; 8+ messages in thread From: Ken Brown @ 2017-12-13 14:33 UTC (permalink / raw) To: cygwin On 12/11/2017 1:46 PM, Jon Turney wrote: > > A new setup release candidate is available at: > > https://cygwin.com/setup/setup-2.883.x86.exe (32 bit version) > https://cygwin.com/setup/setup-2.883.x86_64.exe (64 bit version) > > Please test and report problems to cygwin@cygwin.com. If no > regressions > are discovered in the next week or so, it will be promoted to release. > > This is not the place for setup feature requests. This thread has veered off topic. I'm going to start a new thread to discuss the issue that Steven raised. Ken -- 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: setup 2.883 release candidate - please test 2017-12-11 21:11 setup 2.883 release candidate - please test Jon Turney 2017-12-12 6:53 ` Steven Penny @ 2017-12-15 0:32 ` Achim Gratz 1 sibling, 0 replies; 8+ messages in thread From: Achim Gratz @ 2017-12-15 0:32 UTC (permalink / raw) To: cygwin Jon Turney writes: > A new setup release candidate is available at: > > https://cygwin.com/setup/setup-2.883.x86.exe (32 bit version) > https://cygwin.com/setup/setup-2.883.x86_64.exe (64 bit version) I couldn't give it much testing, but I've built this version for both arches locally and can confirm they work just fine for me. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-12-14 20:13 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-12-11 21:11 setup 2.883 release candidate - please test Jon Turney 2017-12-12 6:53 ` Steven Penny 2017-12-12 14:15 ` Ken Brown 2017-12-13 4:09 ` Steven Penny 2017-12-13 5:21 ` Vince Rice 2017-12-13 7:50 ` cyg Simple 2017-12-13 14:33 ` Ken Brown 2017-12-15 0:32 ` Achim Gratz
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).