c++11 merged in master

c++11 merged in master

[Sage Weil]

Yay!  Thanks, Casey!

This initially breaks the precise and el6 builds on master.  I've fixed 
the precise gitbuilders with

sudo apt-get install python-software-properties
echo | sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt-get update
sudo apt-get install -y g++-4.8
/srv/autobuild-ceph/gitbuilder.git/build/install-deps.sh
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.6 60 --slave /usr/bin/g++ g++ /usr/bin/g++-4.6
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.8 40 --slave /usr/bin/g++ g++ /usr/bin/g++-4.8
echo 2 | sudo update-alternatives --config gcc
sudo restart autobuild-ceph

We'll need to do something similar on centos6 to get g++ 4.7 or 4.8 in 
place, and the jenkins slaves for release builds will also need to be 
updated.

Assuming this doesn't cause problems (e.g., runtime issues on vanilla 
precise) this will have no bearing on the previous discussion about 
whether we continue supporting old distros for future releases.

sage

Re: c++11 merged in master

[Samuel Just]

lambdas and autos for everyone!
-Sam

On Fri, Aug 7, 2015 at 10:52 AM, Sage Weil <sweil@redhat.com> wrote:
> Yay!  Thanks, Casey!
>
> This initially breaks the precise and el6 builds on master.  I've fixed
> the precise gitbuilders with
>
> sudo apt-get install python-software-properties
> echo | sudo add-apt-repository ppa:ubuntu-toolchain-r/test
> sudo apt-get update
> sudo apt-get install -y g++-4.8
> /srv/autobuild-ceph/gitbuilder.git/build/install-deps.sh
> sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.6 60 --slave /usr/bin/g++ g++ /usr/bin/g++-4.6
> sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.8 40 --slave /usr/bin/g++ g++ /usr/bin/g++-4.8
> echo 2 | sudo update-alternatives --config gcc
> sudo restart autobuild-ceph
>
> We'll need to do something similar on centos6 to get g++ 4.7 or 4.8 in
> place, and the jenkins slaves for release builds will also need to be
> updated.
>
> Assuming this doesn't cause problems (e.g., runtime issues on vanilla
> precise) this will have no bearing on the previous discussion about
> whether we continue supporting old distros for future releases.
>
> sage
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: c++11 merged in master

[Ken Dreyer]

On 08/07/2015 11:52 AM, Sage Weil wrote:
> We'll need to do something similar on centos6 to get g++ 4.7 or 4.8 in 
> place, and the jenkins slaves for release builds will also need to be 
> updated.

I think the most official repository for this sort of thing for CentOS 6
is SCL [1] (it's a little like PPA for RPM-based systems).

This is going to make our build process even more complicated, so if you
find that this isn't a trivial drop-in solution, I'm good for just
dropping RHEL 6/CentOS 6 support in master.

[1] https://www.softwarecollections.org/en/scls/rhscl/devtoolset-3/

- Ken

Re: c++11 merged in master

[Brad Hubbard]

On 08/08/2015 04:36 AM, Samuel Just wrote:
> lambdas and autos for everyone!

\o/

> -Sam
>
> On Fri, Aug 7, 2015 at 10:52 AM, Sage Weil <sweil@redhat.com> wrote:
>> Yay!  Thanks, Casey!
>>
>> This initially breaks the precise and el6 builds on master.  I've fixed
>> the precise gitbuilders with
>>
>> sudo apt-get install python-software-properties
>> echo | sudo add-apt-repository ppa:ubuntu-toolchain-r/test
>> sudo apt-get update
>> sudo apt-get install -y g++-4.8
>> /srv/autobuild-ceph/gitbuilder.git/build/install-deps.sh
>> sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.6 60 --slave /usr/bin/g++ g++ /usr/bin/g++-4.6
>> sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.8 40 --slave /usr/bin/g++ g++ /usr/bin/g++-4.8
>> echo 2 | sudo update-alternatives --config gcc
>> sudo restart autobuild-ceph
>>
>> We'll need to do something similar on centos6 to get g++ 4.7 or 4.8 in
>> place, and the jenkins slaves for release builds will also need to be
>> updated.
>>
>> Assuming this doesn't cause problems (e.g., runtime issues on vanilla
>> precise) this will have no bearing on the previous discussion about
>> whether we continue supporting old distros for future releases.
>>
>> sage
>> --
>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: c++11 merged in master

[Brad Hubbard]

On 08/08/2015 05:56 AM, Ken Dreyer wrote:
> On 08/07/2015 11:52 AM, Sage Weil wrote:
>> We'll need to do something similar on centos6 to get g++ 4.7 or 4.8 in
>> place, and the jenkins slaves for release builds will also need to be
>> updated.
>
> I think the most official repository for this sort of thing for CentOS 6
> is SCL [1] (it's a little like PPA for RPM-based systems).
>
> This is going to make our build process even more complicated, so if you
> find that this isn't a trivial drop-in solution, I'm good for just
> dropping RHEL 6/CentOS 6 support in master.
>
> [1] https://www.softwarecollections.org/en/scls/rhscl/devtoolset-3/

I think
https://access.redhat.com/documentation/en-US/Red_Hat_Developer_Toolset/3/html-single/User_Guide/index.html
is probably more comprehensive information for those that want more and should
be generally applicable to both CentOS and RHEL.

Cheers,
Brad

Re: c++11 merged in master

[Sage Weil]

On Fri, 7 Aug 2015, Sage Weil wrote:
> Yay!  Thanks, Casey!
> 
> This initially breaks the precise and el6 builds on master.  I've fixed 
> the precise gitbuilders with
> 
> sudo apt-get install python-software-properties
> echo | sudo add-apt-repository ppa:ubuntu-toolchain-r/test
> sudo apt-get update
> sudo apt-get install -y g++-4.8
> /srv/autobuild-ceph/gitbuilder.git/build/install-deps.sh
> sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.6 60 --slave /usr/bin/g++ g++ /usr/bin/g++-4.6
> sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.8 40 --slave /usr/bin/g++ g++ /usr/bin/g++-4.8
> echo 2 | sudo update-alternatives --config gcc
> sudo restart autobuild-ceph
> 
> We'll need to do something similar on centos6 to get g++ 4.7 or 4.8 in 
> place, and the jenkins slaves for release builds will also need to be 
> updated.
> 
> Assuming this doesn't cause problems (e.g., runtime issues on vanilla 
> precise) this will have no bearing on the previous discussion about 
> whether we continue supporting old distros for future releases.

Well, I spoke too soon.  The builds still aren't completing (the 
older boost's shared_ptr is buggy on c++11, and I'm not sure we can 
upgrade since some of it is dynamically linked).  Also, when you try to 
install packages built with gcc 4.8 (regardless of the branch), you get

2015-08-08T11:28:45.471 INFO:teuthology.orchestra.run.plana89.stdout: ceph 
: Depends: libstdc++6 (>= 4.8.1) but 4.6.3-1ubuntu5 is to be installed
2015-08-08T11:28:45.471 INFO:teuthology.orchestra.run.plana89.stdout: 
ceph-test : Depends: libstdc++6 (>= 4.8.1) but 4.6.3-1ubuntu5 is to be 
installed

...which blows.  I think we'd either need to include the 4.8 runtime 
in our repos or require users to add the appropriate APT source.  :(


At this point my vote is to drop precise and el6 entirely for infernalis 
and later.  Someone can always go build themselves and hunt down the 
proper backports but it's not worth our time.

The main downsides here are:

 - There may be precise or el6 users who want infernalis or later.  Given 
what we've seen so far I think there aren't many of these people and 
our time is better spent on other things.

 - We'll need to reimage the precise machines in the upstream QA 
lab.  This effectively means that while we will still build all the 
existing releases on precise and el6, the regression testing will be on 
trusty and centos7.  Given how few bugs we've seen over the last 
couple years that are distro-dependent, and the (un)likelihood of a new 
distro issue arising in a stable branch, I'm okay with this, but want to 
make sure others aren't concerned.  We will still use VMs running those 
distros doing the stable upgrade tests--they just won't get as much stress 
testing on bare metal.

Thoughts?
sage

RE: c++11 merged in master

[Dałek, Piotr]

> -----Original Message-----
> From: ceph-devel-owner@vger.kernel.org [mailto:ceph-devel-
> owner@vger.kernel.org] On Behalf Of Sage Weil
> Sent: Sunday, August 09, 2015 7:39 PM
> 
> [..]
>
> Well, I spoke too soon.  The builds still aren't completing (the older boost's
> shared_ptr is buggy on c++11, and I'm not sure we can upgrade since some
> of it is dynamically linked).  Also, when you try to install packages built with
> gcc 4.8 (regardless of the branch), you get
> 
> 2015-08-08T11:28:45.471 INFO:teuthology.orchestra.run.plana89.stdout:
> ceph
> : Depends: libstdc++6 (>= 4.8.1) but 4.6.3-1ubuntu5 is to be installed
> 2015-08-08T11:28:45.471 INFO:teuthology.orchestra.run.plana89.stdout:
> ceph-test : Depends: libstdc++6 (>= 4.8.1) but 4.6.3-1ubuntu5 is to be
> installed
> 
> ...which blows.  I think we'd either need to include the 4.8 runtime in our
> repos or require users to add the appropriate APT source.  :(
> 
> At this point my vote is to drop precise and el6 entirely for infernalis
> and later.  Someone can always go build themselves and hunt down the
> proper backports but it's not worth our time.
> 
> The main downsides here are:
> 
>  - There may be precise or el6 users who want infernalis or later.  Given
> what we've seen so far I think there aren't many of these people and
> our time is better spent on other things.
>
> [..]
> 
> Thoughts?
> sage

I'm pretty sure there will be a lot of users (and direct or indirect customers) being forced to use el6, so they won't get Infernalis. I'm not sure about the Red Hat's stance on this, and we probably need their opinion here. For us (Fujitsu) it'll be a huge issue, as we're relying on CentOS 6 and moving to 7 *will* be a huge amount of work, not to mention that we will have to support both CentOS 6 (for existing and near-future customers) and CentOS 7 (for future customers once we make the switch). Probably inevitable, but still a huge pain.
My suggestion is that the current LTS release could have more of "L" in the "LTS" than others, so companies like ours will have more time to switch and still benefit from any fixes community (including us) provide. 


With best regards / Pozdrawiam
Piotr Dałek


--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html