Re: [ANNOUNCEMENT] Updated: mintty 2.9.9
Hi Corinna, Am 24.03.2019 um 19:19 schrieb Corinna Vinschen: On Mar 24 16:57, Thomas Wolff wrote: Hi Achim, Am 16.03.2019 um 15:00 schrieb Achim Gratz: Thomas Wolff writes: I have uploaded mintty 2.9.9 with the following changes: While you're at it, could you please stop using the release number "0" for your packages? I had previously explained why I used to like this (native package, no patches) and there had been no comments... That's supposed to be used for test packages only (if you want to make an effort to convey that in the package file name). I don't see this documented anywhere. Proper releases should start with "1". https://cygwin.com/packaging-contributors-guide.html#updating OK, I see *this* described now; I think it changed some time. Was there any discussion about it? Anyway, with maybe one more vote, I'll make the change. While you're at it, a mintty-debuginfo package may be pretty helpful. Sorry, I neither know how to make use of such a package nor how to generate it or what it contains. But I'd take a patch:) Thomas -- 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
Re: [ANNOUNCEMENT] Updated: mintty 2.9.9
Greetings, Thomas Wolff! > Am 16.03.2019 um 15:00 schrieb Achim Gratz: >> Thomas Wolff writes: >>> I have uploaded mintty 2.9.9 with the following changes: >> While you're at it, could you please stop using the release number "0" for >> your packages? > I had previously explained why I used to like this (native package, no > patches) and there had been no comments... >> That's supposed to be used for test packages only >> (if you want to make an effort to convey that in the package file name). > I don't see this documented anywhere. >> Proper releases should start with "1". >> >> https://cygwin.com/packaging-contributors-guide.html#updating > OK, I see *this* described now; I think it changed some time. Was there > any discussion about it? > Anyway, with maybe one more vote, I'll make the change. I think it was made official with last rewrite of Setup's version matching algorithm. Some 3 to 5 years ago. You can tell full official Cygwin release by -1 added to the relevant upstream version tag. Preliminary/test releases are marked with -0.x. -- With best regards, Andrey Repin Sunday, March 24, 2019 23:53:41 Sorry for my terrible english... -- 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
[ANNOUNCEMENT] Updated: Perl distributions
The following Perl distributions have been updated to their latest version on CPAN, respectively: x86/x86_64 -- perl-Cpanel-JSON-XS-4.10-1 perl-Net-DNS-SEC-1.12-1 perl-Text-CSV_XS-1.39-1 noarch -- perl-libwww-perl-6.37-1 perl-LWP-MediaTypes-6.04-1 perl-Mojolicious-8.13-1 perl-Net-DNS-1.20-1 perl-Sub-Quote-2.006003-1 perl-Test-Differences-0.67-1 perl-Test-Inter-1.09-1 perl-Test2-Suite-0.000119-1 -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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
Re: [PATCH] default ps -W process start time to system boot time when inaccessible, 0, -1
Brian Inglis writes: > System processes with more recent process start times seem to make process > times > available to unelevated processes. > Do startup system processes not have this info available to unelevated > processes > because of some security policy, timing, or possible race conditions with > system > process and performance monitor startup? I don't understand why you keep talking exclusively about system startup processes, these are just a subset (if a particularly stubborn one). The process start time info is generally unavailable for an unprivileged user (since it requires to "open" the process") except for processes started under the same user account in the same user session. There is a security token (I forgot the name, but it's been posted on this list a few days ago) you can add to user accounts so they get to see more (but still not all) such information. Certain types of information are only accessible conditional on which groups you're a member of. It also varies a bit by Windows version and type of install, I think. On top of that come group policies. So this is a lot more involved than just system startup processes. > System startup process start times appear to not be available to unelevated > processes, so the process default value is zero. > ISTM boot time is a better, more accurate, and useful default for those > processes. I still disagree, but then those are not the only processes that have this issue. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves -- 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
Re: [PATCH] default ps -W process start time to system boot time when inaccessible, 0, -1
On 2019-03-24 12:15, Achim Gratz wrote: > Brian Inglis writes: >> Boot time is neither magic nor pulled out of thin air. > No, but other than a lower limit of the process start time it has no > correlation whatsoever to the start time of a process that I am not > proviledged to get the start time from. >> Checking *my* system processes using wmic queries and elevated powershell >> scripts, the boot time is at most a few seconds off from process start times >> from other sources. >> I understand that other systems may run processes where that is not the case. >> Please explain why you think this is misleadingly not useful, or where or >> which >> processes have unvailable start times that are not very close to boot time. > System processes get started and re-started all the time, as do > processes from other users (interactive or otherwise). System processes with more recent process start times seem to make process times available to unelevated processes. Do startup system processes not have this info available to unelevated processes because of some security policy, timing, or possible race conditions with system process and performance monitor startup? > So again: in the case under discussion we _know_ that "0" is a bogus > timestamp value that no process ever got started on, even if it can be > translated to "Jan 1st 1970" if it were indeed a valid timestamp. All > I'm asking is that ps shows something like "N/A" instead of trying to > print something that looks like it might be a valid time, but still > isn't. System startup process start times appear to not be available to unelevated processes, so the process default value is zero. ISTM boot time is a better, more accurate, and useful default for those processes. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: mintty 2.9.9
On Mar 24 16:57, Thomas Wolff wrote: > Hi Achim, > > Am 16.03.2019 um 15:00 schrieb Achim Gratz: > > Thomas Wolff writes: > > > I have uploaded mintty 2.9.9 with the following changes: > > While you're at it, could you please stop using the release number "0" for > > your packages? > I had previously explained why I used to like this (native package, no > patches) and there had been no comments... > > That's supposed to be used for test packages only > > (if you want to make an effort to convey that in the package file name). > I don't see this documented anywhere. > > Proper releases should start with "1". > > > > https://cygwin.com/packaging-contributors-guide.html#updating > OK, I see *this* described now; I think it changed some time. Was there any > discussion about it? > Anyway, with maybe one more vote, I'll make the change. While you're at it, a mintty-debuginfo package may be pretty helpful. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: [PATCH] default ps -W process start time to system boot time when inaccessible, 0, -1
Brian Inglis writes: > Boot time is neither magic nor pulled out of thin air. No, but other than a lower limit of the process start time it has no correlation whatsoever to the start time of a process that I am not proviledged to get the start time from. > Checking *my* system processes using wmic queries and elevated powershell > scripts, the boot time is at most a few seconds off from process start times > from other sources. > I understand that other systems may run processes where that is not the case. > Please explain why you think this is misleadingly not useful, or where or > which > processes have unvailable start times that are not very close to boot time. System processes get started and re-started all the time, as do processes from other users (interactive or otherwise). So again: in the case under discussion we _know_ that "0" is a bogus timestamp value that no process ever got started on, even if it can be translated to "Jan 1st 1970" if it were indeed a valid timestamp. All I'm asking is that ps shows something like "N/A" instead of trying to print something that looks like it might be a valid time, but still isn't. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs -- 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
Re: [ANNOUNCEMENT] Updated: mintty 2.9.9
On 2019-03-24 09:57, Thomas Wolff wrote: > Am 16.03.2019 um 15:00 schrieb Achim Gratz: >> Thomas Wolff writes: >>> I have uploaded mintty 2.9.9 with the following changes: >> While you're at it, could you please stop using the release number "0" for >> your packages? > I had previously explained why I used to like this (native package, no > patches) > and there had been no comments... >> That's supposed to be used for test packages only >> (if you want to make an effort to convey that in the package file name). > I don't see this documented anywhere. >> Proper releases should start with "1". >> https://cygwin.com/packaging-contributors-guide.html#updating > OK, I see *this* described now; I think it changed some time. Was there any > discussion about it? > Anyway, with maybe one more vote, I'll make the change. It may have been informal but is now documented - please go with the flow. Don't make us come after you with puns about fresh flavours and odours, periods in education or loans, or finality, that your package begs for! Let's keep this civil ;^> -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [PATCH] default ps -W process start time to system boot time when inaccessible, 0, -1
On 2019-03-24 02:18, Achim Gratz wrote: > Brian Inglis writes: >> Are there non-startup system processes for which boot time is misleading? >> If you need the truth use wmic, procexp64, or run ps in an elevated shell. > > I don't seem to get my point across. I'm fine with getting no start > time value when that ps wasn't able to obtain that information. If we > have to use magic values to convey that information for one reason or > another, then I'd rather opt for one that is obviously pulled out of > thin air than for one that I have to compare to some other stuff before > that becomes clear. [Cross posting to Cygwin list as this is a more general discussion IMO] Boot time is neither magic nor pulled out of thin air. Checking *my* system processes using wmic queries and elevated powershell scripts, the boot time is at most a few seconds off from process start times from other sources. I understand that other systems may run processes where that is not the case. Please explain why you think this is misleadingly not useful, or where or which processes have unvailable start times that are not very close to boot time. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: mintty 2.9.9
Hi Achim, Am 16.03.2019 um 15:00 schrieb Achim Gratz: Thomas Wolff writes: I have uploaded mintty 2.9.9 with the following changes: While you're at it, could you please stop using the release number "0" for your packages? I had previously explained why I used to like this (native package, no patches) and there had been no comments... That's supposed to be used for test packages only (if you want to make an effort to convey that in the package file name). I don't see this documented anywhere. Proper releases should start with "1". https://cygwin.com/packaging-contributors-guide.html#updating OK, I see *this* described now; I think it changed some time. Was there any discussion about it? Anyway, with maybe one more vote, I'll make the change. Thomas -- 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
Re: [ANNOUNCEMENT] Updated: mintty 2.9.9
On Sat, 16 Mar 2019 15:00:54, Achim Gratz wrote: Thomas Wolff writes: I have uploaded mintty 2.9.9 with the following changes: While you're at it, could you please stop using the release number "0" for your packages? That's supposed to be used for test packages only (if you want to make an effort to convey that in the package file name). Proper releases should start with "1". https://cygwin.com/packaging-contributors-guide.html#updating I agree. Also currently no dependencies are listed. This is incorrect as Mintty requires at least the Cygwin DLL. Adding "bash" to "depends2" would take care of it through child dependencies. -- 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
