TB --- 2014-02-19 07:57:41 - tinderbox 2.20 running on freebsd-current.sentex.ca
TB --- 2014-02-19 07:57:41 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64
TB --- 2014
TB --- 2014-02-19 08:35:44 - tinderbox 2.20 running on freebsd-current.sentex.ca
TB --- 2014-02-19 08:35:44 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64
TB --- 2014
Sent from my iPad
> On Feb 18, 2014, at 9:38 PM, Luigi Rizzo wrote:
>
>> On Tue, Feb 18, 2014 at 11:24 AM, Ian Lepore wrote:
>>
>>> On Fri, 2014-02-14 at 13:46 -0800, Luigi Rizzo wrote:
On Fri, Feb 14, 2014 at 10:23 AM, Ian Lepore wrote:
> On Fri, 2014-02-14 at 18:35 +0100, L
As I use the Gnome2 desktop, I am unclear as to the recommended best
practice.
Base iconv and ports libiconv conflict, so one or the other should be used.
FreeBSD 10 has been updated so that either base iconv or ports libiconv can
be used.
For me to switch between the two requires a two day recomp
On Wed, Feb 19, 2014 at 06:32:07AM -0800, Robert_Burmeister wrote:
> As I use the Gnome2 desktop, I am unclear as to the recommended best
> practice.
>
> Base iconv and ports libiconv conflict, so one or the other should be used.
See the commit made 3 days ago to glib20 port. Of particular inter
On Wed, 19 Feb 2014 06:32:07 -0800 (PST) Robert_Burmeister wrote:
> As I use the Gnome2 desktop, I am unclear as to the recommended best
> practice.
>
> Base iconv and ports libiconv conflict, so one or the other should be used.
> FreeBSD 10 has been updated so that either base iconv or ports libi
TB --- 2014-02-19 16:07:40 - tinderbox 2.20 running on freebsd-current.sentex.ca
TB --- 2014-02-19 16:07:40 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64
TB --- 2014
TB --- 2014-02-19 16:44:50 - tinderbox 2.20 running on freebsd-current.sentex.ca
TB --- 2014-02-19 16:44:50 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64
TB --- 2014
On Tuesday, February 18, 2014 3:02:16 pm Bruno Lauzé wrote:
> root@pcbsd:/dev # stat /dev/ada0
> 1895890688 97 crw-rw-rw- 1 root operator 97 0 "Feb 18 10:52:11 2014" "Feb 17
09:36:43 2014" "Feb 17 09:36:43 2014" "Dec 31 17:59:59 1969" 4096 0 0
/dev/ada0
>
> root@pcbsd:/dev # stat /dev/ada0p2
> 1
On Wed, 2014-02-19 at 13:44 -0500, John Baldwin wrote:
> On Tuesday, February 18, 2014 3:02:16 pm Bruno Lauzé wrote:
> > root@pcbsd:/dev # stat /dev/ada0
> > 1895890688 97 crw-rw-rw- 1 root operator 97 0 "Feb 18 10:52:11 2014" "Feb
> > 17
> 09:36:43 2014" "Feb 17 09:36:43 2014" "Dec 31 17:59:59 1
Hi.
Clock interrupt threads, same as other ones are only softly bound to
specific CPUs by scheduler preferring to run them on CPUs where they are
scheduled. So far that was enough to balance load, but allowed threads
to migrate, if needed. Is it too flexible for some use case?
--
Alexander M
On 19 February 2014 11:40, Alexander Motin wrote:
> Hi.
>
> Clock interrupt threads, same as other ones are only softly bound to
> specific CPUs by scheduler preferring to run them on CPUs where they are
> scheduled. So far that was enough to balance load, but allowed threads to
> migrate, if need
On 19.02.2014 21:51, Adrian Chadd wrote:
On 19 February 2014 11:40, Alexander Motin wrote:
Clock interrupt threads, same as other ones are only softly bound to
specific CPUs by scheduler preferring to run them on CPUs where they are
scheduled. So far that was enough to balance load, but allowed
On 19 February 2014 11:59, Alexander Motin wrote:
>> So if we're moving towards supporting (among others) a pcbgroup / RSS
>> hash style work load distribution across CPUs to minimise
>> per-connection lock contention, we really don't want the scheduler to
>> decide it can schedule things on othe
On 2/19/14, 12:04 PM, Adrian Chadd wrote:
On 19 February 2014 11:59, Alexander Motin wrote:
So if we're moving towards supporting (among others) a pcbgroup / RSS
hash style work load distribution across CPUs to minimise
per-connection lock contention, we really don't want the scheduler to
dec
On Wednesday, February 19, 2014 3:04:51 pm Adrian Chadd wrote:
> On 19 February 2014 11:59, Alexander Motin wrote:
>
> >> So if we're moving towards supporting (among others) a pcbgroup / RSS
> >> hash style work load distribution across CPUs to minimise
> >> per-connection lock contention, we re
On 19.02.2014 22:04, Adrian Chadd wrote:
On 19 February 2014 11:59, Alexander Motin wrote:
So if we're moving towards supporting (among others) a pcbgroup / RSS
hash style work load distribution across CPUs to minimise
per-connection lock contention, we really don't want the scheduler to
decid
Benjamin Kaduk wrote on 17.02.2014 08:56:
On Sun, 16 Feb 2014, Ruslan Makhmatkhanov wrote:
Hello,
there is -Z parameter in ssh-keygen --help output, but no mention of
it in ssh-keygen's man-page. Any clue what values this parameter accept?
It is the "new-format ciphername", which can be used
On Wed, Feb 19, 2014 at 11:04:49PM +0200, Alexander Motin wrote:
> On 19.02.2014 22:04, Adrian Chadd wrote:
> > On 19 February 2014 11:59, Alexander Motin wrote:
> >
> >>> So if we're moving towards supporting (among others) a pcbgroup / RSS
> >>> hash style work load distribution across CPUs to
On 19.02.2014 23:44, Slawa Olhovchenkov wrote:
On Wed, Feb 19, 2014 at 11:04:49PM +0200, Alexander Motin wrote:
On 19.02.2014 22:04, Adrian Chadd wrote:
On 19 February 2014 11:59, Alexander Motin wrote:
So if we're moving towards supporting (among others) a pcbgroup / RSS
hash style work lo
On 19 February 2014 14:09, Alexander Motin wrote:
> On 19.02.2014 23:44, Slawa Olhovchenkov wrote:
>>
>> On Wed, Feb 19, 2014 at 11:04:49PM +0200, Alexander Motin wrote:
>>
>>> On 19.02.2014 22:04, Adrian Chadd wrote:
On 19 February 2014 11:59, Alexander Motin wrote:
>> So if w
On Thu, Feb 20, 2014 at 12:09:04AM +0200, Alexander Motin wrote:
> On 19.02.2014 23:44, Slawa Olhovchenkov wrote:
> > On Wed, Feb 19, 2014 at 11:04:49PM +0200, Alexander Motin wrote:
> >
> >> On 19.02.2014 22:04, Adrian Chadd wrote:
> >>> On 19 February 2014 11:59, Alexander Motin wrote:
> >>>
>
TB --- 2014-02-20 00:07:46 - tinderbox 2.20 running on freebsd-current.sentex.ca
TB --- 2014-02-20 00:07:46 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64
TB --- 2014
Can someone point to where I disable clang from
issuing an error and aborting on an unknown option?
% cd /usr/ports/databases/py-sqlite3
% make
cc -shared -O2 -pipe -march=opteron -fno-strict-aliasing
build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/cache.o
build/temp.freebsd-11.0-CURRENT-amd6
TB --- 2014-02-20 00:44:53 - tinderbox 2.20 running on freebsd-current.sentex.ca
TB --- 2014-02-20 00:44:53 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64
TB --- 2014
On Wed, Feb 19, 2014 at 5:19 PM, Steve Kargl
wrote:
> Can someone point to where I disable clang from
> issuing an error and aborting on an unknown option?
>
> % cd /usr/ports/databases/py-sqlite3
> % make
>
> cc -shared -O2 -pipe -march=opteron -fno-strict-aliasing
> build/temp.freebsd-11.0-CURR
On Wed, Feb 19, 2014 at 06:24:07PM -0800, hiren panchasara wrote:
> On Wed, Feb 19, 2014 at 5:19 PM, Steve Kargl
> wrote:
> > Can someone point to where I disable clang from
> > issuing an error and aborting on an unknown option?
> >
> > % cd /usr/ports/databases/py-sqlite3
> > % make
> >
> > cc .
On Thu, Feb 20, 2014 at 2:19 AM, Steve Kargl
wrote:
> Can someone point to where I disable clang from
> issuing an error and aborting on an unknown option?
>
> % cd /usr/ports/databases/py-sqlite3
> % make
>
> cc -shared -O2 -pipe -march=opteron -fno-strict-aliasing
> build/temp.freebsd-11.0-CURR
The port x11/kde-workspace (kde-workspace-4.10.5_2 on my installation) fails to
be updated
and therefore a bunch of very important applications (i.e. devel/kdevelop) do
not work
anymore.
The build/update of x11/kde4-workspace failst due to:
[...]
[ 98%] Built target kwin
gmake[4]: Entering dir
29 matches
Mail list logo