Re: acpiconf -s 3 does not call acpi sleep event handlers

[Johannes Lundberg]

On Thu, Aug 2, 2018 at 06:20 Andriy Gapon  wrote:

> On 02/08/2018 01:17, Conrad Meyer wrote:
> > I don't understand the concern.  There is only one listener to the
> > event and it just invokes ReqSleepState, which is responsible for
> > performing all suspend behavior.  The behavior is identical between
> > lid close and acpiconf.
>
> Unless someone is adding a new listener for that event.
>

Exactly my point.


> --
> Andriy Gapon
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: acpiconf -s 3 does not call acpi sleep event handlers

[Andriy Gapon]

On 02/08/2018 01:17, Conrad Meyer wrote:
> I don't understand the concern.  There is only one listener to the
> event and it just invokes ReqSleepState, which is responsible for
> performing all suspend behavior.  The behavior is identical between
> lid close and acpiconf.

Unless someone is adding a new listener for that event.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: how to make ports not install xorg or dependencies

[Mark Linimon]

On Tue, Jul 31, 2018 at 01:13:31PM +0200, Miroslav Lachman wrote:
> As Guido Falsi already said it is not guaranteed that you will not
> have ports with some X libs, because some ports does not have option
> to disable X11 dependencies.

IMHO those ports have bugs.

mcl
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: acpiconf -s 3 does not call acpi sleep event handlers

[Conrad Meyer]

I don't understand the concern.  There is only one listener to the
event and it just invokes ReqSleepState, which is responsible for
performing all suspend behavior.  The behavior is identical between
lid close and acpiconf.

On Wed, Aug 1, 2018 at 3:00 PM, Johannes Lundberg  wrote:
>
>
> On Wed, Aug 1, 2018 at 22:55 Conrad Meyer  wrote:
>>
>> ReqSleepState is the routine that takes care of suspend, not the
>> eventhandler.  I'm not sure what difference the proposed change is
>> supposed to make.
>
>
> Listeners to acpi_sleep_event don’t get the event when suspending with
> acpiconf (but they do when suspending via lid or sleep button).
>
> I think one would expect the same behavior when suspending via command line
> or physical switch.
>
>
>>
>>
>> Best,
>> Conrad
>>
>> On Wed, Aug 1, 2018 at 2:48 PM, Johannes Lundberg 
>> wrote:
>> >
>> >
>> > On Wed, Aug 1, 2018 at 9:15 PM Conrad Meyer  wrote:
>> >>
>> >> It seems deliberate, although the commit message does not call it out
>> >> and the event is perhaps poorly named.  The event currently indicates
>> >> that the lid was closed.  And the final registered eventhandler for
>> >> the event calls ReqSleepState.
>> >>
>> >> The ReqSleepState routine, as well as the userspace ioctl that
>> >> 'acpiconf -s' uses (which just invokes ReqSleepState directly, rather
>> >> than invoking the acpi sleep event), were introduced together in
>> >> r170976.
>> >>
>> >
>> > Unless there's a way of calling suspend properly from the cli (zzz uses
>> > acpiconf...) maybe something like this makes more sense to get the same
>> > behavior on for example lid close as zzz or acpiconf -s 3? (untested)
>> >
>> > diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c
>> > index c1bfd880c89..87b506d6bf5 100644
>> > --- a/sys/dev/acpica/acpi.c
>> > +++ b/sys/dev/acpica/acpi.c
>> > @@ -3700,7 +3700,8 @@ acpiioctl(struct cdev *dev, u_long cmd, caddr_t
>> > addr,
>> > int flag, struct thread *t
>> >  case ACPIIO_REQSLPSTATE:
>> > state = *(int *)addr;
>> > if (state != ACPI_STATE_S5)
>> > -   return (acpi_ReqSleepState(sc, state));
>> > +   return ACPI_SUCCESS(AcpiOsExecute(OSL_NOTIFY_HANDLER,
>> > +   acpi_invoke_sleep_eventhandler, )) ? 0 :
>> > ENXIO;
>> > device_printf(sc->acpi_dev, "power off via acpi ioctl not
>> > supported\n");
>> > error = EOPNOTSUPP;
>> > break;
>> >
>> >
>> >>
>> >> Best,
>> >> Conrad
>> >>
>> >> On Wed, Aug 1, 2018 at 8:05 AM, Johannes Lundberg 
>> >> wrote:
>> >> > Hi
>> >> >
>> >> > As the title says, callbacks registered with
>> >> > EVENTHANDLER_REGISTER(acpi_sleep_event, 
>> >> > does not get called when calling acpiconf -s 3.
>> >> > They do however, when suspending with lid or sleep button.
>> >> >
>> >> > Is this deliberate or an oversight?
>> >> >
>> >> > Cheers
>> >> > ___
>> >> > freebsd-current@freebsd.org mailing list
>> >> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> >> > To unsubscribe, send any mail to
>> >> > "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: acpiconf -s 3 does not call acpi sleep event handlers

[Conrad Meyer]

ReqSleepState is the routine that takes care of suspend, not the
eventhandler.  I'm not sure what difference the proposed change is
supposed to make.

Best,
Conrad

On Wed, Aug 1, 2018 at 2:48 PM, Johannes Lundberg  wrote:
>
>
> On Wed, Aug 1, 2018 at 9:15 PM Conrad Meyer  wrote:
>>
>> It seems deliberate, although the commit message does not call it out
>> and the event is perhaps poorly named.  The event currently indicates
>> that the lid was closed.  And the final registered eventhandler for
>> the event calls ReqSleepState.
>>
>> The ReqSleepState routine, as well as the userspace ioctl that
>> 'acpiconf -s' uses (which just invokes ReqSleepState directly, rather
>> than invoking the acpi sleep event), were introduced together in
>> r170976.
>>
>
> Unless there's a way of calling suspend properly from the cli (zzz uses
> acpiconf...) maybe something like this makes more sense to get the same
> behavior on for example lid close as zzz or acpiconf -s 3? (untested)
>
> diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c
> index c1bfd880c89..87b506d6bf5 100644
> --- a/sys/dev/acpica/acpi.c
> +++ b/sys/dev/acpica/acpi.c
> @@ -3700,7 +3700,8 @@ acpiioctl(struct cdev *dev, u_long cmd, caddr_t addr,
> int flag, struct thread *t
>  case ACPIIO_REQSLPSTATE:
> state = *(int *)addr;
> if (state != ACPI_STATE_S5)
> -   return (acpi_ReqSleepState(sc, state));
> +   return ACPI_SUCCESS(AcpiOsExecute(OSL_NOTIFY_HANDLER,
> +   acpi_invoke_sleep_eventhandler, )) ? 0 :
> ENXIO;
> device_printf(sc->acpi_dev, "power off via acpi ioctl not
> supported\n");
> error = EOPNOTSUPP;
> break;
>
>
>>
>> Best,
>> Conrad
>>
>> On Wed, Aug 1, 2018 at 8:05 AM, Johannes Lundberg 
>> wrote:
>> > Hi
>> >
>> > As the title says, callbacks registered with
>> > EVENTHANDLER_REGISTER(acpi_sleep_event, 
>> > does not get called when calling acpiconf -s 3.
>> > They do however, when suspending with lid or sleep button.
>> >
>> > Is this deliberate or an oversight?
>> >
>> > Cheers
>> > ___
>> > freebsd-current@freebsd.org mailing list
>> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> > To unsubscribe, send any mail to
>> > "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: acpiconf -s 3 does not call acpi sleep event handlers

[Johannes Lundberg]

On Wed, Aug 1, 2018 at 22:55 Conrad Meyer  wrote:

> ReqSleepState is the routine that takes care of suspend, not the
> eventhandler.  I'm not sure what difference the proposed change is
> supposed to make.


Listeners to acpi_sleep_event don’t get the event when suspending with
acpiconf (but they do when suspending via lid or sleep button).

I think one would expect the same behavior when suspending via command line
or physical switch.



>
> Best,
> Conrad
>
> On Wed, Aug 1, 2018 at 2:48 PM, Johannes Lundberg 
> wrote:
> >
> >
> > On Wed, Aug 1, 2018 at 9:15 PM Conrad Meyer  wrote:
> >>
> >> It seems deliberate, although the commit message does not call it out
> >> and the event is perhaps poorly named.  The event currently indicates
> >> that the lid was closed.  And the final registered eventhandler for
> >> the event calls ReqSleepState.
> >>
> >> The ReqSleepState routine, as well as the userspace ioctl that
> >> 'acpiconf -s' uses (which just invokes ReqSleepState directly, rather
> >> than invoking the acpi sleep event), were introduced together in
> >> r170976.
> >>
> >
> > Unless there's a way of calling suspend properly from the cli (zzz uses
> > acpiconf...) maybe something like this makes more sense to get the same
> > behavior on for example lid close as zzz or acpiconf -s 3? (untested)
> >
> > diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c
> > index c1bfd880c89..87b506d6bf5 100644
> > --- a/sys/dev/acpica/acpi.c
> > +++ b/sys/dev/acpica/acpi.c
> > @@ -3700,7 +3700,8 @@ acpiioctl(struct cdev *dev, u_long cmd, caddr_t
> addr,
> > int flag, struct thread *t
> >  case ACPIIO_REQSLPSTATE:
> > state = *(int *)addr;
> > if (state != ACPI_STATE_S5)
> > -   return (acpi_ReqSleepState(sc, state));
> > +   return ACPI_SUCCESS(AcpiOsExecute(OSL_NOTIFY_HANDLER,
> > +   acpi_invoke_sleep_eventhandler, )) ? 0 :
> > ENXIO;
> > device_printf(sc->acpi_dev, "power off via acpi ioctl not
> > supported\n");
> > error = EOPNOTSUPP;
> > break;
> >
> >
> >>
> >> Best,
> >> Conrad
> >>
> >> On Wed, Aug 1, 2018 at 8:05 AM, Johannes Lundberg 
> >> wrote:
> >> > Hi
> >> >
> >> > As the title says, callbacks registered with
> >> > EVENTHANDLER_REGISTER(acpi_sleep_event, 
> >> > does not get called when calling acpiconf -s 3.
> >> > They do however, when suspending with lid or sleep button.
> >> >
> >> > Is this deliberate or an oversight?
> >> >
> >> > Cheers
> >> > ___
> >> > freebsd-current@freebsd.org mailing list
> >> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >> > To unsubscribe, send any mail to
> >> > "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: acpiconf -s 3 does not call acpi sleep event handlers

[Johannes Lundberg]

On Wed, Aug 1, 2018 at 9:15 PM Conrad Meyer  wrote:

> It seems deliberate, although the commit message does not call it out
> and the event is perhaps poorly named.  The event currently indicates
> that the lid was closed.  And the final registered eventhandler for
> the event calls ReqSleepState.
>
> The ReqSleepState routine, as well as the userspace ioctl that
> 'acpiconf -s' uses (which just invokes ReqSleepState directly, rather
> than invoking the acpi sleep event), were introduced together in
> r170976.
>
>
Unless there's a way of calling suspend properly from the cli (zzz uses
acpiconf...) maybe something like this makes more sense to get the same
behavior on for example lid close as zzz or acpiconf -s 3? (untested)

diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c
index c1bfd880c89..87b506d6bf5 100644
--- a/sys/dev/acpica/acpi.c
+++ b/sys/dev/acpica/acpi.c
@@ -3700,7 +3700,8 @@ acpiioctl(struct cdev *dev, u_long cmd, caddr_t addr,
int flag, struct thread *t
 case ACPIIO_REQSLPSTATE:
state = *(int *)addr;
if (state != ACPI_STATE_S5)
-   return (acpi_ReqSleepState(sc, state));
+   return ACPI_SUCCESS(AcpiOsExecute(OSL_NOTIFY_HANDLER,
+   acpi_invoke_sleep_eventhandler, )) ? 0 :
ENXIO;
device_printf(sc->acpi_dev, "power off via acpi ioctl not
supported\n");
error = EOPNOTSUPP;
break;



> Best,
> Conrad
>
> On Wed, Aug 1, 2018 at 8:05 AM, Johannes Lundberg 
> wrote:
> > Hi
> >
> > As the title says, callbacks registered with
> > EVENTHANDLER_REGISTER(acpi_sleep_event, 
> > does not get called when calling acpiconf -s 3.
> > They do however, when suspending with lid or sleep button.
> >
> > Is this deliberate or an oversight?
> >
> > Cheers
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "
> freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: acpiconf -s 3 does not call acpi sleep event handlers

[Conrad Meyer]

It seems deliberate, although the commit message does not call it out
and the event is perhaps poorly named.  The event currently indicates
that the lid was closed.  And the final registered eventhandler for
the event calls ReqSleepState.

The ReqSleepState routine, as well as the userspace ioctl that
'acpiconf -s' uses (which just invokes ReqSleepState directly, rather
than invoking the acpi sleep event), were introduced together in
r170976.

Best,
Conrad

On Wed, Aug 1, 2018 at 8:05 AM, Johannes Lundberg  wrote:
> Hi
>
> As the title says, callbacks registered with
> EVENTHANDLER_REGISTER(acpi_sleep_event, 
> does not get called when calling acpiconf -s 3.
> They do however, when suspending with lid or sleep button.
>
> Is this deliberate or an oversight?
>
> Cheers
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: can't make installworld

[AN]

Glen:

On Wed, Aug 1, 2018 at 10:49 AM, Glen Barber  wrote:
> Hmm, gross.  :(
>
> Was there a previous error during a prior installworld attempt?
>
> As a quick workaround regarding this particular binary missing, you
> could:
>
>  # make -C /usr/src/usr.bin/true install

This worked and allowed installworld to finish successfully.


> If that fails, please reply with the list in CC, as there may be
> something more serious going on here.
>
> Glen
>
> On Wed, Aug 01, 2018 at 10:45:17AM -0400, AN wrote:
>> Hey Glen:
>>
>> Thanks for the reply.
>>
>> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
>>
>> On Wed, Aug 1, 2018 at 10:41 AM, Glen Barber  wrote:
>> > On Wed, Aug 01, 2018 at 10:29:18AM -0400, AN wrote:
>> >> FreeBSD BSD12 12.0-CURRENT FreeBSD 12.0-CURRENT #16 r335386: Tue Jun
>> >> 19 19:57:51 EDT 2018
>> >> root@BSD12:/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL  amd64
>> >>
>> >> # cat /etc/master.passwd | grep ntp
>> >> ntpd:*:123:123::0:0:NTP Daemon:/var/db/ntp:/usr/sbin/nologin
>> >>
>> >>
>> >> # cat /etc/group | grep ntp
>> >> ntpd:*:123:
>> >>
>> >
>> > This is a particularly annoying problem since 20180719.
>> >
>> >>
>> >> # svnlite info
>> >> Path: .
>> >> Working Copy Root Path: /usr/src
>> >> URL: svn://svn.freebsd.org/base/head
>> >> Relative URL: ^/head
>> >> Repository Root: svn://svn.freebsd.org/base
>> >> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
>> >> Revision: 337003
>> >> Node Kind: directory
>> >> Schedule: normal
>> >> Last Changed Author: manu
>> >> Last Changed Rev: 337000
>> >> Last Changed Date: 2018-07-31 15:14:52 -0400 (Tue, 31 Jul 2018)
>> >>
>> >>
>> >> For several days I have been trying to update the world without
>> >> success.  In single user mode, trying to make installworld I get the
>> >> following:
>> >>
>> >> >>>Installworld check
>> >> ...
>> >> Required tool true not found in path.
>> >>
>> >>
>> >> Any idea how to fix this?
>> >
>> > What does your $PATH contain?
>> >
>> > Glen
>> >


Thanks for your help and quick response.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: can't make installworld

[Ian Lepore]

On Wed, 2018-08-01 at 14:41 +, Glen Barber wrote:
> On Wed, Aug 01, 2018 at 10:29:18AM -0400, AN wrote:
> > 
> > FreeBSD BSD12 12.0-CURRENT FreeBSD 12.0-CURRENT #16 r335386: Tue
> > Jun
> > 19 19:57:51 EDT 2018
> > root@BSD12:/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL  amd64
> > 
> > # cat /etc/master.passwd | grep ntp
> > ntpd:*:123:123::0:0:NTP Daemon:/var/db/ntp:/usr/sbin/nologin
> > 
> > 
> > # cat /etc/group | grep ntp
> > ntpd:*:123:
> > 
> This is a particularly annoying problem since 20180719.
> 

It's not a problem at all, we are just in one of the rare times when
you actually have to follow the recommended update procedure exactly,
without shortcuts. In particular, you cannot skip the pre-world
"mergemaster -p" step as described in the handbook or at the bottom of
UPDATING.

-- Ian

> > 
> > 
> > # svnlite info
> > Path: .
> > Working Copy Root Path: /usr/src
> > URL: svn://svn.freebsd.org/base/head
> > Relative URL: ^/head
> > Repository Root: svn://svn.freebsd.org/base
> > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> > Revision: 337003
> > Node Kind: directory
> > Schedule: normal
> > Last Changed Author: manu
> > Last Changed Rev: 337000
> > Last Changed Date: 2018-07-31 15:14:52 -0400 (Tue, 31 Jul 2018)
> > 
> > 
> > For several days I have been trying to update the world without
> > success.  In single user mode, trying to make installworld I get
> > the
> > following:
> > 
> > > 
> > > > 
> > > > > 
> > > > > Installworld check
> > ...
> > Required tool true not found in path.
> > 
> > 
> > Any idea how to fix this?
> What does your $PATH contain?
> 
> Glen
> 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

acpiconf -s 3 does not call acpi sleep event handlers

[Johannes Lundberg]

Hi

As the title says, callbacks registered with
EVENTHANDLER_REGISTER(acpi_sleep_event, 
does not get called when calling acpiconf -s 3.
They do however, when suspending with lid or sleep button.

Is this deliberate or an oversight?

Cheers
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: can't make installworld

[Glen Barber]

On Wed, Aug 01, 2018 at 10:29:18AM -0400, AN wrote:
> FreeBSD BSD12 12.0-CURRENT FreeBSD 12.0-CURRENT #16 r335386: Tue Jun
> 19 19:57:51 EDT 2018
> root@BSD12:/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL  amd64
> 
> # cat /etc/master.passwd | grep ntp
> ntpd:*:123:123::0:0:NTP Daemon:/var/db/ntp:/usr/sbin/nologin
> 
> 
> # cat /etc/group | grep ntp
> ntpd:*:123:
> 

This is a particularly annoying problem since 20180719.

> 
> # svnlite info
> Path: .
> Working Copy Root Path: /usr/src
> URL: svn://svn.freebsd.org/base/head
> Relative URL: ^/head
> Repository Root: svn://svn.freebsd.org/base
> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Revision: 337003
> Node Kind: directory
> Schedule: normal
> Last Changed Author: manu
> Last Changed Rev: 337000
> Last Changed Date: 2018-07-31 15:14:52 -0400 (Tue, 31 Jul 2018)
> 
> 
> For several days I have been trying to update the world without
> success.  In single user mode, trying to make installworld I get the
> following:
> 
> >>>Installworld check
> ...
> Required tool true not found in path.
> 
> 
> Any idea how to fix this?

What does your $PATH contain?

Glen



signature.asc
Description: PGP signature

can't make installworld

[AN]

FreeBSD BSD12 12.0-CURRENT FreeBSD 12.0-CURRENT #16 r335386: Tue Jun
19 19:57:51 EDT 2018
root@BSD12:/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL  amd64

# cat /etc/master.passwd | grep ntp
ntpd:*:123:123::0:0:NTP Daemon:/var/db/ntp:/usr/sbin/nologin


# cat /etc/group | grep ntp
ntpd:*:123:


# svnlite info
Path: .
Working Copy Root Path: /usr/src
URL: svn://svn.freebsd.org/base/head
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 337003
Node Kind: directory
Schedule: normal
Last Changed Author: manu
Last Changed Rev: 337000
Last Changed Date: 2018-07-31 15:14:52 -0400 (Tue, 31 Jul 2018)


For several days I have been trying to update the world without
success.  In single user mode, trying to make installworld I get the
following:

>>>Installworld check
...
Required tool true not found in path.


Any idea how to fix this?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Status of OpenSSL 1.1.1

[Eric McCorkle]

On 08/01/2018 09:02, Warner Losh wrote:
> 
> 
> On Wed, Aug 1, 2018, 12:31 PM Eric McCorkle  > wrote:
> 
> Hi folks,
> 
> I'm wondering what's the status of OpenSSL 1.1.1 integration into base?
> More specifically, is there a repo or a branch that's started the
> integration?  I'm aware of the wiki page and the list of port build
> issues, but that seems to be based on replacing the base OpenSSL with a
> port build (similar to the way one replaces it with LibreSSL).
> 
> I have some work I'd like to do that's gating on sorting out the
> kernel/loader crypto situation, and I'd very much like to see OpenSSL
> 1.1.1 get merged, so I can start to look into doing that.
> 
> 
> There are patches to use bear SSL for the loader. OpenSSL is simply too
> large to use due to limits the loader operates under.

I was going to look into the feasibility of doing something like what
LibreSSL does with portable, where they extract a subset of the full
library designed to be embedded in the kernel, loader, etc.

I think it ought to be possible to do something like that, but it really
ought to be done in a tree with 1.1.1 integrated.



signature.asc
Description: OpenPGP digital signature

Re: Status of OpenSSL 1.1.1

[Warner Losh]

On Wed, Aug 1, 2018, 12:31 PM Eric McCorkle  wrote:

> Hi folks,
>
> I'm wondering what's the status of OpenSSL 1.1.1 integration into base?
> More specifically, is there a repo or a branch that's started the
> integration?  I'm aware of the wiki page and the list of port build
> issues, but that seems to be based on replacing the base OpenSSL with a
> port build (similar to the way one replaces it with LibreSSL).
>
> I have some work I'd like to do that's gating on sorting out the
> kernel/loader crypto situation, and I'd very much like to see OpenSSL
> 1.1.1 get merged, so I can start to look into doing that.
>

There are patches to use bear SSL for the loader. OpenSSL is simply too
large to use due to limits the loader operates under.

Warner

Incidentally, if there's something I can do to help out with integrating
> 1.1.1 into base, I'd potentially be interested.
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Status of OpenSSL 1.1.1

[Eric McCorkle]

Hi folks,

I'm wondering what's the status of OpenSSL 1.1.1 integration into base?
More specifically, is there a repo or a branch that's started the
integration?  I'm aware of the wiki page and the list of port build
issues, but that seems to be based on replacing the base OpenSSL with a
port build (similar to the way one replaces it with LibreSSL).

I have some work I'd like to do that's gating on sorting out the
kernel/loader crypto situation, and I'd very much like to see OpenSSL
1.1.1 get merged, so I can start to look into doing that.

Incidentally, if there's something I can do to help out with integrating
1.1.1 into base, I'd potentially be interested.



signature.asc
Description: OpenPGP digital signature

Error occurs in the VirtualBox VM installed from the vmdk image when "close" is pressed on the VM window

[Yuri]

I installed this VMDK image 
https://download.freebsd.org/ftp/snapshots/VM-IMAGES/12.0-CURRENT/amd64/Latest/FreeBSD-12.0-CURRENT-amd64.vmdk.xz 
rom Jul 26.


Once it boots, pressing "close" causes the error.


Yuri


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"