Bug#770670: g++: fails to compile in c++0x mode on ppc64el with std::vector and SDL

2014-11-27 Thread Manuel A. Fernandez Montecelo
2014-11-25 22:39 GMT+00:00 Manuel A. Fernandez Montecelo
manuel.montez...@gmail.com:
 2014-11-25 20:13 GMT+00:00 Dominique Dumont dominique.dum...@hp.com:

 [...]
 So, in summary, I don't think that this is serious (RC), and I even
 have doubts that it's important in a broad sense.  I am quite sure
 that if you believe that it's important and explain it (we have a bug
 report of somebody affected, it's not purely theoretical!), they will
 let it to be applied -- but not 100%, I think that Release Managers
 are more reluctant to accept fixes than in previous releases.


Good that it got accepted.  Thanks for taking care of this :-)


-- 
Manuel A. Fernandez Montecelo manuel.montez...@gmail.com


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#770670: g++: fails to compile in c++0x mode on ppc64el with std::vector and SDL

2014-11-25 Thread Dominique Dumont

Hmm, according to [1], arm64 and ppc64el have made enough progress to be 
release architectures for Jessie. Britney no longer has special handling
for these two. Therefore, FTBFS regressions for arm64 and ppc64el
are now release critical (but non-regressions are not).

Since the fix is quite easy, I think we should not bother the release team and 
upload the fixed package to unstable. (and we need to have the unblock 
approved by Dec 5th).

Thoughts ?

[1] https://lists.debian.org/debian-devel-announce/2014/11/msg5.html

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#770670: g++: fails to compile in c++0x mode on ppc64el with std::vector and SDL

2014-11-25 Thread Manuel A. Fernandez Montecelo
2014-11-25 20:13 GMT+00:00 Dominique Dumont dominique.dum...@hp.com:

 Hmm, according to [1], arm64 and ppc64el have made enough progress to be
 release architectures for Jessie. Britney no longer has special handling
 for these two. Therefore, FTBFS regressions for arm64 and ppc64el
 are now release critical (but non-regressions are not).

 Since the fix is quite easy, I think we should not bother the release team and
 upload the fixed package to unstable. (and we need to have the unblock
 approved by Dec 5th).

 Thoughts ?

 [1] https://lists.debian.org/debian-devel-announce/2014/11/msg5.html


First and foremost, I am fine with whatever you want to do, I don't
have a strong opinion.  I gave my opinion in order to avoid (or at
least be aware)  the situation where we have a package in unstable
during the freeze that release managers don't want to accept in
testing.


With ppc64el being fringe I meant that, independently of what the
release team think, since this is not a mainstream architecture and
quite recent, and the bug triggered only under certain conditions, I
don't think that there will be lots of people affected by this bug.

As a person who helped to get many key packages compiling on both
these new architectures (and helped them in other various ways), and
made changes to several SDL packages very early on (2013) to get these
architectures supported, I am happy to get these things fixed and I do
really care about these new ports.

I am just pointing out that it's not libsdl2 itself which FTBFS while
it compiled before (regression), in which case it would be RC for
sure.  It's only that some packages that use libsdl2, in C++ (not C or
other languages), and (if I understood correctly) only when using the
non-default and still experimental -std=c++0x, fail to compile.

So, in summary, I don't think that this is serious (RC), and I even
have doubts that it's important in a broad sense.  I am quite sure
that if you believe that it's important and explain it (we have a bug
report of somebody affected, it's not purely theoretical!), they will
let it to be applied -- but not 100%, I think that Release Managers
are more reluctant to accept fixes than in previous releases.


Cheers.
-- 
Manuel A. Fernandez Montecelo manuel.montez...@gmail.com


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#770670: g++: fails to compile in c++0x mode on ppc64el with std::vector and SDL

2014-11-24 Thread Dominique Dumont

libsdl2 rules file alerady has

 DEB_HOST_ARCH_CPU ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_CPU)

 ifeq ($(DEB_HOST_ARCH_CPU),powerpc)
  confflags += --disable-altivec
 endif

I'm going to tweak this file to use --disable-altivec on ppc64el arch.

This should fix your problem.

All the best

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#770670: g++: fails to compile in c++0x mode on ppc64el with std::vector and SDL

2014-11-24 Thread Manuel A. Fernandez Montecelo
2014-11-24 7:28 GMT+00:00 Dominique Dumont d...@debian.org:

 libsdl2 rules file alerady has

  DEB_HOST_ARCH_CPU ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_CPU)

  ifeq ($(DEB_HOST_ARCH_CPU),powerpc)
   confflags += --disable-altivec
  endif

 I'm going to tweak this file to use --disable-altivec on ppc64el arch.

 This should fix your problem.

Just wondering... I am all for fixing this and the change seems easy
enough, but would it be worth asking for pre-approval to the release
team?

If GCC-4.9 still does not officially claim to be fully C++11 compliant
(which I don't think it does, but perhaps some later 4.9.x does -- in
any case it's not switched on by default), and ppc64el being a new and
somewhat fringe arch, and the bug does not affect to the availability
of the package itself, I am not 100% sure if they will consider this
RC.


Cheers.
-- 
Manuel A. Fernandez Montecelo manuel.montez...@gmail.com


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Processed: Re: Bug#770670: g++: fails to compile in c++0x mode on ppc64el with std::vector and SDL

2014-11-23 Thread Debian Bug Tracking System
Processing control commands:

 reassign -1 libsdl2-dev
Bug #770670 [g++] g++: fails to compile in c++0x mode on ppc64el with 
std::vector and SDL
Bug reassigned from package 'g++' to 'libsdl2-dev'.
No longer marked as found in versions 4.9.2-2.
Ignoring request to alter fixed versions of bug #770670 to the same values 
previously set
 severity -1 serious
Bug #770670 [libsdl2-dev] g++: fails to compile in c++0x mode on ppc64el with 
std::vector and SDL
Severity set to 'serious' from 'normal'
 retitle -1 libsdl2-dev - SDL.h includes altivec.h, breaks c++ code
Bug #770670 [libsdl2-dev] g++: fails to compile in c++0x mode on ppc64el with 
std::vector and SDL
Changed Bug title to 'libsdl2-dev - SDL.h includes altivec.h, breaks c++ code' 
from 'g++: fails to compile in c++0x mode on ppc64el with std::vector and SDL'

-- 
770670: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770670
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org