Re: C++ ABI change -- freezing unstable for new C++ library packages
On Wed, Jun 15, 2005 at 01:17:59AM +0200, Josselin Mouette wrote: Le mardi 14 juin 2005 à 14:48 -0700, Steve Langasek a écrit : I maintain a package (hdf5) which contains a pure C library and a C++ interface. However, I'm pretty sure the C++ library isn't used by packages depending on it. In this case, is it necessary for the library to be renamed? If the C++ library is exposed in the package's shlibs, yes... Alright, I'll do that. Furthermore, this package has a long history of triggering weird compiler errors, including several ICEs. Is there a way to test the build with g++-4.0 on all architectures before the transition starts? (Other than asking eleven porters to check if it builds...) Upload a package to experimental that build-depends on g++-4.0 and invokes it in debian/rules? -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: C++ ABI change -- freezing unstable for new C++ library packages
Le mercredi 15 juin 2005 à 02:48 -0700, Steve Langasek a écrit : Furthermore, this package has a long history of triggering weird compiler errors, including several ICEs. Is there a way to test the build with g++-4.0 on all architectures before the transition starts? (Other than asking eleven porters to check if it builds...) Upload a package to experimental that build-depends on g++-4.0 and invokes it in debian/rules? Is experimental autobuilt these days? -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: C++ ABI change -- freezing unstable for new C++ library packages
On Wed, Jun 15, 2005 at 01:22:19PM +0200, Josselin Mouette wrote: Le mercredi 15 juin 2005 à 02:48 -0700, Steve Langasek a écrit : Furthermore, this package has a long history of triggering weird compiler errors, including several ICEs. Is there a way to test the build with g++-4.0 on all architectures before the transition starts? (Other than asking eleven porters to check if it builds...) Upload a package to experimental that build-depends on g++-4.0 and invokes it in debian/rules? Is experimental autobuilt these days? Yes, on a best-effort basis (i.e., we try to build everything, but no guarantees are made that everything is built as with unstable). See http://experimental.ftbfs.de/ for an interface similar to the one on http://buildd.debian.org/ -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: C++ ABI change -- freezing unstable for new C++ library packages
Le jeudi 09 juin 2005 à 02:13 +0200, Matthias Klose a écrit : For etch we will update the toolchain (glibc, binutils, linux-kernel-headers, gcc) again. Some updates look easy, other will have a bigger impact on packages. One aspect of the toolchain update is the change of the C++ ABI from version 1 (102) to version 2 (1002) of the GNU C++ compiler. Looks painful, but doable, as some of you may still remember the toolchain update in the early sarge stages. In short, we will have to rename all packages containing shared libraries written in C++. After these library packages have been renamed, all libraries and applications depending on the changed library names have to be uploaded again. To minimize the uploads and and lower the load of the buildds, C++ code should be uploaded, after the C++ compiler (c++, g++) points to a compiler version providing the new C++ ABI. I maintain a package (hdf5) which contains a pure C library and a C++ interface. However, I'm pretty sure the C++ library isn't used by packages depending on it. In this case, is it necessary for the library to be renamed? -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: This is a digitally signed message part
Re: C++ ABI change -- freezing unstable for new C++ library packages
* Josselin Mouette: I maintain a package (hdf5) which contains a pure C library and a C++ interface. However, I'm pretty sure the C++ library isn't used by packages depending on it. In this case, is it necessary for the library to be renamed? Is it reasonable to expect that users compile home-grown software using that library? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: C++ ABI change -- freezing unstable for new C++ library packages
On Tue, Jun 14, 2005 at 09:34:31PM +0200, Josselin Mouette wrote: Le jeudi 09 juin 2005 à 02:13 +0200, Matthias Klose a écrit : For etch we will update the toolchain (glibc, binutils, linux-kernel-headers, gcc) again. Some updates look easy, other will have a bigger impact on packages. One aspect of the toolchain update is the change of the C++ ABI from version 1 (102) to version 2 (1002) of the GNU C++ compiler. Looks painful, but doable, as some of you may still remember the toolchain update in the early sarge stages. In short, we will have to rename all packages containing shared libraries written in C++. After these library packages have been renamed, all libraries and applications depending on the changed library names have to be uploaded again. To minimize the uploads and and lower the load of the buildds, C++ code should be uploaded, after the C++ compiler (c++, g++) points to a compiler version providing the new C++ ABI. I maintain a package (hdf5) which contains a pure C library and a C++ interface. However, I'm pretty sure the C++ library isn't used by packages depending on it. In this case, is it necessary for the library to be renamed? If the C++ library is exposed in the package's shlibs, yes... -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: C++ ABI change -- freezing unstable for new C++ library packages
Le mardi 14 juin 2005 à 14:48 -0700, Steve Langasek a écrit : I maintain a package (hdf5) which contains a pure C library and a C++ interface. However, I'm pretty sure the C++ library isn't used by packages depending on it. In this case, is it necessary for the library to be renamed? If the C++ library is exposed in the package's shlibs, yes... Alright, I'll do that. Furthermore, this package has a long history of triggering weird compiler errors, including several ICEs. Is there a way to test the build with g++-4.0 on all architectures before the transition starts? (Other than asking eleven porters to check if it builds...) -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: This is a digitally signed message part
Re: C++ ABI change -- freezing unstable for new C++ library packages
On Friday 10 June 2005 05:59, Steve Langasek wrote: We're leaning towards possibly keeping udeb-generating packages frozen during etch still because they require manual intervention for syncing udebs into testing; this means separating the source packages that create udebs (which as a class were frozen later) from the rest of the base packages. I'm in the process of adopting a package (freetype2) that builds a udeb. Would updating this package now require manual intervention from the release team? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: C++ ABI change -- freezing unstable for new C++ library packages
On Fri, Jun 10, 2005 at 12:24:05PM +0100, Will Newton wrote: On Friday 10 June 2005 05:59, Steve Langasek wrote: We're leaning towards possibly keeping udeb-generating packages frozen during etch still because they require manual intervention for syncing udebs into testing; this means separating the source packages that create udebs (which as a class were frozen later) from the rest of the base packages. I'm in the process of adopting a package (freetype2) that builds a udeb. Would updating this package now require manual intervention from the release team? Yes, for the moment getting that into testing requires release-team approval (which is unlikely to be withheld - it's just so that the udeb can be synced at the same time). -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: C++ ABI change -- freezing unstable for new C++ library packages
On Friday 10 June 2005 15:27, Colin Watson wrote: I'm in the process of adopting a package (freetype2) that builds a udeb. Would updating this package now require manual intervention from the release team? Yes, for the moment getting that into testing requires release-team approval (which is unlikely to be withheld - it's just so that the udeb can be synced at the same time). So I can upload to unstable as often as I like, but when there's a release that is bug free and suitable for testing I need to notify the release team to get it to migrate there? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: C++ ABI change -- freezing unstable for new C++ library packages
On Fri, Jun 10, 2005 at 03:31:06PM +0100, Will Newton wrote: On Friday 10 June 2005 15:27, Colin Watson wrote: Yes, for the moment getting that into testing requires release-team approval (which is unlikely to be withheld - it's just so that the udeb can be synced at the same time). So I can upload to unstable as often as I like, but when there's a release that is bug free and suitable for testing I need to notify the release team to get it to migrate there? Yes, for the moment it's probably best just to ping us whenever it would have reached testing under normal circumstances according to grep-excuses. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: C++ ABI change -- freezing unstable for new C++ library packages
Matthias Klose wrote: We will send an update with a detailed schedule, when the toolchain is ready for the change. I'm sorry but I'm a little bit confused. Is unstable frozen *now*? If yes, is the toolchain being updated now? I'm assuming the change mostly involve moving gcc-defaults to point at 3.4 or 4.0 which I think is possible for all arch at this time [1]. gcc-3.4 is on all arches that I can see. A much better announcement would be to include some rough estimate on how long are we going to be waiting for the new toolchain. Is it hours? days? week? years? Also, the testing seems to be now unfrozen except for base. Does the base freeze have anything to do with the new C++ ABI? Thanks, - Adam [1] - http://packages.debian.org/unstable/devel/gcc-3.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: C++ ABI change -- freezing unstable for new C++ library packages
On Thu, 9 Jun 2005, Adam Majer wrote: Also, the testing seems to be now unfrozen except for base. Does the base freeze have anything to do with the new C++ ABI? No, it's more a leftover of the freeze process. I asked Steve today about this. He says base packages will be unfrozen again in a few days. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: C++ ABI change -- freezing unstable for new C++ library packages
Santiago Vila wrote: On Thu, 9 Jun 2005, Adam Majer wrote: Also, the testing seems to be now unfrozen except for base. Does the base freeze have anything to do with the new C++ ABI? No, it's more a leftover of the freeze process. I asked Steve today about this. He says base packages will be unfrozen again in a few days. Ok, thanks! I just wander why weren't all packages unfrozen at once. Something to do with too much new stuff entering Etch at once? - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: C++ ABI change -- freezing unstable for new C++ library packages
On Thu, Jun 09, 2005 at 09:04:20PM -0500, Adam Majer wrote: Santiago Vila wrote: On Thu, 9 Jun 2005, Adam Majer wrote: Also, the testing seems to be now unfrozen except for base. Does the base freeze have anything to do with the new C++ ABI? No, it's more a leftover of the freeze process. I asked Steve today about this. He says base packages will be unfrozen again in a few days. Ok, thanks! I just wander why weren't all packages unfrozen at once. Something to do with too much new stuff entering Etch at once? We're leaning towards possibly keeping udeb-generating packages frozen during etch still because they require manual intervention for syncing udebs into testing; this means separating the source packages that create udebs (which as a class were frozen later) from the rest of the base packages. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
C++ ABI change -- freezing unstable for new C++ library packages
-BEGIN PGP SIGNED MESSAGE- Hi all, For etch we will update the toolchain (glibc, binutils, linux-kernel-headers, gcc) again. Some updates look easy, other will have a bigger impact on packages. One aspect of the toolchain update is the change of the C++ ABI from version 1 (102) to version 2 (1002) of the GNU C++ compiler. Looks painful, but doable, as some of you may still remember the toolchain update in the early sarge stages. In short, we will have to rename all packages containing shared libraries written in C++. After these library packages have been renamed, all libraries and applications depending on the changed library names have to be uploaded again. To minimize the uploads and and lower the load of the buildds, C++ code should be uploaded, after the C++ compiler (c++, g++) points to a compiler version providing the new C++ ABI. Therefore, we - - freeze unstable for uploads of C++ library packages with new ABI versions. If a new soname is introduced now, it has to be changed a few weeks later again. Packages depending on these libraries would need to be uploaded twice as well. The freeze is technically enforced by the FTP team by rejecting any such uploads. - - C++ related uploads to unstable are strongly discouraged in order to not make this transtition take longer than strictly needed. For example don't update KDE to 3.4 for the old C++ ABI. Details of the planned C++ ABI change can be found at http://lists.debian.org/debian-release/2005/04/msg00153.html The time frame of the C++ ABI change is not yet fixed. We will certainly need some time to get the toolchain in shape to start the transition. In the meantime you can check the new compilers in unstable (g++-3.4, g++-4.0), the new binutils in experimental (2.16), and the new glibc in experimental (2.3.5). The ABI change will not start, before gcc-3.4.4, gcc-4.0.1 and binutils 2.16.1 are released and available on all architectures. What you can do now: - - All: check the bug tracking system for GCC 3.4/4.0 related patches. A kind soul (Andreas Jochens) did already submit hundreds of patches to various packages. Remember that FTBFS on amd64 will become bug reports with an RC severity. Make a test build of your package. Try to test it on an 64bit architecture (amd64, ia64). - - C++ library maintainers: Same as all. I'll submit patch proposals for library renamings, which already exist, to the Debian BTS. Remember the first version of the library that is compiled for the new ABI. We will collect these versions, so that build dependencies can be updated. - - C++ program maintainers: Same as all. Once packages with the new C++ ABI are uploaded, you must not upload your package until all C++ build dependencies are updated for the new ABI. We will send an update with a detailed schedule, when the toolchain is ready for the change. Have fun, share the pain! Matthias -BEGIN PGP SIGNATURE- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.5.8, an Emacs/PGP interface iQEVAwUBQqeIpAuDzMCIcnEhAQGuKwf/RCt+QymsedEYLJ1n/i+RyvEXAnFkpKuM CZVFkmMhFkYenCmmZGpeTqHoQyK2HYiD5fhFJRbRcZemg5Arx40FOiZd+kP8R3W1 IAFa7AGG6zXe1j33NYjhCRTo0COrvubsMYMy0YOUbSF4KzoCMTzPrgtdEr0r68Ai mvf15v5pJ5aoPAF3tjMqaf39GmXfJyDzHsm8fB3ZcitFUyFICWAl5wbYLRf4A728 p0ylIpmlKPor0up2zoYW4oXOuIkUrhc3VYw1u5mP6u38lB1GiQFfiEpxcikpQL6y ldxgJ1Kt0z4JZgutZc4Stwo0/93d1bweWHgiyPufmPF5wBesZq2LcA== =rY// -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
