Re: Build issue with i386 port

On Mon, Apr 11, 2022 at 8:14 PM <jbo@insane.engineer> wrote:
>
> > I would cherry pick the patch with PATCHFILES:
> > https://docs.freebsd.org/en/books/porters-handbook/book/#makefile-distfiles
> >
> > +PATCH_SITES= https://github.com/Dr-Noob/cpufetch/commit/
> > +PATCHFILES= 0db9f1f5c26e57a6383f4609c5605ed5d3d41fd1.patch:-p1
> >
> > I already have the change ready to push it. Shall we?
>
> Green light from my side!
> Thank you for your efforts, it's greatly appreciated.
>
>

Done. https://cgit.FreeBSD.org/ports/commit/?id=c6e6c7f15310fe881692447dbb56749f0860670b

Cheers!

>
>
> ------- Original Message -------
> On Monday, April 11th, 2022 at 20:10, Fernando Apesteguía <fernape@freebsd.org> wrote:
>
>
> >
> >
> > On Mon, Apr 11, 2022 at 8:04 PM jbo@insane.engineer wrote:
> >
> > > Oooh! This is so obvious it almost hurts...
> > > So basically what happened is that upstream's v1.00 release that the port is building didn't yet support i386. Meanwhile, I was able to compile
> > > successfully on my VMs because I was using the main/master branch which does support i386.
> > > I hope we can just consider this a beginner's mistake :p
> > >
> > > This brings me to the next question: According to Repology [1], a lot of packages are using the v1.01 tag whereas our port is currently
> > > using v1.00. The reason I didn't update the port yet is because there isn't an official release on the upstream's GitHub page.
> > > What is the recommended/preferred way of handling this?
> >
> >
> > I would cherry pick the patch with PATCHFILES:
> > https://docs.freebsd.org/en/books/porters-handbook/book/#makefile-distfiles
> >
> > +PATCH_SITES= https://github.com/Dr-Noob/cpufetch/commit/
> > +PATCHFILES= 0db9f1f5c26e57a6383f4609c5605ed5d3d41fd1.patch:-p1
> >
> > I already have the change ready to push it. Shall we?
> >
> > > [1] https://repology.org/project/cpufetch/versions
> > >
> > > Best regards,
> > > ~ Joel
> > >
> > > ------- Original Message -------
> > > On Monday, April 11th, 2022 at 19:57, Dimitry Andric dim@FreeBSD.org wrote:
> > >
> > > > On 11 Apr 2022, at 19:53, Fernando Apesteguía fernape@freebsd.org wrote:
> > > >
> > > > > On Mon, Apr 11, 2022 at 7:24 PM jbo@insane.engineer wrote:
> > > >
> > > > ...
> > > >
> > > > > > gmake[1]: Entering directory '/wrkdirs/usr/ports/sysutils/cpufetch/work/cpufetch-1.00'
> > > > > > Makefile:38: Unsupported arch detected: i386. See https://github.com/Dr-Noob/cpufetch#1-support
> > > > > > Makefile:39: If your architecture is supported but the compilation fails, please open an issue in https://github.com/Dr-Noob/cpufetch/issues
> > > > > > Makefile:40: *** Aborting compilation. Stop.
> > > > > > gmake[1]: Leaving directory '/wrkdirs/usr/ports/sysutils/cpufetch/work/cpufetch-1.00'
> > > > > > ===> Compilation failed unexpectedly.
> > > > > > Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
> > > > > > the maintainer.
> > > > > > *** Error code 1
> > > > > >
> > > > > > Upstream's Makefile uses $(shell uname -m) to determine the architecture [2]. My VMs are successfully reporting this as
> > > > > > i386 which upstream's Makefile appears to support explicitly. After all, I'm also able to build this software
> > > > > > on those VMs if just cloning & running gmake manually.
> > > > > >
> > > > > > I'm not really sure where to go from here. As I can build the software in FreeBSD i386 VMs I think
> > > > > > that the issue is related to my port and not upstream. But then again, the build fails "within" upstream's Makefile.
> > > > > >
> > > > > > Could somebody help me out here?
> > > > >
> > > > > When the Makefile checks the output of uname -m, it compares the
> > > > > result with a list of values that includes i686 but not i386.
> > > > > I think a simple REINPLACE_CMD would suffice here.
> > > > >
> > > > > Since I failed to detect this, do you want me to fix it in the repo? I
> > > > > will also send a patch upstream.
> > > >
> > > > No need :)
> > > > https://github.com/Dr-Noob/cpufetch/commit/0db9f1f5c26e57a6383f4609c5605ed5d3d41fd1
> > > >
> > > > -Dimitry