As you'll notice, there will be lots more packages bumped for the rebase to gcc. Most completed today, but we'll be working through a list of failures over the next couple days. Things will still be in a bit of flux, but we're working on it.
Java is still being worked on too. Getting the java stack built with gcj is a great accomplishment and I really respect our java and gcj team for putting in the work to further the free java. Please bare with us as we finalize the development changes necessary to accomplish this task.
On Sat, 17 Dec 2005 23:43:16 -0800, Jesse Keating wrote:
As you'll notice, there will be lots more packages bumped for the rebase to gcc. Most completed today, but we'll be working through a list of failures over the next couple days. Things will still be in a bit of flux, but we're working on it.
Java is still being worked on too. Getting the java stack built with gcj is a great accomplishment and I really respect our java and gcj team for putting in the work to further the free java. Please bare with us as we finalize the development changes necessary to accomplish this task.
Does the new GCC introduce any run-time/ABI breakage which requires packages in Fedora Extras Development to be rebuilt? Or does it only reveal problematic source code?
On 1/9/06, Michael Schwendt fedora@wir-sind-cool.org wrote:
On Sat, 17 Dec 2005 23:43:16 -0800, Jesse Keating wrote:
As you'll notice, there will be lots more packages bumped for the rebase to gcc. Most completed today, but we'll be working through a list of failures over the next couple days. Things will still be in a bit of flux, but we're working on it.
Java is still being worked on too. Getting the java stack built with gcj is a great accomplishment and I really respect our java and gcj team for putting in the work to further the free java. Please bare with us as we finalize the development changes necessary to accomplish this task.
Does the new GCC introduce any run-time/ABI breakage which requires packages in Fedora Extras Development to be rebuilt? Or does it only reveal problematic source code?
I think all the extras need to be rebuilt for this. I know seahorse for one needs it (and may need some fixes).
Pete
On Mon, 9 Jan 2006 11:38:28 +0000, Peter Robinson wrote:
On 1/9/06, Michael Schwendt wrote:
On Sat, 17 Dec 2005 23:43:16 -0800, Jesse Keating wrote:
As you'll notice, there will be lots more packages bumped for the rebase to gcc. Most completed today, but we'll be working through a list of failures over the next couple days. Things will still be in a bit of flux, but we're working on it.
Java is still being worked on too. Getting the java stack built with gcj is a great accomplishment and I really respect our java and gcj team for putting in the work to further the free java. Please bare with us as we finalize the development changes necessary to accomplish this task.
Does the new GCC introduce any run-time/ABI breakage which requires packages in Fedora Extras Development to be rebuilt? Or does it only reveal problematic source code?
I think all the extras need to be rebuilt for this. I know seahorse for one needs it (and may need some fixes).
AFAIK, seahorse was affected by SONAME changes in some of its dependencies, which made a rebuild necessary. That was a change not related to the GCC upgrade. My question is not about ordinary breakage through upgrades of dependencies.
As you'll notice, there will be lots more packages bumped for the rebase to gcc. Most completed today, but we'll be working through a list of failures over the next couple days. Things will still be in a bit of flux, but we're working on it.
Java is still being worked on too. Getting the java stack built with gcj is a great accomplishment and I really respect our java and gcj team for putting in the work to further the free java. Please bare with us as we finalize the development changes necessary to accomplish this task.
Does the new GCC introduce any run-time/ABI breakage which requires packages in Fedora Extras Development to be rebuilt? Or does it only reveal problematic source code?
I think all the extras need to be rebuilt for this. I know seahorse for one needs it (and may need some fixes).
AFAIK, seahorse was affected by SONAME changes in some of its dependencies, which made a rebuild necessary. That was a change not related to the GCC upgrade. My question is not about ordinary breakage through upgrades of dependencies.
Yes, I think that's true but I also think there is some gcc41 rebuild issues with it too (well there seems to be when I just try to rebuild the srpm. I think the binaries produced by gcc 4 and 4.1 are compatible so most things won't need to be rebuilt, but then its probably good for them to be rebuilt too.
Pete
Really delighted to see the new compat-libstdc++ today, but getting the following attempting to yum them down:
============================================================================= Install 0 Package(s) Update 2 Package(s) Remove 0 Package(s) Total download size: 405 k Downloading Packages: (1/2): compat-libstdc++-2 100% |=========================| 174 kB 00:00 http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/Fed...: [Errno -1] Package does not match checksum Trying other mirror. (2/2): compat-libstdc++-3 100% |=========================| 230 kB 00:00 http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/Fed...: [Errno -1] Package does not match checksum Trying other mirror.
Error Downloading Packages: compat-libstdc++-33 - 3.2.3-54.fc5.i386: failure: Fedora/RPMS/compat-libstdc++-33-3.2.3-54.fc5.i386.rpm from development: [Errno 256] No more mirrors to try. compat-libstdc++-296 - 2.96-134.i386: failure: Fedora/RPMS/compat-libstdc++-296-2.96-134.i386.rpm from development: [Errno 256] No more mirrors to try.
Peter Robinson writes:
As you'll notice, there will be lots more packages bumped for the rebase to gcc. Most completed today, but we'll be working through a list of failures over the next couple days. Things will still be in a bit of flux, but we're working on it.
Java is still being worked on too. Getting the java stack built with gcj is a great accomplishment and I really respect our java and gcj team for putting in the work to further the free java. Please bare with us as we finalize the development changes necessary to accomplish this task.
Does the new GCC introduce any run-time/ABI breakage which requires packages in Fedora Extras Development to be rebuilt? Or does it only reveal problematic source code?
I think all the extras need to be rebuilt for this. I know seahorse for one needs it (and may need some fixes).
AFAIK, seahorse was affected by SONAME changes in some of its dependencies, which made a rebuild necessary. That was a change not related to the GCC upgrade. My question is not about ordinary breakage through upgrades of dependencies.
Yes, I think that's true but I also think there is some gcc41 rebuild issues with it too (well there seems to be when I just try to rebuild the srpm. I think the binaries produced by gcc 4 and 4.1 are compatible so most things won't need to be rebuilt, but then its probably good for them to be rebuilt too.
Pete
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Janina Sajka wrote:
Really delighted to see the new compat-libstdc++ today, but getting the following attempting to yum them down:
Sorry about the trouble. This error is due to a combination of two factors. We signed the previously unsigned packages, but forgot to repocreate the metadata again. Your yum grabbed the unsigned metadata, which didn't match the checksums on the newly signed packages.
Unfortunately everyone that grabbed metadata prior to signing will need to clear their yum cache. Even though today's rawhide is consistent between packages and metadata, everyone will need to use "yum clean headers metadata" in order to proceed with further updates.
I consider this to be a bug in yum. Once we accidentally pushed an unsigned package in FC4 Updates. When realizing the problem Sopwith signed and re-pushed it, but anybody who had already downloaded the unsigned header forever was stuck being unable to upgrade. Because we had no choice, we had to rebuild the package so yum would re-grab headers and continue updating stuff without manual intervetion.
Warren Togami wtogami@redhat.com
Warren Togami wrote:
Janina Sajka wrote:
Really delighted to see the new compat-libstdc++ today, but getting the following attempting to yum them down:
Unfortunately everyone that grabbed metadata prior to signing will need to clear their yum cache. Even though today's rawhide is consistent between packages and metadata, everyone will need to use "yum clean headers metadata" in order to proceed with further updates.
Ugh... today's rawhide isn't consistent again, because more previously unsigned packages were signed again. Rel-eng is trying to sort this out today.
Warren Togami wtogami@redhat.com
Warren Togami wrote :
Warren Togami wrote:
Janina Sajka wrote:
Really delighted to see the new compat-libstdc++ today, but getting the following attempting to yum them down:
Unfortunately everyone that grabbed metadata prior to signing will need to clear their yum cache. Even though today's rawhide is consistent between packages and metadata, everyone will need to use "yum clean headers metadata" in order to proceed with further updates.
Ugh... today's rawhide isn't consistent again, because more previously unsigned packages were signed again. Rel-eng is trying to sort this out today.
OK, thanks for the info :-)
Matthias
devel@lists.stg.fedoraproject.org
-
Janina Sajka -
Jesse Keating -
Matthias Saou -
Michael Schwendt -
Peter Robinson -
Warren Togami