On Wednesday, 31 August 2016 at 10:58, dani wrote:
[...]
> As far as i could tell, the main argument against my scheme was usage of
> /opt, yet it is approved for scl, despite scl's limitations.
SCL was never approved for Fedora. It's something that Red Hat provides
in their products only.
> I'm
On 31 August 2016 at 04:58, dani wrote:
>
>
> On 29/08//2016 22:23, Jason L Tibbitts III wrote:
>>>
>>> "d" == dani writes:
>>
>> d> I think it is high time to rethink the single version of a package
>> d> policy, and come up with some scheme that
On 29/08//2016 22:23, Jason L Tibbitts III wrote:
"d" == dani writes:
d> I think it is high time to rethink the single version of a package
d> policy, and come up with some scheme that would allow for any package
d> to maintain multiple versions in a consistent manner.
> "d" == dani writes:
d> I think it is high time to rethink the single version of a package
d> policy, and come up with some scheme that would allow for any package
d> to maintain multiple versions in a consistent manner.
We don't have such a policy. At least Fedora
On 27/08//2016 01:38, Neal Gompa wrote:
On Fri, Aug 26, 2016 at 6:24 PM, dani wrote:
I think it is high time to rethink the single version of a package policy,
and come up with some scheme that would allow for any package to maintain
On 16/08/16 06:24, Tom Callaway wrote:
> I'd like to propose that we enable the Developer Toolset repo in EPEL
> and allow packages to depend on it. Thoughts?
There is one issue with this that I don't think others have addressed
yet on this list. EPEL 6 supports i686 as a build target, but
On Fri, Aug 26, 2016 at 6:24 PM, dani wrote:
>
> I think it is high time to rethink the single version of a package policy,
> and come up with some scheme that would allow for any package to maintain
> multiple versions in a consistent manner.
We wouldn't even be the first
On 26 August 2016 at 12:58, Stephen John Smoogen wrote:
> On 26 August 2016 at 06:00, Daniel Letai wrote:
>>
>>
>> On 08/25/2016 11:40 PM, Kevin Fenzi wrote:
>>
>> Perhaps you could explain exactly what you want to propose here again?
>> Just epel6? or 7 as
On Thu, 25 Aug 2016 15:04:58 -0600
Dave Johansen wrote:
> On Thu, Aug 25, 2016 at 2:34 PM, Kevin Fenzi wrote:
>
> > On Wed, 24 Aug 2016 21:59:55 -0600
> > Dave Johansen wrote:
> >
> > > I agree that how to handle SCLs can get
On 08/25/2016 11:40 PM, Kevin Fenzi wrote:
Perhaps you could explain exactly what you want to propose here again?
Just epel6? or 7 as well? Do you have co-maintainers in case you get
busy, etc?
I propose adding several gnu packages (namely gcc, binutils and gdb)
with versions following those
On Thu, Aug 25, 2016 at 2:34 PM, Kevin Fenzi wrote:
> On Wed, 24 Aug 2016 21:59:55 -0600
> Dave Johansen wrote:
>
> > I agree that how to handle SCLs can get really mess really fast, but
> > a lot of projects are jumping on the "modern C++" bandwagon and
On Thu, 25 Aug 2016 12:52:46 -0400
Stephen John Smoogen wrote:
> On 25 August 2016 at 02:14, dani wrote:
> > When I proposed importing gcc-5 to EPEL6 back in 04/2016 (
> >
On Wed, 24 Aug 2016 21:59:55 -0600
Dave Johansen wrote:
> I agree that how to handle SCLs can get really mess really fast, but
> a lot of projects are jumping on the "modern C++" bandwagon and
> allows devtoolset is low risk, easy to do and enables a lot of
> packages to
On 25 August 2016 at 12:49, Stephen John Smoogen wrote:
> On 24 August 2016 at 23:59, Dave Johansen wrote:
>> On Wed, Aug 24, 2016 at 5:28 PM, Kevin Fenzi wrote:
>>
>> I agree that how to handle SCLs can get really mess really fast,
On 25 August 2016 at 02:14, dani wrote:
> When I proposed importing gcc-5 to EPEL6 back in 04/2016 (
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/F5JXEYPKQY77NRBCL4MNUBS3K2YYBBTU/
> ) the response was an unequivocal no, EPEL does
On 24 August 2016 at 23:59, Dave Johansen wrote:
> On Wed, Aug 24, 2016 at 5:28 PM, Kevin Fenzi wrote:
>>
>> On Wed, 24 Aug 2016 16:43:31 -0600
>> Dave Johansen wrote:
>>
>> > On Wed, Aug 24, 2016 at 4:22 PM, Kevin Fenzi
When I proposed importing gcc-5 to EPEL6 back in 04/2016 (
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/F5JXEYPKQY77NRBCL4MNUBS3K2YYBBTU/
) the response was an unequivocal no, EPEL does not install to /opt/ ,
so it dies right there.
Now you are
On Wed, Aug 24, 2016 at 5:28 PM, Kevin Fenzi wrote:
> On Wed, 24 Aug 2016 16:43:31 -0600
> Dave Johansen wrote:
>
> > On Wed, Aug 24, 2016 at 4:22 PM, Kevin Fenzi wrote:
> >
> > > On Tue, 23 Aug 2016 14:21:24 +0100
> > > Karanbir Singh
On Wed, 24 Aug 2016 16:43:31 -0600
Dave Johansen wrote:
> On Wed, Aug 24, 2016 at 4:22 PM, Kevin Fenzi wrote:
>
> > On Tue, 23 Aug 2016 14:21:24 +0100
> > Karanbir Singh wrote:
> >
> > > On 22/08/16 18:30, Jason L Tibbitts III
On Wed, Aug 24, 2016 at 4:22 PM, Kevin Fenzi wrote:
> On Tue, 23 Aug 2016 14:21:24 +0100
> Karanbir Singh wrote:
>
> > On 22/08/16 18:30, Jason L Tibbitts III wrote:
> > >> "DJ" == Dave Johansen writes:
> > >
> > > DJ>
On Tue, 23 Aug 2016 14:21:24 +0100
Karanbir Singh wrote:
> On 22/08/16 18:30, Jason L Tibbitts III wrote:
> >> "DJ" == Dave Johansen writes:
> >
> > DJ> devtoolset is designed to do all of this and is already done,
> > DJ> so it seems that
On Mon, Aug 22, 2016 at 11:30 AM, Jason L Tibbitts III
wrote:
> > "DJ" == Dave Johansen writes:
>
> DJ> devtoolset is designed to do all of this and is already done, so it
> DJ> seems that the only advantage to putting it in EPEL itself would be
>
> "DJ" == Dave Johansen writes:
DJ> devtoolset is designed to do all of this and is already done, so it
DJ> seems that the only advantage to putting it in EPEL itself would be
DJ> to reduce the number of repos during build time.
So is devtoolset something I get
On Tue, Aug 16, 2016 at 11:07 AM, Kevin Fenzi wrote:
> On Mon, 15 Aug 2016 14:24:21 -0400
> Tom Callaway wrote:
>
> > Recently, I've been participating in some discussion as to how to
> > enable C++11 support for EPEL builds. Specifically, R (and its large
On Mon, 15 Aug 2016 14:24:21 -0400
Tom Callaway wrote:
> Recently, I've been participating in some discussion as to how to
> enable C++11 support for EPEL builds. Specifically, R (and its large
> universe of addons in CRAN) would benefit significantly from C++11
> support.
>
On Mon, Aug 15, 2016 at 2:40 PM, Dave Johansen wrote:
> On Mon, Aug 15, 2016 at 12:24 PM, Tom Callaway wrote:
>>
>> Recently, I've been participating in some discussion as to how to enable
>> C++11 support for EPEL builds. Specifically, R (and its
On Mon, Aug 15, 2016 at 12:24 PM, Tom Callaway wrote:
> Recently, I've been participating in some discussion as to how to enable
> C++11 support for EPEL builds. Specifically, R (and its large universe
> of addons in CRAN) would benefit significantly from C++11 support.
>
>
27 matches
Mail list logo