sclorg-distgit-download.yml#L59
)
Cheers,
Nick.
P.S. If anyone would like to take over pyscl-devel development with a view
to making maintenance of the Python SCLs more automated (and easier to
contribute to), just let me know and I'll unarchive the repo.
--
Nick Coghlan | ncogh...
Hi folks,
A while back I started working on a rolling release Python SCL to track the
latest stable release of CPython: https://github.com/ncoghlan/pyscl-devel
While I got a fully automated build running locally in mock, the release
field modification trick I used to handle bootstrapping new feat
tinfo/distutils-sig
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg
On Thu, Oct 5, 2017 at 3:39 PM, Remi Collet wrote:
> Le 05/10/2017 à 06:25, Nick Coghlan a écrit :
>> P.S. I'm not sure when it's expected that the CentOS rebuilds of the
>> RHSCL 3.0 collections will be available through
>> softwarecollections.org
>
> AFAI
-devel/ to work with
3.6 instead would probably be the most reliable way to include
everything needed.
Cheers,
Nick.
P.S. I'm not sure when it's expected that the CentOS rebuilds of the
RHSCL 3.0 collections will be available through
softwarecollections.org
--
Nick Coghlan
Red Ha
o ensure you have the necessary pieces (since the
script uses `fedpkg` in addition to `mock`).
If you're on RHEL or CentOS, you'll need to get `fedpkg` from EPEL instead.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Platform Engineering, Brisbane
___
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg
On Tue, Sep 19, 2017 at 5:31 PM, Petr Kubat wrote:
> On 09/19/2017 08:16 AM, Nick Coghlan wrote:
>> I couldn't find anything in sclorg-distgit
>> that actually *sets* them for the rh-python35 case.
>>
>>
>> https://github.com/sclorg-distgit/rh-
On Mon, Sep 18, 2017 at 9:29 PM, Honza Horak wrote:
> On 09/18/2017 07:29 AM, Nick Coghlan wrote:
>> 2. Assuming I haven't missed anything, how do the *default* values for
>> "scl" and "vendorscl" actually get set?
>
> We can kinda control what
extra
RPM build options for COPR builds? (it would make sense to me that I
can't - the build isn't going to very repeatable if I can run it with
different non-default settings each time)
2. Assuming I haven't missed anything, how do the *default* values for
"scl" and
On Thu, Jul 13, 2017 at 5:18 PM, Nick Coghlan wrote:
> On Wed, Jul 12, 2017 at 4:22 PM, Nick Coghlan wrote:
>> I wasn't planning to publish the COPR builds anywhere other than COPR,
>> they'd just be a place for me to tinker with things before pushing
>> them
top of. That kind of work makes for a
decent job, but a fairly lousy volunteer activity :)
Cheers,
Nick.
--
Nick Coghlan
Red Hat Platform Engineering, Brisbane
___
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg
On Fri, Jul 14, 2017 at 2:36 AM, Jarek Polok wrote:
> If there is some interest we could make these available
> to everybody as pythonXXmore collections for 6 and 7 ?
> (similar to phpXXmore collections)
>
> Your opinion ?
+1, sounds like a good idea to me.
Cheers,
Nick.
--
N
h some suitable documentation updates.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Platform Engineering, Brisbane
___
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg
On Wed, Jul 12, 2017 at 4:22 PM, Nick Coghlan wrote:
> On Tue, Jul 11, 2017 at 11:39 PM, Honza Horak wrote:
>> This guide is actually not complete, as I've just realized -- copr is only
>> one way to build SCLs for www.softwarecollections.org, but we can include
>> SCL
On Tue, Jul 11, 2017 at 11:39 PM, Honza Horak wrote:
> On 07/11/2017 10:44 AM, Nick Coghlan wrote:
>> 1. Create a new sclo-python metapackage, using
>> https://github.com/sclorg-distgit/rh-python35/tree/master as a
>> starting point
>> 2. For now, just create a `sig-sc
On Mon, Jul 3, 2017 at 3:47 PM, Nick Coghlan wrote:
> On Fri, Jun 30, 2017 at 1:24 AM, Davis, Daniel (NIH/NLM) [C]
> wrote:
>> I’ve been lurking on this list for a while, and I wanted to bring myself up
>> to date. I noticed some talk of a community SCL for a “latest” Python,
the 3.6 -> 3.7 switch comes around and they
happened to be relying on a previously deprecated feature that had
finally been removed.
--
Nick Coghlan
Red Hat Platform Engineering, Brisbane
___
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg
hrough the list of tasks at
https://wiki.centos.org/SpecialInterestGroup/SCLo#head-b408f06ad89fd3a67686f755eafac7ce310ee081
(using the rh-python35 collection as a starting point)
Cheers,
Nick.
--
Nick Coghlan
Red Hat Platform Engineering, Brisbane
___
larity/
As a trade-off though, going down that path is requiring changes to
the package management system in Fedora itself, so it isn't readily
usable atop existing systems the way SCLs are.
--
Nick Coghlan
Red Hat Platform Engineering, Brisbane
___
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg
On Wed, May 10, 2017 at 3:37 PM, Nick Coghlan wrote:
> To provide an indicative timeline for this: I'm currently trying to
> get PEP 538's locale coercion squared away for Python 3.7 before
> Fedora 26 hits code freeze, and then will be busy with proposal
> reviews f
On Wed, May 3, 2017 at 10:35 PM, Nick Coghlan wrote:
> On Wed, May 3, 2017 at 9:44 PM, Tomas Orsava wrote:
>> I do see the benefits of the added rolling SCL, though in my mind the
>> benefits are lessened by the pre-existence of Python 3 in EPEL, and thus I'm
>> not
On Wed, May 3, 2017 at 9:44 PM, Tomas Orsava wrote:
> On 05/03/2017 09:13 AM, Nick Coghlan wrote:
>>> On 04/11/2017 10:24 AM, Nick Coghlan wrote:
>> While I thought this sounded reasonable at the time, it turns out to
>> have a lot of problems in practice, as it makes it h
On Fri, Apr 14, 2017 at 12:27 AM, Tomas Orsava wrote:
> Hi!
>
> On 04/11/2017 10:24 AM, Nick Coghlan wrote:
>>
>> I've been mulling this idea over for the past couple of weeks, and I'm
>> wondering if it might make sense to create a rolling "sclo-pyt
ki text is being reviewed at the moment.
The main description has been approved now, the tooltip is just
waiting for a 3rd reviewer to give it the thumbs up.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Platform Engineering, Brisbane
___
SCLorg mailing
On Fri, Mar 31, 2017 at 6:30 PM, Nick Coghlan wrote:
> On Sun, Mar 26, 2017 at 12:50 AM, meson wrote:
>> Hi,
>>
>> is there any estimate on when Python 3.6 will be available as SCL?
>>
>> Our devs are asking about it. If it's going to take a long tim
On Fri, Mar 31, 2017 at 7:02 PM, Remi Collet wrote:
> Le 31/03/2017 à 10:30, Nick Coghlan a écrit :
>
>> Remi, do you have access to edit the CentOS wiki? It would be good to
>> provide a pointer to https://github.com/sclorg-distgit from
>> https://wiki.centos.org/S
olely on the mailing list and the RHSCL component in Red Hat's
bugzilla instance (which only covers the official SCLs anyway).
--
Nick Coghlan
Red Hat Platform Engineering, Brisbane
___
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg
ot; links, and not the more generic
"python" or "pythonX" links.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Platform Engineering, Brisbane
___
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg
this may actually also deal with the Python sys.executable
and hence setuptools and pipsi compatibility problems that I raised in
https://bugzilla.redhat.com/show_bug.cgi?id=1385471
Otherwise sys.executable will still be set to the unwrapped binary,
and any generated shebang lines would refer to that rath
speculation, but assuming past patterns continued, there would be
newer PHP SCLs released between now and 2019, so a supported version
would remain available for some time beyond that.
Regards,
Nick.
--
Nick Coghlan
Red Hat Platform Engineering, Brisbane
__
a place
to publish community maintained collections for development stacks
that Red Hat doesn't support commercially at all (akin to the
community quickstarts for OpenShift v2, and the "bring your own
container" feature in OpenShift v3)
Cheers,
Nick.
--
Nick Coghlan
Red Hat Platform Engineering, Brisbane
___
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg
uild atop SCLs wouldn't come into play.
However, I'm not sure the minor irritations of the official SCLs are
irritating *enough* to put in the time and energy to create and
maintain a fork indefinitely, rather than being able to just submit a
patch to fix the problems.
Cheers,
Ni
On Thu, Jul 7, 2016 at 5:13 PM, Honza Horak wrote:
> On 07/04/2016 03:11 PM, Nick Coghlan wrote:
>> Is there an ETA for when the RHSCL collections will get a proper
>> upstream that accepts patches, rather than just bug reports? (I
>> thought establishing that was part
patches, rather than just bug reports? (I
thought establishing that was part of the purpose of the CentOS SIG)
Cheers,
Nick.
--
Nick Coghlan
Red Hat Platform Engineering, Brisbane
___
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg
he binaries. They certainly *can* be used without it,
but it's an ongoing source of friction since Python tools generally
assume that a Python runtime will know where to find its shared
libraries.
Cheers,
Nick.
--
Nick Coghlan
Fedora Environments & Stacks
Red Hat Developer Exper
-user" installations are
likely to still have problems, but I'm more comfortable with a
restriction saying not to use --user installs in conjunction with
SCLs)
Regards,
Nick.
--
Nick Coghlan
Fedora Environments & Stacks
Red Hat Developer Experience, Brisbane
Soft
On Tue, Mar 15, 2016 at 10:52 PM, Honza Horak wrote:
> On 03/15/2016 01:38 PM, Nick Coghlan wrote:
>>
>> On Tue, Mar 15, 2016 at 10:32 PM, Honza Horak wrote:
>>>
>>> If you have any use case to use CentOS builds from
>>> softwarecollections.org
gt; channel.
One question would be how to enable access to the sclo community SCLs
that aren't in the official Red Hat SCL releases - those are going to
need a non-Red-Hat repo that can nevertheless be readily enabled on
RHEL systems (ala EPEL or IUS).
Cheers,
Nick.
--
Nick Coghlan
Fedora Env
38 matches
Mail list logo
