GitHub: size of remote file is not known
I don't use Github. So I'm not familiar with their service(s). But ports using source fetched from them always return: size of remote file is not known Is it that their servers simply refuse to return size/content-length or is this something else? I can see where this might turn into a problem for those attempting to build ports on a system with limited resources -- especially during a meta-port build, and even more so for newcomers. Is anyone familiar with why this is so? I'd like to change this. Thanks! --Chris ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: %%CONFIGURE_TARGET%% in Makefile and pkg-plist
On Sun, Jan 3, 2021 at 8:41 PM Tomasz CEDRO wrote:
> Hello world :-)
> The new port is comms/limesuite. The pkg-plist line affected is:
> %%OCTAVE%%lib/octave/%%OCTAVE_VERSION%%/site/oct/%%CONFIGURE_TARGET%%/LimeSuite.oct
>
> The problem is as reported in [1]. First variable %%OCTAVE_VERSION%%
> gets replaced and taken from .include
> "../../math/octave/Makefile.version" (I would really prefer to see
> currently installed octave here). Second variable %%CONFIGURE_TARGET%%
> does not get replaced in make package or gets replaced with invalid
> value in stage (i.e. 12.1 on 12.2 platform) leading to invalid
> pkg-plist generation and then problems with make package.
Allright, mystery solved, that full path is provided by the
octave-config utility that is part of the Octave suite, this magic
path in Stage was taken from a CMAKE and provided by octave-config
binary build for pkg on 12.1 system, so we need to obtain this path as
well in Port Makefile (I found VAR!=exec very handy) and then
substitute that full path in a pkg-plist. Now our port fully adapts to
existing Octave Suite binary :-)
Makefile.diff:
-PLIST_SUB+=OCTAVE_VERSION=${OCTAVE_VERSION}
+OCTAVE_OCT_SITE_DIR!= (octave-config --oct-site-dir)
+OCTAVE_M_SITE_DIR!=(octave-config --m-site-dir)
+PLIST_SUB+=OCTAVE_OCT_SITE_DIR=${OCTAVE_OCT_SITE_DIR}
+PLIST_SUB+=OCTAVE_M_SITE_DIR=${OCTAVE_M_SITE_DIR}
pkg-plist.diff:
-%%OCTAVE%%lib/octave/%%OCTAVE_VERSION%%/site/oct/%%CONFIGURE_TARGET%%/LimeSuite.oct
-%%OCTAVE%%share/octave/%%OCTAVE_VERSION%%/site/m/LoadLimeSuite.m
+%%OCTAVEOCTAVE_OCT_SITE_DIR%%/LimeSuite.oct
+%%OCTAVEOCTAVE_M_SITE_DIR%%/LoadLimeSuite.m
CONFIGURE_TARGET is not even necessary here and works as expected it
just needs an assignment in a way:
PLIST_SUB+= CONFIGURE_TARGET=${CONFIGURE_TARGET}
Because at the moment we use this port mainly for debugging USB driver
problem I have also added and enabled by default DEBUG build option
that will generate binaries ready do debug. Original port stripped
them sorry and manual build with debug may be a blocker for testers.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252350
Feedback and Testing welcome Radio-Amateurs :-)
Happy New Year :-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: REINPLACE_CMD QA causing pkg-fallout
On Mon, 4 Jan 2021 18:56:31 +0100
Michael Gmelin wrote:
> On Sat, 2 Jan 2021 18:33:12 +0100
> Michael Gmelin wrote:
>
> > Hi,
> >
> > I updated the devel/phabricator port yesterday, which included
> > running the usual QA steps (`poudriere testport', also running "make
> > check-plist" on a local ports tree).
> >
> > Later, after committing the change and when updating on a production
> > machine, I noticed a problem with the package list, which I first
> > corrected in-place and then committed the corrections. Today I
> > started receiving pkg-fallout messages - seems like timing was quite
> > unfortunate. Those messages motivated me to look into the issue
> > and I figured out why it failed:
> >
> > It turns out that if DEVELOPER is set, it worked fine (which is
> > also what is set when `poudriere testport' is run). Without
> > DEVELOPER set (e.g., in `poudriere bulk') it failed.
> >
> > The reason is that this port sets REINPLACE_ARGS to override the
> > "-i" argument to $REINPLACE_CMD like this:
> >
> > REINPLACE_ARGS= -i ""
> >
> > which seems to be the intended use of this variable, according to
> > bsd.port.mk:
> >
> > # Macro for doing in-place file editing using regexps.
> > # REINPLACE_ARGS may only be used to set or override the -i
> > # argument. Any other use is considered invalid.
> >
> > Now, since r522484[0], reviewed in [1], REINPLACE_CMD is set to
> > sed_checked.sh (which now is ${SCRIPTSDIR}/sed_checked.sh), which
> > hardcodes the call to `/usr/bin/sed -i.bak "$@"'.
> >
> > Therefore, this is what made me create the broken pkg-plist:
> > - I had "DEVELOPER=yes" in /etc/make.conf.
> > - I used `make makeplist' to create a new pkg-list.
> > - The new pkg-plist contained .bak files created by sed_checked.sh
> > without me noticing.
> > - `make stage-qa' and `poudriere testport' worked just fine, as the
> > .bak files are created there as well.
> > - Once building without "DEVELOPER" set (production server with
> > ports tree, `poudriere bulk', project build servers), it failed, as
> > sed_checked.sh isn't involved there, so no .bak files are created,
> > as REINPLACE_ARGS is applied.
> >
> > To keep supporting overriding "-i" and making sure that DEVELOPER
> > builds are the same as non-DEVELOPER builds, I would suggest to
> > modify sed_checked.sh like this:
> >
> > - Change the call to sed: /usr/bin/sed -i.sedcheck "$@"
> > - Move the backup file back to the original file after checking:
> > mv "$@".sedcheck "$@"
> > - Run sed again, this time passing $REINPLACE_ARGS
> >
> > Maybe @swills has time to look into this, if not, I'll try to find
> > the time to come up with a patch and open a review.
> >
> > Cheers,
> > Michael
> >
> > [0] https://svnweb.freebsd.org/ports?view=revision&revision=522484
> > [1] https://reviews.freebsd.org/D22174
> >
>
> I implemented a simple fix and opened a review:
> https://lists.freebsd.org/pipermail/freebsd-ports/2021-January/119978.html
>
> -m
>
Breaking the recursion, here's the correct link to the review:
https://reviews.freebsd.org/D27954
-m
--
Michael Gmelin
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: REINPLACE_CMD QA causing pkg-fallout
On Sat, 2 Jan 2021 18:33:12 +0100
Michael Gmelin wrote:
> Hi,
>
> I updated the devel/phabricator port yesterday, which included running
> the usual QA steps (`poudriere testport', also running "make
> check-plist" on a local ports tree).
>
> Later, after committing the change and when updating on a production
> machine, I noticed a problem with the package list, which I first
> corrected in-place and then committed the corrections. Today I started
> receiving pkg-fallout messages - seems like timing was quite
> unfortunate. Those messages motivated me to look into the issue
> and I figured out why it failed:
>
> It turns out that if DEVELOPER is set, it worked fine (which is
> also what is set when `poudriere testport' is run). Without DEVELOPER
> set (e.g., in `poudriere bulk') it failed.
>
> The reason is that this port sets REINPLACE_ARGS to override the "-i"
> argument to $REINPLACE_CMD like this:
>
> REINPLACE_ARGS= -i ""
>
> which seems to be the intended use of this variable, according to
> bsd.port.mk:
>
> # Macro for doing in-place file editing using regexps.
> # REINPLACE_ARGS may only be used to set or override the -i
> # argument. Any other use is considered invalid.
>
> Now, since r522484[0], reviewed in [1], REINPLACE_CMD is set to
> sed_checked.sh (which now is ${SCRIPTSDIR}/sed_checked.sh), which
> hardcodes the call to `/usr/bin/sed -i.bak "$@"'.
>
> Therefore, this is what made me create the broken pkg-plist:
> - I had "DEVELOPER=yes" in /etc/make.conf.
> - I used `make makeplist' to create a new pkg-list.
> - The new pkg-plist contained .bak files created by sed_checked.sh
> without me noticing.
> - `make stage-qa' and `poudriere testport' worked just fine, as the
> .bak files are created there as well.
> - Once building without "DEVELOPER" set (production server with ports
> tree, `poudriere bulk', project build servers), it failed, as
> sed_checked.sh isn't involved there, so no .bak files are created,
> as REINPLACE_ARGS is applied.
>
> To keep supporting overriding "-i" and making sure that DEVELOPER
> builds are the same as non-DEVELOPER builds, I would suggest to modify
> sed_checked.sh like this:
>
> - Change the call to sed: /usr/bin/sed -i.sedcheck "$@"
> - Move the backup file back to the original file after checking:
> mv "$@".sedcheck "$@"
> - Run sed again, this time passing $REINPLACE_ARGS
>
> Maybe @swills has time to look into this, if not, I'll try to find the
> time to come up with a patch and open a review.
>
> Cheers,
> Michael
>
> [0] https://svnweb.freebsd.org/ports?view=revision&revision=522484
> [1] https://reviews.freebsd.org/D22174
>
I implemented a simple fix and opened a review:
https://lists.freebsd.org/pipermail/freebsd-ports/2021-January/119978.html
-m
--
Michael Gmelin
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: gmake can't find GNUmakefile, only Makefile?
Thanks! It works perfectly! Fernando Apesteguía escreveu no dia segunda, 4/01/2021 à(s) 12:49: > > > On Mon, Jan 4, 2021 at 1:45 PM Nuno Teixeira wrote: > >> Hello, >> >> I'm porting a c'++ program that depends on gmake. >> >> upstream uses GNUmakefile instead of Makefile name. >> > > Try: > > MAKEFILE= GNUmakefile > > >> Thats strange that gmake sees GNUmakefile when doing gmake in work/port >> but >> port itself fails with: >> >> --- >> gmake[2]: Entering directory >> '/usr/home/nunotex/Work/ports/cxxmatrix/work/port' >> gmake[2]: Makefile: No such file or directory >> gmake[2]: *** No rule to make target 'Makefile'. Stop. >> gmake[2]: Leaving directory >> '/usr/home/nunotex/Work/ports/cxxmatrix/work/port' >> ===> Compilation failed unexpectedly. >> --- >> >> How do I tell gmake to find it?, >> >> Thanks, >> >> Nuno Teixeira >> ___ >> freebsd-ports@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-ports >> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" >> > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: gmake can't find GNUmakefile, only Makefile?
On Mon, Jan 4, 2021 at 1:45 PM Nuno Teixeira wrote: > Hello, > > I'm porting a c'++ program that depends on gmake. > > upstream uses GNUmakefile instead of Makefile name. > Try: MAKEFILE= GNUmakefile > Thats strange that gmake sees GNUmakefile when doing gmake in work/port but > port itself fails with: > > --- > gmake[2]: Entering directory > '/usr/home/nunotex/Work/ports/cxxmatrix/work/port' > gmake[2]: Makefile: No such file or directory > gmake[2]: *** No rule to make target 'Makefile'. Stop. > gmake[2]: Leaving directory > '/usr/home/nunotex/Work/ports/cxxmatrix/work/port' > ===> Compilation failed unexpectedly. > --- > > How do I tell gmake to find it?, > > Thanks, > > Nuno Teixeira > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
gmake can't find GNUmakefile, only Makefile?
Hello, I'm porting a c'++ program that depends on gmake. upstream uses GNUmakefile instead of Makefile name. Thats strange that gmake sees GNUmakefile when doing gmake in work/port but port itself fails with: --- gmake[2]: Entering directory '/usr/home/nunotex/Work/ports/cxxmatrix/work/port' gmake[2]: Makefile: No such file or directory gmake[2]: *** No rule to make target 'Makefile'. Stop. gmake[2]: Leaving directory '/usr/home/nunotex/Work/ports/cxxmatrix/work/port' ===> Compilation failed unexpectedly. --- How do I tell gmake to find it?, Thanks, Nuno Teixeira ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Broken Ports Tree Neochat/kquickimageeditor r560251
On Monday, 4 January 2021 04:22:32 CET Li-Wen Hsu wrote: > On Mon, Jan 4, 2021 at 9:42 AM Nick Wolff wrote: > > Hello Adriaan , > > > > https://svnweb.freebsd.org/ports?view=revision&revision=560251 Seems to > > cause poudriere to puke due to a missing line in graphics/Makefile for new > > port dependency you added. > > I've committed this in r560258. Thanks for the patch! Thank you Li-Wen for cleaning up after me. I can guess how this passed my local builds, but not elsewhere: I built the kquickimageeditor port (and package) with poudriere explicitly, first .. so it was already lying around for use when I then tried to build neochat; I never needed the INDEX. /me adds a "srsly, don't add a new port as part of an update to another" to his checklist [ade] signature.asc Description: This is a digitally signed message part.
