On 02/27/2016 09:57 PM, Dave Johansen wrote:
On Fri, Feb 26, 2016 at 10:38 PM, Dave Johansen <[email protected] <mailto:[email protected]>> wrote:On Fri, Feb 26, 2016 at 10:12 PM, Dave Johansen <[email protected] <mailto:[email protected]>> wrote: On Wed, Jan 20, 2016 at 10:07 AM, Honza Horak <[email protected] <mailto:[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]> <mailto:[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]>> <mailto:[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]>>> <mailto:[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.
Do you think sources from devtoolset-3 could be used? https://github.com/sclorg-distgit/felix-gogo-parent/tree/sig-sclo6-devtoolset-3-rh Honza _______________________________________________ SCLorg mailing list [email protected] https://www.redhat.com/mailman/listinfo/sclorg
