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

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

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

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

Re: how to make ports not install xorg or dependencies

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

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

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,

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

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

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

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

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

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

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

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

Re: can't make installworld

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

Re: can't make installworld

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

acpiconf -s 3 does not call acpi sleep event handlers

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 ___

Re: can't make installworld

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

can't make installworld

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: #

Re: Status of OpenSSL 1.1.1

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

Re: Status of OpenSSL 1.1.1

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

Status of OpenSSL 1.1.1

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

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

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