Several meetings ago, the EPEL Steering Committee took up the following points:
1. Peter Robinson's DTS enablement request A. What packages require it (chromium etc) B. Is there a version in CentOS? i. If not is it possible for it to exist in CentOS? ii. If not what work would a CentOS version take and how long? iii. If not and not possible does this make EPEL non-workable/closed source on it? C. What problems are known for getting it into Koji i. Does it cause problems with normal packages ii. Do users need to have any bits from it to work? [old yacc/bison problem] iii. Does koji have problems with this as another channel to work with? iv. Does Fedora have the ability to get this channel or need to use a different one (aka CentOS one if it exists)?
==
At that time, EPSCO agreed that we are ok with this for just the development toolkit. We are still needing to work out the following items:
1. How do we do this with mock so that people who rebuild with CentOS can do so. 2. How do we get Koji to do this 3. What are the packaging guidelines that need to be put into EPEL packaging guidelines as the SCL guidelines were never finalized and the devtoolset is an scl that we would be building against.
On Fri, Jan 26, 2018 at 4:41 PM, Stephen John Smoogen smooge@gmail.com wrote:
Several meetings ago, the EPEL Steering Committee took up the following points:
- Peter Robinson's DTS enablement request
A. What packages require it (chromium etc) B. Is there a version in CentOS?
Yes, CentOS builds the DTS and makes it available via the SCL repositories [1]
i. If not is it possible for it to exist in CentOS? ii. If not what work would a CentOS version take and how long? iii. If not and not possible does this make EPEL non-workable/closed source on it?
So because CentOS has it available all 3 of those questions are irrelevant.
C. What problems are known for getting it into Koji i. Does it cause problems with normal packages
No, it doesn't. It doesn't "Provide" any of the core toolchains or any other package so like any other package not in the core build root you need to explicitly add it to the BuildRequires in the package spec file.
ii. Do users need to have any bits from it to work? [old yacc/bison problem]
No, DTS has been available as part of the standard RHEL subscription for _YEARS_ and is in use widely.
iii. Does koji have problems with this as another channel to work with?
No, just like extras/optional and any of the other additional channels it has no impact, users need to explicitly add buildrequires to get any of the packages into their buildroot.
iv. Does Fedora have the ability to get this channel or need to use a different one (aka CentOS one if it exists)?
Yes, it's provided as part of the standard Red Hat el7 subscription. Any RHEL user that had a standard RHEL subscription can add the channel, this is no different from Optional/Extras so no different for any of the other EPEL use cases.
==
At that time, EPSCO agreed that we are ok with this for just the development toolkit. We are still needing to work out the following items:
- How do we do this with mock so that people who rebuild with CentOS can do so.
For RHEL users they need to add the appropriate DTS channels, for CentOS users they just have to follow the details in the CentOS wiki [2]
- How do we get Koji to do this
Add DTS to the sync process, add the new repos for all the supported architectures to the koji external-repos as per Server/Optional/HA/Extras that are already part of the el7.
- What are the packaging guidelines that need to be put into EPEL
packaging guidelines as the SCL guidelines were never finalized and the devtoolset is an scl that we would be building against.
The DTS isn't really a SCL, it's maintained by a completely different team and is released on a different schedule. I would think it would be covered by the same guidelines as the "Extras" repository which, like DTS, provides additional toolchains such as Golang so what were the extra packaging guidelines that were required when Extras were made available in the el7 buildroot?
Any other questions you'd like to use to fillibuster this?
Peter
[1] https://buildlogs.centos.org/centos/7/sclo/ [2] https://wiki.centos.org/AdditionalResources/Repositories/SCL
On 27 January 2018 at 04:45, Peter Robinson pbrobinson@gmail.com wrote:
On Fri, Jan 26, 2018 at 4:41 PM, Stephen John Smoogen smooge@gmail.com wrote:
Several meetings ago, the EPEL Steering Committee took up the following
points:
- Peter Robinson's DTS enablement request
A. What packages require it (chromium etc) B. Is there a version in CentOS?
I am going to try this again because I didn't communicate clearly what was needed to be done now. I also sent an email that wasn't complete and should have caught that.
1. The proposal was accepted. The questions were answered in the meeting and also by Peter outside the meeting. Peter has answered it again because I was not clear.
2. The next step is getting the mock and fedpkg commands to work with the DTS cleanly. This means adding the lines to mock-core-configs package files for to do so. The package seems ot be owned by Releng but I am not sure as zodbot says no such package.
[centos-sclo-sclo] name=CentOS-7 - SCLo sclo baseurl=http://mirror.centos.org/centos/7/sclo/$basearch/sclo/ gpgcheck=1 enabled=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-SCLo
[centos-sclo-rh] name=CentOS-7 - SCLo rh baseurl=http://mirror.centos.org/centos/7/sclo/$basearch/rh/ gpgcheck=1 enabled=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-SCLo
A similar set need to be added to the Koji configs pointing to the copies.
3. Another step is writing up the extra steps needed to set up environments inside an RPM spec file. This just needs to be some text that a packager knows what to say in the spec file sections so that the build works. The instructions in Toshio's draft is for developing RPMs and the other instructions on the other parts were for running it in an interactive shell. Looking at the chromium I see things like:
%if 0%{?rhel} == 7 BuildRequires: devtoolset-7-toolchain, devtoolset-7-libatomic-devel%endif
====
%build
%if 0%{?rhel} == 7 . /opt/rh/devtoolset-7/enable%endif
But I am not sure if that is all the items needed for getting this working. If that is all that is needed does the following text work for the EPEL-7 packaging guidelines?
=== Devtoolset ===
The Developer Toolset that is found in CentOS SCL's and Red Hat subscription can be used as a build requirement in EPEL packages. This will allow packages which require newer gcc and similar tools to build appropriately.
In order to work with these a packager needs to do the following:
1. Add a Build Requires
%if 0%{?rhel} == 7 BuildRequires: devtoolset-7-toolchain, devtoolset-7-libatomic-devel%endif
2. In sections needing compiler or other tools are being used, the packager will need to set up the environment. This can be done via the following lines:
%if 0%{?rhel} == 7 . /opt/rh/devtoolset-7/enable %endif
This will put the newer gcc and other tools earlier in the buildpath and set up any other changes needed.
CAVEAT: EPEL packages may only use devtoolset as a build requirement and not as a Requires. This is because it needs access to extra repositories and channels a user may not wish or be allowed to add to their system.
[1] https://buildlogs.centos.org/centos/7/sclo/ [2] https://wiki.centos.org/AdditionalResources/Repositories/SCL _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org
Stephen John Smoogen wrote:
- The proposal was accepted. The questions were answered in the meeting
and also by Peter outside the meeting. Peter has answered it again because I was not clear.
- The next step is getting the mock and fedpkg commands to work with the
DTS cleanly. This means adding the lines to mock-core-configs package files for to do so. The package seems ot be owned by Releng but I am not sure as zodbot says no such package.
I think the way to get the changes into mock-core-configs is to submit these changes to the mock project directly. Something like this, perhaps:
https://github.com/tmzullinger/mock/commit/d12eaa824
If that seems reasonable I can submit a pull request for more review upstream.
I'm not sure if we want to limit the package set to devtoolset* via includepkgs or not. I did so in the above commit and have tested it very lightly. Restricting the packages may help prevent packages from accidentally pulling in bits from SCLo beyond the intended devtoolset packages.
%if 0%{?rhel} == 7 BuildRequires: devtoolset-7-toolchain, devtoolset-7-libatomic-devel %endif
Technically, can't this be supported in epel-6 as well? (Please pardon me if I have overlooked a decision to only support DTS in epel-7.)
We'll also have to limit this to x86_64, won't we? I didn't see any other architectures with SCLo support in CentOS. If I've overlooked them and someone can point me to them, that would be great. If not, we'll just want to append
&& %{_arch} == x86_64
Maybe a macro can be added to epel-rpm-macros simplify this. That would be one place to edit if/when additional relases and architectures are added to SCLo.
On 27 January 2018 at 15:41, Todd Zullinger tmz@pobox.com wrote:
Stephen John Smoogen wrote:
- The proposal was accepted. The questions were answered in the meeting
and also by Peter outside the meeting. Peter has answered it again
because
I was not clear.
- The next step is getting the mock and fedpkg commands to work with the
DTS cleanly. This means adding the lines to mock-core-configs package
files
for to do so. The package seems ot be owned by Releng but I am not sure
as
zodbot says no such package.
I think the way to get the changes into mock-core-configs is to submit these changes to the mock project directly. Something like this, perhaps:
https://github.com/tmzullinger/mock/commit/d12eaa824If that seems reasonable I can submit a pull request for more review upstream.
I'm not sure if we want to limit the package set to devtoolset* via includepkgs or not. I did so in the above commit and have tested it very lightly. Restricting the packages may help prevent packages from accidentally pulling in bits from SCLo beyond the intended devtoolset packages.
If that works, I don't have a problem with that.
%if 0%{?rhel} == 7 BuildRequires: devtoolset-7-toolchain, devtoolset-7-libatomic-devel %endif
Technically, can't this be supported in epel-6 as well? (Please pardon me if I have overlooked a decision to only support DTS in epel-7.)
I don't know of any reason it would not work in EL-6 either. The spec files I found using devtool-set only set it to rhel 7.
We'll also have to limit this to x86_64, won't we? I didn't see any other architectures with SCLo support in CentOS. If I've overlooked them and someone can point me to them, that would be great. If not, we'll just want to append
&& %{_arch} == x86_64Maybe a macro can be added to epel-rpm-macros simplify this. That would be one place to edit if/when additional relases and architectures are added to SCLo.
I thought aarch64 was also supported for this.
Stephen John Smoogen wrote:
On 27 January 2018 at 15:41, Todd Zullinger tmz@pobox.com wrote:
I'm not sure if we want to limit the package set to devtoolset* via includepkgs or not. I did so in the above commit and have tested it very lightly. Restricting the packages may help prevent packages from accidentally pulling in bits from SCLo beyond the intended devtoolset packages.
If that works, I don't have a problem with that.
I think it does, but I worry that I'm missing some oddity in yum/dnf/mock parsing of the single config file. I tested with mock-1.4.8 on Fedora 26. Moving the epel repo section after the sclo* repos I was still able to install epel packages. I was worried that the includepkgs might not be properly limited to the sclo repos, but it seems like it is. It's easy enough to remove it if that proves incorrect with wider testing.
Technically, can't this be supported in epel-6 as well? (Please pardon me if I have overlooked a decision to only support DTS in epel-7.)
I don't know of any reason it would not work in EL-6 either. The spec files I found using devtool-set only set it to rhel 7.
Yeah, I imagine we're at the point where most people building things which require a newer compiler are moving to EL-7. I could have used it while trying to build znc-1.6 for EL-6 a year or so ago.
(I ended up building znc with clang instead. I was going to send the patch to the znc maintainers in EPEL, but it got dropped in EL-6 before I had time to do so.)
We'll also have to limit this to x86_64, won't we? I didn't see any other architectures with SCLo support in CentOS. If I've overlooked them and someone can point me to them, that would be great. If not, we'll just want to append
&& %{_arch} == x86_64Maybe a macro can be added to epel-rpm-macros simplify this. That would be one place to edit if/when additional relases and architectures are added to SCLo.
I thought aarch64 was also supported for this.
It looks like the devtoolset bits are still in the sclo testing repositories for aarch64¹. We could potentially enable those in the mock configs if they're ready for more testing. Or we can wait for them to reach stable.
If we end up with some macro to enable things, then we'd just have to update epel-rpm-macros and the next builds of packages which use them would work for aarch64. I'm sure the various arch support across RHEL/CentOS/EPEL is a lot of fun for everyone.
¹ https://www.softwarecollections.org/en/scls/rhscl/devtoolset-7/
Thanks,
On 27 January 2018 at 18:45, Todd Zullinger tmz@pobox.com wrote:
Stephen John Smoogen wrote:
On 27 January 2018 at 15:41, Todd Zullinger tmz@pobox.com wrote:
I'm not sure if we want to limit the package set to devtoolset* via includepkgs or not. I did so in the above commit and have tested it very lightly. Restricting the packages may help prevent packages from accidentally pulling in bits from SCLo beyond the intended devtoolset packages.
If that works, I don't have a problem with that.
I think it does, but I worry that I'm missing some oddity in yum/dnf/mock parsing of the single config file. I tested with mock-1.4.8 on Fedora 26. Moving the epel repo section after the sclo* repos I was still able to install epel packages. I was worried that the includepkgs might not be properly limited to the sclo repos, but it seems like it is. It's easy enough to remove it if that proves incorrect with wider testing.
Technically, can't this be supported in epel-6 as well? (Please pardon me if I have overlooked a decision to only support DTS in epel-7.)
I don't know of any reason it would not work in EL-6 either. The spec
files
I found using devtool-set only set it to rhel 7.
Yeah, I imagine we're at the point where most people building things which require a newer compiler are moving to EL-7. I could have used it while trying to build znc-1.6 for EL-6 a year or so ago.
(I ended up building znc with clang instead. I was going to send the patch to the znc maintainers in EPEL, but it got dropped in EL-6 before I had time to do so.)
I don't think it would be a problem, and may be useful for EL-6 as we still have more EL-6 users than EL-7 users. That said, I am also not wanting to break the world here. If people with more experience with the devtoolset think it would make things harder in EL-6 or would need other flags to work.. we can put them in the appropriate section.
On Sat, Jan 27, 2018 at 4:45 PM, Todd Zullinger tmz@pobox.com wrote:
Stephen John Smoogen wrote:
I thought aarch64 was also supported for this.
It looks like the devtoolset bits are still in the sclo testing repositories for aarch64¹. We could potentially enable those in the mock configs if they're ready for more testing. Or we can wait for them to reach stable.
Yeah, I wish this was more widely documented, but CentOS' DTS 7 is now built for ppc64le and aarch64.
https://bugs.centos.org/view.php?id=14078
- Ken
On 31 January 2018 at 09:57, Ken Dreyer ktdreyer@ktdreyer.com wrote:
On Sat, Jan 27, 2018 at 4:45 PM, Todd Zullinger tmz@pobox.com wrote:
Stephen John Smoogen wrote:
I thought aarch64 was also supported for this.
It looks like the devtoolset bits are still in the sclo testing repositories for aarch64¹. We could potentially enable those in the mock configs if they're ready for more testing. Or we can wait for them to reach stable.
Yeah, I wish this was more widely documented, but CentOS' DTS 7 is now built for ppc64le and aarch64.
So we have a problem with what is the canonical place for SCL's. I was going from http://mirror.centos.org/centos/7/sclo/ which just says x86_64.
There are parts built in CBS but it isn't clear that these are any more official than a Fedora COPR... I will let someone with releng experience say whether that is ok or not.
https://bugs.centos.org/view.php?id=14078
- Ken
epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org
On 01/31/2018 10:53 AM, Stephen John Smoogen wrote:
So we have a problem with what is the canonical place for SCL's. I was going from http://mirror.centos.org/centos/7/sclo/ which just says x86_64.
Even just getting x86_64 devtoolset into the potential buildroot for EPEL would be hugely helpful to me, because that's all chromium cares about right now.
~tom
Tom "spot" Callaway wrote:
On 01/31/2018 10:53 AM, Stephen John Smoogen wrote:
So we have a problem with what is the canonical place for SCL's. I was going from http://mirror.centos.org/centos/7/sclo/ which just says x86_64.
Even just getting x86_64 devtoolset into the potential buildroot for EPEL would be hugely helpful to me, because that's all chromium cares about right now.
I filed a pull request to update mock-core-configs:
https://github.com/rpm-software-management/mock/pull/159
If anyone here knows relevant folks on the SCL team who can provide some input on the preferred/canonical repository URLs (or any other issues with that PR), it would be great.
I tend to think that the mock configs we ship should use whatever URLs the centos-release-scl{,-rh} packages use. That's what end-users would see if they wanted to rebuild packages outside of mock. If those change we can always update them in mock-core-configs to match.
On 02/01/2018 07:40 AM, Todd Zullinger wrote:
Tom "spot" Callaway wrote:
On 01/31/2018 10:53 AM, Stephen John Smoogen wrote:
So we have a problem with what is the canonical place for SCL's. I was going from http://mirror.centos.org/centos/7/sclo/ which just says x86_64.
Even just getting x86_64 devtoolset into the potential buildroot for EPEL would be hugely helpful to me, because that's all chromium cares about right now.
I filed a pull request to update mock-core-configs:
https://github.com/rpm-software-management/mock/pull/159
If anyone here knows relevant folks on the SCL team who can provide some input on the preferred/canonical repository URLs (or any other issues with that PR), it would be great.
I tend to think that the mock configs we ship should use whatever URLs the centos-release-scl{,-rh} packages use. That's what end-users would see if they wanted to rebuild packages outside of mock. If those change we can always update them in mock-core-configs to match.
Well, that will help people who do local mock builds, but won't do anything for koji/epel. ;)
I think at this point it just needs someone to do the setup, and I think Peter said he could. If not, I can put it on my list, but not sure when I would get to it.
kevin
Kevin Fenzi wrote:
On 02/01/2018 07:40 AM, Todd Zullinger wrote:
Tom "spot" Callaway wrote:
On 01/31/2018 10:53 AM, Stephen John Smoogen wrote:
So we have a problem with what is the canonical place for SCL's. I was going from http://mirror.centos.org/centos/7/sclo/ which just says x86_64.
Even just getting x86_64 devtoolset into the potential buildroot for EPEL would be hugely helpful to me, because that's all chromium cares about right now.
I filed a pull request to update mock-core-configs:
https://github.com/rpm-software-management/mock/pull/159
If anyone here knows relevant folks on the SCL team who can provide some input on the preferred/canonical repository URLs (or any other issues with that PR), it would be great.
I tend to think that the mock configs we ship should use whatever URLs the centos-release-scl{,-rh} packages use. That's what end-users would see if they wanted to rebuild packages outside of mock. If those change we can always update them in mock-core-configs to match.
Well, that will help people who do local mock builds, but won't do anything for koji/epel. ;)
Of course. :)
Doing the mock part takes a little off the plate of the folks who have access to make the changes in koji/epel.
More important, I think, is ensuring that local mock builds, koji/epel builds, and plain old local rpmbuild builds work as similarly as possible. The mock-core-config changes were merged the other day, so with the next release we should see devtoolset enabled in mock for x86_64. If/when other arches move out of testing on CentOS and RHEL we'll just have to update the mock configs.
I think at this point it just needs someone to do the setup, and I think Peter said he could. If not, I can put it on my list, but not sure when I would get to it.
Cool, thanks.
On 27 January 2018 at 13:34, Stephen John Smoogen smooge@gmail.com wrote:
On 27 January 2018 at 04:45, Peter Robinson pbrobinson@gmail.com wrote:
On Fri, Jan 26, 2018 at 4:41 PM, Stephen John Smoogen smooge@gmail.com wrote:
Several meetings ago, the EPEL Steering Committee took up the following points:
- Peter Robinson's DTS enablement request
A. What packages require it (chromium etc) B. Is there a version in CentOS?
I am going to try this again because I didn't communicate clearly what was needed to be done now. I also sent an email that wasn't complete and should have caught that.
- The proposal was accepted. The questions were answered in the meeting and
also by Peter outside the meeting. Peter has answered it again because I was not clear.
- The next step is getting the mock and fedpkg commands to work with the
DTS cleanly. This means adding the lines to mock-core-configs package files for to do so. The package seems ot be owned by Releng but I am not sure as zodbot says no such package.
Status Report:
I have gotten scl's for RH PPCLE and x86_64 downloaded to the Fedora Infrastructure batcave. I have not been able to get aarch64 downloaded. I need help here on getting the cdn address correct.
I need someone from releng (I guess it would be Peter?) to help us enable this in koji.
After that dts should be ready for updates.
On 02/07/2018 05:24 PM, Stephen John Smoogen wrote:
Status Report:
I have gotten scl's for RH PPCLE and x86_64 downloaded to the Fedora Infrastructure batcave. I have not been able to get aarch64 downloaded. I need help here on getting the cdn address correct.
I need someone from releng (I guess it would be Peter?) to help us enable this in koji.
After that dts should be ready for updates.
Any updates? :)
~tom
I have gotten scl's for RH PPCLE and x86_64 downloaded to the Fedora Infrastructure batcave. I have not been able to get aarch64 downloaded. I need help here on getting the cdn address correct.
I need someone from releng (I guess it would be Peter?) to help us enable this in koji.
After that dts should be ready for updates.
Any updates? :)
Sorry, I took the action to sort out the aarch64 DTS and to close out the rest to get it enabled in koji. Had other deadlines in the last week or so that took priority, those are now done (as of about 90 mins ago) so I'll finish this up this afternoon and reply to this mail once complete.
P
On 02/14/2018 08:36 AM, Peter Robinson wrote:
I have gotten scl's for RH PPCLE and x86_64 downloaded to the Fedora Infrastructure batcave. I have not been able to get aarch64 downloaded. I need help here on getting the cdn address correct.
I need someone from releng (I guess it would be Peter?) to help us enable this in koji.
After that dts should be ready for updates.
Any updates? :)
Sorry, I took the action to sort out the aarch64 DTS and to close out the rest to get it enabled in koji. Had other deadlines in the last week or so that took priority, those are now done (as of about 90 mins ago) so I'll finish this up this afternoon and reply to this mail once complete.
ok, with many thanks to Peter and Smooge we finally have this enabled.
You should be able to use devtoolset now in specs.
Note that we have only approved devtoolset use currently, so please don't use other SCLs at least yet. In tomorrow's meeting we should discuss them.
IMHO, I would prefer to allow any scl that has no runtime dependency on SCLs. ie, users can install and use it as they do now. If we ship things that do have runtime dependencies on SCLs we need to make sure they can install those (ie, how do they enable them in CentOS? In RHEL? what error(s) would they get).
kevin
Any other questions you'd like to use to fillibuster this?
I messed up and was unclear. I was not meaning to fillibuster but I see how it came across as that.
Peter
[1] https://buildlogs.centos.org/centos/7/sclo/ [2] https://wiki.centos.org/AdditionalResources/Repositories/SCL _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org
epel-devel@lists.fedoraproject.org
-
Ken Dreyer -
Kevin Fenzi -
Peter Robinson -
Stephen John Smoogen -
Todd Zullinger -
Tom Callaway