kensmith2007-12-29 06:21:59 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_6_3)
usr.sbin/sysinstall main.c
Log:
MFC v1.78 and v1.79:
Remove process limits for datasize and stacksize which are unlimited
during a "normal login" (thanks to /etc/login.conf) bu
kensmith2007-12-29 06:19:18 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_6)
usr.sbin/sysinstall main.c
Log:
MFC v1.78 and v1.79:
Remove process limits for datasize and stacksize which are unlimited
during a "normal login" (thanks to /etc/login.conf) but
kensmith2007-12-29 06:17:05 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_7_0)
usr.sbin/sysinstall main.c
Log:
MFC v1.78 and v1.79:
Remove process limits for datasize and stacksize which are unlimited
during a "normal login" (thanks to /etc/login.conf) bu
kensmith2007-12-29 06:14:35 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_7)
usr.sbin/sysinstall main.c
Log:
MFC v1.78 and v1.79:
Remove process limits for datasize and stacksize which are unlimited
during a "normal login" (thanks to /etc/login.conf) but
kensmith2007-12-29 04:52:52 UTC
FreeBSD src repository
Modified files:
usr.sbin/sysinstall main.c
Log:
Adjust the some error messages as suggested during re@ review, and
adjust a comment that won't be true shortly.
Revision ChangesPath
1.79 +10 -3 src/usr.
On Fri, 2007-12-28 at 05:08 +, Ken Smith wrote:
> kensmith2007-12-28 05:08:54 UTC
>
> FreeBSD src repository
>
> Modified files:
> usr.sbin/sysinstall main.c
> Log:
> The limit on datasize in the install environment is 128M. That's a bit
> too small for today's standards
kensmith2007-12-28 05:08:54 UTC
FreeBSD src repository
Modified files:
usr.sbin/sysinstall main.c
Log:
The limit on datasize in the install environment is 128M. That's a bit
too small for today's standards. While loading packages sysinstall
blows past this by a LOT but I t
On Mon, Apr 30, 2007, David Schultz wrote:
> I think Alfred is absolutely right, and this is a pretty major
> POLA violation. As a result of these changes, I've got two ports
> (so far) and some model checking software that won't build/run
> anymore. If we've been doing something right for years, c
On Tue, May 01, 2007 at 12:10:11PM -0400, John Baldwin wrote:
> Now, that said, apparently some folks on this list CAN'T READ.
>
> Linux has the new putenv() algorithm already, so if any software breaks with
> this, it is _ALREADY_ broken on Linux. Please consider that before ripping
> ache@ a
* Andrey Chernov <[EMAIL PROTECTED]> [070501 04:52] wrote:
> On Tue, May 01, 2007 at 04:31:55AM -0700, Alfred Perlstein wrote:
> > If the fallout from your changes broke a bunch of things in
> > -current, then we can expect the fallout in -stable to be
> > even worse.
>
> They are not planning to
On Tue, May 01, 2007 at 08:33:56PM +0200, Alexander Leidinger wrote:
> And may I remind you that we talk about following POSIX so most of the
> programs we have in the ports should be ok?
I think so too.
> I agree that it may have been more nice if there was a HEADS-UP first
> (the age old behavi
Quoting Roman Kurakin <[EMAIL PROTECTED]> (Tue, 01 May 2007 15:27:18 +0400):
> Peter Jeremy wrote:
> > Note that just building the ports with these changes will not demonstrate
> > much. This change alters the functionality of putenv() rather than the
> > API/ABI so testing the change requires e
On Tuesday 01 May 2007 06:06:42 am Peter Jeremy wrote:
> On 2007-May-01 04:02:42 +0400, Andrey Chernov <[EMAIL PROTECTED]> wrote:
> >On Mon, Apr 30, 2007 at 06:57:17PM -0400, David Schultz wrote:
> >> I think Alfred is absolutely right, and this is a pretty major
> >> POLA violation.
> >
> >That's
* Andrey Chernov <[EMAIL PROTECTED]> [070501 05:25] wrote:
> On Tue, May 01, 2007 at 03:51:33PM +0400, Andrey Chernov wrote:
> > > Your query about bug reports is a straw man as anticipating
> > > a lot of fallout which has already occured does not require
> > > that I actually have a bug report.
>
On Tue, May 01, 2007 at 03:51:33PM +0400, Andrey Chernov wrote:
> > Your query about bug reports is a straw man as anticipating
> > a lot of fallout which has already occured does not require
> > that I actually have a bug report.
I can add that I expect _much_less_ fallouts from the ports since t
On Tue, May 01, 2007 at 03:27:18PM +0400, Roman Kurakin wrote:
> I suggest to install all ports sources and grep them at first. I am sure
> some of ports
> could be marked as bug-less and other should be marked for exec-check or
> probably
> for more accurate review not just grep.
Interesti
On Tue, May 01, 2007 at 04:31:55AM -0700, Alfred Perlstein wrote:
> If the fallout from your changes broke a bunch of things in
> -current, then we can expect the fallout in -stable to be
> even worse.
They are not planning to go into -stable any soon until the moment when
7.x becomes -stable, wh
Andrey,
If the fallout from your changes broke a bunch of things in
-current, then we can expect the fallout in -stable to be
even worse.
Your query about bug reports is a straw man as anticipating
a lot of fallout which has already occured does not require
that I actually have a bug report.
The
On Tue, May 01, 2007 at 08:59:37PM +1000, Peter Jeremy wrote:
> Note that just building the ports with these changes will not demonstrate
> much. This change alters the functionality of putenv() rather than the
> API/ABI so testing the change requires exercising the ports. This is
> a much more d
Peter Jeremy wrote:
On 2007-May-01 10:48:28 +0400, Andrey Chernov <[EMAIL PROTECTED]> wrote:
On Mon, Apr 30, 2007 at 06:39:57PM -0700, Alfred Perlstein wrote:
Using the strategy "commit to -current then suffer the fallout"
is pretty bogus.
The only possible. Nobody can run all po
On 2007-May-01 10:48:28 +0400, Andrey Chernov <[EMAIL PROTECTED]> wrote:
>On Mon, Apr 30, 2007 at 06:39:57PM -0700, Alfred Perlstein wrote:
>> Using the strategy "commit to -current then suffer the fallout"
>> is pretty bogus.
>
>The only possible. Nobody can run all ports at once. Kris already pro
On Tue, May 01, 2007 at 08:06:42PM +1000, Peter Jeremy wrote:
> I would have expected this proposed change to get a heads-up in
> current@ first. _Especially_ since there is a current thread in
> current@ about fixing some long-standing memory leaks in our *env()
> functions. Implementing a major
On 2007-May-01 04:02:42 +0400, Andrey Chernov <[EMAIL PROTECTED]> wrote:
>On Mon, Apr 30, 2007 at 06:57:17PM -0400, David Schultz wrote:
>> I think Alfred is absolutely right, and this is a pretty major
>> POLA violation.
>
>That's -current for. Do you suggest to wait yet more N years to commit
>
On Tue, May 01, 2007 at 03:30:32AM -0500, Mark Linimon wrote:
> On Tue, May 01, 2007 at 10:48:28AM +0400, Andrey Chernov wrote:
> > On Mon, Apr 30, 2007 at 06:39:57PM -0700, Alfred Perlstein wrote:
> > > Using the strategy "commit to -current then suffer the fallout"
> > > is pretty bogus.
> >
> >
On Tue, May 01, 2007 at 10:48:28AM +0400, Andrey Chernov wrote:
> On Mon, Apr 30, 2007 at 06:39:57PM -0700, Alfred Perlstein wrote:
> > Using the strategy "commit to -current then suffer the fallout"
> > is pretty bogus.
>
> The only possible. Nobody can run all ports at once. Kris already promise
On Mon, Apr 30, 2007 at 06:39:57PM -0700, Alfred Perlstein wrote:
> Using the strategy "commit to -current then suffer the fallout"
> is pretty bogus.
The only possible. Nobody can run all ports at once. Kris already promise
all ports build results with those changes in, lets see.
Speaking about
Using the strategy "commit to -current then suffer the fallout"
is pretty bogus.
I don't understand why some form of compatibility or #define wasn't
thought out before hand.
This stands out like "fixing select" to record time elapsed into
the timevals, POSIX'ly correct, but incorrect for FreeBSD,
On Tue, May 01, 2007 at 04:59:42AM +0400, Roman Kurakin wrote:
> Hi,
>
> Since there is some noise around this, could we just scream for a while
> that code should be fixed but allow it to still work? After some time than
> the majority of the buggy code will be fixed we will stick to the std
Hi,
Since there is some noise around this, could we just scream for a while
that code should be fixed but allow it to still work? After some time than
the majority of the buggy code will be fixed we will stick to the std
behavior? IMHO this will be less painful.
rik
Andrey Chernov wrote:
On T
On Tue, May 01, 2007 at 04:02:42AM +0400, Andrey Chernov wrote:
> On Mon, Apr 30, 2007 at 06:57:17PM -0400, David Schultz wrote:
> > I think Alfred is absolutely right, and this is a pretty major
> > POLA violation.
>
> That's -current for. Do you suggest to wait yet more N years to commit
> exa
On Mon, Apr 30, 2007 at 06:57:17PM -0400, David Schultz wrote:
> I think Alfred is absolutely right, and this is a pretty major
> POLA violation.
That's -current for. Do you suggest to wait yet more N years to commit
exact that stuff?
> As a result of these changes, I've got two ports
> (so far
On Mon, Apr 30, 2007, Andrey Chernov wrote:
> On Mon, Apr 30, 2007 at 11:00:43AM -0700, Alfred Perlstein wrote:
> > * Andrey A. Chernov <[EMAIL PROTECTED]> [070430 08:17] wrote:
> > > ache2007-04-30 15:16:19 UTC
> > >
> > > FreeBSD src repository
> > >
> > > Modified files:
> > >
On Mon, Apr 30, 2007 at 11:00:43AM -0700, Alfred Perlstein wrote:
> * Andrey A. Chernov <[EMAIL PROTECTED]> [070430 08:17] wrote:
> > ache2007-04-30 15:16:19 UTC
> >
> > FreeBSD src repository
> >
> > Modified files:
> > usr.sbin/sysinstall main.c
> > Log:
> > Preparing for
* Andrey A. Chernov <[EMAIL PROTECTED]> [070430 08:17] wrote:
> ache2007-04-30 15:16:19 UTC
>
> FreeBSD src repository
>
> Modified files:
> usr.sbin/sysinstall main.c
> Log:
> Preparing for upcoming POSIXed putenv() rewrite:
> don't allow const as putenv() arg, dup it
>
On Mon, Apr 30, 2007 at 12:56:14PM -0400, John Baldwin wrote:
> Ok. FWIW, this seems like a ridiculous and gross hack just to provide a
> backdoor for updating the environment w/o making a fooenv() function call
> (either putenv, or setenv).
It rather history issue. POSIX just precisely documen
On Mon, Apr 30, 2007 at 09:05:38PM +0400, Andrey Chernov wrote:
> On Mon, Apr 30, 2007 at 12:54:45PM -0400, John Baldwin wrote:
> > Hmm, I think I see that this is orthogonal to the setenv(3) fix, but still,
> > if
> > one does this:
> >
> > char *cp = strdup("FOO=bar");
> > putenv(cp);
On Monday 30 April 2007 12:40:31 pm Andrey Chernov wrote:
> On Mon, Apr 30, 2007 at 12:29:20PM -0400, John Baldwin wrote:
> > Have you coordinated at all with the guy on current@ who has patches to
make
> > setenv(3) not leak memory as bad?
>
> No, I don't touch current allocation scheme at al
On Mon, Apr 30, 2007 at 12:54:45PM -0400, John Baldwin wrote:
> Hmm, I think I see that this is orthogonal to the setenv(3) fix, but still,
> if
> one does this:
>
> char *cp = strdup("FOO=bar");
> putenv(cp);
> ...
> setenv("FOO", "baz");
cp value is undefined right her
On Monday 30 April 2007 12:29:20 pm John Baldwin wrote:
> On Monday 30 April 2007 11:16:19 am Andrey A. Chernov wrote:
> > ache2007-04-30 15:16:19 UTC
> >
> > FreeBSD src repository
> >
> > Modified files:
> > usr.sbin/sysinstall main.c
> > Log:
> > Preparing for upcoming PO
On Mon, Apr 30, 2007 at 12:29:20PM -0400, John Baldwin wrote:
> Have you coordinated at all with the guy on current@ who has patches to make
> setenv(3) not leak memory as bad?
No, I don't touch current allocation scheme at all. It isn't my goal.
> Also, given that we malloc a limited space
>
On Monday 30 April 2007 11:16:19 am Andrey A. Chernov wrote:
> ache2007-04-30 15:16:19 UTC
>
> FreeBSD src repository
>
> Modified files:
> usr.sbin/sysinstall main.c
> Log:
> Preparing for upcoming POSIXed putenv() rewrite:
> don't allow const as putenv() arg, dup it
Hav
ache2007-04-30 15:16:19 UTC
FreeBSD src repository
Modified files:
usr.sbin/sysinstall main.c
Log:
Preparing for upcoming POSIXed putenv() rewrite:
don't allow const as putenv() arg, dup it
Revision ChangesPath
1.75 +1 -1 src/usr.sbin/sysinstall/main.
42 matches
Mail list logo
