Mk/bsd.port.mk PORTS_FEATURES logic fix?
Hello,
just from an isolated view, line 1047
(https://svnweb.freebsd.org/ports/head/Mk/bsd.port.mk?view=markup=529956)
reads:
if !defined(PORTS_FEATURES) && empty(${PORTS_FEATURES:MFLAVORS})
I guess the negation was swapped, since ${PORTS_FEATURES:MFLAVORS} is
always empty if ${PORTS_FEATURES} is undefined, is it?
Never looked at PORTS_FEATURES, but what's the meaning if FLAVORS is
added unconditionally – even if the tautological if statement was fixed,
it's still unconditionally set…
Thanks,
-harry
___
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: [PATCH] Fix simple typos in Mk/bsd.port.mk
On Mon, Sep 9, 2019 at 5:38 PM Rebecca Cran wrote:
>
> I'm not a ports committer. So if anyone's interested, could someone else
> commit the following (change "Unkown" to "Unknown"), please?
>
>
> Index: Mk/bsd.port.mk
> ===
> --- Mk/bsd.port.mk (revision 511716)
> +++ Mk/bsd.port.mk (working copy)
> @@ -1462,7 +1462,7 @@
> .endif
> .endfor
> .if !defined(_usefound)
> -ERROR+="Unkonwn USES=${f:C/\:.*//}"
> +ERROR+="Unknown USES=${f:C/\:.*//}"
> .endif
> .endfor
>
> @@ -1984,7 +1984,7 @@
> .endif
> .endfor
> .if !defined(_usefound)
> -ERROR+="Unkonwn USES=${f:C/\:.*//}"
> +ERROR+="Unknown USES=${f:C/\:.*//}"
> .endif
> .endfor
Done. Thanks Rebecca! I'd love to fix as many of these as you can find.
# Adam
--
Adam Weinberger
ad...@adamw.org
https://www.adamw.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"
[PATCH] Fix simple typos in Mk/bsd.port.mk
I'm not a ports committer. So if anyone's interested, could someone else
commit the following (change "Unkown" to "Unknown"), please?
Index: Mk/bsd.port.mk
=======
--- Mk/bsd.port.mk (revision 511716)
+++ Mk/bsd.port.mk (working copy)
@@ -1462,7 +1462,7 @@
.endif
.endfor
.if !defined(_usefound)
-ERROR+= "Unkonwn USES=${f:C/\:.*//}"
+ERROR+= "Unknown USES=${f:C/\:.*//}"
.endif
.endfor
@@ -1984,7 +1984,7 @@
.endif
.endfor
.if !defined(_usefound)
-ERROR+= "Unkonwn USES=${f:C/\:.*//}"
+ERROR+= "Unknown USES=${f:C/\:.*//}"
.endif
.endfor
-- Rebecca Cran
___
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"
poudriere-devel: make: cannot open /usr/ports/Mk/bsd.port.mk
Hi All! I've set up a new poudriere test box and get an error: - % pkg info -x poudriere-devel poudriere-devel-3.1.99.20151125_1 % uname -a FreeBSD sm.bsnet 11.0-CURRENT FreeBSD 11.0-CURRENT #23 r291910: Mon Dec 7 02:45:32 MSK 2015 bsam@sm.bsnet:/usr/obj/usr/src/sys/SM amd64 % sudo poudriere bulk -j 11-amd64 -p default ports-mgmt/poudriere-devel [00:00:00] >> Creating the reference jail... done [00:00:00] >> Mounting system devices for 11-amd64-default [00:00:00] >> Mounting ports/packages/distfiles [00:00:00] >> Converting package repository to new format [00:00:00] >> Stashing existing package repository [00:00:00] >> Mounting ccache from: /var/cache/ccache [00:00:00] >> Mounting packages from: /poudriere/data/packages/11-amd64-default /etc/resolv.conf -> /poudriere/data/.m/11-amd64-default/ref/etc/resolv.conf [00:00:00] >> Starting jail 11-amd64-default make: cannot open /usr/ports/Mk/bsd.port.mk. [00:00:00] >> Cleaning up [00:00:00] >> Umounting file systems - Is it a misconfigure/bug/smth else? The server does not have /usr/ports populated. Should it? Thanks! -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: suggestion of a pre- install- recursive for Mk/bsd.port.mk
Walter Schwarzenfeld wrote: > Hallo !! > > Please run make extract and post the lines 8700 - 8730 of > work/gtk+-2.24.28/gdk/Gdk-2.0.gir. Hi Walter Thanks, yesterday (when I posted to gnome@freebsd) I'd have really appreciated help on gtk20 :-) , but as I wrote to ports@freebsdd since: > Solved with a crude: > pkg delete gtk2-2.24.28_1 > cd /usr/ports/x11-toolkits/gtk20 ; make So I don't know what you want it for, but here it is -- glib:nick="eraser"> -- Which I presume is all OK, as my makes depending on gtk20 now pass on. What interests me now is an install- dependencies- recursively- before- makeing- parent- node function for Mk/ Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Reply after previous text, like a play - Not before, which loses context. Indent previous text with "> " Insert new lines before 80 chars. Send plain text, Not quoted-printable, Not HTML, Not ms.doc, Not base64. ___ 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: suggestion of a pre- install- recursive for Mk/bsd.port.mk
Walter Schwarzenfeld wrote: > Sorry, seems I not read: > Solved with a crude. Thanks again though Walter, nice that you were ready to help :-) Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Reply after previous text, like a play - Not before, which loses context. Indent previous text with "> " Insert new lines before 80 chars. Send plain text, Not quoted-printable, Not HTML, Not ms.doc, Not base64. ___ 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: suggestion of a pre- install- recursive for Mk/bsd.port.mk
Sorry, seems I not read: Solved with a crude. ___ 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"
suggestion of a pre- install- recursive for Mk/bsd.port.mk
I had a problem with my current x11-toolkits/gtk20 http://lists.freebsd.org/pipermail/freebsd-gnome/2015-September/033060.html Solved with a crude: pkg delete gtk2-2.24.28_1 cd /usr/ports/x11-toolkits/gtk20 ; make but that zapped my system, deleting 330m meg of other presumably mostly working stuff, a lot of stuff to wait to re-make & reinstall. To debug any port, it would be nice if we had a make label that would forcibly recursively re-install all dependencies Before the main make, not just after install of main, as is done by my patch for make reinstall-recursive http://berklix.com/~jhs/src/bsd/fixes/freebsd/ports/gen/Mk/bsd.port.mk.reinstall-recursive.REL=8.2-RELEASE.diff http://berklix.com/~jhs/src/bsd/fixes/freebsd/ports/gen/Mk/bsd.port.subdir.mk.reinstall-recursive.REL=8.2-RELEASE.diff A shell or macro to make & install from list from `make build-depends` Should I write it, or does it exist, can we throw a shell to do it ? This did not achieve it: cd /usr/ports/x11-toolkits/gtk20 make build-depends make package-depends make config-recursive unsetenv NOCLEANDEPENDS make clean make rmconfig-recursive make config-recursive make In theory it shouldn't be necessary in a static well built ports/ but in a current moving target, while it appears all dependencies are made & installed, it will have bits that have changed but are not detected. Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Reply after previous text, like a play - Not before, which looses context. Indent previous text with "> " Insert new lines before 80 chars. Send plain text, Not quoted-printable, Not HTML, Not ms.doc, Not base64. ___ 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: suggestion of a pre- install- recursive for Mk/bsd.port.mk
Hallo !! Please run make extract and post the lines 8700 - 8730 of work/gtk+-2.24.28/gdk/Gdk-2.0.gir. greetings ___ 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: bsd.port.mk reduce error to warning for UNAME_r OSVERSION mismatch
Sorry for my delay replying, Thanks to
olli hauer wrote Thu Jun 18 04:28:49 UTC 2015 :
On 2015-06-16 17:06, Julian H. Stacey wrote:
bsd.port.mk test below is too agressive, let's have it just Warn, not Fail.
Also prefix text Error: or Warning: make it obvious which is
happening.
It seems likely people may have different opinions if it should
just Warn or Error, so kets add an environent switch to stear that decision.
Which way the default setting of switch should be, I won't suggest
(in hope of enhancing chance of agreement to add the switch :-)
Whoever adds the switch could decide ?
Background:
current fails to make my /usr/ports/graphics/libspiro
I contacted cc'd MAINTAINER= who wrote me
my poudriere is running on 10
I dont run poudriere, but have a native 10 partition
so simply did a chroot ...
I ran:
cd /s2; head -1 /etc/motd
To correct myself: cd /s2; chroot /s2 ; head -1 /etc/motd
# FreeBSD 10.1-RELEASE (LAPR.small) #0: Sat Feb 28 16:29:20 CET 2015
cd /usr/ports/graphics/libspiro
make clean
make: /usr/ports/Mk/bsd.port.mk line 1214: UNAME_r (11.0-CURRENT) and
OSVERSION (1001000) do not agree on major version number.
make
make: /usr/ports/Mk/bsd.port.mk line 1214: UNAME_r (11.0-CURRENT) and
OSVERSION (1001000) do not agree on major version number.
Same forced error can be seen on current lines 1197 1199.
After I patched out the failing bsd.port.mk error I could continue my test
of the port see the port build with 10 src ports on an 11 kernel.
Patching bsd.port.mk is not the way to go, set the following environment vars
before starting a build inside the jail
- UNAME_r=10.1-RELEASE-p10
- UNAME_v=FreeBSD 10.1-RELEASE-p10
- OSVERSION=1001000
For example in the login.conf of the jail
default:\
:setenv=UNAME_r=10.1-RELEASE-p10,UNAME_v=FreeBSD
10.1-RELEASE-p10,OSVERSION=1001000:\
...
Thanks for the syntax Olli, I've noted it for use on a slim sharing jail,
But what I perhaps didn't make sufficiently clear above last time:
It's a _chroot_ to a total complete working bootable partition.
It's not appropriate to edit bsd.port.mk
It should not be necessary to assert any environment varables.
(+ it's un-necessarily hard work to deduce different numbers to feed env vars
to test each different complete bootable partition).
bsd.port.mk should simply Not break, but Does break.
The diff below both improves the error report,
optionaly fixes errors to warnings.
http://www.berklix.com/~jhs/src/bsd/fixes/FreeBSD/ports/gen/Mk/bsd.port.mk.error_to_warn.REL=11.0-CURRENT.diff
*** ports/Mk/bsd.port.mko Tue Jun 16 17:10:28 2015
--- ports/Mk/bsd.port.mkFri Jun 19 16:19:28 2015
***
*** 1194,1202
# Skip if OSVERSION specified on cmdline for testing. Only works for bmake.
.if !defined(.MAKEOVERRIDES) || !${.MAKEOVERRIDES:MOSVERSION}
.if ${_OSVERSION_MAJOR} != ${UNAMER:R}
! .error UNAME_r (${UNAMER}) and OSVERSION (${OSVERSION}) do not agree on major
version number.
.elif ${_OSVERSION_MAJOR} != ${OSREL:R}
! .error OSREL (${OSREL}) and OSVERSION (${OSVERSION}) do not agree on major
version number.
.endif
.endif
--- 1194,1210
# Skip if OSVERSION specified on cmdline for testing. Only works for bmake.
.if !defined(.MAKEOVERRIDES) || !${.MAKEOVERRIDES:MOSVERSION}
.if ${_OSVERSION_MAJOR} != ${UNAMER:R}
! .ifndef BERKLIX
! .error Fatal Error: UNAME_r (${UNAMER}) and OSVERSION (${OSVERSION}) do not
agree on major version number.
! .else
! .warning Warning: UNAME_r (${UNAMER}) and OSVERSION (${OSVERSION}) do not
agree on major version number.
! .endif
.elif ${_OSVERSION_MAJOR} != ${OSREL:R}
! .ifndef BERKLIX
! .error Fatal Error: OSREL (${OSREL}) and OSVERSION (${OSVERSION}) do not
agree on major version number.
! .else
! .warning Warning: OSREL (${OSREL}) and OSVERSION (${OSVERSION}) do not agree
on major version number.
! .endif
.endif
.endif
Cheers,
Julian
--
Julian Stacey, BSD Linux Unix Net Sys Eng Consultant Munich http://berklix.com
Reply after previous text, like a play - Not before, which looses context.
Indent previous text with Insert new lines before 80 chars.
Send plain text, Not quoted-printable, Not HTML, Not ms.doc, Not base64.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: bsd.port.mk reduce error to warning for UNAME_r OSVERSION mismatch
On 2015-06-16 17:06, Julian H. Stacey wrote: bsd.port.mk test below is too agressive, let's have it just Warn, not Fail. Also prefix text Error: or Warning: make it obvious which is happening. It seems likely people may have different opinions if it should just Warn or Error, so kets add an environent switch to stear that decision. Which way the default setting of switch should be, I won't suggest (in hope of enhancing chance of agreement to add the switch :-) Whoever adds the switch could decide ? Background: current fails to make my /usr/ports/graphics/libspiro I contacted cc'd MAINTAINER= who wrote me my poudriere is running on 10 I dont run poudriere, but have a native 10 partition so simply did a chroot ... I ran: cd /s2; head -1 /etc/motd # FreeBSD 10.1-RELEASE (LAPR.small) #0: Sat Feb 28 16:29:20 CET 2015 cd /usr/ports/graphics/libspiro make clean make: /usr/ports/Mk/bsd.port.mk line 1214: UNAME_r (11.0-CURRENT) and OSVERSION (1001000) do not agree on major version number. make make: /usr/ports/Mk/bsd.port.mk line 1214: UNAME_r (11.0-CURRENT) and OSVERSION (1001000) do not agree on major version number. Same forced error can be seen on current lines 1197 1199. After I patched out the failing bsd.port.mk error I could continue my test of the port see the port build with 10 src ports on an 11 kernel. Patching bsd.port.mk is not the way to go, set the following environment vars before starting a build inside the jail - UNAME_r=10.1-RELEASE-p10 - UNAME_v=FreeBSD 10.1-RELEASE-p10 - OSVERSION=1001000 For example in the login.conf of the jail default:\ :setenv=UNAME_r=10.1-RELEASE-p10,UNAME_v=FreeBSD 10.1-RELEASE-p10,OSVERSION=1001000:\ ... -- olli ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
bsd.port.mk reduce error to warning for UNAME_r OSVERSION mismatch
bsd.port.mk test below is too agressive, let's have it just Warn, not Fail. Also prefix text Error: or Warning: make it obvious which is happening. It seems likely people may have different opinions if it should just Warn or Error, so kets add an environent switch to stear that decision. Which way the default setting of switch should be, I won't suggest (in hope of enhancing chance of agreement to add the switch :-) Whoever adds the switch could decide ? Background: current fails to make my /usr/ports/graphics/libspiro I contacted cc'd MAINTAINER= who wrote me my poudriere is running on 10 I dont run poudriere, but have a native 10 partition so simply did a chroot ... I ran: cd /s2; head -1 /etc/motd # FreeBSD 10.1-RELEASE (LAPR.small) #0: Sat Feb 28 16:29:20 CET 2015 cd /usr/ports/graphics/libspiro make clean make: /usr/ports/Mk/bsd.port.mk line 1214: UNAME_r (11.0-CURRENT) and OSVERSION (1001000) do not agree on major version number. make make: /usr/ports/Mk/bsd.port.mk line 1214: UNAME_r (11.0-CURRENT) and OSVERSION (1001000) do not agree on major version number. Same forced error can be seen on current lines 1197 1199. After I patched out the failing bsd.port.mk error I could continue my test of the port see the port build with 10 src ports on an 11 kernel. Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Indent previous with . Reply Below as a play script. Send plain text, Not quoted-printable, HTML, or base64. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[Bug 129741] [patch] bsd.port.mk: support systems that have been built WITHOUT_INFO=yes (no makeinfo install-info)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=129741 Baptiste Daroussin b...@freebsd.org changed: What|Removed |Added Attachment #92158|0 |1 is patch|| Attachment #92158|text/plain; |text/plain mime type|charset=US-ASCII| -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[Bug 129741] [patch] bsd.port.mk: support systems that have been built WITHOUT_INFO=yes (no makeinfo install-info)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=129741 Baptiste Daroussin b...@freebsd.org changed: What|Removed |Added Attachment #92156|0 |1 is patch|| -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[Bug 129741] [patch] bsd.port.mk: support systems that have been built WITHOUT_INFO=yes (no makeinfo install-info)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=129741 Baptiste Daroussin b...@freebsd.org changed: What|Removed |Added Status|Open|Issue Resolved Resolution|--- |FIXED --- Comment #10 from Baptiste Daroussin b...@freebsd.org --- Imho the best approach here is to make the ports depend on print/texinfo if base was built WITHOUT_INFO -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[Bug 129741] [patch] bsd.port.mk: support systems that have been built WITHOUT_INFO=yes (no makeinfo install-info)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=129741 --- Comment #11 from commit-h...@freebsd.org --- A commit references this bug: Author: bapt Date: Sun Jun 15 21:38:30 UTC 2014 New revision: 357930 URL: http://svnweb.freebsd.org/changeset/ports/357930 Log: Make ports providing info files depending on print/textinfo if base has been built WITHOUT_INFO PR:129741 Changes: head/Mk/bsd.port.mk -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[Bug 129741] [patch] bsd.port.mk: support systems that have been built WITHOUT_INFO=yes (no makeinfo install-info)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=129741 Baptiste Daroussin b...@freebsd.org changed: What|Removed |Added Status|In Discussion |Needs Help CC||b...@freebsd.org --- Comment #9 from Baptiste Daroussin b...@freebsd.org --- this is still needed, I to think having a USES=info might be a good idea -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[Bug 129741] [patch] bsd.port.mk: support systems that have been built WITHOUT_INFO=yes (no makeinfo install-info)
http://bugs.freebsd.org/bugzilla/show_bug.cgi?id=129741 Mark Linimon lini...@freebsd.org changed: What|Removed |Added Component|Individual Port(s) |Infrastructure --- Comment #8 from Mark Linimon lini...@freebsd.org --- Infrastructure PR. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
bsd.port.mk
Hi! A few minutes ago I did run portsnap fetch update and was okay. After portmaster -aD I got: === Gathering distinfo list for installed ports === Starting check of installed ports for available updates make: /usr/ports/Mk/bsd.port.mk line 1540: Cannot open /usr/ports/Mk/Uses/bzip2.mk make: Fatal errors encountered -- cannot continue Thanks. -- ajtiM http://www.redbubble.com/people/lumiwa ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: bsd.port.mk
On Mon, May 26, 2014 at 08:42:31AM -0400, Ajtim wrote: Hi! A few minutes ago I did run portsnap fetch update and was okay. After portmaster -aD I got: === Gathering distinfo list for installed ports === Starting check of installed ports for available updates make: /usr/ports/Mk/bsd.port.mk line 1540: Cannot open /usr/ports/Mk/Uses/bzip2.mk make: Fatal errors encountered -- cannot continue Thanks. Something went wrong on your side, /usr/ports/Mk/Uses/bzip2.mk this file exists for a while now. regards, Bapt pgpTbfsYT3LeL.pgp Description: PGP signature
Re: bsd.port.mk
On ma, 2014-05-26 at 14:45 +0200, Baptiste Daroussin wrote: On Mon, May 26, 2014 at 08:42:31AM -0400, Ajtim wrote: Hi! A few minutes ago I did run portsnap fetch update and was okay. After portmaster -aD I got: === Gathering distinfo list for installed ports === Starting check of installed ports for available updates make: /usr/ports/Mk/bsd.port.mk line 1540: Cannot open /usr/ports/Mk/Uses/bzip2.mk make: Fatal errors encountered -- cannot continue Thanks. Something went wrong on your side, /usr/ports/Mk/Uses/bzip2.mk this file exists for a while now. regards, Bapt I think miwi@ just fixed this. USES=bzip2 instead of USES=tar:bzip2. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: bsd.port.mk
Am 26.05.2014 14:45 (UTC+1) schrieb Baptiste Daroussin: On Mon, May 26, 2014 at 08:42:31AM -0400, Ajtim wrote: Hi! A few minutes ago I did run portsnap fetch update and was okay. After portmaster -aD I got: === Gathering distinfo list for installed ports === Starting check of installed ports for available updates make: /usr/ports/Mk/bsd.port.mk line 1540: Cannot open /usr/ports/Mk/Uses/bzip2.mk make: Fatal errors encountered -- cannot continue Thanks. Something went wrong on your side, /usr/ports/Mk/Uses/bzip2.mk this file exists for a while now. I am sorry, but I also do not have this file in all of my boxes running HEAD with recent ports (r355321). Greetings, Rainer regards, Bapt ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: bsd.port.mk
On Mon, May 26, 2014 at 02:57:19PM +0200, Rainer Hurling wrote: Am 26.05.2014 14:45 (UTC+1) schrieb Baptiste Daroussin: On Mon, May 26, 2014 at 08:42:31AM -0400, Ajtim wrote: Hi! A few minutes ago I did run portsnap fetch update and was okay. After portmaster -aD I got: === Gathering distinfo list for installed ports === Starting check of installed ports for available updates make: /usr/ports/Mk/bsd.port.mk line 1540: Cannot open /usr/ports/Mk/Uses/bzip2.mk make: Fatal errors encountered -- cannot continue Thanks. Something went wrong on your side, /usr/ports/Mk/Uses/bzip2.mk this file exists for a while now. I am sorry, but I also do not have this file in all of my boxes running HEAD with recent ports (r355321). Greetings, Rainer Sorry I misread someone messed up and if you be tar.mk :) so someone might have committed USES=bzip2 instead of USES=tar:bzip2 regards, Bapt pgpp6AEg7KhWq.pgp Description: PGP signature
ports/Mk/bsd.port.mk Verifying install for - to call REinstall
Hi po...@freebsd.org
While making my standard collection of ports on 8.4-RELEASE
(yes I also have 9.2 10 on other partitions on some but not all hosts)
I saw numerous examples similar to:
cd /usr/ports/multimedia/ogmrip ; make
=== ogmrip-1.0.0 depends on executable: mencoder - found
=== ogmrip-1.0.0 depends on executable: mplayer - found
=== ogmrip-1.0.0 depends on executable: gsed - not found
===Verifying install for gsed in /usr/ports/textproc/gsed
=== Returning to build of ogmrip-1.0.0
... a later fail with eg gsed not found
(why not found I'm not sure, as I started with a new empty /usr/local/
but why is irrelevant, it should recover)
(in this case, a manual make in
/pri/FreeBSD/branches/-current/ports/textproc/gsed
solved it, but that's an exception to the general case,
also irrelevant)
Wouldn't it be better if we had a make reinstall in dependency
(eg textproc/gsed) not just
a make install which presumably just looks at dependency
textproc/gsed/work/.install_done.sed._usr_local
doesnt try to install the binary we already know IS missing.
I'm not clear how to do reinstall instead of install via Mk/ ?
But it's somewhere around here:
vi -c'/^_INSTALL_DEPENDS=' /usr/ports/Mk/bsd.port.mk
Called from ${_INSTALL_DEPENDS} in fragment:
if [ $$notfound != 0 ]; then \
${ECHO_MSG} ===Verifying $$target for $$prog in
$$dir; \
if [ ! -d $$dir ]; then \
${ECHO_MSG} = No directory for $$prog.
Skipping..; \
else \
${_INSTALL_DEPENDS} \
fi; \
Cheers,
Julian
--
Julian Stacey, BSD Linux Unix'78 C Sys Eng Consultant Munich http://berklix.com
Interleave reply paragraphs like a play script.
http://berklix.eu/pirates/ - A daft name but good ideas, read before voting.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
RFC: bsd.port.mk needs some changes around plist processing
Greetings, we've recently seen that the docbook ports were broken, and while the ports now build, they still cause leftover directories; Details in PR 186882: http://www.freebsd.org/cgi/query-pr.cgi?pr=186882 Sample log from Tinderbox: http://people.freebsd.org/~mandree/docbook-xml450-4.5_3.log Background: the ports - by way of textproc/docbook/bsd.docbook.mk - add port documentation to TMPPLIST, and adds a few @dirrm-like instances to TMPPLIST, too. In practice, this does not work due to several ordering issues in bsd.port.mk: 1. TMPPLIST stuff added from do-install is *not* subject to the @dirrmtry and related processing that generate-plist does. Stuff added from pre-install would be, however. This processing, for instance, changes @dirrmtry D to @unexec rmdir D || : for pre-pkgNG hosts. The cause is that generate-plist runs between pre-install and do-install. 2. post-stage stuff is currently executed *after* stage-qa, so stage-qa does not check the final state of the stagedir, but an intermediate state. In particular, if post-stage were used to fix TMPPLIST, stage-qa would already have complained about plist problems that are no longer present when the overall stage target is reached. Consequence: The port in fact cannot add @dirrm to TMPPLIST without reimplementing several bsd.port.mk targets or without causing bogus warnings. It is certainly possible to work around all this with a POST-DEINSTALL target, but I propose that we fix the framework instead. I propose that bsd.port.mk: F1. moves stage-qa until after post-stage so that stage-qa validates the final STAGEDIR contents. F2. adds a late-plist target so that a port can add clean-up material to TMPPLIST *after* everything that is derived from variables such as PORTDOCS, PORTEXAMPLES. This should be really late in the process, possibly only before the fix-plist-sequence. F3. the postprocessing with REINPLACE_CMD that, for instance, translates @dirrmtry, be (a) split out from generate-plist and (b) run *after* late-plist, so that ports can just start using the pkgNG directives (such as @dirrmtry) that pkg_create does not understand. Possibly before the fix-plist-sequence target. F3 is particularly important so that we don't add backwards kludges (as mat@ had to do for the docbook/bsd.docbook.mk) that we will have to clean up later when pkgNG is the only supported tool. Now, I've tried to figure out how the whole bsd.port.mk rigging works, took a few stabs at it, and have found myself lost, so I cannot propose code or provide patches; someone who is more acquainted with the bsd.port.mk sequencing and target innards should do that. I'll be happy to help with testing, and fixing the docbook ports, on pkgNG as well as on pkg_create/pkg_add systems. Any takers? Cheers, Matthias ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: bsd.port.mk FETCH_ARGS defaults, why -A ?
On 12/28/2013 02:27, Baptiste Daroussin wrote: On Sat, Dec 28, 2013 at 02:05:31AM +0100, Michael Gmelin wrote: On Sat, 28 Dec 2013 01:56:22 +0100 Baptiste Daroussin b...@freebsd.org wrote: On Sat, Dec 28, 2013 at 01:52:45AM +0100, John Marino wrote: On 12/28/2013 01:49, Dimitry Andric wrote: On 28 Dec 2013, at 01:12, John Marino freebsd.cont...@marino.st wrote: For months I've been getting a lot of fetch failures in ports that I couldn't reproduce outside of them. It appears it is caused by the default -A passed to fetch. For example, /usr/ports/emulators/javatari will fail with make fetch but it will succeed with with make fetch FETCH_ARGS=-Fpr I'd like to understand why -A is the default. Clearly many distfiles could be retrieved that aren't, so I'd like to know what -A is saving us from, and why that would be worse than the current situation? Crappy download sites that redirect you to ad pages, malware domains, or worse? And? The checksum won't match, and the next site in the MASTER_SITES list will be checked, right? What is the downside of this redirect? Keep in mind that the site was once approved by the port maintainer, it's not some random URL stuck in a wiki. That's to avoid infinite loop on redirection bapt libfetch allows a maximum um five redirects and the -A flag is implemented in terms of limiting this to one: http.c: ... /* Maximum number of redirects to follow */ #define MAX_REDIRECT 5 ... /* if the A flag is set, we only get one try */ n = noredirect ? 1 : MAX_REDIRECT; i = 0; ... Great so that s not an argument anymore, it was the argument I was told 2 years ago when I proposed to remove the -A Does that mean that -A option will be removed in the near future? As Doug indicated, there doesn't seem to be any current reason to have it and sufficient reason not to have it. John ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
bsd.port.mk FETCH_ARGS defaults, why -A ?
For months I've been getting a lot of fetch failures in ports that I couldn't reproduce outside of them. It appears it is caused by the default -A passed to fetch. For example, /usr/ports/emulators/javatari will fail with make fetch but it will succeed with with make fetch FETCH_ARGS=-Fpr I'd like to understand why -A is the default. Clearly many distfiles could be retrieved that aren't, so I'd like to know what -A is saving us from, and why that would be worse than the current situation? Thanks, John ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: bsd.port.mk FETCH_ARGS defaults, why -A ?
On 28 Dec 2013, at 01:12, John Marino freebsd.cont...@marino.st wrote: For months I've been getting a lot of fetch failures in ports that I couldn't reproduce outside of them. It appears it is caused by the default -A passed to fetch. For example, /usr/ports/emulators/javatari will fail with make fetch but it will succeed with with make fetch FETCH_ARGS=-Fpr I'd like to understand why -A is the default. Clearly many distfiles could be retrieved that aren't, so I'd like to know what -A is saving us from, and why that would be worse than the current situation? Crappy download sites that redirect you to ad pages, malware domains, or worse? -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: bsd.port.mk FETCH_ARGS defaults, why -A ?
On 12/28/2013 01:49, Dimitry Andric wrote: On 28 Dec 2013, at 01:12, John Marino freebsd.cont...@marino.st wrote: For months I've been getting a lot of fetch failures in ports that I couldn't reproduce outside of them. It appears it is caused by the default -A passed to fetch. For example, /usr/ports/emulators/javatari will fail with make fetch but it will succeed with with make fetch FETCH_ARGS=-Fpr I'd like to understand why -A is the default. Clearly many distfiles could be retrieved that aren't, so I'd like to know what -A is saving us from, and why that would be worse than the current situation? Crappy download sites that redirect you to ad pages, malware domains, or worse? And? The checksum won't match, and the next site in the MASTER_SITES list will be checked, right? What is the downside of this redirect? Keep in mind that the site was once approved by the port maintainer, it's not some random URL stuck in a wiki. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: bsd.port.mk FETCH_ARGS defaults, why -A ?
On Sat, Dec 28, 2013 at 01:52:45AM +0100, John Marino wrote: On 12/28/2013 01:49, Dimitry Andric wrote: On 28 Dec 2013, at 01:12, John Marino freebsd.cont...@marino.st wrote: For months I've been getting a lot of fetch failures in ports that I couldn't reproduce outside of them. It appears it is caused by the default -A passed to fetch. For example, /usr/ports/emulators/javatari will fail with make fetch but it will succeed with with make fetch FETCH_ARGS=-Fpr I'd like to understand why -A is the default. Clearly many distfiles could be retrieved that aren't, so I'd like to know what -A is saving us from, and why that would be worse than the current situation? Crappy download sites that redirect you to ad pages, malware domains, or worse? And? The checksum won't match, and the next site in the MASTER_SITES list will be checked, right? What is the downside of this redirect? Keep in mind that the site was once approved by the port maintainer, it's not some random URL stuck in a wiki. That's to avoid infinite loop on redirection bapt pgpHgGgGwaGyv.pgp Description: PGP signature
Re: bsd.port.mk FETCH_ARGS defaults, why -A ?
On 12/28/2013 01:56, Baptiste Daroussin wrote: On Sat, Dec 28, 2013 at 01:52:45AM +0100, John Marino wrote: On 12/28/2013 01:49, Dimitry Andric wrote: On 28 Dec 2013, at 01:12, John Marino freebsd.cont...@marino.st wrote: For months I've been getting a lot of fetch failures in ports that I couldn't reproduce outside of them. It appears it is caused by the default -A passed to fetch. For example, /usr/ports/emulators/javatari will fail with make fetch but it will succeed with with make fetch FETCH_ARGS=-Fpr I'd like to understand why -A is the default. Clearly many distfiles could be retrieved that aren't, so I'd like to know what -A is saving us from, and why that would be worse than the current situation? Crappy download sites that redirect you to ad pages, malware domains, or worse? And? The checksum won't match, and the next site in the MASTER_SITES list will be checked, right? What is the downside of this redirect? Keep in mind that the site was once approved by the port maintainer, it's not some random URL stuck in a wiki. That's to avoid infinite loop on redirection Does not fetch detect too many redirects? What about the emulators/javatari case? Do we really want that to fetch to fail on a valid url? My gut tells me the current fetch setup is not ideal and it can (and should) be improved. Any ideas (assuming -A really has a fatal case, of which I'm not convinced since I can't envision how this infinite redirection would occur) John ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: bsd.port.mk FETCH_ARGS defaults, why -A ?
On Sat, 28 Dec 2013 01:56:22 +0100 Baptiste Daroussin b...@freebsd.org wrote: On Sat, Dec 28, 2013 at 01:52:45AM +0100, John Marino wrote: On 12/28/2013 01:49, Dimitry Andric wrote: On 28 Dec 2013, at 01:12, John Marino freebsd.cont...@marino.st wrote: For months I've been getting a lot of fetch failures in ports that I couldn't reproduce outside of them. It appears it is caused by the default -A passed to fetch. For example, /usr/ports/emulators/javatari will fail with make fetch but it will succeed with with make fetch FETCH_ARGS=-Fpr I'd like to understand why -A is the default. Clearly many distfiles could be retrieved that aren't, so I'd like to know what -A is saving us from, and why that would be worse than the current situation? Crappy download sites that redirect you to ad pages, malware domains, or worse? And? The checksum won't match, and the next site in the MASTER_SITES list will be checked, right? What is the downside of this redirect? Keep in mind that the site was once approved by the port maintainer, it's not some random URL stuck in a wiki. That's to avoid infinite loop on redirection bapt libfetch allows a maximum um five redirects and the -A flag is implemented in terms of limiting this to one: http.c: ... /* Maximum number of redirects to follow */ #define MAX_REDIRECT 5 ... /* if the A flag is set, we only get one try */ n = noredirect ? 1 : MAX_REDIRECT; i = 0; ... -- Michael Gmelin ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: bsd.port.mk FETCH_ARGS defaults, why -A ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/27/2013 04:56 PM, Baptiste Daroussin wrote: | The checksum won't match, and the next site in the MASTER_SITES | list | will be checked, right? What is the downside of this redirect? | Keep in mind that the site was once approved by the port | maintainer, it's not some random URL stuck in a wiki. | | That's to avoid infinite loop on redirection ~ which fetch does not permit in any case. Next? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBCAAGBQJSviR9AAoJEFzGhvEaGryEZboIAKm4M8KR10WwjvhfNjl8QB9x 89q6Ah02qj7lf9xe1oZdxMh2Y1amYvVOORSrJlfMC5zol8Wxs7XZnDNtrLdNopL6 pEV2ywjnCAqqbyZ6Ws18WthTxYalT/k9Ml57QCFdztLbEs6cnuBZrFCX47+c5feo fiQHoYEL2h94kvOqjQTb+2wFCYWyfx/XDjFwM68wW2xoBX4lqvgKAYLb9n4RTe6p Rj34exvZFXPYcFmlKtWnosE2trGNqDerUyp4j2ZmBNOjbWiSyeF1LtSgJvg5Iqwp fRt/rbindOiiXEXBjpaANewO6MScVa/UMxexC9ke7T+hM1H3rRrhYbKYMWLKZNU= =cogg -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: bsd.port.mk FETCH_ARGS defaults, why -A ?
On Sat, Dec 28, 2013 at 02:05:31AM +0100, Michael Gmelin wrote: On Sat, 28 Dec 2013 01:56:22 +0100 Baptiste Daroussin b...@freebsd.org wrote: On Sat, Dec 28, 2013 at 01:52:45AM +0100, John Marino wrote: On 12/28/2013 01:49, Dimitry Andric wrote: On 28 Dec 2013, at 01:12, John Marino freebsd.cont...@marino.st wrote: For months I've been getting a lot of fetch failures in ports that I couldn't reproduce outside of them. It appears it is caused by the default -A passed to fetch. For example, /usr/ports/emulators/javatari will fail with make fetch but it will succeed with with make fetch FETCH_ARGS=-Fpr I'd like to understand why -A is the default. Clearly many distfiles could be retrieved that aren't, so I'd like to know what -A is saving us from, and why that would be worse than the current situation? Crappy download sites that redirect you to ad pages, malware domains, or worse? And? The checksum won't match, and the next site in the MASTER_SITES list will be checked, right? What is the downside of this redirect? Keep in mind that the site was once approved by the port maintainer, it's not some random URL stuck in a wiki. That's to avoid infinite loop on redirection bapt libfetch allows a maximum um five redirects and the -A flag is implemented in terms of limiting this to one: http.c: ... /* Maximum number of redirects to follow */ #define MAX_REDIRECT 5 ... /* if the A flag is set, we only get one try */ n = noredirect ? 1 : MAX_REDIRECT; i = 0; ... Great so that s not an argument anymore, it was the argument I was told 2 years ago when I proposed to remove the -A regards, Bapt pgpJ0dl47XCvk.pgp Description: PGP signature
Re: bsd.port.mk FETCH_ARGS defaults, why -A ?
On Sat, 28 Dec 2013 02:27:11 +0100 Baptiste Daroussin b...@freebsd.org wrote: On Sat, Dec 28, 2013 at 02:05:31AM +0100, Michael Gmelin wrote: On Sat, 28 Dec 2013 01:56:22 +0100 Baptiste Daroussin b...@freebsd.org wrote: On Sat, Dec 28, 2013 at 01:52:45AM +0100, John Marino wrote: On 12/28/2013 01:49, Dimitry Andric wrote: On 28 Dec 2013, at 01:12, John Marino freebsd.cont...@marino.st wrote: For months I've been getting a lot of fetch failures in ports that I couldn't reproduce outside of them. It appears it is caused by the default -A passed to fetch. For example, /usr/ports/emulators/javatari will fail with make fetch but it will succeed with with make fetch FETCH_ARGS=-Fpr I'd like to understand why -A is the default. Clearly many distfiles could be retrieved that aren't, so I'd like to know what -A is saving us from, and why that would be worse than the current situation? Crappy download sites that redirect you to ad pages, malware domains, or worse? And? The checksum won't match, and the next site in the MASTER_SITES list will be checked, right? What is the downside of this redirect? Keep in mind that the site was once approved by the port maintainer, it's not some random URL stuck in a wiki. That's to avoid infinite loop on redirection bapt libfetch allows a maximum um five redirects and the -A flag is implemented in terms of limiting this to one: http.c: ... /* Maximum number of redirects to follow */ #define MAX_REDIRECT 5 ... /* if the A flag is set, we only get one try */ n = noredirect ? 1 : MAX_REDIRECT; i = 0; ... Great so that s not an argument anymore, it was the argument I was told 2 years ago when I proposed to remove the -A regards, Bapt MAX_REDIRECT is 20 now (9.2 / 10) to match the behavior of popular browsers, but other than that it has been unchanged for over a decade (since July 2000 to be precise). -- Michael Gmelin ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Too frequent/poorly tested bsd.port.mk commits, and general uselessness of p5-FreeBSD-Portindex
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/26/2013 03:03 PM, Matthew Seaman wrote: | I've just committed an update to version 3.3 which should address some | of the issues to do with handling options files. Happy to say that the latest version now runs without errors on cache-init and portindex, using db5. Thank you for doing the update. I rather strongly suspect that the fact cache-init runs without errors is that work went into fixing the ports I reported broken, so I would also like to offer thanks to those who did that work. Meanwhile since I made my original post there have been 2 more commits to bsd.port.mk. So my other question remains open ... are willy-nilly commits to that file the new way of the world? If so I can adjust my expectations accordingly. It's likely that cache-init is still faster than 'make index', and on those rare occasions when I catch updates between bsd.port.mk commits cache-init isn't necessary in any case. Doug -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBCAAGBQJSvjPLAAoJEFzGhvEaGryEhkMIAKcsW5K8vXwpKrN7WVTWsWwE QXpY4zPfjGnUY8bJyEvPkioxCO3QIZ6vOMJE7dGX6Gfij3SOpnZ1ty/1mkcQQg5z WJH+L9m9tcNLd3ixd7Rj/ufSeiiPYxxmxJhuuXU9KbubAH8p0T/lqzpG4aet2Dv0 7Y3C/jLPt2pWi33v9ZcOkyuyV/QqrXQdKfz5V+TACwS4g45aVLZNRrEKOoTbVOrh i6lHGHXUq+uZ1RlPXrFUwai6bNeptHn7dfIvFWlI98ej9fOuB2qpSmAALB3wQ36h BBAoItYfQbsKwuZ1LM6NSnP6BIUe6dpwaUCHRpHUPFlb2dClydp5JgfjaGvNtVE= =Z6P1 -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Too frequent/poorly tested bsd.port.mk commits, and general uselessness of p5-FreeBSD-Portindex
On 12/25/2013 11:30 PM, Doug Barton wrote: I have used Matthew's p5-FreeBSD-Portindex for several years. In the past it was a very valuable tool that allowed me to keep an INDEX up to date relative to changes in the ports tree in seconds or minutes, instead of having to do 'make index' every time. However the utility of the solution is dependent on a couple of things, including that bsd.port.mk does not change often. Over the last year or so however the changes to bsd.port.mk, which used to be well tested and batched together, are now coming fast and furious. To make matters worse, the commits are often poorly tested, which leads to several commits related to the same issue in one week. Obviously that's bad for the project generally, but I'm more concerned about whether or not it's going to be useful to stick with p5-FreeBSD-Portindex going forward. Speaking of p5-FreeBSD-Portindex generally, I'm wondering what Matthew's plans are for it? For some time now running 'cache-update -f svn-up,options' has caused errors related to WARNING unknown options file that seem to have to do with the recent changes to the /var/db/ports/category_portname convention. Is an update planned to handle this? Also, I just tried running cache-init with bdb 5, which seemed to succeed, but running portindex generated a lot of suspicious errors. I'll try again after reinstalling bdb 4.7, but I'm wondering if this is a known issue. So it turns out bdb 47 doesn't work any better ... these are relatively new errors: Accumulating dependency information: .[1000].Use of uninitialized value $_ in concatenation (.) or string at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Port.pm line 356. Missing RUN_DEPENDS dependency for print/latex-cjk (latex-cjk-4.8.2_6) -- Can't call method PKGNAME on an undefined value at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Port.pm line 352. at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Tree.pm line 824 Use of uninitialized value $_ in concatenation (.) or string at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Port.pm line 356. Missing BUILD_DEPENDS dependency for print/latex-cjk (latex-cjk-4.8.2_6) -- Can't call method PKGNAME on an undefined value at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Port.pm line 352. at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Tree.pm line 824 Use of uninitialized value $_ in concatenation (.) or string at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Port.pm line 356. Missing RUN_DEPENDS dependency for chinese/font-std (zh-font-std-0.0.20090602) -- Can't call method PKGNAME on an undefined value at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Port.pm line 352. at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Tree.pm line 824 Use of uninitialized value $_ in concatenation (.) or string at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Port.pm line 356. Missing RUN_DEPENDS dependency for chinese/oxim (zh-oxim-1.2.2_4) -- Can't call method PKGNAME on an undefined value at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Port.pm line 352. at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Tree.pm line 824 [2000].[3000].[4000].[5000].[6000].[7000].[8000].[9000].[1].[11000].[12000].[13000].Use of uninitialized value $_ in concatenation (.) or string at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Port.pm line 356. Missing BUILD_DEPENDS dependency for misc/freebsd-doc-sr (sr-freebsd-doc-43251,1) -- Can't call method PKGNAME on an undefined value at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Port.pm line 352. at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Tree.pm line 824 Use of uninitialized value $_ in concatenation (.) or string at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Port.pm line 356. Missing BUILD_DEPENDS dependency for misc/freebsd-doc-ru (ru-freebsd-doc-43251,1) -- Can't call method PKGNAME on an undefined value at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Port.pm line 352. at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Tree.pm line 824 Use of uninitialized value $_ in concatenation (.) or string at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Port.pm line 356. Missing BUILD_DEPENDS dependency for misc/freebsd-doc-ja (ja-freebsd-doc-43251,1) -- Can't call method PKGNAME on an undefined value at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Port.pm line 352. at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Tree.pm line 824 Use of uninitialized value $_ in concatenation (.) or string at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Port.pm line 356. Missing BUILD_DEPENDS dependency for misc/freebsd-doc-el (el-freebsd-doc-43251,1) -- Can't call method PKGNAME on an undefined value at /usr/local/lib
Re: Too frequent/poorly tested bsd.port.mk commits, and general uselessness of p5-FreeBSD-Portindex
On 26/12/2013 07:30, Doug Barton wrote: Speaking of p5-FreeBSD-Portindex generally, I'm wondering what Matthew's plans are for it? For some time now running 'cache-update -f svn-up,options' has caused errors related to WARNING unknown options file that seem to have to do with the recent changes to the /var/db/ports/category_portname convention. Is an update planned to handle this? Also, I just tried running cache-init with bdb 5, which seemed to succeed, but running portindex generated a lot of suspicious errors. I'll try again after reinstalling bdb 4.7, but I'm wondering if this is a known issue. My own usage has switched pretty much entirely to poudriere+pkgng, so I'm not running portindex myself routinely. I'll be happy to fix any problems reported to me, but I need to see reports of problems. Yours is the first mention I've seen of the problems you mention. Now I know about it, a fix will be forthcoming. Obvious in retrospect, but I didn't connect the dots at the time those OPTIONS changes came out. As for db4 vs db5 vs db6 -- portindex doesn't use the extended capabilities of db, just an on-disk key-value store. That should just work with any version of db. Upgrading from db4 to db5 almost certainly won't work: you should cache-init again. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: Too frequent/poorly tested bsd.port.mk commits, and general uselessness of p5-FreeBSD-Portindex
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/26/2013 12:54 AM, Matthew Seaman wrote: | I'll be happy to fix any problems reported to me, but I need to see | reports of problems. Yours is the first mention I've seen of the | problems you mention. Now I know about it, a fix will be forthcoming. | Obvious in retrospect, but I didn't connect the dots at the time those | OPTIONS changes came out. Yes, I've been slack in reporting it. I have mostly just been fixing them by hand, but since I was whining about stuff anyway, I thought I'd mention it. :) FWIW, I have a bunch of old-style db/ports directories still in place from ports I installed before the style switch and haven't updated yet. So p5-FreeBSD-Portindex should probably handle both styles. | As for db4 vs db5 vs db6 -- portindex doesn't use the extended | capabilities of db, just an on-disk key-value store. That should just | work with any version of db. Upgrading from db4 to db5 almost | certainly won't work: you should cache-init again. Yes, I did cache-init after each change of bdb version. I sent a followup post with a bunch of errors from portindex, but I think they are related to underlying ports problems as they happened with db47 as well as db5. The resultant INDEX seems to work Ok in spite of those errors, but I haven't pushed it very hard yet. Thanks for the response. :) Doug -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBCAAGBQJSu/DiAAoJEFzGhvEaGryEN1sH/2KMCl3oaW76XPVsAD5HPjNW SV3rY9cvPDacxn3a1HGJaz83AcxZ24ENoFJX8IztyGlxjYBFk8tGXe0ho04V2NOf KrfNQEZEI4gtT++tj9z3cfHfwBTJQVjn8vl7x6b+AJxL6vUpV1YrArdSxrLkxbjS nj+b8Mpb7oT4SlwtNNhtR+9AOxyFqJiPgbgsTXpcTMXFpKNGtk/srsdcw+RvtdpY brd2nI4EOnjpqxWIO8Ivi9tZn+R9nTi9P5nS3NR9sFkfPDFhR9tCMhsu9rLoI4sA scxaIBcS/3HKwhk3x0VYqFUrWGlD7g5KXjjyozy1OMMttabV2XpRgM+JewbuhJE= =C0iT -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Too frequent/poorly tested bsd.port.mk commits, and general uselessness of p5-FreeBSD-Portindex
On 26/12/2013 08:34, Doug Barton wrote: On 12/25/2013 11:30 PM, Doug Barton wrote: I have used Matthew's p5-FreeBSD-Portindex for several years. In the past it was a very valuable tool that allowed me to keep an INDEX up to date relative to changes in the ports tree in seconds or minutes, instead of having to do 'make index' every time. However the utility of the solution is dependent on a couple of things, including that bsd.port.mk does not change often. Over the last year or so however the changes to bsd.port.mk, which used to be well tested and batched together, are now coming fast and furious. To make matters worse, the commits are often poorly tested, which leads to several commits related to the same issue in one week. Obviously that's bad for the project generally, but I'm more concerned about whether or not it's going to be useful to stick with p5-FreeBSD-Portindex going forward. Speaking of p5-FreeBSD-Portindex generally, I'm wondering what Matthew's plans are for it? For some time now running 'cache-update -f svn-up,options' has caused errors related to WARNING unknown options file that seem to have to do with the recent changes to the /var/db/ports/category_portname convention. Is an update planned to handle this? Also, I just tried running cache-init with bdb 5, which seemed to succeed, but running portindex generated a lot of suspicious errors. I'll try again after reinstalling bdb 4.7, but I'm wondering if this is a known issue. So it turns out bdb 47 doesn't work any better ... these are relatively new errors: Accumulating dependency information: .[1000].Use of uninitialized value $_ in concatenation (.) or string at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Port.pm line 356. Missing RUN_DEPENDS dependency for print/latex-cjk (latex-cjk-4.8.2_6) -- Can't call method PKGNAME on an undefined value at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Port.pm line 352. at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Tree.pm line 824 Use of uninitialized value $_ in concatenation (.) or string at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Port.pm line 356. Missing BUILD_DEPENDS dependency for print/latex-cjk (latex-cjk-4.8.2_6) -- Can't call method PKGNAME on an undefined value at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Port.pm line 352. at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Tree.pm line 824 Use of uninitialized value $_ in concatenation (.) or string at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Port.pm line 356. Missing RUN_DEPENDS dependency for chinese/font-std (zh-font-std-0.0.20090602) -- Can't call method PKGNAME on an undefined value at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Port.pm line 352. at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Tree.pm line 824 Use of uninitialized value $_ in concatenation (.) or string at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Port.pm line 356. Missing RUN_DEPENDS dependency for chinese/oxim (zh-oxim-1.2.2_4) -- Can't call method PKGNAME on an undefined value at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Port.pm line 352. at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Tree.pm line 824 [2000].[3000].[4000].[5000].[6000].[7000].[8000].[9000].[1].[11000].[12000].[13000].Use of uninitialized value $_ in concatenation (.) or string at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Port.pm line 356. Missing BUILD_DEPENDS dependency for misc/freebsd-doc-sr (sr-freebsd-doc-43251,1) -- Can't call method PKGNAME on an undefined value at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Port.pm line 352. at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Tree.pm line 824 Use of uninitialized value $_ in concatenation (.) or string at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Port.pm line 356. Missing BUILD_DEPENDS dependency for misc/freebsd-doc-ru (ru-freebsd-doc-43251,1) -- Can't call method PKGNAME on an undefined value at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Port.pm line 352. at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Tree.pm line 824 Use of uninitialized value $_ in concatenation (.) or string at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Port.pm line 356. Missing BUILD_DEPENDS dependency for misc/freebsd-doc-ja (ja-freebsd-doc-43251,1) -- Can't call method PKGNAME on an undefined value at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Port.pm line 352. at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Tree.pm line 824 Use of uninitialized value $_ in concatenation (.) or string at /usr/local/lib/perl5/site_perl/5.14/FreeBSD/Portindex/Port.pm line 356. Missing BUILD_DEPENDS dependency for misc/freebsd-doc-el (el-freebsd
Too frequent/poorly tested bsd.port.mk commits, and general uselessness of p5-FreeBSD-Portindex
I have used Matthew's p5-FreeBSD-Portindex for several years. In the past it was a very valuable tool that allowed me to keep an INDEX up to date relative to changes in the ports tree in seconds or minutes, instead of having to do 'make index' every time. However the utility of the solution is dependent on a couple of things, including that bsd.port.mk does not change often. Over the last year or so however the changes to bsd.port.mk, which used to be well tested and batched together, are now coming fast and furious. To make matters worse, the commits are often poorly tested, which leads to several commits related to the same issue in one week. Obviously that's bad for the project generally, but I'm more concerned about whether or not it's going to be useful to stick with p5-FreeBSD-Portindex going forward. Speaking of p5-FreeBSD-Portindex generally, I'm wondering what Matthew's plans are for it? For some time now running 'cache-update -f svn-up,options' has caused errors related to WARNING unknown options file that seem to have to do with the recent changes to the /var/db/ports/category_portname convention. Is an update planned to handle this? Also, I just tried running cache-init with bdb 5, which seemed to succeed, but running portindex generated a lot of suspicious errors. I'll try again after reinstalling bdb 4.7, but I'm wondering if this is a known issue. Doug ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: someone broke bsd.port.mk ?
On Fri, Jun 08, 2012 at 12:55:09PM -0700, Jakub Lach wrote:
/usr/ports/Mk/bsd.port.mk, line 6097: Malformed conditional
(${_COMPLETE_OPTIONS_LIST:O} != ${_FILE_COMPLETE_OPTIONS_LIST:O})
Fresh portsnap, some there were changes to bsd.port.mk..
Strange this hasn't changed for a while. What command makes it happen?
regards,
Bapt
pgpd8liwMF5n4.pgp
Description: PGP signature
Re: Part of bsd.port.mk broken with pkgng
On Tue, Aug 27, 2013 at 06:08:28AM +0200, Alexander Leidinger wrote: Hi, in bsd.port.mk there is a variable ACTUAL-PACKAGE-DEPENDS. To my understanding it is broken with pkgng. The target where this is used is still used if FORCE_PACKAGE is set. Can someone confirm (I've only read the code)? Previously this target was used to only record the explicit dependencies of a port and not all the recursive dependencies. To my understanding (again, I've only read the code) the EXPLICIT_PACKAGE_DEPENDS feature is broken now at least on systems which don't use pkgng (it seems that one of the changes to support pkgng in bsd.port.mk introduced this regression). I don't know how pkgng handles this part of the package creation. If it has no internal knowledge similar to EXPLICIT_PACKAGE_DEPENDS, this feature is broken with pkgng too. Can someone confirm? If my analysis is correct, does someone know if this is on the TODO list of pkgng? This is specially interesting as the release process of FreeBSD 10 is starting and it seems that the ld of FreeBSD 10 doesn't record recursive lib-dependencies anymore and as such it may be interesting to switch to EXPLICIT_PACKAGE_DEPENDS for 10-onwards. ACTUAL-PACKAGE-DEPENDS from bsD.port.mk isn't used, the one from bsd.pkgng.mk is used instead which is different. yes EXPLICIT_PACKAGE_DEPENDS is not working with pkgng for 2 reasons: - it was unsafe for binary packages (breaking the 1.0 solver sometime) in 1.1 it is safe now but see next point - it is and will be the default behaviour the pkg 1.1.5 which also include the code to automatically add dependency on all libraries it is being linked on. meaning the port framework will only have to add the direct run deps and nothing more. regards, Bapt pgpiDp9iw6aVP.pgp Description: PGP signature
Part of bsd.port.mk broken with pkgng
Hi, in bsd.port.mk there is a variable ACTUAL-PACKAGE-DEPENDS. To my understanding it is broken with pkgng. The target where this is used is still used if FORCE_PACKAGE is set. Can someone confirm (I've only read the code)? Previously this target was used to only record the explicit dependencies of a port and not all the recursive dependencies. To my understanding (again, I've only read the code) the EXPLICIT_PACKAGE_DEPENDS feature is broken now at least on systems which don't use pkgng (it seems that one of the changes to support pkgng in bsd.port.mk introduced this regression). I don't know how pkgng handles this part of the package creation. If it has no internal knowledge similar to EXPLICIT_PACKAGE_DEPENDS, this feature is broken with pkgng too. Can someone confirm? If my analysis is correct, does someone know if this is on the TODO list of pkgng? This is specially interesting as the release process of FreeBSD 10 is starting and it seems that the ld of FreeBSD 10 doesn't record recursive lib-dependencies anymore and as such it may be interesting to switch to EXPLICIT_PACKAGE_DEPENDS for 10-onwards. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: make: /usr/ports/Mk/bsd.port.mk line 1638: warning: Couldn't read shell's output for if /sbin/sysctl -n compat.ia32.maxvmem /dev/null 21; then echo YES; fi
On Fri, Jun 21, 2013 at 04:54:22PM +0200, John Marino wrote: On 6/21/2013 16:42, Anton Shterenlikht wrote: On ia64 r252055 with ports at r321471 make issues lots of warnings like: # make -C /usr/ports/ fetchindex make: /usr/ports/Mk/bsd.port.subdir.mk line 101: warning: Couldn't read shell's output for if /sbin/sysctl -n compat.ia32.maxvmem /dev/null 21; then echo YES; fi make: /usr/ports/Mk/bsd.port.mk line 1638: warning: Couldn't read shell's output for if /sbin/sysctl -n compat.ia32.maxvmem /dev/null 21; then echo YES; fi *and many more idencal ones* That looks like bmake output. There should be an else part of the conditional that returns TRUE or echo. bmake shell commands don't like null output. The bsd.port.subdir.mk needs to be tweaked for bmake. John Fixed as of r321735 and r321739 regards, Bapt pgpOwD5oofXta.pgp Description: PGP signature
make: /usr/ports/Mk/bsd.port.mk line 1638: warning: Couldn't read shell's output for if /sbin/sysctl -n compat.ia32.maxvmem /dev/null 21; then echo YES; fi
On ia64 r252055 with ports at r321471 make issues lots of warnings like: # make -C /usr/ports/ fetchindex make: /usr/ports/Mk/bsd.port.subdir.mk line 101: warning: Couldn't read shell's output for if /sbin/sysctl -n compat.ia32.maxvmem /dev/null 21; then echo YES; fi make: /usr/ports/Mk/bsd.port.mk line 1638: warning: Couldn't read shell's output for if /sbin/sysctl -n compat.ia32.maxvmem /dev/null 21; then echo YES; fi *and many more idencal ones* /usr/ports/INDEX-10.bz2 100% of 1702 kB 458 kBps 00m04s # or /usr/ports/devel/robodoc # make -C /usr/ports/devel/robodoc showconfig make: /usr/ports/Mk/bsd.port.mk line 1638: warning: Couldn't read shell's output for if /sbin/sysctl -n compat.ia32.maxvmem /dev/null 21; then echo YES; fi === The following configuration options are available for robodoc-4.99.41: DOCS=on: Build and/or install documentation EXAMPLES=on: Build and/or install examples === Use 'make config' to modify these settings # I updated OS from r249xxx, where this warning didn't appear. Please advise Thanks Anton ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: make: /usr/ports/Mk/bsd.port.mk line 1638: warning: Couldn't read shell's output for if /sbin/sysctl -n compat.ia32.maxvmem /dev/null 21; then echo YES; fi
On 6/21/2013 16:42, Anton Shterenlikht wrote: On ia64 r252055 with ports at r321471 make issues lots of warnings like: # make -C /usr/ports/ fetchindex make: /usr/ports/Mk/bsd.port.subdir.mk line 101: warning: Couldn't read shell's output for if /sbin/sysctl -n compat.ia32.maxvmem /dev/null 21; then echo YES; fi make: /usr/ports/Mk/bsd.port.mk line 1638: warning: Couldn't read shell's output for if /sbin/sysctl -n compat.ia32.maxvmem /dev/null 21; then echo YES; fi *and many more idencal ones* That looks like bmake output. There should be an else part of the conditional that returns TRUE or echo. bmake shell commands don't like null output. The bsd.port.subdir.mk needs to be tweaked for bmake. John ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
WITH_BMAKE: make: /usr/ports/Mk/bsd.port.mk line 5137: warning: using previous script for -depends defined here
Well, I'm brave and switched several beta switches on my FreeBSD 10.0-CUR systems on and I realize, that I receive a lot of make: /usr/ports/Mk/bsd.port.mk line 5137: warning: using previous script for -depends defined here make: /usr/ports/Mk/bsd.port.mk line 5140: warning: duplicate script for target -depends ignored messages when doing updates with portmaster or installing ports. I think this is BETA-normal, but a re there serious implications apart from some performance issues at the moment using bmake as the replacement for the oldish make in FreeBSD? I'm just curious, so feel free to answer if you like. Oliver signature.asc Description: OpenPGP digital signature
Re: WITH_BMAKE: make: /usr/ports/Mk/bsd.port.mk line 5137: warning: using previous script for -depends defined here
Using bmake requires several edits to bsd.port.mk. DragonFly's DPorts (based on ports) uses BMake and we had to edit several lines. https://github.com/jrmarino/DeltaPorts/blob/master/special/Mk/diffs/bsd.port.mk.diff See line 654. It's caused by the :L modifier. It's one of many issues with bmake and bsd.*.mk. You can't fix them until all supported versions of FreeBSD understand these modifiers (legacy make understands :tl, etc., I mean) John On 2/20/2013 11:20, O. Hartmann wrote: Well, I'm brave and switched several beta switches on my FreeBSD 10.0-CUR systems on and I realize, that I receive a lot of make: /usr/ports/Mk/bsd.port.mk line 5137: warning: using previous script for -depends defined here make: /usr/ports/Mk/bsd.port.mk line 5140: warning: duplicate script for target -depends ignored messages when doing updates with portmaster or installing ports. I think this is BETA-normal, but a re there serious implications apart from some performance issues at the moment using bmake as the replacement for the oldish make in FreeBSD? I'm just curious, so feel free to answer if you like. Oliver ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: WITH_BMAKE: make: /usr/ports/Mk/bsd.port.mk line 5137: warning: using previous script for -depends defined here
Simon Gerraty has cleverly written some sed magic that makes the ports tree work with bmake. Hopefully it'll be ready at some point, but major testing will be required, since the ports tree has other weird behaviours of pmake that it relies on. I'm sure he'll announce when it's ready and we can get testing, but for the meantime I honestly wouldn't try it unless you enjoy debugging very weird errors! Chris On 20 Feb 2013 10:50, John Marino freebs...@marino.st wrote: Using bmake requires several edits to bsd.port.mk. DragonFly's DPorts (based on ports) uses BMake and we had to edit several lines. https://github.com/jrmarino/**DeltaPorts/blob/master/** special/Mk/diffs/bsd.port.mk.**diffhttps://github.com/jrmarino/DeltaPorts/blob/master/special/Mk/diffs/bsd.port.mk.diff See line 654. It's caused by the :L modifier. It's one of many issues with bmake and bsd.*.mk. You can't fix them until all supported versions of FreeBSD understand these modifiers (legacy make understands :tl, etc., I mean) John On 2/20/2013 11:20, O. Hartmann wrote: Well, I'm brave and switched several beta switches on my FreeBSD 10.0-CUR systems on and I realize, that I receive a lot of make: /usr/ports/Mk/bsd.port.mk line 5137: warning: using previous script for -depends defined here make: /usr/ports/Mk/bsd.port.mk line 5140: warning: duplicate script for target -depends ignored messages when doing updates with portmaster or installing ports. I think this is BETA-normal, but a re there serious implications apart from some performance issues at the moment using bmake as the replacement for the oldish make in FreeBSD? I'm just curious, so feel free to answer if you like. Oliver __**_ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-portshttp://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscribe@**freebsd.orgfreebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: WITH_BMAKE: make: /usr/ports/Mk/bsd.port.mk line 5137: warning: using previous script for -depends defined here
On 2/20/2013 12:46, Chris Rees wrote: Simon Gerraty has cleverly written some sed magic that makes the ports tree work with bmake. Hopefully it'll be ready at some point, but major testing will be required, since the ports tree has other weird behaviours of pmake that it relies on. I'm sure he'll announce when it's ready and we can get testing, but for the meantime I honestly wouldn't try it unless you enjoy debugging very weird errors! In the meantime you should keep me involved because we've hit bmake-involved errors that I am quite sure sed won't address. Sure, you'll get most of them (we basically did this too, translating the problem modifiers during the copy from FreeBSD). We still had a few problems. DPorts has the solutions in the repository. John ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [RFC] bsd.port.mk: Record OPTIONS into /var/db/pkg on install
On 08/03/2012 17:49, Bryan Drewery wrote: Hi, While developing on ports-mgmt/poudriere I've added support to automatically rebuild packages if the selected options in /var/db/ports, or make.conf change. This so far has worked well with pkgng as it records the OPTIONS selected into the package already. By suggestion of bapt, 'pretty-print-config' is used to compare the packaged OPTIONS to the selected OPTIONS. This has worked great for pkgng. Just today I added support [1] to poudriere for pkg_create(1) packages by storing the 'pretty-print-config' into the /var/db/pkg/PKGNAME/+CONTENTS as a comment: @comment OPTIONS:`make pretty-print-config` I'd like to add it to 'fake-pkg' so that the @comment is saved on every port/package creation. This may potentially benefit portmaster and portupgrade as well. [1] http://fossil.etoilebsd.net/poudriere/ci/98426527c8?sbs=0 Comparison of the package +CONTENTS after patch: diff -ur /tmp/zsh-5.0.0.orig/+CONTENTS /var/db/pkg/zsh-5.0.0/+CONTENTS --- /tmp/zsh-5.0.0.orig/+CONTENTS 2012-08-04 02:31:51.0 +0200 +++ /var/db/pkg/zsh-5.0.0/+CONTENTS 2012-08-04 02:33:26.0 +0200 @@ -639,7 +639,7 @@ share/zsh/5.0.0/functions/Completion/Solaris/_zones @comment MD5:858863d60ce982e149dbe3f2adb679c3 share/zsh/5.0.0/functions/Completion/Unix.zwc -@comment MD5:13a3ee08695e76219a326f722d7006c7 +@comment MD5:8219096a131f65761e23864a62088298 share/zsh/5.0.0/functions/Completion/Unix/_a2ps @comment MD5:e2d2d6b9f68fd43ce63040fc680ef9d6 share/zsh/5.0.0/functions/Completion/Unix/_adb @@ -2013,6 +2013,7 @@ @dirrm share/zsh/5.0.0/scripts @dirrm share/zsh/5.0.0 @unexec rmdir %D/share/zsh 2/dev/null || true +@comment OPTIONS:-DEBUG +DOCS -GDBM +MAILDIR -MEM +MULTIBYTE -PCRE +SECURE_FREE -STATIC @cwd @dirrm share/licenses/zsh-5.0.0 @unexec rmdir %D/share/licenses 2/dev/null || true I think this is a fantastic idea, as it would more fully answer the question of how was this package built? I would also like to see us embed the distfile information, either in +CONTENTS or in its own file. This information is very useful for tools like portmaster to better handle automated distfile cleanup. hth, Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [RFC] bsd.port.mk: Record OPTIONS into /var/db/pkg on install
On 8/6/2012 3:00 AM, Doug Barton wrote: I would also like to see us embed the distfile information, either in +CONTENTS or in its own file. This information is very useful for tools like portmaster to better handle automated distfile cleanup. hth, I like that idea. My only feedback is to make the auto-delete on deinstall be optional in bsd.port.mk. They may turnaround and reinstall it right away and not want to waste the bandwidth again. Makes sense for port building tools to wipe the old files on upgrade! -- Regards, Bryan Drewery bdrewery@freenode/EFNet ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [RFC] bsd.port.mk: Record OPTIONS into /var/db/pkg on install
On 08/06/2012 06:34 AM, Bryan Drewery wrote: On 8/6/2012 3:00 AM, Doug Barton wrote: I would also like to see us embed the distfile information, either in +CONTENTS or in its own file. This information is very useful for tools like portmaster to better handle automated distfile cleanup. hth, I like that idea. My only feedback is to make the auto-delete on deinstall be optional in bsd.port.mk. They may turnaround and reinstall it right away and not want to waste the bandwidth again. Makes sense for port building tools to wipe the old files on upgrade! Sorry I wasn't clear, I use the information on the old package to delete the old distfiles, after first comparing to the list of distfiles used by other ports to make sure that it isn't in use elsewhere (such as QT). In portmaster un-installing the port is a different option from upgrading, and has a component of deleting the current distfiles if the user chooses it. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [RFC] bsd.port.mk: Record OPTIONS into /var/db/pkg on install
On 8/6/2012 9:38 AM, Doug Barton wrote: On 08/06/2012 06:34 AM, Bryan Drewery wrote: On 8/6/2012 3:00 AM, Doug Barton wrote: I would also like to see us embed the distfile information, either in +CONTENTS or in its own file. This information is very useful for tools like portmaster to better handle automated distfile cleanup. hth, I like that idea. My only feedback is to make the auto-delete on deinstall be optional in bsd.port.mk. They may turnaround and reinstall it right away and not want to waste the bandwidth again. Makes sense for port building tools to wipe the old files on upgrade! Sorry I wasn't clear, I use the information on the old package to delete the old distfiles, after first comparing to the list of distfiles used by other ports to make sure that it isn't in use elsewhere (such as QT). Ah I see my confusion now. http://www.freebsd.org/cgi/query-pr.cgi?pr=106483 I saw the $RM lines in deinstall and didn't look close enough. They are just removing the distfile list, not the actual files. Regards, Bryan ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [CFT] [bsd.port.mk] ports ccache build support
On Sat, 4 Aug 2012 17:38:44 -0700 Eitan Adler wrote: On 4 August 2012 15:21, RW rwmailli...@googlemail.com wrote: On Sat, 04 Aug 2012 09:42:39 -0500 Bryan Drewery wrote: Having a default ccache directory in the makefile that's different from the default documented in the ccache man page seems needlessly confusing to me. +1 for /var/cache And since large root file-systems seem to be increasingly popular, /root/.ccache may seem reasonable, and people may run cache -M on that. remember that its possible to build as a non-root user, but install as root, or similar. Using $HOME for any aspect of the build isn't a good idea. Why isn't it? In that scenario /var/cache wouldn't be writable. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [CFT] [bsd.port.mk] ports ccache build support
On 5 August 2012 04:15, RW rwmailli...@googlemail.com wrote: On Sat, 4 Aug 2012 17:38:44 -0700 Eitan Adler wrote: Why isn't it? In that scenario /var/cache wouldn't be writable. IMHO the directories used by the ports system should be predictable and static. Which user you happen to be shouldn't affect that choice. -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [CFT] [bsd.port.mk] ports ccache build support
On Sun, Aug 5, 2012 at 7:18 PM, Eitan Adler li...@eitanadler.com wrote: On 5 August 2012 04:15, RW rwmailli...@googlemail.com wrote: On Sat, 4 Aug 2012 17:38:44 -0700 Eitan Adler wrote: Why isn't it? In that scenario /var/cache wouldn't be writable. IMHO the directories used by the ports system should be predictable and static. Which user you happen to be shouldn't affect that choice. Regardless of what the shared directory is the problem of setting permissions so that multiple users can share the ccache directory is something that the ports system shouldn't try to solve. Leave it to the admin of the system. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [CFT] [bsd.port.mk] ports ccache build support
On Sun, Aug 5, 2012 at 11:40 AM, Kimmo Paasiala kpaas...@gmail.com wrote: On Sun, Aug 5, 2012 at 7:18 PM, Eitan Adler li...@eitanadler.com wrote: On 5 August 2012 04:15, RW rwmailli...@googlemail.com wrote: On Sat, 4 Aug 2012 17:38:44 -0700 Eitan Adler wrote: Why isn't it? In that scenario /var/cache wouldn't be writable. IMHO the directories used by the ports system should be predictable and static. Which user you happen to be shouldn't affect that choice. Regardless of what the shared directory is the problem of setting permissions so that multiple users can share the ccache directory is something that the ports system shouldn't try to solve. Leave it to the admin of the system. I agree. The document in the ccache port is pretty clear and it's not hard to follow. Cheers, Mezz -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [CFT] [bsd.port.mk] ports ccache build support
Bryan Drewery bdrew...@freebsd.org writes:
The cache directory CCACHE_DIR defaults to /usr/obj/ccache
Why not ${.OBJDIR}/ccache? This avoids one big port taking away all
allocated space for itself unless --max-size is raised.
Also, I have /usr/obj - /nonexistent symlink. Anything that doesn't
respect MAKEOBJDIRPREFIX is bogus.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [CFT] [bsd.port.mk] ports ccache build support
On 08/05/2012 19:47, Jan Beich wrote:
Bryan Drewery bdrew...@freebsd.org writes:
The cache directory CCACHE_DIR defaults to /usr/obj/ccache
Why not ${.OBJDIR}/ccache? This avoids one big port taking away all
allocated space for itself unless --max-size is raised.
Also, I have /usr/obj - /nonexistent symlink. Anything that doesn't
respect MAKEOBJDIRPREFIX is bogus.
Bryan's proposal is for ports. /usr/obj is for things in the base.
The equivalent to MAKEOBJDIRPREFIX in ports is WRKDIRPREFIX, but IMO the
ccache cache should be independent of either.
Personally I don't see why we would want to change the defaults here at
all. There are 2 possibilities ... either the user has customized the
location, in which case we shouldn't mess with it. Or, they haven't, in
which case if the regular default for the port is good, it should be
used. If it isn't, it should be fixed for all users.
Doug
--
I am only one, but I am one. I cannot do everything, but I can do
something. And I will not let what I cannot do interfere with what
I can do.
-- Edward Everett Hale, (1822 - 1909)
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [CFT] [bsd.port.mk] ports ccache build support
On 8/4/2012 7:38 PM, Eitan Adler wrote: On 4 August 2012 15:21, RW rwmailli...@googlemail.com wrote: On Sat, 04 Aug 2012 09:42:39 -0500 Bryan Drewery wrote: Having a default ccache directory in the makefile that's different from the default documented in the ccache man page seems needlessly confusing to me. +1 for /var/cache And since large root file-systems seem to be increasingly popular, /root/.ccache may seem reasonable, and people may run cache -M on that. remember that its possible to build as a non-root user, but install as root, or similar. Using $HOME for any aspect of the build isn't a good idea. I can see both arguments here. non-root building suggests $HOME/.ccache. This has the benefit of having ccache(1) just work when configuring. A downside of possibly duplicating the cache for some users. pkgng is storing cache files in /var/cache/pkg. This is not listed in hier(7) yet, but probably should be added. Given that, /var/cache/ccache makes sense as well. I still am concerned that adding a default 1gb sized cache into /var is not a good idea. Another downside is having to define CCACHE_DIR to run ccache(1) I actually had used /var/cache in my initial patch, but changed to /usr/obj since /var can be so small. On my own systems I have a mess of symlinks to fix my own indecision on the matter. /root/.ccache - /var/cache/ccache - /usr/ccache I'm starting to lean towards sticking to the default of $HOME/.ccache as well as it may be more safe and less confusing to use with ccache(1). The user can always override. -- Regards, Bryan Drewery bdrewery@freenode/EFNet ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [CFT] [bsd.port.mk] ports ccache build support
On Fri, 03 Aug 2012 20:05:54 -0500
Bryan Drewery wrote:
Hi,
ports/169579 is currently tracking this.
This patch adds ccache support to ports (off by default). Other
patches have changed $CC to use ccache, which results in having a
space in $CC. This breaks many ports such as boost and libtool ports.
This patch however utilizes the symlinks in
/usr/local/libexec/ccache/{cc,gcc,etc...} by prefixing that directory
into $PATH in the $MAKE_ENV.
But if you've read the ccache documentation you probably already have
that directory in PATH anyway. Does this patch provide a significant
advantage?
The cache directory CCACHE_DIR defaults to /usr/obj/ccache
...
To use ccache(1) from the command line to configure the size or view
stats: CCACHE_DIR=/usr/obj/ccache ccache -s
Having a default ccache directory in the makefile that's different from
the default documented in the ccache man page seems needlessly
confusing to me.
And see hier(7) and section 25.7.6 of the handbook for
why /usr/obj/ccache is a poor choice.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [CFT] [bsd.port.mk] ports ccache build support
On 8/4/2012 8:16 AM, RW wrote:
On Fri, 03 Aug 2012 20:05:54 -0500
Bryan Drewery wrote:
Hi,
ports/169579 is currently tracking this.
This patch adds ccache support to ports (off by default). Other
patches have changed $CC to use ccache, which results in having a
space in $CC. This breaks many ports such as boost and libtool ports.
This patch however utilizes the symlinks in
/usr/local/libexec/ccache/{cc,gcc,etc...} by prefixing that directory
into $PATH in the $MAKE_ENV.
But if you've read the ccache documentation you probably already have
that directory in PATH anyway. Does this patch provide a significant
advantage?
That requires needless customization. The purpose here is easy, safe and
native support.
The included ccache-howto-freebsd.txt with devel/ccache is quite long
for something that is straight forward.
I've seen many incorrect guides that suggest changing $CC. There's forum
posts and sysutils/bsdadminscripts that do this. This leads to broken
builds and needing to define which ports support ccache via $CC and
which do not.
The cache directory CCACHE_DIR defaults to /usr/obj/ccache
...
To use ccache(1) from the command line to configure the size or view
stats: CCACHE_DIR=/usr/obj/ccache ccache -s
Having a default ccache directory in the makefile that's different from
the default documented in the ccache man page seems needlessly
confusing to me.
The default being $HOME/.ccache makes even less sense for port building.
And see hier(7) and section 25.7.6 of the handbook for
why /usr/obj/ccache is a poor choice.
I think /usr/obj makes sense. There is /var/cache now, but /var is
typically a smaller partition.
Do you have a better suggestion?
--
Regards,
Bryan Drewery
bdrewery@freenode/EFNet
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [CFT] [bsd.port.mk] ports ccache build support
On Sat, Aug 4, 2012 at 5:42 PM, Bryan Drewery bdrew...@freebsd.org wrote:
On 8/4/2012 8:16 AM, RW wrote:
On Fri, 03 Aug 2012 20:05:54 -0500
Bryan Drewery wrote:
Hi,
ports/169579 is currently tracking this.
This patch adds ccache support to ports (off by default). Other
patches have changed $CC to use ccache, which results in having a
space in $CC. This breaks many ports such as boost and libtool ports.
This patch however utilizes the symlinks in
/usr/local/libexec/ccache/{cc,gcc,etc...} by prefixing that directory
into $PATH in the $MAKE_ENV.
But if you've read the ccache documentation you probably already have
that directory in PATH anyway. Does this patch provide a significant
advantage?
That requires needless customization. The purpose here is easy, safe and
native support.
The included ccache-howto-freebsd.txt with devel/ccache is quite long
for something that is straight forward.
I've seen many incorrect guides that suggest changing $CC. There's forum
posts and sysutils/bsdadminscripts that do this. This leads to broken
builds and needing to define which ports support ccache via $CC and
which do not.
The cache directory CCACHE_DIR defaults to /usr/obj/ccache
...
To use ccache(1) from the command line to configure the size or view
stats: CCACHE_DIR=/usr/obj/ccache ccache -s
Having a default ccache directory in the makefile that's different from
the default documented in the ccache man page seems needlessly
confusing to me.
The default being $HOME/.ccache makes even less sense for port building.
And see hier(7) and section 25.7.6 of the handbook for
why /usr/obj/ccache is a poor choice.
I think /usr/obj makes sense. There is /var/cache now, but /var is
typically a smaller partition.
Do you have a better suggestion?
Based on what I've read on the subject I'd say it's better to leave
/usr/obj to just for stuff from /usr/src. I vote for /var/cache/ccache
as the default ccache directory.
-Kimmo
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [CFT] [bsd.port.mk] ports ccache build support
On 08/04/2012 08:03, Kimmo Paasiala wrote: Based on what I've read on the subject I'd say it's better to leave /usr/obj to just for stuff from /usr/src. Yes please. :) -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [CFT] [bsd.port.mk] ports ccache build support
On 08/03/2012 18:05, Bryan Drewery wrote:
This patch however utilizes the symlinks in
/usr/local/libexec/ccache/{cc,gcc,etc...} by prefixing that directory
into $PATH in the $MAKE_ENV.
FWIW, when I was asked to add ccache support to portmaster this was the
method suggested to me. I added it years ago, and have never had a user
complain that it didn't work.
hth,
Doug
--
I am only one, but I am one. I cannot do everything, but I can do
something. And I will not let what I cannot do interfere with what
I can do.
-- Edward Everett Hale, (1822 - 1909)
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [CFT] [bsd.port.mk] ports ccache build support
On Sat, 04 Aug 2012 09:42:39 -0500 Bryan Drewery wrote: But if you've read the ccache documentation you probably already have that directory in PATH anyway. Does this patch provide a significant advantage? That requires needless customization. The purpose here is easy, safe and native support. The included ccache-howto-freebsd.txt with devel/ccache is quite long for something that is straight forward. I think that's an exaggeration. I'd say it's quite short and most of it is easily skipped over. Having a default ccache directory in the makefile that's different from the default documented in the ccache man page seems needlessly confusing to me. The default being $HOME/.ccache makes even less sense for port building. No, but it has the merit of being documented as being the default in the first place one is likely to look. And since large root file-systems seem to be increasingly popular, /root/.ccache may seem reasonable, and people may run cache -M on that. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [CFT] [bsd.port.mk] ports ccache build support
On 4 August 2012 15:21, RW rwmailli...@googlemail.com wrote: On Sat, 04 Aug 2012 09:42:39 -0500 Bryan Drewery wrote: Having a default ccache directory in the makefile that's different from the default documented in the ccache man page seems needlessly confusing to me. +1 for /var/cache And since large root file-systems seem to be increasingly popular, /root/.ccache may seem reasonable, and people may run cache -M on that. remember that its possible to build as a non-root user, but install as root, or similar. Using $HOME for any aspect of the build isn't a good idea. -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[RFC] bsd.port.mk: Record OPTIONS into /var/db/pkg on install
Hi,
While developing on ports-mgmt/poudriere I've added support to
automatically rebuild packages if the selected options in /var/db/ports,
or make.conf change. This so far has worked well with pkgng as it
records the OPTIONS selected into the package already.
By suggestion of bapt, 'pretty-print-config' is used to compare the
packaged OPTIONS to the selected OPTIONS. This has worked great for pkgng.
Just today I added support [1] to poudriere for pkg_create(1) packages
by storing the 'pretty-print-config' into the
/var/db/pkg/PKGNAME/+CONTENTS as a comment:
@comment OPTIONS:`make pretty-print-config`
I'd like to add it to 'fake-pkg' so that the @comment is saved on every
port/package creation.
This may potentially benefit portmaster and portupgrade as well.
[1] http://fossil.etoilebsd.net/poudriere/ci/98426527c8?sbs=0
Comparison of the package +CONTENTS after patch:
diff -ur /tmp/zsh-5.0.0.orig/+CONTENTS /var/db/pkg/zsh-5.0.0/+CONTENTS
--- /tmp/zsh-5.0.0.orig/+CONTENTS 2012-08-04 02:31:51.0 +0200
+++ /var/db/pkg/zsh-5.0.0/+CONTENTS 2012-08-04 02:33:26.0 +0200
@@ -639,7 +639,7 @@
share/zsh/5.0.0/functions/Completion/Solaris/_zones
@comment MD5:858863d60ce982e149dbe3f2adb679c3
share/zsh/5.0.0/functions/Completion/Unix.zwc
-@comment MD5:13a3ee08695e76219a326f722d7006c7
+@comment MD5:8219096a131f65761e23864a62088298
share/zsh/5.0.0/functions/Completion/Unix/_a2ps
@comment MD5:e2d2d6b9f68fd43ce63040fc680ef9d6
share/zsh/5.0.0/functions/Completion/Unix/_adb
@@ -2013,6 +2013,7 @@
@dirrm share/zsh/5.0.0/scripts
@dirrm share/zsh/5.0.0
@unexec rmdir %D/share/zsh 2/dev/null || true
+@comment OPTIONS:-DEBUG +DOCS -GDBM +MAILDIR -MEM +MULTIBYTE -PCRE
+SECURE_FREE -STATIC
@cwd
@dirrm share/licenses/zsh-5.0.0
@unexec rmdir %D/share/licenses 2/dev/null || true
--
Regards,
Bryan Drewery
bdrewery@freenode/EFNet
--- /usr/ports/Mk/bsd.port.mk.orig 2012-08-04 02:22:29.0 +0200
+++ /usr/ports/Mk/bsd.port.mk 2012-08-04 02:32:20.0 +0200
@@ -5692,6 +5692,7 @@
.endif
.endif
.endif
+ @cd ${.CURDIR} { ${ECHO_CMD} -n @comment OPTIONS:; ${MAKE}
pretty-print-config; } ${TMPPLIST}
.endif
${TMPPLIST}:
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[CFT] [bsd.port.mk] ports ccache build support
Hi,
ports/169579 is currently tracking this.
This patch adds ccache support to ports (off by default). Other patches
have changed $CC to use ccache, which results in having a space in $CC.
This breaks many ports such as boost and libtool ports.
This patch however utilizes the symlinks in
/usr/local/libexec/ccache/{cc,gcc,etc...} by prefixing that directory
into $PATH in the $MAKE_ENV.
Using this method, I have seen 0 failures, compared to the $CC method
which results in many build failures and requiring to define which ports
do not support ccache.
To enable: Define WITH_CCACHE_BUILD=yes in /etc/make.conf
The cache directory CCACHE_DIR defaults to /usr/obj/ccache
Defining NO_CCACHE can disable ccache support in make.conf or in a port.
This is mostly to allow compatibility with current setups utilizing
NO_CCACHE.
If $CC already contains ccache, the support is disabled in case of
custom setup.
Users can override other ccache env variables [1] by using MAKE_ENV+= in
their make.conf. Such as:
MAKE_ENV+= CCACHE_LOGFILE=/var/log/ccache.log
To use ccache(1) from the command line to configure the size or view
stats: CCACHE_DIR=/usr/obj/ccache ccache -s
FWIW, this is also possible to achieve with bsd.local.mk [2], but it
would be much nicer to support without needing to customize your checkout.
[1] https://ccache.samba.org/manual.html#_environment_variables
[2] http://fossil.etoilebsd.net/poudriere/doc/trunk/doc/ccache.wiki
--
Regards,
Bryan Drewery
bdrewery@freenode/EFNet
--- bsd.port.mk.orig2012-08-04 02:57:19.0 +0200
+++ bsd.port.mk 2012-08-04 02:58:43.0 +0200
@@ -934,6 +934,13 @@
#that are explicitly marked MAKE_JOBS_UNSAFE.
User settable.
# MAKE_JOBS_NUMBER
# - Override the number of make jobs to be used.
User settable.
+## cacche
+#
+# WITH_CCACHE_BUILD
+# - Enable CCACHE support (devel/ccache)
+# CCACHE_DIR
+# - Directory to use for ccache objects
+#Default: /usr/obj/ccache
#
# For install:
#
@@ -2217,6 +2224,21 @@
.endif
.endif
+# ccache support
+# Support NO_CCACHE for common setups, require WITH_CCACHE_BUILD, and don't
use if ccache already set in CC
+.if !defined(NO_CCACHE) defined(WITH_CCACHE_BUILD) !${CC:M*ccache*}
+CCACHE_DIR?= /usr/obj/ccache
+
+# Avoid depends loops between pkg and ccache
+. if !${.CURDIR:M*/devel/ccache} !${.CURDIR:M*/ports-mgmt/pkg}
+BUILD_DEPENDS+=${LOCALBASE}/bin/ccache:${PORTSDIR}/devel/ccache
+. endif
+
+# Prepend the ccache dir into the PATH and setup ccache env
+MAKE_ENV+= PATH=${LOCALBASE}/libexec/ccache:${PATH} \
+ CCACHE_DIR=${CCACHE_DIR}
+.endif
+
PTHREAD_CFLAGS?=
PTHREAD_LIBS?= -pthread
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ bsd.port.mk ] improper evaluation of config-recursive target
On 21-6-2012 21:02, Alexander Pronin wrote:
- @for dir in ${.CURDIR} $$(${ALL-DEPENDS-LIST}); do \
- (cd $$dir; ${MAKE} config-conditional); \
+ @for dir in $$(${MAKE} all-depends-list); do \
Almost.
@for dir in $$(${MAKE} run-depends-list build-depends-list|uniq); do \
Observe the difference on something like x11/xorg.
--
Mel
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[ bsd.port.mk ] improper evaluation of config-recursive target
Hello porters,
My name is Alexander Pronin. I am a GSOC intern. My project is
(http://wiki.freebsd.org/SummerOfCode2012/Parallelization_in_the_ports_collection#preview)
It is assumed that if a user calls
%make config-recursive
then options of current port and all it's dependency ports will be processed,
but
If this port(A) enables dependency port(Z) via options then
$$(${ALL-DEPENDS-LIST}) will not include this port(Z), hence options of port(Z)
will not be processed.
If dependency port(B) of port(A) enables another dependency port(X) then
options of this port(X) will not be processed either.
If I am correct with my assumptions, then the following patch fixes this
behaviour:
--- /Users/scher/tmp/config-recursive/bsd.port.mk 2012-06-21
22:53:45.0 +0400
+++ /Users/scher/tmp/config-recursive/bsd.port.mk-fixed 2012-06-21
22:54:35.0 +0400
@@ -6110,8 +6110,8 @@
.if !target(config-recursive)
-config-recursive:
+config-recursive: config-conditional
@${ECHO_MSG} === Setting user-specified options for ${PKGNAME} and
dependencies;
- @for dir in ${.CURDIR} $$(${ALL-DEPENDS-LIST}); do \
- (cd $$dir; ${MAKE} config-conditional); \
+ @for dir in $$(${MAKE} all-depends-list); do \
+ (cd $$dir; ${MAKE} config-recursive); \
done
.endif # config-recursive
---
Best regards,
Alexander Pronin
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ bsd.port.mk ] improper evaluation of config-recursive target
On 6/21/2012 2:02 PM, Alexander Pronin wrote:
Hello porters,
My name is Alexander Pronin. I am a GSOC intern. My project is
(http://wiki.freebsd.org/SummerOfCode2012/Parallelization_in_the_ports_collection#preview)
It is assumed that if a user calls
%make config-recursive
then options of current port and all it's dependency ports will be processed,
but
If this port(A) enables dependency port(Z) via options then
$$(${ALL-DEPENDS-LIST}) will not include this port(Z), hence options of
port(Z) will not be processed.
If dependency port(B) of port(A) enables another dependency port(X) then
options of this port(X) will not be processed either.
If I am correct with my assumptions, then the following patch fixes this
behaviour:
--- /Users/scher/tmp/config-recursive/bsd.port.mk 2012-06-21
22:53:45.0 +0400
+++ /Users/scher/tmp/config-recursive/bsd.port.mk-fixed 2012-06-21
22:54:35.0 +0400
@@ -6110,8 +6110,8 @@
.if !target(config-recursive)
-config-recursive:
+config-recursive: config-conditional
@${ECHO_MSG} === Setting user-specified options for ${PKGNAME} and
dependencies;
- @for dir in ${.CURDIR} $$(${ALL-DEPENDS-LIST}); do \
- (cd $$dir; ${MAKE} config-conditional); \
+ @for dir in $$(${MAKE} all-depends-list); do \
+ (cd $$dir; ${MAKE} config-recursive); \
done
.endif # config-recursive
The patch seems right and makes sense to me. Properly runs
config-conditional on every port first, then recurses into it, reading
its dependencies as they change.
Filing a PR is best so this doesn't get lost.
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
Re: [ bsd.port.mk ] improper evaluation of config-recursive target
On Thu, Jun 21, 2012 at 09:42:13PM -0500, Bryan Drewery wrote:
On 6/21/2012 2:02 PM, Alexander Pronin wrote:
Hello porters,
My name is Alexander Pronin. I am a GSOC intern. My project is
(http://wiki.freebsd.org/SummerOfCode2012/Parallelization_in_the_ports_collection#preview)
It is assumed that if a user calls
%make config-recursive
then options of current port and all it's dependency ports will be
processed, but
If this port(A) enables dependency port(Z) via options then
$$(${ALL-DEPENDS-LIST}) will not include this port(Z), hence options of
port(Z) will not be processed.
If dependency port(B) of port(A) enables another dependency port(X) then
options of this port(X) will not be processed either.
If I am correct with my assumptions, then the following patch fixes this
behaviour:
--- /Users/scher/tmp/config-recursive/bsd.port.mk 2012-06-21
22:53:45.0 +0400
+++ /Users/scher/tmp/config-recursive/bsd.port.mk-fixed 2012-06-21
22:54:35.0 +0400
@@ -6110,8 +6110,8 @@
.if !target(config-recursive)
-config-recursive:
+config-recursive: config-conditional
@${ECHO_MSG} === Setting user-specified options for ${PKGNAME} and
dependencies;
- @for dir in ${.CURDIR} $$(${ALL-DEPENDS-LIST}); do \
- (cd $$dir; ${MAKE} config-conditional); \
+ @for dir in $$(${MAKE} all-depends-list); do \
+ (cd $$dir; ${MAKE} config-recursive); \
done
.endif # config-recursive
The patch seems right and makes sense to me. Properly runs
config-conditional on every port first, then recurses into it, reading
its dependencies as they change.
Filing a PR is best so this doesn't get lost.
Regards,
Bryan Drewery
This looks nice to me either.
The best still is to send a PR about it so that we can take it in the next run
of exp-run and do not forget about at that time :)
regards,
Bapt
pgpduMS14VBxy.pgp
Description: PGP signature
someone broke bsd.port.mk ?
/usr/ports/Mk/bsd.port.mk, line 6097: Malformed conditional
(${_COMPLETE_OPTIONS_LIST:O} != ${_FILE_COMPLETE_OPTIONS_LIST:O})
Fresh portsnap, some there were changes to bsd.port.mk..
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/someone-broke-bsd-port-mk-tp5716638.html
Sent from the freebsd-ports mailing list archive at Nabble.com.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: someone broke bsd.port.mk ?
On 6/8/12 3:55 PM, Jakub Lach wrote:
/usr/ports/Mk/bsd.port.mk, line 6097: Malformed conditional
(${_COMPLETE_OPTIONS_LIST:O} != ${_FILE_COMPLETE_OPTIONS_LIST:O})
Fresh portsnap, some there were changes to bsd.port.mk..
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/someone-broke-bsd-port-mk-tp5716638.html
Sent from the freebsd-ports mailing list archive at Nabble.com.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
correct, looks broken:
see my email of a few mins ago:
Original Message
Subject: woops: Re: conditional config is skipped for optionsNG'ified
ports
Date: Fri, 8 Jun 2012 15:28:04 -0400
From: Michael Scheidell scheid...@freebsd.org
Organization: SECNAP Network Security Corp
To: freebsd-ports@freebsd.org
On 6/8/12 2:44 PM, Baptiste Daroussin wrote:
Should be fixed thank you. Bapt
old one worked on devel/cross-gcc
pcvs co -r 1.725 ports/Mk/bsd.port.mk
make TGTARCH=arm TGTABI=elf clean
=== Cleaning for arm-elf-gcc-4.5.2
this newest one, not so much:
$FreeBSD: ports/Mk/bsd.port.mk,v 1.726 2012/06/08 18:44:17 bapt Exp $
make TGTARCH=arm TGTABI=elf clean
/usr/ports/Mk/bsd.port.mk, line 6097: Malformed conditional
(${_COMPLETE_OPTIONS_LIST:O} != ${_FILE_COMPLETE_OPTIONS_LIST:O})
/usr/ports/Mk/bsd.port.mk, line 6429: if-less endif
make: fatal errors encountered -- cannot continue
--
Michael Scheidell, CTO
*| * SECNAP Network Security Corporation
d: +1.561.948.2259
w: http://people.freebsd.org/~scheidell
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: someone broke bsd.port.mk ?
On 6/8/12 4:21 PM, Thomas Abthorpe wrote:
On Fri, Jun 08, 2012 at 04:08:49PM -0400, Michael Scheidell wrote:
On 6/8/12 3:55 PM, Jakub Lach wrote:
/usr/ports/Mk/bsd.port.mk, line 6097: Malformed conditional
(${_COMPLETE_OPTIONS_LIST:O} != ${_FILE_COMPLETE_OPTIONS_LIST:O})
A fix was committed that appears to have address the situation, please
update your ports tree and give it a try to verify the changes work for
you.
looking good...
--
Michael Scheidell, CTO
*| * SECNAP Network Security Corporation
d: +1.561.948.2259
w: http://people.freebsd.org/~scheidell
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: someone broke bsd.port.mk ?
Same here, looks normal again. -- View this message in context: http://freebsd.1045724.n5.nabble.com/someone-broke-bsd-port-mk-tp5716638p571.html Sent from the freebsd-ports mailing list archive at Nabble.com. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Minor changes to bsd.port.mk and bsd.pkgng.mk
Hello,
what do you think about the following minor changes to bsd.port.mk
and bsd.pkgng.mk? The motivation is that it is currently relatively
hard to detect, which options of a port are locally changed by user,
or by gradual port upgrades with OPTIONS changed by port maintainer.
(With consequence that when upgrading ports using packages and there
is some non-default options value in a port, direct port compilation
should be forced instead of use of a package.)
Some port maintainers do not use on/off, but they use values ON/On/OFF/Off.
I think that curent default value detection in make showconfig is useless
and confusing, and it should be better to detect real value difference
among OPTIONS in Makefile and options is /var/db/ports.
Furthermore, it is possible to define WITH_* and WITHOUT_* variables
in environment, so maybe there could be even bigger checks for on/off.
--- bsd.port.mk.orig2012-02-24 20:03:39.0 +0100
+++ bsd.port.mk 2012-02-24 20:17:01.0 +0100
@@ -5981,7 +5981,7 @@
set -- ${OPTIONS} XXX; \
while [ $$# -gt 3 ]; do \
OPTIONSLIST=$${OPTIONSLIST} $$1; \
- defaultval=$$3; \
+ defaultval=$$(${ECHO_CMD} $$3 | ${TR} [A-Z] [a-z]); \
withvar=WITH_$$1; \
withoutvar=WITHOUT_$$1; \
withval=$$(eval ${ECHO_CMD} $$\{$${withvar}\}); \
@@ -6086,7 +6086,7 @@
fi; \
set -- ${OPTIONS} XXX; \
while [ $$# -gt 3 ]; do \
- defaultval=$$3; \
+ defaultval=$$(${ECHO_CMD} $$3 | ${TR} [A-Z] [a-z]); \
withvar=WITH_$$1; \
withoutvar=WITHOUT_$$1; \
withval=$$(eval ${ECHO_CMD} $$\{$${withvar}\}); \
@@ -6096,7 +6096,10 @@
elif [ ! -z $${withoutval} ]; then \
val=off; \
else \
- val=$${defaultval} (default); \
+ val=$${defaultval}; \
+ fi; \
+ if [ $${val} = $${defaultval} ]; then \
+ val=$$val (default); \
fi; \
${ECHO_MSG} $$1=$${val} \$$2\; \
shift 3; \
--- bsd.pkgng.mk.orig 2012-02-24 20:08:33.0 +0100
+++ bsd.pkgng.mk2012-02-24 20:14:50.0 +0100
@@ -85,7 +85,7 @@
fi; \
set -- ${OPTIONS} XXX; \
while [ $$# -gt 3 ]; do \
- defaultval=$$3 \
+ defaultval=$$(${ECHO_CMD} $$3 | ${TR} [A-Z] [a-z]); \
withvar=WITH_$$1; \
withoutvar=WITHOUT_$$1; \
withval=$$(eval ${ECHO_CMD} $$\{$${withvar}\}); \
--
Rudolf Cejka cejkar at fit.vutbr.cz http://www.fit.vutbr.cz/~cejkar
Brno University of Technology, Faculty of Information Technology
Bozetechova 2, 612 66 Brno, Czech Republic
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Minor changes to bsd.port.mk and bsd.pkgng.mk
Cejka Rudolf wrote (2012/02/24):
+ defaultval=$$(${ECHO_CMD} $$3 | ${TR} [A-Z] [a-z]); \
I'm sorry - all three lines with ${TR} have to be changed to
+ defaultval=$$(${ECHO_CMD} $$3 | ${TR} [A-Z] [a-z]); \
so that one letter files in ports directories
do not break functionality.
--
Rudolf Cejka cejkar at fit.vutbr.cz http://www.fit.vutbr.cz/~cejkar
Brno University of Technology, Faculty of Information Technology
Bozetechova 2, 612 66 Brno, Czech Republic
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Minor changes to bsd.port.mk and bsd.pkgng.mk
On Feb 24, 2012, at 2:35 PM, Cejka Rudolf wrote:
I'm sorry - all three lines with ${TR} have to be changed to
+defaultval=$$(${ECHO_CMD} $$3 | ${TR} [A-Z] [a-z]); \
so that one letter files in ports directories
do not break functionality.
For your next update, please use [:upper:] and [:lower:] character classes.
This works with languages with diacritical marks and so forth...
Regards,
--
-Chuck
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: LDFLAGS support for bsd.port.mk and CPPFLAGS/LDFLAGS cleanup
Hello, Dmitry. You wrote 24 сентября 2011 г., 3:36:14: The patch was committed, LDFLAGS and CPPFLAGS and now handled similarily, shouldn't be passed to CONFIGURE_ENV and should be altered by += like C/CXXFLAGS. This commit breaks building `databases/sqlite3' with ICU support: command line utility can not be linked, as all libiuc-related options are lost. Previous version of sqlite3/Makefile (1.62) works well. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: LDFLAGS support for bsd.port.mk and CPPFLAGS/LDFLAGS cleanup
Hello, Dmitry. You wrote 24 сентября 2011 г., 3:36:14: The patch was committed, LDFLAGS and CPPFLAGS and now handled similarily, shouldn't be passed to CONFIGURE_ENV and should be altered by += like C/CXXFLAGS. devel/dbus could not be built with this commit, too: checking for pkg-config... (cached) /usr/local/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for XML_ParserCreate_MM in -lexpat... no configure: error: Could not find expat.h, check config.log for failed attempts === Script configure failed unexpectedly. It seems, that every port, which rely on `pkg-config' to determine libraries configuration, will fail. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: LDFLAGS support for bsd.port.mk and CPPFLAGS/LDFLAGS cleanup
Hello, Dmitry. You wrote 24 сентября 2011 г., 3:36:14: The patch was committed, LDFLAGS and CPPFLAGS and now handled similarily, shouldn't be passed to CONFIGURE_ENV and should be altered by += like C/CXXFLAGS. Add devel/dbus-glib to the list... Should I make formal PR for all these ports? -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: LDFLAGS support for bsd.port.mk and CPPFLAGS/LDFLAGS cleanup
On Sun, Sep 25, 2011 at 02:41:36PM +0400, Lev Serebryakov wrote: Hello, Dmitry. You wrote 24 2011 ??., 3:36:14: The patch was committed, LDFLAGS and CPPFLAGS and now handled similarily, shouldn't be passed to CONFIGURE_ENV and should be altered by += like C/CXXFLAGS. Add devel/dbus-glib to the list... Should I make formal PR for all these ports? I could build all those ports just fine ysterday (after the referenced commit went in) and there has not yet been a wide outcry of people having trouble building ports, so I suspect the problem is local to your machine. -- Insert your favourite quote here. Erik Trulsson ertr1...@student.uu.se ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: LDFLAGS support for bsd.port.mk and CPPFLAGS/LDFLAGS cleanup
Hello, Erik. You wrote 25 сентября 2011 г., 14:49:19: The patch was committed, LDFLAGS and CPPFLAGS and now handled similarily, shouldn't be passed to CONFIGURE_ENV and should be altered by += like C/CXXFLAGS. Add devel/dbus-glib to the list... Should I make formal PR for all these ports? I could build all those ports just fine ysterday (after the referenced commit went in) and there has not yet been a wide outcry of people having trouble building ports, so I suspect the problem is local to your machine. It is very strange, as I have csup'ped ports tree without any local changes, and try to portmaster -a my installation. When I've rollback latest changes in these ports, everything works (and upgraded) perfectly. Ports database is Ok, no lost files or dependencies, etc. Many other ports are built without problems, but these three fails to apply proper LDFLAGS, sqlite3 to actual build commands (please note, that problem is only if ICU support is turned on for sqlite3, which is off by default), and tow dbus-related ports on configure stage. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: LDFLAGS support for bsd.port.mk and CPPFLAGS/LDFLAGS cleanup
Lev Serebryakov l...@freebsd.org writes: Hello, Dmitry. You wrote 24 сентября 2011 г., 3:36:14: The patch was committed, LDFLAGS and CPPFLAGS and now handled similarily, shouldn't be passed to CONFIGURE_ENV and should be altered by += like C/CXXFLAGS. devel/dbus could not be built with this commit, too: checking for pkg-config... (cached) /usr/local/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for XML_ParserCreate_MM in -lexpat... no configure: error: Could not find expat.h, check config.log for failed attempts === Script configure failed unexpectedly. It seems, that every port, which rely on `pkg-config' to determine libraries configuration, will fail. I see this, too. Turns out my cvsup mirror is broken. It doesn't have LDFLAGS commit r1.696 for ports/Mk/bsd.port.mk,v while it has r1.86 for ports/devel/dbus/Makefile,v. After using different mirror the issue is gone away. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: LDFLAGS support for bsd.port.mk and CPPFLAGS/LDFLAGS cleanup
* Lev Serebryakov (l...@freebsd.org) wrote: The patch was committed, LDFLAGS and CPPFLAGS and now handled similarily, shouldn't be passed to CONFIGURE_ENV and should be altered by += like C/CXXFLAGS. Add devel/dbus-glib to the list... Should I make formal PR for all these ports? All three ports build here without problems (sqlite3 with ICU option enabled as well), tinderbox shows no problem either. Here's sqlite3+icu log, for example: http://people.freebsd.org/~amdmi3/sqlite3-icu-3.7.8.log configure command shows that LDFLAGS is used as expected after patch. There has also been a set of exp-runs before I committed the patch, last of which showed no breakages. Please double check your ports tree is in consistent state. If there's a problem with specific CVS mirror, this should be reported. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: LDFLAGS support for bsd.port.mk and CPPFLAGS/LDFLAGS cleanup
Hello, h. You wrote 25 сентября 2011 г., 18:40:06: I see this, too. Turns out my cvsup mirror is broken. It doesn't have LDFLAGS commit r1.696 for ports/Mk/bsd.port.mk,v while it has r1.86 for ports/devel/dbus/Makefile,v. After using different mirror the issue is gone away. Yep, it looks like cvsup2.ru.freebsd.org has same problem too. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: LDFLAGS support for bsd.port.mk and CPPFLAGS/LDFLAGS cleanup
On Sat, Sep 24, 2011 at 03:36:14AM +0400, Dmitry Marakasov wrote: * Dmitry Marakasov (amd...@amdmi3.ru) wrote: The patch was committed, LDFLAGS and CPPFLAGS and now handled similarily, shouldn't be passed to CONFIGURE_ENV and should be altered by += like C/CXXFLAGS. Thanks you very much for your work on this. regards, Bapt pgpPCfKrkao7e.pgp Description: PGP signature
Re: LDFLAGS support for bsd.port.mk and CPPFLAGS/LDFLAGS cleanup
* Dmitry Marakasov (amd...@amdmi3.ru) wrote: The patch was committed, LDFLAGS and CPPFLAGS and now handled similarily, shouldn't be passed to CONFIGURE_ENV and should be altered by += like C/CXXFLAGS. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: LDFLAGS support for bsd.port.mk and CPPFLAGS/LDFLAGS cleanup
* Dmitry Marakasov (amd...@amdmi3.ru) wrote: The patch is ready: http://people.freebsd.org/~amdmi3/ldflags.patch While it's mostly a bunch of similar changes, I'd like community eyes on specific important parts, namely Mk/ changes, python and ruby and generally all := assigns of *FLAGS, as these are dangerous (may refer variables which were not yet defined or which are changed later. However, I don't see any other way to prepend values instead of appending). -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: USERS/GROUPS in bsd.port.mk [was: FreeBSD Port: postfix-2.8.4, 1]
Miroslav Lachman wrote: Sahil Tandon wrote: On Tue, 2011-08-02 at 00:04:14 +0200, olli hauer wrote: No, you don't hit the limitation. It seems you really found a bug in the Framework! From the Framework code in bsd.port.mk existing groups should honored. Along those lines, what about using groupmod instead of usermod? Perhaps due to my ignorance, it seems more straightforward and does not require much sed-fu; I've attached a (probably incomplete) patch to illustrate my thinking. I understand what I am suggesting could introduce other problems, so please do not construe it as an as-is suggestion, but rather something to stoke discussion. I tested your patch and it works for me. # pkg_version -vIL = | grep postfix postfix-2.7.2,1 needs updating (index has 2.8.4,1) # id postfix uid=125(postfix) gid=125(postfix) groups=125(postfix),6(mail),3125(maildirs) # patch ~/bsd.port.mk.diff # portmaster postfix-2.7.2,1 === The following actions were performed: Upgrade of mysql-client-5.1.53 to mysql-client-5.1.58 Upgrade of libtool-2.2.10 to libtool-2.4 Upgrade of cyrus-sasl-2.1.23_1 to cyrus-sasl-2.1.23_3 Upgrade of postfix-2.7.2,1 to postfix-2.8.4,1 # id postfix uid=125(postfix) gid=125(postfix) groups=125(postfix),6(mail),3125(maildirs) It was tested on really old testing system... Thank you for your time and working solution. Will the fix be committed to the ports tree? I upgraded Postfix on another machines yesterday and get the same error as reported month ago - upgrade removed postfix from manualy created group. Should I send PR for this? Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: USERS/GROUPS in bsd.port.mk [was: FreeBSD Port: postfix-2.8.4, 1]
On Sep 8, 2011, at 7:35 AM, Miroslav Lachman 000.f...@quip.cz wrote: Miroslav Lachman wrote: Sahil Tandon wrote: On Tue, 2011-08-02 at 00:04:14 +0200, olli hauer wrote: No, you don't hit the limitation. It seems you really found a bug in the Framework! From the Framework code in bsd.port.mk existing groups should honored. Along those lines, what about using groupmod instead of usermod? Perhaps due to my ignorance, it seems more straightforward and does not require much sed-fu; I've attached a (probably incomplete) patch to illustrate my thinking. I understand what I am suggesting could introduce other problems, so please do not construe it as an as-is suggestion, but rather something to stoke discussion. I tested your patch and it works for me. # pkg_version -vIL = | grep postfix postfix-2.7.2,1 needs updating (index has 2.8.4,1) # id postfix uid=125(postfix) gid=125(postfix) groups=125(postfix),6(mail),3125(maildirs) # patch ~/bsd.port.mk.diff # portmaster postfix-2.7.2,1 === The following actions were performed: Upgrade of mysql-client-5.1.53 to mysql-client-5.1.58 Upgrade of libtool-2.2.10 to libtool-2.4 Upgrade of cyrus-sasl-2.1.23_1 to cyrus-sasl-2.1.23_3 Upgrade of postfix-2.7.2,1 to postfix-2.8.4,1 # id postfix uid=125(postfix) gid=125(postfix) groups=125(postfix),6(mail),3125(maildirs) It was tested on really old testing system... Thank you for your time and working solution. Will the fix be committed to the ports tree? I upgraded Postfix on another machines yesterday and get the same error as reported month ago - upgrade removed postfix from manualy created group. Should I send PR for this? I am very sorry to hear that. I already filed a PR after you sent your report to this mailing list, and followed up with portmgr@ earlier this week. I believe they are doing an -exp run before committing the change. I will ping them again if there is no progress in the next few days. Sorry again for the inconvenience.___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: USERS/GROUPS in bsd.port.mk [was: FreeBSD Port: postfix-2.8.4, 1]
On Thu, Sep 08, 2011 at 01:19:26PM -0400, Sahil Tandon wrote: On Sep 8, 2011, at 7:35 AM, Miroslav Lachman 000.f...@quip.cz wrote: Miroslav Lachman wrote: Sahil Tandon wrote: On Tue, 2011-08-02 at 00:04:14 +0200, olli hauer wrote: No, you don't hit the limitation. It seems you really found a bug in the Framework! From the Framework code in bsd.port.mk existing groups should honored. Along those lines, what about using groupmod instead of usermod? Perhaps due to my ignorance, it seems more straightforward and does not require much sed-fu; I've attached a (probably incomplete) patch to illustrate my thinking. I understand what I am suggesting could introduce other problems, so please do not construe it as an as-is suggestion, but rather something to stoke discussion. I tested your patch and it works for me. # pkg_version -vIL = | grep postfix postfix-2.7.2,1 needs updating (index has 2.8.4,1) # id postfix uid=125(postfix) gid=125(postfix) groups=125(postfix),6(mail),3125(maildirs) # patch ~/bsd.port.mk.diff # portmaster postfix-2.7.2,1 === The following actions were performed: Upgrade of mysql-client-5.1.53 to mysql-client-5.1.58 Upgrade of libtool-2.2.10 to libtool-2.4 Upgrade of cyrus-sasl-2.1.23_1 to cyrus-sasl-2.1.23_3 Upgrade of postfix-2.7.2,1 to postfix-2.8.4,1 # id postfix uid=125(postfix) gid=125(postfix) groups=125(postfix),6(mail),3125(maildirs) It was tested on really old testing system... Thank you for your time and working solution. Will the fix be committed to the ports tree? I upgraded Postfix on another machines yesterday and get the same error as reported month ago - upgrade removed postfix from manualy created group. Should I send PR for this? I am very sorry to hear that. I already filed a PR after you sent your report to this mailing list, and followed up with portmgr@ earlier this week. I believe they are doing an -exp run before committing the change. I will ping them again if there is no progress in the next few days. Sorry again for the inconvenience.___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org The exp-run is running right now, some news about this in the next couple of days regards, Bapt pgpiwz8T7k8sh.pgp Description: PGP signature
LDFLAGS support for bsd.port.mk and CPPFLAGS/LDFLAGS cleanup
Hi!
As CPPFLAGS support was recently added to ports ([1]) I've proposed to
add support for LDFLAGS as well ([2]). That is quite logical in terms of
consistence, and also may be useful for other purposes such as passing
LTO flags to the linker.
Since many ports set LDFLAGS via CONFIGURE_ENV, e.g.
CONFIGURE_ENV= CPPFLAGS=-I${LOCALBASE}/include LDFLAGS=-L${LOCALBASE}/lib
which will override ${LDFLAGS}, it's also required to get rid of these.
The same thing should also be done with CPPFLAGS leftovers.
For now, I've processed about 10% of ports which set CONFIGURE_ENV and I
want the community to skim through this partial patch and check if
there are any errors or something should be done differently/should
not be done. See http://people.freebsd.org/~amdmi3/ldflags.patch
Currently, changes are:
* Move CPPFLAGS/LDFLAGS overrides out of CONFIGURE_ENV:
-CONFIGURE_ENV= CPPFLAGS=-I${LOCALBASE}/include
+CPPFLAGS+= -I${LOCALBASE}/include
appends is processed correctly, e.g.
-CONFIGURE_ENV= CPPFLAGS=${CPPFLAGS} -I${LOCALBASE}/include
+CPPFLAGS+= -I${LOCALBASE}/include
* Drop simple passing of CPPFLAGS/LDFLAGS to configure (since it's now
done by ports framework):
-CONFIGURE_ENV= CPPFLAGS=${CPPFLAGS}
* Change CPPFLAGS/LDFLAGS assignments to append (to allow user to tune
these and to be consistent with CFLAGS/CXXFLAGS):
-CPPFLAGS= -I${LOCALBASE}/include
+CPPFLAGS+= -I${LOCALBASE}/include
There are also some other changes made by hand, such as moving CFLAGS
out of CONFIGURE_ENV and tuning MAKE_ENV in the same manner as
CONFIGURE_ENV, but I guess I'll do these automatically as well.
The changes are processed by a perl script, which applies fixes to
each port and then shows a diff for me to check and accept or fix
manually.
I also plan to do an additional pass to fix some other errors such
as using += in CONFIGURE_ENV (e.g. CONFIGURE_ENV=CPPFLAGS+=-I...),
which is illegal and maybe other error I run into before submitting
final version of a patch for an exp-run.
[1]
http://www.freebsd.org/cgi/cvsweb.cgi/ports/Mk/bsd.port.mk.diff?r1=1.673;r2=1.674
[2] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/157936
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Why don't we split bsd.port.mk up?
Hi all,
I've been boring people on IRC with this and perhaps I need to widen
participation to get some opinions.
What do people think of this?
http://wiki.freebsd.org/SimplifyingMkIncludes
tl;dr -- bsd.port.mk is too big, Mk/ directory is cluttered,
.including files from ${PORTSDIR}/Mk in ports is ugly.
A preliminary patch is at [1], for the first part. Yes, I'm sure it'll
break horribly somewhere, but hopefully that'll show what needs
fixing/whether it's possible/practical.
Chris
[1] http://bugs.freebsd.org/160361
--
Chris Rees | FreeBSD Developer
cr...@freebsd.org | http://people.freebsd.org/~crees
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[Request for Comments] Adding a JAILED meta-variable to bsd.port.mk
Hi,
I would like to propose a change to bsd.port.mk which, similarly to
obtaining the OSVERSION, checks if the system on which a port is being
built is a jailed environment.
This change can allow port maintainers to mark ports that do not run in
jailed environments as IGNORE, or adjust PKG_MESSAGE to inform the user
of special conditions or changes that will be needed to run a port from
within a jail. One particular example of the latter is
databases/postgresql*-server, where the user must enable
security.jail.sysvipc_allowed. I am sure this feature could expand to
other cases I have not considered yet, as well.
I have included three patches:
0-Mk-bsd.port.mk.txt - the proposed change to bsd.port.mk
1-ircservices-Makefile.txt - an example usage of disallowing a port from
being built within a jail
2-sshguard-Makefile.txt - an example usage of disabling a port from
being built within a jail conditionally (in this example, it is assumed
security/sshguard-pf is the target port)
Comments, etc, are welcome.
Regards,
Glen
--
Glen Barber | g...@freebsd.org
FreeBSD Documentation Project
--- bsd.port.mk.orig2011-08-12 12:39:23.0 -0400
+++ bsd.port.mk 2011-08-20 06:15:19.644576050 -0400
@@ -46,6 +46,7 @@
#FreeBSD, NetBSD, or OpenBSD as
appropriate.
# OSREL- The release version (numeric) of the
operating system.
# OSVERSION- The value of __FreeBSD_version.
+# JAILED - The system is a FreeBSD jail.
#
# This is the beginning of the list of all variables that need to be
# defined in a port, listed in order that they should be included
@@ -1196,6 +1197,11 @@
.endif
.endif
+# Check if the system is a jail
+.if !defined(JAILED)
+JAILED!= ${SYSCTL} -n security.jail.jailed
+.endif
+
MASTERDIR?=${.CURDIR}
.if ${MASTERDIR} != ${.CURDIR}
--- Makefile.orig 2009-08-31 09:50:55.0 -0400
+++ Makefile2011-08-20 06:14:04.987796133 -0400
@@ -27,6 +27,10 @@
.include bsd.port.pre.mk
+.if ${JAILED}
+IGNORE=Does not run from within a jail
+.endif
+
.if ${OSVERSION} 700042
CFLAGS+= -fno-stack-protector
.endif
--- Makefile.orig 2011-07-24 14:16:29.0 -0400
+++ Makefile2011-08-20 06:14:24.513106022 -0400
@@ -40,6 +40,9 @@
CONFIGURE_ARGS+= --mandir=${MANPREFIX}/man
.if ${SSHGUARDFW} == pf
+. if ${JAILED}
+IGNORE=Cannot use with pf within a jail
+. endif
PKGMSG_FWBLOCK= To activate or configure PF see
http://sshguard.sf.net/doc/setup/blockingpf.html;
.elif ${SSHGUARDFW} == ipfw
PKGMSG_FWBLOCK= Verify that IPFW is active with \ipfw show\.
signature.asc
Description: OpenPGP digital signature
Re: [Request for Comments] Adding a JAILED meta-variable to bsd.port.mk
On Sat, Aug 20, 2011 at 07:09:49AM -0400, Glen Barber wrote: Hi, I would like to propose a change to bsd.port.mk which, similarly to obtaining the OSVERSION, checks if the system on which a port is being built is a jailed environment. This change can allow port maintainers to mark ports that do not run in jailed environments as IGNORE, or adjust PKG_MESSAGE to inform the user of special conditions or changes that will be needed to run a port from within a jail. One particular example of the latter is databases/postgresql*-server, where the user must enable security.jail.sysvipc_allowed. I am sure this feature could expand to other cases I have not considered yet, as well. I do not think this is good idea. The machine or environment where the port is built sometimes (or, in my setups, quite often) is not the same as where it is run. Your proposal gives a tool to tightly tie the ports to build environments, that is detrimental for some setups, and also diminish the value of packaging. IMHO. pgpUm2qVh9JvO.pgp Description: PGP signature
