[scl.org] devtoolset 2?

Honza Horak hhorak at redhat.com
Wed Jan 20 17:07:58 UTC 2016


On 01/13/2016 05:14 AM, Dave Johansen wrote:
> On Wed, Jan 6, 2016 at 1:47 PM, Honza Horak <hhorak at redhat.com
> <mailto:hhorak at redhat.com>> wrote:
>
>     On 01/06/2016 05:41 PM, Dave Johansen wrote:
>
>         On Wed, Jan 6, 2016 at 8:04 AM, Honza Horak <hhorak at redhat.com
>         <mailto:hhorak at redhat.com>
>         <mailto:hhorak at redhat.com <mailto: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>
>                  <mailto:hhorak at redhat.com <mailto:hhorak at redhat.com>>
>                  <mailto:hhorak at redhat.com <mailto:hhorak at redhat.com>
>         <mailto: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?
>
>
>     Well, why not, I can add you as collaborator in this project -- what
>     is your copr username? However, I'm afraid that whoever tried that,
>     he got blocked on some non easy issues, which is the reason why it
>     is not finished.
>
>
> My username is daveisfera.

Well, I've realized the copr is not named devtoolset-2, but just 
devtoolset, which is not ideal.. and renaming is not possible in copr.. 
maybe it would be better if you'd create your own copr, which has 
correct name..

> Is there anything special that needs to be done to do these builds?

Honestly, I don't know what is necessary to fix the builds, but since 
they were failing, I expect something would need to be fixed.

> Is there an original location for the source rpms? And is this COPR use
> those or some modification of them?

The sources are available here:
http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/RHDevToolset/SRPMS/

Again, I don't know unfortunately, whether there were already some 
modifications done, sorry.

Honza




More information about the SCLorg mailing list