On 8 March 2016 at 19:13, Digimer <lists@xxxxxxxxxx> wrote:
> 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?
>
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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
