James Hogarth
2016-Mar-08 19:08 UTC
[CentOS] Can anyone compile mtr source RPM on CentOS 6.7?
On 8 March 2016 at 19:02, Digimer <lists at alteeve.ca> wrote:> On 08/03/16 01:51 PM, James Hogarth wrote: > > On 8 March 2016 at 17:22, Digimer <lists at alteeve.ca> wrote: > > > >> On 08/03/16 11:36 AM, James Hogarth wrote: > >>> On 8 March 2016 at 16:15, Digimer <lists at alteeve.ca> wrote: > >>> > >>>> On 08/03/16 07:11 AM, James Hogarth wrote: > >>>>> On 8 March 2016 at 10:07, Leon Fauster <leonfauster at googlemail.com> > >>>> wrote: > >>>>> > >>>>>> Am 08.03.2016 um 01:50 schrieb Digimer <lists at alteeve.ca>: > >>>>>>> I'm not surprised, given that it is in the repo. That's why I was > >>>> asking > >>>>>>> if anyone tried building it themselves and, if so, did they have > the > >>>>>>> same issue as I describe below? > >>>>>>> > >>>>>>> Alternatively, any tips/advice on solving my build issue would be > >>>>>> helpful. > >>>>>> > >>>>>> > >>>>>> > >>>>>> what says /var/tmp/rpm-tmp.gu9Ds0? > >>>>>> > >>>>>> all dependencies installed? > >>>>>> > >>>>>> > >>>>>> > >>>>> No need to check that .... the error is clear "make: *** No rule to > >> make > >>>>> target `install'. Stop." ... that mini Makefile he posted doesn't > >>>> include > >>>>> an install: section > >>>>> > >>>>> Of course what the OP is missing is *that* makefile does not get > used. > >>>>> > >>>>> In the tarball there is a Makefile.in that gets processed into the > >> actual > >>>>> makefile by ./configure (well %configure in the spec but you get the > >>>> point) > >>>>> > >>>>> So we come back round the houses to the key point - Digimer what are > >> you > >>>>> *actually* trying to do? > >>>>> > >>>>> You obviously aren't building from the spec in that src.rpm or using > >> mock > >>>>> as those have configure which would generate the valid makefile with > >> the > >>>>> make install target... so what are you doing and what do you want to > >>>>> achieve? > >>>>> > >>>>> The %install phase you posted is really not of interest to your > >> 'problem' > >>>>> but rather the %build phase would be telling. > >>>> > >>>> As I've done with several other RPMs, I did the following; > >>>> > >>>> ==> >>>> yumdownloader --source mtr-gtk > >>>> > >>>> rpm -Uvh mtr-0.75-5.el6.src.rpm > >>>> > >>>> cd rpmbuild/SPECS/ > >>>> > >>>> # Change "Release" > >>>> > >>>> rpmbuild -ba mtr.spec > >>>> ==> >>>> > >>>> If you're asking a more generic "why are you doing this?" question; I > am > >>>> including the RPM in a project we're working on and I don't want to > risk > >>>> running fould of the CentOS project by directly redistributing their > >>>> (and RHEL's) rpms. > >>>> > >>>> > >>> I'm sure Karanbir and Johnny can weigh in here more but so long as you > >> are > >>> not claiming to be CentOS and using their trademarks (see the modified > >> ones > >>> with centos in the name) I'm pretty certain that you are safe building > an > >>> appliance on CentOS and can ship the RPMs on that ... > >>> > >>> Regardless of that issue what you've described above should work (or > >> freak > >>> out if a build dependency was missing ... unless one isn't defined as a > >>> BuildRequires but is in the default mock root and is causing %configure > >>> not to generate the Makefile). > >>> > >>> Again the right answer here is "use mock" ... > >>> > >>> yumdownloader --source mtr-gtk > >>> > >>> rpm -Uvh mtr-0.75-5.el6.src.rpm > >>> > >>> cd rpmbuild > >>> > >>> vi SPECS/mtr.spec (change release etc ... bear in mind that bumping > >> release > >>> may not help you when a centos update happens ... may not care for an > >>> appliance) > >>> > >>> rpmbuild -bs SPECS/mtr.spec > >>> > >>> mock -r epel-6-x86_64 SRPMS/mtr-*.src.rpm > >>> > >>> ===================> >>> > >>> That will get you a reproducible clean build environment in a way not > >>> dependent on the state of your workstation and avoid any accidental > >>> depednencies etc popping up > >> > >> Thanks for the help, but I got the same results; > >> > >> ===> >> mock /home/digimer/rpmbuild/SRPMS/mtr-0.75-5.el6.anvil.src.rpm > >> > >> <dependencies installed> > >> <build messages> > >> + make DESTDIR=/builddir/build/BUILDROOT/mtr-0.75-5.el6.anvil.x86_64 > >> install > >> make: *** No rule to make target `install'. Stop. > >> > >> > >> RPM build errors: > >> error: Bad exit status from /var/tmp/rpm-tmp.8atuER (%install) > >> Bad exit status from /var/tmp/rpm-tmp.8atuER (%install) > >> ERROR: > >> Exception(/home/digimer/rpmbuild/SRPMS/mtr-0.75-5.el6.anvil.src.rpm) > >> Config(epel-6-x86_64) 5 minutes 54 seconds > >> INFO: Results and/or logs in: /var/lib/mock/epel-6-x86_64/result > >> ERROR: Command failed. See logs for output. > >> # bash --login -c /usr/bin/rpmbuild -bb --target x86_64 --nodeps > >> /builddir/build/SPECS/mtr.spec > >> ===> >> > >> As for redistribution; I spoke to someone here some months back about > >> creating a custom ISO and I was told I couldn't modify 'Packages', which > >> is what I needed to do. I am also making a RHEL variant, and emailing > >> their legal didn't get a reply, so I am going this route to not step on > >> toes. > >> > >> > >> > > okay looks like you've uncovered an bug in mock that should be reported > in > > EPEL > > > > > https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora%20EPEL&version=el6&component=mock > > > > I don't see any existing bug that would seem to apply ... > > > > You can see the build completes with a target of epel6 on an F23 install > > but a clean C6 install that uses the mock from epel6 fails: > > > > http://pastebin.centos.org/41116/ > > > > Can't see anything that differs in the output from that to explain why > the > > Makefile isn't regenerated on the epel6 mock unlike the F23 one. > > > > Right now I don't have time to look into this myself - perhaps Jim, > > Karanbir or Johnny can check build logs for how mtr was built at the 6.7 > > release. > > > > Given the different behaviour I'm guessing a mock bug ... would need to > > spend a while digging through those full build logs to compare if any > > packages differed, perhaps add some debug statements to the spec to track > > the changes to the Makefile and see why it isn't generated correctly on > the > > second build. > > https://bugzilla.redhat.com/show_bug.cgi?id=1315856 >What's odd is how it works in Fedora using mock but not EPEL6 with mock ... got to be down to how the build roots are constructed. Decided to do a quick test of something given how EPEL has adjusted macros recently to reduce boilerplate between Fedora and itself ... I just removed the rm -rf line from %clean and got a clean mock build on a CentOS6 base. It must have cleaned out the generated makefile between %build and %install and that left it with the bare one that had no install: section This will bite Red Hat at the 6.8 milestone (unless they build on Fedora) and presumably CentOS when 6.8 rolls round if RH don't remove the rm -rf from %clean ;)
On 08/03/16 02:08 PM, James Hogarth wrote:> On 8 March 2016 at 19:02, Digimer <lists at alteeve.ca> wrote: > >> On 08/03/16 01:51 PM, James Hogarth wrote: >>> On 8 March 2016 at 17:22, Digimer <lists at alteeve.ca> wrote: >>> >>>> On 08/03/16 11:36 AM, James Hogarth wrote: >>>>> On 8 March 2016 at 16:15, Digimer <lists at alteeve.ca> wrote: >>>>> >>>>>> On 08/03/16 07:11 AM, James Hogarth wrote: >>>>>>> On 8 March 2016 at 10:07, Leon Fauster <leonfauster at googlemail.com> >>>>>> wrote: >>>>>>> >>>>>>>> Am 08.03.2016 um 01:50 schrieb Digimer <lists at alteeve.ca>: >>>>>>>>> I'm not surprised, given that it is in the repo. That's why I was >>>>>> asking >>>>>>>>> if anyone tried building it themselves and, if so, did they have >> the >>>>>>>>> same issue as I describe below? >>>>>>>>> >>>>>>>>> Alternatively, any tips/advice on solving my build issue would be >>>>>>>> helpful. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> what says /var/tmp/rpm-tmp.gu9Ds0? >>>>>>>> >>>>>>>> all dependencies installed? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> No need to check that .... the error is clear "make: *** No rule to >>>> make >>>>>>> target `install'. Stop." ... that mini Makefile he posted doesn't >>>>>> include >>>>>>> an install: section >>>>>>> >>>>>>> Of course what the OP is missing is *that* makefile does not get >> used. >>>>>>> >>>>>>> In the tarball there is a Makefile.in that gets processed into the >>>> actual >>>>>>> makefile by ./configure (well %configure in the spec but you get the >>>>>> point) >>>>>>> >>>>>>> So we come back round the houses to the key point - Digimer what are >>>> you >>>>>>> *actually* trying to do? >>>>>>> >>>>>>> You obviously aren't building from the spec in that src.rpm or using >>>> mock >>>>>>> as those have configure which would generate the valid makefile with >>>> the >>>>>>> make install target... so what are you doing and what do you want to >>>>>>> achieve? >>>>>>> >>>>>>> The %install phase you posted is really not of interest to your >>>> 'problem' >>>>>>> but rather the %build phase would be telling. >>>>>> >>>>>> As I've done with several other RPMs, I did the following; >>>>>> >>>>>> ==>>>>>> yumdownloader --source mtr-gtk >>>>>> >>>>>> rpm -Uvh mtr-0.75-5.el6.src.rpm >>>>>> >>>>>> cd rpmbuild/SPECS/ >>>>>> >>>>>> # Change "Release" >>>>>> >>>>>> rpmbuild -ba mtr.spec >>>>>> ==>>>>>> >>>>>> If you're asking a more generic "why are you doing this?" question; I >> am >>>>>> including the RPM in a project we're working on and I don't want to >> risk >>>>>> running fould of the CentOS project by directly redistributing their >>>>>> (and RHEL's) rpms. >>>>>> >>>>>> >>>>> I'm sure Karanbir and Johnny can weigh in here more but so long as you >>>> are >>>>> not claiming to be CentOS and using their trademarks (see the modified >>>> ones >>>>> with centos in the name) I'm pretty certain that you are safe building >> an >>>>> appliance on CentOS and can ship the RPMs on that ... >>>>> >>>>> Regardless of that issue what you've described above should work (or >>>> freak >>>>> out if a build dependency was missing ... unless one isn't defined as a >>>>> BuildRequires but is in the default mock root and is causing %configure >>>>> not to generate the Makefile). >>>>> >>>>> Again the right answer here is "use mock" ... >>>>> >>>>> yumdownloader --source mtr-gtk >>>>> >>>>> rpm -Uvh mtr-0.75-5.el6.src.rpm >>>>> >>>>> cd rpmbuild >>>>> >>>>> vi SPECS/mtr.spec (change release etc ... bear in mind that bumping >>>> release >>>>> may not help you when a centos update happens ... may not care for an >>>>> appliance) >>>>> >>>>> rpmbuild -bs SPECS/mtr.spec >>>>> >>>>> mock -r epel-6-x86_64 SRPMS/mtr-*.src.rpm >>>>> >>>>> ===================>>>>> >>>>> That will get you a reproducible clean build environment in a way not >>>>> dependent on the state of your workstation and avoid any accidental >>>>> depednencies etc popping up >>>> >>>> Thanks for the help, but I got the same results; >>>> >>>> ===>>>> mock /home/digimer/rpmbuild/SRPMS/mtr-0.75-5.el6.anvil.src.rpm >>>> >>>> <dependencies installed> >>>> <build messages> >>>> + make DESTDIR=/builddir/build/BUILDROOT/mtr-0.75-5.el6.anvil.x86_64 >>>> install >>>> make: *** No rule to make target `install'. Stop. >>>> >>>> >>>> RPM build errors: >>>> error: Bad exit status from /var/tmp/rpm-tmp.8atuER (%install) >>>> Bad exit status from /var/tmp/rpm-tmp.8atuER (%install) >>>> ERROR: >>>> Exception(/home/digimer/rpmbuild/SRPMS/mtr-0.75-5.el6.anvil.src.rpm) >>>> Config(epel-6-x86_64) 5 minutes 54 seconds >>>> INFO: Results and/or logs in: /var/lib/mock/epel-6-x86_64/result >>>> ERROR: Command failed. See logs for output. >>>> # bash --login -c /usr/bin/rpmbuild -bb --target x86_64 --nodeps >>>> /builddir/build/SPECS/mtr.spec >>>> ===>>>> >>>> As for redistribution; I spoke to someone here some months back about >>>> creating a custom ISO and I was told I couldn't modify 'Packages', which >>>> is what I needed to do. I am also making a RHEL variant, and emailing >>>> their legal didn't get a reply, so I am going this route to not step on >>>> toes. >>>> >>>> >>>> >>> okay looks like you've uncovered an bug in mock that should be reported >> in >>> EPEL >>> >>> >> https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora%20EPEL&version=el6&component=mock >>> >>> I don't see any existing bug that would seem to apply ... >>> >>> You can see the build completes with a target of epel6 on an F23 install >>> but a clean C6 install that uses the mock from epel6 fails: >>> >>> http://pastebin.centos.org/41116/ >>> >>> Can't see anything that differs in the output from that to explain why >> the >>> Makefile isn't regenerated on the epel6 mock unlike the F23 one. >>> >>> Right now I don't have time to look into this myself - perhaps Jim, >>> Karanbir or Johnny can check build logs for how mtr was built at the 6.7 >>> release. >>> >>> Given the different behaviour I'm guessing a mock bug ... would need to >>> spend a while digging through those full build logs to compare if any >>> packages differed, perhaps add some debug statements to the spec to track >>> the changes to the Makefile and see why it isn't generated correctly on >> the >>> second build. >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1315856 >> > > > > > What's odd is how it works in Fedora using mock but not EPEL6 with mock ... > got to be down to how the build roots are constructed. > > Decided to do a quick test of something given how EPEL has adjusted macros > recently to reduce boilerplate between Fedora and itself ... > > I just removed the rm -rf line from %clean and got a clean mock build on a > CentOS6 base. > > It must have cleaned out the generated makefile between %build and %install > and that left it with the bare one that had no install: section > > This will bite Red Hat at the 6.8 milestone (unless they build on Fedora) > and presumably CentOS when 6.8 rolls round if RH don't remove the rm -rf > from %clean ;)Should the priority on the bug be changed? -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?
James Hogarth
2016-Mar-08 19:32 UTC
[CentOS] Can anyone compile mtr source RPM on CentOS 6.7?
On 8 March 2016 at 19:13, Digimer <lists at alteeve.ca> wrote:> On 08/03/16 02:08 PM, James Hogarth wrote: > > On 8 March 2016 at 19:02, Digimer <lists at alteeve.ca> wrote: > > > >> On 08/03/16 01:51 PM, James Hogarth wrote: > >>> On 8 March 2016 at 17:22, Digimer <lists at alteeve.ca> wrote: > >>> > >>>> On 08/03/16 11:36 AM, James Hogarth wrote: > >>>>> On 8 March 2016 at 16:15, Digimer <lists at alteeve.ca> wrote: > >>>>> > >>>>>> On 08/03/16 07:11 AM, James Hogarth wrote: > >>>>>>> On 8 March 2016 at 10:07, Leon Fauster <leonfauster at googlemail.com > > > >>>>>> wrote: > >>>>>>> > >>>>>>>> Am 08.03.2016 um 01:50 schrieb Digimer <lists at alteeve.ca>: > >>>>>>>>> I'm not surprised, given that it is in the repo. That's why I was > >>>>>> asking > >>>>>>>>> if anyone tried building it themselves and, if so, did they have > >> the > >>>>>>>>> same issue as I describe below? > >>>>>>>>> > >>>>>>>>> Alternatively, any tips/advice on solving my build issue would be > >>>>>>>> helpful. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> what says /var/tmp/rpm-tmp.gu9Ds0? > >>>>>>>> > >>>>>>>> all dependencies installed? > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> No need to check that .... the error is clear "make: *** No rule to > >>>> make > >>>>>>> target `install'. Stop." ... that mini Makefile he posted doesn't > >>>>>> include > >>>>>>> an install: section > >>>>>>> > >>>>>>> Of course what the OP is missing is *that* makefile does not get > >> used. > >>>>>>> > >>>>>>> In the tarball there is a Makefile.in that gets processed into the > >>>> actual > >>>>>>> makefile by ./configure (well %configure in the spec but you get > the > >>>>>> point) > >>>>>>> > >>>>>>> So we come back round the houses to the key point - Digimer what > are > >>>> you > >>>>>>> *actually* trying to do? > >>>>>>> > >>>>>>> You obviously aren't building from the spec in that src.rpm or > using > >>>> mock > >>>>>>> as those have configure which would generate the valid makefile > with > >>>> the > >>>>>>> make install target... so what are you doing and what do you want > to > >>>>>>> achieve? > >>>>>>> > >>>>>>> The %install phase you posted is really not of interest to your > >>>> 'problem' > >>>>>>> but rather the %build phase would be telling. > >>>>>> > >>>>>> As I've done with several other RPMs, I did the following; > >>>>>> > >>>>>> ==> >>>>>> yumdownloader --source mtr-gtk > >>>>>> > >>>>>> rpm -Uvh mtr-0.75-5.el6.src.rpm > >>>>>> > >>>>>> cd rpmbuild/SPECS/ > >>>>>> > >>>>>> # Change "Release" > >>>>>> > >>>>>> rpmbuild -ba mtr.spec > >>>>>> ==> >>>>>> > >>>>>> If you're asking a more generic "why are you doing this?" question; > I > >> am > >>>>>> including the RPM in a project we're working on and I don't want to > >> risk > >>>>>> running fould of the CentOS project by directly redistributing their > >>>>>> (and RHEL's) rpms. > >>>>>> > >>>>>> > >>>>> I'm sure Karanbir and Johnny can weigh in here more but so long as > you > >>>> are > >>>>> not claiming to be CentOS and using their trademarks (see the > modified > >>>> ones > >>>>> with centos in the name) I'm pretty certain that you are safe > building > >> an > >>>>> appliance on CentOS and can ship the RPMs on that ... > >>>>> > >>>>> Regardless of that issue what you've described above should work (or > >>>> freak > >>>>> out if a build dependency was missing ... unless one isn't defined > as a > >>>>> BuildRequires but is in the default mock root and is causing > %configure > >>>>> not to generate the Makefile). > >>>>> > >>>>> Again the right answer here is "use mock" ... > >>>>> > >>>>> yumdownloader --source mtr-gtk > >>>>> > >>>>> rpm -Uvh mtr-0.75-5.el6.src.rpm > >>>>> > >>>>> cd rpmbuild > >>>>> > >>>>> vi SPECS/mtr.spec (change release etc ... bear in mind that bumping > >>>> release > >>>>> may not help you when a centos update happens ... may not care for an > >>>>> appliance) > >>>>> > >>>>> rpmbuild -bs SPECS/mtr.spec > >>>>> > >>>>> mock -r epel-6-x86_64 SRPMS/mtr-*.src.rpm > >>>>> > >>>>> ===================> >>>>> > >>>>> That will get you a reproducible clean build environment in a way not > >>>>> dependent on the state of your workstation and avoid any accidental > >>>>> depednencies etc popping up > >>>> > >>>> Thanks for the help, but I got the same results; > >>>> > >>>> ===> >>>> mock /home/digimer/rpmbuild/SRPMS/mtr-0.75-5.el6.anvil.src.rpm > >>>> > >>>> <dependencies installed> > >>>> <build messages> > >>>> + make DESTDIR=/builddir/build/BUILDROOT/mtr-0.75-5.el6.anvil.x86_64 > >>>> install > >>>> make: *** No rule to make target `install'. Stop. > >>>> > >>>> > >>>> RPM build errors: > >>>> error: Bad exit status from /var/tmp/rpm-tmp.8atuER (%install) > >>>> Bad exit status from /var/tmp/rpm-tmp.8atuER (%install) > >>>> ERROR: > >>>> Exception(/home/digimer/rpmbuild/SRPMS/mtr-0.75-5.el6.anvil.src.rpm) > >>>> Config(epel-6-x86_64) 5 minutes 54 seconds > >>>> INFO: Results and/or logs in: /var/lib/mock/epel-6-x86_64/result > >>>> ERROR: Command failed. See logs for output. > >>>> # bash --login -c /usr/bin/rpmbuild -bb --target x86_64 --nodeps > >>>> /builddir/build/SPECS/mtr.spec > >>>> ===> >>>> > >>>> As for redistribution; I spoke to someone here some months back about > >>>> creating a custom ISO and I was told I couldn't modify 'Packages', > which > >>>> is what I needed to do. I am also making a RHEL variant, and emailing > >>>> their legal didn't get a reply, so I am going this route to not step > on > >>>> toes. > >>>> > >>>> > >>>> > >>> okay looks like you've uncovered an bug in mock that should be reported > >> in > >>> EPEL > >>> > >>> > >> > https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora%20EPEL&version=el6&component=mock > >>> > >>> I don't see any existing bug that would seem to apply ... > >>> > >>> You can see the build completes with a target of epel6 on an F23 > install > >>> but a clean C6 install that uses the mock from epel6 fails: > >>> > >>> http://pastebin.centos.org/41116/ > >>> > >>> Can't see anything that differs in the output from that to explain why > >> the > >>> Makefile isn't regenerated on the epel6 mock unlike the F23 one. > >>> > >>> Right now I don't have time to look into this myself - perhaps Jim, > >>> Karanbir or Johnny can check build logs for how mtr was built at the > 6.7 > >>> release. > >>> > >>> Given the different behaviour I'm guessing a mock bug ... would need to > >>> spend a while digging through those full build logs to compare if any > >>> packages differed, perhaps add some debug statements to the spec to > track > >>> the changes to the Makefile and see why it isn't generated correctly on > >> the > >>> second build. > >> > >> https://bugzilla.redhat.com/show_bug.cgi?id=1315856 > >> > > > > > > > > > > What's odd is how it works in Fedora using mock but not EPEL6 with mock > ... > > got to be down to how the build roots are constructed. > > > > Decided to do a quick test of something given how EPEL has adjusted > macros > > recently to reduce boilerplate between Fedora and itself ... > > > > I just removed the rm -rf line from %clean and got a clean mock build on > a > > CentOS6 base. > > > > It must have cleaned out the generated makefile between %build and > %install > > and that left it with the bare one that had no install: section > > > > This will bite Red Hat at the 6.8 milestone (unless they build on Fedora) > > and presumably CentOS when 6.8 rolls round if RH don't remove the rm -rf > > from %clean ;) > > Should the priority on the bug be changed? >No leave it as is for now ... I'm really quite confused as after it worked I thought I'd try the original SRPM again and it worked :/ I have no idea what has changed on the system to provide for that - doing some quick looks now.