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
alwa
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
> ===
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
c/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?
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:
>
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,
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"
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
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
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
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
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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=129741
Baptiste Daroussin b...@freebsd.org changed:
What|Removed |Added
Attachment #92158|0 |1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=129741
Baptiste Daroussin b...@freebsd.org changed:
What|Removed |Added
Attachment #92156|0 |1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=129741
Baptiste Daroussin b...@freebsd.org changed:
What|Removed |Added
Status|Open|Issue
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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=129741
Baptiste Daroussin b...@freebsd.org changed:
What|Removed |Added
Status|In Discussion |Needs Help
http://bugs.freebsd.org/bugzilla/show_bug.cgi?id=129741
Mark Linimon lini...@freebsd.org changed:
What|Removed |Added
Component|Individual Port(s) |Infrastructure
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
/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
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
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
:
=== 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
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
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
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:
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
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
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,
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
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
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
-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
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
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:
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
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
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
-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
,
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
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
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
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
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
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
/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
; 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
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
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
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
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
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
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
,
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
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 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
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
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
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
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
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 -
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
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
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
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
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
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
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
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
/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
/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
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 \
) 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
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
) 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
/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
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
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
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
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
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
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
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
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...
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?
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.
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
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
* 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
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
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
* 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
* 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
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
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
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
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.
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
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
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
1 - 100 of 161 matches
Mail list logo
