10:41 a.m.
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.
--
Stephen J Smoogen.
3:45 a.m.
On Fri, Jan 26, 2018 at 4:41 PM, Stephen John Smoogen <smooge(a)gmail.com> wrote:
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?
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:
1. 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]
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.
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.
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
12:34 p.m.
On 27 January 2018 at 04:45, Peter Robinson <pbrobinson(a)gmail.com> wrote:
On Fri, Jan 26, 2018 at 4:41 PM, Stephen John Smoogen
<smooge(a)gmail.com>
wrote:
> 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 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(a)lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave(a)lists.fedoraproject.org
--
Stephen J Smoogen.
2:41 p.m.
Stephen John Smoogen wrote:
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.
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.
--
Todd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A statesman is a dead politician. Lord knows, we need more statesmen.
-- Opus
2:54 p.m.
On 27 January 2018 at 15:41, Todd Zullinger <tmz(a)pobox.com> wrote:
Stephen John Smoogen wrote:
> 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.
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 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_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.
I thought aarch64 was also supported for this.
--
Stephen J Smoogen.
5:45 p.m.
Stephen John Smoogen wrote:
On 27 January 2018 at 15:41, Todd Zullinger <tmz(a)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_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.
>
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,
--
Todd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Reality is that which, when you stop believing in it, doesn't go away.
-- Philip K. Dick
6:25 p.m.
On 27 January 2018 at 18:45, Todd Zullinger <tmz(a)pobox.com> wrote:
Stephen John Smoogen wrote:
> On 27 January 2018 at 15:41, Todd Zullinger <tmz(a)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.
--
Stephen J Smoogen.
8:57 a.m.
On Sat, Jan 27, 2018 at 4:45 PM, Todd Zullinger <tmz(a)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
9:53 a.m.
On 31 January 2018 at 09:57, Ken Dreyer <ktdreyer(a)ktdreyer.com> wrote:
On Sat, Jan 27, 2018 at 4:45 PM, Todd Zullinger <tmz(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave(a)lists.fedoraproject.org
--
Stephen J Smoogen.
5:36 a.m.
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
9:40 a.m.
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.
--
Todd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Health is merely the slowest possible rate at which one can die.
11:48 a.m.
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
11:12 a.m.
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.
--
Todd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The only difference between a rut and a grave is the depth.
4:24 p.m.
On 27 January 2018 at 13:34, Stephen John Smoogen <smooge(a)gmail.com> wrote:
On 27 January 2018 at 04:45, Peter Robinson <pbrobinson(a)gmail.com> wrote:
>
> On Fri, Jan 26, 2018 at 4:41 PM, Stephen John Smoogen <smooge(a)gmail.com>
> wrote:
> > 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 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.
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.
--
Stephen J Smoogen.
9:47 a.m.
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
10:36 a.m.
> 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
6:09 p.m.
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
12:39 p.m.
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(a)lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave(a)lists.fedoraproject.org
--
Stephen J Smoogen.
2239
days inactive
2279
days old
epel-devel@lists.fedoraproject.org
17 comments
6 participants
participants (6)
-
Ken Dreyer -
Kevin Fenzi -
Peter Robinson -
Stephen John Smoogen -
Todd Zullinger -
Tom Callaway