Re: Apache/PHP maintainership
On Thu, Jan 27, 2005 at 01:37:40AM +0100, Stipe Tolj wrote: Corinna Vinschen wrote: On Jan 24 23:55, Brian Dessent wrote: So, unfortunately I throw in the towel on this one. I think I've posted the patches to this list that I had made, which would be a starting point if anyone else feels up to the task. At the point where I stopped, the PHP modules would at least all build as dynamic shared modules but some of them would not load or would cause segfaults. So, there's still some work to be done there to find out why. Are you also laying down Apache maintainership? That would be a pity. I don't see why Apache should depend on PHP. Webserver also work fine without PHP scripts from what I can tell :-) now, agree'ing to Corinna here. As I am still on the list and yes, still work on Apache for Cygwin... I'd like to pick-up the opportunity to bring up some new packages with the apache-1.3 tree and the httpd-2.0 tree - on which I worked already in trying to get it build in DSO/DLL fashion mode - for upload. At least re-building the latest apache-1.3 should be a very quick shot to go for. I've checked with Corinna on this. We are not interested in taking you up on this offer. Thank you. cgf
Re: Setup: hardlinks percentages. (+patches)
Bas van Gompel wrote: 2005-01-07 Bas van Gompel [EMAIL PROTECTED] * archive.cc (archive::extract_file): Use prefixPath for linktarget on hardlinks. --- setup/archive.cc 25 Dec 2004 23:05:56 - 2.10 +++ setup/archive.cc 7 Jan 2005 20:39:42 - @@ -161,7 +161,7 @@ archive::extract_file (archive * source, io_stream::remove (destfilename); int ok = io_stream::mklink (destfilename, - prefixURL + source-linktarget (), + prefixURL + prefixPath + source-linktarget (), IO_STREAM_HARDLINK); /* FIXME: check what tar's filelength is set to for hardlinks */ source-skip_file (); I agree something is wrong here, but there are the following issues to consider: A copy/paste of virtually the same code above deals with symlinks. Presumably that needs fixing too. Also, might we need to handle relative and absolute linktarget paths differently here? 2005-01-07 Bas van Gompel [EMAIL PROTECTED] * ini.cc (class GuiParseFeedback): change type of lastpct. Applied, thanks. (With slight changes to log message.) Max.
wget postinstall and setup
The wget postinstall is doing a cp. As discussed earlier, a cp does not preserve the ACL and any cp done in a postinstall script must be accompanied by a touch to create the new file before copying unto it (see e.g. as in man.sh), or a chmod to set reasonable permissions after the copying (e.g. as in openldap.sh). If that's not done, the user may end up having unreadable files. Sorry I didn't notice that earlier. It's a pain to have to impose this to all package maintainers. It would be much better to set CYGWIN=nontsec from setup.exe while running the postinstall scripts. The only scripts that need to chown or chmod files are those related to services (cron, exim,...). Their maintainers are well aware of that. They should set CYGWIN=ntsec. Pierre
Re: wget postinstall and setup
On Thu, Jan 27, 2005 at 01:31:01PM -0500, Pierre A. Humblet wrote: The wget postinstall is doing a cp. As discussed earlier, a cp does not preserve the ACL and any cp done in a postinstall script must be accompanied by a touch to create the new file before copying unto it (see e.g. as in man.sh), or a chmod to set reasonable permissions after the copying (e.g. as in openldap.sh). If that's not done, the user may end up having unreadable files. Sorry I didn't notice that earlier. Wouldt cp -p not do the right thing in this case? cgf
Re: wget postinstall and setup
Pierre A. Humblet schrieb: The wget postinstall is doing a cp. As discussed earlier, a cp does not preserve the ACL and any cp done in a postinstall script must be accompanied by a touch to create the new file before copying unto it (see e.g. as in man.sh), or a chmod to set reasonable permissions after the copying (e.g. as in openldap.sh). If that's not done, the user may end up having unreadable files. Sorry I didn't notice that earlier. /bin/install -m MODE also from coreutils is IMHO easier. It's a pain to have to impose this to all package maintainers. It would be much better to set CYGWIN=nontsec from setup.exe while running the postinstall scripts. The only scripts that need to chown or chmod files are those related to services (cron, exim,...). Their maintainers are well aware of that. They should set CYGWIN=ntsec. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/
Re: wget postinstall and setup
Christopher Faylor wrote:
On Thu, Jan 27, 2005 at 01:31:01PM -0500, Pierre A. Humblet wrote:
The wget postinstall is doing a cp. As discussed earlier, a cp does
not preserve the ACL and any cp done in a postinstall script must be
accompanied by a touch to create the new file before copying unto it
(see e.g. as in man.sh), or a chmod to set reasonable permissions
after the copying (e.g. as in openldap.sh). If that's not done, the
user may end up having unreadable files. Sorry I didn't notice that
earlier.
Wouldt cp -p not do the right thing in this case?
Nope. The issue (there is an old thread) is that the relevant access
rights in the original file are in special acl entries, not in
owner/group/world. Unix tools don't copy them.
With nontsec, the script uses the Windows default, which is always
OK (see below).
Using install -m would work, but it's again imposing a constraint
on all maintainers. Another drawback of {touch, chmod, install}
is that you end up with file permissions that are different from
the files installed by setup, possibly leading to problems during
uninstall.
There is no drawback using nontsec because that's how all other
files were installed in the first place.
Pierre
Re: wget postinstall and setup (MAXB please take note)
On Thu, Jan 27, 2005 at 02:07:13PM -0500, Pierre A. Humblet wrote:
Christopher Faylor wrote:
On Thu, Jan 27, 2005 at 01:31:01PM -0500, Pierre A. Humblet wrote:
The wget postinstall is doing a cp. As discussed earlier, a cp does
not preserve the ACL and any cp done in a postinstall script must be
accompanied by a touch to create the new file before copying unto it
(see e.g. as in man.sh), or a chmod to set reasonable permissions
after the copying (e.g. as in openldap.sh). If that's not done, the
user may end up having unreadable files. Sorry I didn't notice that
earlier.
Wouldt cp -p not do the right thing in this case?
Nope. The issue (there is an old thread) is that the relevant access
rights in the original file are in special acl entries, not in
owner/group/world. Unix tools don't copy them.
With nontsec, the script uses the Windows default, which is always
OK (see below).
Using install -m would work, but it's again imposing a constraint
on all maintainers. Another drawback of {touch, chmod, install}
is that you end up with file permissions that are different from
the files installed by setup, possibly leading to problems during
uninstall.
There is no drawback using nontsec because that's how all other
files were installed in the first place.
maxb -- can we consider this a needed urgent fix? This is a
long-standing problem which is causing people a lot of problems.
cgf
Re: wget postinstall and setup (MAXB please take note)
Christopher Faylor wrote: On Thu, Jan 27, 2005 at 02:07:13PM -0500, Pierre A. Humblet wrote: There is no drawback using nontsec because that's how all other files were installed in the first place. maxb -- can we consider this a needed urgent fix? This is a long-standing problem which is causing people a lot of problems. Just to confirm: The decision is that setup will set CYGWIN=nontsec and it is the responsibility of maintainers who need ntsec in postinstall scripts to explicitly enable it. Sounds easy - just add a putenv(CYGWIN=nontsec) in main(). Do I wait a few days to allow the maintainers to check/change their postinstalls, or do I release a new setup tonight? BTW, the permissions on setup.exe on sourceware are such that only you can change it. If accidental, could you fix, so I can release a new setup myself? Thanks, Max.
Re: wget postinstall and setup (MAXB please take note)
On Thu, Jan 27, 2005 at 07:40:28PM -, Max Bowsher wrote: Do I wait a few days to allow the maintainers to check/change their postinstalls, or do I release a new setup tonight? It doesn't sound like there's any reason to wait. BTW, the permissions on setup.exe on sourceware are such that only you can change it. If accidental, could you fix, so I can release a new setup myself? It is not accidental. It's a side effect of upset parsing. Just tell me where to get the updated setup.exe and I'll install it. cgf
Re: wget postinstall and setup (MAXB please take note)
Hi guys, Sorry for busting in... Wouldn't putenv(CYGWIN=nontsec) possibly override a user's own CYGWIN environment variable (I always set mine under HKLM) Wouldn't it be preferable to check the existence of the CYGWIN environment variable and simply append nontsec in this case? my 2 cents. JST On Thu, Jan 27, 2005 at 02:50:23PM -0500, Christopher Faylor wrote: On Thu, Jan 27, 2005 at 07:40:28PM -, Max Bowsher wrote: Do I wait a few days to allow the maintainers to check/change their postinstalls, or do I release a new setup tonight? It doesn't sound like there's any reason to wait. BTW, the permissions on setup.exe on sourceware are such that only you can change it. If accidental, could you fix, so I can release a new setup myself? It is not accidental. It's a side effect of upset parsing. Just tell me where to get the updated setup.exe and I'll install it. cgf
Re: wget postinstall and setup (MAXB please take note)
Christopher Faylor wrote: On Thu, Jan 27, 2005 at 07:40:28PM -, Max Bowsher wrote: Do I wait a few days to allow the maintainers to check/change their postinstalls, or do I release a new setup tonight? It doesn't sound like there's any reason to wait. BTW, the permissions on setup.exe on sourceware are such that only you can change it. If accidental, could you fix, so I can release a new setup myself? It is not accidental. It's a side effect of upset parsing. Just tell me where to get the updated setup.exe and I'll install it. Ready for: mv setup-2.457.2.2.exe setup.exe Max.
Re: wget postinstall and setup (MAXB please take note)
Jean-Sebastien Trottier wrote: Hi guys, Sorry for busting in... Wouldn't putenv(CYGWIN=nontsec) possibly override a user's own CYGWIN environment variable (I always set mine under HKLM) Wouldn't it be preferable to check the existence of the CYGWIN environment variable and simply append nontsec in this case? This is only for running postinstall scripts. So I don't think it matters. Max.
Re: wget postinstall and setup (MAXB please take note)
On Thu, Jan 27, 2005 at 09:25:31PM -, Max Bowsher wrote: Christopher Faylor wrote: On Thu, Jan 27, 2005 at 07:40:28PM -, Max Bowsher wrote: Do I wait a few days to allow the maintainers to check/change their postinstalls, or do I release a new setup tonight? It doesn't sound like there's any reason to wait. BTW, the permissions on setup.exe on sourceware are such that only you can change it. If accidental, could you fix, so I can release a new setup myself? It is not accidental. It's a side effect of upset parsing. Just tell me where to get the updated setup.exe and I'll install it. Ready for: mv setup-2.457.2.2.exe setup.exe Done. I forgot to copy the old file to old, though. I hope that won't be a problem. Thanks for the very quick response. cgf
Re: wget postinstall and setup (MAXB please take note)
Christopher Faylor wrote: On Thu, Jan 27, 2005 at 09:25:31PM -, Max Bowsher wrote: Christopher Faylor wrote: On Thu, Jan 27, 2005 at 07:40:28PM -, Max Bowsher wrote: Do I wait a few days to allow the maintainers to check/change their postinstalls, or do I release a new setup tonight? It doesn't sound like there's any reason to wait. BTW, the permissions on setup.exe on sourceware are such that only you can change it. If accidental, could you fix, so I can release a new setup myself? It is not accidental. It's a side effect of upset parsing. Just tell me where to get the updated setup.exe and I'll install it. Ready for: mv setup-2.457.2.2.exe setup.exe Done. I forgot to copy the old file to old, though. I hope that won't be a problem. There's a copy of it at http://cygwin.com/setup/old/ But the changes are tiny, I can't see any reason for it to be wanted. Thanks for the very quick response. No problem, it was basically a one-liner change. Max.
Re: Setup: hardlinks percentages. (+patches)
Op Thu, 27 Jan 2005 15:06:08 - schreef Max Bowsher in [EMAIL PROTECTED]: : Bas van Gompel wrote: : 2005-01-07 Bas van Gompel [EMAIL PROTECTED] : : * archive.cc (archive::extract_file): Use prefixPath for linktarget : on hardlinks. : : : --- setup/archive.cc 25 Dec 2004 23:05:56 - 2.10 : +++ setup/archive.cc 7 Jan 2005 20:39:42 - : @@ -161,7 +161,7 @@ archive::extract_file (archive * source, : io_stream::remove (destfilename); : int ok = : io_stream::mklink (destfilename, : - prefixURL + source-linktarget (), : + prefixURL + prefixPath + source-linktarget (), :IO_STREAM_HARDLINK); : /* FIXME: check what tar's filelength is set to for hardlinks */ : source-skip_file (); : : I agree something is wrong here, but there are the following issues to : consider: Well, lets consider them, then. : A copy/paste of virtually the same code above deals with symlinks. : Presumably that needs fixing too. That would be wrong. The target for symlinks is stored relative to their position, or absolute, AIUI. : Also, might we need to handle relative and absolute linktarget paths : differently here? That appears not to be needed. All hardlinks are stored relative to the top of the archive AFAICT. Links to outside the stored tree are replaced with copies. To see how this works, consider the following script and output: ===begin script #!/bin/sh cd /tmp mkdir test cd test mkdir outside echo testfile outside/afile1 echo testfile outside/afile2 mkdir inside cd inside echo another testfile afile ln afile link ln -s afile slink ln /tmp/test/inside/afile alink ln -s /tmp/test/inside/afile salink ln ../outside/afile1 xlink ln -s ../outside/afile2 sxlink ln /tmp/test/outside/afile1 axlink ln -s /tmp/test/outside/afile2 saxlink mkdir adir cd adir echo yet another testfile afile ln ../afile link ln -s ../afile slink cd .. ln adir/afile dlink ln -s adir/afile sdlink cd .. ls -Rl tar -jcf test.tar.bz2 inside tar -jtvf test.tar.bz2 cd .. rm -rf test #!/bin/sh cd /tmp mkdir test cd test mkdir outside echo testfile outside/afile mkdir inside cd inside echo another testfile afile ln afile link ln -s afile slink ln /tmp/test/inside/afile alink ln -s /tmp/test/inside/afile salink ln ../outside/afile xlink ln -s ../outside/afile sxlink ln /tmp/test/outside/afile axlink ln -s /tmp/test/outside/afile saxlink mkdir adir cd adir echo yet another testfile afile ln ../afile link ln -s ../afile slink cd .. ln adir/afile dlink ln -s adir/afile sdlink cd .. ls -Rl tar -jcf test.tar.bz2 inside tar -jtvf test.tar.bz2 cd .. rm -rf test ===end script ===atsrt output .: total 0 drwxr-xr-x+ 3 Buzz Geen 0 Jan 28 02:19 inside drwxr-xr-x+ 2 Buzz Geen 0 Jan 28 02:19 outside ./inside: total 11 drwxr-xr-x+ 2 Buzz Geen 0 Jan 28 02:19 adir -rw-r--r-- 4 Buzz Geen 17 Jan 28 02:19 afile -rw-r--r-- 4 Buzz Geen 17 Jan 28 02:19 alink -rw-r--r-- 3 Buzz Geen 9 Jan 28 02:19 axlink -rw-r--r-- 2 Buzz Geen 21 Jan 28 02:19 dlink -rw-r--r-- 4 Buzz Geen 17 Jan 28 02:19 link lrwxrwxrwx 1 Buzz Geen 22 Jan 28 02:19 salink - /tmp/test/inside/afile lrwxrwxrwx 1 Buzz Geen 24 Jan 28 02:19 saxlink - /tmp/test/outside/afile2 lrwxrwxrwx 1 Buzz Geen 10 Jan 28 02:19 sdlink - adir/afile lrwxrwxrwx 1 Buzz Geen 5 Jan 28 02:19 slink - afile lrwxrwxrwx 1 Buzz Geen 17 Jan 28 02:19 sxlink - ../outside/afile2 -rw-r--r-- 3 Buzz Geen 9 Jan 28 02:19 xlink ./inside/adir: total 3 -rw-r--r-- 2 Buzz Geen 21 Jan 28 02:19 afile -rw-r--r-- 4 Buzz Geen 17 Jan 28 02:19 link lrwxrwxrwx 1 Buzz Geen 8 Jan 28 02:19 slink - ../afile ./outside: total 2 -rw-r--r-- 3 Buzz Geen 9 Jan 28 02:19 afile1 -rw-r--r-- 1 Buzz Geen 9 Jan 28 02:19 afile2 drwxr-xr-x Buzz/Geen 0 2005-01-28 02:19:05 inside/ drwxr-xr-x Buzz/Geen 0 2005-01-28 02:19:05 inside/adir/ -rw-r--r-- Buzz/Geen21 2005-01-28 02:19:05 inside/adir/afile -rw-r--r-- Buzz/Geen17 2005-01-28 02:19:05 inside/adir/link lrwxrwxrwx Buzz/Geen 0 2005-01-28 02:19:05 inside/adir/slink - ../afile -rw-r--r-- Buzz/Geen 0 2005-01-28 02:19:05 inside/afile link to inside/adir/link -rw-r--r-- Buzz/Geen 0 2005-01-28 02:19:05 inside/alink link to inside/adir/link -rw-r--r-- Buzz/Geen 9 2005-01-28 02:19:05 inside/axlink -rw-r--r-- Buzz/Geen 0 2005-01-28 02:19:05 inside/dlink link to inside/adir/afile -rw-r--r-- Buzz/Geen 0 2005-01-28 02:19:05 inside/link link to inside/adir/link lrwxrwxrwx Buzz/Geen 0 2005-01-28 02:19:05 inside/salink - /tmp/test/inside/afile lrwxrwxrwx Buzz/Geen 0 2005-01-28 02:19:05 inside/saxlink - /tmp/test/outside/afile2 lrwxrwxrwx Buzz/Geen 0 2005-01-28 02:19:05 inside/sdlink - adir/afile lrwxrwxrwx Buzz/Geen 0 2005-01-28 02:19:05 inside/slink - afile lrwxrwxrwx Buzz/Geen 0 2005-01-28 02:19:05 inside/sxlink - ../outside/afile2 -rw-r--r-- Buzz/Geen 0 2005-01-28 02:19:05 inside/xlink link to inside/axlink ===end output [...] L8r, Buzz.
