On 10.11.2020 10:55, matthew green wrote:
> at this point the right thing is to revert, and then proceed
> with the discussion. if you can convince people that your
> idea is of merit, you can put it back in, but right now that
> is quite clearly not a shared sentiment.
OK.
Hello,
Warp is a real-time space war game that doesn't get boring very quickly.
Read warp.doc and the manual page for more information.
games/warp originally distributed with 4.3BSD-Reno, is back to the BSD
world via NetBSD. Its remnants (and the status of being missing) were
still documented in
On 18.10.2020 15:00, Paul Goyette wrote:
>
> I'm getting lost inside all this elf stuff :)
ptrace is not really pluggable and the maintenance burden to have part
of it as loadable modules questions the usefulness of this.
My request to demodularize it stands.
signature.asc
Description:
On 17.10.2020 18:53, Paul Goyette wrote:
> Kamil wrote:
>
>> This, I propose to do the following:
>>
>> 1. Remove the modularization of ptrace. This does not affect the compat
>> layers that still can and should be in my opinion modular.
>>
>> 2. Either abandon 'no PTRACE' or make it complete
On 17.10.2020 15:32, Christos Zoulas wrote:
> In article ,
> Paul Goyette wrote:
>> For a custom kernel build with ``no options PTRACE'' and ``no options
>> COREDUMP'' defined, and sources updated on 2020-10-16 at 13:18:24 UTC,
>> I get the following linker error:
>>
>> # link
On 29.09.2020 16:09, Roy Marples wrote:
> # link gdb/gdb
> /usr/tools/bin/x86_64--netbsd-clang++ --sysroot=/
> -Wl,--warn-shared-textrel -Wl,-z,relro -pie -o gdb gdb.o
> -Wl,-rpath-link,/lib -L=/lib
> -L/home/roy/src/hg/src/external/gpl3/gdb/lib/libgdb/obj.amd64 -lgdb
>
On 12.09.2020 10:33, matthew green wrote:
> hi folks.
>
>
> i've switched x86 and arm to GCC 9. several others are liking
> to switch soon, and they will all likely need clean builds to
> be stable.
>
> please send email here or to me or send-pr for problems.
>
> thanks!
>
>
> .mrg.
>
On 21.08.2020 17:10, Patrick Welche wrote:
> pbulk was idle stuck building kio at
>
> dbus24339 0.0 0.0 182156 9644 pts/6 Il 12:45PM 0:00.04
> /usr/pkg/bin/cmake -E cmake_autogen
>
On 14.07.2020 06:28, Martin Husemann wrote:
> On Tue, Jul 14, 2020 at 02:49:00AM +0200, Joerg Sonnenberger wrote:
>> Replacing malloc is just as invalid from a strict standard compliance
>> perspective, so *shrug*
>
> Why is that?
>
> We have e.g. shells/standalone-tcsh that does it. Is it
On 06.07.2020 14:31, Robert Elz wrote:
> Date:Sun, 5 Jul 2020 23:11:44 +0200
> From: Kamil Rytarowski
> Message-ID: <57c15085-dc7d-6c71-1b26-a402839ba...@netbsd.org>
>
> | This is extended to the behavior of "at dlclose() or a normal
On 05.07.2020 19:42, Robert Elz wrote:
> Date:Tue, 30 Jun 2020 13:43:00 +0200
> From: Kamil Rytarowski
> Message-ID:
>
> I had been ignoring this discussion, but on cleaning up some
> unread list e-mail, I saw this nonsense, and this is
On 30.06.2020 15:49, Valery Ushakov wrote:
> On Tue, Jun 30, 2020 at 15:09:14 +0200, Kamil Rytarowski wrote:
>
>> On 30.06.2020 14:24, Valery Ushakov wrote:
>>> On Tue, Jun 30, 2020 at 13:43:00 +0200, Kamil Rytarowski wrote:
>>>
>>>> On 30.06.2020 05:16,
On 30.06.2020 14:24, Valery Ushakov wrote:
> On Tue, Jun 30, 2020 at 13:43:00 +0200, Kamil Rytarowski wrote:
>
>> On 30.06.2020 05:16, Jason Thorpe wrote:
>>>
>>>> On Jun 29, 2020, at 5:13 PM, Kamil Rytarowski wrote:
>>>>
>>>>>
>
On 30.06.2020 05:16, Jason Thorpe wrote:
>
>> On Jun 29, 2020, at 5:13 PM, Kamil Rytarowski wrote:
>>
>>>
>>> The atexit() function shall register the function pointed to by func, to be
>>> called without arguments at normal program terminatio
On 29.06.2020 21:36, Jason Thorpe wrote:
>
>> On Jun 29, 2020, at 9:09 AM, Rhialto wrote:
>>
>> But I wonder if there is any standards text that
>> describes whether this particular scenario is supposed to work.
>
> Quoting from "The Open Group Base Specifications Issue 7, 2018 edition"
>
>
>
On 29.06.2020 00:50, Joerg Sonnenberger wrote:
> On Mon, Jun 29, 2020 at 12:34:31AM +0200, Kamil Rytarowski wrote:
>> On 28.06.2020 23:57, Joerg Sonnenberger wrote:
>>> On Sun, Jun 28, 2020 at 11:48:15PM +0200, Kamil Rytarowski wrote:
>>>> On 28.06.2020 2
On 28.06.2020 23:57, Joerg Sonnenberger wrote:
> On Sun, Jun 28, 2020 at 11:48:15PM +0200, Kamil Rytarowski wrote:
>> On 28.06.2020 23:29, Joerg Sonnenberger wrote:
>>> It is fundamentally wrong to use a handler in a library that can be
>>> unloaded. Some syste
On 28.06.2020 23:29, Joerg Sonnenberger wrote:
> It is fundamentally wrong to use a handler in a library that can be
> unloaded. Some systems hack around that problem by looping over all
> atexit handlers on dlclose, but that's exactly that, a costly hack. The
> most common way this triggers is a
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 use
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 article notes that blocklist is a confusing term as a list of
blocks and notes a proposal of denylist.
On 15.06.2020 21:10, Christos Zoulas wrote:
> https://www.theregister.com/2020/06/15/github_replaces_master_with_main/
>
> christos
>
>> On Jun 15, 2020, at 2:35 PM
lwp_exit() used to work for curlwp and !curlwp.
There is a regression that there was introduced code called from
lwp_exit() calling lwp_thread_cleanup(l) that asserts curlwp,
effectively enforcing lwp_exit() to be operational for curlwp only.
This was introduced by:
commit
On 23.05.2020 02:08, matthew sporleder wrote:
> On Fri, May 22, 2020 at 5:57 PM Greg A. Woods wrote:
>>
>> At Thu, 21 May 2020 15:11:41 -0400, Andrew Cagney
>> wrote:
>> Subject: Re: github.com/NetBSD/src 5 days old?
>>>
>>> The details are all found here:
>>>
I'm hitting a kernel crash that is reproduced by syzkaller in several
reports, e.g.:
[ 98.5966763] panic: kernel diagnostic assertion "hispgrp->pg_jobc > 0"
failed: file
"/syzkaller/managers/netbsd-kmsan/kernel/sys/kern/kern_proc.c", line 1529
[ 98.6166813] cpu1: Begin traceback...
[
On 17.04.2020 18:46, Robert Elz wrote:
> Date:Fri, 17 Apr 2020 16:49:40 +0200
> From: Kamil Rytarowski
> Message-ID:
>
> | I use this in ksh and I find this as a useful feature.
>
> If you just mean that you use noclobber mode (set -C) f
On 16.04.2020 21:10, Robert Elz wrote:
> Date:Thu, 16 Apr 2020 19:27:48 +0200
> From:Joerg Sonnenberger
> Message-ID: <20200416172748.ga86...@bec.de>
>
> | What is the point of this "restriction"? They wanted to make a set flag,
> | but allow people to not have
On 13.04.2020 14:28, Robert Elz wrote:
> This panic has been plauging the b5 ATF tests for a while now, it
> is from the "tracer_sysctl_lookup_without_duplicates" ATF test.
>
> The backtrace isn't all that helpful, child_return() calls eventswitch()
> calls KASSERT() - boom.
>
> (After that
On 05.04.2020 01:14, NetBSD Test Fixture wrote:
> 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.04.04.21.36.15.
>
> An extract from the build.sh output
On 04.04.2020 21:44, Thomas Klausner wrote:
> Hi!
>
> I've just fixed the compat32* packages so that they built for me. Then
> I tried running two programs with wip/wine64 (see
> https://blog.netbsd.org/tnf/entry/porting_wine_to_amd64_on1)
>
> The first one is a c# application. wine automatically
On 24.03.2020 15:27, Robert Elz wrote:
> Are there any objections to making strerror_lr() user visible?
There are no users.
Our strerror() is already thread-safe.
signature.asc
Description: OpenPGP digital signature
On 16.03.2020 18:14, Tobias Nygren wrote:
> Hi,
>
> Got a new one today. Copied manually:
>
> panic: kernel diagnostic assertion (opte (& PTE_A | PTE_B)) != PTE_A pmap.c
> line 4029
> kern_assert()
> pmap_sync_pv()
> pmap_pp_remove()
> uvm_anon_dispose()
> uvm_anon_freelst()
> amap_wipeout()
>
On 11.03.2020 21:44, Chavdar Ivanov wrote:
>> The test program below shows the difference. On NetBSD-9 you have many
>> "resched", as expected. On NetBSD-current you have none.
> As you say, I don't get any output from your program on -current from
> yesterday.
>
We definitely need ATF tests as
On 07.03.2020 20:43, Andreas Gustafsson wrote:
> The NetBSD Test Fixture wrote:
>> cc1: all warnings being treated as errors
>> *** [t_ptrace_wait.o] Error code 1
>
> The compiler error message did not appare because it was too far
> back from the end of the build log (5149 lines):
>
>
On 01.03.2020 23:31, Andrew Doran wrote:
> On Sun, Mar 01, 2020 at 03:26:12PM +0200, Andreas Gustafsson wrote:
>
>> 55020 dbregs_dr?_dont_inherit_lwp test cases fail on real hardware
>
> I've not personally looked into these yet.
>
In 55020 we strangely (unless there is a bug that I
On 01.03.2020 14:26, Andreas Gustafsson wrote:
> Hi all,
>
> NetBSD-current is again suffering from a number of regressions. The
> last time the ATF tests showed zero unexpected failures on real amd64
> hardware was on Dec 12, and the sparc, sparc64, pmax, and hpcmips
> tests have all been
On 23.02.2020 12:57, matthew green wrote:
> i'm not sure if this patch is right, but i'm reasonably confident
> it is and it fixes the build breakage i'm seeing:
>
>https://www.netbsd.org/~mrg/lfs.buildfix.diff
>
>
> .mrg.
>
While there,
There are LFS UBSan reports (for the sources from
On 21.02.2020 06:59, Taylor R Campbell wrote:
> This morning at 15:48 UTC, while aiming to add some dtrace probes to
> the buffer cache (normally a totally innocuous change so I wasn't
> paying very close attention), I committed a mistake that totally
> screwed it up -- causing bbusy to return a
On 18.02.2020 00:09, Chavdar Ivanov wrote:
> Mono-6.6 - the previous build from 28th of January on the same machine
> running -current of the time - works fine.
>
>
>
Please update your pkgsrc tree as there were runtime fixes.
signature.asc
Description: OpenPGP digital signature
On 16.02.2020 17:44, Tom Ivar Helbekkmo wrote:
> Thomas Klausner writes:
>
>>> To generate a diff of this commit:
>>> cvs rdiff -u -r1.164 -r1.165 src/lib/libpthread/pthread.c
>>> cvs rdiff -u -r1.101 -r1.102 src/lib/libpthread/pthread_int.h
>>> cvs rdiff -u -r1.74 -r1.75
On 16.02.2020 14:54, Thomas Klausner wrote:
> On Sun, Feb 16, 2020 at 01:02:32PM +0100, Kamil Rytarowski wrote:
>> On 16.02.2020 12:48, Thomas Klausner wrote:
>>> Hi!
>>>
>>> I've upgraded kernel + userland to 9.99.47/amd64.
>>> Now mpv (built on 9.
On 16.02.2020 12:48, Thomas Klausner wrote:
> Hi!
>
> I've upgraded kernel + userland to 9.99.47/amd64.
> Now mpv (built on 9.99.43) dumps core immediately.
>
Does it work if you just revert this:
Modified Files:
src/lib/libpthread: pthread.c pthread_int.h pthread_mutex.c
cedure
> so I don't have to keep referring to my old notes every time :)
>
> -Dustin
>
> On Mon, Feb 10, 2020 at 6:57 PM Kamil Rytarowski wrote:
>>
>> On 11.02.2020 01:49, Dustin Marquess wrote:
>>> I'm trying to upgrade a VM from a 9.99.10 install that was b
On 11.02.2020 01:49, Dustin Marquess wrote:
> I'm trying to upgrade a VM from a 9.99.10 install that was built
> around Sep 2th to a 9.99.46 install compiled yesterday.
>
> I installed the new kernel and modules and rebooted into the new
> kernel / old userland. Once done, almost everything
On 07.02.2020 00:18, NetBSD Test Fixture wrote:
> 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.02.06.20.17.04.
>
> An extract from the build.sh output
On 17.01.2020 20:29, Andrew Doran wrote:
> Hi,
>
> On Fri, Jan 17, 2020 at 07:58:52PM +0100, Kamil Rytarowski wrote:
>
>> My system with i915 survived with these changes applied (credit
>> riastradh@ for hints):
>>
>> https://www.netbsd.org/~ka
On 16.01.2020 23:17, Andrew Doran wrote:
> Hi,
>
> On Thu, Jan 16, 2020 at 06:14:40PM +, Chavdar Ivanov wrote:
>
>> Today's update brought 9.99.38, which fails to boot on my HP Envy 17
>> laptop with Intel 530 graphics and NVidia GeForce; latter not used. The
>> system uses EFI boot and the
On 09.01.2020 09:35, Andreas Gustafsson wrote:
> The i386 build is still failing as of source date 2020.01.09.04.04.01:
>
> --- dependall-exec_elf32 ---
> /tmp/bracket/build/2020.01.09.04.04.01-i386/src/sys/kern/core_elf32.c: In
> function 'coredump_note_elf32':
>
>
On 27.12.2019 02:30, Andrew Doran wrote:
> Hi Michael,
>
> On Thu, Dec 26, 2019 at 11:04:12AM -0800, Michael Cheponis wrote:
>
>> what does this mean? (Received last night on RPi 3B+ that has been h/w
>> stable):
>>
>> panic: kernel diagnostic assertion "uvmexp.swpgonly + npages <=
>>
On 02.12.2019 20:10, Andrew Doran wrote:
> Hello,
>
> In light of the recent discussion, and having asked Jaromir his thoughts on
> the subject, we both think it's time to enable this by default, so it gets
> wider testing. Is there a good reason not to?
>
> Cheers,
> Andrew
>
There were
On 13.11.2019 23:34, Christos Zoulas wrote:
> In article <20191113222728.ga79...@bec.de>,
> Joerg Sonnenberger wrote:
>> On Wed, Nov 13, 2019 at 10:24:21PM -, Christos Zoulas wrote:
>>> I don't want processes to die of fail to start because I am extracting
>>> a tar file and I happen to be
Fixed in:
src/tests/lib/libc/sys/t_ptrace_wait.c r.1.141
src/tests/lib/libc/sys/t_ptrace_wait.h r.1.18
On 12.11.2019 18:34, Paul Goyette wrote:
> I've confirmed that these failures occur with builds from before
> my most recent changes. So, as Kamil indicated (and Joerg on
> IRC), it ain't my
The problem is in ATF tests with assumptions that are no longer valid.
We are working on this. The right fix is to improve the tests.
On 12.11.2019 13:53, Paul Goyette wrote:
> Hmmm, this might be my fault. Checking/bisecting now...
>
> On Tue, 12 Nov 2019, NetBSD Test Fixture wrote:
>
>>
On 12.11.2019 09:26, NetBSD Test Fixture wrote:
> This is an automatically generated notice of new failures of the
> NetBSD test suite.
>
> The newly failing test cases are:
>
> lib/libc/sys/t_ptrace_wait3:thread_concurrent_signals
>
On 06.11.2019 21:03, Frank Kardel wrote:
> When bulk building pkgsrc boost libs 1.71.0 fails to compile with:
>
> In file included from /usr/include/stddef.h:37,
> from /usr/include/g++/cstddef:50,
> from ./boost/config/compiler/gcc.hpp:165,
>
On 31.10.2019 01:16, Kamil Rytarowski wrote:
> On 30.10.2019 14:49, SAITOH Masanobu wrote:
>> Hi.
>>
>> Today, I updated three amd64 machines to the latest -current and
>> all of them didn't boot. All of them use "options KUBSAN". Two of
>> them s
On 30.10.2019 14:49, SAITOH Masanobu wrote:
> Hi.
>
> Today, I updated three amd64 machines to the latest -current and
> all of them didn't boot. All of them use "options KUBSAN". Two of
> them stuck at after "loading /var/db/entropy-file" and another
> machine reset after loading the kernel.
On 23.10.2019 10:46, Kamil Rytarowski wrote:
> On 23.10.2019 06:33, Thomas Klausner wrote:
>> Hi!
>>
>> Yesterday evening's current with:
>>
>> build.sh -j 32 -x -V MKDEBUG=yes -V MKDEBUGLIB=yes -V MKLLVM=yes -T
>> /usr/obj/tools.gcc -m amd64 -O /usr/
On 23.10.2019 06:33, Thomas Klausner wrote:
> Hi!
>
> Yesterday evening's current with:
>
> build.sh -j 32 -x -V MKDEBUG=yes -V MKDEBUGLIB=yes -V MKLLVM=yes -T
> /usr/obj/tools.gcc -m amd64 -O /usr/obj/src.amd64 -D
> /usr/obj/amd64.gcc.20191022 -R /usr/obj/amd64.gcc.20191022.release
>
On 21.10.2019 18:30, Joerg Sonnenberger wrote:
> On Mon, Oct 21, 2019 at 06:29:18AM -0700, Hisashi T Fujinaka wrote:
>> On Mon, 21 Oct 2019, Martin Husemann wrote:
>>
>>> On Mon, Oct 21, 2019 at 11:54:44AM +0200, J. Hannken-Illjes wrote:
Somewhere between Netbsd-8 and NetBSD-9 "tar" changed
I have bumped the number of threads in the t_ptrace_wait* LWP tests from
3 to 100. Each thread attempts to generate 1 or 2 SIGTRAP. 100 threads
struggling to emit 100 sigtraps generates complexity that affects timing
of execution.
Please report back whether the execution on low-end setups or
On 24.09.2019 10:27, Patrick Welche wrote:
> Just found a netbsd.0.core left behind at the time daily would have run,
> which would have coincided with a pbulk run (judging from just how many
> nbmake processe there are.)
>
> (Yesterday's -current/amd64)
>
> crash> bt
> _KERNEL_OPT_NARCNET() at
On 23.09.2019 09:02, Kamil Rytarowski wrote:
> On 23.09.2019 08:26, Kamil Rytarowski wrote:
>> On 23.09.2019 04:41, NetBSD Test Fixture wrote:
>>> This is an automatically generated notice of a NetBSD-current/i386
>>> build failure.
>>>
>>> The fail
On 23.09.2019 08:26, Kamil Rytarowski wrote:
> On 23.09.2019 04:41, NetBSD Test Fixture wrote:
>> This is an automatically generated notice of a NetBSD-current/i386
>> build failure.
>>
>> The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
>
On 23.09.2019 04:41, NetBSD Test Fixture wrote:
> 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 2019.09.22.23.34.13.
>
> An extract from the build.sh output
On 22.09.2019 23:33, Brad Spencer wrote:
>
> I committed a change today to add USE_SHLIBDIR=yes to the libraries used
> by /sbin/{zfs,mount_zfs,zpool}. The general effect will be to move the
> libraries from /usr/lib to /lib and put compatibility links in place so
> that things, say in /usr/pkg,
On 23.09.2019 00:21, Brett Lymn wrote:
>
> Folks,
>
> I have been sloppy with my memory allocations and use in hte libcurses
> testframe which, though the code seems to work, some tests fail when
> jemalloc is enabled. I am trying to work out where to look but it is
> difficult becuse there are
On 21.09.2019 18:18, Robert Elz wrote:
> Date:Sat, 21 Sep 2019 15:40:49 + (UTC)
> From:NetBSD Test Fixture
> Message-ID: <156908044959.2857.11788397410553967...@babylon5.netbsd.org>
>
> | The newly failing test cases are:
> |
> |
On 13.09.2019 04:29, Emmanuel Dreyfus wrote:
> I committed multiboot 2 support for x86 bootloaders. This enable booting
> Xen from a EFI system.
>
> That this also require a kernel change, otherwise the NetBSD dom0
> crashes at startup because it fails to detect ACPI.
>
On 11.09.2019 18:51, Kamil Rytarowski wrote:
> I've fixes few LSan issues and pushed patches upstream.
>
> I've precompiled and uploaded the patched version of the toolchain here:
>
> http://cdn.netbsd.org/pub/NetBSD/misc/kamil/llvm-clang-compilerrt-10.0.0beta_2019-09-11.tar.bz2
I've fixes few LSan issues and pushed patches upstream.
I've precompiled and uploaded the patched version of the toolchain here:
http://cdn.netbsd.org/pub/NetBSD/misc/kamil/llvm-clang-compilerrt-10.0.0beta_2019-09-11.tar.bz2
$ cat leak.c
#include
void *p;
int main() {
p = malloc(7);
p =
On 07.09.2019 01:08, Kamil Rytarowski wrote:
> I could backport LSan/LLVM for NetBSD-9 if there would be a request.
> However before that I would prefer to address the mentioned
> false-positive from the atexit(3) callback. I have originally
> rescheduled it for NetBSD-10.
I spe
On 07.09.2019 01:07, Kamil Rytarowski wrote:
> On 07.09.2019 00:41, Thomas Klausner wrote:
>> On Sat, Sep 07, 2019 at 12:36:49AM +0200, Kamil Rytarowski wrote:
>>> Sanitizing compiler is available without MKSANITIZER.
>>
>> I tried (on 9.99.10 from Aug 26):
>>
&
On 07.09.2019 00:41, Thomas Klausner wrote:
> On Sat, Sep 07, 2019 at 12:36:49AM +0200, Kamil Rytarowski wrote:
>> Sanitizing compiler is available without MKSANITIZER.
>
> I tried (on 9.99.10 from Aug 26):
>
> wiz@yt:~> clang -fsanitize=address -g memory-leak.c
On 07.09.2019 00:14, Thomas Klausner wrote:
> On Fri, Sep 06, 2019 at 09:19:49PM +0200, Kamil Rytarowski wrote:
>> On 06.09.2019 21:02, Kamil Rytarowski wrote:
>>> On 06.09.2019 20:57, Thomas Klausner wrote:
>>>> On Fri, Sep 06, 2019 at 08:01:13PM +0200, Kamil Rytarow
On 06.09.2019 21:02, Kamil Rytarowski wrote:
> On 06.09.2019 20:57, Thomas Klausner wrote:
>> On Fri, Sep 06, 2019 at 08:01:13PM +0200, Kamil Rytarowski wrote:
>>> On 06.09.2019 19:46, Thomas Klausner wrote:
>>>> On Fri, Sep 06, 2019 at 03:11:55PM +0200, Kamil Ry
On 06.09.2019 20:57, Thomas Klausner wrote:
> On Fri, Sep 06, 2019 at 08:01:13PM +0200, Kamil Rytarowski wrote:
>> On 06.09.2019 19:46, Thomas Klausner wrote:
>>> On Fri, Sep 06, 2019 at 03:11:55PM +0200, Kamil Rytarowski wrote:
>>>> The only supported combinati
On 06.09.2019 19:46, Thomas Klausner wrote:
> On Fri, Sep 06, 2019 at 03:11:55PM +0200, Kamil Rytarowski wrote:
>> The only supported combination is:
>>
>> HAVE_LLVM=yes MKSANITIZER=yes MKGCC=no MKLLVM=yes
>
> So I tried the suggested combination, and i
On 06.09.2019 14:57, Thomas Klausner wrote:
> On Fri, Sep 06, 2019 at 01:00:07PM +0100, Roy Marples wrote:
>> On 06/09/2019 11:34, Thomas Klausner wrote:
>>> I guess I have to turn off the gcc build as well, but for now I'd like
>>> to have both compilers...
>>
>> I've not been able to build both
On 29.08.2019 00:24, Riccardo Mottola wrote:
> Hi!
>
> I updated current and did a rebuild of the user base. LLVM excluded.
>
> I am used to get sometimes a couple of extra files, but this time, I got
> a huge amount.
>
> === 438 extra files in DESTDIR =
> Files in DESTDIR but
On 25.08.2019 23:42, Thomas Klausner wrote:
> On Sun, Aug 25, 2019 at 05:32:32PM +0200, Kamil Rytarowski wrote:
>> On 25.08.2019 09:31, Thomas Klausner wrote:
>>> On Sun, Aug 25, 2019 at 08:09:06AM +0200, Kamil Rytarowski wrote:
>>>> On 24.08.2019 14:51, Kamil Rytarow
On 25.08.2019 17:32, Kamil Rytarowski wrote:
> On 25.08.2019 09:31, Thomas Klausner wrote:
>> On Sun, Aug 25, 2019 at 08:09:06AM +0200, Kamil Rytarowski wrote:
>>> On 24.08.2019 14:51, Kamil Rytarowski wrote:
>>>> On 24.08.2019 10:08, Thomas Klausner wrote:
>>&g
On 25.08.2019 09:31, Thomas Klausner wrote:
> On Sun, Aug 25, 2019 at 08:09:06AM +0200, Kamil Rytarowski wrote:
>> On 24.08.2019 14:51, Kamil Rytarowski wrote:
>>> On 24.08.2019 10:08, Thomas Klausner wrote:
>>>> On Sat, Aug 24, 2019 at 08:49:59AM +0200, Thomas Klausn
On 24.08.2019 14:51, Kamil Rytarowski wrote:
> On 24.08.2019 10:08, Thomas Klausner wrote:
>> On Sat, Aug 24, 2019 at 08:49:59AM +0200, Thomas Klausner wrote:
>>> On Fri, Aug 23, 2019 at 04:19:25PM +0200, Kamil Rytarowski wrote:
>>>> I will try to reproduce and fix i
On 24.08.2019 10:08, Thomas Klausner wrote:
> On Sat, Aug 24, 2019 at 08:49:59AM +0200, Thomas Klausner wrote:
>> On Fri, Aug 23, 2019 at 04:19:25PM +0200, Kamil Rytarowski wrote:
>>> I will try to reproduce and fix it.
>>
>> I saw you committed a fix, I'
On 23.08.2019 16:10, Thomas Klausner wrote:
> On Fri, Aug 23, 2019 at 04:03:01PM +0200, Kamil Rytarowski wrote:
>> On 23.08.2019 11:41, Thomas Klausner wrote:
>>> With a cvs checkout from about an our ago, an amd64 build failed for
>>> me:
>>>
>>> ---
On 23.08.2019 11:41, Thomas Klausner wrote:
> With a cvs checkout from about an our ago, an amd64 build failed for
> me:
>
> --- dependall-safestack-m32 ---
> /usr/src/sys/external/bsd/compiler_rt/dist/lib/safestack/safestack.cc:271:23:
> error: constructor priorities from 0 to 100 are reserved
On 10.08.2019 15:51, Andreas Gustafsson wrote:
> NetBSD Test Fixture wrote:
>> An extract from the build.sh output follows:
>
> More relevant error messages:
>
>--- dependall-gpl3 ---
>In file included from
>
On 21.06.2019 18:09, 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_vnops:ext2fs_rename_dir
> fs/vfs/t_vnops:ext2fs_rename_reg_nodir
> fs/vfs/t_vnops:ffs_rename_dir
On 01.06.2019 12:01, matthew green wrote:
> so, i just updated a few X11 packages in -current. as part
> of testing, i ran them on the sandy bridge laptop i've seen
> display glitches with the new intel driver on (mate-terminal).
>
> these glitches are now gone.
>
> can anyone with intel driver
On 01.06.2019 11:51, Robert Elz wrote:
> Does anyone know of any reason that would not work? Or have any objections
> to moving in that direction?(After NetBSD-9 is branched).
>
I would try to consul this with pooka@, even if he is inactive.
The selling point of rump was that it was
On 01.06.2019 06:57, Robert Elz wrote:
> Date:Sat, 1 Jun 2019 01:37:38 + (UTC)
> From:NetBSD Test Fixture
> Message-ID: <155935305832.14526.4119478232545999...@babylon5.netbsd.org>
>
>
> | --- dependall-tests ---
> | *** [t_hid] Error code 1
> |
On 29.05.2019 11:41, Kamil Rytarowski wrote:
> On 29.05.2019 09:12, Martin Husemann wrote:
>> Hey folks,
>>
>> I would like to get your feedback about the current state of the base X11,
>> as there have been lots of threads about various issues and I have lost
&g
On 19.05.2019 17:33, Christos Zoulas wrote:
> In article <76d02b7c-6408-1836-b247-0b5951c8a...@gmx.com>,
> Kamil Rytarowski wrote:
>> -=-=-=-=-=-
>> -=-=-=-=-=-
>>
>> On 18.05.2019 17:21, Martin Husemann wrote:
>>> On Fri, May 17, 2019 at 12:15:16PM
On 18.05.2019 17:21, Martin Husemann wrote:
> On Fri, May 17, 2019 at 12:15:16PM -0500, David Young wrote:
>> On Fri, May 17, 2019 at 05:19:40PM +0100, Patrick Welche wrote:
>>> What should one do about
>>>
>>> UBSan: Undefined Behavior in
>>>
On 12.05.2019 08:09, Martin Husemann wrote:
> On Sat, May 11, 2019 at 11:25:42PM +0100, Chavdar Ivanov wrote:
>> There is definitely some recent problem with the new Intel driver. A few
>> days ago, still under 8.99.37, it worked very well for me (Intel 530).
>> glmark2 completed with no problems,
On 11.05.2019 04:54, Kamil Rytarowski wrote:
> On 10.05.2019 08:29, matthew green wrote:
>> this is probably the recently discussed intel driver issues.
>> i've added a build option to use the older driver.
>>
>> can you try build with INTEL_DRIVER_DATE=2014. jmake sur
On 10.05.2019 08:29, matthew green wrote:
> this is probably the recently discussed intel driver issues.
> i've added a build option to use the older driver.
>
> can you try build with INTEL_DRIVER_DATE=2014. jmake sure you
> clean src/external/mit/xorg/server/drivers/xf86-video-intel or
> the
On 10.05.2019 21:04, Mayuresh wrote:
> On Sat, May 11, 2019 at 12:05:03AM +0530, Mayuresh wrote:
>> pxe_call.c:(.text.pxe_api_call+0x12): undefined reference to
>> `__stack_chk_guard'
>
> PKGSRC_USE_SSP=no makes it go away, but that gives rise to following
> errors that weren't present when it
I've upgraded to NetBSD 8.99.38 on two laptops with Intel GPU.
On one of the I can observe kind of 'splashes' when typing text or
switching windows.
Hardware (dmesg on an older revision):
https://dmesgd.nycbug.org/index.cgi?do=view=2967
It's tolerable as there no crashes so far.
The other one
On 03.05.2019 11:20, NetBSD Test Fixture wrote:
> This is an automatically generated notice of new failures of the
> NetBSD test suite.
>
> The newly failing test cases are:
>
> lib/libc/sys/t_ptrace_wait3:bytes_transfer_alignment_piod_read_auxv
>
1 - 100 of 199 matches
Mail list logo
