Re: [arch-general] [arch-dev-public] Kill old gcc versions
On Mon, 2009-06-15 at 10:45 +1000, Allan McRae wrote:
Baho Utot wrote:
On Mon, 2009-06-15 at 00:51 +0200, Jan de Groot wrote:
On Sun, 2009-06-14 at 18:46 -0400, Baho Utot wrote:
I have encountered many packages in extra that don't compile with gcc-4.4.0. The easy way to fix them is to compile them with gcc-3.4
The easy way to fix them is by reporting bugs. Bugfixing most of these packages is very easy and takes us only a few minutes to fix, so why bother supporting an old outdated compiler that hasn't been supported upstream for a long while?
Do you really want a list of all the packages in extra that are broke?
There are lots of them
Filing a bug report means they will get fixed. Not telling us about them, means they will wait until an update or rebuild is needed.
Allan
I can do that....if you can stand all the bug reports :) My script just finished and it found another 400+ that didn't build, that will take some time to go through to find the ones that didn't build because of gcc-4.4.0 errors :)
Excerpts from Baho Utot's message of Mo Jun 15 03:14:10 +0200 2009:
I can do that....if you can stand all the bug reports :)
I hope you understand that the problem is with upstream (if the package won't compile because the source is not standards compliant), so it should be reported there and not on arch's bugtracker.
On Mon, Jun 15, 2009 at 04:14, Baho Utot<baho-utot@columbus.rr.com> wrote:
On Mon, 2009-06-15 at 10:45 +1000, Allan McRae wrote:
Baho Utot wrote:
On Mon, 2009-06-15 at 00:51 +0200, Jan de Groot wrote:
On Sun, 2009-06-14 at 18:46 -0400, Baho Utot wrote:
I have encountered many packages in extra that don't compile with gcc-4.4.0. The easy way to fix them is to compile them with gcc-3.4
The easy way to fix them is by reporting bugs. Bugfixing most of these packages is very easy and takes us only a few minutes to fix, so why bother supporting an old outdated compiler that hasn't been supported upstream for a long while?
Do you really want a list of all the packages in extra that are broke?
There are lots of them
Filing a bug report means they will get fixed. Not telling us about them, means they will wait until an update or rebuild is needed.
Allan
I can do that....if you can stand all the bug reports :)
My script just finished and it found another 400+ that didn't build, that will take some time to go through to find the ones that didn't build because of gcc-4.4.0 errors :)
Packages that are already built don't really need immediate fixing unless you build all your packages from source. There are always some packages that cannot be built with current gcc/glibc/kernel/other-deps, but they work because they were built already some time ago. When such package is going to be updated due to new version, for example - either these errors are already fixed upstream, or some patching is done to fix them. So actually there won't be the need to fix all broken packages at one time. -- Roman Kyrylych (Роман Кирилич)
Roman Kyrylych schrieb:
Packages that are already built don't really need immediate fixing unless you build all your packages from source. There are always some packages that cannot be built with current gcc/glibc/kernel/other-deps, but they work because they were built already some time ago. When such package is going to be updated due to new version, for example - either these errors are already fixed upstream, or some patching is done to fix them. So actually there won't be the need to fix all broken packages at one time.
From his messages to this list, it seems Baho has actually been rebuilding our complete repository. It is convenient to have those fixes applied. But I would rather have Baho report the problems and fixes upstream to the projects instead of here. Most projects will gladly fix any compile problems with recent compilers.
Baho Utot schrieb:
I can do that....if you can stand all the bug reports :)
My script just finished and it found another 400+ that didn't build, that will take some time to go through to find the ones that didn't build because of gcc-4.4.0 errors :)
You could collect them in one bugreport instead of opening a separate one for each. All of these packages have been built at some point, so it is likely they worked with gcc 4.1, 4.2 or 4.3 (unless they are ancient and haven't been rebuilt much longer than that). Most of them probably worked with 4.3. Once we have to rebuild these packages, we fix them to compile with the current compiler - which is very easy most of the time. If you are building our whole repositories, you will probably find those problems before we do.
On Mon, 2009-06-15 at 09:07 +0200, Thomas Bächler wrote:
Baho Utot schrieb:
I can do that....if you can stand all the bug reports :)
My script just finished and it found another 400+ that didn't build, that will take some time to go through to find the ones that didn't build because of gcc-4.4.0 errors :)
You could collect them in one bugreport instead of opening a separate one for each.
All of these packages have been built at some point, so it is likely they worked with gcc 4.1, 4.2 or 4.3 (unless they are ancient and haven't been rebuilt much longer than that). Most of them probably worked with 4.3.
Once we have to rebuild these packages, we fix them to compile with the current compiler - which is very easy most of the time. If you are building our whole repositories, you will probably find those problems before we do.
I really don't like these collection bugs that contain bugreports for 400 packages with the same problem. Some get fixed, some don't get fixed, we lose track and after a while it gets closed with message "probably fixed, open new one if you find more".
On Mon, 2009-06-15 at 09:07 +0200, Thomas Bächler wrote:
Baho Utot schrieb:
I can do that....if you can stand all the bug reports :)
My script just finished and it found another 400+ that didn't build, that will take some time to go through to find the ones that didn't build because of gcc-4.4.0 errors :)
You could collect them in one bugreport instead of opening a separate one for each.
All of these packages have been built at some point, so it is likely they worked with gcc 4.1, 4.2 or 4.3 (unless they are ancient and haven't been rebuilt much longer than that). Most of them probably worked with 4.3.
Once we have to rebuild these packages, we fix them to compile with the current compiler - which is very easy most of the time. If you are building our whole repositories, you will probably find those problems before we do.
That is exactly what I am doing. I am compiling the whole lot to run native on AMD. Core usually compiles just fine with little or no problems, extra has lots of problems from bad URL to PKGBUILD that are not standard to gcc problems.
participants (5)
-
Baho Utot
-
Jan de Groot
-
Jan Spakula
-
Roman Kyrylych
-
Thomas Bächler