Re: [PATCH] inform user if any postinstall script failed to run
On Sat, Aug 28, 2010 at 01:30:54PM +0100, Jon TURNEY wrote: >On 27/08/2010 19:33, Christopher Faylor wrote: >> On Fri, Aug 27, 2010 at 06:15:38PM +0100, Jon TURNEY wrote: >>> On 29/07/2010 17:28, Jon TURNEY wrote: On 28/07/2010 15:58, Christopher Faylor wrote: > On Wed, Jul 28, 2010 at 03:25:17PM +0100, Jon TURNEY wrote: >> Anyhow, here's another attempt, which unfortunately changes rather more >> than I >> wanted to. It adds a new page, which is displayed if any script failed, >> and >> reports which packages and scripts failed. > > That is great. Please check in (with a ChangeLog of course). >>> >>> Due to the way I tested this change, I'd failed to notice that when a >>> package >>> is installed with a failing postinstall script, this will list the failing >>> script twice, once with the package name and once as 'no package'. >>> >>> Attached is a patch to remedy that. >> >> Do we realy need a separate for loop for this? Couldn't we just piggy >> back on the previous for loop? > >Sure. I'm not sure if it's any more elegant, though :-) Yow. No, it isn't. I didn't think you'd need to modify RunScript to deal with the behavior. So, nevermind. The previous solution looks simpler. Please go ahead with that one. cgf
Re: [PATCH] inform user if any postinstall script failed to run
On 27/08/2010 19:33, Christopher Faylor wrote:
On Fri, Aug 27, 2010 at 06:15:38PM +0100, Jon TURNEY wrote:
On 29/07/2010 17:28, Jon TURNEY wrote:
On 28/07/2010 15:58, Christopher Faylor wrote:
On Wed, Jul 28, 2010 at 03:25:17PM +0100, Jon TURNEY wrote:
Anyhow, here's another attempt, which unfortunately changes rather more than I
wanted to. It adds a new page, which is displayed if any script failed, and
reports which packages and scripts failed.
That is great. Please check in (with a ChangeLog of course).
Due to the way I tested this change, I'd failed to notice that when a package
is installed with a failing postinstall script, this will list the failing
script twice, once with the package name and once as 'no package'.
Attached is a patch to remedy that.
Do we realy need a separate for loop for this? Couldn't we just piggy
back on the previous for loop?
Sure. I'm not sure if it's any more elegant, though :-)
Index: postinstall.cc
===
RCS file: /cvs/cygwin-apps/setup/postinstall.cc,v
retrieving revision 2.25
diff -u -r2.25 postinstall.cc
--- postinstall.cc 30 Jul 2010 20:53:42 - 2.25
+++ postinstall.cc 28 Aug 2010 12:25:34 -
@@ -74,7 +74,7 @@
class RunScript
{
public:
- RunScript(const std::string& name, const vector
Re: [PATCH] Don't set sticky bit on /var/log
On Aug 27 20:35, Corinna Vinschen wrote: > On Aug 27 19:11, Jon TURNEY wrote: > > > > For the purposes of discussion, attached is a patch which changes > > the mode which setup gives /var/log from 1777 to 0777. > > > > See this thread [1] for why I think I want to do this. > > > > I haven't thought at all about the security implications of this change at > > all. > > > > I have observed that /var/log has mode 0755 on a couple of linux > > systems I've looked at. > > > > It looks like the setting of mode 1777 was added by Corrina on > > s/rrin/rinn/ > > > 2008-08-20, I'm guessing as part of the Cygwin 1.7 changes. > > > > [1] http://cygwin.com/ml/cygwin-xfree/2010-08/msg00090.html > > The problem is in fact one of security. If the directory has 0777 > permissions, everyone can remove log files from everyone else. That's > hardly feasible, especially given service logs and stuff. > > May I suggest to follow the basic route you outlined in the > aforementioned mail? Create a subdir /var/log/XWin with 0777 > permissions and use that to create the XWin logs. is there some way to > set this as global setting right from the package installation? Here's another idea. What about making the default logfile name user-specific, as in /var/log/XWin.$USER.$DISPLAY.log ? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
