Can anyone suggest a good test suite for stressing atomic
primitives and/or userland locking?
There were some questions on freebsd-arm about verifying
that our atomics are correct; a few people have looked at the
code and everything looks good so far, but it would be
reassuring to have some test
On Mon, 6 May 2013 00:11:51 +0200, Baptiste Daroussin writes:
>The ports tree on current is still in very bad shape but I don't see
>anymore errors due to bmake specifically.
>
>You have my approval as portmgr to switch base make to bmake.
As an interim step, I would propose the change below.
In
hackers-requ...@freebsd.org wrote:
> > > > From: John-Mark Gurney
> > > > To: hack...@freebsd.org
> > > > Subject: looking for someone to fix humanize_number (test cases
> > > > included)
> > > >
> > > > I'm look
On 28 December 2012 15:06, Clifton Royston wrote:
> On Thu, Dec 27, 2012 at 02:24:33PM -1000, Clifton Royston wrote:
>> On Thu, Dec 27, 2012 at 08:31:36AM -1000, Clifton Royston wrote:
>> > ...
>> > I'll put the updated test program somewhere shortly.
>>
&g
On Thu, Dec 27, 2012 at 02:24:33PM -1000, Clifton Royston wrote:
> On Thu, Dec 27, 2012 at 08:31:36AM -1000, Clifton Royston wrote:
> > ...
> > I'll put the updated test program somewhere shortly.
>
> Test code and draft of revisions to function are at
>
>
On Thu, Dec 27, 2012 at 08:31:36AM -1000, Clifton Royston wrote:
> ...
> I'll put the updated test program somewhere shortly.
Test code and draft of revisions to function are at
http://www.volcano.org/misc/humanize_number/
Man page update will follow later.
Gurney
> > Subject: Re: looking for someone to fix humanize_number (test cases
> > included)
> > Message-ID:
> >
> > Content-Type: text/plain; charset=UTF-8
> >
> > On 25 December 2012 14:46, Clifton Royston wrote:
> > >> I correct myself:
On Wed, Dec 26, 2012 at 12:00:01PM +, freebsd-hackers-requ...@freebsd.org
wrote:
> Date: Tue, 25 Dec 2012 14:52:09 -0500
> From: Eitan Adler
> To: freebsd-hackers@freebsd.org, John-Mark Gurney
> Subject: Re: looking for someone to fix humanize_number (test cases
> incl
On 25 December 2012 14:46, Clifton Royston wrote:
>> I correct myself: the function works fine, and there are no bugs I
> could find, though it's clear the man page could emphasize the correct
> usage a bit more.
Can you submit a diff to the man page as well? I figure if you got
confused at lea
> > To: hack...@freebsd.org
> > > Subject: looking for someone to fix humanize_number (test cases
> > > included)
> > >
> > > I'm looking for a person who is interested in fixing up humanize_number.
> ...
> > > So I decided to write a test program to
On Tue, Dec 25, 2012 at 07:20:37AM -1000, Clifton Royston wrote:
> On Mon, Dec 24, 2012 at 12:00:01PM +, freebsd-hackers-requ...@freebsd.org
> wrote:
> > From: John-Mark Gurney
> > To: hack...@freebsd.org
> > Subject: looking for someone to fix humanize_number (tes
On Mon, Dec 24, 2012 at 12:00:01PM +, freebsd-hackers-requ...@freebsd.org
wrote:
> Date: Sun, 23 Dec 2012 00:32:20 -0800
> From: John-Mark Gurney
> To: hack...@freebsd.org
> Subject: looking for someone to fix humanize_number (test cases
> included)
> Message-ID: &
t the results from the -k run, but the new machine had a larger result
(I copied from UFS to ZFS)... It turns out that humanize_number was
broken when doing rounding... No longer does humanize_number round up
at .5 or more of the prefix..
So I decided to write a test program to test the output, an
Den 03/09/2012 kl. 09.25 skrev Junior White :
> hi all,
> I build a new kernel and install it, but don't known how to test the my
> new kernel's performance.
> I have read the Regressin and Performance Testing Guide in developer's
> handbook. But where is
>
hi all,
I build a new kernel and install it, but don't known how to test the my
new kernel's performance.
I have read the Regressin and Performance Testing Guide in developer's
handbook. But where is
the test program is, and how do i invoke them?
Gratitude to any
://www.bayofrum.net/~crees/scratch/doxygen-truss
>>>
>> _umtx_op(0x8012b0280,0x16,0x0,0x0,0x0,0x1) ERR#22 'Invalid argument'
>>
>> can you execute it in gdb and print its value ?
>>
>> print/x *(int *)0x8012b0280
>> print/x *(int *)(0x8012b0280+4)
valid argument'
>
> can you execute it in gdb and print its value ?
>
> print/x *(int *)0x8012b0280
> print/x *(int *)(0x8012b0280+4)
I've been having trouble debugging it since it's threaded, and so I
ran a binary search over the last few days of revisions from 1/Apr
On 2012/07/08 18:21, Chris Rees wrote:
Hi all / David,
doxygen has been failing for a while now on -CURRENT and apparently
-STABLE too. The current fix is disabling one of the tests in the
build, but obviously it points to a problem with our base system
I've trussed [1] the failing code [2
Hi all / David,
doxygen has been failing for a while now on -CURRENT and apparently
-STABLE too. The current fix is disabling one of the tests in the
build, but obviously it points to a problem with our base system
I've trussed [1] the failing code [2], and it looks as though it's
hanging on
[Since I did not receive any feedback on my previous message to the
-hackers list, I try again and CC: to -current in the hope to attract
more interest ...]
The NSCD patch attached to the previous mail, which can be found at:
http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg1645
tests. iconv_open(3) usage
part is rewrote.
2 changes from NetBSD are not merged:
1. To use signed char instead of unsigned char in 8-bit mode. This
requires to cast all character to at least unsigned char when passing
them to ctype(3). Test cases are required to convince me on this part;
2
ngual editing.
Affected LC_CTYPE in FreeBSD:
ko_KR.CP949, ko_KR.eucKR
ja_JP.eucJP
zh_CN.GB2312, zh_CN.GBK, zh_CN.eucCN
If you any locale above (especially for Japanese, Korean users), please help
me test whether the CJK text (in any kind of encodings) are being handled
correctly. Thanks.
--
Zhihao
2011/9/1 Ivan Voras :
> On 1 September 2011 16:11, Attilio Rao wrote:
>
>>> I mean, if we have 2 cpus in a machine, but MAXCPU is set to 256, there
>>> is a bunch of "lost" memory and higher levels of lock contention?
>>>
>>> I thought that attilio was taking a stab at enhancing this, but at the
>
On 1 September 2011 16:11, Attilio Rao wrote:
>> I mean, if we have 2 cpus in a machine, but MAXCPU is set to 256, there
>> is a bunch of "lost" memory and higher levels of lock contention?
>>
>> I thought that attilio was taking a stab at enhancing this, but at the
>> current time anything more
2011/8/31 Sean Bruno :
> On Tue, 2011-08-30 at 17:11 -0700, Ivan Voras wrote:
>> On 29.8.2011. 20:15, John Baldwin wrote:
>>
>> > However, the SRAT code just ignores the table when it encounters an issue
>> > like
>> > this, it doesn't hang. Something else later in the boot must have hung.
>>
>>
On Tue, 2011-08-30 at 17:11 -0700, Ivan Voras wrote:
> On 29.8.2011. 20:15, John Baldwin wrote:
>
> > However, the SRAT code just ignores the table when it encounters an issue
> > like
> > this, it doesn't hang. Something else later in the boot must have hung.
>
> Anyway... that machine can in
On 29.8.2011. 20:15, John Baldwin wrote:
However, the SRAT code just ignores the table when it encounters an issue like
this, it doesn't hang. Something else later in the boot must have hung.
Anyway... that machine can in its maximal configuration be populated
with eight 10-core CPUs, i.e. 8
On Monday, August 29, 2011 1:28:37 pm Ivan Voras wrote:
> On 29 August 2011 18:33, wrote:
> > On Mon, Aug 29, 2011 at 7:46 AM, Ivan Voras wrote:
> >> On 26/08/2011 19:44, Garrett Cooper wrote:
> >>> On Fri, Aug 26, 2011 at 10:36 AM, Ivan Voras wrote:
> >>>
> >>> ...
> >>>
> I think that I'
On 29 August 2011 18:33, wrote:
> On Mon, Aug 29, 2011 at 7:46 AM, Ivan Voras wrote:
>> On 26/08/2011 19:44, Garrett Cooper wrote:
>>> On Fri, Aug 26, 2011 at 10:36 AM, Ivan Voras wrote:
>>>
>>> ...
>>>
I think that I'll need a 9-CURRENT snapshot on it to run all 128 CPUs,
right?
>>>
On Mon, Aug 29, 2011 at 7:46 AM, Ivan Voras wrote:
> On 26/08/2011 19:44, Garrett Cooper wrote:
>> On Fri, Aug 26, 2011 at 10:36 AM, Ivan Voras wrote:
>>
>> ...
>>
>>> I think that I'll need a 9-CURRENT snapshot on it to run all 128 CPUs,
>>> right?
>>
>> A 9.0-BETA1 snapshot, yes.
>
> Well, I'll
On 29 August 2011 17:15, Andriy Gapon wrote:
> on 29/08/2011 17:46 Ivan Voras said the following:
>> On 26/08/2011 19:44, Garrett Cooper wrote:
>>> On Fri, Aug 26, 2011 at 10:36 AM, Ivan Voras wrote:
>>>
>>> ...
>>>
I think that I'll need a 9-CURRENT snapshot on it to run all 128 CPUs,
On 29 August 2011 17:20, Andriy Gapon wrote:
> on 29/08/2011 18:18 Ivan Voras said the following:
>>> Not sure if hw.memtest.tests tunable has made it into 9.0-BETA1.
>>> Setting it to zero should result in skipping the checks.
>>
>> If it did, to what should I set it?
>
> See one line above your
on 29/08/2011 18:18 Ivan Voras said the following:
> On 29 August 2011 17:15, Andriy Gapon wrote:
>> on 29/08/2011 17:46 Ivan Voras said the following:
>>> On 26/08/2011 19:44, Garrett Cooper wrote:
On Fri, Aug 26, 2011 at 10:36 AM, Ivan Voras wrote:
...
> I think that I'l
on 29/08/2011 17:46 Ivan Voras said the following:
> On 26/08/2011 19:44, Garrett Cooper wrote:
>> On Fri, Aug 26, 2011 at 10:36 AM, Ivan Voras wrote:
>>
>> ...
>>
>>> I think that I'll need a 9-CURRENT snapshot on it to run all 128 CPUs,
>>> right?
>>
>> A 9.0-BETA1 snapshot, yes.
>
> Well, I'll
On 29/08/2011 16:46, Ivan Voras wrote:
> On 26/08/2011 19:44, Garrett Cooper wrote:
>> On Fri, Aug 26, 2011 at 10:36 AM, Ivan Voras wrote:
>>
>> ...
>>
>>> I think that I'll need a 9-CURRENT snapshot on it to run all 128 CPUs,
>>> right?
>>
>> A 9.0-BETA1 snapshot, yes.
>
> Well, I'll leave it an
On 26/08/2011 19:44, Garrett Cooper wrote:
> On Fri, Aug 26, 2011 at 10:36 AM, Ivan Voras wrote:
>
> ...
>
>> I think that I'll need a 9-CURRENT snapshot on it to run all 128 CPUs,
>> right?
>
> A 9.0-BETA1 snapshot, yes.
Well, I'll leave it another half an hour but the 9.9-beta1 shapshot
froz
BSD's base system, if it's
possible.
On Tue, Aug 23, 2011 at 3:33 PM, Zhihao Yuan wrote:
> On Tue, Aug 23, 2011 at 12:51 PM, Ulrich Spörlein
> wrote:
>> On Thu, 2011-08-18 at 22:15:47 -0500, Zhihao Yuan wrote:
>>> On Thu, Aug 18, 2011 at 9:26 PM, Test Rat wrote:
>
On Fri, Aug 26, 2011 at 10:36 AM, Ivan Voras wrote:
...
> I think that I'll need a 9-CURRENT snapshot on it to run all 128 CPUs,
> right?
A 9.0-BETA1 snapshot, yes.
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman
I'll have a 8x8x2 (128 logical CPUs) machine to test for an afternoon
next week and I'm just wondering if any of you have something they want
tested. The opportunities are limited: it would have to be a
self-contained test (no network, drives, etc.) and fairly short.
Of course, I&
On Tue, Aug 23, 2011 at 12:51 PM, Ulrich Spörlein wrote:
> On Thu, 2011-08-18 at 22:15:47 -0500, Zhihao Yuan wrote:
>> On Thu, Aug 18, 2011 at 9:26 PM, Test Rat wrote:
>> > timp writes:
>> >
>> >> Hi!
>> >> I just tried you patch on latest c
On Thu, 2011-08-18 at 22:15:47 -0500, Zhihao Yuan wrote:
> On Thu, Aug 18, 2011 at 9:26 PM, Test Rat wrote:
> > timp writes:
> >
> >> Hi!
> >> I just tried you patch on latest current with clang.
> >>
> >> [root@current64 /usr/src]# uname -a
&g
Just checked your new patch. Works too. Thanks!
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/nvi-iconv-Call-for-test-tp4698373p4723231.html
Sent from the freebsd-hackers mailing list archive at Nabble.com.
___
freebsd-hackers
I'm very sorry.
Thanks to all!
-p0 was the problem.
Now it compiles and works.
I tried new vi with russian text and everything is fine.
Thank you!
And I'll try new patch
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/nvi-iconv-Call-for-test-tp4698373p4722191.html
And replace usr.bin/vi/config.h with the one you downloaded.
After the src tree is patched, please issue a make WITH_ICONV=1 depend
first under usr.bin/vi/ if you just want to test nvi instead of to
rebuild the world.
For the new config.h, the FreeBSD-only SYSV_CURSES macro is removed,
since we only
On Thu, Aug 18, 2011 at 9:26 PM, Test Rat wrote:
> timp writes:
>
>> Hi!
>> I just tried you patch on latest current with clang.
>>
>> [root@current64 /usr/src]# uname -a
>> FreeBSD current64 9.0-BETA1 FreeBSD 9.0-BETA1 #0: Thu Aug 18 03:56:45 MSK
>> 2
timp writes:
> Hi!
> I just tried you patch on latest current with clang.
>
> [root@current64 /usr/src]# uname -a
> FreeBSD current64 9.0-BETA1 FreeBSD 9.0-BETA1 #0: Thu Aug 18 03:56:45 MSK
> 2011 mox@current64:/usr/obj/usr/src/sys/GENERIC amd64
>
> [root@current64 /usr/src]# patch < ~/nvi2-
;t know how to make cl_bsd.c. Stop
> *** Error code 2
>
> Stop in /usr/src/usr.bin.
> *** Error code 1
>
> Stop in /usr/src.
> *** Error code 1
>
> Stop in /usr/src.
> *** Error code 1
>
> Stop in /usr/src.
>
> Maybe do I something wrong?
>
> --
> Vi
1
Stop in /usr/src.
Maybe do I something wrong?
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/nvi-iconv-Call-for-test-tp4698373p4711635.html
Sent from the freebsd-hackers mailing list archive at Nabble.com.
___
freebsd-hackers
chray/nvi2/nvi2-freebsd-2011-08-17.diff.gz
and I tested it with make buildworld.
Note that this version sets WARNS=1 in vi's Makefile, since it's
warning free with clang and gcc.
And there is change to `rescue`'s compilation: now it links to
libcursesw if WITH_ICONV is on.
On Tue, Aug
Zhihao Yuan writes:
> On Sun, Aug 14, 2011 at 10:39 AM, Zhihao Yuan wrote:
>> Hi, hackers:
>>
>> My GSoC2011 project, "Multibyte Encoding Support in Nvi" is ready for
>> testing. The proposal of the project is here:
>> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/zy/1
[...]
> --
> Zhihao Yuan, nickname lichray
> The best way to predict the future is to invent it.
> ___
> 4BSD -- http://4bsd.biz/
>
Let me try to ``quickly'' explain how to involve into the testing.
First, download the patch from
https://github.
Hi, hackers:
My GSoC2011 project, "Multibyte Encoding Support in Nvi" is ready for
testing. The proposal of the project is here:
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/zy/1
The project creates a multibyte fork of the BSD-licensed nvi editor.
It adds only 1 dependence,
hackers,
On Sun, May 08, 2011 at 01:54:18PM -0400, Jason Hellenthal wrote:
>
> hackers,
>
> Test
>
My appologies. this message was never supposed to leave the outbox.
Instead of hitting one key I hit another. Please disregard.
Thanks.
--
Regards, (jhell)
J
hackers,
Test
--
Regards, (jhell)
Jason Hellenthal
___
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"
> > #if defined(KNOB_VALID_ADDRESS)
> > ?
>
I needed something to differentiate between the new CAM changes and the
old (in <= 7.2), so if you have a better knob ...
> Sorry, wrong question. But those who will test on CURRENT should take
> care about it.
why? it com
Hi.
Danny Braniss wrote:
wups, forgot a small little detail:
ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-2.2.3.tar.gz
Is there reason why
cpi->transport = XPORT_ISCSI;
covered by
#if defined(KNOB_VALID_ADDRESS)
?
--
Alexander Motin
___
ill test on CURRENT should take
care about it.
--
Alexander Motin
___
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"
wups, forgot a small little detail:
ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-2.2.3.tar.gz
danny
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "fr
This new version:
o - has some bug fixes.
o - has full header/data digest support, thanks to Daisuke Aoyama
.
o - the limit for the number of sessions is now 64, but can be
raised - eventually via a sysctl call.
o - the number of LUNs is unlimited, but things might get hairy
over
on 13/04/2009 18:51 Andriy Gapon said the following:
> on 13/04/2009 18:48 Sean Bruno said the following:
>> The "self-test" never goes beyond "90%" complete?
>
> Yes, exactly. Even for the short one, which is supposed to complete in 1
> minute:
A
on 13/04/2009 18:48 Sean Bruno said the following:
> On Mon, 2009-04-13 at 10:06 +0300, Andriy Gapon wrote:
>> Smart self test never completing.
>
> The "self-test" never goes beyond "90%" complete?
Yes, exactly. Even for the short one, which is supposed to c
On Mon, 2009-04-13 at 10:06 +0300, Andriy Gapon wrote:
> Smart self test never completing.
The "self-test" never goes beyond "90%" complete?
Sean
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/list
out what might be happening?
>>
>
> I couldn't see anything specifically wrong with the output.
Smart self test never completing.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/free
On Thu, 2009-04-09 at 16:24 +0300, Andriy Gapon wrote:
> I wonder if anybody has an issue like I do:
> http://thread.gmane.org/gmane.linux.utilities.smartmontools/6354
>
> Does anybody has guesses/clues about what might be happening?
>
I couldn't see anything specifically wrong with the output.
I wonder if anybody has an issue like I do:
http://thread.gmane.org/gmane.linux.utilities.smartmontools/6354
Does anybody has guesses/clues about what might be happening?
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebs
Hi,
There is a test that I am doing with FreeBSD and Linux. This test involves
qmail and postfix comparison. Both FreeBSD and Linux seems to have 1024 File
Descriptor limit. (FD_SETSIZE in select.h in FreeBSD) .
To have a better concurrency in qmail on smtp level. I have used a patch named
Omer Faruk Sen wrote:
as you can see there is a big difference in just simple dd test. Is
there additional steps that I can follow to increase performance?
Use a benchmark that matches your actual workload, and then see how
things look. I would be surprised if your target workload was &qu
On Saturday 07 February 2009 09:00:37 Omer Faruk Sen wrote:
> Hi,
>
> I have installed a new server to test performance results. BIOS and
> RAID BIOS is the latest in this server ( Raid controller is a Intel
> SRCSASBB8I )
>
>
>
> # dmesg |grep -i mfi
> mfi0: port
On Sat, 7 Feb 2009, Omer Faruk Sen wrote:
I have installed a new server to test performance results. BIOS and RAID
BIOS is the latest in this server ( Raid controller is a Intel SRCSASBB8I )
Hi Omer--
Comparing I/O and file system performance is a bit fraught with peril,
especially given
Hi,
I have installed a new server to test performance results. BIOS and
RAID BIOS is the latest in this server ( Raid controller is a Intel
SRCSASBB8I )
# dmesg |grep -i mfi
mfi0: port 0x2000-0x20ff mem
0xb8b0-0xb8b3,0xb8b4-0xb8b7 irq 16 at device 0.0 on
pci10
mfi0: Megaraid
html/text/...)
>>
>> There's also a wiki page about testing, which you may want to check out:
>>http://wiki.freebsd.org/TetIntegration
>>
>> I don't really know python nose. I just looked at it quickly and can not see
>> any big benefit compared t
t; - be able to compare different runs with the perl tools
> - be able to generate a lot of different output formats (html/text/...)
>
> There's also a wiki page about testing, which you may want to check out:
>http://wiki.freebsd.org/TetIntegration
>
> I don't really
you may want to check out:
http://wiki.freebsd.org/TetIntegration
I don't really know python nose. I just looked at it quickly and can
not see any big benefit compared to the perl test protocol outlined
above (and the stuff outlined in the wiki looks even more advanced
than th
Hello Hackers and Porters,
I'm currently working on a proposal to the FreeBSD foundation to use
Python Nose as a testing framework for writing tests. If there are any
individuals who are experienced and interested helping review and
provide insight into my plans for using nose as a testing
On Friday 17 October 2008 20:18:20 Igor Pokrovsky wrote:
> I need to check if file is locked or not (with flock) from a shell
> script. I remember there was something but cannot recall what exactly.
> And if possible I do not want to write my own test utility even it
> is several lin
On Friday 17 October 2008, Igor Pokrovsky wrote:
> Hi all!
>
> I need to check if file is locked or not (with flock) from a shell
> script. I remember there was something but cannot recall what exactly.
> And if possible I do not want to write my own test utility even it
> i
Igor Pokrovsky <[EMAIL PROTECTED]> writes:
> I need to check if file is locked or not (with flock) from a shell
> script. I remember there was something but cannot recall what exactly.
> And if possible I do not want to write my own test utility even it
> is several lines in
Hi all!
I need to check if file is locked or not (with flock) from a shell
script. I remember there was something but cannot recall what exactly.
And if possible I do not want to write my own test utility even it
is several lines in length)
Thanks,
-ip
On Wed, Oct 08, 2008 at 04:29:46PM +0300, Volodymyr Kostyrko wrote:
> Hi all.
>
> Does anyone tried to build world with clang (devel/llvm-devel)? I just
> have tested clang on some code from our tree, gzip and bzip2 for
> example. Well... it works. Gzip compiled with clang become faster, bzip2
Hi all.
Does anyone tried to build world with clang (devel/llvm-devel)? I just
have tested clang on some code from our tree, gzip and bzip2 for
example. Well... it works. Gzip compiled with clang become faster, bzip2
don't... Right now I'm playing with world making it compile with clang.
If a
List test. Please IGNORE!
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On 05/16/07 08:49, Larry Rosenman wrote:
On Wed, 16 May 2007, Diomidis Spinellis wrote:
I'm testing the backwards compatibility of the process accounting processing
tools (sa(8) and lastcomm(1)) with the upcoming new acct(5) record format.
If you have root access on a FreeBSD AMD64, Sparc64, i
On Wed, 16 May 2007, Diomidis Spinellis wrote:
I'm testing the backwards compatibility of the process accounting processing
tools (sa(8) and lastcomm(1)) with the upcoming new acct(5) record format.
If you have root access on a FreeBSD AMD64, Sparc64, ia64, or PowerPC machine
please run the sh
Diomidis Spinellis wrote:
> I'm testing the backwards compatibility of the process accounting
> processing tools (sa(8) and lastcomm(1)) with the upcoming new acct(5)
> record format. If you have root access on a FreeBSD AMD64, Sparc64,
> ia64, or PowerPC machine please run the shell script
> http
On 05/16/07 02:35, Diomidis Spinellis wrote:
I'm testing the backwards compatibility of the process accounting
processing tools (sa(8) and lastcomm(1)) with the upcoming new acct(5)
record format. If you have root access on a FreeBSD AMD64, Sparc64,
ia64, or PowerPC machine please run the shel
I'm testing the backwards compatibility of the process accounting
processing tools (sa(8) and lastcomm(1)) with the upcoming new acct(5)
record format. If you have root access on a FreeBSD AMD64, Sparc64,
ia64, or PowerPC machine please run the shell script
http://www.spinellis.gr/FreeBSD/valu
On Thu, 2007-04-05 at 10:08 -0500, Dan Nelson wrote:
> In the last episode (Apr 05), Joe Marcus Clarke said:
> > I noticed something weird with test(1) when I ran across a problem port
> > Makefile. Our test(1) doesn't properly check to make sure there is an
> >
In the last episode (Apr 05), Joe Marcus Clarke said:
> I noticed something weird with test(1) when I ran across a problem port
> Makefile. Our test(1) doesn't properly check to make sure there is an
> operand argument to unary operators like -f. For example:
>
> test -f
&
I noticed something weird with test(1) when I ran across a problem port
Makefile. Our test(1) doesn't properly check to make sure there is an
operand argument to unary operators like -f. For example:
test -f
Will print "TRUE" on FreeBSD. On Solaris, it will die:
/usr/bi
On Thu, 2007-04-05 at 03:12 -0400, Joe Marcus Clarke wrote:
> I noticed something weird with test(1) when I ran across a problem port
> Makefile. Our test(1) doesn't properly check to make sure there is an
> operand argument to unary operators like -f. For example:
>
> tes
I noticed something weird with test(1) when I ran across a problem port
Makefile. Our test(1) doesn't properly check to make sure there is an
operand argument to unary operators like -f. For example:
test -f
Will print "TRUE" on FreeBSD. On Solaris, it will die:
/usr/bi
://people.freebsd.org/~daichi/unionfs/unionfs-procfs-sup.diff
For 6-stable
http://people.freebsd.org/~daichi/unionfs/unionfs6-procfs-sup.diff
The unionfs lovers, would you do test that patch please? If you have
no trouble, it'll be merged to common unionfs patch :)
Thanks
--
Daichi
with committers.
The Bugathon was only announced on -ports because we weren't sure to get
enough src committers, mainly because of the very short notice (it was
decided on friday evening CET).
Anyway, the result of the Test-Bugathon is that around 140 PRs have been
closed (kern:8, bin:2,
Download: http://ftp.intron.ac/tmp/linux_aio-20060817.tar.bz2
Let my patch set keep up with new Linuxolator.
From Beijing, China
Divacky Roman wrote:
On Wed, Aug 09, 2006 at
onv/
It sounds like these patches implement better supports.
Hiro
On Sun, 13 Aug 2006 01:28:17 +0800
"Intron" <[EMAIL PROTECTED]> wrote:
I'm sorry that I send my experimental patch set here to call for test.
But if I send it to freebsd-i18n@, I wonder no one will res
atch set here to call for test.
But if I send it to freebsd-i18n@, I wonder no one will respond to me.
Download: http://ftp.intron.ac/tmp/kiconv_utf8_20060813.tar.bz2
My patch set implements a UTF-8 <-> UTF-16BE converter for iconv in
kernel. It doesn't need kiconv(3) to send unnecessa
You may try these patches, first.
http://people.freebsd.org/~imura/kiconv/
It sounds like these patches implement better supports.
Hiro
On Sun, 13 Aug 2006 01:28:17 +0800
"Intron" <[EMAIL PROTECTED]> wrote:
> I'm sorry that I send my experimental patch set here to c
I'm sorry that I send my experimental patch set here to call for test.
But if I send it to freebsd-i18n@, I wonder no one will respond to me.
Download: http://ftp.intron.ac/tmp/kiconv_utf8_20060813.tar.bz2
My patch set implements a UTF-8 <-> UTF-16BE converter for iconv in
kernel.
#Description
After printing CUPS test page from "lynx localhost:631" I get an error
described below and my computer halts. I get this error quite regulary
after printing smth through CUPS (not always but ap
#Description
After printing CUPS test page from "lynx localhost:631" I get an error
described below and my computer halts. I get this error quite regulary
after printing smth through CUPS (not always but ap
1 - 100 of 384 matches
Mail list logo
