Bug#712956: marked as done (0ad: seems to use CPU features not available everywhere)
reopen 712956 thanks nvidia-texture-tools (2.0.8-1+dfsg-4) unstable; urgency=low . [ Fabio Pedretti ] * Add armel and armhf build support (Closes: #721972) * Remove -march=athlon64 from CXXFLAGS (Closes: #713966, #712956) This is clealy the wrong bug you're closing. It's assigned to 0ad. 0.0.14-2 is still using -msse -march=i686 on i386. It wasn't using -march=athlon64 on amd64 before either as far as I know but had problem running on at least one of the buildds. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712956: marked as done (0ad: seems to use CPU features not available everywhere)
On Sat, Sep 7, 2013 at 1:02 AM, Kurt Roeckx k...@roeckx.be wrote: reopen 712956 thanks nvidia-texture-tools (2.0.8-1+dfsg-4) unstable; urgency=low . [ Fabio Pedretti ] * Add armel and armhf build support (Closes: #721972) * Remove -march=athlon64 from CXXFLAGS (Closes: #713966, #712956) This is clealy the wrong bug you're closing. It's assigned to 0ad. 0.0.14-2 is still using -msse -march=i686 on i386 See explanation by upstream here [1]. If compiling with -march=i686 is strictly not allowed on Debian i386, I can just simply stop building 0ad for i386, although I'm not sure if that's necessary at all; the package has been sitting in the archive for over a year and I still haven't gotten any complaints about 0ad not running on any Debian user's i386 machine. It wasn't using -march=athlon64 on amd64 before either as far as I know but had problem running on at least one of the buildds. The original issue was that nvidia-texture-tools was compiled with -march=athlon64, which caused one of the amd64 buildds to complain about an Illegal instruction when trying to run 0ad's test suite when building 0ad. There's a relevant issue filed against upstream nvidia-texture-tools about this as well. [2] Regards, Vincent [1] http://trac.wildfiregames.com/ticket/1994#comment:5 [2] https://code.google.com/p/nvidia-texture-tools/issues/detail?id=188 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712956: marked as done (0ad: seems to use CPU features not available everywhere)
On Sat, Sep 07, 2013 at 01:21:59AM -0700, Vincent Cheng wrote: On Sat, Sep 7, 2013 at 1:02 AM, Kurt Roeckx k...@roeckx.be wrote: reopen 712956 thanks nvidia-texture-tools (2.0.8-1+dfsg-4) unstable; urgency=low . [ Fabio Pedretti ] * Add armel and armhf build support (Closes: #721972) * Remove -march=athlon64 from CXXFLAGS (Closes: #713966, #712956) This is clealy the wrong bug you're closing. It's assigned to 0ad. 0.0.14-2 is still using -msse -march=i686 on i386 See explanation by upstream here [1]. If compiling with -march=i686 is strictly not allowed on Debian i386, I can just simply stop building 0ad for i386, although I'm not sure if that's necessary at all; the package has been sitting in the archive for over a year and I still haven't gotten any complaints about 0ad not running on any Debian user's i386 machine. I don't know if having i686 is acceptable or not. But I currently see no good reason for it. [1] is my own comment. The only reply to that is that they still use the legacy functions, and no reply as to why they need to keep using it and can't move to the new ones. It wasn't using -march=athlon64 on amd64 before either as far as I know but had problem running on at least one of the buildds. The original issue was that nvidia-texture-tools was compiled with -march=athlon64, which caused one of the amd64 buildds to complain about an Illegal instruction when trying to run 0ad's test suite when building 0ad. There's a relevant issue filed against upstream nvidia-texture-tools about this as well. [2] So that was #713966 and that was fixed in 0ad with the 0.0.14-2 uploaded? Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712956: marked as done (0ad: seems to use CPU features not available everywhere)
On Sat, Sep 7, 2013 at 1:46 AM, Kurt Roeckx k...@roeckx.be wrote: On Sat, Sep 07, 2013 at 01:21:59AM -0700, Vincent Cheng wrote: On Sat, Sep 7, 2013 at 1:02 AM, Kurt Roeckx k...@roeckx.be wrote: reopen 712956 thanks nvidia-texture-tools (2.0.8-1+dfsg-4) unstable; urgency=low . [ Fabio Pedretti ] * Add armel and armhf build support (Closes: #721972) * Remove -march=athlon64 from CXXFLAGS (Closes: #713966, #712956) This is clealy the wrong bug you're closing. It's assigned to 0ad. 0.0.14-2 is still using -msse -march=i686 on i386 See explanation by upstream here [1]. If compiling with -march=i686 is strictly not allowed on Debian i386, I can just simply stop building 0ad for i386, although I'm not sure if that's necessary at all; the package has been sitting in the archive for over a year and I still haven't gotten any complaints about 0ad not running on any Debian user's i386 machine. I don't know if having i686 is acceptable or not. But I currently see no good reason for it. [1] is my own comment. The only reply to that is that they still use the legacy functions, and no reply as to why they need to keep using it and can't move to the new ones. Err, sorry, should have linked to comment #7 instead in that ticket. [1] We wouldn't run on an actual 486 due to use of several newer CPU instructions, one of which is the CAS in ia32.cpp. If indeed we have to compile with -march=i486, which sounds like a last resort, the CAS could be replaced with GCC-specific assembly, and we'd have a decent hope of compiling successfully. To me that sounds reasonable enough as to why we should be building 0ad with -march=i686. It wasn't using -march=athlon64 on amd64 before either as far as I know but had problem running on at least one of the buildds. The original issue was that nvidia-texture-tools was compiled with -march=athlon64, which caused one of the amd64 buildds to complain about an Illegal instruction when trying to run 0ad's test suite when building 0ad. There's a relevant issue filed against upstream nvidia-texture-tools about this as well. [2] So that was #713966 and that was fixed in 0ad with the 0.0.14-2 uploaded? Yes, should be fixed now, but again, since I don't have any hardware where I can reproduce this locally, I suppose the only way to prove that this is fixed is to have 0ad 0.0.14-2 be rebuilt on barber. Regards, Vincent [1] http://trac.wildfiregames.com/ticket/1994#comment:7 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712956: marked as done (0ad: seems to use CPU features not available everywhere)
On Sat, Sep 07, 2013 at 01:53:26AM -0700, Vincent Cheng wrote: On Sat, Sep 7, 2013 at 1:46 AM, Kurt Roeckx k...@roeckx.be wrote: On Sat, Sep 07, 2013 at 01:21:59AM -0700, Vincent Cheng wrote: On Sat, Sep 7, 2013 at 1:02 AM, Kurt Roeckx k...@roeckx.be wrote: reopen 712956 thanks nvidia-texture-tools (2.0.8-1+dfsg-4) unstable; urgency=low . [ Fabio Pedretti ] * Add armel and armhf build support (Closes: #721972) * Remove -march=athlon64 from CXXFLAGS (Closes: #713966, #712956) This is clealy the wrong bug you're closing. It's assigned to 0ad. 0.0.14-2 is still using -msse -march=i686 on i386 See explanation by upstream here [1]. If compiling with -march=i686 is strictly not allowed on Debian i386, I can just simply stop building 0ad for i386, although I'm not sure if that's necessary at all; the package has been sitting in the archive for over a year and I still haven't gotten any complaints about 0ad not running on any Debian user's i386 machine. I don't know if having i686 is acceptable or not. But I currently see no good reason for it. [1] is my own comment. The only reply to that is that they still use the legacy functions, and no reply as to why they need to keep using it and can't move to the new ones. Err, sorry, should have linked to comment #7 instead in that ticket. [1] We wouldn't run on an actual 486 due to use of several newer CPU instructions, one of which is the CAS in ia32.cpp. If indeed we have to compile with -march=i486, which sounds like a last resort, the CAS could be replaced with GCC-specific assembly, and we'd have a decent hope of compiling successfully. CAS being a compare and swap? Which is the atomic function they want to use? To me that sounds reasonable enough as to why we should be building 0ad with -march=i686. Anyway, I have no idea if g++ supports those new atomic functions without -march=i686, but I at least hope so. It wasn't using -march=athlon64 on amd64 before either as far as I know but had problem running on at least one of the buildds. The original issue was that nvidia-texture-tools was compiled with -march=athlon64, which caused one of the amd64 buildds to complain about an Illegal instruction when trying to run 0ad's test suite when building 0ad. There's a relevant issue filed against upstream nvidia-texture-tools about this as well. [2] So that was #713966 and that was fixed in 0ad with the 0.0.14-2 uploaded? Yes, should be fixed now, but again, since I don't have any hardware where I can reproduce this locally, I suppose the only way to prove that this is fixed is to have 0ad 0.0.14-2 be rebuilt on barber. I've triggerd that it gets build on barber, you should have a log about that in half an hour I guess. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712956: marked as done (0ad: seems to use CPU features not available everywhere)
On Sat, Sep 7, 2013 at 2:00 AM, Kurt Roeckx k...@roeckx.be wrote: On Sat, Sep 07, 2013 at 01:53:26AM -0700, Vincent Cheng wrote: On Sat, Sep 7, 2013 at 1:46 AM, Kurt Roeckx k...@roeckx.be wrote: On Sat, Sep 07, 2013 at 01:21:59AM -0700, Vincent Cheng wrote: On Sat, Sep 7, 2013 at 1:02 AM, Kurt Roeckx k...@roeckx.be wrote: reopen 712956 thanks nvidia-texture-tools (2.0.8-1+dfsg-4) unstable; urgency=low . [ Fabio Pedretti ] * Add armel and armhf build support (Closes: #721972) * Remove -march=athlon64 from CXXFLAGS (Closes: #713966, #712956) This is clealy the wrong bug you're closing. It's assigned to 0ad. 0.0.14-2 is still using -msse -march=i686 on i386 See explanation by upstream here [1]. If compiling with -march=i686 is strictly not allowed on Debian i386, I can just simply stop building 0ad for i386, although I'm not sure if that's necessary at all; the package has been sitting in the archive for over a year and I still haven't gotten any complaints about 0ad not running on any Debian user's i386 machine. I don't know if having i686 is acceptable or not. But I currently see no good reason for it. [1] is my own comment. The only reply to that is that they still use the legacy functions, and no reply as to why they need to keep using it and can't move to the new ones. Err, sorry, should have linked to comment #7 instead in that ticket. [1] We wouldn't run on an actual 486 due to use of several newer CPU instructions, one of which is the CAS in ia32.cpp. If indeed we have to compile with -march=i486, which sounds like a last resort, the CAS could be replaced with GCC-specific assembly, and we'd have a decent hope of compiling successfully. CAS being a compare and swap? Which is the atomic function they want to use? I don't know... To me that sounds reasonable enough as to why we should be building 0ad with -march=i686. Anyway, I have no idea if g++ supports those new atomic functions without -march=i686, but I at least hope so. This is all beyond my knowledge, so the most I can do is just relay messages back and forth between you and upstream if you have any further questions... It wasn't using -march=athlon64 on amd64 before either as far as I know but had problem running on at least one of the buildds. The original issue was that nvidia-texture-tools was compiled with -march=athlon64, which caused one of the amd64 buildds to complain about an Illegal instruction when trying to run 0ad's test suite when building 0ad. There's a relevant issue filed against upstream nvidia-texture-tools about this as well. [2] So that was #713966 and that was fixed in 0ad with the 0.0.14-2 uploaded? Yes, should be fixed now, but again, since I don't have any hardware where I can reproduce this locally, I suppose the only way to prove that this is fixed is to have 0ad 0.0.14-2 be rebuilt on barber. I've triggerd that it gets build on barber, you should have a log about that in half an hour I guess. Yep, built successfully [1] on barber, hence I think it's safe to say that the bug is fixed (or that the original FTBFS issue isn't reproducible anymore). Vincent [1] https://buildd.debian.org/status/fetch.php?pkg=0adarch=amd64ver=0.0.14-2stamp=1378546204 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
