Re: preparing for GCC 5, especially libstdc++6
On 07/03/2015 03:24 PM, Matthias Klose wrote: On 07/02/2015 06:45 PM, Emilio Pozuelo Monfort wrote: On 01/07/15 14:39, Matthias Klose wrote: On 06/26/2015 03:01 AM, Emilio Pozuelo Monfort wrote: On 25/06/15 17:44, Matthias Klose wrote: On 06/25/2015 01:20 PM, Matthias Klose wrote: On 06/25/2015 11:23 AM, Emilio Pozuelo Monfort wrote: - You suggest that some libraries may need to be renamed due to the ABI breaks. Do you have a list of affected libraries? No. Getting this list is a bit difficult. Candidates for these packages are the GCC 5 build failures due to mismatched symbols files. However there may be more packages which successfully build, but have additional symbols (this may be an empty set, because usually some symbol names should be just replaced by new ones). If symbol versioning is used in a library, you probably won't see this at all, until the package is built using GCC 5. I'll ask for another test rebuild with a diverted dpkg-gensymbols to look at the generated symbols files. Thanks Matthias. I'd be very interested in knowing more about what breaks. We have 361 C++ libraries which define at least one of these new symbols [1]. Note this list only includes the packages which succeed to build with GCC 5. Another 70 packages might need the same action (the issues at [2] with severity important, which fail during the dpkg-gensymbols call). So my proposal would be to file bug reports for each of these packages, asking the maintainers for what to do with this library. Actions could be: - do nothing, if none of these symbols are part of the library ABI. That would be a rebuild of the library and its reverse dependencies. - add breaks to all reverse dependencies on this library, and rebuild the library and the reverse dependencies. - rename the library package and rebuild all reverse dependencies. The default action should be the most conservative action (the renaming of the library package). But let's not do transitions unnecessarily... we have hundreds of libraries there, so if we can avoid a bunch, then we should avoid them. So I'd say the default action should be to investigate if a transition is needed or not. I'm not advocating to blindly ignore the problem, fwiw, just want to try to make this a little manageable. agreed. So I think filing these issues as a task to check their libraries is the right thing to do, and asking to close the issue if the packages should just be rebuilt without a transition. I see there are quite a few FTBFS bugs for the affected libraries, but since the plan is to do the switch to GCC 5 first, and the libstdc++6 transition later, there would be time in between to fix those bugs and prepare for the transition. Right? We could do the GCC 5 switch first, but then would have to deal with a second round of uploads once we change the default ABI. I'd like to avoid that. Note that for the packages mentioned in the transition we have far more RC issues which are unrelated to GCC 5. From my point the GCC 5 issues can be handled, and I'm currently asking people to help with fixes. I'm unsure what to do with all the other RC issues, as these are popping up while other unrelated packages are uploaded to the archive. Maybe let auto removals do it's work? These bug reports could be used as transition bug reports as well, once GCC 5 is the default. Then these could be reassigned to release.debian.org once the transitions start. Yeah, that or new bugs. As long as usertags / titles are set properly, I don't mind. :) Now filed as https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libstdc%2B%2B-cxx11;users=debian-...@lists.debian.org while fixing build failures, I set some of these issues to 'confirmed' where I found link errors while trying to build a package without first rebuilding all it's c++ dependencies. There are some ... plus there are some more, which I didn't find while inspecting the libraries. The ones I found were tagcoll, and exiv2 not showing up in my initial batch, but were tagcoll and exiv2 symbols from the template headers were included in another library libfoo, and then trying to build something depending on libfoo failed without rebuilding that libfoo. So what do we want to do about the default action (always rename, or keep the name)? Certainly some things will break if you don't rename, however you could rename the library later too once you see the actual breakage. Another way to reduce renamings would be to only rename the lowest library in a library stack (e.g. tagcall in tagcall/libept/wibble/..., glibmm in glibmm/gtkmm/pangomm/cairomm/...), because almost everything depends on the low level dependency as well. Not sure how many more stacks we would have. Matthias -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive:
Re: preparing for GCC 5, especially libstdc++6
* Matthias Klose d...@debian.org [2015-06-16 23:37]: it's time to prepare for GCC 5 as the default compiler in unstable. FWIW, I compiled the entire archive on arm64 and I didn't find any obvious compiler bugs (i.e. internal compiler errors and similar). I found some more build failures with GCC 5 (mostly failures that only show up on !x86 and some new packages) which I reported to the BTS. -- Martin Michlmayr Linux for HP Helion, Hewlett-Packard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150707201348.gi21...@jirafa.cyrius.com
Re: preparing for GCC 5, especially libstdc++6
On 07/02/2015 06:45 PM, Emilio Pozuelo Monfort wrote: On 01/07/15 14:39, Matthias Klose wrote: On 06/26/2015 03:01 AM, Emilio Pozuelo Monfort wrote: On 25/06/15 17:44, Matthias Klose wrote: On 06/25/2015 01:20 PM, Matthias Klose wrote: On 06/25/2015 11:23 AM, Emilio Pozuelo Monfort wrote: - You suggest that some libraries may need to be renamed due to the ABI breaks. Do you have a list of affected libraries? No. Getting this list is a bit difficult. Candidates for these packages are the GCC 5 build failures due to mismatched symbols files. However there may be more packages which successfully build, but have additional symbols (this may be an empty set, because usually some symbol names should be just replaced by new ones). If symbol versioning is used in a library, you probably won't see this at all, until the package is built using GCC 5. I'll ask for another test rebuild with a diverted dpkg-gensymbols to look at the generated symbols files. Thanks Matthias. I'd be very interested in knowing more about what breaks. We have 361 C++ libraries which define at least one of these new symbols [1]. Note this list only includes the packages which succeed to build with GCC 5. Another 70 packages might need the same action (the issues at [2] with severity important, which fail during the dpkg-gensymbols call). So my proposal would be to file bug reports for each of these packages, asking the maintainers for what to do with this library. Actions could be: - do nothing, if none of these symbols are part of the library ABI. That would be a rebuild of the library and its reverse dependencies. - add breaks to all reverse dependencies on this library, and rebuild the library and the reverse dependencies. - rename the library package and rebuild all reverse dependencies. The default action should be the most conservative action (the renaming of the library package). But let's not do transitions unnecessarily... we have hundreds of libraries there, so if we can avoid a bunch, then we should avoid them. So I'd say the default action should be to investigate if a transition is needed or not. I'm not advocating to blindly ignore the problem, fwiw, just want to try to make this a little manageable. agreed. So I think filing these issues as a task to check their libraries is the right thing to do, and asking to close the issue if the packages should just be rebuilt without a transition. I see there are quite a few FTBFS bugs for the affected libraries, but since the plan is to do the switch to GCC 5 first, and the libstdc++6 transition later, there would be time in between to fix those bugs and prepare for the transition. Right? We could do the GCC 5 switch first, but then would have to deal with a second round of uploads once we change the default ABI. I'd like to avoid that. Note that for the packages mentioned in the transition we have far more RC issues which are unrelated to GCC 5. From my point the GCC 5 issues can be handled, and I'm currently asking people to help with fixes. I'm unsure what to do with all the other RC issues, as these are popping up while other unrelated packages are uploaded to the archive. Maybe let auto removals do it's work? These bug reports could be used as transition bug reports as well, once GCC 5 is the default. Then these could be reassigned to release.debian.org once the transitions start. Yeah, that or new bugs. As long as usertags / titles are set properly, I don't mind. :) Now filed as https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libstdc%2B%2B-cxx11;users=debian-...@lists.debian.org Matthias -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55968d12.4010...@debian.org
Re: preparing for GCC 5, especially libstdc++6
On 01/07/15 14:39, Matthias Klose wrote: On 06/26/2015 03:01 AM, Emilio Pozuelo Monfort wrote: On 25/06/15 17:44, Matthias Klose wrote: On 06/25/2015 01:20 PM, Matthias Klose wrote: On 06/25/2015 11:23 AM, Emilio Pozuelo Monfort wrote: - You suggest that some libraries may need to be renamed due to the ABI breaks. Do you have a list of affected libraries? No. Getting this list is a bit difficult. Candidates for these packages are the GCC 5 build failures due to mismatched symbols files. However there may be more packages which successfully build, but have additional symbols (this may be an empty set, because usually some symbol names should be just replaced by new ones). If symbol versioning is used in a library, you probably won't see this at all, until the package is built using GCC 5. I'll ask for another test rebuild with a diverted dpkg-gensymbols to look at the generated symbols files. Thanks Matthias. I'd be very interested in knowing more about what breaks. We have 361 C++ libraries which define at least one of these new symbols [1]. Note this list only includes the packages which succeed to build with GCC 5. Another 70 packages might need the same action (the issues at [2] with severity important, which fail during the dpkg-gensymbols call). So my proposal would be to file bug reports for each of these packages, asking the maintainers for what to do with this library. Actions could be: - do nothing, if none of these symbols are part of the library ABI. That would be a rebuild of the library and its reverse dependencies. - add breaks to all reverse dependencies on this library, and rebuild the library and the reverse dependencies. - rename the library package and rebuild all reverse dependencies. The default action should be the most conservative action (the renaming of the library package). But let's not do transitions unnecessarily... we have hundreds of libraries there, so if we can avoid a bunch, then we should avoid them. So I'd say the default action should be to investigate if a transition is needed or not. I'm not advocating to blindly ignore the problem, fwiw, just want to try to make this a little manageable. I see there are quite a few FTBFS bugs for the affected libraries, but since the plan is to do the switch to GCC 5 first, and the libstdc++6 transition later, there would be time in between to fix those bugs and prepare for the transition. Right? These bug reports could be used as transition bug reports as well, once GCC 5 is the default. Then these could be reassigned to release.debian.org once the transitions start. Yeah, that or new bugs. As long as usertags / titles are set properly, I don't mind. :) Cheers, Emilio -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55956ab2.8030...@debian.org
Re: preparing for GCC 5, especially libstdc++6
On 06/26/2015 03:01 AM, Emilio Pozuelo Monfort wrote: On 25/06/15 17:44, Matthias Klose wrote: On 06/25/2015 01:20 PM, Matthias Klose wrote: On 06/25/2015 11:23 AM, Emilio Pozuelo Monfort wrote: - You suggest that some libraries may need to be renamed due to the ABI breaks. Do you have a list of affected libraries? No. Getting this list is a bit difficult. Candidates for these packages are the GCC 5 build failures due to mismatched symbols files. However there may be more packages which successfully build, but have additional symbols (this may be an empty set, because usually some symbol names should be just replaced by new ones). If symbol versioning is used in a library, you probably won't see this at all, until the package is built using GCC 5. I'll ask for another test rebuild with a diverted dpkg-gensymbols to look at the generated symbols files. Thanks Matthias. I'd be very interested in knowing more about what breaks. We have 361 C++ libraries which define at least one of these new symbols [1]. Note this list only includes the packages which succeed to build with GCC 5. Another 70 packages might need the same action (the issues at [2] with severity important, which fail during the dpkg-gensymbols call). So my proposal would be to file bug reports for each of these packages, asking the maintainers for what to do with this library. Actions could be: - do nothing, if none of these symbols are part of the library ABI. That would be a rebuild of the library and its reverse dependencies. - add breaks to all reverse dependencies on this library, and rebuild the library and the reverse dependencies. - rename the library package and rebuild all reverse dependencies. The default action should be the most conservative action (the renaming of the library package). These bug reports could be used as transition bug reports as well, once GCC 5 is the default. Then these could be reassigned to release.debian.org once the transitions start. Matthias [1] https://people.debian.org/~doko/logs/gcc5-20150701/ [2] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-5;users=debian-...@lists.debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5593df7a.9060...@debian.org
Re: preparing for GCC 5, especially libstdc++6
On 06/25/2015 11:23 AM, Emilio Pozuelo Monfort wrote: Thanks for the report. I have looked at the wiki page, but it's not entirely clear to me how the libstdc++ transition will go, so I have a few questions to better understand it. - You suggest that some libraries may need to be renamed due to the ABI breaks. Do you have a list of affected libraries? No. Getting this list is a bit difficult. Candidates for these packages are the GCC 5 build failures due to mismatched symbols files. However there may be more packages which successfully build, but have additional symbols (this may be an empty set, because usually some symbol names should be just replaced by new ones). - Will those libraries need to migrate all at the same time with libstdc++, or could libstdc++/gcc-5 migrate first, and then the libraries can slowly migrate independently? libstdc++/gcc-5 can migrate first (and it already is). the dual ABI build only adds an ABI, doesn't remove one). Depending on which packages really depend on catching the std::system_error exception, and adding these to libstdc++6:Breaks, you have a small set which may need transitioning at the same time. I was talking with the boost maintainers to do a boost version bump at the same time. My main concern with all this is if we'll have a huge transition with lots of libraries been renamed and having to migrate at the same time with their rdeps. yes, but I can't see a good way around it. What I heard from other distros is that they handle this just with a rebuild. Of course Debian can do this as well, but it probably will make partial upgrades not working. Matthias -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/558be3f9.6000...@debian.org
Re: preparing for GCC 5, especially libstdc++6
On 06/25/2015 01:20 PM, Matthias Klose wrote: On 06/25/2015 11:23 AM, Emilio Pozuelo Monfort wrote: - You suggest that some libraries may need to be renamed due to the ABI breaks. Do you have a list of affected libraries? No. Getting this list is a bit difficult. Candidates for these packages are the GCC 5 build failures due to mismatched symbols files. However there may be more packages which successfully build, but have additional symbols (this may be an empty set, because usually some symbol names should be just replaced by new ones). If symbol versioning is used in a library, you probably won't see this at all, until the package is built using GCC 5. I'll ask for another test rebuild with a diverted dpkg-gensymbols to look at the generated symbols files. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/558c21dd.2070...@debian.org
Re: preparing for GCC 5, especially libstdc++6
On 25/06/15 17:44, Matthias Klose wrote: On 06/25/2015 01:20 PM, Matthias Klose wrote: On 06/25/2015 11:23 AM, Emilio Pozuelo Monfort wrote: - You suggest that some libraries may need to be renamed due to the ABI breaks. Do you have a list of affected libraries? No. Getting this list is a bit difficult. Candidates for these packages are the GCC 5 build failures due to mismatched symbols files. However there may be more packages which successfully build, but have additional symbols (this may be an empty set, because usually some symbol names should be just replaced by new ones). If symbol versioning is used in a library, you probably won't see this at all, until the package is built using GCC 5. I'll ask for another test rebuild with a diverted dpkg-gensymbols to look at the generated symbols files. Thanks Matthias. I'd be very interested in knowing more about what breaks. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/558ca482.3090...@debian.org
Re: preparing for GCC 5, especially libstdc++6
On 16/06/15 23:37, Matthias Klose wrote: Hi, it's time to prepare for GCC 5 as the default compiler in unstable. Compared to earlier version bumps, the switch to GCC 5 is a bit more complicated because libstdc++6 sees a few ABI incompatibilities, partially depending on the C++ standard version used for the builds. libstdc++6 will support two ABI's, the classic cxx98 ABI (currently in testing/unstable) and the new cxx11 ABI (currently enabled in experimental as the default ABI). - the majority of packages using c++98 or earlier c++ standards should just continue to work. - In GCC 4.9 and earlier versions the libstdc++6 C++11 support was still marked as experimental, and upstream doesn't (and didn't in the past) guarantee c++11 ABI compatibility across major GCC versions. It worked somehow ok in the past, however it won't this time. - some c++98 code won't work when parts are built using GCC 4.9, and some parts with GCC 5 (see PR66145 upstream). Unfortunately due to PR66145 we already have an incompatible libstdc++6 (at least for some packages) in testing/unstable, which was only seen after the first packages were rebuilt and issues like #784655 were reported. My goal is to make the GCC version bump in early July, and use the time until then to prepare libstdc++6 depending packages to get ready for GCC 5, and avoiding version bumps for C++ libraries until this time. Details for the whole transition are outlined in https://wiki.debian.org/GCC5 I'd appreciate feedback for this plan, clarify the wiki page, and would like to post a finalized plan next week to d-d-a, and file appropriate transition bugs next week. Hi Matthias, Thanks for the report. I have looked at the wiki page, but it's not entirely clear to me how the libstdc++ transition will go, so I have a few questions to better understand it. - You suggest that some libraries may need to be renamed due to the ABI breaks. Do you have a list of affected libraries? - Will those libraries need to migrate all at the same time with libstdc++, or could libstdc++/gcc-5 migrate first, and then the libraries can slowly migrate independently? My main concern with all this is if we'll have a huge transition with lots of libraries been renamed and having to migrate at the same time with their rdeps. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/558bc883.1060...@debian.org
Re: preparing for GCC 5, especially libstdc++6
On 06/17/2015 09:42 PM, Lisandro Damián Nicanor Pérez Meyer wrote: On Tuesday 16 June 2015 23:37:41 Matthias Klose wrote: Hi, it's time to prepare for GCC 5 as the default compiler in unstable. Compared to earlier version bumps, the switch to GCC 5 is a bit more complicated because libstdc++6 sees a few ABI incompatibilities, partially depending on the C++ standard version used for the builds. libstdc++6 will support two ABI's, the classic cxx98 ABI (currently in testing/unstable) and the new cxx11 ABI (currently enabled in experimental as the default ABI). Hi Matthias! [snip] My goal is to make the GCC version bump in early July, and use the time until then to prepare libstdc++6 depending packages to get ready for GCC 5, and avoiding version bumps for C++ libraries until this time. As you already know we the Qt/KDE team, in order to avoid an ABI break, need to either: a) Push Qt 5.4.2 to unstable before gcc5 becomes the default compiler. This is currently not an option due to #787689. b) Push Qt 5.4.2 to unstable at the same time as gcc5 becomes the default (well, one or two dinstalls later maybe). If some package gets compiled with gcc5 and Qt 5.4.2 in the meantime we can binNMU it. c) Push Qt 5.4.2 to unstable a couple of days before gcc5 becomes the default. Once gcc5 becomes the default ask for a give back in armhf. d) Push Qt 5.4.2 to unstable either by forcing gcc5 as default at build time or working around the bug. I would definitely would like to avoid this option as: - The current Qt stack is comprised of 25 source packages. I don't think me or my teammates will have the time to hack all of them before beginnings of July. - I don't know if some other lib/app that build depends on qt5 will still have the issue on armhf if we workaround it. - I don't know what happens if Qt5 gets built against gcc5 but apps against gcc4.9. Possibly and hopefully nothing, but I just don't know. My current preference would be acb (totally discarding d), but I'm open to suggestions too. I would prefer b), and preparing the packages to build with the gcc-5 from experimental (not unstable). Does Qt 5.4.2 change sonames? If not, please prepare to change the library package names, if new cxx11 symbols are introduced. Matthias -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5582c0bb.7010...@debian.org
Re: preparing for GCC 5, especially libstdc++6
On Thursday 18 June 2015 14:59:39 Matthias Klose wrote: [snip] I would prefer b), and preparing the packages to build with the gcc-5 from experimental (not unstable). OK. Does Qt 5.4.2 change sonames? If not, please prepare to change the library package names, if new cxx11 symbols are introduced. No and no std symbols are exposed. We are not expecting breakage in that front, counting from the experience of other distros. So far the only breakage I have seen are constructors/destructors [dis]appearing, which is just normal stuff and can be fixed by a simple symbols fix.For that we just need for all archs to build the packages and then fix them. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: preparing for GCC 5, especially libstdc++6
On Tuesday 16 June 2015 23:37:41 Matthias Klose wrote: Hi, it's time to prepare for GCC 5 as the default compiler in unstable. Compared to earlier version bumps, the switch to GCC 5 is a bit more complicated because libstdc++6 sees a few ABI incompatibilities, partially depending on the C++ standard version used for the builds. libstdc++6 will support two ABI's, the classic cxx98 ABI (currently in testing/unstable) and the new cxx11 ABI (currently enabled in experimental as the default ABI). Hi Matthias! [snip] My goal is to make the GCC version bump in early July, and use the time until then to prepare libstdc++6 depending packages to get ready for GCC 5, and avoiding version bumps for C++ libraries until this time. As you already know we the Qt/KDE team, in order to avoid an ABI break, need to either: a) Push Qt 5.4.2 to unstable before gcc5 becomes the default compiler. This is currently not an option due to #787689. b) Push Qt 5.4.2 to unstable at the same time as gcc5 becomes the default (well, one or two dinstalls later maybe). If some package gets compiled with gcc5 and Qt 5.4.2 in the meantime we can binNMU it. c) Push Qt 5.4.2 to unstable a couple of days before gcc5 becomes the default. Once gcc5 becomes the default ask for a give back in armhf. d) Push Qt 5.4.2 to unstable either by forcing gcc5 as default at build time or working around the bug. I would definitely would like to avoid this option as: - The current Qt stack is comprised of 25 source packages. I don't think me or my teammates will have the time to hack all of them before beginnings of July. - I don't know if some other lib/app that build depends on qt5 will still have the issue on armhf if we workaround it. - I don't know what happens if Qt5 gets built against gcc5 but apps against gcc4.9. Possibly and hopefully nothing, but I just don't know. My current preference would be acb (totally discarding d), but I'm open to suggestions too. Kinds regards, Lisandro. -- El futuro es WIN95 A no ser que hagamos algo a tiempo. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
preparing for GCC 5, especially libstdc++6
Hi, it's time to prepare for GCC 5 as the default compiler in unstable. Compared to earlier version bumps, the switch to GCC 5 is a bit more complicated because libstdc++6 sees a few ABI incompatibilities, partially depending on the C++ standard version used for the builds. libstdc++6 will support two ABI's, the classic cxx98 ABI (currently in testing/unstable) and the new cxx11 ABI (currently enabled in experimental as the default ABI). - the majority of packages using c++98 or earlier c++ standards should just continue to work. - In GCC 4.9 and earlier versions the libstdc++6 C++11 support was still marked as experimental, and upstream doesn't (and didn't in the past) guarantee c++11 ABI compatibility across major GCC versions. It worked somehow ok in the past, however it won't this time. - some c++98 code won't work when parts are built using GCC 4.9, and some parts with GCC 5 (see PR66145 upstream). Unfortunately due to PR66145 we already have an incompatible libstdc++6 (at least for some packages) in testing/unstable, which was only seen after the first packages were rebuilt and issues like #784655 were reported. My goal is to make the GCC version bump in early July, and use the time until then to prepare libstdc++6 depending packages to get ready for GCC 5, and avoiding version bumps for C++ libraries until this time. Details for the whole transition are outlined in https://wiki.debian.org/GCC5 I'd appreciate feedback for this plan, clarify the wiki page, and would like to post a finalized plan next week to d-d-a, and file appropriate transition bugs next week. Thanks, Matthias -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55809725.8040...@debian.org
