On 08/03/16 02:08 PM, James Hogarth wrote:
> On 8 March 2016 at 19:02, Digimer <lists@xxxxxxxxxx> wrote:
>
>> On 08/03/16 01:51 PM, James Hogarth wrote:
>>> On 8 March 2016 at 17:22, Digimer <lists@xxxxxxxxxx> wrote:
>>>
>>>> On 08/03/16 11:36 AM, James Hogarth wrote:
>>>>> On 8 March 2016 at 16:15, Digimer <lists@xxxxxxxxxx> wrote:
>>>>>
>>>>>> On 08/03/16 07:11 AM, James Hogarth wrote:
>>>>>>> On 8 March 2016 at 10:07, Leon Fauster <leonfauster@xxxxxxxxxxxxxx>
>>>>>> wrote:
>>>>>>>
>>>>>>>> Am 08.03.2016 um 01:50 schrieb Digimer <lists@xxxxxxxxxx>:
>>>>>>>>> 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?
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
