Re: gcc4-core PACKAGE BUG
On 13/08/2010 20:29, Corinna Vinschen wrote: On Aug 13 20:31, Dave Korn wrote: On 08/08/2010 17:26, Corinna Vinschen wrote: Hi Dave, testing with the latest setup.exe I came across an error message in postinstall: gcc4-core.sh, exit code 126 Manuall testing turned up that the script /usr/sbin/fix-libtool-scripts-for-latest-gcc-runtimes.sh is not executable. Yep, I was aware of that, and have explained it on the list whenever it's come up, but now we've got a requester I'll have to fix it properly. I'll do a respin 4.3.4-4 over the weekend or so. Cool, thank you. Come to think of it, wouldn't it be better to just update 4.3.4-3 in place (i.e. without a version bump)? It seems a bit much to force everyone who's already got it installed to redownload that many megabytes just for the sake of a couple of 'x' bits. cheers, DaveK
Re: gcc4-core PACKAGE BUG
On 08/14/2010 12:17 PM, Dave Korn wrote: Come to think of it, wouldn't it be better to just update 4.3.4-3 in place (i.e. without a version bump)? It seems a bit much to force everyone who's already got it installed to redownload that many megabytes just for the sake of a couple of 'x' bits. No, that would only work for people who haven't downloaded it yet, or who explicitly reinstall. A version bump seems like the best way to ensure it gets picked up without any effort on the user's part. Too bad we don't have anything comparable to yum's presto mode that makes delta downloading easier for simple things like adding an x bit. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: gcc4-core PACKAGE BUG
On 14/08/2010 19:19, Eric Blake wrote: On 08/14/2010 12:17 PM, Dave Korn wrote: Come to think of it, wouldn't it be better to just update 4.3.4-3 in place (i.e. without a version bump)? It seems a bit much to force everyone who's already got it installed to redownload that many megabytes just for the sake of a couple of 'x' bits. No, that would only work for people who haven't downloaded it yet, or who explicitly reinstall. Yes, that's the point. The main motivation for the update at all is to stop setup.exe reporting an error in the postinstall script stage. Anyone who's already got it installed isn't going to be bothered by that and would be inconvenienced by being forced to redownload the whole thing just in order to run a script. A version bump seems like the best way to ensure it gets picked up without any effort on the user's part. Too bad we don't have anything comparable to yum's presto mode that makes delta downloading easier for simple things like adding an x bit. I don't think actually fixing the x bit is that important, it's just the scary-and-offputting-to-noobs setup.exe error that needs fixing. As for the actual script itself, I think that anyone who's already got GCC installed and has been running it probably isn't bothered by the problem. I've had to mention it maybe half a dozen times on the list, but haven't had any new reports in ages. It's simple enough to tell folks to chmod or source it manually. So I really don't think it's worth the end-user's while in this instance, but I'd like to hear what Corinna and cgf think before I proceed. cheers, DaveK
Re: gcc4-core PACKAGE BUG
On Sat, Aug 14, 2010 at 08:05:00PM +0100, Dave Korn wrote: So I really don't think it's worth the end-user's while in this instance, but I'd like to hear what Corinna and cgf think before I proceed. I'm with you on this, Dave. Your reasonsing seems right to me. I don't normally like to make silent changes to existing packages but in this case it seems like the least intrusive way to fix the problem. I wouldn't even announce the change since that would probably generate some confusion. cgf
Re: gcc4-core PACKAGE BUG
On 08/14/2010 01:13 PM, Christopher Faylor wrote: On Sat, Aug 14, 2010 at 08:05:00PM +0100, Dave Korn wrote: So I really don't think it's worth the end-user's while in this instance, but I'd like to hear what Corinna and cgf think before I proceed. I'm with you on this, Dave. Your reasonsing seems right to me. I don't normally like to make silent changes to existing packages but in this case it seems like the least intrusive way to fix the problem. I wouldn't even announce the change since that would probably generate some confusion. My only worry now is if any mirrors will have a stale checksum that doesn't correspond to the new tarball. But I'm convinced that it's worth trying the silent upgrade, now. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: gcc4-core PACKAGE BUG
On Sat, Aug 14, 2010 at 01:15:20PM -0600, Eric Blake wrote: On 08/14/2010 01:13 PM, Christopher Faylor wrote: On Sat, Aug 14, 2010 at 08:05:00PM +0100, Dave Korn wrote: So I really don't think it's worth the end-user's while in this instance, but I'd like to hear what Corinna and cgf think before I proceed. I'm with you on this, Dave. Your reasonsing seems right to me. I don't normally like to make silent changes to existing packages but in this case it seems like the least intrusive way to fix the problem. I wouldn't even announce the change since that would probably generate some confusion. My only worry now is if any mirrors will have a stale checksum that doesn't correspond to the new tarball. But I'm convinced that it's worth trying the silent upgrade, now. That's a good point. Dave, when you make the change, please remove any md5.sum in that directory. That will force the file to be regenerated and upset will do the right thing if it isn't there. cgf
Re: gcc4-core PACKAGE BUG
On Sat, Aug 14, 2010 at 03:20:40PM -0400, Christopher Faylor wrote: On Sat, Aug 14, 2010 at 01:15:20PM -0600, Eric Blake wrote: On 08/14/2010 01:13 PM, Christopher Faylor wrote: On Sat, Aug 14, 2010 at 08:05:00PM +0100, Dave Korn wrote: So I really don't think it's worth the end-user's while in this instance, but I'd like to hear what Corinna and cgf think before I proceed. I'm with you on this, Dave. Your reasonsing seems right to me. I don't normally like to make silent changes to existing packages but in this case it seems like the least intrusive way to fix the problem. I wouldn't even announce the change since that would probably generate some confusion. My only worry now is if any mirrors will have a stale checksum that doesn't correspond to the new tarball. But I'm convinced that it's worth trying the silent upgrade, now. That's a good point. Dave, when you make the change, please remove any md5.sum in that directory. That will force the file to be regenerated and upset will do the right thing if it isn't there. To be clear: that directory == /sourceware/ftp/anonftp/pub/cygwin/release/gcc4/... cgf
Re: gcc4-core PACKAGE BUG
On 08/08/2010 17:26, Corinna Vinschen wrote: Hi Dave, testing with the latest setup.exe I came across an error message in postinstall: gcc4-core.sh, exit code 126 Manuall testing turned up that the script /usr/sbin/fix-libtool-scripts-for-latest-gcc-runtimes.sh is not executable. Yep, I was aware of that, and have explained it on the list whenever it's come up, but now we've got a requester I'll have to fix it properly. I'll do a respin 4.3.4-4 over the weekend or so. cheers, DaveK
Re: gcc4-core PACKAGE BUG
On Aug 13 20:31, Dave Korn wrote: On 08/08/2010 17:26, Corinna Vinschen wrote: Hi Dave, testing with the latest setup.exe I came across an error message in postinstall: gcc4-core.sh, exit code 126 Manuall testing turned up that the script /usr/sbin/fix-libtool-scripts-for-latest-gcc-runtimes.sh is not executable. Yep, I was aware of that, and have explained it on the list whenever it's come up, but now we've got a requester I'll have to fix it properly. I'll do a respin 4.3.4-4 over the weekend or so. Cool, thank you. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
gcc4-core PACKAGE BUG
Hi Dave, testing with the latest setup.exe I came across an error message in postinstall: gcc4-core.sh, exit code 126 Manuall testing turned up that the script /usr/sbin/fix-libtool-scripts-for-latest-gcc-runtimes.sh is not executable. Either /etc/postinstall/gcc4-core.sh should call the script like this: sh /usr/sbin/fix-libtool-scripts-for-latest-gcc-runtimes.sh or the script should be executable. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
