On 10/17/2016 08:52 AM, Nick Coghlan wrote:
On 15 October 2016 at 02:00, Tomas Orsava wrote:
Hi!
I'm not able to find it myself, and nobody chimed in so far. Have you had
any luck?
OK, I filed https://bugzilla.redhat.com/show_bug.cgi?id=1385471
There's a mini-rant in the "Additional Info" se
On 15 October 2016 at 02:00, Tomas Orsava wrote:
> Hi!
>
> I'm not able to find it myself, and nobody chimed in so far. Have you had
> any luck?
OK, I filed https://bugzilla.redhat.com/show_bug.cgi?id=1385471
There's a mini-rant in the "Additional Info" section regarding RPATH,
as not setting th
Hi!
I'm not able to find it myself, and nobody chimed in so far. Have you
had any luck?
Yours aye,
Tomas
On 10/05/2016 06:37 PM, Nick Coghlan wrote:
On 5 October 2016 at 21:45, Tomas Orsava wrote:
On 10/04/2016 03:10 PM, Nick Coghlan wrote:
I bring that up, as one of the other challenges
On 5 October 2016 at 21:45, Tomas Orsava wrote:
> On 10/04/2016 03:10 PM, Nick Coghlan wrote:
>> I bring that up, as one of the other challenges with the way SCLs
>> currently work is that the upstream convention of copying
>> "sys.executable" into the shebang to generate a script that runs in
>>
On 10/04/2016 03:10 PM, Nick Coghlan wrote:
On 3 October 2016 at 23:36, Tomas Orsava wrote:
On 09/27/2016 08:43 AM, Nick Coghlan wrote:
P.P.S. I realize rh-python34 is available on RHSCL, but it didn't seem to
support "python3" in scripts...
Script shebang lines can be supported via SCLs, but
On 3 October 2016 at 23:36, Tomas Orsava wrote:
> On 09/27/2016 08:43 AM, Nick Coghlan wrote:
>>>
>>> P.P.S. I realize rh-python34 is available on RHSCL, but it didn't seem to
>>> support "python3" in scripts...
>>
>> Script shebang lines can be supported via SCLs, but they need to run a
>> wrappe
On 09/27/2016 08:43 AM, Nick Coghlan wrote:
P.P.S. I realize rh-python34 is available on RHSCL, but it didn't seem to
support "python3" in scripts...
Script shebang lines can be supported via SCLs, but they need to run a
wrapper script that implicitly enables the SCL, rather than just being
a sy
On 24 September 2016 at 18:17, Tim Orling wrote:
> I came across a need for python34 on epel6. I did not see any BZ for it.
>
> Are there significant issues with packaging python34 for epel6? or just
> nobody wanted to do it yet?
Mainly the latter I think - most folks needing to su
I came across a need for python34 on epel6. I did not see any BZ for it.
Are there significant issues with packaging python34 for epel6? or just
nobody wanted to do it yet?
Cheers.
--Tim
P.S Thank you for python34 on epel7. worked like a charm.
P.P.S. I realize rh-python34 is available on
On 08/24/2016 11:38 PM, Orion Poplawski wrote:
> I have no idea if there is any interest in this or not. I managed to get the
> EPEL7 python34 package to build on EL6 with a few modifications. Is there any
> interest in supporting this?
>
>
>
> ___
>
On 08/24/2016 11:39 PM, Neal Gompa wrote:
On Wed, Aug 24, 2016 at 5:38 PM, Orion Poplawski wrote:
I have no idea if there is any interest in this or not. I managed to get the
EPEL7 python34 package to build on EL6 with a few modifications. Is there any
interest in supporting this?
I think
> "AL" == Avram Lubkin writes:
AL> I'm curious if anyone else has any insight. Maybe it is worth
AL> bringing up at a FPC meeting.
That would more appropriately be a topic of an EPEL meeting, since this
is purely an EPEL policy issue.
- J<
___
py
On Wed, Aug 24, 2016 at 8:44 PM, Jason L Tibbitts III
wrote:
>
> To be completely fair, I don't actually know EPEL policy here. The rule
> is that you can't conflict with RHEL packages, but SRPMs aren't really
> installed the same way as other packages and whether or not they would
> install to
> "AL" == Avram Lubkin writes:
AL> Not needing reviews would help, but I wonder how hard it would be to
AL> make them children of python-PACKAGE. The main issue is the SRPM
AL> needs to have a different name so there is no conflict with the RHEL
AL> SRPM.
To be completely fair, I don't actua
>
> Which is an annoying bit of process, but it would be quite possible to
> exempt those packages from needing package reviews. It needn't take
> that long.
>
>
Not needing reviews would help, but I wonder how hard it would be to make
them children of python-PACKAGE. The main issue is the SRPM ne
> "AL" == Avram Lubkin writes:
AL> Definitely, but it runs into the same problem as 3.4 on EL7, the
AL> fact that there are few packages available and adding them when the
AL> package already exists in RHEL requires creating a separate parent
AL> package in Fedora pkgdb.
Which is an annoying
Definitely, but it runs into the same problem as 3.4 on EL7, the fact that
there are few packages available and adding them when the package already
exists in RHEL requires creating a separate parent package in Fedora pkgdb.
On Wed, Aug 24, 2016 at 5:38 PM, Orion Poplawski
wrote:
> I have no ide
On Wed, Aug 24, 2016 at 5:38 PM, Orion Poplawski wrote:
> I have no idea if there is any interest in this or not. I managed to get the
> EPEL7 python34 package to build on EL6 with a few modifications. Is there any
> interest in supporting this?
>
I think the Koji people would be interested in
I have no idea if there is any interest in this or not. I managed to get the
EPEL7 python34 package to build on EL6 with a few modifications. Is there any
interest in supporting this?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office
19 matches
Mail list logo
