On 27 October 2012 22:10, Simon J. Gerraty s...@juniper.net wrote:
On Sat, 27 Oct 2012 19:53:56 +0100, Chris Rees writes:
I'm saying that it's unacceptable to expect people to change their
systems just to make the ports tree work after we have broken it on a
supposedly supported version.
But
On 28 October 2012 19:11, Simon J. Gerraty s...@juniper.net wrote:
On Sun, 28 Oct 2012 14:06:41 +, Chris Rees writes:
Are we planning to replace /usr/bin/make with bmake in the near future?
That was what I heard, but any such move is dependent on dealing with
ports. The
On Sun, 28 Oct 2012 14:06:41 +, Chris Rees writes:
Are we planning to replace /usr/bin/make with bmake in the near future?
That was what I heard, but any such move is dependent on dealing with
ports. The ~sjg/ports2bmake.tar.gz on freefall is the plan I came up
with after the above
On 27 Oct 2012 00:35, Simon J. Gerraty s...@juniper.net wrote:
On Fri, 26 Oct 2012 22:02:00 +0100, Chris Rees writes:
In that case we have a switch time on the order of years, not weeks; 8.3
is
supported until May '14, and unless we get a :tl etc MFC into 8, even
longer. All this time the
BTW, would it be useful to put a devel/fmake into ports to make it easy
for people with older systems to install an up to date version of
freebsd make (which groks both sets of toupper/tolower modifiers)?
Perhaps a knob to install it or put in a link as /usr/bin/make ?
[trim CC list a little to stop people regretting replying to this thread]
On 27 October 2012 10:15, Chris Rees utis...@gmail.com wrote:
On 27 Oct 2012 00:35, Simon J. Gerraty s...@juniper.net wrote:
On Fri, 26 Oct 2012 22:02:00 +0100, Chris Rees writes:
In that case we have a switch time on
On 27 October 2012 15:32, Bryan Drewery br...@shatow.net wrote:
On 10/27/2012 8:23 AM, Chris Rees wrote:
[trim CC list a little to stop people regretting replying to this thread]
On 27 October 2012 10:15, Chris Rees utis...@gmail.com wrote:
On 27 Oct 2012 00:35, Simon J. Gerraty
On 10/27/2012 8:23 AM, Chris Rees wrote:
[trim CC list a little to stop people regretting replying to this thread]
On 27 October 2012 10:15, Chris Rees utis...@gmail.com wrote:
On 27 Oct 2012 00:35, Simon J. Gerraty s...@juniper.net wrote:
On Fri, 26 Oct 2012 22:02:00 +0100, Chris Rees
On 27 October 2012 10:34, Chris Rees utis...@gmail.com wrote:
This weeks is making a assumptions that users 1. reads ports@ or 2.
Update to security/errata patches in a timely manner or 3. Read UPDATING
Quite. This should be at least a few months, otherwise we're making
unreasonable requests
On 10/27/2012 9:40 AM, Eitan Adler wrote:
On 27 October 2012 10:34, Chris Rees utis...@gmail.com wrote:
This weeks is making a assumptions that users 1. reads ports@ or 2.
Update to security/errata patches in a timely manner or 3. Read UPDATING
Quite. This should be at least a few months,
On 27 October 2012 18:27, Simon J. Gerraty s...@juniper.net wrote:
These discussions need backing up with a real roadmap, including detail on
exactly what 8.3 and 7.4 users will have to do to ensure that the ports
tree still works.
I've tested the ports tree converted to bmake - per the patch I
These discussions need backing up with a real roadmap, including detail on
exactly what 8.3 and 7.4 users will have to do to ensure that the ports
tree still works.
I've tested the ports tree converted to bmake - per the patch I
mentioned on a 7.1 box. It worked for me. Once the ports tree has
On 27 October 2012 19:52, Simon J. Gerraty s...@juniper.net wrote:
On Sat, 27 Oct 2012 14:23:29 +0100, Chris Rees writes:
We (ab)use the security update mechanism to merge the pmake changes
(:tl and :tu) into releng/7.4 and releng/8.3 (possibly the earlier
I originally provided the :tl and :tu
On Sat, 27 Oct 2012 09:44:36 -0500, Bryan Drewery writes:
Could there be a make.conf/env setting to make bmake run AS pmake in
full compat mode? On by default until all older branches are EoL, then
it can flip and be optional.
This has been mentioned before.
Firstly, I have changed bmake
On Sat, 27 Oct 2012 18:32:56 +0100, Chris Rees writes:
On 27 October 2012 18:27, Simon J. Gerraty s...@juniper.net wrote:
I've tested the ports tree converted to bmake - per the patch I
mentioned on a 7.1 box. It worked for me. Once the ports tree has
What about these?
[crees@pegasus]~%
On Sat, 27 Oct 2012 14:23:29 +0100, Chris Rees writes:
We (ab)use the security update mechanism to merge the pmake changes
(:tl and :tu) into releng/7.4 and releng/8.3 (possibly the earlier
I originally provided the :tl and :tu patch for something like that
(not planning any abuse mind ;-)
But,
On Sat, 27 Oct 2012 19:53:56 +0100, Chris Rees writes:
I'm saying that it's unacceptable to expect people to change their
systems just to make the ports tree work after we have broken it on a
supposedly supported version.
But there's no suggestion of that.
The ports tree would take care of
Can someone please explain to me what the original reason is for
causing such ridiculously large, far reaching issues?
And why people seem to be in a really, really big rush for it?
Adrian
___
freebsd-hackers@freebsd.org mailing list
On 26 Oct 2012 06:01, Konstantin Belousov kostik...@gmail.com wrote:
On Thu, Oct 25, 2012 at 03:53:53PM -0700, Simon J. Gerraty wrote:
On Thu, 25 Oct 2012 23:01:27 +0100, Chris Rees writes:
Is there a Wiki page where the actual benefits of moving to bmake are
made clear? This is a
In particular, why cannot the ':L' and ':U' support be added ?
:U is already used by bmake for something else- I can't remember what, but
I checked the man page last night :(
http://www.crufty.net/sjg/blog/freebsd-meta-mode.htm
might provide some interesting background.
It is a more FreeBSD
In particular, why cannot the ':L' and ':U' support be added ?
Because they already exist - with different meanings.
They were added to NetBSD make over 10 years ago, from the OSF version
of pmake.
In several areas the behavior of bmake has been changed to make it a
drop in replacement for
On 10/25/12 23:23, Simon J. Gerraty wrote:
In particular, why cannot the ':L' and ':U' support be added ?
Because they already exist - with different meanings.
They were added to NetBSD make over 10 years ago, from the OSF version
of pmake.
In several areas the behavior of bmake has been
On Oct 26, 2012, at 12:23 AM, Simon J. Gerraty wrote:
In particular, why cannot the ':L' and ':U' support be added ?
Because they already exist - with different meanings.
They were added to NetBSD make over 10 years ago, from the OSF version
of pmake.
And we've had the :U and :L for a
On Fri, 2012-10-26 at 08:27 -0600, Warner Losh wrote:
On Oct 26, 2012, at 12:23 AM, Simon J. Gerraty wrote:
In particular, why cannot the ':L' and ':U' support be added ?
Because they already exist - with different meanings.
They were added to NetBSD make over 10 years ago, from the
On Thu, Oct 25, 2012 at 03:00:21PM -0700, Garrett Cooper wrote:
Here's an updated version of the workaround that works properly in all
cases and installs bmake as make and links make to pmake when
WITH_BMAKE=yes, and installs make as make when WITHOUT_BMAKE is
specified (this works better than
On Thu, Oct 25, 2012 at 03:00:21PM -0700, Garrett Cooper wrote:
Here's an updated version of the workaround that works properly in all
cases and installs bmake as make and links make to pmake when
WITH_BMAKE=yes, and installs make as make when WITHOUT_BMAKE is
specified (this works better than
On Tue, Oct 02, 2012 at 07:19:55AM -0700, Garrett Cooper wrote:
Hmmm... that's one of the 3 approaches I provided, but it turned out
...
1. Test programs live with the sources (this was the requested approach), e.g.
2. Test programs live in subdirs:
3. Test programs completely decoupled from
On Oct 26, 2012, at 11:21 AM, Simon J. Gerraty wrote:
On Fri, 26 Oct 2012 08:27:06 -0600, Warner Losh writes:
And we've had the :U and :L for a similar period of time as well. =
Sorry, I didn't mean to imply age has anything to do with it.
The doc I refered to makes it clear that the
On Thu, Oct 25, 2012 at 02:23:06PM -0700, Marcel Moolenaar wrote:
I think there are 2 reasons why not to:
1. The people working on ATF have not raised this concern and
have expressed that using the WITH_BMAKE knob is but a small
price to pay.
I'm trying to create an ATF test for
On Fri, 26 Oct 2012 08:27:06 -0600, Warner Losh writes:
And we've had the :U and :L for a similar period of time as well. =
Sorry, I didn't mean to imply age has anything to do with it.
The doc I refered to makes it clear that the two sets of conflicting
modifers were introduced at about the
with their use of FreeBSD's make in their own projects. So picking a
good name now would be helpful.
FWIW I keep a copy in /usr/bin/fmake so I can compare behavior.
___
freebsd-hackers@freebsd.org mailing list
On Fri, Oct 26, 2012 at 09:41:36AM -0600, Ian Lepore wrote:
We have to be able to build the same source for multiple versions of
freebsd, so even finding all the old :U and :L and any other
incompatibilities and fixing them isn't an option because we'd just
trade works in freebsd 10 for broken
On Fri, Oct 26, 2012 at 12:12:44AM +0200, Baptiste Daroussin wrote:
Do be able to get the ports tree working with bmake asap, I also asked
him to MFC it to 9.1, from latest reply he got positive answer from re@
about this, but was waiting for something I don't remember.
:tu/:tl is in
On Fri, Oct 26, 2012 at 11:12:53AM -0700, Simon J. Gerraty wrote:
On Fri, 26 Oct 2012 11:41:46 -0600, Warner Losh writes:
It's called a transition period for a reason. The historical use has =
permeated itself into many places, not all of which are obvious.
It would seem that leaving
On Fri, 26 Oct 2012 11:41:46 -0600, Warner Losh writes:
It's called a transition period for a reason. The historical use has =
permeated itself into many places, not all of which are obvious.
It would seem that leaving FreeBSD make as make, for the transition
period and installing bmake as
On Fri, 2012-10-26 at 11:09 -0700, David O'Brien wrote:
On Fri, Oct 26, 2012 at 09:41:36AM -0600, Ian Lepore wrote:
We have to be able to build the same source for multiple versions of
freebsd, so even finding all the old :U and :L and any other
incompatibilities and fixing them isn't an
On Oct 26, 2012, at 12:11 PM, David O'Brien wrote:
On Fri, Oct 26, 2012 at 12:12:44AM +0200, Baptiste Daroussin wrote:
Do be able to get the ports tree working with bmake asap, I also asked
him to MFC it to 9.1, from latest reply he got positive answer from re@
about this, but was waiting
On Fri, 26 Oct 2012 10:55:59 -0700, David O'Brien writes:
I'm trying to create an ATF test for filemon, but I don't want to have to
build make back and forth when I want to build a port.
Likely that doesn't put me in the people working on ATF in your book.
What can I and others do to work on
On Fri, Oct 26, 2012 at 11:11:52AM -0700, David O'Brien wrote:
On Fri, Oct 26, 2012 at 12:12:44AM +0200, Baptiste Daroussin wrote:
Do be able to get the ports tree working with bmake asap, I also asked
him to MFC it to 9.1, from latest reply he got positive answer from re@
about this, but
On 26 Oct 2012 19:12, David O'Brien obr...@freebsd.org wrote:
On Fri, Oct 26, 2012 at 12:12:44AM +0200, Baptiste Daroussin wrote:
Do be able to get the ports tree working with bmake asap, I also asked
him to MFC it to 9.1, from latest reply he got positive answer from re@
about this, but
On Fri, Oct 26, 2012 at 9:34 AM, David O'Brien obr...@freebsd.org wrote:
On Thu, Oct 25, 2012 at 03:00:21PM -0700, Garrett Cooper wrote:
Here's an updated version of the workaround that works properly in all
cases and installs bmake as make and links make to pmake when
WITH_BMAKE=yes, and
On Fri, Oct 26, 2012 at 9:54 AM, David O'Brien obr...@freebsd.org wrote:
On Tue, Oct 02, 2012 at 07:19:55AM -0700, Garrett Cooper wrote:
Hmmm... that's one of the 3 approaches I provided, but it turned out
...
1. Test programs live with the sources (this was the requested approach),
e.g.
2.
Minor disambiguation:
On Fri, Oct 26, 2012 at 12:27 PM, Garrett Cooper yaneg...@gmail.com wrote:
...
There are some basic examples, but they're in my p4 branch and
unfortunately they depend on atf.test.mk/bsd.test.mk/bsd.progs.mk
existing before they can be built (please see the Examples
On 26 Oct 2012 20:15, Chris Rees utis...@gmail.com wrote:
On 26 Oct 2012 19:12, David O'Brien obr...@freebsd.org wrote:
On Fri, Oct 26, 2012 at 12:12:44AM +0200, Baptiste Daroussin wrote:
Do be able to get the ports tree working with bmake asap, I also asked
him to MFC it to 9.1, from
On Fri, Oct 26, 2012 at 12:54 PM, Simon J. Gerraty s...@juniper.net wrote:
On Fri, 26 Oct 2012 12:27:35 -0700, Garrett Cooper writes:
There are some basic examples, but they're in my p4 branch and
unfortunately they depend on atf.test.mk/bsd.test.mk/bsd.progs.mk
Speaking of which. I notice
On Fri, 26 Oct 2012 12:27:35 -0700, Garrett Cooper writes:
There are some basic examples, but they're in my p4 branch and
unfortunately they depend on atf.test.mk/bsd.test.mk/bsd.progs.mk
Speaking of which. I notice there is now a bsd.progs.mk in head, which
bears little relationship to the one
On 26 Oct 2012 21:51, Simon J. Gerraty s...@juniper.net wrote:
On Fri, 26 Oct 2012 21:00:26 +0100, Chris Rees writes:
:L -- seems that bmake's use for this is kinda pointless; returning the
name of the variable; we could swap that usage over directly.
Acutally it is very useful.
The
On Fri, 26 Oct 2012 21:00:26 +0100, Chris Rees writes:
:L -- seems that bmake's use for this is kinda pointless; returning the
name of the variable; we could swap that usage over directly.
Acutally it is very useful.
The debugging facilities in dirdeps.mk rely on it.
The junos build uses it in
On Fri, Oct 26, 2012 at 09:00:26PM +0100, Chris Rees wrote:
:U -- with bmake has non-optional arguments, so for example:
${VAR:U} - pmake behaviour
${VAR:Uval} - make behaviour.
Would that be acceptable? I can get a patch in if that's popular.
${VAR:U} is useful for bmake as well. For
On Fri, Oct 26, 2012 at 09:34:20AM -0700, David O'Brien wrote:
(there are no pre-build packages for 10-CURRENT).
Please see the first two entries on:
http://pkgbeta.freebsd.org/
mcl
___
freebsd-hackers@freebsd.org mailing list
On Fri, Oct 26, 2012 at 10:02:00PM +0100, Chris Rees wrote:
On 26 Oct 2012 21:51, Simon J. Gerraty s...@juniper.net wrote:
On Fri, 26 Oct 2012 21:00:26 +0100, Chris Rees writes:
:L -- seems that bmake's use for this is kinda pointless; returning the
name of the variable; we could swap
On Fri, 26 Oct 2012 22:02:00 +0100, Chris Rees writes:
In that case we have a switch time on the order of years, not weeks; 8.3 is
supported until May '14, and unless we get a :tl etc MFC into 8, even
longer. All this time the ports tree must work with pmake.
I'm pretty sure I was told it is
On Mon, Oct 08, 2012 at 09:11:29AM -0700, Marcel Moolenaar wrote:
two independent efforts (ATF bmake) and there was no indication that
one would be greatly benefitted from the other. At least not to the
point of creating a dependency.
It seems we do have the situation where folks feel there
On 25 October 2012 22:15, David O'Brien obr...@freebsd.org wrote:
On Mon, Oct 08, 2012 at 09:11:29AM -0700, Marcel Moolenaar wrote:
two independent efforts (ATF bmake) and there was no indication that
one would be greatly benefitted from the other. At least not to the
point of creating a
On Oct 25, 2012, at 2:15 PM, David O'Brien obr...@freebsd.org wrote:
On Mon, Oct 08, 2012 at 09:11:29AM -0700, Marcel Moolenaar wrote:
two independent efforts (ATF bmake) and there was no indication that
one would be greatly benefitted from the other. At least not to the
point of creating a
On Thu, Oct 25, 2012 at 2:23 PM, Marcel Moolenaar mar...@xcllnt.net wrote:
...
I think there are 2 reasons why not to:
1. The people working on ATF have not raised this concern and
have expressed that using the WITH_BMAKE knob is but a small
price to pay. So let's work the bmake
On Thu, Oct 25, 2012 at 2:32 PM, Garrett Cooper yaneg...@gmail.com wrote:
...
The real issue is that I need to take the patch Simon developed, run
with it, and in parallel he needs to -- and hopefully already is --
engage portmgr to get it through a number of exp- runs to make sure
bmake
On 25 October 2012 22:32, Garrett Cooper yaneg...@gmail.com wrote:
On Thu, Oct 25, 2012 at 2:23 PM, Marcel Moolenaar mar...@xcllnt.net wrote:
...
I think there are 2 reasons why not to:
1. The people working on ATF have not raised this concern and
have expressed that using the
On Thu, Oct 25, 2012 at 11:01:27PM +0100, Chris Rees wrote:
On 25 October 2012 22:32, Garrett Cooper yaneg...@gmail.com wrote:
On Thu, Oct 25, 2012 at 2:23 PM, Marcel Moolenaar mar...@xcllnt.net wrote:
...
I think there are 2 reasons why not to:
1. The people working on ATF have
On 25 October 2012 18:12, Baptiste Daroussin b...@freebsd.org wrote:
Not much test has been done on the ports tree about it, from what I have
tested
so far, except from the :tu :tl difference the ports seems to work ootb with
both bmake and make, I asked obrien to MFC the support for :tl :tu
On Thu, Oct 25, 2012 at 3:01 PM, Chris Rees cr...@freebsd.org wrote:
...
Now you've terrified me, and probably most other ports people too.
Is there a Wiki page where the actual benefits of moving to bmake are
made clear? This is a major, *major* upheaval, and having two
versions of
On Thu, 25 Oct 2012 22:21:59 +0100, Chris Rees writes:
We really aren't going to have any luck yet...
[crees@pegasus]/usr/ports% sudo make MAKE=/usr/bin/bmake index | head
If anyone is eager to play with this, I just have put a copy of
ports2bmake.tar.gz in ~sjg/ on freefall.
This contains a
On Thu, Oct 25, 2012 at 10:21:59PM +0100, Chris Rees wrote:
On 25 October 2012 22:15, David O'Brien obr...@freebsd.org wrote:
On Mon, Oct 08, 2012 at 09:11:29AM -0700, Marcel Moolenaar wrote:
two independent efforts (ATF bmake) and there was no indication that
one would be greatly
On Thu, 25 Oct 2012 23:01:27 +0100, Chris Rees writes:
Is there a Wiki page where the actual benefits of moving to bmake are
made clear? This is a major, *major* upheaval, and having two
versions of bsd.port.mk for years is simply not an option.
There is no need/plan for two versions of
On Thu, Oct 25, 2012 at 03:53:53PM -0700, Simon J. Gerraty wrote:
On Thu, 25 Oct 2012 23:01:27 +0100, Chris Rees writes:
Is there a Wiki page where the actual benefits of moving to bmake are
made clear? This is a major, *major* upheaval, and having two
versions of bsd.port.mk for years is
On Oct 8, 2012, at 12:11 , Marcel Moolenaar mar...@xcllnt.net wrote:
On Oct 4, 2012, at 9:42 AM, Garrett Cooper yaneg...@gmail.com wrote:
Both parties (Isilon/Juniper) are converging on the ATF porting work
that Giorgos/myself have done after talking at the FreeBSD Foundation
meet-n-greet.
On Oct 13, 2012, at 12:15 PM, George Neville-Neil g...@neville-neil.com wrote:
I think that's a small price to pay for getting going with the ATF
stuff now rather than in 4 weeks. What's the right way to do this
now with HEAD?
Set WITH_BMAKE=yes in /etc/src.conf or /etc/make.conf and
On Sat, 13 Oct 2012 15:15:59 -0400, George Neville-Neil writes:
It could be a while (many weeks) before we get to 4, so the question
really is whether the people working on ATF are willing and able to
build and install FreeBSD using WITH_BMAKE?
=20
I think that's a small price to pay for
On Sat, Oct 13, 2012 at 1:13 PM, Simon J. Gerraty s...@juniper.net wrote:
On Sat, 13 Oct 2012 15:15:59 -0400, George Neville-Neil writes:
It could be a while (many weeks) before we get to 4, so the question
really is whether the people working on ATF are willing and able to
build and install
On Oct 4, 2012, at 9:42 AM, Garrett Cooper yaneg...@gmail.com wrote:
Both parties (Isilon/Juniper) are converging on the ATF porting work
that Giorgos/myself have done after talking at the FreeBSD Foundation
meet-n-greet. I have contributed all of the patches that I have other
to marcel for
On Oct 2, 2012, at 10:37 , John Baldwin j...@freebsd.org wrote:
This is very non-obvious to the public at large (e.g. there was no public
response to one group's inquiry about the second ATF import for example).
Also, given that you had no idea that sgf@ and obrien@ were working on
On Thu, Oct 04, 2012 at 12:11:21PM -0400, George Neville-Neil wrote:
...
But, I would like to drive this to a solution on arch@. We don't have an
atf@, but we do have a test@ and testing@. We have too many mailing
lists already, so let's finish this up here if we can and then
continue
On Thu, Oct 4, 2012 at 9:29 AM, David Wolfskill da...@catwhisker.org wrote:
On Thu, Oct 04, 2012 at 12:11:21PM -0400, George Neville-Neil wrote:
...
But, I would like to drive this to a solution on arch@. We don't have an
atf@, but we do have a test@ and testing@. We have too many mailing
On Mon, Oct 1, 2012 at 5:00 PM, Simon J. Gerraty s...@juniper.net wrote:
Not to mention the fact that bsd.prog.mk goes from being relatively
simple, to unspeakably hard to read, and all for rather limited =
return.
This btw I think is the more important issue.
I was looking at bsd.prog.mk in
On Tue, 2 Oct 2012 07:19:55 -0700, Garrett Cooper writes:
We put the test cases in a subdir of the lib/prog
This has multiple benefits, and eliminates any impact on the normal
build of said libs/progs.
Hmmm... that's one of the 3 approaches I provided, but it turned out
to be annoying to make
Hi Simon!
On Oct 1, 2012, at 3:31 PM, Simon J. Gerraty wrote:
Hi Garrett,
From: Garrett Cooper yaneg...@gmail.com
Subject: [CFT/RFC]: refactor bsd.prog.mk to understand multiple =
programs instead of a singular program
Date: September 2, 2012 11:01:09 PM PDT
To:
Not to mention the fact that bsd.prog.mk goes from being relatively
simple, to unspeakably hard to read, and all for rather limited =
return.
This btw I think is the more important issue.
I was looking at bsd.prog.mk in netbsd the other day.
It has no business being that complex.
Getting back
In message cagh67wqty4krgwspa5jaht-4hqd4veykley-r3c6k9f5xaf...@mail.gmail.com
, Garrett Cooper writes:
No difference proven at 95.0% confidence
This is the important bit of information...
Thanks for the tip :)!
You're welcome :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
On Sep 24, 2012, at 1:21 AM, Poul-Henning Kamp p...@phk.freebsd.dk wrote:
In message
cagh67wqty4krgwspa5jaht-4hqd4veykley-r3c6k9f5xaf...@mail.gmail.com
, Garrett Cooper writes:
No difference proven at 95.0% confidence
This is the important bit of information...
Yeah.. It's been a few
On Sat, Sep 22, 2012 at 11:30 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote:
In message
cagh67wsux7zjrtb5gehqwhkqykog-atwkinw5csjlrzftzk...@mail.gmail.com
, Garrett Cooper writes:
Without the change:
$ python calc_runtime.py bw.*_without.log | ministat -w 72
[...]
$ python calc_runtime.py
On Sun, Sep 2, 2012 at 11:01 PM, Garrett Cooper yaneg...@gmail.com wrote:
Hello,
I've been a bit busy working on porting over ATF from NetBSD, and
one of the pieces that's currently not available in FreeBSD that's
available in NetBSD is the ability to understand and compile multiple
81 matches
Mail list logo
