similar to: Building nut 2.6.0 on OpenBSD 4.8 - compile issue

On Jul 29, 2013, at 7:56 AM, Charles Lepple wrote: > On Jul 29, 2013, at 6:43 AM, Pavel Potcheptsov (EKTOS) wrote: > >> Hello list, >> I have explored https://github.com/networkupstools/nut repository >> and found that Riello UPS added into list of supported UPS. >> But current package for most distribution it's nut-2.6.5 which >> doesn't have

Gentlemen, I have determined that on my UPS (APC Back-UPS ES 650 FW:818.w1.D USB FW:w1), the variable UPS.PowerSummary.RemainingCapacityLimit is writeable. I am setting this variable to start shutdown a little earlier. Appended is an unconditional patch for apc-hid.h. If, as indicated by the original code, there are APC UPS devices that don't allow setting of this variable, it becomes

Hi, I've just tried to compile dovecot & pigeonhole in my openbsd box, and got this: gcc -DHAVE_CONFIG_H -I. -I../.. -I/home/seajob/build/dovecot-2.1.5 -I/home/seajob/build/dovecot-2.1.5/src/lib -I/home/seajob/build/dovecot-2.1.5/src/lib-dict -I/home/seajob/build/dovecot-2.1.5/src/lib-dns -I/home/seajob/build/dovecot-2.1.5/src/lib-mail

On 6/25/19 8:14 AM, Richard W.M. Jones wrote: > On Tue, Jun 25, 2019 at 02:58:34PM +0200, Martin Kletzander wrote: >> Here are few things I found out when using libnbd that might be perfectly fine >> or maybe just an oversight, but I wanted to point them out. It's nothing major. >> >> When running a program with `nbdkit -U - --run ...`, the $nbd parameter gets

Rather than moving the connection to DEAD, we can just ignore further contexts to the existing command handle, and fail the overall command with the same errno as the failed callback. Eric Blake (2): states: Track cmd->error as errno, not wire value api: Recover from block status callback failure generator/generator | 5 ++- generator/states-reply-simple.c | 2 +-

When we introduced valid_flags, there was an incentive to do as few callbacks as possible, favoring cb(VALID|FREE) calls over the sequence cb(VALID);cb(FREE). To make it work, we set .callback=NULL after an early free, so that the later check during retirement didn't free again. But now that our .free callback is distinct from our other callbacks, there is no longer an advantage to bundling

On Wed, Aug 02, 2023 at 08:50:21PM -0500, Eric Blake wrote: > Previously, we had not been doing any validation of server extent > responses, which means a client query at an offset near the end of the > export can result in a buggy server sending a response longer than the > export length and potentially confusing the client. The NBD spec also > says that an extent length should be

Here are few things I found out when using libnbd that might be perfectly fine or maybe just an oversight, but I wanted to point them out. It's nothing major. When running a program with `nbdkit -U - --run ...`, the $nbd parameter gets expanded to nbd:unix:/path/to/socket. When this string is passed to nbd_connect_uri(), it does not return an error (even though it is not a valid URL), but

Arjen de Korte wrote: > > Author: adkorte-guest > Date: Fri Aug 10 20:23:27 2007 > New Revision: 1041 > > Log: > * drivers/usbhid.[ch]: > - Moved the struct & data for ups.status processing to usbhid.c, since this is only used in there. Subdrivers report the status through text messages, they don't set the status bits directly. > - Rewrote (flattened) the

Hello, llvmdev! Subj, not all UNIX systems have that much number of errnos, so I'm attaching the workaround that i've used to build llvm. Hope this gets resolved. Thanks! -------------- next part -------------- diff --git a/include/llvm/System/system_error.h b/include/llvm/System/system_error.h index 3bfc092..2c0fa5c 100644 --- a/include/llvm/System/system_error.h +++

This morning I finished building and configuring nut 2.6.0 on OpenBSD 4.8, and it is running fine. While I was in the config files, I noticed what looks like it may be a discrepancy between the config file commetns and the configure script default. uspd.conf has the following comment: # STATEPATH <path> # STATEPATH /var/run/nut # # Tell upsd to look for the driver state sockets in

Patches 1 & 2 are rather complex, but the end result is that we pass closures + user_data + free function in single struct parameters as I described previously in this email: https://www.redhat.com/archives/libguestfs/2019-August/msg00210.html Patch 3 adds a convenient FREE_CALLBACK macro which seems a worthwhile simplification if you buy into 1 & 2. Patch 4 adds another macro which is

OpenBSD 6.1/amd64 nut-2.7.4p0 (from OpenBSD package) UPS: Tripp-Lite OMNI1500LCDT I cannot get the driver for the UPS to load without error. Here are the commands, with the output, and the config files: ======================================================= # upsdrvctl start Network UPS Tools - UPS driver controller 2.7.4 Network UPS Tools - Generic HID driver 0.41 (2.7.4) USB communication

Hello again! Thanks to the precious help from Henning Brauer, I managed to solve an issue with my UPS (a rebranded UPS speaking in Ablerex-ese over USB). Under OpenBSD 4.3, the UPS was claimed by HID. Now that I recompiled the kernel, adding a USB_quirk, this is what I get when I insert the USB cable: ugen0 at uhub0 port 2 "UIS_ABLER USB to Serial" rev 1.00/1.00 addr 2 So far, so

Arjen de Korte wrote: > - HIDOpenDevice() will now handle closing the device on reload if > needed, so that HIDCloseDevice() can now really close it and free > the allocated memory for report buffer and parsed report descriptor. If I remember correctly, the old behavior on "reopen" was to keep the previous report descriptor, and try to find a device that matches the previously

The code to detect fragments in checksum_setup() was missing for IPv4 and too eager for IPv6. (It transpires that Windows seems to send IPv6 packets with a fragment header even if they are not a fragment - i.e. offset is zero, and M bit is not set). Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Cc: Wei Liu <wei.liu2@citrix.com> Cc: Ian Campbell <ian.campbell@citrix.com>

I think having this logic buried within libhid/libusb (libusb:libusb_open(), line 179 to 206) is ultimately a mistake, albeit one that I am probably responsible for. Would it make sense to confine libhid to low-level operations, and leave the decision of trying to reopen vs. retrying to open to the high-level driver, in this case usbhid-ups? I envision that the code in usbhid-ups:reconnect_ups()

> Author: aquette > Date: Thu Jun 21 07:43:46 2007 > New Revision: 971 > > Log: > fix communication lost status handling > > Modified: > trunk/ChangeLog > trunk/drivers/usbhid-ups.c > > Modified: trunk/ChangeLog > ============================================================================== > --- trunk/ChangeLog (original) > +++ trunk/ChangeLog

As proposed here: https://www.redhat.com/archives/libguestfs/2019-August/msg00130.html I didn't actually read Eric's replies to that yet because I've been concentrating on writing these patches all day. Anyway here they are and I'll look at what Eric said about the proposal next. Rich.

Hi, Here is the current process list. We can see missing winbind and *mbd processes : [root at dmzrodc ~]# netstat -plaunt | egrep "ntp|bind|named|samba|?mbd" tcp 0 0 0.0.0.0:636 0.0.0.0:* LISTEN 1229/samba tcp 0 0 0.0.0.0:49152 0.0.0.0:* LISTEN 1226/samba tcp 0 0 0.0.0.0:49153 0.0.0.0:* LISTEN 1226/samba tcp 0 0 0.0.0.0:49154 0.0.0.0:* LISTEN 1226/samba tcp 0 0 0.0.0.0:3268