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 -- 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?