On Fri, Feb 26, 2016 at 10:12 PM, Dave Johansen <[email protected]> wrote:
> On Wed, Jan 20, 2016 at 10:07 AM, Honza Horak <[email protected]> wrote: > >> On 01/13/2016 05:14 AM, Dave Johansen wrote: >> >>> On Wed, Jan 6, 2016 at 1:47 PM, Honza Horak <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> On 01/06/2016 05:41 PM, Dave Johansen wrote: >>> >>> On Wed, Jan 6, 2016 at 8:04 AM, Honza Horak <[email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> wrote: >>> >>> On 01/05/2016 04:35 PM, Dave Johansen wrote: >>> >>> On Tue, Jan 5, 2016 at 8:30 AM, Honza Horak >>> <[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>> >>> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>>> 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/ >> > > It looks like the source .rpm for felix-gogo-parent is missing. What needs > to happen for that to be added? > Also, it appears that some of them depend on maven plugins that aren't available: https://copr-be.cloud.fedoraproject.org/results/daveisfera/devtoolset2/epel-6-x86_64/00163449-devtoolset-2-apache-commons-codec/root.log.gz What can be done to resolve that? Thanks, Dave
_______________________________________________ SCLorg mailing list [email protected] https://www.redhat.com/mailman/listinfo/sclorg
