similar to: 2.8.0 roadmap

Hi, this is the 2nd part of the PowerChain RFC. 2011/6/13 Arnaud Quette <aquette.dev at gmail.com> > As already presented, the links below will describe in details the > PowerChain notion: > > https://wiki.ubuntu.com/ServerOneiricInfraPower > https://wiki.ubuntu.com/ServerOneiricInfraPower#PowerChain%20design >

Hey, I'm scheduling a 2.6.2 release for max. September 15. The content will be lighter than first expected with 2.8.0 (see below). This includes the current trunk plus: - merge the nut-scanner branch, - some snmp-ups improvements (sysOID matching for init stage) and some more MIBs, - a first complete version of the nut-ipmipsu driver, - the new jNut Java binding, - preliminary support of

As already presented, the links below will describe in details the PowerChain notion: https://wiki.ubuntu.com/ServerOneiricInfraPower https://wiki.ubuntu.com/ServerOneiricInfraPower#PowerChain%20design https://wiki.ubuntu.com/ServerOneiricInfraPower#PowerChain%20implementation The idea here is to add a new variable, named 'device.parent', so that every device can reference its parent. I

Fellows, I've been caught by real life, and didn't find time to share / discuss this with you. I've been attending UDS Oneiric, from May 9 to 13 in Budapest, and had a chance to present and complete some ideas around NUT: https://wiki.ubuntu.com/ServerOneiricInfraPower The end target is to have NUT ready to address infrastructures, both static like data-centers and flexible like

I upgraded an operating system to openSUSE 42.2, kernel 4.4 and recompiled nut 2.7.4. ./configure, make clean and make went well, but make install failed. Make reports Making install in clients make[1]: Entering directory '/mnt/home/rprice/nut/nut-2.7.4.dev/clients' make[2]: Entering directory '/mnt/home/rprice/nut/nut-2.7.4.dev/clients' /usr/bin/mkdir -p '/usr/lib64'

I think this trunk-to-branch interior merge should be clean, but the merge logic correctly identifies some missing files in the reposurgeon output (checked in -pre7 and -pre4). They are in SVN on that branch, though (ignoring .gitignore for the time being). I only see one java file in scripts/java/jNut/src/main/java/org/networkupstools/jnut/ from reposurgeon.

I've been looking around but haven't been able to find even a mention of a client on Android. Does one exist? -Parker Reed -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20180626/4b7c026e/attachment.html>

Hello, I am embarking on a project using NUT on a Raspberry pi talking to a Cyberpower UPS for storm event (e.g. hurricane) power management at a remote location. I would prefer to use Java as a programming platform for this application, but I see the NUT Java project has not been updated in a long time (7 years?!). Is it being tested with new NUT releases or has been abandoned? If the later, I

Hi All, Perhaps you have seen, a few weeks ago, a release of jNut-0.2 which introduces nut-scanner capability to jNut java library, see http://networkupstools.org/download.html#_java_packages. With this package have been released jNutWebApi, a java web archive which uses jNut to present some UPSD and nut-scanner data on the form of a web service. This package is a maven-based project

[when replying to the list, please use "reply all" - the list does not mangle Reply-To headers] On Jun 26, 2018, at 3:14 PM, Parker Reed <parker.l.reed at gmail.com> wrote: > > I've been looking around but haven't been able to find even a mention of a client on Android. Does one exist? I am not aware of one, but it seems like it shouldn't be too hard to write

Hi, I''m very interested in migrating some apps to ruby and wxRuby. Is there a rough estimate of when wxRuby will support wxWidgets 2.6.0? Are there specific tasks that require volunteers?

Ben, For us the two important feature to have will be : 0 - Continue to improve gNFS server (and make it works on AIX and Solaris) 1 - Continuous Data Replication (over WAN) 2 - CIFS/Active Directory Support (native support) And then : -Object storage (unified file and object) -Geo-replication to Amazon S3 (unify public and private cloud) -Continuous Data Protection -Improved User

Here''s another general comment for discussion... The bottom of page 18 in the Xen Roadmap proposal recommends considering how to "export byte stream (TCP) data between domains in a high performance fashion." For communications that occur between domains on a single physical machine, it would seem logical to setup a new address and protocol family within Linux that could be

Ian, Thank you for your detailed report. > As a user space application, Qemu can''t run in the stub domain > directly, but requires an operating system kernel. The neatest way of > doing this would be to link qemu against `minios'', which is > effectively a library operating system for just this purpose. Since > minios makes use of a broad range of libc calls, it

Dear Experts, IHAC who interested in Sun''s xVM server. They would like to know when the xVM server will be available on Solaris. Thanks. Regards, Ray

Hi, Now that compiz 0.7 is out what are the plans for the 0.8 release. It would be also interesting to know when the finial 0.8 release is planned, to make it easier for distributions to decide if they want to start updating to 0.7/git in there development trees or not.

On May 9, 2012, at 2:00 PM, dag at cray.com wrote: > We also can't afford to have compiler builds break because someone > upstream decided to change an API we rely on. We make monthly releases. > We have to have some control over when we introduce such changes. There's no great solution. But you'll have to make a tradeoff between being engaged in the development process vs

On May 11, 2012, at 8:31 AM, dag at cray.com wrote: > Andrew Trick <atrick at apple.com> writes: > >> If all goes well, I expect SD scheduling to be removed by 3.3. That has not been discussed. > > Is there any particular reason to remove it? Something has to convert > from SDNodes to MachineInstrs so we'll at least need the "original > order" SUnit

Hi Dave, >>> Actually, we don't have any problem releasing tests. We have done so >>> before when sending patches. The problem is the people we got the >>> tests from. Some are from proprietary test suites, others are from >>> sensitive codes, etc. It's often not up to us at all. >> >> I completely understand. Why don't we start by

On Mar 19, 2015, at 2:00 PM, Arnaud Quette <arnaud.quette at gmail.com> wrote: > So is everything good to go from your PoV Charles? Yes, except if we aren't going to fix the NSS SSL issue for this release, we should do two things before releasing: ? Add a note to UPGRADING explaining the problem and the -D workaround ? Branch and plan to release 2.7.3.1 (or similar) once we fix