On Tue, Mar 21, 2023 at 11:39:11PM +0100, Yuri wrote:
> These have been in there for quite some time now, and every time I
> try to grep something I see this (I know about -s option, but it's
> there in opengrok and other tools output as well):
> grep: sys/contrib/openzfs/contrib/debian/openzfs-zfs
On Thu, Aug 29, 2013 at 06:02:06PM +0100, David Chisnall wrote:
> rather busy organising the DevSummit. The notes for the sessions will
> be posted to various mailing lists soon (and summarised for a special
> status report), but since the ports and toolchain build sessions are
> already largely u
On Fri, Sep 06, 2013 at 09:19:32PM +0100, David Chisnall wrote:
> As of r255321, we are no longer building gcc or libstdc++ as part of
> the default install on platforms where clang is cc.
I guess I missed where this was discussed.
I don't feel we should not ship 10.0 without /usr/bin/g[c+][c+].
On Tue, Sep 10, 2013 at 08:14:30PM +0200, O. Hartmann wrote:
> On Tue, 10 Sep 2013 09:24:45 -0700 John-Mark Gurney wrote:
> > But, can you tell use how you built your kernel and on what system?
> > COMPILER_TYPE should always be defined... Are you trying to build
> > a HEAD kernel on 9stable w/o
For some reason bmake is now using share/mk/ from within a source tree
instead of the installation in /usr/share/mk/:
/w/10/usr.bin/xinstall$ bmake
bmake: "/b/deo/10/share/mk/bsd.own.mk" line 444: MK_BMAKE can't be set by a
user.
I believe this is against POLA as there is no guarantee that
On Sat, Dec 15, 2012 at 11:13:26PM +0200, Alexander Motin wrote:
> On 15.12.2012 23:03, Alexander Motin wrote:
> > Sorry, it's my fault. I've tried to save some time on patch generation
> > and forgot about that change in lib/. We haven't touched user-level in
> > our work except that file. Here is
On Sat, Nov 10, 2012 at 05:46:21PM +1100, Greg 'groggy' Lehey wrote:
> On Friday, 9 November 2012 at 13:52:24 +0100, Dimitry Andric wrote:
> > Looks like yet another cpp -traditional abuse.
>
> Use or abuse? In any case, it's not the only one. In the Good Old
> Days people did things like that.
On Mon, Oct 22, 2012 at 02:53:11PM +0200, C. P. Ghost wrote:
> How about converting them to SGML and integrating them into
> the Handbook (with the caveat that they are outdated, but
> retained for archival purposes)?
I find the Handbook to not look very well due to its SGML nature and one
page pe
On Fri, Oct 19, 2012 at 04:36:18PM +0200, Ulrich Sprlein wrote:
> those roff sources have been very naughty and will be removed from the
> tree by the end of the year.
...
> Should people feel strongly about them, we might be able to move them
> over to the doc repository.
This does not seem a "RF
On Mon, Jul 02, 2012 at 10:55:57PM +0100, Simon L. B. Nielsen wrote:
> Tested patches are accepted
> (http://svnweb.freebsd.org/base/svnadmin/tools/export.py), or even better -
> work on killing off CVS sooner rather than later.
I like the latter. :-)
As we discussed at BSDcan -- I don't use CVS
On Sun, Jul 01, 2012 at 11:14:45AM +0100, Simon L. B. Nielsen wrote:
> On 1 Jul 2012, at 10:20, Bjoern A. Zeeb wrote:
> > Just FYI,
> >
> > the svn2cvs exporter is currently down due to
> > http://svn.freebsd.org/changeset/base/237860 .
> > I'll fix it as soon as I get back from lunch, so should b
On Tue, Apr 24, 2012 at 09:34:58PM +0300, Vladimir Sharun wrote:
> ===> usr.bin/file (all)
...
> file.o: In function `main':
> /usr/src/usr.bin/file/../../contrib/file/file.c:(.text+0x717): undefined
> reference to `magic_getpath'
> /usr/src/usr.bin/file/../../contrib/file/file.c:(.text+0x7df): und
On Sat, Apr 28, 2012 at 11:03:17AM +0100, Bob Bishop wrote:
> Yes. You to have a statically linked /rescue/sh on board, so what's the
> point of /bin/sh being dynamic?
While you and I agree on this, the primary reason we went with a
dynamically linked root was for PAM and NSS support -- which are
On Thu, Apr 26, 2012 at 07:52:01AM -0400, John Baldwin wrote:
> You could use /rescue/sh as your single-user shell. Of course, that would
> perhaps let you still be able to recompile things if you had a static
> toolchain. :)
Having the toolchain static has saved me in exactly this way.
--
-
On Thu, Apr 26, 2012 at 12:38:03PM +0100, Bob Bishop wrote:
> > Apparently, current dependencies are much more spread, e.g. /bin/sh
> > is dynamically linked [etc]
>
> That seems like a bad mistake, because it would prevent even booting
> single-user if rtld/libraries are broken.
When one enters
On Fri, Apr 27, 2012 at 02:05:37PM +0200, Jan Sieka wrote:
> --- a/lib/libmagic/Makefile
> +++ b/lib/libmagic/Makefile
> @@ -10,9 +10,16 @@ DPADD= ${LIBZ}
> LDADD= -lz
> MAN= libmagic.3 magic.5
>
> +HOSTOSRELDATE!= echo ${VERSION} | cut -d " " -f 4
$ cd lib/libmagic
$ ma
On Sun, Apr 22, 2012 at 09:06:18AM -0700, Garrett Cooper wrote:
> >>> On 4/20/2012 5:16 AM, Jan Sieka wrote:
> I can't build world from recent sources (HEAD as of 2012.04.19 11:06:48
> UTC) on a machine running FreeBSD 7.3.
...
> Ugh. The usecase (that's now broken) is that Jan from Semih
On Fri, Apr 20, 2012 at 02:13:32PM -0700, Pedro Giffuni wrote:
> Easier said than done. Feel free to give libedit a try.
That has nothing to do with our process and everything to do with us
blindly hacking away pissing all over to be our own thing -- BUT still
wanting to take work from the origina
On Thu, Apr 12, 2012 at 01:19:56PM -0700, Jason Evans wrote:
> On Apr 12, 2012, at 11:41 AM, David O'Brien wrote:
> > On Wed, Apr 04, 2012 at 09:56:45PM -0700, Jason Evans wrote:
> >> I have the current version of jemalloc integrated into libc as
> >>
On Wed, Apr 04, 2012 at 09:56:45PM -0700, Jason Evans wrote:
> I have the current version of jemalloc integrated into libc as
> contrib/jemalloc:
> http://people.freebsd.org/~jasone/patches/jemalloc_20120404b.patch
Looking at the latest patch
http://people.freebsd.org/~jasone/patches/jemall
On Fri, Dec 02, 2011 at 12:57:20PM +0700, Max Khon wrote:
> On Fri, Dec 2, 2011 at 8:55 AM, David O'Brien wrote:
> If you go with (2) above, we'll still have *tons* of ports that want a
> > libreadline, so we'll just end up growing a port of it and we'll wind
On Fri, Dec 02, 2011 at 11:56:31AM +0700, Max Khon wrote:
> You still failed to name a single compelling reason to leave profiled
> libs even in -CURRENT.
Sorry Joe, I don't think your reasoning is compelling.
I'm sure you know how to stick "NO_PROFILE=true" in your /etc/src.conf.
How far do you
On Thu, Dec 01, 2011 at 08:41:12PM -0600, Brooks Davis wrote:
> On Thu, Dec 01, 2011 at 05:55:37PM -0800, David O'Brien wrote:
> > On Tue, Nov 29, 2011 at 12:02:23PM +0700, Max Khon wrote:
> > > It is possible to build and link our in-tree gdb & friends with libedit
>
On Fri, Nov 25, 2011 at 08:01:37PM +0100, Baptiste Daroussin wrote:
> and last: upgrade flex to the latest upstream version (it will need the m4
> upgrade) while here I'll move back flex to contrib/
> patches can be found there:
> http://people.freebsd.org/~bapt/flex-update.diff
Hi Baptiste,
I ca
On Tue, Nov 29, 2011 at 12:02:23PM +0700, Max Khon wrote:
> It is possible to build and link our in-tree gdb & friends with libedit
> after r228114.
> The remaining question is what to do with libreadline:
> 1) just build & link gdb with libedit
> OR
> 2) re-import libreadline from gdb sources and
On Mon, Nov 28, 2011 at 05:38:20PM +0700, Max Khon wrote:
> I would like to disable building profiled libraries by default. Opinions?
On Tue, Nov 29, 2011 at 07:46:17PM +, Max Khon wrote:
> Author: fjoe
> Date: Tue Nov 29 19:46:17 2011
> New Revision: 228143
> URL: http://svn.freebsd.org/chang
On Tue, Nov 29, 2011 at 04:46:30PM +0700, Max Khon wrote:
> This is a separate issue that I want to handle separately.
I see no value in handling it separately. I either have a libreadline on
my system or I don't.
Again, "what problem are you trying to solve"?
> The question is what to do with
On Thu, Dec 01, 2011 at 11:35:50AM -0800, Matt Mullins wrote:
> On Thu, Dec 1, 2011 at 3:28 AM, Alexander Best wrote:
> > implement a new -N switch or so which isn't based on a file's
> > existance, but a file's checksum.
>
> You can always use net/rsync, which does by default compare checksums.
On Thu, Dec 01, 2011 at 10:04:08AM -0500, John Baldwin wrote:
> I think this is useful, perhaps send it to harti@ or jilles@ for review?
I'd like to get some NetBSD bmake maintainers POV too.
We should reduce the needless diversion between the two makes.
--
-- David (obr...@freebsd.org)
___
On Wed, Nov 30, 2011 at 05:59:33PM -0800, Garrett Cooper wrote:
> On Wed, Nov 30, 2011 at 5:43 PM, Alexander Best wrote:
> > On Wed Nov 30 11, Garrett Cooper wrote:
> >> On Wed, Nov 30, 2011 at 4:25 PM, Alexander Best
> >> wrote:
> >> ? ? pmake sucks as far as diagnostic output is concerned when
On Mon, Sep 26, 2011 at 07:48:23PM -0400, Benjamin Kaduk wrote:
> My recollection is that this is because kensmith forgot to take
> 'makeoptions DEBUG=-g' out of GENERIC when branching stable/8, and no one
> noticed until a couple of releases in, at which point it seemed consistent
> with POLA t
On Fri, Sep 09, 2011 at 06:00:02PM +0300, Kostik Belousov wrote:
> --- libs/m3core/src/thread/POSIX/ThreadPosix.m3.orig 2011-09-09
> 17:58:12.867431639 +0300
> +++ libs/m3core/src/thread/POSIX/ThreadPosix.m3 2011-09-09
> 17:58:30.380428486 +0300
> @@ -180,7 +180,7 @@
>pausedThreads : T
Hi KIB,
Thanks for the list of issues you know about -- I don't believe we have
PRs covering those.
On Thu, Jun 23, 2011 at 11:21:53PM +0300, Kostik Belousov wrote:
> - I believe Peter Holm has more test cases that fails with tmpfs. He
> would have more details. I somewhat remember some panic on
Does anyone object to this patch?
David Wolfskill and I have run TMPFS on a number of machines for two
years with no problems.
I may have missed something, but I'm not aware of any serious PRs on
TMPFS either.
Index: tmpfs_vfsops.c
===
Feb 24 19:43:16 : FreeBSD 9.0-CURRENT #662 r218815:218845M: Tue Feb 22 00:13:31
PST 2011
Feb 24 19:43:16 : /sys/i386/compile/DRAGON i386
[..]
Mar 5 14:41:38 : start = 0, len = 1659, fs = /storage
Mar 5 14:41:38 : panic: ffs_alloccg: map corrupted
Mar 5 14:41:38 : cpuid = 0
Mar 5 14:41:38 : KDB
On Thu, Dec 02, 2010 at 03:31:41PM -0800, Garrett Cooper wrote:
> On Thu, Dec 2, 2010 at 2:43 PM, David O'Brien wrote:
> > Thoughts?
> >
> > FreeBSD 9.0-CURRENT #654 r215604M: Sat Nov 20 19:51:27 PST 2010
> > ? ?ro...@dragon:/sys/i386/compile/DRAGON i386
> &
FreeBSD 9.0-CURRENT #654 r215604M: Sat Nov 20 19:51:27 PST 2010
ro...@dragon:/sys/i386/compile/DRAGON i386
[..]
start = 0, len = 2, fs = /jazz
panic: ffs_alloccg: map corrupted
cpuid = 2
KDB: stack backtrace:
db_trace_self_wrapper(c0839222,0,1,4,0,...) at 0xc04e9ab6 =
db_trace_self_wrapper+0x2
Thoughts?
FreeBSD 9.0-CURRENT #654 r215604M: Sat Nov 20 19:51:27 PST 2010
ro...@dragon:/sys/i386/compile/DRAGON i386
[..]
start = 0, len = 3359, fs = /files
panic: ffs_alloccg: map corrupted
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper(c0839222,a0d7365,0,c08affe0,7,...) at 0xc04e9ab6
Machine booted, without any mention of sf(4) in rc.conf or loader.conf and
without sf(4) in the core kernel. This is without WITNESS or INVARIANTS.
>From multi-user, I issued 'ifconfig sf0' and got the below panic.
These are the console messages related to this:
FreeBSD 9.0-CURRENT #654 r215604
Thoughts?
anh-thu.NUXI.org dumped core - see ./vmcore.1
Tue Nov 30 16:10:57 PST 2010
FreeBSD anh-thu.NUXI.org 9.0-CURRENT FreeBSD 9.0-CURRENT #85 r214782M: Thu Nov
4 09:13:24 PDT 2010
ro...@anh-thu.nuxi.org:/usr/src/sys/i386/compile/ANH-THU i386
panic: make_dev_credv: bad si_name (error
On Thu, Nov 11, 2010 at 02:30:59PM -0800, Pyun YongHyeon wrote:
> On Wed, Nov 10, 2010 at 04:32:54PM -0800, David O'Brien wrote:
> > Kernel page fault with the following non-sleepable locks held:
> > exclusive sleep mutex sf0 (network driver) r = 0 (0xc722b584) locked @
>
Thoughts?
Script started on Sat Nov 20 22:44:55 2010
FreeBSD 9.0-CURRENT #644 r215099M: Wed Nov 10 11:45:01 PST 2010
obr...@dragon:/usr/obj/4kib/i386/compile/DRAGON-WITNESS i386
WARNING: WITNESS option enabled, expect reduced performance.
WARNING: DIAGNOSTIC option enabled, expect reduced per
Script started on Wed Nov 10 15:56:31 2010
FreeBSD 9.0-CURRENT #644 r215099M: Wed Nov 10 11:45:01 PST 2010
obr...@dragon:/usr/obj/4kib/i386/compile/DRAGON-WITNESS i386
WARNING: WITNESS option enabled, expect reduced performance.
WARNING: DIAGNOSTIC option enabled, expect reduced performance.
[.
On Tue, Nov 09, 2010 at 10:52:23AM +0800, Randy Bush wrote:
> > Can you verify this is a 64-bit platform?
>
> i can verify that this is am64
Ok, that explains why I could not reproduce this under i386.
Please try r215027.
--
-- David (obr...@freebsd.org)
___
On Tue, Nov 09, 2010 at 08:28:27AM +0800, Randy Bush wrote:
> > On Mon, Nov 08, 2010 at 03:14:02PM +0800, Randy Bush wrote:
> >> ===> gnu/usr.bin/groff/src/preproc/eqn (all)
> >> c++ -O2 -pipe
> >> -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/preproc/eqn
> >> -
On Mon, Nov 08, 2010 at 05:11:19PM -0800, Garrett Cooper wrote:
> Tinderbox agrees :(...
TB --- 2010-11-08 23:15:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-11-08 23:15:00 - starting HEAD tinderbox run for amd64/amd64
TB --- 2010-11-08 23:15:00 - cleaning the object tree
TB
On Mon, Nov 08, 2010 at 03:14:02PM +0800, Randy Bush wrote:
> ===> gnu/usr.bin/groff/src/preproc/eqn (all)
> c++ -O2 -pipe
> -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/preproc/eqn
> -I. -DHAVE_CONFIG_H
> -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../
On Mon, Nov 08, 2010 at 03:14:02PM +0800, Randy Bush wrote:
> very current amd64
> ===> gnu/usr.bin/groff/src/preproc/eqn (all)
> c++ -O2 -pipe
> -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/preproc/eqn
> -I. -DHAVE_CONFIG_H
> -I/usr/src/gnu/usr.bin/groff/src/
On Fri, Nov 05, 2010 at 09:42:27PM -0700, Garrett Cooper wrote:
> On Fri, Nov 5, 2010 at 1:25 PM, Ulrich Sp?rlein wrote:
> > Hey folks, not sure why, but I had a stab at looking which files were
> > actually read during building world.
[..]
> > usr.bin/cpio/test/* ? ? # move to tools/regression?
On Wed, Oct 13, 2010 at 11:42:48PM +0200, Jilles Tjoelker wrote:
> Style bug:
> > +growstrstackblock(int n) {
> The opening brace should be on its own line.
Indeed. I'm surprised I did that. Thank you for catching it.
> Your test is too fragile: it often fails to detect the bug. Calling like
>
At $WORK we hit a bug where ${var%/*} was not producing the correct
expansion. There are two patches to fix this. I prefer the first
as I feel it is cleaner from an API perspective. I've also added
a regression testcase that shows the problem.
Thoughts?
--
-- David (obr...@freebsd.org)
Com
On Fri, Sep 03, 2010 at 11:34:10PM -0700, David O'Brien (@FreeBSD) wrote:
> This happens on AMD64 for me, r212166 (2010-09-02 15:37:13 -0700) kernel
> sources.
Sorry for the false alarm - this was a local environment problem.
-- David
This happens on AMD64 for me, r212166 (2010-09-02 15:37:13 -0700) kernel
sources.
But, an i386 kernel of r212166 sources boots fine on the same hardware.
Root mount waiting for: usbus6 usbus2
uhub2: 6 ports with 6 removable, self powered
uhub6: 6 ports with 6 removable, self powered
Trying to mou
On Wed, May 05, 2010 at 12:54:07PM -1000, Jeff Roberson wrote:
> On Mon, 3 May 2010, Fabien Thomas wrote:
I'm with r207548 now and since some days i've system deadlock.
It seems related to SUJ with process waiting on suspfs or ppwait.
>>>
>>> I've also seen it stalled in suspfs, but this
On Fri, Mar 12, 2010 at 12:50:32PM -0700, M. Warner Losh wrote:
> : On Thu, Mar 11, 2010 at 07:24:23PM -0700, M. Warner Losh wrote:
> So the issue isn't as cut and dried as you might think. There's
> multiple different conventions used here in addition to your simple
> example.
I guess we'd have
On Mon, Mar 15, 2010 at 09:00:18AM -0700, Julian Elischer wrote:
> I certainly agree.. can it be changed please?
I've waited a while to see what other opinions would be expressed on this
topic. I believe there is sufficient support to rename COMPAT_FREEBSD32
to something else based on responses i
On Sat, Mar 13, 2010 at 09:13:03PM -0700, M. Warner Losh wrote:
> The Makefile already knows where the kernel src is located. Let's use
> that knowledge to make things a little simpler. This also uses the
> Makefile variable SYSDIR. It should also work with non-standard sys
> directories.
..
> I
On Mon, Mar 15, 2010 at 08:44:26AM -0600, M. Warner Losh wrote:
> In message: <20100315142806.ga5...@dragon.nuxi.org>
> "David O'Brien" writes:
> : On Sat, Mar 13, 2010 at 09:13:03PM -0700, M. Warner Losh wrote:
> : > In message: <
On Sat, Mar 13, 2010 at 09:13:03PM -0700, M. Warner Losh wrote:
> In message: <20100312171206.ga31...@dragon.nuxi.org>
> "David O'Brien" writes:
> : * Simplify SRCDIR calculation by directly finding the kernel sources
> : based directly on
On Thu, Mar 11, 2010 at 08:54:32PM -0700, Scott Long wrote:
> On Mar 11, 2010, at 6:14 PM, Scot Hetzel wrote:
> > On Thu, Mar 11, 2010 at 10:36 AM, Mike Jakubik
> > wrote:
> >> On 3/11/2010 9:50 AM, Nathan Whitehorn wrote:
> >>>
> >>> As a result of importing 32-bit compatibility support for non-
On Thu, Mar 11, 2010 at 07:24:23PM -0700, M. Warner Losh wrote:
> In message: <7d6fde3d1003111720g7dccf93w1f51db88758a5...@mail.gmail.com>
> Garrett Cooper writes:
> : On Thu, Mar 11, 2010 at 5:14 PM, Scot Hetzel wrote:
> : > On Thu, Mar 11, 2010 at 10:36 AM, Mike Jakubik
> : > wrote
* Simplify SRCDIR calculation by directly finding the kernel sources
based directly on one of them.
Reviewed by: dhw
This change does not increase the kernel build time. It also continues
to restrict the revision to just the kernel sources, and not the whole
tree.
Timing tests by: dhw
Details at
http://trang.nuxi.org:8080/panics/DSC_0010.JPG
Kernel sources at r203083 are stable for me.
Unfortunately, I cannot get a dump for this.
--
-- David (obr...@freebsd.org)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org
Details at
http://trang.nuxi.org:8080/panics/DSC_0070.JPG
Kernel sources at r203083 are stable for me.
Unfortunately, I cannot get a dump for this.
--
-- David (obr...@freebsd.org)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org
On Sun, Mar 07, 2010 at 08:51:22PM +, Robert Watson wrote:
> On Sat, 6 Mar 2010, David O'Brien wrote:
>> No, not it isn't. Provide a script to convert path's in the diff. This is
>> what $LARGE_FREEBSD_USER did when it rearranged it source tree.
>>
>
On Sun, Mar 07, 2010 at 02:49:04PM -0700, M. Warner Losh wrote:
> In message: <20100307054423.ge70...@dragon.nuxi.org>
> "David O'Brien" writes:
> : On Fri, Mar 05, 2010 at 09:41:40AM +, Robert Watson wrote:
> : > On Fri, 5 Mar 2010, Poul-H
On Fri, Mar 05, 2010 at 09:41:40AM +, Robert Watson wrote:
> On Fri, 5 Mar 2010, Poul-Henning Kamp wrote:
>> In message , Robert
>> Watso n writes:
>>> Doing that kind of rearrangement [...] would be a nightmare for anyone
>>> with large [...] patches, so I'd say we could pretty much rule tha
On Fri, Mar 05, 2010 at 12:01:30PM +0100, Svein Skogen (Listmail Account) wrote:
> Oh, so because a lot of the programmers behind it receive wages, and the
> project itself won't commit ritual suicide by basically blocking the
> companies using FreeBSD from returning improvements they make to the
>
On Sat, Mar 06, 2010 at 01:28:24AM -0800, Garrett Cooper wrote:
> FWIW, NetBSD's charter has been to run their OS on a number of
> architectures, not just a primary set of architectures; OpenBSD's
> charter differs -- if we all were NetBSD or OpenBSD, then we'd all be
> using the same thing. B
On Fri, Mar 05, 2010 at 11:16:41AM +, Doug Rabson wrote:
> I think you misunderstand. Some of us old-timers have been having this
> discussion repeatedly for well over ten years. It always ends up the same
> way - a re-org might make the source tree marginally prettier but the
> consequences fo
Ever since kerberos5 got hooked up to the build by default I'm getting
*TONS* (758) of CPP macros. An example is:
In file included from /usr/obj/usr/src/kerberos5/lib/libasn1/roken.h:77,
from /usr/src/crypto/heimdal/lib/vers/print_version.c:38:
/usr/src/crypto/heimdal/lib/roken/r
On Sun, Nov 30, 2003 at 09:27:03PM -0800, Sean McNeil wrote:
> Also, I do not see any reason why bash should remain linked -static
> for -current.
Lucky for me (who wants a static Bash), I don't have to make the
decission -- ports are frozen and have been for a while.
_
On Sun, Nov 30, 2003 at 11:47:24PM -0500, Robert Watson wrote:
> On Mon, 1 Dec 2003, Maxim M. Kazachek wrote:
> > On Sun, 30 Nov 2003, Richard Coleman wrote:
..snip..
> For 5.2-CURRENT, I think we should revisit this issue with one of the
> following conclusions winning out, and the rest being disc
On Sat, Nov 29, 2003 at 01:36:03AM +0100, Dag-Erling Sm?rgrav wrote:
> Kris Kennaway <[EMAIL PROTECTED]> writes:
> > On Thu, Nov 27, 2003 at 01:02:18PM +0400, rihad wrote:
> > > CFLAGS= -O2 -pipe
> > > I'll try to build it without -O2, thanks.
> > *sigh*, I see we need more figlet in the documentat
On Fri, Nov 28, 2003 at 09:17:39PM +0100, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Tim Kientzle writes:
> >David O'Brien wrote:
> >> On Wed, Nov 26, 2003 at 10:37:48AM -0800, Tim Kientzle wrote:
> >>>and [/usr/bin/ftp] doesn't
On Wed, Nov 26, 2003 at 10:16:37AM -0600, Matthew D. Fuller wrote:
> The advantage of this method is it's simple, cheap, automatic, and lets
> us say "You can try setting ADDITIONAL_RESCUE=usr.sbin/foo in make.conf
> and it may work",
Please send a tested patch for this. :-)
If ADDITIONAL_RESCUE
On Tue, Nov 25, 2003 at 09:14:10PM -0700, M. Warner Losh wrote:
> We recommend
>
> make buildworld
> make buildkernel
> make installkernel
> reboot -s -> single user
> make installworld
"make buildkernel ; make installkernel" can be shortened to just
"make kernel".
___
On Mon, Nov 24, 2003 at 03:48:57PM -0800, Tim Kientzle wrote:
> >>... I think [/rescue] only needs to support those
> >>recovery actions necessary to repair /bin and /sbin if they break.
> >
> >My stance is that no failure mode needs to
> >be repairable that wasn't repairable with a static /.
>
>
On Tue, Nov 25, 2003 at 03:07:55PM +1030, Daniel O'Connor wrote:
> What about the newer version of gcc? That is considerably slower than
> previous versions, but I don't see people screaming to have it removed.
Uh... you must not know what you are talking about. GCC *COMPILES*
slower as it does a
On Wed, Nov 26, 2003 at 02:00:08AM +0100, Matthias Andree wrote:
> As a user, I like /rescue better than the step-child that /stand/* used
> to be. It's part of the world, which /stand wasn't.
Except that we still have /stand. It should be shot, but some won't let
it go...
___
On Mon, Nov 24, 2003 at 06:27:13PM -0800, Tim Kientzle wrote:
> The debate right now is over what programs from /usr/bin and
> /usr/sbin should be included. Right now, that includes
> tar, gzip, bzip2, and vi/ex.
All but vi(ex) were built statically, but installed into /usr/bin.
--
-- David (
On Mon, Nov 24, 2003 at 07:19:31PM -0700, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Andrew Gallatin <[EMAIL PROTECTED]> writes:
> :
> : M. Warner Losh writes:
> : > In message: <[EMAIL PROTECTED]>
> : > Andrew Gallatin <[EMAIL PROTECTED]> writes:
> : > :
On Mon, Nov 24, 2003 at 04:07:49PM -0500, Michael Edenfield wrote:
> > I doubt there is any perfect answer which will satisfy
> > everyone, but perhaps we can recognize that and figure out
> > some flexible middle ground.
>
> Would it be possible, through some make.conf magic, for the end-user to
On Mon, Nov 24, 2003 at 12:08:58PM -0800, Tim Kientzle wrote:
> Contrary to what David claims, I don't think /rescue does need
> to support all of the recovery actions that a static /s?bin
> would support. Rather, I think it only needs to support those
> recovery actions necessary to repair /bin a
On Mon, Nov 24, 2003 at 10:47:24AM -0500, Robert Watson wrote:
> It strikes me that this whole conversation has gotten a little
> confrontational... The "middle ground" of adding a static /sbin/sh for
> scripts soudds like a reasonable choice, and has precedent in other
> systems (Solaris).
Time
On Mon, Nov 24, 2003 at 11:46:54AM -0500, Garrett Wollman wrote:
> < said:
> > We have made the assumption for the first three options since day one.
> > Why should we change the assumptions just because we now have a dynamic
> > /?
>
> Because we are not all masochists.
Why wasn't it enough of a
[ From: set to /dev/null as too many can't follow the Reply-To: ]
On Mon, Nov 24, 2003 at 11:00:24AM -0500, Rahul Siddharthan wrote:
> > NO. /rescue was allowed in the system to handle the case of a trashed
> > file in /lib[exec]. To allow a sysadmin to recover a system from the
> > same type of
On Sun, Nov 23, 2003 at 06:00:36PM -0800, Tim Kientzle wrote:
> Scenarios that require /rescue are ones in which /bin and /sbin
> are unusable, which is almost always going to imply a trashed file
> in /bin, /sbin, or /lib. Thus, most /rescue scenarios are going to
> involve locating a good copy o
On Sun, Nov 23, 2003 at 06:27:01PM -0500, Richard Coleman wrote:
> But it would be sorta odd to have statically linked versions of sh in
> both /bin and /rescue.
We'd remove it from /rescue if the /bin/sh one was static. :-)
--
-- David ([EMAIL PROTECTED])
On Mon, Nov 24, 2003 at 12:14:39AM -, Duncan Barclay wrote:
>
> From: "David O'Brien" <[EMAIL PROTECTED]>
>
> > I'll seriously argue against the 2nd point above. I don't know of a
> > SINGLE person that uses /bin/sh as their interactiv
> As I pointed out earlier, some of the heat here comes
> from the fact that /bin/sh is currently overloaded:
>
> * It is the default system script interpreter, used
>by the rc scripts and many other things. As such,
>it must start quickly.
>
> * It is the default user shell for many use
On Sun, Nov 23, 2003 at 02:42:58AM +0100, Brad Knowles wrote:
> At 5:22 PM -0800 2003/11/22, David O'Brien wrote:
>
> > Please, NO. There wasn't an FTP client available for this type of
> > recovery pre-/rescue, there shouldn't be one now.
>
> Wh
On Fri, Nov 21, 2003 at 02:11:30PM -0800, Tim Kientzle wrote:
> >Thanks to /rescue and the live filesystem archives on
> >current.freebsd.org, I was able to recover
> >... I could have used the ftp client (or fetch) in /rescue :-)
>
> Yes, fetch would be useful. I imagine a lot of people
>
On Fri, Nov 21, 2003 at 03:33:51PM -0600, Guy Helmer wrote:
> Tim Kientzle wrote:
> > Guy Helmer wrote:
> > > Thanks to /rescue and the live filesystem archives on
> > > current.freebsd.org, I was able to recover a machine
> > > that I hosed after the statfs change by trying to installworld
> > > w
On Mon, Nov 17, 2003 at 10:12:03AM -0800, David O'Brien wrote:
> The kernel changes of the past week has totally turned my AMD64 machine
> that I use in 32-bit mode running FreeBSD/i386 (GENERIC):
>
> OK boot -v
> cpuid = 0; apic id = 00
> instruction pointer = 0x
The kernel changes of the past week has totally turned my AMD64 machine
that I use in 32-bit mode running FreeBSD/i386 (GENERIC):
OK boot -v
cpuid = 0; apic id = 00
instruction pointer = 0x0:0xa00
stack pointer = 0x0:0xffe
frame pointer = 0x0:0x0
code segment= b
On Mon, Nov 17, 2003 at 01:51:53AM -0800, Peter Wemm wrote:
> sledge.freebsd.org is now running in SMP, as is the loaner 4-way Opteron
> that I have for testing.
Now that you've got all 4 CPU's spinning up, producing maxium BTU's,
aren't you glad I brought you that new useful space header for wint
On Sun, Nov 16, 2003 at 11:37:47PM -0500, Bill Vermillion wrote:
> > > > 1) Much smaller /bin and /sbin. On i386, /bin and /sbin are 33 MB
> > > > static.
> > > >Dynamically linked, they are only 4 MB.
>
> I don't think saving that little space on the / partition is as
> important as having e
# cd /usr/src ; cvs -qR up -PdA
...
U sys/netgraph/bluetooth/include/ng_btsocket_hci_raw.h
U sys/netgraph/bluetooth/include/ng_btsocket_l2cap.h
U sys/netgraph/bluetooth/include/ng_btsocket_rfcomm.h
panic: Assertion td->td_turnstile != NULL failed at
../../../kern/subr_turnstile.c:427
cpuid = 1;
pa
On Sat, Nov 15, 2003 at 03:16:03PM -0800, Marcel Moolenaar wrote:
> Provided that we
> 2. replace the date with a convenient sequence number, which we can
>call the minor version number, and
..
> E.g.: libc.so.6.0, libc.so.6.1, and (first release) libc.so.6.2...
Please no -- it wouldn't be ea
1 - 100 of 1694 matches
Mail list logo
