Hello tech@,
Working on something else, this bit of code is somewhat in my way and it
feels like an early testing feature instead of actually being useful.
Is anyone actually using this, or can it be removed?
martijn@
Index: mps.c
George Koehler wrote:
> On Tue, 11 Feb 2020 18:58:48 +0100
> Jeremie Courreges-Anglas wrote:
>
> > So the steps would be:
> > - build and install a new clang
> > - bump the major of libc++, build and install it
> > - rebuild and reinstall clang
> > - build new snap
>
> You are the first
On Tue, 11 Feb 2020 18:58:48 +0100
Jeremie Courreges-Anglas wrote:
> So the steps would be:
> - build and install a new clang
> - bump the major of libc++, build and install it
> - rebuild and reinstall clang
> - build new snap
You are the first person to suggest bumping .so majors; I didn't
On Mon, Feb 10, 2020 at 05:37:04PM -0600, Scott Cheloha wrote:
> This code converts between milliseconds and ticks. If we strip out
> the conversions we can just use milliseconds directly with
> timeout_add_msec(9) and delete the conversion code, too.
I agree.
> This is only built for sparc64.
On Mon, Feb 10, 2020 at 05:28:43PM -0600, Scott Cheloha wrote:
> The parameter name "ms" is misleading. All the calling code uses
> microseconds. I think the author's thought process in choosing that
> name was roughly: "microseconds" -> "Micro Seconds" -> "ms".
>
> In any case, I've renamed
On Tue, Feb 11 2020, "Todd C. Miller" wrote:
> On Tue, 11 Feb 2020 21:44:21 +, Nicholas Marriott wrote:
>
>> Looks like the existing code is OK, you still want to test the original
>> expression even if you are predicting it is false, no?
>
> Right, the code is correct as written.
Woops,
On Tue, 11 Feb 2020 21:44:21 +, Nicholas Marriott wrote:
> Looks like the existing code is OK, you still want to test the original
> expression even if you are predicting it is false, no?
Right, the code is correct as written.
- todd
Looks like the existing code is OK, you still want to test the original
expression even if you are predicting it is false, no?
On Tue, Feb 11, 2020 at 07:33:19PM +0100, Jeremie Courreges-Anglas wrote:
>
> Found while looking at __ISO_C_VISIBLE. I'm not sure which compilers
> would be
Jeremie Courreges-Anglas wrote:
> On Tue, Feb 11 2020, George Koehler wrote:
> > On Tue, 11 Feb 2020 15:20:00 +0100
> > Jeremie Courreges-Anglas wrote:
> >
> >> fwiw I'm already ok with the diff George sent for ports/devel/llvm.
> >> I'm mostly ok with this one but it would be nice to know
On Tue, Feb 11, 2020 at 07:01:28PM +0100, Florian Obser wrote:
> I've been running the base diffs since you posted them. Firefox,
> chrome and mpv still make noise :)
>
> I'm puzzled by this:
>
> $ cat /etc/mixerctl.conf
>
Found while looking at __ISO_C_VISIBLE. I'm not sure which compilers
would be affected. The fallback could simply be
#define __predict_true(exp)(exp)
#define __predict_false(exp) (exp)
but I settled for a minimal change.
ok?
Index: cdefs.h
I've been running the base diffs since you posted them. Firefox,
chrome and mpv still make noise :)
I'm puzzled by this:
$ cat /etc/mixerctl.conf
outputs.master=255,255
record.enable=off
$ mixerctl outputs.master
On Tue, Feb 11 2020, George Koehler wrote:
> On Tue, 11 Feb 2020 15:20:00 +0100
> Jeremie Courreges-Anglas wrote:
>
>> fwiw I'm already ok with the diff George sent for ports/devel/llvm.
>> I'm mostly ok with this one but it would be nice to know whether
>> base-clang can rebuild itself. :)
>
>
On Tue, 11 Feb 2020 15:20:00 +0100
Jeremie Courreges-Anglas wrote:
> fwiw I'm already ok with the diff George sent for ports/devel/llvm.
> I'm mostly ok with this one but it would be nice to know whether
> base-clang can rebuild itself. :)
base-clang can't rebuild itself in the normal way. I
IIUC we should limit the visibility of C features to ANSI C (instead of
C11) for old C++ standards.
I guess this is low priority so I didn't do much testing, but I can do
a base+xenocara build on amd64 and sparc64 if deemed useful.
Thoughts?
Index: cdefs.h
On Tue, Feb 11, 2020 at 04:51:08PM +0100, Tobias Heider wrote:
> Hi,
>
> here are some small improvements for iwm's interrupt handler.
>
> - Hardware errors (r1 == 0x || (r1 & 0xfff0) == 0xa5a5a5a0) should
> be checked in both cases (ict and non-ict).
> - r1 and r2 should be
Hi,
here are some small improvements for iwm's interrupt handler.
- Hardware errors (r1 == 0x || (r1 & 0xfff0) == 0xa5a5a5a0) should
be checked in both cases (ict and non-ict).
- r1 and r2 should be uint32, they are read with bus_space_read_4()
- (Slightly) better explanation for
On Wed, Feb 05, 2020 at 10:32:09PM +0800, Nathanael Rensen wrote:
> When I boot an APU2 using wake-on-lan and then attempt to power off with
> shutdown -hp it wakes itself up again. To prevent this it is necessary to
> clear the I210 PME_STATUS flag. This is described in section 5.6.2 of the
>
On Mon, Feb 03, 2020 at 12:52:05AM +, Jimmy Brush wrote:
> No golang tcp server can be pledged without this change because it
> queries kern.somaxconn before it listens on a tcp socket[1][2][3].
>
> I cannot think of any advantage this change would give an attacker
> who has compromised a
On Wed, Feb 05 2020, Todd Mortimer wrote:
> Hi George,
>
> On Tue, Feb 04, 2020 at 08:39:12PM -0500, George Koehler wrote:
>> Hello tech list,
>>
>> This is a diff for base-clang. It would change the powerpc target to
>> return small structs in registers r3 and r4. This would fix an
>>
On Sat, Feb 08, 2020 at 01:07:01PM +0800, Nathanael Rensen wrote:
> The diff below adds support for the watchdog as found in the embedded
> AMD FCH (fusion controller hub) as found on APU2.
>
> Index: sys/dev/pci/piixpm.c
> ===
> RCS
On Tue, Feb 11, 2020 at 02:03:40PM +0100, Martin Pieuchot wrote:
> On 06/02/20(Thu) 12:08, Martin Pieuchot wrote:
> > As exposed recently via the t_ptrace regression and some make changes an
> > exit status might reported twice to its parent via wait(2).
> >
> > The diff below fixes that by
On 09/02/20(Sun) 16:40, Visa Hankala wrote:
> [...]
> In addition,
> IPL_AUDIO is above IPL_MPFLOOR on some architectures.
That's because audio interrupt handlers have been considered MP-safe, we
now know they aren't 8)
On 06/02/20(Thu) 12:08, Martin Pieuchot wrote:
> As exposed recently via the t_ptrace regression and some make changes an
> exit status might reported twice to its parent via wait(2).
>
> The diff below fixes that by making sure we do not re-parent a child to
> the same parent.
>
> With it the
Hi,
Jan Stary wrote on Mon, Feb 10, 2020 at 01:13:58PM +0100:
> Why does cron(8) and crontab(1) need to setlocale()?
Committed; thanks to millert@ for cross-checking.
Ingo
> Index: cron.c
> ===
> RCS file:
On Mon, Feb 10, 2020 at 01:14:25PM +0100, Mark Kettenis wrote:
> Stefan Sperling schreef op 2020-02-06 12:45:
> > At 36c3 I noticed roaming failures with iwm(4) where we would get stuck
> > trying to roam to a different AP. Debugging this with bluhm@ we found
> > that the reason it gets stuck is a
On Wednesday, January 8, 2020, Abel Abraham Camarillo Ojeda <
acam...@verlet.org> wrote:
>
>
> On Mon, Dec 30, 2019 at 1:24 PM Abel Abraham Camarillo Ojeda <
> acam...@verlet.org> wrote:
>
>> The following enables audio via the dock station port in my thinkpad L460.
>> But, anyone knows if its
27 matches
Mail list logo
