macro 'FUSE_OPT_KEY'
> #define FUSE_OPT_KEY(t, k) { t, -1, k }
> ^~
> main.cpp:138:5: note: insert an explicit cast to silence this issue
> FUSE_OPT_KEY("-h", KEY_HELP),
> ^~~
Mark Kettenis wrote:
> The UEFI firmware for the MACCHIATObin implements the EFI Random
> Number Generator Protocol. That makes it possible to implement the
> mdrandom() function for arm64's EFIBOOT. The random data is XORed
> onto the buffer so bad random data can't hurt us.
>
> The code is w
The UEFI firmware for the MACCHIATObin implements the EFI Random
Number Generator Protocol. That makes it possible to implement the
mdrandom() function for arm64's EFIBOOT. The random data is XORed
onto the buffer so bad random data can't hurt us.
The code is written such that it can be easily d
p:138:5: note: insert an explicit cast to silence this issue
FUSE_OPT_KEY("-h", KEY_HELP),
^
--8<--
Full log at:
https://junkpile.org/p/failures/i386-20180407/archivers/fuse-zip.log
On Fri, 6 Apr 2018 09:28:54 -0500
Scott Cheloha wrote:
> So that your stats stay correct if the system clock is changed.
>
> This is simple enough to suggest that it's correct at a glance,
> but I have no hardware to test this with. Can anyone confirm that
> this works?
No regressions.
Greetin
I have an RK3399 system that has two RTCs. One of those is the RTC
integrated on the RK808 PMIC that is a companion chip to the RK3399.
The second one is an ISL1208 I2C chip. Only the ISL1208 is battery
powered, so obviously we want to use that one. But rkpmic(4) attaches
after islrtc(4) on this
> Date: Wed, 4 Apr 2018 11:56:28 +0200 (CEST)
> From: Mark Kettenis
>
> With the growing popularity of SoCs, external PHYs are making a bit of
> a comeback. In quite a few cases I'm seeing rgephy(4) show up twice,
> once on address 0 and once on some other address. But there is only
> one PHY s
On Sat, 07 Apr 2018 10:46:01 +0200, Anton Lindqvist wrote:
> Since patch(1) no longer invokes ed(1), pathnames.h can be removed.
> _PATH_TMP is still used inside patch.c but including paths.h is
> sufficient.
OK millert@
- todd
On 2018/04/07 13:33, Claudio Jeker wrote:
> On Sat, Apr 07, 2018 at 11:51:39AM +0100, Stuart Henderson wrote:
> > On 2018/04/07 12:29, Peter J. Philipp wrote:
> > > Hi,
> > >
> > > I've been running iked for a while now and have been able to guess which
> > > iked
> > > belongs to which rdomain b
On Fri, 6 Apr 2018, Jonathan Gray wrote:
> On Thu, Apr 05, 2018 at 09:57:17PM +0200, Stefan Fritsch wrote:
> > Print the error code if hardware initialization failed.
> >
> > If EM_DEBUG is defined, print the phy/mac type during attach.
>
> ok jsg@
>
> Though these are just enum values we assig
On Fri, 6 Apr 2018, Jonathan Gray wrote:
> On Thu, Apr 05, 2018 at 09:57:23PM +0200, Stefan Fritsch wrote:
> > Add another magic 1ms delay that seems to help with some remaining
> > issues on an HP elitebook 820 G3 with i219LM. A printf() at the same
> > place helps, too.
>
> Could you explain wh
On Sat, Apr 07, 2018 at 11:51:39AM +0100, Stuart Henderson wrote:
> On 2018/04/07 12:29, Peter J. Philipp wrote:
> > Hi,
> >
> > I've been running iked for a while now and have been able to guess which
> > iked
> > belongs to which rdomain by the cpu counter but as I'm using the other iked
> > mo
On Sat, Apr 07, 2018 at 12:29:37PM +0200, Peter J. Philipp wrote:
> I introduce the -r flag to fstat in order to display rdomains on sockets in
> order to find the right iked. The fix is simple but because some peoples
> scripts may depend on the old output I made it an extra flag.
Is is a rdomai
On 2018/04/07 12:29, Peter J. Philipp wrote:
> Hi,
>
> I've been running iked for a while now and have been able to guess which iked
> belongs to which rdomain by the cpu counter but as I'm using the other iked
> more the cpu counter is about the same and it's confusing when I have to
> restart i
On Wed, Apr 04, 2018 at 07:18:43PM +0200, Tobias Stoeckmann wrote:
> On Wed, Apr 04, 2018 at 01:30:52PM +0200, Theo Buehler wrote:
> > > +/* convert uint64_t to base N string */
> > >
> > > char *
> > > -ulton(long unsigned int n, int base)
> > > +u64ton(uint64_t n, int base)
> > > {
> > > cha
Hi,
I've been running iked for a while now and have been able to guess which iked
belongs to which rdomain by the cpu counter but as I'm using the other iked
more the cpu counter is about the same and it's confusing when I have to
restart iked with route exec.
I introduce the -r flag to fstat in
On Wed, Apr 04, 2018 at 01:30:52PM +0200, Theo Buehler wrote:
> > +/* convert uint64_t to base N string */
> >
> > char *
> > -ulton(long unsigned int n, int base)
> > +u64ton(uint64_t n, int base)
> > {
> > char *p;
> > static char buf [20];
>
> I don't think it's actually an issue sin
Hi,
Since patch(1) no longer invokes ed(1), pathnames.h can be removed.
_PATH_TMP is still used inside patch.c but including paths.h is
sufficient.
Comments? OK?
diff --git usr.bin/patch/patch.c usr.bin/patch/patch.c
index fef7df6466e..af142599340 100644
--- usr.bin/patch/patch.c
+++ usr.bin/patc
Hello,
Yesterday I wrote to misc@ with this:
https://marc.info/?l=openbsd-misc&m=152302592426018&w=2
I apologize with the inline paste, thunderbird is just not good enough for
this stuff.
Anyhow I have produced this patch after upgrading the 6.2 box to 6.3. It all
works now:
Here is my config
19 matches
Mail list logo
