Hi,
On behalf of pkgng crew, I'm happy to announce pkg 1.0-beta9
- changes:
* query -f has been replaced by query -F when querying a package (file) for
consistency with pkg info
* fix autoremove recursion
* pkg set -o oldorigin:neworigin allow the user to modify the origin of a
packages
At 02:02 15/12/2011, O. Hartmann wrote:
Just read this on
phoronix.com
Is this finally a chance to get GPGPU on FreeBSD natively supported?
nVidia has a binary driver, supporting well their higher end graphics
cards on FreeBSD 64bit natively.
I do not understand much about the compiler
Baptiste Daroussin wrote:
* pkg set -o oldorigin:neworigin allow the user to modify the origin of a
packages (useful for MOVED)
Can such things be tracked automatically?
I.e. will pkg upgrade upgrade moved packages?
___
freebsd-current@freebsd.org
A few messages here:
1. An open apology to Brooks Davis. I already apologized privately; this is
for all others to know such.
2. Whoever complained about me cross posting on the lists, there are
reasons I do such. Java on FreeBSD on the PowerPC platform includes all
mailing lists here and- at
A couple of days ago I updated FreeBSD 10.0-CURRENT and deleted old libs
and old files via make delete-old-XXX in /usr/src, as I saw that
Kerberos5/Heimdal got an update.
After that, several server/applications didn't work correctly anymore
due to missing, already deleted libraries.
So i
On Fri, Mar 30, 2012 at 11:12:42AM +0200, Baptiste Daroussin wrote:
Hi,
On behalf of pkgng crew, I'm happy to announce pkg 1.0-beta9
[...]
Please note that normally this will be the last beta version,
So we can expect an official package repository with the first RC?
pgptOzA777NGx.pgp
On 03/30/2012 01:10 PM, Lars Engels wrote:
On Fri, Mar 30, 2012 at 11:12:42AM +0200, Baptiste Daroussin wrote:
Hi,
On behalf of pkgng crew, I'm happy to announce pkg 1.0-beta9
[...]
Please note that normally this will be the last beta version,
So we can expect an official package
At 20:23 29/03/2012, you wrote:
Ð Thu, 15 Dec 2011 01:02:03 +0100
O. Hartmann ohart...@zedat.fu-berlin.de пиÑеÑ:
Just read this on
phoronix.com
Is this finally a chance to get GPGPU on FreeBSD natively supported?
nVidia has a binary driver, supporting well their higher end graphics
On Fri, Mar 30, 2012 at 01:12:42PM +0200, Julien Laffaye wrote:
On 03/30/2012 01:10 PM, Lars Engels wrote:
On Fri, Mar 30, 2012 at 11:12:42AM +0200, Baptiste Daroussin wrote:
Hi,
On behalf of pkgng crew, I'm happy to announce pkg 1.0-beta9
[...]
Please note that normally this will
TB --- 2012-03-30 09:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-03-30 09:40:00 - starting HEAD tinderbox run for amd64/amd64
TB --- 2012-03-30 09:40:00 - cleaning the object tree
TB --- 2012-03-30 09:40:00 - cvsupping the source tree
TB --- 2012-03-30 09:40:00 -
On Mar 30, 2012 6:22 AM, Eric van Gyzen e...@vangyzen.net wrote:
However, if you always want to use tmpfs instead of stable storage,
please do not. Some people expect /tmp to be persistent. This is why
/etc/defaults/rc.conf has clear_tmp_enable=NO. Changing this would break
the POLA.
This is
I track stable/8, stable/9, and head on (different slices on) my laptop
on a daily basis. I share /usr/local among all of these: while I update
the installed ports on a daily basis, I'm unwilling to do that 3 times
daily. :-}
The x11/nvidia-driver port is one, however, that I've found helpful to
However, if you always want to use tmpfs instead of stable storage,
please do not. Some people expect /tmp to be persistent. This is why
/etc/defaults/rc.conf has clear_tmp_enable=NO. Changing this would break
the POLA.
This is a mistake.
The default should be clear_tmp_enable=YES
On Fri, 2012-03-30 at 06:18 -0700, David Wolfskill wrote:
I track stable/8, stable/9, and head on (different slices on) my laptop
on a daily basis. I share /usr/local among all of these: while I update
the installed ports on a daily basis, I'm unwilling to do that 3 times
daily. :-}
The
TB --- 2012-03-30 12:46:00 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-03-30 12:46:00 - starting HEAD tinderbox run for mips/mips
TB --- 2012-03-30 12:46:01 - cleaning the object tree
TB --- 2012-03-30 12:46:46 - cvsupping the source tree
TB --- 2012-03-30 12:46:46 -
TB --- 2012-03-30 12:49:45 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-03-30 12:49:45 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2012-03-30 12:49:45 - cleaning the object tree
TB --- 2012-03-30 12:49:45 - cvsupping the source tree
TB --- 2012-03-30 12:49:45 -
On 30 Mar 2012 14:26, sth...@nethelp.no wrote:
However, if you always want to use tmpfs instead of stable storage,
please do not. Some people expect /tmp to be persistent. This is why
/etc/defaults/rc.conf has clear_tmp_enable=NO. Changing this would
break
the POLA.
This is a
O. Hartmann ohartman at zedat.fu-berlin.de writes:
Am 03/29/12 18:14, schrieb David Wolfskill:
On Thu, Mar 29, 2012 at 04:18:06PM +0200, O. Hartmann wrote:
I was wondering if there are some objections using TMPFS for /tmp and
/var/run.
...
...
Linux is using TMPFS filesystems a lot
Sorry for the naiv headline.
I run into massive problems on all of my FreeBSD 10.0-CURRENT driven
boxes. PostgreSQL rejects accessing OpenLDAP via SSL and all clients
accessing the database and autheticating users via a SSL/TLS secured
conection to OpenLDAP refuse working. This includes some very
/tmp is used by eaccelerator for its cache. It's not required to persist but
does prevent the need to regenerate everything after a reboot.
Lucas Holt
On Mar 30, 2012, at 10:43 AM, Chris Rees utis...@gmail.com wrote:
On 30 Mar 2012 14:26, sth...@nethelp.no wrote:
However, if you always
On Friday, March 30, 2012 9:18:33 am David Wolfskill wrote:
I track stable/8, stable/9, and head on (different slices on) my laptop
on a daily basis. I share /usr/local among all of these: while I update
the installed ports on a daily basis, I'm unwilling to do that 3 times
daily. :-}
The
On Thursday, January 12, 2012 4:08:09 pm John Baldwin wrote:
On Tuesday, January 03, 2012 7:31:59 pm Adrian Connolly wrote:
On 2012/01/04, at 0:37, John Baldwin j...@freebsd.org wrote:
On Monday, January 02, 2012 11:39:10 pm aconnoll...@yahoo.co.jp wrote:
I am running 9.0-RC3 on an
On Fri, Mar 30, 2012 at 12:18:58PM -0400, John Baldwin wrote:
...
I've sent an e-mail to the NVIDIA driver author about how best to fix this.
You can just change the driver to use VM_MEMATTR_UNCACHEABLE instead of
VM_MEMATTR_UNCACHED for now.
Thanks; I'd need to make it conditional
Am 03/30/12 15:50, schrieb O. Hartmann:
Sorry for the naiv headline.
I run into massive problems on all of my FreeBSD 10.0-CURRENT driven
boxes. PostgreSQL rejects accessing OpenLDAP via SSL and all clients
accessing the database and autheticating users via a SSL/TLS secured
conection to
The default should be clear_tmp_enable=YES
if only to uncover those broken configurations that expect /tmp to be
persistent.
If you want to break POLA and make a lot of people angry, sure.
Otherwise no.
I would very much like an example of where /tmp is expected to persist.
I
On Fri, Mar 30, 2012 at 3:18 PM, sth...@nethelp.no wrote:
However, if you always want to use tmpfs instead of stable storage,
please do not. Some people expect /tmp to be persistent. This is why
/etc/defaults/rc.conf has clear_tmp_enable=NO. Changing this would break
the POLA.
This is
On 30 March 2012 17:31, C. P. Ghost cpgh...@cordula.ws wrote:
On Fri, Mar 30, 2012 at 3:18 PM, sth...@nethelp.no wrote:
However, if you always want to use tmpfs instead of stable storage,
please do not. Some people expect /tmp to be persistent. This is why
/etc/defaults/rc.conf has
On Fri, Mar 30, 2012 at 05:56:06PM +, Chris Rees wrote:
On 30 March 2012 17:31, C. P. Ghost cpgh...@cordula.ws wrote:
On Fri, Mar 30, 2012 at 3:18 PM, sth...@nethelp.no wrote:
However, if you always want to use tmpfs instead of stable storage,
please do not. Some people expect /tmp
On 03/26/12 02:55, Kaho Toshikazu wrote:
Hello, Andriy Gapon and ML members,
Date: Sun, 25 Mar 2012 13:15:26 +0300
on 25/03/2012 08:02 Kaho Toshikazu said the following:
Hello Andriy Gapon,
Thank you for your comment.
Message-ID:4f6d9672.4050...@freebsd.org
Date: Sat, 24 Mar 2012
On 03/30/12 11:15, Steve Kargl wrote:
On Fri, Mar 30, 2012 at 05:56:06PM +, Chris Rees wrote:
On 30 March 2012 17:31, C. P. Ghost cpgh...@cordula.ws wrote:
On Fri, Mar 30, 2012 at 3:18 PM, sth...@nethelp.no wrote:
However, if you always want to use tmpfs instead of stable storage,
please
Let me tell you a story.
Someone decided that ext4 could have a decent speed up if it
implemented the posix standard for not flushing files on close().
After all, if you needed it to be guaranteed to be written to disk,
you would call a flush routine first, before you called close().
So they did
On 30 March 2012 19:36, Adrian Chadd adr...@freebsd.org wrote:
On 30 March 2012 10:56, Chris Rees cr...@freebsd.org wrote:
On 30 March 2012 17:31, C. P. Ghost cpgh...@cordula.ws wrote:
On Fri, Mar 30, 2012 at 3:18 PM, sth...@nethelp.no wrote:
However, if you always want to use tmpfs instead
On 30 March 2012 12:42, Chris Rees cr...@freebsd.org wrote:
Guess what ext4 did? :)
Don't mis-estimate POLA.
Well, having thought about what this conversation was *really* about,
I may have unintentionally derailed it a little.
My original intention was to say to Oliver, please, don't be
TB --- 2012-03-30 20:00:26 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-03-30 20:00:26 - starting HEAD tinderbox run for mips/mips
TB --- 2012-03-30 20:00:26 - cleaning the object tree
TB --- 2012-03-30 20:01:11 - cvsupping the source tree
TB --- 2012-03-30 20:01:11 -
On Friday, March 30, 2012 12:41:12 pm David Wolfskill wrote:
On Fri, Mar 30, 2012 at 12:18:58PM -0400, John Baldwin wrote:
...
I've sent an e-mail to the NVIDIA driver author about how best to fix
this.
You can just change the driver to use VM_MEMATTR_UNCACHEABLE instead of
On Fri, Mar 30, 2012 at 01:46:58PM -0400, John Baldwin wrote:
...
You can actually use that on 8 and 9 as well. I think it's a likely a bug
that it used VM_MEMATTR_UNCACHED in the first place and that it should have
been using VM_MEMATTR_UNCACHEABLE all along. (Which is why I've renamed
the
C. P. Ghost wrote:
Not clearing /tmp on reboot has been
the norm for way too long and it is too late to change now.
We either evolve or be in a stalemate forever.
It's not just POLA, it also involves deleting data of unaware
users, and that should be avoided.
Mounting on a directory (/tmp)
On 30 March 2012 17:57, deeptec...@gmail.com wrote:
C. P. Ghost wrote:
Not clearing /tmp on reboot has been
the norm for way too long and it is too late to change now.
We either evolve or be in a stalemate forever.
No, you do it in a sensible, controlled fashion.
You make it really easy
On Fri, 30 Mar 2012, Adrian Chadd wrote:
On 30 March 2012 17:57, deeptec...@gmail.com wrote:
C. P. Ghost wrote:
Not clearing /tmp on reboot has been
the norm for way too long and it is too late to change now.
We either evolve or be in a stalemate forever.
No, you do it in a sensible,
deeptech71 at gmail.com writes:
...
One of those reasons people stick/stuck with BSD is that we don't go
and change this stuff so quickly.
Yes, it would be a total of ~20 years before we finally decided to switch to
using TMPFS for /tmp.
...
According to TMPFS(5)
BUGS
The
TB --- 2012-03-31 01:00:00 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-03-31 01:00:00 - starting HEAD tinderbox run for i386/pc98
TB --- 2012-03-31 01:00:00 - cleaning the object tree
TB --- 2012-03-31 01:00:00 - cvsupping the source tree
TB --- 2012-03-31 01:00:00 -
TB --- 2012-03-31 03:14:16 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-03-31 03:14:16 - starting HEAD tinderbox run for mips/mips
TB --- 2012-03-31 03:14:16 - cleaning the object tree
TB --- 2012-03-31 03:15:05 - cvsupping the source tree
TB --- 2012-03-31 03:15:05 -
TB --- 2012-03-31 03:13:01 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-03-31 03:13:01 - starting HEAD tinderbox run for ia64/ia64
TB --- 2012-03-31 03:13:01 - cleaning the object tree
TB --- 2012-03-31 03:13:01 - cvsupping the source tree
TB --- 2012-03-31 03:13:01 -
Hello Alexander Motin,
Could you collect more information about what's exactly happens
with the device? Can you execute some camcontrol inquiry or
camcontrol readcap commands after kernel misdetected size with
READ CAPACITY(16)?
If yes (device is still alive), could you run these
44 matches
Mail list logo
