TB --- 2010-06-14 05:41:14 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-06-14 05:41:14 - starting HEAD tinderbox run for sparc64/sun4v
TB --- 2010-06-14 05:41:14 - cleaning the object tree
TB --- 2010-06-14 05:41:23 - cvsupping the source tree
TB --- 2010-06-14 05:41:23 - /usr/b
TB --- 2010-06-14 04:54:51 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-06-14 04:54:51 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2010-06-14 04:54:51 - cleaning the object tree
TB --- 2010-06-14 04:55:01 - cvsupping the source tree
TB --- 2010-06-14 04:55:01 - /usr
TB --- 2010-06-14 05:21:54 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-06-14 05:21:54 - starting HEAD tinderbox run for sparc64/sparc64
TB --- 2010-06-14 05:21:54 - cleaning the object tree
TB --- 2010-06-14 05:22:03 - cvsupping the source tree
TB --- 2010-06-14 05:22:03 - /usr
* Alexander Best wrote:
> CC=gcc44
> CXX=g++44
> CPP=cpp44
As I mentioned before, "gcc44" and "/usr/local/bin/gcc44" are spelled
differently.
--
Ed Schouten
WWW: http://80386.nl/
pgpCgGKibtSmx.pgp
Description: PGP signature
TB --- 2010-06-14 03:23:02 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-06-14 03:23:02 - starting HEAD tinderbox run for ia64/ia64
TB --- 2010-06-14 03:23:02 - cleaning the object tree
TB --- 2010-06-14 03:23:11 - cvsupping the source tree
TB --- 2010-06-14 03:23:11 - /usr/bin/c
On 06/13/10 19:09, Alan Cox wrote:
On Sun, Jun 13, 2010 at 8:38 PM, Doug Barton wrote:
On 06/01/10 08:26, John Baldwin wrote:
I've asked the driver author if the calls to vm_page_wire() and
vm_page_unwire() can simply be removed but have not heard back yet.
Is there any news on this? I h
Thanks for the report! This was caused by an
overflow in the compression calculation when the "in"
bytes was larger than the "out" bytes.
I just committed a fix as r209152.
Tim
Boris Samorodov wrote:
Hi!
-
% uname -a
FreeBSD host.ipt.ru 9.0-CURRENT FreeBSD 9.0-CURRENT #4 r208799: Fri Jun
On Sun, Jun 13, 2010 at 8:38 PM, Doug Barton wrote:
> On 06/01/10 08:26, John Baldwin wrote:
>
>>
>> I've asked the driver author if the calls to vm_page_wire() and
>> vm_page_unwire() can simply be removed but have not heard back yet.
>>
>
> Is there any news on this? I have updated to the lates
2010/6/14 Peter Jeremy :
> On 2010-Jun-13 10:07:15 +0200, Dag-Erling Smørgrav wrote:
>>You always overwrite passphrases, keys etc. as soon as you're done with
>>them so they don't end up in a crash dump or on a swap disk or
>>something.
>
> Which brings up an associated issue: By default, mlock(2)
On Sun, Jun 13, 2010 at 11:35 PM, Bernd Walter wrote:
> Crypto code wasn't aware of this problem and this is a way more
> obviuous optimization than function exchange.
> And I do believe that the programmers were clever people.
> Alarming, isn't it?
> Maybe paranoid users might consider compiling
On 06/01/10 08:26, John Baldwin wrote:
I've asked the driver author if the calls to vm_page_wire() and
vm_page_unwire() can simply be removed but have not heard back yet.
Is there any news on this? I have updated to the latest current so I'm
running the nv driver now, but I'd like to get the
On 2010-Jun-13 10:07:15 +0200, Dag-Erling Smørgrav wrote:
>You always overwrite passphrases, keys etc. as soon as you're done with
>them so they don't end up in a crash dump or on a swap disk or
>something.
Which brings up an associated issue: By default, mlock(2) can only be
used by root process
On Mon, Jun 14, 2010 at 1:28 AM, Doug Barton wrote:
> On 06/13/10 16:21, Alexander Best wrote:
>>
>> `mount -p&& stat -x /usr/src /usr/obj`:
>
> wow, completely unhelpful. So let me try again. If the /usr/src and /usr/obj
> are not literal directories in /usr then the tests you posted won't work.
On 06/13/10 16:21, Alexander Best wrote:
`mount -p&& stat -x /usr/src /usr/obj`:
wow, completely unhelpful. So let me try again. If the /usr/src and
/usr/obj are not literal directories in /usr then the tests you posted
won't work. Given what you've posted so far I strongly suspect that
the
On Mon, Jun 14, 2010 at 1:02 AM, Doug Barton wrote:
> On 06/13/10 15:58, Alexander Best wrote:
>>
>> hmmm...but i thought during buildworld either
>>
>> empty(.CURDIR:M/usr/src/*) or
>> empty(.CURDIR:M/usr/obj/*) should be false. so CC/CXX/CPP should never
>> actually be set during buildworld or b
On 06/13/10 15:58, Alexander Best wrote:
hmmm...but i thought during buildworld either
empty(.CURDIR:M/usr/src/*) or
empty(.CURDIR:M/usr/obj/*) should be false. so CC/CXX/CPP should never
actually be set during buildworld or buildkernel.
That depends, are /usr/src and /usr/obj literally direc
On Sun, Jun 13, 2010 at 11:46 PM, Ed Schouten wrote:
> Alexander,
>
> * Alexander Best wrote:
>> .if empty(.CURDIR:M/usr/src/*) && empty(.CURDIR:M/usr/obj/*) &&
>> exists(/usr/local/bin/gcc44)
>> CC = gcc44
>> CXX = g++44
>> CPP = cpp44
>> .endif
>
> Try /usr/local/bin/gcc44. The FreeBSD build in
On Sun, Jun 13, 2010 at 11:41:03PM +0200, Dag-Erling Smørgrav wrote:
> Bernd Walter writes:
> > Dag-Erling Smørgrav writes:
> > > The only way you can tell that gcc did it is if you break the rules,
> > > such as by defining your own version of printf() or puts().
> > Our loader stages do this fo
Le Sun, 13 Jun 2010 23:35:12 +0200,
Bernd Walter a écrit :
> Go back to the originating mail.
> Crypto code wasn't aware of this problem and this is a way more
> obviuous optimization than function exchange.
> And I do believe that the programmers were clever people.
> Alarming, isn't it?
The re
Alexander,
* Alexander Best wrote:
> .if empty(.CURDIR:M/usr/src/*) && empty(.CURDIR:M/usr/obj/*) &&
> exists(/usr/local/bin/gcc44)
> CC = gcc44
> CXX = g++44
> CPP = cpp44
> .endif
Try /usr/local/bin/gcc44. The FreeBSD build infrastructure overrides
PATH to prevent accidental use of local tools
Bernd Walter writes:
> Dag-Erling Smørgrav writes:
> > The only way you can tell that gcc did it is if you break the rules,
> > such as by defining your own version of printf() or puts().
> Our loader stages do this for good reasons. And in microcontroller
> programming (surely out of FreeBSD sc
On Mon, Jun 14, 2010 at 02:20:26AM +1000, Andrew Milton wrote:
> +---[ Bernd Walter ]--
> | On Sun, Jun 13, 2010 at 05:44:29PM +0200, Dag-Erling Smørgrav wrote:
> | > Bernd Walter writes:
> | > > Amazing - this is one of the things which can get nasty if you try some
> | >
On Sun, Jun 13, 2010 at 10:28 PM, Alexander Best
wrote:
> hi there. i'm experiencing two problems during buildworld. i'm not
> sure if these are the result of me doing weird stuff or a problem in
> the src structure:
>
> 1. i have the following in my make.conf:
>
> .if empty(.CURDIR:M/usr/src/*) &
On Jun 13, 2010, at 3:28 PM, Alexander Best wrote:
> hi there. i'm experiencing two problems during buildworld. i'm not
> sure if these are the result of me doing weird stuff or a problem in
> the src structure:
>
> 1. i have the following in my make.conf:
>
> .if empty(.CURDIR:M/usr/src/*) &&
hi there. i'm experiencing two problems during buildworld. i'm not
sure if these are the result of me doing weird stuff or a problem in
the src structure:
1. i have the following in my make.conf:
.if empty(.CURDIR:M/usr/src/*) && empty(.CURDIR:M/usr/obj/*) &&
exists(/usr/local/bin/gcc44)
CC = gcc
On 2010-06-13 23:37:23 (+0900), Norikatsu Shigemura wrote:
> Hi yongari!
>
> I have a OpenRD Ultimate, which has two GbE ports - if_mge(4). But
> I couldn't use mge1 like following. So I tried to investigate.
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Rui Paulo-3 wrote:
>
>
> On 13 Jun 2010, at 12:40, Jakub Lach wrote:
>
>> Rui Paulo-3 wrote:
>>>
>>> On 13 Jun 2010, at 04:23, Jakub Lach wrote:
>>>
Hello.
Is update of wpa_supplicant planned?
>>>
>>>
>>> I'll likely work on this soon.
>>>
>>> --
>>> Rui Paulo
>>>
>>
>
On 13 Jun 2010, at 12:40, Jakub Lach wrote:
>
>
> Rui Paulo-3 wrote:
>>
>> On 13 Jun 2010, at 04:23, Jakub Lach wrote:
>>
>>> Hello.
>>>
>>> Is update of wpa_supplicant planned?
>>
>>
>> I'll likely work on this soon.
>>
>> --
>> Rui Paulo
>>
>
> That's splendid, thanks for fast reply.
TB --- 2010-06-13 18:47:41 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-06-13 18:47:41 - starting HEAD tinderbox run for sparc64/sun4v
TB --- 2010-06-13 18:47:41 - cleaning the object tree
TB --- 2010-06-13 18:47:51 - cvsupping the source tree
TB --- 2010-06-13 18:47:51 - /usr/b
Rui Paulo-3 wrote:
>
> On 13 Jun 2010, at 04:23, Jakub Lach wrote:
>
>> Hello.
>>
>> Is update of wpa_supplicant planned?
>
>
> I'll likely work on this soon.
>
> --
> Rui Paulo
>
That's splendid, thanks for fast reply.
Is MFC to 8 feasible?
regards,
- Jakub Lach
--
View this message
TB --- 2010-06-13 18:00:52 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-06-13 18:00:52 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2010-06-13 18:00:52 - cleaning the object tree
TB --- 2010-06-13 18:01:03 - cvsupping the source tree
TB --- 2010-06-13 18:01:03 - /usr
TB --- 2010-06-13 18:27:13 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-06-13 18:27:13 - starting HEAD tinderbox run for sparc64/sparc64
TB --- 2010-06-13 18:27:13 - cleaning the object tree
TB --- 2010-06-13 18:27:22 - cvsupping the source tree
TB --- 2010-06-13 18:27:22 - /usr
On 13 Jun 2010, at 04:23, Jakub Lach wrote:
>
> Hello.
>
> Is update of wpa_supplicant planned?
>
> Current version in STABLE as well as CURRENT
> (v0.6.8) is suffering from CTRL-EVENT-SCAN-RESULTS
> log spam.
>
> If it's the same problem, looks like it's fixed in v0.6.10
>
> http://bugs.d
TB --- 2010-06-13 16:32:45 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-06-13 16:32:45 - starting HEAD tinderbox run for ia64/ia64
TB --- 2010-06-13 16:32:45 - cleaning the object tree
TB --- 2010-06-13 16:32:54 - cvsupping the source tree
TB --- 2010-06-13 16:32:54 - /usr/bin/c
On Sun, Jun 13, 2010 at 06:14:11PM +0200, Dag-Erling Smørgrav wrote:
> Bernd Walter writes:
> > Dag-Erling Smørgrav writes:
> > > Bernd Walter writes:
> > > > Amazing - this is one of the things which can get nasty if you try
> > > > some kind of microtuning.
> > > Only if you break the rules.
+---[ Bernd Walter ]--
| On Sun, Jun 13, 2010 at 05:44:29PM +0200, Dag-Erling Smørgrav wrote:
| > Bernd Walter writes:
| > > Amazing - this is one of the things which can get nasty if you try some
| > > kind of microtuning.
| >
| > Only if you break the rules. Bad code is
Bernd Walter writes:
> Dag-Erling Smørgrav writes:
> > Bernd Walter writes:
> > > Amazing - this is one of the things which can get nasty if you try
> > > some kind of microtuning.
> > Only if you break the rules. Bad code is always bad, even if it
> > sometimes works by accident.
> To expect t
On Sun, Jun 13, 2010 at 05:44:29PM +0200, Dag-Erling Smørgrav wrote:
> Bernd Walter writes:
> > Amazing - this is one of the things which can get nasty if you try some
> > kind of microtuning.
>
> Only if you break the rules. Bad code is always bad, even if it
> sometimes works by accident.
To
Bernd Walter writes:
> Amazing - this is one of the things which can get nasty if you try some
> kind of microtuning.
Only if you break the rules. Bad code is always bad, even if it
sometimes works by accident.
DES
--
Dag-Erling Smørgrav - d...@des.no
__
Hi yongari!
I have a OpenRD Ultimate, which has two GbE ports - if_mge(4). But
I couldn't use mge1 like following. So I tried to investigate.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
Jun 13 05:02:14 sidearms kernel: mge1: watchdo
On Sun, Jun 13, 2010 at 12:44:03PM +0200, Matthias Andree wrote:
> Am 13.06.2010, 00:52 Uhr, schrieb Bernd Walter:
>
> >>In more general terms, the compiler is allowed to make any changes it
> >>likes to the program as long as the end result behaves exactly like it
> >>would if it hadn't been chan
Hello.
Is update of wpa_supplicant planned?
Current version in STABLE as well as CURRENT
(v0.6.8) is suffering from CTRL-EVENT-SCAN-RESULTS
log spam.
If it's the same problem, looks like it's fixed in v0.6.10
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=539915
best regards,
Jakub Lach
> Dnia 06.06.2010 b. f. napisał/a:
> > Is anybody planning to update the base system heimdal, which has been
> > largely untouched since May 2008? In addition to the many other
> > bug-fixes and improvements in the current version 1.3.3 (see, for
> > example:
>
> I decided to give it a try. My
Am 13.06.2010, 00:52 Uhr, schrieb Bernd Walter:
In more general terms, the compiler is allowed to make any changes it
likes to the program as long as the end result behaves exactly like it
would if it hadn't been changed. This is called the "as if" rule. For
instance, if you call printf() or f
TB --- 2010-06-13 07:57:08 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-06-13 07:57:08 - starting HEAD tinderbox run for sparc64/sun4v
TB --- 2010-06-13 07:57:08 - cleaning the object tree
TB --- 2010-06-13 07:57:17 - cvsupping the source tree
TB --- 2010-06-13 07:57:17 - /usr/b
TB --- 2010-06-13 07:11:24 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-06-13 07:11:24 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2010-06-13 07:11:24 - cleaning the object tree
TB --- 2010-06-13 07:11:35 - cvsupping the source tree
TB --- 2010-06-13 07:11:35 - /usr
TB --- 2010-06-13 07:39:07 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-06-13 07:39:07 - starting HEAD tinderbox run for sparc64/sparc64
TB --- 2010-06-13 07:39:07 - cleaning the object tree
TB --- 2010-06-13 07:39:16 - cvsupping the source tree
TB --- 2010-06-13 07:39:16 - /usr
On Sun, Jun 13, 2010 at 12:17:50AM +, Bruce Cran wrote:
> On Sun, Jun 13, 2010 at 12:52:16AM +0200, Bernd Walter wrote:
> > I'm at least sure that the compiler can't if it is linked from another
> > object file.
>
> Is that still true if LTO is enabled?
Good question - I wasn't aware of LTO.
Hi all,
The time has come to solicit some external testing for my SIFTR tool.
I'm hoping to commit it within a week or so unless problems are discovered.
SIFTR is a kernel module that logs a range of statistics on active TCP
connections to a log file. It provides the ability to make highly
g
Bernd Walter writes:
> Dag-Erling Smørgrav writes:
> > Bernd Walter writes:
> > > I'm not sure when removing a memset is allowed.
> > Always, if the compiler can determine that the data will not be used
> > later.
> I'm at least sure that the compiler can't if it is linked from another
> object
TB --- 2010-06-13 05:40:45 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-06-13 05:40:45 - starting HEAD tinderbox run for ia64/ia64
TB --- 2010-06-13 05:40:45 - cleaning the object tree
TB --- 2010-06-13 05:40:57 - cvsupping the source tree
TB --- 2010-06-13 05:40:57 - /usr/bin/c
51 matches
Mail list logo
