[scl.org] devtoolset 2?

Dave Johansen davejohansen at gmail.com
Wed Jan 6 16:41:29 UTC 2016


On Wed, Jan 6, 2016 at 8:04 AM, Honza Horak <hhorak at redhat.com> wrote:

> On 01/05/2016 04:35 PM, Dave Johansen wrote:
>
>> On Tue, Jan 5, 2016 at 8:30 AM, Honza Horak <hhorak at redhat.com
>> <mailto:hhorak at redhat.com>> wrote:
>>
>>     Interesting, you're first who asks for that. Currently, there is
>>     nobody working on it.
>>
>>
>> We're working on moving to EL 7, but still need to support EL 6
>> installations. We'd also like to start allowing use of C++11 in our code
>> base and using the same version of gcc on both EL 6 and 7 seemed like
>> the best way to accomplish both of these goals.
>>
>>     If you're willing to try that, I wouldn't be against, I just must
>>     warn you that rebuilding devtoolset is always a lot of fun (like
>>     https://www.redhat.com/archives/sclorg/2015-December/msg00050.html)..
>>
>>
>> What's the best way to start this?
>> Are there modifications that are required for source .rpm (removing
>> RedHat naming, etc)? Or is it just start building it and dealing with
>> the issues that pop up?
>>
>
> There is no need to remove any naming, we usually take srpm from RH and
> rebuild. However, the bootstrapping is usually very challenging. I'd
> recommend first to try to rebuild at least basic packages yourself using
> mock (or copr), so you see how far you can get.. Then, if you'll see it is
> worth the work, we can create tags/targets in CBS and start with real
> rebuilds.
>

I was just going to start playing around with this on COPR and I noticed
that there appears to already be an existing build of devtoolset-2:
https://copr.fedoraproject.org/coprs/rhscl/devtoolset/

It looks like it's not complete because only some of the packages
succeeded, but would that serve as the best starting point? If so, what's
the best way to move forward with that?

Thanks,
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/sclorg/attachments/20160106/63880df9/attachment.htm>


More information about the SCLorg mailing list