--------------------------------------------------------------------- Fedora Update Notification FEDORA-2003-050 2004-01-12 ---------------------------------------------------------------------
Name : gcc Version : 3.3.2 Release : 6 Summary : Various compilers (C, C++, Objective-C, Java, ...) Description : The gcc package contains the GNU Compiler Collection version 3.3.2. You'll need this package in order to compile C code.
--------------------------------------------------------------------- * Fri Jan 09 2004 Jakub Jelinek jakub@redhat.com 3.3.2-6
- update from gcc-3_3-branch - PRs fortran/12632, target/13373, bootstrap/13068, middle-end/13475, target/11576, optimization/13394, c/13382, target/11271, middle-end/13400, optimization/13031, c++/13239, c++/2294, c++/5050, c++/11554, c++/12696, c++/12862, c++/13070, c++/13081, c++/13239, c++/13371, c++/13445, c++/13507, libstdc++/13007 - fix endless loop on AMD64 (#112678, PR optimization/13521) - fix __builtin_expect
* Fri Dec 19 2003 Jakub Jelinek jakub@redhat.com 3.3.2-5
- update from gcc-3_3-branch - PRs target/11992, target/13122, optimization/13037, target/13256, target/12598, optimization/13318, optimization/13060, optimization/12965, target/13354, optimization/4490, target/13150, middle-end/10060, driver/13211, target/13302, target/11322, target/12467, 12969, target/8407, 10239, 11640, c++/12253, c++/13262, c++/13323, fortran/12633, libstdc++/6243, libstdc++/11612, libstdc++/12496, libstdc++/13290, libstdc++/9371, libstdc++/9546, libstdc++/10093, libstdc++/10095 - fix __builtin_expect in C++ code - fix unwinding through SA_ONSTACK signal frames on IA-64
* Fri Dec 12 2003 Jakub Jelinek jakub@redhat.com 3.3.2-4
- fix unwinding through signal frames on IA-64
* Wed Dec 03 2003 Jakub Jelinek jakub@redhat.com 3.3.2-3
- update from gcc-3_3-branch - PRs optimization/11634, other/12505, optimization/13041, target/12900, optimization/12926, optimization/12953, target/12865, optimization/10467, optimization/11741, c++/2094, libobjc/11433, c++/2094, libstdc++/12297, libstdc++/12594 - BuildRequire texinfo (#111168) - Require /sbin/install-info for libgcj (#110904) - fix structure initialization with const fields and mostly zeros in the initializer (#110966) - fix gcj on PPC64 not emitting needed nop after branch and link to non-local Java method (Richard Henderson) - some more > 2GB handling fixes (Jan Hubicka)
* Mon Nov 10 2003 Jakub Jelinek jakub@redhat.com 3.3.2-2
- update from gcc-3_3-branch - PRs bootstrap/12666, target/11598, libgcj/10610, target/12654, target/12690, target/12712 - fix ICE with C++ initializers (Jason Merrill, #109283, PR c++/12726) - fix handling of functions with > 2GB stack frames - fix handling of objects larger than 2GB or 4GB (Jan Hubicka and others) - fix Fortran COMMONs bigger than 2GB (#106542)
--------------------------------------------------------------------- This update can be downloaded from: http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/1/
1941f3b9d7772501b8a0c2dd875cc558 SRPMS/gcc-3.3.2-6.src.rpm 15e765e153a6e4fb4e3cfec6b4cc0f1f i386/gcc-3.3.2-6.i386.rpm 11bfe68770ceebd46e67e0083d2b9c37 i386/libgcc-3.3.2-6.i386.rpm 62607c864d09f641672aa15d6266e0d0 i386/gcc-c++-3.3.2-6.i386.rpm 614432767a1ddd2b6a10620c6a873357 i386/libstdc++-3.3.2-6.i386.rpm 733337e74baedc5354164dbfd57e1f94 i386/libstdc++-devel-3.3.2-6.i386.rpm be5211e412ff386325017f4931918d42 i386/gcc-objc-3.3.2-6.i386.rpm 41bb9cbd9c03dfa4f4e66f0e66cd9cf1 i386/libobjc-3.3.2-6.i386.rpm 30bd3f8e6f1d253a65ed0962b78462db i386/gcc-g77-3.3.2-6.i386.rpm 2948fd2048f5a0704f9eb42435f52c13 i386/libf2c-3.3.2-6.i386.rpm 77da8e2fca1f84646ecb00fe6db8976b i386/gcc-java-3.3.2-6.i386.rpm 68de5143e20d9deb199f63def2005670 i386/libgcj-3.3.2-6.i386.rpm bc3fdc644379747a37aee754c4096aef i386/libgcj-devel-3.3.2-6.i386.rpm 45a5c5aa17fc9871c30610245945b47b i386/cpp-3.3.2-6.i386.rpm 92d8a68253f23fd6e313bfe89e83b8cd i386/gcc-gnat-3.3.2-6.i386.rpm a5ad9c06c6b3bebd38b333d701fd8c04 i386/libgnat-3.3.2-6.i386.rpm ff9fb1d693b68151d9325d2acadb2f7c i386/debug/gcc-debuginfo-3.3.2-6.i386.rpm
This update can also be installed with the Update Agent; you can launch the Update Agent with the 'up2date' command. ---------------------------------------------------------------------
On Mon, 12 Jan 2004 09:40:13 -0500 Jakub Jelinek jakub@redhat.com wrote:
http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/1/
Hi there,
Shouldn't the latest version always be available from:
http://download.fedora.redhat.com/pub/fedora/linux/core/development
Shouldn't the flow of an rpm be something like:
development -> testing -> stable ?
It's hard to keep track of the latest rpm's new ones somtimes skip the first step. For those of us with local mirrors we'll have to mirror _both_ development and testing. Perhaps there is a reason why this particular release didn't appear in the development rpms?
Cheers, Sean
development -> testing -> stable ?
As i remark till now was:
testing ---(1 day to 1 week)---> devel ---> stable.
If i am wrong correct me.
It's hard to keep track of the latest rpm's new ones somtimes skip the first step. For those of us with local mirrors we'll have to mirror _both_ development and testing. Perhaps there is a reason why this particular release didn't appear in the development rpms?
Cheers, Sean
On Mon, Jan 12, 2004 at 11:56:00AM -0500, Sean Estabrooks wrote:
Shouldn't the flow of an rpm be something like:
development -> testing -> stable ?
No. The 'development' packages are built in a rawhide build environment -- you certainly don't want those ending up as stable updates for Fedora Core 1.
Basically a package is either built for testing (and then perhaps moved to stable) *or* for development.
Tim. */
On Mon, Jan 12, 2004 at 05:12:35PM +0000, Tim Waugh wrote:
On Mon, Jan 12, 2004 at 11:56:00AM -0500, Sean Estabrooks wrote:
Shouldn't the flow of an rpm be something like:
development -> testing -> stable ?
No. The 'development' packages are built in a rawhide build environment -- you certainly don't want those ending up as stable updates for Fedora Core 1.
Basically a package is either built for testing (and then perhaps moved to stable) *or* for development.
And in the case of GCC, there are so far no reasons to have different compiler for FC1 updates and development, which means that the package has to be built as FC1 testing and when it becomes FC1 stable it will be automatically inherited into FC2 development.
Jakub
On Mon, 12 Jan 2004 12:19:25 -0500 Jakub Jelinek jakub@redhat.com wrote:
On Mon, Jan 12, 2004 at 05:12:35PM +0000, Tim Waugh wrote:
On Mon, Jan 12, 2004 at 11:56:00AM -0500, Sean Estabrooks wrote:
Shouldn't the flow of an rpm be something like:
development -> testing -> stable ?
No. The 'development' packages are built in a rawhide build environment -- you certainly don't want those ending up as stable updates for Fedora Core 1.
Basically a package is either built for testing (and then perhaps moved to stable) *or* for development.
And in the case of GCC, there are so far no reasons to have different compiler for FC1 updates and development, which means that the package has to be built as FC1 testing and when it becomes FC1 stable it will be automatically inherited into FC2 development.
Jakub,
Thanks for the response. Would it make more sense that FC2 development inherit the package when it goes into testing instead? Development is meant to be most current and isn't garenteed to not break. This should speed up the discovery of any issues. If it's good enough for FC1 testing does it not mean it's good enough for FC2 development?
Thanks, Sean
On Mon, 12 Jan 2004 12:19:25 -0500 Jakub Jelinek jakub@redhat.com wrote:
And in the case of GCC, there are so far no reasons to have different compiler for FC1 updates and development, which means that the package has to be built as FC1 testing and when it becomes FC1 stable it will be automatically inherited into FC2 development.
Jakub,
Ok, bandwidth-be-damned i've setup mirroring for binary and source rpms of both core/testing and core/development from redhat.com.
Would still be interested to hear if you think a change is in order about when rpms are automatically inherited by FC2 development. Don't you think it would be better if it happened at testing time, rather than when moved to stable? Although i do like the notion that we test our rpms _before_ we develop them... That's got to make development easier. ;o)
Sean
On Mon, 2004-01-12 at 17:16, Sean Estabrooks wrote:
Would still be interested to hear if you think a change is in order about when rpms are automatically inherited by FC2 development. Don't you think it would be better if it happened at testing time, rather than when moved to stable? Although i do like the notion that we test our rpms _before_ we develop them... That's got to make development easier. ;o)
I don't think this test/stable and development/rawhide system is setup that way. Testing is for making sure the package works before it is moved to production up2date for the current release. Development/rawhide is for working on the next release, which once a package is working fine for the current one, then it's made to work with the new-to-be release, which will probably have lots of different dependencies/mechanisms, like the 2.6 kernel, newer kde, gnome and so on.
LOL, doubt I'm explaining this correctly, hopefully my point is across at least hehe.
On Mon, 12 Jan 2004 18:55:09 -0600 Mike Chambers mike@netlyncs.com wrote:
I don't think this test/stable and development/rawhide system is setup that way. Testing is for making sure the package works before it is moved to production up2date for the current release. Development/rawhide is for working on the next release, which once a package is working fine for the current one, then it's made to work with the new-to-be release, which will probably have lots of different dependencies/mechanisms, like the 2.6 kernel, newer kde, gnome and so on.
LOL, doubt I'm explaining this correctly, hopefully my point is across at least hehe.
Ahh ya did fine ;o) It turns out the testing directories aren't very big anyway, so it's not a huge deal either way.
Cheers, Sean
On Mon, 12 Jan 2004 17:12:35 +0000 Tim Waugh twaugh@redhat.com wrote:
On Mon, Jan 12, 2004 at 11:56:00AM -0500, Sean Estabrooks wrote:
Shouldn't the flow of an rpm be something like:
development -> testing -> stable ?
No. The 'development' packages are built in a rawhide build environment -- you certainly don't want those ending up as stable updates for Fedora Core 1.
Basically a package is either built for testing (and then perhaps moved to stable) *or* for development.
Hey Tim,
Ok, i guess that makes some sense. My own feeling is that the development branch should not be behind the testing branch of the current release. All i was really asking was shouldn't it be released to"rawhide" ie. development branch first or at least in parallel? If it's good enough to be pre-stable, isn't it good enough for the development branch?
This would increase the exposure and perhaps reveal additional issues, prior to going stable. My other reason is admittedly somewhat selfish in that i only have a local mirror of the development rpms and would dislike having to mirror all the testing rpms just to get the odd rpm that appears there first. This can't be good for the download sites either.
Cheers, Sean
On Monday 12 January 2004 09:40, Jakub Jelinek wrote:
Fedora Update Notification FEDORA-2003-050 2004-01-12
Name : gcc Version : 3.3.2 Release : 6 Summary : Various compilers (C, C++, Objective-C, Java, ...) Description : The gcc package contains the GNU Compiler Collection version 3.3.2. You'll need this package in order to compile C code.
- Fri Jan 09 2004 Jakub Jelinek jakub@redhat.com 3.3.2-6
- update from gcc-3_3-branch
- PRs fortran/12632, target/13373, bootstrap/13068, middle-end/13475, target/11576, optimization/13394, c/13382, target/11271, middle-end/13400, optimization/13031, c++/13239, c++/2294, c++/5050, c++/11554, c++/12696, c++/12862, c++/13070, c++/13081, c++/13239, c++/13371, c++/13445, c++/13507, libstdc++/13007
- fix endless loop on AMD64 (#112678, PR optimization/13521)
- fix __builtin_expect
I would appreciate this getting into the development tree sooner rather than later so I can test the AMD64 endless loop fix without needing to rebuild myself. I already run the patch on locally build rpms and would like to verify on the "offical" rpms.
-
Balint Cristian -
Gene C. -
Jakub Jelinek -
Mike Chambers -
Sean Estabrooks -
Tim Waugh