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
Software Development Workflow Desi
ng
solely 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
he "/usr/bin/pythonX.Y" 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
I believe 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 wo
On Tue, Jul 11, 2017 at 11:39 PM, Honza Horak <hho...@redhat.com> 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 n
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 Mon, Jul 3, 2017 at 3:47 PM, Nick Coghlan <ncogh...@redhat.com> wrote:
> On Fri, Jun 30, 2017 at 1:24 AM, Davis, Daniel (NIH/NLM) [C]
> <daniel.da...@nih.gov> wrote:
>> I’ve been lurking on this list for a while, and I wanted to bring myself up
>> to date. I no
On Wed, Jul 12, 2017 at 4:22 PM, Nick Coghlan <ncogh...@redhat.com> wrote:
> On Tue, Jul 11, 2017 at 11:39 PM, Honza Horak <hho...@redhat.com> wrote:
>> This guide is actually not complete, as I've just realized -- copr is only
>> one way to build SCLs for www.software
at 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 Thu, Jul 13, 2017 at 5:18 PM, Nick Coghlan <ncogh...@redhat.com> wrote:
> On Wed, Jul 12, 2017 at 4:22 PM, Nick Coghlan <ncogh...@redhat.com> wrote:
>> I wasn't planning to publish the COPR builds anywhere other than COPR,
>> they'd just be a place for me to tinker
witch 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
On Wed, May 3, 2017 at 9:44 PM, Tomas Orsava <tors...@redhat.com> 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
On Wed, May 3, 2017 at 10:35 PM, Nick Coghlan <ncogh...@redhat.com> wrote:
> On Wed, May 3, 2017 at 9:44 PM, Tomas Orsava <tors...@redhat.com> wrote:
>> I do see the benefits of the added rolling SCL, though in my mind the
>> benefits are lessened by the pre-existence of
On Fri, Apr 14, 2017 at 12:27 AM, Tomas Orsava <tors...@redhat.com> 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 roll
On Mon, Sep 18, 2017 at 9:29 PM, Honza Horak <hho...@redhat.com> 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 kind
On Tue, Sep 19, 2017 at 5:31 PM, Petr Kubat <pku...@redhat.com> 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/sclor
ions 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 "vendorscl" actually get set?
ieces (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
-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 Hat Platform
On Thu, Oct 5, 2017 at 3:39 PM, Remi Collet <fed...@famillecollet.com> 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
>> softwarecol
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
ml#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...@gmail.com | Brisbane, Aus
22 matches
Mail list logo
