atom feed12 messages in com.redhat.epel-devel-list[EPEL-devel] Re: nodejs broken
FromSent OnAttachments
Richard GraingerAug 23, 2017 1:55 am 
Anssi JohanssonAug 23, 2017 3:31 am 
Anssi JohanssonAug 23, 2017 4:13 am 
Richard GraingerAug 23, 2017 4:16 am 
Stephen GallagherAug 23, 2017 6:43 am 
Peter RobinsonAug 23, 2017 7:01 am 
Stephen John SmoogenAug 23, 2017 8:38 am 
Stephen GallagherAug 23, 2017 8:52 am 
Peter RobinsonAug 23, 2017 8:58 am 
Peter RobinsonAug 23, 2017 9:01 am 
Stephen GallagherAug 23, 2017 10:27 am 
Paul HowarthAug 24, 2017 1:09 am 
Subject:[EPEL-devel] Re: nodejs broken
From:Peter Robinson (pbro@gmail.com)
Date:Aug 23, 2017 8:58:03 am
List:com.redhat.epel-devel-list

On Wed, Aug 23, 2017 at 4:38 PM, Stephen John Smoogen <smo@gmail.com> wrote:

On 23 August 2017 at 10:01, Peter Robinson <pbro@gmail.com> wrote:

On Wed, Aug 23, 2017 at 7:17 AM Richard Grainger <grai@gmail.com> wrote:

I'm trying to figure out what to do here. We can't just put back the http-parser in EPEL unfortunately because the RHEL folks unintentionally released a lower NVR for the official package. If we put ours back, it would supersede RHEL and take them out of support on any package linking against it (which now includes parts of SSSD).

We should really be bumping and pushing an errata if RHEL picked up

I am not sure who the we here is. I am guessing Red Hat but it could also be EPEL. If there is something we can do inside of EPEL, I will try to get it done this week.

We is Red Hat EL platform engineering, nothing EPEL can do.

the EPEL package and pulled it into core RHEL anyway because if people had been previously using it in EPEL for other reasons (and 100s of enterprises do sync EPEL) they would already be in a situation where they're running an unsupported version, there is no other fix to that and Red Hat engineering needs to improve their processes in this regard because there is a number of these issues each el7 cycle.

The usual issue is the following:

1. The package gets pulled into RHEL-7-next by whatever arcane processes does that. 2. The owner usually fixes some problem and thinks that the version they are pushing with the fix will be accepted internally. 3. The fix is too late in the arcane processes and RHEL ships with an older version. 4. Everyone points fingers at each other for a couple of months after a release. Someone tries to iron out problems. 5. We have a good release cycle next time. 6. Some arcane process changes 7. Goto 1.

I think we have done this dance every other minor release since 5.1

I have some ideas on how we can try to 'fix' this from now on that I will be presenting at FLOCK next week so that releng and related groups can fix/kill.

Sure, but it's a Red Hat not a Fedora/EPEL problem so I don't actually see how a Flock presentation can fix it, it needs internal product management etc to put together a process to deal.

I'm going to spend a little time today trying to figure out if I can fix the OpenSSL 1.0.1 compatibility patch and push out an update that will work with the bundled http-parser for now.

Can you not just rebuild nodejs, which will rebuild the bundled http-parser, against the new 1.0.2 build in 7.4?