Jon TURNEY | 5 Jan 20:50 2011
Picon

[PATCH] cygcheck -s should not imply -d


Currently, for cygcheck -s implies -d.  This seems rather unhelpful.

I'm afraid I've lost the thread which inspired this, but in it the reporter
provided cygcheck -svr output as requested, but this did not help diagnose
what ultimately turned out to be the problem, that a DLL was actually an older
version (presumably due to replace-in-use problems)

Attached a patch to modify cygcheck so -s no longer implies -d (although -d
can still be used).


2011-01-05  Jon TURNEY  <jon.turney <at> dronecode.org.uk>

	* cygcheck.cc (main): don't imply -d from -s option to cygcheck

Index: cygcheck.cc
===================================================================
RCS file: /cvs/src/src/winsup/utils/cygcheck.cc,v
retrieving revision 1.124
diff -u -r1.124 cygcheck.cc
--- cygcheck.cc	28 Aug 2010 11:22:37 -0000	1.124
+++ cygcheck.cc	5 Jan 2011 15:49:47 -0000
 <at>  <at>  -2180,7 +2180,7  <at>  <at> 
   -c, --check-setup    show installed version of PACKAGE and verify integrity\n\
                        (or for all installed packages if none specified)\n\
   -d, --dump-only      just list packages, do not verify (with -c)\n\
-  -s, --sysinfo        produce diagnostic system information (implies -c -d)\n\
(Continue reading)

Corinna Vinschen | 10 Jan 13:51 2011

Re: [PATCH] cygcheck -s should not imply -d

On Jan  5 19:50, Jon TURNEY wrote:
> 
> Currently, for cygcheck -s implies -d.  This seems rather unhelpful.
> 
> I'm afraid I've lost the thread which inspired this, but in it the reporter
> provided cygcheck -svr output as requested, but this did not help diagnose
> what ultimately turned out to be the problem, that a DLL was actually an older
> version (presumably due to replace-in-use problems)
> 
> Attached a patch to modify cygcheck so -s no longer implies -d (although -d
> can still be used).
> 

> 
> 2011-01-05  Jon TURNEY
> 
> 	* cygcheck.cc (main): don't imply -d from -s option to cygcheck

Looks good to me.  Applied.

Thanks,
Corinna

--

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

Christopher Faylor | 10 Jan 18:52 2011

Re: [PATCH] cygcheck -s should not imply -d

On Mon, Jan 10, 2011 at 01:51:02PM +0100, Corinna Vinschen wrote:
>On Jan  5 19:50, Jon TURNEY wrote:
>> 
>> Currently, for cygcheck -s implies -d.  This seems rather unhelpful.
>> 
>> I'm afraid I've lost the thread which inspired this, but in it the reporter
>> provided cygcheck -svr output as requested, but this did not help diagnose
>> what ultimately turned out to be the problem, that a DLL was actually an older
>> version (presumably due to replace-in-use problems)
>> 
>> Attached a patch to modify cygcheck so -s no longer implies -d (although -d
>> can still be used).
>> 
>
>> 
>> 2011-01-05  Jon TURNEY
>> 
>> 	* cygcheck.cc (main): don't imply -d from -s option to cygcheck
>
>Looks good to me.  Applied.

Sorry that I didn't reply to this.  I wasn't 100% convinced that this
was a good idea since some of the packages show up as having problems
when they are ok.  I was wondering if that would end up generating more
(understandably) confused mailing list traffic but I guess, in the end,
it probably is better to check the validity of the packages for the
prescribed error reporting technique.

cgf

(Continue reading)

Corinna Vinschen | 11 Jan 09:10 2011

Re: [PATCH] cygcheck -s should not imply -d

On Jan 10 12:52, Christopher Faylor wrote:
> On Mon, Jan 10, 2011 at 01:51:02PM +0100, Corinna Vinschen wrote:
> >On Jan  5 19:50, Jon TURNEY wrote:
> >> 
> >> Currently, for cygcheck -s implies -d.  This seems rather unhelpful.
> >> 
> >> I'm afraid I've lost the thread which inspired this, but in it the reporter
> >> provided cygcheck -svr output as requested, but this did not help diagnose
> >> what ultimately turned out to be the problem, that a DLL was actually an older
> >> version (presumably due to replace-in-use problems)
> >> 
> >> Attached a patch to modify cygcheck so -s no longer implies -d (although -d
> >> can still be used).
> >> 
> >
> >> 
> >> 2011-01-05  Jon TURNEY
> >> 
> >> 	* cygcheck.cc (main): don't imply -d from -s option to cygcheck
> >
> >Looks good to me.  Applied.
> 
> Sorry that I didn't reply to this.  I wasn't 100% convinced that this
> was a good idea since some of the packages show up as having problems
> when they are ok.  I was wondering if that would end up generating more
> (understandably) confused mailing list traffic but I guess, in the end,
> it probably is better to check the validity of the packages for the
> prescribed error reporting technique.

I wasn't quite sure either, but while running cygcheck with Jon's patch
(Continue reading)

Yaakov (Cygwin/X | 11 Jan 10:36 2011
Picon
Picon

Fixes for cfget[io]speed

I discovered some compliance issues with cfget[io]speed:

* POSIX requires these to be declared (at least) as functions[1];
* POSIX requires their argument to be const[1];
* the macros are not safe for C++ code.

The following patch fixes these issues, providing that constifying the
arguments doesn't change the ABI.

Yaakov

[1]
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/termios.h.html
Attachment (posix-cfgetospeed.patch): text/x-patch, 1945 bytes
Corinna Vinschen | 11 Jan 11:10 2011

Re: Fixes for cfget[io]speed

On Jan 11 03:36, Yaakov (Cygwin/X) wrote:
> I discovered some compliance issues with cfget[io]speed:
> 
> * POSIX requires these to be declared (at least) as functions[1];
> * POSIX requires their argument to be const[1];
> * the macros are not safe for C++ code.
> 
> The following patch fixes these issues, providing that constifying the
> arguments doesn't change the ABI.
> 
> 
> Yaakov
> 
> [1]
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/termios.h.html

> 2011-01-11  Yaakov Selkowitz
> 
> 	* termios.cc (cfgetospeed, cfgetispeed): Constify argument per POSIX.
> 	* include/sys/termios.h (cfgetospeed, cfgetispeed): Declare functions.
> 	Move macros after declarations and make conditional on !__cplusplus.

Thanks, applied.

Corinna

--

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

Jon TURNEY | 11 Jan 15:26 2011
Picon

Re: [PATCH] cygcheck -s should not imply -d

On 11/01/2011 08:10, Corinna Vinschen wrote:
> On Jan 10 12:52, Christopher Faylor wrote:
>> On Mon, Jan 10, 2011 at 01:51:02PM +0100, Corinna Vinschen wrote:
>>> On Jan  5 19:50, Jon TURNEY wrote:
>>>>
>>>> Currently, for cygcheck -s implies -d.  This seems rather unhelpful.
>>>>
>>>> I'm afraid I've lost the thread which inspired this, but in it the reporter
>>>> provided cygcheck -svr output as requested, but this did not help diagnose
>>>> what ultimately turned out to be the problem, that a DLL was actually an older
>>>> version (presumably due to replace-in-use problems)
>>>>
>>>> Attached a patch to modify cygcheck so -s no longer implies -d (although -d
>>>> can still be used).
>>>>
>>>
>>>>
>>>> 2011-01-05  Jon TURNEY
>>>>
>>>> 	* cygcheck.cc (main): don't imply -d from -s option to cygcheck
>>>
>>> Looks good to me.  Applied.
>>
>> Sorry that I didn't reply to this.  I wasn't 100% convinced that this
>> was a good idea since some of the packages show up as having problems
>> when they are ok.  I was wondering if that would end up generating more
>> (understandably) confused mailing list traffic but I guess, in the end,
>> it probably is better to check the validity of the packages for the
>> prescribed error reporting technique.
> 
(Continue reading)

Corinna Vinschen | 13 Jan 13:33 2011

Re: [PATCH] cygcheck -s should not imply -d

On Jan 11 14:26, Jon TURNEY wrote:
> On 11/01/2011 08:10, Corinna Vinschen wrote:
> > I wasn't quite sure either, but while running cygcheck with Jon's patch
> > it started to make more sense.  We can also change the docs to ask for
> > `cygcheck -svrd' output, but I guess we should just wait and see.
> 
> FWIW (I don't have all packages installed), mutt is the only package I have
> installed for which cygcheck -c falsely reports a problem.
> 
> $ cygcheck -c | grep -v OK
> Cygwin Package Information
> Package                        Version                  Status
> mutt                           1.5.20-1                 Incomplete

Do you happen to know why?

> Would a patch to http://cygwin.com/setup.html be welcome recommending that:
> (a) if a package installs files which a user is expected to customize, don't
> trample over those customizations when the package is upgraded/reinstalled

Isn't that what /etc/defaults and /etc/postinstall is for, basically?
I'm not sure I understand what you're proposing.  At which point should
setup warn and how is it supposed to know that a file is a
user-customizable one?  In theory, that's all in the responsibility
of the package.

> (b) a package should verify as correctly installed with cygcheck -c?

I don't understand this, sorry.  Would you mind to rephrase and maybe
give an example what you mean?
(Continue reading)

Jon TURNEY | 13 Jan 14:04 2011
Picon

Re: [PATCH] cygcheck -s should not imply -d

On 13/01/2011 12:33, Corinna Vinschen wrote:
> On Jan 11 14:26, Jon TURNEY wrote:
>> On 11/01/2011 08:10, Corinna Vinschen wrote:
>>> I wasn't quite sure either, but while running cygcheck with Jon's patch
>>> it started to make more sense.  We can also change the docs to ask for
>>> `cygcheck -svrd' output, but I guess we should just wait and see.
>>
>> FWIW (I don't have all packages installed), mutt is the only package I have
>> installed for which cygcheck -c falsely reports a problem.
>>
>> $ cygcheck -c | grep -v OK
>> Cygwin Package Information
>> Package                        Version                  Status
>> mutt                           1.5.20-1                 Incomplete
> 
> Do you happen to know why?

You can read my ill-informed speculation about this matter at [1] :-)

[1] http://sourceware.org/ml/cygwin-apps/2010-11/msg00065.html

>> Would a patch to http://cygwin.com/setup.html be welcome recommending that:
>> (a) if a package installs files which a user is expected to customize, don't
>> trample over those customizations when the package is upgraded/reinstalled
> 
> Isn't that what /etc/defaults and /etc/postinstall is for, basically?
> I'm not sure I understand what you're proposing.  At which point should
> setup warn and how is it supposed to know that a file is a
> user-customizable one?  In theory, that's all in the responsibility
> of the package.
(Continue reading)

Corinna Vinschen | 13 Jan 14:24 2011

Re: [PATCH] cygcheck -s should not imply -d

On Jan 13 13:04, Jon TURNEY wrote:
> On 13/01/2011 12:33, Corinna Vinschen wrote:
> > On Jan 11 14:26, Jon TURNEY wrote:
> >> On 11/01/2011 08:10, Corinna Vinschen wrote:
> >>> I wasn't quite sure either, but while running cygcheck with Jon's patch
> >>> it started to make more sense.  We can also change the docs to ask for
> >>> `cygcheck -svrd' output, but I guess we should just wait and see.
> >>
> >> FWIW (I don't have all packages installed), mutt is the only package I have
> >> installed for which cygcheck -c falsely reports a problem.
> >>
> >> $ cygcheck -c | grep -v OK
> >> Cygwin Package Information
> >> Package                        Version                  Status
> >> mutt                           1.5.20-1                 Incomplete
> > 
> > Do you happen to know why?
> 
> You can read my ill-informed speculation about this matter at [1] :-)
> 
> [1] http://sourceware.org/ml/cygwin-apps/2010-11/msg00065.html

Uh, ok.  Thanks for the pointer.

> >> Would a patch to http://cygwin.com/setup.html be welcome recommending that:
> >> (a) if a package installs files which a user is expected to customize, don't
> >> trample over those customizations when the package is upgraded/reinstalled
> > 
> > Isn't that what /etc/defaults and /etc/postinstall is for, basically?
> > I'm not sure I understand what you're proposing.  At which point should
(Continue reading)


Gmane