Re: GSoC:Complete Package support in the pkg_install tools and cleanup

2010-05-05 Thread Wesley Shields
On Tue, May 04, 2010 at 10:30:13AM -0700, Julien Laffaye wrote:
> On Tue, May 4, 2010 at 3:15 AM, Andrew Brampton
>  wrote:
> >
> > Hi Julien,
> >
> > Glad you got onto the GSoC programme. I'm curious, what benefit is a
> > complete package over many individual ones?
> 
> Hi Andrew,
> 
> If you cant or dont want to use the remote feature of of pkg_add (ex.
> your packages are built with non default options and you think its
> overkill to setup a server to distribute them) then you make a
> complete package. You only have to copy one file (say on an usb
> device), which is less error prone than 150 files.
> The global idea is to write a meta port which depends on the desired
> ports, type `make complete-package`, copy the output file on the
> machine to bootstrap, pkg_add /path/to/complete-pkg and voila!

Do you intend to add the "complete-package" target also or is that out
of scope?

-- WXS
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


Re: regenerating /var/db/pkg

2010-04-23 Thread Wesley Shields
On Thu, Apr 22, 2010 at 08:56:39AM -0500, Dan Rue wrote:
> On Thu, Apr 22, 2010 at 03:21:16PM +0300, Eitan Adler wrote:
> > >
> > > Just asking opinions, if people want this, I'll make a patch and
> > > file a PR.
> > >
> > 
> > Is this script correct?
> 
> We're starting to use SSDs for boot drives in our freebsd boxes.  We'd
> like to have /var on a memory backed FS, but losing the package database
> on every reboot is troublesome.  
> 
> This script would be a decent solution to my problem as well, 

You can look into how NanoBSD does things if you want to go this route.

-- WXS
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


Re: Something rotten in ports (was Re: package building failure irritation)

2010-03-14 Thread Wesley Shields
On Sat, Mar 13, 2010 at 08:40:32PM -0500, jhell wrote:
> Rather simple way to go about creating final packages and from some 
> earlier emails to the list there was word of some directories not being 
> included in final built packages due to empty directories or something 
> like that so be careful when/if considering something like this.

I believe you are talking about ports/144164 which was about RC scripts
not being included in a package when using package-noinstall. This is
currently in the hands of portmgr. It will have to wait until 7.3 is
out, at the earliest.

-- WXS
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


Re: (Ab)using rcng's features to keep rc.d-style services running should they fail.

2009-10-05 Thread Wesley Shields
On Sun, Oct 04, 2009 at 12:30:55PM -0700, Doug Barton wrote:
> Alex Trull wrote:
> > Hi all,
> > 
> > I realised that because portupgrade/portmaster don't always 
> > cleanly restart processes that have died due to being 
> > upgraded (mysqld, often!) that this was something I wanted 
> > to fix.
> 
> I can't speak to portupgrade, however for portmaster there is no such
> facility whatsoever. The admin is expected to disable things prior to
> an upgrade and re-enable them when the upgrade is done. I don't feel
> that this is an overwhelming burden. :)

There is the @stopdaemon directive in plists (which gets translated into
@unexec to forcestop the script). Some ports use it and some do not.
Personally I think ports doing this automatically are quite annoying,
and would love to rip them all out from the ports. Something like
portmaster growing support for it would be welcome provided it does not
happen by default.

I've always found it funny that there is no @startdaemon directive
(rightfully so, as we want people to explicitly turn things on) but it's
acceptable if things get turned off via @stopdaemon without explicit
permission. If a particular upgrade requires that the thing be not
running we should check for that and abort, not go shutting things down.

-- WXS
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


Re: 256-byte inode support

2008-09-09 Thread Wesley Shields
On Tue, Sep 09, 2008 at 03:37:47PM +0300, Kostik Belousov wrote:
> On Tue, Sep 09, 2008 at 08:29:17AM -0400, Wesley Shields wrote:
> > On Tue, Sep 09, 2008 at 02:53:51PM +0300, Kostik Belousov wrote:
> > > On Sun, Sep 07, 2008 at 11:07:47AM -0400, Wesley Shields wrote:
> > > > On Sat, Sep 06, 2008 at 07:26:27PM -0400, jT wrote:
> > > > > hackers,
> > > > > 
> > > > > since tytso had updated ext3 -- i've noticed that i can't use my
> > > > > 265-byte inode ext3 drives -- is there any effort to update it?  If
> > > > > not -- if you know where i should attempt to start please let me know
> > > > > so i can start working on support (i have a few other people i know
> > > > > interested in this) -- thanks and hope everyone is well
> > > > 
> > > > There was a PR submitted for it and eventually a patch added to the PR.
> > > > I've tested the patch given in the URL at the port and it works.  We
> > > > will start to see more of this as the newer version becomes more common
> > > > in the wild.
> > > > 
> > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/124621
> > > > 
> > > > Would be nice to see this fixed in 7.1 but it may be too late for that.
> > > 
> > > What was the reason for increasing inode size ? I think it is rather
> > > pointless to increase the size without using newly added space for some
> > > data. Is inode format the same for the first 128 bytes, and does data
> > > at the second 128 bytes should be used to correctly interpret inode ?
> > 
> > I honestly don't know the answer.  Though I do agree that it is
> > pointless to increase the size without using the new space.
> > 
> > All I know is that I was unable to read an ext filesystem made with -I
> > 256 (which is the default when using the most recent
> > sysutils/e2fsprogs).
> 
> I think it is too dangerous for the user data to commit this patch,
> without investigating this first.

I think that's a fair assessment to make.  The patch is certainly simple
enough but I'm not familiar with what it's doing to make an accurate
assessment.  I know it worked for the simple test case I provided in my
previous message.  If I can be of any further assistance please let me
know.

-- WXS
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: 256-byte inode support

2008-09-09 Thread Wesley Shields
On Tue, Sep 09, 2008 at 02:53:51PM +0300, Kostik Belousov wrote:
> On Sun, Sep 07, 2008 at 11:07:47AM -0400, Wesley Shields wrote:
> > On Sat, Sep 06, 2008 at 07:26:27PM -0400, jT wrote:
> > > hackers,
> > > 
> > > since tytso had updated ext3 -- i've noticed that i can't use my
> > > 265-byte inode ext3 drives -- is there any effort to update it?  If
> > > not -- if you know where i should attempt to start please let me know
> > > so i can start working on support (i have a few other people i know
> > > interested in this) -- thanks and hope everyone is well
> > 
> > There was a PR submitted for it and eventually a patch added to the PR.
> > I've tested the patch given in the URL at the port and it works.  We
> > will start to see more of this as the newer version becomes more common
> > in the wild.
> > 
> > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/124621
> > 
> > Would be nice to see this fixed in 7.1 but it may be too late for that.
> 
> What was the reason for increasing inode size ? I think it is rather
> pointless to increase the size without using newly added space for some
> data. Is inode format the same for the first 128 bytes, and does data
> at the second 128 bytes should be used to correctly interpret inode ?

I honestly don't know the answer.  Though I do agree that it is
pointless to increase the size without using the new space.

All I know is that I was unable to read an ext filesystem made with -I
256 (which is the default when using the most recent
sysutils/e2fsprogs).

[EMAIL PROTECTED] ~ % truncate -s 1G ext-128
[EMAIL PROTECTED] ~ % truncate -s 1G ext-256
[EMAIL PROTECTED] ~ % sudo mdconfig -a -t vnode -f ext-128 -s 1G
md0
[EMAIL PROTECTED] ~ % sudo mdconfig -a -t vnode -f ext-256 -s 1G
md1
[EMAIL PROTECTED] ~ % sudo kldload ext2fs
[EMAIL PROTECTED] ~ % mke2fs -I 128 /dev/md0
mke2fs 1.41.0 (10-Jul-2008)
mke2fs: Permission denied while trying to determine filesystem size
[EMAIL PROTECTED] ~ % sudo mke2fs -I 128 /dev/md0
mke2fs 1.41.0 (10-Jul-2008)
Filesystem label=
OS type: FreeBSD
Block size=4096 (log=2)
Fragment size=4096 (log=2)
65536 inodes, 262144 blocks
13107 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=268435456
8 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
32768, 98304, 163840, 229376

Writing inode tables: done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 27 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
[EMAIL PROTECTED] ~ % sudo mke2fs /dev/md1
mke2fs 1.41.0 (10-Jul-2008)
Filesystem label=
OS type: FreeBSD
Block size=4096 (log=2)
Fragment size=4096 (log=2)
65536 inodes, 262144 blocks
13107 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=268435456
8 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376

Writing inode tables: done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 37 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
[EMAIL PROTECTED] ~ % sudo mount -t ext2fs /dev/md0 /mnt/ext2-128 
[EMAIL PROTECTED] ~ % sudo mount -t ext2fs /dev/md1 /mnt/ext2-256 
[EMAIL PROTECTED] ~ % ls /mnt/ext2-128 
lost+found/
[EMAIL PROTECTED] ~ % ls /mnt/ext2-256
ls: /mnt/ext2-256: Bad file descriptor
[EMAIL PROTECTED] ~ % 

-- WXS
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: 256-byte inode support

2008-09-07 Thread Wesley Shields
On Sat, Sep 06, 2008 at 07:26:27PM -0400, jT wrote:
> hackers,
> 
> since tytso had updated ext3 -- i've noticed that i can't use my
> 265-byte inode ext3 drives -- is there any effort to update it?  If
> not -- if you know where i should attempt to start please let me know
> so i can start working on support (i have a few other people i know
> interested in this) -- thanks and hope everyone is well

There was a PR submitted for it and eventually a patch added to the PR.
I've tested the patch given in the URL at the port and it works.  We
will start to see more of this as the newer version becomes more common
in the wild.

http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/124621

Would be nice to see this fixed in 7.1 but it may be too late for that.

-- WXS
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: zpool scrub tank && high file system activity caused crash

2008-03-24 Thread Wesley Shields
On Mon, Mar 24, 2008 at 04:23:19PM -0700, Bert JW Regeer wrote:
> Hey guys,
> 
> I am running FreeBSD 7.0-RELEASE with GENERIC on a AMD XP Athlon 3500+ with 
> 1267 MB of ram, and a GigBit NIC. I am testing out ZFS just for the hell of 
> it, I know, 32 bit is not suggested and runs badly, but it does what it 
> needs to do.
> 
> I was copying large amounts of data for backup purposes from my MacBook Pro 
> to the machine over FTP. At the time I was looking around the man page for 
> zpool, and figured I'd run a zpool scrub just to see how badly it affects 
> performance. It affects it in that it takes down the machine with a dump.
> 
> keyhole# kgdb kernel.debug /var/crash/vmcore.0
> [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: 
> Undefined symbol "ps_pglobal_lookup"]
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you 
> are
> welcome to change it and/or distribute copies of it under certain 
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-marcel-freebsd".
> 
> Unread portion of the kernel message buffer:
> panic: vm_page_insert: offset already allocated
> cpuid = 0
> Uptime: 10h58m58s
> Physical memory: 1267 MB
> Dumping 335 MB: 320 304 288 272 256 240 224 208 192 176 160 144 128 112 96 
> 80 64 48 32 16

Out of curiosity, have you done any tuning on this machine?
Specifically some of the stuff mentioned on the wiki?

-- WXS
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Network Throughput between jail and base system

2008-03-07 Thread Wesley Shields
On Fri, Mar 07, 2008 at 12:13:04AM +0200, Stefan Lambrev wrote:
> Greetings,
> 
> 
> Ilias Marinos wrote:
> > Hello all,
> > I have a jail to my FreeBSD-STABLE, in which I run some
> >   
> uname -a will be more helpful then "FreeBSD-STABLE".
> > services.I have configured and setup this jail using ezjail-admin.
> > [EMAIL PROTECTED]:~$ jls
> >JID  IP Address  Hostname  Path
> >  1  192.168.1.100   ws/usr/jails/ws
> > /usr/jails/ws
> >
> > #Jails
> > ezjail_enable="YES"
> > ifconfig_lo1="192.168.1.100 netmask 0x" # Jail iface
> >
> > I use lo1 as jail interface and I nat internet traffic to it with pf:
> > nat on $ext_if from $ws to any -> ($ext_if)
> >
> > Today I 've tried to scp a big directory inside the jail and
> > I've noticed that I was secure copying with 2-3MB/s .That sounds too
> > weird for me and I would like to hear some opinions , for what it may be
> > the problem.
> >
> >   
> You should investigate where the bottle-neck is. It's probably not in
> the network protocol.
> Most probably it is limitation of your CPU or your HDD(s).
> I think (not sure) jail have default limit to % of the CPU resources, so
> if you encrypt the stream
> most probably the limitation is in the CPU.
> You can check http://wiki.freebsd.org/JailResourceLimits for more
> information.

Based upon that wiki page I'm led to believe that this is not in any
branch of FreeBSD yet.  That is, it's not in CVS.

-- WXS
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: FreeBSD hacker 101

2008-01-24 Thread Wesley Shields
On Thu, Jan 24, 2008 at 11:11:05PM +0800, william wong wrote:
> 2008/1/24, Dag-Erling Sm?rgrav <[EMAIL PROTECTED]>:
> > "william wong" <[EMAIL PROTECTED]> writes:
> > > Thanks for enlightening me on different aspects. Actually I found there 
> > > are
> > > many exciting network stack projects/overhaul happening in FreeBSD 8. I 
> > > just
> > > want to gear up myself and see what I can do. I have got 6.3 installed and
> > > tweaking some of the kernel modification and compilation process so that i
> > > can get myself acquainted to the software development process.
> >
> > You should really, really upgrade to 7.  Nobody is doing any serious
> > work on 6 (beyond merging bug fixes back from 7); all the exciting work
> > happens in 8, and kernel patches against 8 will very rarely apply
> > cleanly to 6.
> >
> > > It seems that Juniper favors the even number FreeBSD's.
> >
> > Only because 5 was a dog.  They probably stuck with 4 for a while, then
> > switched to 6 once they had ascertained that it was significantly more
> > stable than 5.  I would be surprised if they skipped 7.
> 
> Please pardon my ignorance of the jargons. Does that mean 5 is not
> stable or does not perform or what?

STABLE in this context is a bit of a misnomer.  What it's talking about
is not stability in the sense of "it doesn't crash as much as current"
but stability in the ABI sense.  This is often a cause of confusion for
people new to FreeBSD.

While it is generally true that stable does not crash as much as
current, it is not a promise.  There have been times when a stable 
branch would not build or has serious bugs in it.  However, it is my
experience that these are rare (even in current), and the developers do
their best to ensure they don't happen.

-- WXS
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Updated procstat(1)

2007-11-27 Thread Wesley Shields
On Tue, Nov 27, 2007 at 05:18:47PM +, Robert Watson wrote:
> The last of these required new kernel changes, including an MD component. 
> I've tested the MD parts only on i386, although I have quick hacks at what 
> they should look like on amd64, arm, powerpc, sparc64, sun4v.  I don't 
> promise these compile or work, but they might do.

The kernel build didn't work on AMD64...

cc -c -O2 -frename-registers -pipe -fno-strict-aliasing  -std=c99 -g -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
-Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-fformat-extensions -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-finline-limit=8000 --param inline-unit-growth=100 --param 
large-function-growth=1000  -fno-omit-frame-pointer -mcmodel=kernel 
-mno-red-zone  -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow  
-msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror  
/usr/src/sys/amd64/amd64/db_trace.c
cc1: warnings being treated as errors
/usr/src/sys/amd64/amd64/db_trace.c: In function 'stack_save_td':
/usr/src/sys/amd64/amd64/db_trace.c:535: warning: type defaults to 'int' in 
declaration of 'rbp'
/usr/src/sys/amd64/amd64/db_trace.c:537: warning: implicit declaration of 
function 'TD_IS_SWWAPPED'
/usr/src/sys/amd64/amd64/db_trace.c:537: warning: nested extern declaration of 
'TD_IS_SWWAPPED'
*** Error code 1

Stop in /usr/obj/usr/src/sys/GENERIC.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
[EMAIL PROTECTED] /usr/src % 

Here's an updated patch to sys/amd64/amd64/db_trace.c (it's a diff
against revision 1.81).  It changes "register rbp" to be "register_t
rbp" and fixes the extra "W" in TD_IS_SWAPPED.  The kernel built fine
after these changes.  I'll test it out tomorrow.

--- sys/amd64/amd64/db_trace.c.orig 2007-11-15 17:00:56.0 -0500
+++ sys/amd64/amd64/db_trace.c  2007-11-27 22:59:29.0 -0500
@@ -505,15 +505,13 @@
ctx->pcb_rip, count));
 }
 
-void
-stack_save(struct stack *st)
+static void
+stack_capture(struct stack *st, register_t rbp)
 {
struct amd64_frame *frame;
vm_offset_t callpc;
-   register_t rbp;
 
stack_zero(st);
-   __asm __volatile("movq %%rbp,%0" : "=r" (rbp));
frame = (struct amd64_frame *)rbp;
while (1) {
if (!INKERNEL((long)frame))
@@ -531,6 +529,29 @@
}
 }
 
+void
+stack_save_td(struct stack *st, struct thread *td)
+{
+   register_t rbp;
+
+   if (TD_IS_SWAPPED(td))
+   panic("stack_save_td: swapped");
+   if (TD_IS_RUNNING(td))
+   panic("stack_save_td: running");
+
+   rbp = td->td_pcb->pcb_rbp;
+   stack_capture(st, rbp);
+}
+
+void
+stack_save(struct stack *st)
+{
+   register_t rbp;
+
+   __asm __volatile("movq %%rbp,%0" : "=r" (rbp));
+   stack_capture(st, rbp);
+}
+
 int
 amd64_set_watch(watchnum, watchaddr, size, access, d)
int watchnum;

> I think procstat(1) is getting a lot closer to commitable state for 
> 8-CURRENT, but further feedback would be most welcome (including reports of 
> success on non-i386 architectures, and possibly patches to fix them).  For 
> FreeBSD developers with P4 access, you can also check out

Thank you for this.  I think procstat(1) is going to be very useful.

-- WXS
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: pkg_add doesn't keep dependent pkgs

2007-11-07 Thread Wesley Shields
On Tue, Nov 06, 2007 at 12:27:13PM -0800, Maslan wrote:
> > Package dependencies may change, depending on the user settings and
> > port maintainers configuration for the port (i.e. Makefiles). The same
> > sort of applies to packages as well.
> > Or were you referring to just packages instead of ports based
> > package metadata :)?
> > Or maybe a better question is: what are you trying to accomplish?
> > -Garrett
> >
> 
> The problem is that i always try FreeBSD snapshots, and each time i
> did a fresh install, i found my self in need to install xorg & gnome.
> so when i use pkg_add -rK xorg or pkg_add -rK gnome, it just keeps the
> package itself only without its dependencies, it would be better for
> me to keep the packages i use rather than downloading them every time.
> 
> The ports has no problem with that, since it leaves all the port
> dependencies in /usr/ports/distfiles but i prefer packages than
> recompiling every time i install a fresh system something like gnome
> would eat my day compiling it.

You could always use pkg_fetch -fR (from portupgrade) to fetch them all
first, and then pkg_add them after.  Of course, I think fixing pkg_add
to keep the dependencies also is a better solution.

-- WXS
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: truncate tool - must be root?

2006-05-30 Thread Wesley Shields
On Tue, May 30, 2006 at 10:59:11AM -0500, Eric Anderson wrote:
> Is it expected that truncate(8) must be used by a superuser?  If so, 
> then the man page should probably mention it.  If not, then it's broken :)
> 
> 
> Eric

I can use truncate on files I own without a problem.  Who owns the
files?  A quick experiment indicates that even setting a file to mode
647 when owned by root:wheel doesn't allow it to be operated on by
anyone other than root when using truncate.

-- WXS
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: speed up port compiling using RAM (tmpfs) ???

2006-01-19 Thread Wesley Shields
On Thu, Jan 19, 2006 at 05:54:02PM +0100, Dag-Erling Sm?rgrav wrote:
> Mike Meyer <[EMAIL PROTECTED]> writes:
> > Will using a swap-backed disk change anything?
> 
> Not really.
> 
> > How about the best way to configure things to use two disks for the
> > compile?
> 
> I'm not sure what you are trying to achieve.  Unlike the base system,
> the ports tree does not use separate source and object directories.

I think he is trying to get at a scenario where WRKDIR is on a seperate
disk from the one /usr/ports is on.

To answer his question, assuming this is what he is going, for why not
just add a new physical disk to the system per the handbook, and set
WRKDIR to be where ever that disk is mounted.

-- WXS
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Kernel source hacking

2005-11-04 Thread Wesley Shields
On Fri, Nov 04, 2005 at 02:59:05PM +, Joao Barros wrote:
> On 11/4/05, Robert Watson <[EMAIL PROTECTED]> wrote:
> >
> > On Thu, 3 Nov 2005, M. Warner Losh wrote:
> >
> > > : Also, is there a page with other tasks for kernel neophytes like me? I
> > > : looked for some such page but I couldn't find any.
> > >
> > > phk used to have a /jkh/ page, or Junior Kernel Hacker page.  Don't know
> > > if that's still that way or not.
> >
> > Now that we have a FreeBSD Developer wiki, it may make sense to move the
> > page there so it can be more easily reached and maintained by a broader
> > set of developers?
> >
> 
> Could you please provide the link for the Wiki? Thanks.

http://wikitest.freebsd.org/ is the only one I am aware of.  If there is
a more official one I'm not aware of it.

-- WXS
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: [FreeBSD-Announce] New Logo

2005-11-01 Thread Wesley Shields
On Tue, Nov 01, 2005 at 08:09:58AM -0800, [EMAIL PROTECTED] wrote:
> At 10:05 AM 11/1/2005 -0600, Tillman Hodgson wrote:
> | On Tue, Nov 01, 2005 at 11:01:51AM -0500, Branson Matheson wrote:
> | > Since there has been a plethora of negative.. i thought i'd add my 
> 2cents..
> | > I think the new logo is pretty cool. Modern and artsy.
> | 
> | > Definately keeps with the roots of our Daemon .. while showing we can 
> | > evolve and be more modern. Kudos to the artist and the selecton crew.
> | 
> | I agree, it's a nice logo -- it has a nod to Beastie and yet looks like
> | a logo instead of a mascot. Printing letterhead with it could be
> | expensive (full color), but that's just encouragement to stay paperless
> | anyway ;-)
> | 
> | I think that it'll look great when shown on the new web site design.
> 
> what's the URL for the logo?
> 
> Ray

http://logo-contest.freebsd.org/result/

-- WXS
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"