Re: [ceph-users] Recompiling source code - to find exact RPM
Hey Brad, Many thanks for the explanation... > ~~~ > WARNING: the following dangerous and experimental features are enabled: > ~~~ > Can I ask why you want to disable this warning? We using bluestore with kraken, we are aware that this is in tech preview. To hide these warning compiled like this. Thanks On Mon, Mar 27, 2017 at 5:04 AM, Brad Hubbard wrote: > > > On Fri, Mar 24, 2017 at 6:49 PM, nokia ceph > wrote: > > Brad, cool now we are on the same track :) > > > > So whatever change we made after this location src/* as it mapped to > > respective rpm correct? > > > > For eg:- > > src/osd/* -- ceph-osd > > src/common - ceph-common > > src/mon - ceph-mon > > src/mgr - ceph-mgr > > I think this is true in most, if not all, cases. > > > > > Since we are using bluestore with kraken, I though to disable the below > > warning while triggering `ceph -s` > > > > ~~~ > > WARNING: the following dangerous and experimental features are enabled: > > ~~~ > > Can I ask why you want to disable this warning? > > > > > Here I made a comment in this file > > > >>vim src/common/ceph_context.cc > > 307 // if (!cct->_experimental_features.empty()) > > 308 // lderr(cct) << "WARNING: the following dangerous and > experimental > > features are enabled: " > > 309 // << cct->_experimental_features << dendl; > > Right. > > > > > As per my assumption, the change should reflect in this binary > > "ceph-common" > > libceph-common specifically. > > > > > But when I closely looked on librados library as these warning showing > here > > also. > > #strings -a /usr/lib64/librados.so.2 | grep dangerous > > WARNING: the following dangerous and experimental features are enabled: > --> > > > > Then I conclude for this change ceph-common and librados were required. > > > > Please correct me if I'm wrong. > > So I looked at this on current master built on Fedora and see the > following. > > $ for lib in $(find . \! -type l -type f -name lib\*); do strings > $lib|grep "following dangerous and experimenta l"; if [ $? -eq 0 ]; then > echo $lib; fi; done > WARNING: the following dangerous and experimental features are enabled: > ./libcephd.a > WARNING: the following dangerous and experimental features are enabled: > ./libceph-common.so.0 > WARNING: the following dangerous and experimental features are enabled: > ./libcommon.a > > So in my case the only shared object that has this string is > libceph-common. > However, that library is dynamically linked to libceph-common. > > $ ldd librados.so.2.0.0|grep libceph-common > libceph-common.so.0 => > /home/brad/working/src/ceph/build/lib/libceph-common.so.0 > (0x7faa2cf42000) > > I checked a rhel version and sure enough the string is there, because in > that > version on rhel/CentOS we statically linked libcommon.a into librados IIRC. > > # ldd librados.so.2.0.0|grep libceph-common > # > > So if the string shows up in your librados then I'd suggest it is also > statically linked ([1] we only changed this fairly recently) and you will > need > to replace it to reflect your change. > > [1] https://github.com/ceph/ceph/commit/8f7643792c9e6a3d1ba4a06ca7d09b > 0de9af1443 > > > > > On Fri, Mar 24, 2017 at 5:41 AM, Brad Hubbard > wrote: > >> > >> Oh wow, I completely misunderstood your question. > >> > >> Yes, src/osd/PG.cc and src/osd/PG.h are compiled into the ceph-osd > binary > >> which > >> is included in the ceph-osd rpm as you said in your OP. > >> > >> On Fri, Mar 24, 2017 at 3:10 AM, nokia ceph > >> wrote: > >> > Hello Piotr, > >> > > >> > I didn't understand, could you please elaborate about this procedure > as > >> > mentioned in the last update. It would be really helpful if you share > >> > any > >> > useful link/doc to understand what you actually meant. Yea correct, > >> > normally > >> > we do this procedure but it takes more time. But here my intention is > to > >> > how > >> > to find out the rpm which caused the change. I think we are in > opposite > >> > direction. > >> > > >> >>> But wouldn't be faster and/or more convenient if you would just > >> >>> recompile > >> >>> binaries in-place (or use network symlinks) > >> > > >> > Thanks > >> > > >> > > >> > > >> > On Thu, Mar 23, 2017 at 6:47 PM, Piotr Dałek < > piotr.da...@corp.ovh.com> > >> > wrote: > >> >> > >> >> On 03/23/2017 02:02 PM, nokia ceph wrote: > >> >> > >> >>> Hello Piotr, > >> >>> > >> >>> We do customizing ceph code for our testing purpose. It's a part of > >> >>> our > >> >>> R&D :) > >> >>> > >> >>> Recompiling source code will create 38 rpm's out of these I need to > >> >>> find > >> >>> which one is the correct rpm which I made change in the source code. > >> >>> That's > >> >>> what I'm try to figure out. > >> >> > >> >> > >> >> Yes, I understand that. But wouldn't be faster and/or more convenient > >> >> if > >> >> you would just recompile binaries in-place (or use network symlinks) > >> >> instead > >> >> of packaging entire Ceph and (re)installing its packages each
Re: [ceph-users] Recompiling source code - to find exact RPM
On Fri, Mar 24, 2017 at 6:49 PM, nokia ceph wrote: > Brad, cool now we are on the same track :) > > So whatever change we made after this location src/* as it mapped to > respective rpm correct? > > For eg:- > src/osd/* -- ceph-osd > src/common - ceph-common > src/mon - ceph-mon > src/mgr - ceph-mgr I think this is true in most, if not all, cases. > > Since we are using bluestore with kraken, I though to disable the below > warning while triggering `ceph -s` > > ~~~ > WARNING: the following dangerous and experimental features are enabled: > ~~~ Can I ask why you want to disable this warning? > > Here I made a comment in this file > >>vim src/common/ceph_context.cc > 307 // if (!cct->_experimental_features.empty()) > 308 // lderr(cct) << "WARNING: the following dangerous and experimental > features are enabled: " > 309 // << cct->_experimental_features << dendl; Right. > > As per my assumption, the change should reflect in this binary > "ceph-common" libceph-common specifically. > > But when I closely looked on librados library as these warning showing here > also. > #strings -a /usr/lib64/librados.so.2 | grep dangerous > WARNING: the following dangerous and experimental features are enabled: --> > > Then I conclude for this change ceph-common and librados were required. > > Please correct me if I'm wrong. So I looked at this on current master built on Fedora and see the following. $ for lib in $(find . \! -type l -type f -name lib\*); do strings $lib|grep "following dangerous and experimenta l"; if [ $? -eq 0 ]; then echo $lib; fi; done WARNING: the following dangerous and experimental features are enabled: ./libcephd.a WARNING: the following dangerous and experimental features are enabled: ./libceph-common.so.0 WARNING: the following dangerous and experimental features are enabled: ./libcommon.a So in my case the only shared object that has this string is libceph-common. However, that library is dynamically linked to libceph-common. $ ldd librados.so.2.0.0|grep libceph-common libceph-common.so.0 => /home/brad/working/src/ceph/build/lib/libceph-common.so.0 (0x7faa2cf42000) I checked a rhel version and sure enough the string is there, because in that version on rhel/CentOS we statically linked libcommon.a into librados IIRC. # ldd librados.so.2.0.0|grep libceph-common # So if the string shows up in your librados then I'd suggest it is also statically linked ([1] we only changed this fairly recently) and you will need to replace it to reflect your change. [1] https://github.com/ceph/ceph/commit/8f7643792c9e6a3d1ba4a06ca7d09b0de9af1443 > > On Fri, Mar 24, 2017 at 5:41 AM, Brad Hubbard wrote: >> >> Oh wow, I completely misunderstood your question. >> >> Yes, src/osd/PG.cc and src/osd/PG.h are compiled into the ceph-osd binary >> which >> is included in the ceph-osd rpm as you said in your OP. >> >> On Fri, Mar 24, 2017 at 3:10 AM, nokia ceph >> wrote: >> > Hello Piotr, >> > >> > I didn't understand, could you please elaborate about this procedure as >> > mentioned in the last update. It would be really helpful if you share >> > any >> > useful link/doc to understand what you actually meant. Yea correct, >> > normally >> > we do this procedure but it takes more time. But here my intention is to >> > how >> > to find out the rpm which caused the change. I think we are in opposite >> > direction. >> > >> >>> But wouldn't be faster and/or more convenient if you would just >> >>> recompile >> >>> binaries in-place (or use network symlinks) >> > >> > Thanks >> > >> > >> > >> > On Thu, Mar 23, 2017 at 6:47 PM, Piotr Dałek >> > wrote: >> >> >> >> On 03/23/2017 02:02 PM, nokia ceph wrote: >> >> >> >>> Hello Piotr, >> >>> >> >>> We do customizing ceph code for our testing purpose. It's a part of >> >>> our >> >>> R&D :) >> >>> >> >>> Recompiling source code will create 38 rpm's out of these I need to >> >>> find >> >>> which one is the correct rpm which I made change in the source code. >> >>> That's >> >>> what I'm try to figure out. >> >> >> >> >> >> Yes, I understand that. But wouldn't be faster and/or more convenient >> >> if >> >> you would just recompile binaries in-place (or use network symlinks) >> >> instead >> >> of packaging entire Ceph and (re)installing its packages each time you >> >> do >> >> the change? Generating RPMs takes a while. >> >> >> >> >> >> -- >> >> Piotr Dałek >> >> piotr.da...@corp.ovh.com >> >> https://www.ovh.com/us/ >> > >> > >> > >> > ___ >> > ceph-users mailing list >> > ceph-users@lists.ceph.com >> > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com >> > >> >> >> >> -- >> Cheers, >> Brad > > -- Cheers, Brad ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Re: [ceph-users] Recompiling source code - to find exact RPM
Piotr, thanks for the info.
Yea this method is time saving, but we are not started testing with build
from source method. We will consider this for our next part of testing :)
On Fri, Mar 24, 2017 at 1:17 PM, Piotr Dałek
wrote:
> On 03/23/2017 06:10 PM, nokia ceph wrote:
>
>> Hello Piotr,
>>
>> I didn't understand, could you please elaborate about this procedure as
>> mentioned in the last update. It would be really helpful if you share any
>> useful link/doc to understand what you actually meant. Yea correct,
>> normally
>> we do this procedure but it takes more time. But here my intention is to
>> how
>> to find out the rpm which caused the change. I think we are in opposite
>> direction.
>>
>
>
> Here's described how to build Ceph from source ("Build Ceph" paragraph):
> http://docs.ceph.com/docs/master/install/build-ceph/
> And here's how to install the built binaries:
> http://docs.ceph.com/docs/master/install/install-storage-
> cluster/#installing-a-build
> That's enough to build and install Ceph binaries on a specific host
> without building RPMs. After doing a code change, "make install" is enough
> to update binaries, restart of Ceph daemons is still required.
>
>
> --
> Piotr Dałek
> piotr.da...@corp.ovh.com
> https://www.ovh.com/us/
>
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Re: [ceph-users] Recompiling source code - to find exact RPM
Brad, cool now we are on the same track :) So whatever change we made after this location src/* as it mapped to respective rpm correct? For eg:- src/osd/* -- ceph-osd src/common - ceph-common src/mon - ceph-mon src/mgr - ceph-mgr Since we are using bluestore with kraken, I though to disable the below warning while triggering `ceph -s` ~~~ WARNING: the following dangerous and experimental features are enabled: ~~~ Here I made a comment in this file >vim src/common/ceph_context.cc 307 // if (!cct->_experimental_features.empty()) 308 // lderr(cct) << "WARNING: the following dangerous and experimental features are enabled: " 309 // << cct->_experimental_features << dendl; As per my assumption, the change should reflect in this binary "ceph-common" But when I closely looked on librados library as these warning showing here also. #strings -a /usr/lib64/librados.so.2 | grep dangerous WARNING: the following dangerous and experimental features are enabled: --> Then I conclude for this change ceph-common and librados were required. Please correct me if I'm wrong. On Fri, Mar 24, 2017 at 5:41 AM, Brad Hubbard wrote: > Oh wow, I completely misunderstood your question. > > Yes, src/osd/PG.cc and src/osd/PG.h are compiled into the ceph-osd binary > which > is included in the ceph-osd rpm as you said in your OP. > > On Fri, Mar 24, 2017 at 3:10 AM, nokia ceph > wrote: > > Hello Piotr, > > > > I didn't understand, could you please elaborate about this procedure as > > mentioned in the last update. It would be really helpful if you share > any > > useful link/doc to understand what you actually meant. Yea correct, > normally > > we do this procedure but it takes more time. But here my intention is to > how > > to find out the rpm which caused the change. I think we are in opposite > > direction. > > > >>> But wouldn't be faster and/or more convenient if you would just > recompile > >>> binaries in-place (or use network symlinks) > > > > Thanks > > > > > > > > On Thu, Mar 23, 2017 at 6:47 PM, Piotr Dałek > > wrote: > >> > >> On 03/23/2017 02:02 PM, nokia ceph wrote: > >> > >>> Hello Piotr, > >>> > >>> We do customizing ceph code for our testing purpose. It's a part of our > >>> R&D :) > >>> > >>> Recompiling source code will create 38 rpm's out of these I need to > find > >>> which one is the correct rpm which I made change in the source code. > >>> That's > >>> what I'm try to figure out. > >> > >> > >> Yes, I understand that. But wouldn't be faster and/or more convenient if > >> you would just recompile binaries in-place (or use network symlinks) > instead > >> of packaging entire Ceph and (re)installing its packages each time you > do > >> the change? Generating RPMs takes a while. > >> > >> > >> -- > >> Piotr Dałek > >> piotr.da...@corp.ovh.com > >> https://www.ovh.com/us/ > > > > > > > > ___ > > ceph-users mailing list > > ceph-users@lists.ceph.com > > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > > > > > > -- > Cheers, > Brad > ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Re: [ceph-users] Recompiling source code - to find exact RPM
On 03/23/2017 06:10 PM, nokia ceph wrote:
Hello Piotr,
I didn't understand, could you please elaborate about this procedure as
mentioned in the last update. It would be really helpful if you share any
useful link/doc to understand what you actually meant. Yea correct, normally
we do this procedure but it takes more time. But here my intention is to how
to find out the rpm which caused the change. I think we are in opposite
direction.
Here's described how to build Ceph from source ("Build Ceph" paragraph):
http://docs.ceph.com/docs/master/install/build-ceph/
And here's how to install the built binaries:
http://docs.ceph.com/docs/master/install/install-storage-cluster/#installing-a-build
That's enough to build and install Ceph binaries on a specific host without
building RPMs. After doing a code change, "make install" is enough to update
binaries, restart of Ceph daemons is still required.
--
Piotr Dałek
piotr.da...@corp.ovh.com
https://www.ovh.com/us/
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Re: [ceph-users] Recompiling source code - to find exact RPM
Oh wow, I completely misunderstood your question. Yes, src/osd/PG.cc and src/osd/PG.h are compiled into the ceph-osd binary which is included in the ceph-osd rpm as you said in your OP. On Fri, Mar 24, 2017 at 3:10 AM, nokia ceph wrote: > Hello Piotr, > > I didn't understand, could you please elaborate about this procedure as > mentioned in the last update. It would be really helpful if you share any > useful link/doc to understand what you actually meant. Yea correct, normally > we do this procedure but it takes more time. But here my intention is to how > to find out the rpm which caused the change. I think we are in opposite > direction. > >>> But wouldn't be faster and/or more convenient if you would just recompile >>> binaries in-place (or use network symlinks) > > Thanks > > > > On Thu, Mar 23, 2017 at 6:47 PM, Piotr Dałek > wrote: >> >> On 03/23/2017 02:02 PM, nokia ceph wrote: >> >>> Hello Piotr, >>> >>> We do customizing ceph code for our testing purpose. It's a part of our >>> R&D :) >>> >>> Recompiling source code will create 38 rpm's out of these I need to find >>> which one is the correct rpm which I made change in the source code. >>> That's >>> what I'm try to figure out. >> >> >> Yes, I understand that. But wouldn't be faster and/or more convenient if >> you would just recompile binaries in-place (or use network symlinks) instead >> of packaging entire Ceph and (re)installing its packages each time you do >> the change? Generating RPMs takes a while. >> >> >> -- >> Piotr Dałek >> piotr.da...@corp.ovh.com >> https://www.ovh.com/us/ > > > > ___ > ceph-users mailing list > ceph-users@lists.ceph.com > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > -- Cheers, Brad ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Re: [ceph-users] Recompiling source code - to find exact RPM
Hello Piotr, I didn't understand, could you please elaborate about this procedure as mentioned in the last update. It would be really helpful if you share any useful link/doc to understand what you actually meant. Yea correct, normally we do this procedure but it takes more time. But here my intention is to how to find out the rpm which caused the change. I think we are in opposite direction. >> But wouldn't be faster and/or more convenient if you would just recompile binaries in-place (or use network symlinks) Thanks On Thu, Mar 23, 2017 at 6:47 PM, Piotr Dałek wrote: > On 03/23/2017 02:02 PM, nokia ceph wrote: > > Hello Piotr, >> >> We do customizing ceph code for our testing purpose. It's a part of our >> R&D :) >> >> Recompiling source code will create 38 rpm's out of these I need to find >> which one is the correct rpm which I made change in the source code. >> That's >> what I'm try to figure out. >> > > Yes, I understand that. But wouldn't be faster and/or more convenient if > you would just recompile binaries in-place (or use network symlinks) > instead of packaging entire Ceph and (re)installing its packages each time > you do the change? Generating RPMs takes a while. > > > -- > Piotr Dałek > piotr.da...@corp.ovh.com > https://www.ovh.com/us/ > ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Re: [ceph-users] Recompiling source code - to find exact RPM
On 03/23/2017 02:02 PM, nokia ceph wrote: Hello Piotr, We do customizing ceph code for our testing purpose. It's a part of our R&D :) Recompiling source code will create 38 rpm's out of these I need to find which one is the correct rpm which I made change in the source code. That's what I'm try to figure out. Yes, I understand that. But wouldn't be faster and/or more convenient if you would just recompile binaries in-place (or use network symlinks) instead of packaging entire Ceph and (re)installing its packages each time you do the change? Generating RPMs takes a while. -- Piotr Dałek piotr.da...@corp.ovh.com https://www.ovh.com/us/ ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Re: [ceph-users] Recompiling source code - to find exact RPM
Hello Piotr, We do customizing ceph code for our testing purpose. It's a part of our R&D :) Recompiling source code will create 38 rpm's out of these I need to find which one is the correct rpm which I made change in the source code. That's what I'm try to figure out. Thanks On Thu, Mar 23, 2017 at 6:18 PM, Piotr Dałek wrote: > On 03/23/2017 01:41 PM, nokia ceph wrote: > >> Hey brad, >> >> Thanks for the info. >> >> Yea we know that these are test rpm's. >> >> The idea behind my question is if I made any changes in the ceph source >> code, then I recompile it. Then I need to find which is the appropriate >> rpm >> mapped to that changed file. If I find the exact RPM, then apply that RPM >> in >> our existing ceph cluster instead of applying/overwriting all the >> compiled >> rpms. >> >> I hope this cleared your doubt. >> > > And why exactly you want to rebuild rpms each time? If the machines are > powerful enough, you could recompile binaries in place. Or symlink them via > nfs (or whatever) to build machine and build once there. > > -- > Piotr Dałek > piotr.da...@corp.ovh.com > https://www.ovh.com/us/ > > ___ > ceph-users mailing list > ceph-users@lists.ceph.com > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Re: [ceph-users] Recompiling source code - to find exact RPM
On 03/23/2017 01:41 PM, nokia ceph wrote: Hey brad, Thanks for the info. Yea we know that these are test rpm's. The idea behind my question is if I made any changes in the ceph source code, then I recompile it. Then I need to find which is the appropriate rpm mapped to that changed file. If I find the exact RPM, then apply that RPM in our existing ceph cluster instead of applying/overwriting all the compiled rpms. I hope this cleared your doubt. And why exactly you want to rebuild rpms each time? If the machines are powerful enough, you could recompile binaries in place. Or symlink them via nfs (or whatever) to build machine and build once there. -- Piotr Dałek piotr.da...@corp.ovh.com https://www.ovh.com/us/ ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Re: [ceph-users] Recompiling source code - to find exact RPM
Hey brad, Thanks for the info. Yea we know that these are test rpm's. The idea behind my question is if I made any changes in the ceph source code, then I recompile it. Then I need to find which is the appropriate rpm mapped to that changed file. If I find the exact RPM, then apply that RPM in our existing ceph cluster instead of applying/overwriting all the compiled rpms. I hope this cleared your doubt. Thanks On Wed, Mar 22, 2017 at 5:47 AM, Brad Hubbard wrote: > Based solely on the information given the only rpms with this specific > commit in > them would be here > https://shaman.ceph.com/builds/ceph/wip-prune-past-intervals-kraken/ > (specifically > https://4.chacra.ceph.com/r/ceph/wip-prune-past-intervals-kraken/ > 8263140fe539f9c3241c1c0f6ee9cfadde9178c0/centos/7/flavors/default/x86_64/ > ). > These are test rpms, not official releases. > > Note that the branch "wip-prune-past-intervals-kraken" exists only in the > ceph-ci repo and *not* the main ceph repo and that the particular commit > above > does not seem to have made it into the "ceph" repo. > > $ git log -S _simplify_past_intervals > $ git log --grep="_simplify_past_intervals" > $ > > Given this commit is not in the ceph repo I would suggest we have never > shipped > an official rpm that contains this commit. > > It's not totally clear to me exactly what you are trying to achieve, maybe > you > could have another go at describing your objective? > > On Wed, Mar 22, 2017 at 12:26 AM, nokia ceph > wrote: > > Hello, > > > > I made some changes in the below file on ceph kraken v11.2.0 source code > as > > per this article > > > > https://github.com/ceph/ceph-ci/commit/wip-prune-past-intervals-kraken > > > > ..src/osd/PG.cc > > ..src/osd/PG.h > > > > Is there any way to find which rpm got affected by these two files. I > > believe it should be ceph-osd-11.2.0-0.el7.x86_64.rpm . Can you confirm > > please ? > > > > I failed to find it from the ceph.spec file. > > > > Could anyone please guide me the right procedure to check this. > > > > The main intention is that if we find the exact rpm affected by these > files, > > we can simply overwrite it with the old rpm. > > > > Awaiting for comments. > > > > Thanks > > > > > > ___ > > ceph-users mailing list > > ceph-users@lists.ceph.com > > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > > > > > > -- > Cheers, > Brad > ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Re: [ceph-users] Recompiling source code - to find exact RPM
Based solely on the information given the only rpms with this specific commit in them would be here https://shaman.ceph.com/builds/ceph/wip-prune-past-intervals-kraken/ (specifically https://4.chacra.ceph.com/r/ceph/wip-prune-past-intervals-kraken/8263140fe539f9c3241c1c0f6ee9cfadde9178c0/centos/7/flavors/default/x86_64/). These are test rpms, not official releases. Note that the branch "wip-prune-past-intervals-kraken" exists only in the ceph-ci repo and *not* the main ceph repo and that the particular commit above does not seem to have made it into the "ceph" repo. $ git log -S _simplify_past_intervals $ git log --grep="_simplify_past_intervals" $ Given this commit is not in the ceph repo I would suggest we have never shipped an official rpm that contains this commit. It's not totally clear to me exactly what you are trying to achieve, maybe you could have another go at describing your objective? On Wed, Mar 22, 2017 at 12:26 AM, nokia ceph wrote: > Hello, > > I made some changes in the below file on ceph kraken v11.2.0 source code as > per this article > > https://github.com/ceph/ceph-ci/commit/wip-prune-past-intervals-kraken > > ..src/osd/PG.cc > ..src/osd/PG.h > > Is there any way to find which rpm got affected by these two files. I > believe it should be ceph-osd-11.2.0-0.el7.x86_64.rpm . Can you confirm > please ? > > I failed to find it from the ceph.spec file. > > Could anyone please guide me the right procedure to check this. > > The main intention is that if we find the exact rpm affected by these files, > we can simply overwrite it with the old rpm. > > Awaiting for comments. > > Thanks > > > ___ > ceph-users mailing list > ceph-users@lists.ceph.com > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > -- Cheers, Brad ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
[ceph-users] Recompiling source code - to find exact RPM
Hello, I made some changes in the below file on ceph kraken v11.2.0 source code as per this article https://github.com/ceph/ceph-ci/commit/wip-prune-past-intervals-kraken ..src/osd/PG.cc ..src/osd/PG.h Is there any way to find which rpm got affected by these two files. I believe it should be ceph-osd-11.2.0-0.el7.x86_64.rpm . Can you confirm please ? I failed to find it from the ceph.spec file. Could anyone please guide me the right procedure to check this. The main intention is that if we find the exact rpm affected by these files, we can simply overwrite it with the old rpm. Awaiting for comments. Thanks ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
