Updating src tree:
P src/lib/libc/rpc/svc_fdset.h
P src/libexec/ld.elf_so/arch/aarch64/mdreloc.c
P src/libexec/ld.elf_so/arch/arm/mdreloc.c
P src/sbin/fsck_lfs/kernelops.c
P src/sys/arch/cobalt/conf/GENERIC
P src/sys/conf/Makefile.kern.inc
P src/sys/dev/raidframe/rf_netbsdkintf.c
P
This is an automatically generated notice of a NetBSD-current/i386
build failure.
The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2020.06.15.16.59.05.
An extract from the build.sh output follows:
hello. If you reboot again, the raid2 will probably look as you
expect. The general procedure for disk replacement is;
1. raidctl -a /dev/newdisk raidset
2. raidctl -F /dev/baddisk raidset (fails the bad disk, uses the spare and
reconstructs to it)
3. Raid is left with a
+ core.
christos
> On Jun 16, 2020, at 3:31 PM, Alexander Nasonov wrote:
>
> Christos Zoulas wrote:
>>
>>
>>> On Jun 16, 2020, at 2:17 PM, Alexander Nasonov wrote:
>>>
>>> If my reading of the current commit guideline is correct, a case
>>> of renaming already released application doesn't
Christos Zoulas wrote:
>
>
> > On Jun 16, 2020, at 2:17 PM, Alexander Nasonov wrote:
> >
> > If my reading of the current commit guideline is correct, a case
> > of renaming already released application doesn't fall into the
> > "obvious" fix because some people can possibly object to breaking
> On Jun 16, 2020, at 2:17 PM, Alexander Nasonov wrote:
>
> If my reading of the current commit guideline is correct, a case
> of renaming already released application doesn't fall into the
> "obvious" fix because some people can possibly object to breaking
> backward compatibility.
You are
I just had another similar hang, this time in git, while trying to
pull pkgsrc/wip:
...
[Switching to LWP 2518 of process 2823]
0x72b102aa87aa in ___lwp_park60 () from /usr/lib/libc.so.12
(gdb) thread apply all bt
Thread 2 (LWP 2823 of process 2823):
#0 0x72b102a4551a in _lwp_wait ()
Christos Zoulas wrote:
> I think that you would agree that owners of applications should be
> allowed to name them as they please. And that me renaming my application
> causes equal "abuse" (inconvenience) to everyone.
If my reading of the current commit guideline is correct, a case
of renaming
On 16.06.2020 16:27, Christos Zoulas wrote:
> In article <02813400-41f9-cec9-84d0-ed3ccd2a8...@netbsd.org>,
> Kamil Rytarowski wrote:
>> -=-=-=-=-=-
>> Perpetuating this Western-centric stereotype in such renames is abusive
>> to the white East people, that used to be on the black skin side of
In article <02813400-41f9-cec9-84d0-ed3ccd2a8...@netbsd.org>,
Kamil Rytarowski wrote:
>-=-=-=-=-=-
>Perpetuating this Western-centric stereotype in such renames is abusive
>to the white East people, that used to be on the black skin side of the
>human history (Slavic ethnicity has etymology in
On Tue, Jun 16, 2020 at 12:18:34AM -0700, Greywolf wrote:
...
> Components:
> /dev/dk0: optimal
> component1: spared
> Spares:
> /dev/dk1: used_spare
...
> I would have expected /dev/dk1 to have shifted up to 'optimal' and component1
> to
> have vanished.
AFAIR
On Tue, Jun 16, 2020 at 08:52:55AM -0300, Jared McNeill wrote:
> This happened on aarch64 -current while running a pkgsrc bulk build:
>
> [ 346117.3280182] panic: kernel diagnostic assertion "amap->am_nused <
> amap->am_maxslot" failed: file "/home/source/ab/HEAD/src/sys/uvm/uvm_amap.c",
> line
On 15.06.2020 21:44, Christos Zoulas wrote:
> Hi Marc,
>
> When I wrote this in 2015 I did not consider the terms blacklist/whitelist
> offensive,
> or associated them with race.
Perpetuating this Western-centric stereotype in such renames is abusive
to the white East people, that used to be on
This happened on aarch64 -current while running a pkgsrc bulk build:
[ 346117.3280182] panic: kernel diagnostic assertion "amap->am_nused < amap->am_maxslot"
failed: file "/home/source/ab/HEAD/src/sys/uvm/uvm_amap.c", line 1506
[ 346117.3380176] cpu4: Begin traceback...
[ 346117.3380176] trace
> On 16. Jun 2020, at 12:42, NetBSD Test Fixture wrote:
>
> This is an automatically generated notice of new failures of the
> NetBSD test suite.
>
> The newly failing test cases are:
>
>fs/vfs/t_full:nfs_fillfs
[snip]
>2020.06.14.23.38.25 kamil src/sys/rump/include/rump/rump.h,v
This is an automatically generated notice of new failures of the
NetBSD test suite.
The newly failing test cases are:
fs/vfs/t_full:nfs_fillfs
fs/vfs/t_io:nfs_extendfile
fs/vfs/t_io:nfs_extendfile_append
fs/vfs/t_io:nfs_holywrite
fs/vfs/t_io:nfs_overwrite512
I don't know what I did to get that volume to recover but ripping
it apart and placing the good component first on reconfiguration
produced a good volume on a rebuild. As I recall it looked a lot like this:
Components:
component0: failed
/dev/wd1c: optimal
Spares:
On Tue, Jun 16, 2020 at 07:43:07AM +0200, Marc Balmer wrote:
> Well, obviously anything with the word black in it must be considered
> racist these days.
Hmm... May be.
Out of the 4k+ times the word occurred majority occurrences were for the
black as in color (say of the terminal). May be we
Hello,
Am 16.06.2020 um 07:43 schrieb Marc Balmer:
Am 16.06.2020 um 04:53 schrieb Mayuresh :
On Mon, Jun 15, 2020 at 03:44:22PM -0400, Christos Zoulas wrote:
We should be all doing whatever we can to correct social/race/gender/sex
injustices/prejudices around us, and every little bit
19 matches
Mail list logo
