Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...

2009-12-21 Thread Corinna Vinschen
On Dec 17 17:01, Corinna Vinschen wrote:
> On Dec 17 10:52, Christopher Faylor wrote:
> > On Thu, Dec 17, 2009 at 02:12:15PM +0100, Corinna Vinschen wrote:
> > >On Dec 16 13:40, Christopher Faylor wrote:
> > >> On Wed, Dec 16, 2009 at 06:18:38PM +0100, Corinna Vinschen wrote:
> > >> >But we discussed this on the developers list.  The old setup will be
> > >> >setup-legacy.exe and setup.exe is only for 1.7 and later.  I'm rather
> > >> >puzzled that you want to change this again.  I have matching local
> > >> >changes to the web page waiting.  Please don't change this again.
> > >> 
> > >> Since I have to change source code to understand the "release-legacy"
> > >> directory, I opted to just do it in the trunk rather than the ancient
> > >> setup 1.5 branch.  There will still be a setup-legacy binary.
> > >
> > >Ok.  The problem is just this.  If setup.exe still works for 9x users
> > >and just access setup-legacy.ini, they will never see that they are
> > >accessing an unsupported repository.  That's why I now think that
> > >setup.exe should give them a warning instead.  They should explicitely
> > >be forced to use setup-legacy.exe if they updated at all.
> > 
> > "There will still be a setup-legacy binary" != "setup.exe will seem to
> > work just fine for Windows 9x users".
> 
> You wrote that you would like setup to work on 9x again and that's what
> I'm talking about.  I didn't mean to imply anything about setup-legacy.
> It's all about setup.  Details might be helpful.

Is there a chance we can release 1.7.1 before Christmas?


Corinna

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


Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...

2009-12-17 Thread Corinna Vinschen
On Dec 17 10:52, Christopher Faylor wrote:
> On Thu, Dec 17, 2009 at 02:12:15PM +0100, Corinna Vinschen wrote:
> >On Dec 16 13:40, Christopher Faylor wrote:
> >> On Wed, Dec 16, 2009 at 06:18:38PM +0100, Corinna Vinschen wrote:
> >> >But we discussed this on the developers list.  The old setup will be
> >> >setup-legacy.exe and setup.exe is only for 1.7 and later.  I'm rather
> >> >puzzled that you want to change this again.  I have matching local
> >> >changes to the web page waiting.  Please don't change this again.
> >> 
> >> Since I have to change source code to understand the "release-legacy"
> >> directory, I opted to just do it in the trunk rather than the ancient
> >> setup 1.5 branch.  There will still be a setup-legacy binary.
> >
> >Ok.  The problem is just this.  If setup.exe still works for 9x users
> >and just access setup-legacy.ini, they will never see that they are
> >accessing an unsupported repository.  That's why I now think that
> >setup.exe should give them a warning instead.  They should explicitely
> >be forced to use setup-legacy.exe if they updated at all.
> 
> "There will still be a setup-legacy binary" != "setup.exe will seem to
> work just fine for Windows 9x users".

You wrote that you would like setup to work on 9x again and that's what
I'm talking about.  I didn't mean to imply anything about setup-legacy.
It's all about setup.  Details might be helpful.


Corinna

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


Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...

2009-12-17 Thread Christopher Faylor
On Thu, Dec 17, 2009 at 02:12:15PM +0100, Corinna Vinschen wrote:
>On Dec 16 13:40, Christopher Faylor wrote:
>> On Wed, Dec 16, 2009 at 06:18:38PM +0100, Corinna Vinschen wrote:
>> >But we discussed this on the developers list.  The old setup will be
>> >setup-legacy.exe and setup.exe is only for 1.7 and later.  I'm rather
>> >puzzled that you want to change this again.  I have matching local
>> >changes to the web page waiting.  Please don't change this again.
>> 
>> Since I have to change source code to understand the "release-legacy"
>> directory, I opted to just do it in the trunk rather than the ancient
>> setup 1.5 branch.  There will still be a setup-legacy binary.
>
>Ok.  The problem is just this.  If setup.exe still works for 9x users
>and just access setup-legacy.ini, they will never see that they are
>accessing an unsupported repository.  That's why I now think that
>setup.exe should give them a warning instead.  They should explicitely
>be forced to use setup-legacy.exe if they updated at all.

"There will still be a setup-legacy binary" != "setup.exe will seem to
work just fine for Windows 9x users".

cgf


Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...

2009-12-17 Thread Corinna Vinschen
On Dec 16 13:40, Christopher Faylor wrote:
> On Wed, Dec 16, 2009 at 06:18:38PM +0100, Corinna Vinschen wrote:
> >But we discussed this on the developers list.  The old setup will be
> >setup-legacy.exe and setup.exe is only for 1.7 and later.  I'm rather
> >puzzled that you want to change this again.  I have matching local
> >changes to the web page waiting.  Please don't change this again.
> 
> Since I have to change source code to understand the "release-legacy"
> directory, I opted to just do it in the trunk rather than the ancient
> setup 1.5 branch.  There will still be a setup-legacy binary.

Ok.  The problem is just this.  If setup.exe still works for 9x users
and just access setup-legacy.ini, they will never see that they are
accessing an unsupported repository.  That's why I now think that
setup.exe should give them a warning instead.  They should explicitely
be forced to use setup-legacy.exe if they updated at all.


Corinna

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


Re: general setup.exe status incl network install [was Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...]

2009-12-17 Thread Corinna Vinschen
On Dec 17 01:33, Dave Korn wrote:
>   I think the strace suggests where the problem lies:
> 
> >   350  519655 [main] bash 680 open: 3 = open (/tmp/sh-thd-1261038922, 
> > 0x10E01)
>[ ... snip ... ]
> >   517  535090 [main] bash 680 open: 4 = open (/tmp/sh-thd-1261038922, 
> > 0x1)
> >   454  535544 [main] bash 680 close: close (3)
> >   476  536020 [main] bash 680 fhandler_base::close: closing 
> > '/tmp/sh-thd-1261038922' handle 0x6A4
> >   679  536699 [main] bash 680 close: 0 = close (3)
> >   563  537262 [main] bash 680 normalize_posix_path: src 
> > /tmp/sh-thd-1261038922
> >   605  537867 [main] bash 680 normalize_posix_path: /tmp/sh-thd-1261038922 
> > = normalize_posix_path (/tmp/sh-thd-1261038922)
> >   449  538316 [main] bash 680 mount_info::conv_to_win32_path: 
> > conv_to_win32_path (/tmp/sh-thd-1261038922)
> >   571  538887 [main] bash 680 set_flags: flags: binary (0x2)
> >   806  539693 [main] bash 680 mount_info::conv_to_win32_path: src_path 
> > /tmp/sh-thd-1261038922, dst Z:\cygremotewin2\tmp\sh-thd-1261038922, flags 
> > 0x3000A, rc 0
> >  1641  541334 [main] bash 680 symlink_info::check: not a symlink
> >  1003  542337 [main] bash 680 symlink_info::check: 0 = symlink.check 
> > (Z:\cygremotewin2\tmp\sh-thd-1261038922, 0x22B5E8) (0x3000A)
> >   466  542803 [main] bash 680 path_conv::check: 
> > this->path(Z:\cygremotewin2\tmp\sh-thd-1261038922), has_acls(1)
> >   547  543350 [main] bash 680 seterrno_from_win_error: 
> > /ext/build/netrel/src/cygwin-1.7.0-62/winsup/cygwin/syscalls.cc:674 windows 
> > error 32
> >   496  543846 [main] bash 680 geterrno_from_win_error: windows error 32 == 
> > errno 16
> >   449  544295 [main] bash 680 __set_errno: void 
> > seterrno_from_win_error(const char*, int, DWORD):319 val 16
> >   433  544728 [main] bash 680 unlink: -1 = unlink (/tmp/sh-thd-1261038922)
> >   740  545468 [main] bash 680 close: close (4)
> >   498  545966 [main] bash 680 fhandler_base::close: closing 
> > '/tmp/sh-thd-1261038922' handle 0x6A0
> >  1121  547087 [main] bash 680 close: 0 = close (4)
> 
>   It looks like the unlink-while-you-still-have-an-open-handle-to-the-file
> trick isn't working on SMB mounts, perhaps?

Indeed.  unlink-while-you-still-have-an-open-handle-to-the-file requires
to be able to move the file to the recycle bin.  The recycle bin does not
exist on shares.  So you get an EBUSY which is perfectly fine with POSIX.


Corinna

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


Re: general setup.exe status incl network install [was Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...]

2009-12-16 Thread Dave Korn
Corinna Vinschen wrote:
> On Dec 16 14:24, Dave Korn wrote:

>>   Does this symptom suggest any possibilities to anyone?
> 
> Unfortunately not.  It's really officially the NULL SID.  The NULL SID
> ACE is created when at least one of the special SUID, SGID or VTX bits
> are set in the permissions.

  Ah, ok.  Well, I've got more.  Here's what happens when you launch the first
cygwin shell after completing the install:

> Copying skeleton files.
> These files are for the user to personalise their cygwin experience.
> 
> They will never be overwritten nor automatically updated.
> 
> `./.bashrc' -> `/home/DaveK//.bashrc'
> `./.bash_profile' -> `/home/DaveK//.bash_profile'
> `./.inputrc' -> `/home/DaveK//.inputrc'
> bash: cannot create temp file for here document: Device or resource busy

  I remembered wrong; it's not r-o, it's busy.  That error happens again every
time you start up a shell, and when you look in the tmp dir, you see that it
did in fact manage to create the temp file for the here doc:

> $ ls -lart /tmp/
> total 12
> -rw---  1 Administrators None  122 Dec 16 23:42 sh-thd-1260978391
> drwxr-xr-x+ 1 Administrators None0 Dec 17 01:17 ..
> -rw---  1 Administrators None   26 Dec 17 01:17 sh-thd-1261018730
> -rw---  1 Administrators None   26 Dec 17 01:18 sh-thd-1261013343
> -rw-r--r--  1 Administrators None0 Dec 17 01:18 foobar
> -rw-r--r--  1 Administrators None  866 Dec 17 01:19 bar
> -rw---  1 Administrators None 2023 Dec 17 01:20 sh-thd-3715808728
> -rw---  1 Administrators None0 Dec 17 01:20 sh-thd-1261024743
> -rw---  1 Administrators None   26 Dec 17 01:27 sh-thd-1261038942
> -rw---  1 Administrators None0 Dec 17 01:28 sh-thd-1261038922
> drwxrwxrwt+ 1 Administrators None0 Dec 17 01:28 .
> 
> da...@winxp2 ~
> $

  I think the strace suggests where the problem lies:

>   350  519655 [main] bash 680 open: 3 = open (/tmp/sh-thd-1261038922, 0x10E01)
   [ ... snip ... ]
>   517  535090 [main] bash 680 open: 4 = open (/tmp/sh-thd-1261038922, 0x1)
>   454  535544 [main] bash 680 close: close (3)
>   476  536020 [main] bash 680 fhandler_base::close: closing 
> '/tmp/sh-thd-1261038922' handle 0x6A4
>   679  536699 [main] bash 680 close: 0 = close (3)
>   563  537262 [main] bash 680 normalize_posix_path: src /tmp/sh-thd-1261038922
>   605  537867 [main] bash 680 normalize_posix_path: /tmp/sh-thd-1261038922 = 
> normalize_posix_path (/tmp/sh-thd-1261038922)
>   449  538316 [main] bash 680 mount_info::conv_to_win32_path: 
> conv_to_win32_path (/tmp/sh-thd-1261038922)
>   571  538887 [main] bash 680 set_flags: flags: binary (0x2)
>   806  539693 [main] bash 680 mount_info::conv_to_win32_path: src_path 
> /tmp/sh-thd-1261038922, dst Z:\cygremotewin2\tmp\sh-thd-1261038922, flags 
> 0x3000A, rc 0
>  1641  541334 [main] bash 680 symlink_info::check: not a symlink
>  1003  542337 [main] bash 680 symlink_info::check: 0 = symlink.check 
> (Z:\cygremotewin2\tmp\sh-thd-1261038922, 0x22B5E8) (0x3000A)
>   466  542803 [main] bash 680 path_conv::check: 
> this->path(Z:\cygremotewin2\tmp\sh-thd-1261038922), has_acls(1)
>   547  543350 [main] bash 680 seterrno_from_win_error: 
> /ext/build/netrel/src/cygwin-1.7.0-62/winsup/cygwin/syscalls.cc:674 windows 
> error 32
>   496  543846 [main] bash 680 geterrno_from_win_error: windows error 32 == 
> errno 16
>   449  544295 [main] bash 680 __set_errno: void seterrno_from_win_error(const 
> char*, int, DWORD):319 val 16
>   433  544728 [main] bash 680 unlink: -1 = unlink (/tmp/sh-thd-1261038922)
>   740  545468 [main] bash 680 close: close (4)
>   498  545966 [main] bash 680 fhandler_base::close: closing 
> '/tmp/sh-thd-1261038922' handle 0x6A0
>  1121  547087 [main] bash 680 close: 0 = close (4)

  It looks like the unlink-while-you-still-have-an-open-handle-to-the-file
trick isn't working on SMB mounts, perhaps?

cheers,
  DaveK




Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...

2009-12-16 Thread Christopher Faylor
On Wed, Dec 16, 2009 at 06:18:38PM +0100, Corinna Vinschen wrote:
>But we discussed this on the developers list.  The old setup will be
>setup-legacy.exe and setup.exe is only for 1.7 and later.  I'm rather
>puzzled that you want to change this again.  I have matching local
>changes to the web page waiting.  Please don't change this again.

Since I have to change source code to understand the "release-legacy"
directory, I opted to just do it in the trunk rather than the ancient
setup 1.5 branch.  There will still be a setup-legacy binary.

cgf


Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...

2009-12-16 Thread Andy Koppe
2009/12/16 Corinna Vinschen:
> But we discussed this on the developers list.  The old setup will be
> setup-legacy.exe and setup.exe is only for 1.7 and later.

Does setup.exe have the warning about upgrading from 1.5 to 1.7 that
Dave had suggested?

Andy


Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...

2009-12-16 Thread Corinna Vinschen
On Dec 16 12:09, Christopher Faylor wrote:
> On Wed, Dec 16, 2009 at 05:37:27PM +0100, Corinna Vinschen wrote:
> >On Dec 16 11:16, Christopher Faylor wrote:
> >> On Wed, Dec 16, 2009 at 09:56:11AM +0100, Corinna Vinschen wrote:
> >> >> Changes by: c...@ouch   2009-12-13 19:23:43
> >> 
> >> Ouch.
> >
> >Ouch.
> >
> >> >There's actually no package_message.h file in the repository.  Could
> >> >you please check it in?
> >> 
> >> I've checked it in.
> >
> >Thanks.
> >
> >> >Btw., is setup finished for the 1.7.1 release with this patch or is
> >> >there more to come?
> >> 
> >> There is more to come.  I have found a problem with the latest setup.exe
> >> when running on Windows 9x that I still need to fix.  And, I have the
> >
> >On 9x?!?  I applied a patch a couple of days ago so that the new setup
> >won't run on 9x anymore.  It just shows a message box.
> 
> Yes, I saw that.  It was rather puzzling given our private email
> discussion where I advocated for making the trunk setup NT-only and you
> indicated that it was supposed to work.
> 
> Part of my pending changes resurrect 9x support so that we can use one
> binary for legacy and regular cygwin installations.

But we discussed this on the developers list.  The old setup will be
setup-legacy.exe and setup.exe is only for 1.7 and later.  I'm rather
puzzled that you want to change this again.  I have matching local
changes to the web page waiting.  Please don't change this again.


Corinna

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


Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...

2009-12-16 Thread Christopher Faylor
On Wed, Dec 16, 2009 at 05:37:27PM +0100, Corinna Vinschen wrote:
>On Dec 16 11:16, Christopher Faylor wrote:
>> On Wed, Dec 16, 2009 at 09:56:11AM +0100, Corinna Vinschen wrote:
>> >> Changes by:   c...@ouch   2009-12-13 19:23:43
>> 
>> Ouch.
>
>Ouch.
>
>> >There's actually no package_message.h file in the repository.  Could
>> >you please check it in?
>> 
>> I've checked it in.
>
>Thanks.
>
>> >Btw., is setup finished for the 1.7.1 release with this patch or is
>> >there more to come?
>> 
>> There is more to come.  I have found a problem with the latest setup.exe
>> when running on Windows 9x that I still need to fix.  And, I have the
>
>On 9x?!?  I applied a patch a couple of days ago so that the new setup
>won't run on 9x anymore.  It just shows a message box.

Yes, I saw that.  It was rather puzzling given our private email
discussion where I advocated for making the trunk setup NT-only and you
indicated that it was supposed to work.

Part of my pending changes resurrect 9x support so that we can use one
binary for legacy and regular cygwin installations.

cgf


Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...

2009-12-16 Thread Corinna Vinschen
On Dec 16 11:16, Christopher Faylor wrote:
> On Wed, Dec 16, 2009 at 09:56:11AM +0100, Corinna Vinschen wrote:
> >> Changes by:c...@ouch   2009-12-13 19:23:43
> 
> Ouch.

Ouch.

> >There's actually no package_message.h file in the repository.  Could
> >you please check it in?
> 
> I've checked it in.

Thanks.

> >Btw., is setup finished for the 1.7.1 release with this patch or is
> >there more to come?
> 
> There is more to come.  I have found a problem with the latest setup.exe
> when running on Windows 9x that I still need to fix.  And, I have the

On 9x?!?  I applied a patch a couple of days ago so that the new setup
won't run on 9x anymore.  It just shows a message box.


Corinna

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


Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...

2009-12-16 Thread Christopher Faylor
On Wed, Dec 16, 2009 at 09:56:11AM +0100, Corinna Vinschen wrote:
>Hi Chris,
>
>On Dec 13 19:23, c...@sourceware.org wrote:
>> CVSROOT: /cvs/cygwin-apps
>> Module name: setup
>> Changes by:  c...@ouch   2009-12-13 19:23:43

Ouch.

>There's actually no package_message.h file in the repository.  Could
>you please check it in?

I've checked it in.

>Btw., is setup finished for the 1.7.1 release with this patch or is
>there more to come?

There is more to come.  I have found a problem with the latest setup.exe
when running on Windows 9x that I still need to fix.  And, I have the
changes which remove the "release-2" from the sources waiting for when
release-2 actually goes away.

cgf


Re: general setup.exe status incl network install [was Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...]

2009-12-16 Thread Corinna Vinschen
On Dec 16 14:24, Dave Korn wrote:
>   I gave it a try and produced an oddity, although possibly just as an
> artifact of the way I did it: instead of creating a share, I mapped the
> default admin //sever/I$ share of my main PC as Z: over SMB from inside a VM
> and installed it to that drive.  Everything appeared to go OK during
> setup.exe, but in fact the /tmp dir got created with a bad ACL making it
> unwritable, and as a consequnce I got shell failures during the postinstall
> scripts and when running the base-files initial setup; you can't create here
> docs if the /tmp dir is r-o.

Did the tmp dir get created with the below ACL?  If so, it's not R/O.
it looks perfectly reasonable for a directory created with 01777
permissions.  That's what is done for /tmp in install.cc.

> > C:\Documents and Settings\Administrator>cacls i:\cygremotewin\tmp
> > i:\cygremotewin\tmp BUILTIN\Administrators:F

Full access for admins.

> > UBIK\None:(special access:)
> >   READ_CONTROL
> >   SYNCHRONIZE
> >   FILE_GENERIC_READ
> >   FILE_GENERIC_WRITE
> >   FILE_GENERIC_EXECUTE
> >   FILE_READ_DATA
> >   FILE_WRITE_DATA
> >   FILE_APPEND_DATA
> >   FILE_READ_EA
> >   FILE_WRITE_EA
> >   FILE_EXECUTE
> >   FILE_READ_ATTRIBUTES
> >   FILE_WRITE_ATTRIBUTES
> > 
> > Everyone:(special access:)
> >  READ_CONTROL
> >  SYNCHRONIZE
> >  FILE_GENERIC_READ
> >  FILE_GENERIC_WRITE
> >  FILE_GENERIC_EXECUTE
> >  FILE_READ_DATA
> >  FILE_WRITE_DATA
> >  FILE_APPEND_DATA
> >  FILE_READ_EA
> >  FILE_WRITE_EA
> >  FILE_EXECUTE
> >  FILE_READ_ATTRIBUTES
> >  FILE_WRITE_ATTRIBUTES
> > 
> > (special access:)
> >   FILE_READ_DATA

See below.

> > CREATOR OWNER:(OI)(CI)(IO)F

Full access for creator-owner for subsequently created objects.

> > CREATOR GROUP:(OI)(CI)(IO)(special access:)
> >   READ_CONTROL
> >   SYNCHRONIZE
> >   FILE_GENERIC_READ
> >   FILE_GENERIC_WRITE
> >   FILE_GENERIC_EXECUTE
> >   FILE_READ_DATA
> >   FILE_WRITE_DATA
> >   FILE_APPEND_DATA
> >   FILE_READ_EA
> >   FILE_WRITE_EA
> >   FILE_EXECUTE
> >   FILE_READ_ATTRIBUTES
> >   FILE_WRITE_ATTRIBUTES
> > 
> > Everyone:(OI)(CI)(IO)(special access:)
> >  READ_CONTROL
> >  SYNCHRONIZE
> >  FILE_GENERIC_READ
> >  FILE_GENERIC_WRITE
> >  FILE_GENERIC_EXECUTE
> >  FILE_READ_DATA
> >  FILE_WRITE_DATA
> >  FILE_APPEND_DATA
> >  FILE_READ_EA
> >  FILE_WRITE_EA
> >  FILE_EXECUTE
> >  FILE_READ_ATTRIBUTES
> >  FILE_WRITE_ATTRIBUTES
> 
>   Hmm, what?  That thing that says "Account Domain not found" shows up in the
> explorer properties dialog security tab as "S-1-0-0", or if I run the cacls
> command from the VM guest side, it is described as "NULL SID", which is
> probably because the VM is XP and the host is 2k and MS only made cacls.exe
> smart enough to recognize the null sid in the XP version, but that doesn't
> explain what it's doing there in the first place!
> 
>   Does this symptom suggest any possibilities to anyone?

Unfortunately not.  It's really officially the NULL SID.  The NULL SID
ACE is created when at least one of the 

general setup.exe status incl network install [was Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...]

2009-12-16 Thread Dave Korn
Corinna Vinschen wrote:

> 
> Btw., is setup finished for the 1.7.1 release with this patch or is
> there more to come?

  Can't speak for cgf, but from my side, I've got all my new features done.  I
just discovered YA loop-retrying-forever-in-unattended mode bug, which I'll
spin up a patch for shortly, but I don't think it's terribly critical as it'll
only happen if there's a corrupt mirror, which is an uncommon enough occurrence.

  Also I think it would be nice if we could figure out what's going on with
Thomas' network install in the time remaining, but I don't think we should
delay the release any for it.

  I gave it a try and produced an oddity, although possibly just as an
artifact of the way I did it: instead of creating a share, I mapped the
default admin //sever/I$ share of my main PC as Z: over SMB from inside a VM
and installed it to that drive.  Everything appeared to go OK during
setup.exe, but in fact the /tmp dir got created with a bad ACL making it
unwritable, and as a consequnce I got shell failures during the postinstall
scripts and when running the base-files initial setup; you can't create here
docs if the /tmp dir is r-o.

  I haven't yet figured out what exactly went wrong, but one clue is that -
now looking at the created dirs on my main box where they appeared on the I:
drive - the ACL of the /tmp dir is weird.  Here for comparison is the ACL of
the /usr dir, seen from the host (remote) side:

> C:\Documents and Settings\Administrator>cacls i:\cygremotewin\usr
> i:\cygremotewin\usr BUILTIN\Administrators:F
> UBIK\None:R
> Everyone:R
> CREATOR OWNER:(OI)(CI)(IO)F
> CREATOR GROUP:(OI)(CI)(IO)R
> Everyone:(OI)(CI)(IO)R

  Here's how setup.exe created the /tmp dir:

> 
> C:\Documents and Settings\Administrator>cacls i:\cygremotewin\tmp
> i:\cygremotewin\tmp BUILTIN\Administrators:F
> UBIK\None:(special access:)
>   READ_CONTROL
>   SYNCHRONIZE
>   FILE_GENERIC_READ
>   FILE_GENERIC_WRITE
>   FILE_GENERIC_EXECUTE
>   FILE_READ_DATA
>   FILE_WRITE_DATA
>   FILE_APPEND_DATA
>   FILE_READ_EA
>   FILE_WRITE_EA
>   FILE_EXECUTE
>   FILE_READ_ATTRIBUTES
>   FILE_WRITE_ATTRIBUTES
> 
> Everyone:(special access:)
>  READ_CONTROL
>  SYNCHRONIZE
>  FILE_GENERIC_READ
>  FILE_GENERIC_WRITE
>  FILE_GENERIC_EXECUTE
>  FILE_READ_DATA
>  FILE_WRITE_DATA
>  FILE_APPEND_DATA
>  FILE_READ_EA
>  FILE_WRITE_EA
>  FILE_EXECUTE
>  FILE_READ_ATTRIBUTES
>  FILE_WRITE_ATTRIBUTES
> 
> (special access:)
>   FILE_READ_DATA
> 
> CREATOR OWNER:(OI)(CI)(IO)F
> CREATOR GROUP:(OI)(CI)(IO)(special access:)
>   READ_CONTROL
>   SYNCHRONIZE
>   FILE_GENERIC_READ
>   FILE_GENERIC_WRITE
>   FILE_GENERIC_EXECUTE
>   FILE_READ_DATA
>   FILE_WRITE_DATA
>   FILE_APPEND_DATA
>   FILE_READ_EA
>   FILE_WRITE_EA
>   FILE_EXECUTE
>   FILE_READ_ATTRIBUTES
>   FILE_WRITE_ATTRIBUTES
> 
> Everyone:(OI)(CI)(IO)(special access:)
>  READ_CONTROL
>  SYNCHRONIZE
>  FILE_GENERIC_READ
>  FILE_GENERIC_WRITE
>  FILE_GENERIC_EXECUTE
>  FILE_READ_DATA
>  FILE_WRITE_DATA
>  FILE_APPEND_DATA
>  FILE_READ_EA
>  FILE_WRITE_EA

Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...

2009-12-16 Thread Corinna Vinschen
Hi Chris,

On Dec 13 19:23, c...@sourceware.org wrote:
> CVSROOT:  /cvs/cygwin-apps
> Module name:  setup
> Changes by:   c...@sourceware.org 2009-12-13 19:23:43
> 
> Modified files:
>   .  : ChangeLog IniDBBuilder.h IniDBBuilderPackage.cc 
>IniDBBuilderPackage.h PickPackageLine.cc 
>PickView.cc install.cc package_meta.cc 
>prereq.cc package_version.cc package_version.h 
>package_meta.h inilex.ll iniparse.yy 
> 
> Log message:
>   * IniDBBuilder.h (buildMessage): Define for base class.
>   * IniDBBuilderPackage.cc (IniDBBuilderPackage::buildMessage): Define.
>   * IniDBBuilderPackage.h (IniDBBuilderPackage::buildMessage): Declare.
>   * PickPackageLine.cc: Pass pointer to package to "pick" throughout, 
> where
>   appropriate.
>   * PickView.cc: Ditto.
>   * install.cc: Ditto.
>   * package_meta.cc: Ditto.
>   * prereq.cc: Ditto.
>   * package_version.cc: Ditto.
>   (packageversion::pick): Add pkg pointer as second argument.  Display 
> message
>   where appropriate.
>   * package_version.h (packageversion::pick): Add pkg pointer as second 
> argument.
>   * package_meta.h (packagemeta::mesage): Define.
>   (packagemeta::set_message): Define.
>   * inilex.ll: Properly return MESSAGE token.
>   * iniparse.yy: Handle message: keyword.

This patch seems to be incomplete.  Trying to build setup now results in
an error:

  In file included from choose.h:21,
   from choose.cc:51:
  package_meta.h:27:29: package_message.h: No such file or directory
  In file included from choose.h:21,
  from choose.cc:51:
  package_meta.h:146: error: `packagemessage' does not name a type
  package_meta.h: In member function `void packagemeta::set_message(const 
std::string&, const std::string&)':
  package_meta.h:91: error: `message' undeclared (first use this function)
  package_meta.h:91: error: (Each undeclared identifier is reported only once 
for each function it appears in.)
  make[2]: *** [choose.o] Error 1

There's actually no package_message.h file in the repository.  Could
you please check it in?

Btw., is setup finished for the 1.7.1 release with this patch or is
there more to come?


Corinna

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