On Fri, Feb 26, 2016 at 10:38 PM, Dave Johansen <[email protected]> wrote:
> 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? > It looks like the maven packages are supposed to come from the maven SCL, so never mind about that. On a related note, the odd thing is that some of the apache-common packages are in the devtoolset SCL and other are in maven SCL. It just seems kind of odd to be broken up that way, but whatever works I guess. So, the only real issue seems to be the missing source .rpm for felix-gogo-parent.
_______________________________________________ SCLorg mailing list [email protected] https://www.redhat.com/mailman/listinfo/sclorg
