I just noticed that the version of cmake that comes with RHEL 6 is currently 2.8.12.2 and the EPEL has a cmake28 package that is at version 2.8.11.2. I believe that RHEL 6 originally shipped with cmake 2.6 and updated in a later point release, but I have two questions: 1) Is the cmake28 a duplicate and need to be removed? 2) I'm working on packaging cppformat and on RHEL 6 when I build with cmake28 everything works out of the box, but with cmake I have to add -DCMAKE_SKIP_RPATH=OFF to get the linker to work properly?
Is #2 an error/incorrect assumption in the cmake setup for cppformat? Or is it something wrong in the "system cmake" that is correct in cmake28?
Thanks, Dave
On 04/20/2015 09:32 PM, Dave Johansen wrote:
I just noticed that the version of cmake that comes with RHEL 6 is currently 2.8.12.2 and the EPEL has a cmake28 package that is at version 2.8.11.2. I believe that RHEL 6 originally shipped with cmake 2.6 and updated in a later point release, but I have two questions:
- Is the cmake28 a duplicate and need to be removed?
Yes.
- I'm working on packaging cppformat and on RHEL 6 when I build with
cmake28 everything works out of the box, but with cmake I have to add -DCMAKE_SKIP_RPATH=OFF to get the linker to work properly?
Is #2 an error/incorrect assumption in the cmake setup for cppformat? Or is it something wrong in the "system cmake" that is correct in cmake28?
It's a (longstanding) bug in the RHEL cmake package: https://bugzilla.redhat.com/show_bug.cgi?id=640672
Thanks, Dave
epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
On Mon, Apr 20, 2015 at 9:40 PM, Orion Poplawski orion@cora.nwra.com wrote:
On 04/20/2015 09:32 PM, Dave Johansen wrote:
I just noticed that the version of cmake that comes with RHEL 6 is currently 2.8.12.2 and the EPEL has a cmake28 package that is at version 2.8.11.2. I believe that RHEL 6 originally shipped with cmake 2.6 and updated in a later point release, but I have two questions:
- Is the cmake28 a duplicate and need to be removed?
Yes.
Ok. Is this already being worked on? Or does a bugzilla need to be created for it?
2) I'm working on packaging cppformat and on RHEL 6 when I build with
cmake28 everything works out of the box, but with cmake I have to add -DCMAKE_SKIP_RPATH=OFF to get the linker to work properly?
Is #2 an error/incorrect assumption in the cmake setup for cppformat? Or is it something wrong in the "system cmake" that is correct in cmake28?
It's a (longstanding) bug in the RHEL cmake package: https://bugzilla.redhat.com/show_bug.cgi?id=640672
Thanks for the heads up. I'll just leave the flag in there for now.
On 04/21/2015 08:48 PM, Dave Johansen wrote:
On Mon, Apr 20, 2015 at 9:40 PM, Orion Poplawski <orion@cora.nwra.com mailto:orion@cora.nwra.com> wrote:
On 04/20/2015 09:32 PM, Dave Johansen wrote: I just noticed that the version of cmake that comes with RHEL 6 is currently 2.8.12.2 and the EPEL has a cmake28 package that is at version 2.8.11.2. I believe that RHEL 6 originally shipped with cmake 2.6 and updated in a later point release, but I have two questions: 1) Is the cmake28 a duplicate and need to be removed? Yes.
Ok. Is this already being worked on? Or does a bugzilla need to be created for it?
A quick search: https://bugzilla.redhat.com/buglist.cgi?quicksearch=%3Acmake28&list_id=3...
turns up: https://bugzilla.redhat.com/show_bug.cgi?id=1159351
There is some question as to whether or not it is worth the pain to retire. I suppose you could also consider it pulling things away from EPEL users. If it is kept, it probably should be updated at least.
On Tue, Apr 21, 2015 at 8:07 PM, Orion Poplawski orion@cora.nwra.com wrote:
On 04/21/2015 08:48 PM, Dave Johansen wrote:
On Mon, Apr 20, 2015 at 9:40 PM, Orion Poplawski <orion@cora.nwra.com mailto:orion@cora.nwra.com> wrote:
On 04/20/2015 09:32 PM, Dave Johansen wrote: I just noticed that the version of cmake that comes with RHEL 6 is currently 2.8.12.2 and the EPEL has a cmake28 package that is at version 2.8.11.2. I believe that RHEL 6 originally shipped with cmake 2.6 and updated in a later point release, but I have two questions: 1) Is the cmake28 a duplicate and need to be removed? Yes.
Ok. Is this already being worked on? Or does a bugzilla need to be created for it?
A quick search: https://bugzilla.redhat.com/buglist.cgi?quicksearch=%3Acmake28&list_id=3...
turns up: https://bugzilla.redhat.com/show_bug.cgi?id=1159351
There is some question as to whether or not it is worth the pain to retire. I suppose you could also consider it pulling things away from EPEL users. If it is kept, it probably should be updated at least.
Would it be possible to create a Bugzilla and request that a virtual provide for cmake28 be added to the cmake package in RHEL? I believe that would allow the package in EPEL to be retired without requiring changes to existing .spec files. I'm guessing that a cmake28 symlink might be needed as well, but it still seems possible and a solution that shouldn't have too much headache.
On 05/15/2015 10:57 PM, Dave Johansen wrote:
On Tue, Apr 21, 2015 at 8:07 PM, Orion Poplawski <orion@cora.nwra.com mailto:orion@cora.nwra.com> wrote:
On 04/21/2015 08:48 PM, Dave Johansen wrote: On Mon, Apr 20, 2015 at 9:40 PM, Orion Poplawski <orion@cora.nwra.com <mailto:orion@cora.nwra.com> <mailto:orion@cora.nwra.com <mailto:orion@cora.nwra.com>>> wrote: On 04/20/2015 09:32 PM, Dave Johansen wrote: I just noticed that the version of cmake that comes with RHEL 6 is currently 2.8.12.2 and the EPEL has a cmake28 package that is at version 2.8.11.2. I believe that RHEL 6 originally shipped with cmake 2.6 and updated in a later point release, but I have two questions: 1) Is the cmake28 a duplicate and need to be removed? Yes. Ok. Is this already being worked on? Or does a bugzilla need to be created for it? A quick search: https://bugzilla.redhat.com/buglist.cgi?quicksearch=%3Acmake28&list_id=3417355 turns up: https://bugzilla.redhat.com/show_bug.cgi?id=1159351 There is some question as to whether or not it is worth the pain to retire. I suppose you could also consider it pulling things away from EPEL users. If it is kept, it probably should be updated at least.
Would it be possible to create a Bugzilla and request that a virtual provide for cmake28 be added to the cmake package in RHEL? I believe that would allow the package in EPEL to be retired without requiring changes to existing .spec files. I'm guessing that a cmake28 symlink might be needed as well, but it still seems possible and a solution that shouldn't have too much headache.
Sure, anything is possible :). Although I don't see what the big deal about changing the EPEL packages would be. If anything, it would just bring them back in line with the Fedora branches.
On Sat, May 16, 2015 at 7:48 PM, Orion Poplawski orion@cora.nwra.com wrote:
On 05/15/2015 10:57 PM, Dave Johansen wrote:
On Tue, Apr 21, 2015 at 8:07 PM, Orion Poplawski <orion@cora.nwra.com mailto:orion@cora.nwra.com> wrote:
On 04/21/2015 08:48 PM, Dave Johansen wrote: On Mon, Apr 20, 2015 at 9:40 PM, Orion Poplawski <orion@cora.nwra.com <mailto:orion@cora.nwra.com> <mailto:orion@cora.nwra.com <mailto:orion@cora.nwra.com>>> wrote: On 04/20/2015 09:32 PM, Dave Johansen wrote: I just noticed that the version of cmake that comes with RHEL 6 is currently 2.8.12.2 and the EPEL has a cmake28 package that is at version 2.8.11.2. I believe that RHEL 6 originally shipped with cmake 2.6 and updated in a later point release, but I have two
questions: 1) Is the cmake28 a duplicate and need to be removed?
Yes. Ok. Is this already being worked on? Or does a bugzilla need to be created for it? A quick search:
https://bugzilla.redhat.com/buglist.cgi?quicksearch=%3Acmake28&list_id=3...
turns up: https://bugzilla.redhat.com/show_bug.cgi?id=1159351 There is some question as to whether or not it is worth the pain to retire. I suppose you could also consider it pulling things away from EPEL users. If it is kept, it probably should be updated at
least.
Would it be possible to create a Bugzilla and request that a virtual provide for cmake28 be added to the cmake package in RHEL? I believe that would allow the package in EPEL to be retired without requiring changes to existing .spec files. I'm guessing that a cmake28 symlink might be needed as well, but it still seems possible and a solution that shouldn't have too much headache.
Sure, anything is possible :). Although I don't see what the big deal about changing the EPEL packages would be. If anything, it would just bring them back in line with the Fedora branches.
My concern would just be the added effort of maintaining both of them and it falling behind like has already happened here.
epel-devel@lists.fedoraproject.org