similar to: GE LanPro + SNMP + NUT

Hello All ! Recently I have upgraded NUT to 2.4.1, and now I can't monitor old IMV LanPro S3 UPS with old SNMP board. Previously it is monitored OK, but now snmp-ups refuses to start: [root at perforce /usr/local/etc/nut]# /usr/local/libexec/nut/snmp-ups -a lanproups -DDDDDDD Network UPS Tools - Generic SNMP UPS driver 0.44 (2.4.1) debug level is '7' SNMP UPS driver : entering

[I had a look through the mail archives before sending this, but I didn't find anyone else having this issue.] Has anyone seen this before? I'm almost 100% certain I tested this nut correctly detected OB LB in the past, but when I happened to look at it today, I see it refusing to work -- apparently because the NUT client knows how to ask for RFC1628 OIDs, but not what to do with the

>>>>> Mikko Korpela <mikko.korpela at helsinki.fi> >>>>> on Wed, 18 May 2016 14:18:20 +0300 writes: > On 18/05/16 13:50, Martin Maechler wrote: >>>>>>> Mikko Korpela <mikko.korpela at helsinki.fi> on Wed, 18 >>>>>>> May 2016 13:05:24 +0300 writes: >> >> > I get an error

On 18/05/16 13:50, Martin Maechler wrote: >>>>>> Mikko Korpela <mikko.korpela at helsinki.fi> >>>>>> on Wed, 18 May 2016 13:05:24 +0300 writes: > > > I get an error when running "make check" after building > > R-devel r70629 on Ubuntu 14.04. > > Here are the relevant > > lines in the file

Hi again, The unz connection is non-blocking by default. I checked do_unz which calls R_newunz which calls init_con and the only place in any of those functions that sets 'blocking' is init_con which sets it to FALSE: https://github.com/wch/r-source/blob/0c26529e807a9b1dd65f7324958c17bf72e1de1a/src/main/connections.c#L713 I'll open an issue on R-bugzilla and see if they're

Thank you for the introduction to these recent changes, Martin. I think this was the second time I ran "make check" on that platform (Raspberry Pi 32-bit), and the first time (some months ago) it worked fine. So, that makes it kind of "suddenly", although I must say that my use of "make check" is very irregular. I compared code before and after the split you are

(Belated) thanks for the confirmation, Ista. I just reported this issue on the R bug tracker: https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17412 Best regards, - Mikko -----Alkuper?inen viesti----- L?hett?j?: Ista Zahn [mailto:istazahn at gmail.com] L?hetetty: 7. helmikuuta 2018 17:05 Vastaanottaja: Korpela Mikko (MML) Kopio: r-devel at r-project.org Aihe: Re: [Rd] Possible bug in

On 10/20/2015 05:18 PM, Michael Rutter wrote: > On 10/20/2015 09:51 AM, Mikko Pesari wrote: >> Hi, >> >> In the aftermath of the signing key expiring a couple of days ago, it >> seems that the Ubuntu repositories are no longer signed (there is no >> Release.gpg file present). This is not a good situation as users cannot >> verify the packages' origin.

>>>>> Mikko Korpela <mikko.korpela at helsinki.fi> >>>>> on Wed, 18 May 2016 13:05:24 +0300 writes: > I get an error when running "make check" after building > R-devel r70629 on Ubuntu 14.04. > Here are the relevant > lines in the file "reg-tests-1c.Rout.fail": > > ## m1z uses match(x, *) with

On Thu, Feb 23, 2017 at 03:23:10PM +0100, Martin Maechler wrote: > >>>>> Mikko Korpela <mikko.korpela at helsinki.fi> > >>>>> on Thu, 23 Feb 2017 14:02:58 +0200 writes: > > > With new R releases soon to come, I suggest updating the > > Rcopyright macro in "doc/manual/R-defs.texi" to use year > > 2017. >

> IIRC the client should contact the PDC (domain<0x1b>). But can you > check the logs and see if the clients are trying to change it on > domain<0x1c> (any DC)? Thanks. Can you give me any hints on how to find such information in the log files? My log level is 5, and I can find some password change messages in the logs, but I don't know how to check if they are looking

Dear Sirs, I'm Massimo Zampieri responsible for the software and connectivity accessories for Riello UPS. I would like to list our UPS to NUT. For this porpoise we will provide to you all the information requested as serial protocols, end even some ups in case. We have 2 way to communicate with our ups via RS232 and USB (with our driver, but the source code will be provided in case) and via

On 06/09/2017 10:25 PM, Mikko Perttunen wrote: > On Tegra186, powergating is handled by the BPMP power domain provider > and the "legacy" powergating API is not available. Therefore skip > these calls if we are attached to a power domain. Thanks Mikko, Taken all 3 patches into my tree. Ben. > > Signed-off-by: Mikko Perttunen <mperttunen at nvidia.com> > ---

Bisection status report: The latest commit I have gotten to work is 10842ba074e9 drm/nouveau: remove unused nouveau_fence_work() i.e. the first bad commit is d7722134b825 drm/nouveau: switch over to new memory and vmm interfaces Even with the first one some patches/hacks are needed: - in mmu/gp10b.c, in the constructor we need to select the GM200 path - the GP100 path seems to not to work

> On Feb 29, 2016, at 5:59 AM, Sven Templer <sven.templer at gmail.com> wrote: > > Hello, > > sorry for not being clear enough. > > My problem is represented with the following code, running on OSX: > > mkdir ~/test > ln -s ~/test ~/testlink > touch ~/test/foo > Rscript -e 'Sys.readlink(c("~/test/foo", "~/testlink/foo"));

Hi, you could use "scan" instead, it seems to work fine also when wrapped around "unz". Or, alternatively, you could use "unzip" instead of "unz". It works as expected, i.e. reads the last incomplete line and throws a warning about this. So it seems to me that "unz" creates a non-blocking connection, whereas "unzip" creates a

Thanks Mikko - pieced the 3 links you sent and got new configs... Well..I have successfully got the PAM files so NT users can login from the terminal as well as through the samba shares (no local users required), including using the NT groups to provide share level permissions. Now here is the next battle: 1. I can not access the shares using the linux local accounts --> recieve: the

Hello, sorry for not being clear enough. My problem is represented with the following code, running on OSX: mkdir ~/test ln -s ~/test ~/testlink touch ~/test/foo Rscript -e 'Sys.readlink(c("~/test/foo", "~/testlink/foo")); normalizePath(c("~/test/foo","~/testlink/foo"))' I expected `Sys.readlink` to show the same output as `normalizePath`. Also,

I have just committed your first patch (the strlen() replacement) to R-devel, and will soon put it in R-patched as well. I wont have time to look at this again before the 3.2.4 release, so your file.show() patch isn't going to make it unless someone else gets to it. There's still a faint chance that I'll do more in R-devel before 3.3.0, but I think it's best if there were bug

Hi NUT-Users, we work with a GE LP 33 UPS and an Advanced SNMP WEB Interface Card. This card supports the RFC1628 Definition. So I think this combination work together with NUT and the snmp-driver, correct? I installed the networkupstools on my Debian Sarge with apt-get (nut & nut-snmp). After configuration I start the upsd and upsmon. I get following output in /var/log/syslog: ... Aug 3