Re: [Nut-upsuser] usbhid-ups not loading with Arduino Leonardo on Ubuntu 23.10
"Is it possible I need to compile NUT myself instead of using the Ubuntu package?" Certainly! For me, it's very rare that I install anything that isn't compiled from source. As long as you have compilers and any prerequisite packages in place, it's close to a trivial process. - Tim On October 29, 2023 10:17:20 PM EDT, Kelly Byrd wrote: >> VID 2341 doesn't show up in the NUT Git source tree. >I was curious about this so just searched for Arduino and then 2341. I >found a few hits, but the interesting one was in nut/drivers >/arduino-hid.c > >I don't know enough about the project to know what a "subdriver" (that's >what the comments says) is, but it looks to me like there's at least some >people that have thought about Arduino support since 2021. > >Is it possible I need to compile NUT myself instead of using the Ubuntu >package? > > >On Sun, Oct 29, 2023 at 6:46 PM Charles Lepple wrote: > >> > On Oct 29, 2023, at 9:25 PM, Kelly Byrd wrote: >> > >> > I have seen reports of folks claiming this just worked for them out of >> the box, >> >> Here you're referring to just making things work on Windows or macOS, >> right? I don't think it will be quite as simple with NUT, mostly because >> the NUT drivers are trying to expose all of the variables and commands, >> rather than just the simple shutdown bits. >> >> I'm not sure where a generic HID PDC driver sits in the priority list at >> the moment, but IIRC the current driver is still fairly tightly coupled to >> the USB VID and resulting model-specific mappings. So once you get the >> permissions worked out, you would still need a new source file that maps >> the HID Usage "paths" to NUT variable names. It's one of those things that >> in hindsight, it would have been great to fall back to a generic mapping >> that just looks at the OB and LB bits, but real-world UPSes are messy, and >> we would have needed those model-specific mappings to be able to >> distinguish things like input and output voltage. >> >> That said, if you change the VID/PID to something supported already, >> things just might work. The "Couldn't retrieve descriptors" is likely a >> result of the driver dropping root privileges, then not having enough >> permissions to write to the /dev/bus/usb node to request the HID >> descriptor. I don't know how your VID/PID got into the udev rules file - >> VID 2341 doesn't show up in the NUT Git source tree. >> >> -- >> Charles Lepple >> clepple@gmail >> >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] usbhid-ups not loading with Arduino Leonardo on Ubuntu 23.10
> VID 2341 doesn't show up in the NUT Git source tree. I was curious about this so just searched for Arduino and then 2341. I found a few hits, but the interesting one was in nut/drivers /arduino-hid.c I don't know enough about the project to know what a "subdriver" (that's what the comments says) is, but it looks to me like there's at least some people that have thought about Arduino support since 2021. Is it possible I need to compile NUT myself instead of using the Ubuntu package? On Sun, Oct 29, 2023 at 6:46 PM Charles Lepple wrote: > > On Oct 29, 2023, at 9:25 PM, Kelly Byrd wrote: > > > > I have seen reports of folks claiming this just worked for them out of > the box, > > Here you're referring to just making things work on Windows or macOS, > right? I don't think it will be quite as simple with NUT, mostly because > the NUT drivers are trying to expose all of the variables and commands, > rather than just the simple shutdown bits. > > I'm not sure where a generic HID PDC driver sits in the priority list at > the moment, but IIRC the current driver is still fairly tightly coupled to > the USB VID and resulting model-specific mappings. So once you get the > permissions worked out, you would still need a new source file that maps > the HID Usage "paths" to NUT variable names. It's one of those things that > in hindsight, it would have been great to fall back to a generic mapping > that just looks at the OB and LB bits, but real-world UPSes are messy, and > we would have needed those model-specific mappings to be able to > distinguish things like input and output voltage. > > That said, if you change the VID/PID to something supported already, > things just might work. The "Couldn't retrieve descriptors" is likely a > result of the driver dropping root privileges, then not having enough > permissions to write to the /dev/bus/usb node to request the HID > descriptor. I don't know how your VID/PID got into the udev rules file - > VID 2341 doesn't show up in the NUT Git source tree. > > -- > Charles Lepple > clepple@gmail > > ___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] usbhid-ups not loading with Arduino Leonardo on Ubuntu 23.10
> On Oct 29, 2023, at 9:25 PM, Kelly Byrd wrote: > > I have seen reports of folks claiming this just worked for them out of the > box, Here you're referring to just making things work on Windows or macOS, right? I don't think it will be quite as simple with NUT, mostly because the NUT drivers are trying to expose all of the variables and commands, rather than just the simple shutdown bits. I'm not sure where a generic HID PDC driver sits in the priority list at the moment, but IIRC the current driver is still fairly tightly coupled to the USB VID and resulting model-specific mappings. So once you get the permissions worked out, you would still need a new source file that maps the HID Usage "paths" to NUT variable names. It's one of those things that in hindsight, it would have been great to fall back to a generic mapping that just looks at the OB and LB bits, but real-world UPSes are messy, and we would have needed those model-specific mappings to be able to distinguish things like input and output voltage. That said, if you change the VID/PID to something supported already, things just might work. The "Couldn't retrieve descriptors" is likely a result of the driver dropping root privileges, then not having enough permissions to write to the /dev/bus/usb node to request the HID descriptor. I don't know how your VID/PID got into the udev rules file - VID 2341 doesn't show up in the NUT Git source tree. -- Charles Lepple clepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] usbhid-ups not loading with Arduino Leonardo on Ubuntu 23.10
> Here you're referring to just making things work on Windows or macOS, right? I don't think it will be quite as simple with NUT, mostly because the NUT drivers are trying to expose all of the variables and commands, rather than just the simple shutdown bits. By "work with on Windows on macOS" I mean: "both Windows and MacOS show the correct "AC present/charging vs "no AC/discharging" status as well as showing the expected remaining status and percent charged. > I'm not sure where a generic HID PDC driver sits in the priority list at the moment, but IIRC the current driver is still fairly tightly coupled to the USB VID and resulting model-specific mappings > f you change the VID/PID to something supported already, things just might work... The current usbhid-ups driver should be perfect. As I said in the original email, rhe Ubuntu package includes a usev rules file that has a VID/PID (2341:8036) for the Arduino I have so it looks supported to me and that should solve the permissions issue, right? The USB HID power device standard has a well known report structure so I expected the simple things like "AC Present" vs "Discharding" to work. But I'm not even at mapping variables yet. Just at: "the OS package appears to support thie VID/PID, but it doesn't work" On Sun, Oct 29, 2023 at 6:46 PM Charles Lepple wrote: > > On Oct 29, 2023, at 9:25 PM, Kelly Byrd wrote: > > > > I have seen reports of folks claiming this just worked for them out of > the box, > > Here you're referring to just making things work on Windows or macOS, > right? I don't think it will be quite as simple with NUT, mostly because > the NUT drivers are trying to expose all of the variables and commands, > rather than just the simple shutdown bits. > > I'm not sure where a generic HID PDC driver sits in the priority list at > the moment, but IIRC the current driver is still fairly tightly coupled to > the USB VID and resulting model-specific mappings. So once you get the > permissions worked out, you would still need a new source file that maps > the HID Usage "paths" to NUT variable names. It's one of those things that > in hindsight, it would have been great to fall back to a generic mapping > that just looks at the OB and LB bits, but real-world UPSes are messy, and > we would have needed those model-specific mappings to be able to > distinguish things like input and output voltage. > > That said, if you change the VID/PID to something supported already, > things just might work. The "Couldn't retrieve descriptors" is likely a > result of the driver dropping root privileges, then not having enough > permissions to write to the /dev/bus/usb node to request the HID > descriptor. I don't know how your VID/PID got into the udev rules file - > VID 2341 doesn't show up in the NUT Git source tree. > > -- > Charles Lepple > clepple@gmail > > ___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] usbhid-ups not loading with Arduino Leonardo on Ubuntu 23.10
Looking at the output of lsub in my original message: `bNumInterfaces 1` Then there's only one Interface Descriptor section. I can modify the USB code the runs on the Arduino, if needed. I'm looking for help on what is going wrong and what I could modify to fix it. I have seen reports of folks claiming this just worked for them out of the box, so unsure what to do next. On Sun, Oct 29, 2023 at 4:13 PM Jim Klimov wrote: > OTOH: I wonder whether, when it says "Claimed interface 2 successfully" > it got the right number of the correct (HID) one of many interfaces you > likely have there?.. :\ > > Jim > > > On Mon, Oct 30, 2023, 00:04 Kelly Byrd wrote: > >> >> >> Apologies for the long post. I'm trying to include what I hope are the >> relevant bits (output of lsusb -v and usbhid-ups) >> >> Long term goal: I've got a DIY UPS that I would like to get working with >> my QNAP NAS (which uses Linux and NUT underneath the hood) >> ... >> > ___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Spammy notification-tech diagnostic message
Vojtěch Hurčík via Nut-upsuser writes: > Thanks for the reply, it's only reported once per spawned process and > what you say makes perfect sense in this light. A configuration toggle > or environment variable also seems like a good idea, but I'm sure I or > we can also live with the message being reported once per process as > it currently is... looking forward to the stable release & thanks for > everything! If it's only once per process, I lean lean to one of don't make it configurable and just phrase it so it isn't scary or at cmake time, specify the integration with system management stuff and then get it right. and overall the second seems nicer but ENOPATCH. ___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] usbhid-ups not loading with Arduino Leonardo on Ubuntu 23.10
OTOH: I wonder whether, when it says "Claimed interface 2 successfully" it got the right number of the correct (HID) one of many interfaces you likely have there?.. :\ Jim On Mon, Oct 30, 2023, 00:04 Kelly Byrd wrote: > > > Apologies for the long post. I'm trying to include what I hope are the > relevant bits (output of lsusb -v and usbhid-ups) > > Long term goal: I've got a DIY UPS that I would like to get working with > my QNAP NAS (which uses Linux and NUT underneath the hood) > ... > ___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] usbhid-ups not loading with Arduino Leonardo on Ubuntu 23.10
Apologies for the long post. I'm trying to include what I hope are the relevant bits (output of lsusb -v and usbhid-ups) Long term goal: I've got a DIY UPS that I would like to get working with my QNAP NAS (which uses Linux and NUT underneath the hood) Immediate short-term problem: I can't get past running usbhid-ups on Ubuntu 23.10 with an Arduino Leonardo. I have an Arduino Micro using this https://github.com/abratchik/HIDPowerDevice/ library. I have a sketch working successfully with both Win10 and MacOS. They both recognize the Arduino as a HID power device and detect the AC present true/false as well as a hard-coded (for now) charge state. Before getting it to work with the QNAP I thought it would be easier to get this working on a full Linux install. So I have Ubuntu 23.10 running on a Raspberry Pi. I installed the nut-server and nut-client packages and did a simple test with an APC UPS I have and was able to see in the logs that nut loaded the driver for it. However, I cannot get this to work with the Arduino. For both the APC and the Arduino I used `nut-scanner -U`. For the Arduino I get: Scanning USB bus. [nutdev1] driver = "usbhid-ups" port = "auto" vendorid = "2341" productid = "8036" product = "Arduino Leonardo" serial = "UPS11" vendor = "Arduino LLC" bus = "001" I then put this in my ups.conf [diyups] driver = "usbhid-ups" desc = "DIY UPS via Arduino" port = "auto" vendorid = "2341" productid = "8036" The Ubuntu nut package installed /lib/udev/rules.d/62-nut-usbups.rules which does have the VID/PID combination of my device so I hoped this would "just work" :-( When I run the usbhid driver (as root) like this: /usr/lib/nut/usbhid-ups -D -a diyups Network UPS Tools - Generic HID driver 0.47 (2.8.0) USB communication driver (libusb 1.0) 0.43 0.00 [D3] do_global_args: var='maxretry' val='3' 0.000360 [D3] main_arg: var='driver' val='usbhid-ups' 0.000435 [D3] main_arg: var='desc' val='DIY UPS via Arduino' 0.000503 [D3] main_arg: var='port' val='auto' 0.000569 [D5] send_to_all: SETINFO driver.parameter.port "auto" 0.000620 [D3] main_arg: var='vendorid' val='2341' 0.000682 [D5] send_to_all: SETINFO driver.parameter.vendorid "2341" 0.000734 [D3] main_arg: var='productid' val='8036' 0.000785 [D5] send_to_all: SETINFO driver.parameter.productid "8036" 0.000918 [D1] debug level is '9' 0.009460 [D5] send_to_all: SETINFO device.type "ups" 0.009549 [D2] Initializing an USB-connected UPS with library libusb-1.0.26 (API: 0x1000109) (NUT subdriver name='USB communication driver (libusb 1.0)' ver='0.43') 0.009608 [D1] upsdrv_initups (non-SHUT)... 0.041470 [D2] Checking device 1 of 5 (2341/8036) 0.049789 [D2] - VendorID: 2341 0.049863 [D2] - ProductID: 8036 0.049907 [D2] - Manufacturer: Arduino LLC 0.049948 [D2] - Product: Arduino Leonardo 0.049990 [D2] - Serial Number: UPS11 0.050032 [D2] - Bus: 001 0.050078 [D2] - Device: unknown 0.050126 [D2] - Device release number: 0100 0.050171 [D2] Trying to match device 0.050224 [D2] match_function_subdriver (non-SHUT mode): matching a device... 0.050272 [D3] match_function_regex: matching a device... 0.050642 [D2] Device matches 0.050744 [D2] Reading first configuration descriptor 0.050799 [D2] result: -5 (Entity not found) 0.050921 [D3] libusb_kernel_driver_active() returned 0 0.051021 [D2] Claimed interface 2 successfully 0.051066 [D3] nut_usb_set_altinterface: skipped libusb_set_interface_alt_setting(udev, 2, 0) 0.051108 [D2] Couldn't retrieve descriptors 0.051346 [D2] Checking device 2 of 5 (0424/7800) 0.051500 [D1] Failed to open device (0424/7800), skipping: Access denied (insufficient permissions) 0.051548 [D2] Checking device 3 of 5 (0424/2514) 0.051642 [D1] Failed to open device (0424/2514), skipping: Access denied (insufficient permissions) 0.051708 [D2] Checking device 4 of 5 (0424/2514) 0.051798 [D1] Failed to open device (0424/2514), skipping: Access denied (insufficient permissions) 0.051845 [D2] Checking device 5 of 5 (1D6B/0002) 0.051945 [D1] Failed to open device (1D6B/0002), skipping: Access denied (insufficient permissions) 0.051991 [D2] libusb1: No appropriate HID device found 0.052033 libusb1: Could not open any HID devices: insufficient permissions on everything 0.052074 No matching HID UPS found Note that the Arduino is "interesting" because it's a composite USB device. With my sketch loaded it has a CDC interface (for flashing and serial output) and a HID device (which my sketch controls). Current Arduino core libraries let you enable and disable the CDC so I have tried with it both enabled and disabled. Neither seems to work. The above usbhid-ups run
Re: [Nut-upsuser] Spammy notification-tech diagnostic message
Thanks for the reply, it's only reported once per spawned process and what you
say makes perfect sense in this light. A configuration toggle or environment
variable also seems like a good idea, but I'm sure I or we can also live with
the message being reported once per process as it currently is... looking
forward to the stable release & thanks for everything!
VH
--- Original Message ---
On Sunday, October 29th, 2023 at 16:22, Jim Klimov
wrote:
> Thanks for your concern.
>
> Technically, it is not about just systemd - other systems where launched
> processes that have ways to interact with some OS framework (like SMF,
> upstart, Windows services, docker/kubernetes, whatever) *and* such framework
> offers ways for services to inform they have started and e.g. dependencies
> can begin starting, with better precision than "we have forked off an init
> script and assume that this instant its service is fully ready".
>
> One bit that worries me in your report is "I am repeatedly getting these
> messages in my syslog" - does it mean you get them more often than once per
> uptime of each daemon (upsd, upsmon, driver)? Or that you reboot so often
> that the "noise" gets your eyes sore? :)
>
> I did initially have the opposite feedback in the beginning, about not having
> those notifications working and services set up for notification-based
> integration getting restarted by their OS framework because their startup
> allegedly timed out.
>
> I think this sort of behaviors with OS-dependent variations was supposed to
> become managed by envvars (e.g. offering a toggle to not make noise easy to
> set in packaged init-scripts etc.) but it seems that for this particular case
> one was not merged. Something similar was discussed about NUT daemon banner
> and a few other lines emitted at startup, which some people see as important
> post-mortem tool when inspecting logs or console dumps, and others treat as
> noise ("unless there's an error, I want to see nothing") - and frankly both
> stances have their merits for different audiences.
>
> Jim Klimov
>
> On Sun, Oct 29, 2023 at 2:45 PM Vojtěch Hurčík via Nut-upsuser
> wrote:
>
>> Hello friends!
>>
>> With the upcoming NUT release there is one thing I would like to ask:
>>
>> -
>>
>> no notification tech defined, will not spam more about
>>
>> I am repeatedly getting these messages in my syslog more recently because I
>> do not have systemd available to me on my distribution and also do not want
>> to use it.
>>
>> Maybe the debug level for such messages could be raised to 1 instead, as
>> they still seem a bit too spammy for something us, who don't use the
>> systemd, already know. At least then we would have a way to suppress them...
>>
>> Vojtěch
>> ___
>> Nut-upsuser mailing list
>> Nut-upsuser@alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Spammy notification-tech diagnostic message
Would this help?
https://github.com/networkupstools/nut/pull/2136
Jim
On Sun, Oct 29, 2023 at 5:04 PM Vojtěch Hurčík wrote:
> Thanks for the reply, it's only reported once per spawned process and what
> you say makes perfect sense in this light. A configuration toggle or
> environment variable also seems like a good idea, but I'm sure I or we can
> also live with the message being reported once per process as it currently
> is... looking forward to the stable release & thanks for everything!
>
> VH
>
> --- Original Message ---
> On Sunday, October 29th, 2023 at 16:22, Jim Klimov <
> jimklimov+...@gmail.com> wrote:
>
> Thanks for your concern.
>
> Technically, it is not about just systemd - other systems where launched
> processes that have ways to interact with some OS framework (like SMF,
> upstart, Windows services, docker/kubernetes, whatever) *and* such
> framework offers ways for services to inform they have started and e.g.
> dependencies can begin starting, with better precision than "we have forked
> off an init script and assume that this instant its service is fully ready".
>
> One bit that worries me in your report is "I am repeatedly getting these
> messages in my *syslog*" - does it mean you get them more often than once
> per uptime of each daemon (upsd, upsmon, driver)? Or that you reboot so
> often that the "noise" gets your eyes sore? :)
>
> I did initially have the opposite feedback in the beginning, about not
> having those notifications working and services set up for
> notification-based integration getting restarted by their OS framework
> because their startup allegedly timed out.
>
> I think this sort of behaviors with OS-dependent variations was supposed
> to become managed by envvars (e.g. offering a toggle to not make noise easy
> to set in packaged init-scripts etc.) but it seems that for this particular
> case one was not merged. Something similar was discussed about NUT daemon
> banner and a few other lines emitted at startup, which some people see as
> important post-mortem tool when inspecting logs or console dumps, and
> others treat as noise ("unless there's an error, I want to see nothing") -
> and frankly both stances have their merits for different audiences.
>
> Jim Klimov
>
>
> On Sun, Oct 29, 2023 at 2:45 PM Vojtěch Hurčík via Nut-upsuser <
> nut-upsuser@alioth-lists.debian.net> wrote:
>
>> Hello friends!
>>
>> With the upcoming NUT release there is one thing I would like to ask:
>>
>>-
>>
>>no notification tech defined, will not spam more about
>>
>>
>> I am repeatedly getting these messages in my *syslog* more recently
>> because I do not have *systemd* available to me on my distribution and
>> also do not want to use it.
>>
>> Maybe the debug level for such messages could be raised to 1 instead, as
>> they still seem a bit too spammy for something us, who don't use the
>> *systemd*, already know. At least then we would have a way to suppress
>> them...
>>
>> Vojtěch
>> ___
>> Nut-upsuser mailing list
>> Nut-upsuser@alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>>
>
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Spammy notification-tech diagnostic message
Thanks for your concern.
Technically, it is not about just systemd - other systems where launched
processes that have ways to interact with some OS framework (like SMF,
upstart, Windows services, docker/kubernetes, whatever) *and* such
framework offers ways for services to inform they have started and e.g.
dependencies can begin starting, with better precision than "we have forked
off an init script and assume that this instant its service is fully ready".
One bit that worries me in your report is "I am repeatedly getting these
messages in my *syslog*" - does it mean you get them more often than once
per uptime of each daemon (upsd, upsmon, driver)? Or that you reboot so
often that the "noise" gets your eyes sore? :)
I did initially have the opposite feedback in the beginning, about not
having those notifications working and services set up for
notification-based integration getting restarted by their OS framework
because their startup allegedly timed out.
I think this sort of behaviors with OS-dependent variations was supposed to
become managed by envvars (e.g. offering a toggle to not make noise easy to
set in packaged init-scripts etc.) but it seems that for this particular
case one was not merged. Something similar was discussed about NUT daemon
banner and a few other lines emitted at startup, which some people see as
important post-mortem tool when inspecting logs or console dumps, and
others treat as noise ("unless there's an error, I want to see nothing") -
and frankly both stances have their merits for different audiences.
Jim Klimov
On Sun, Oct 29, 2023 at 2:45 PM Vojtěch Hurčík via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:
> Hello friends!
>
> With the upcoming NUT release there is one thing I would like to ask:
>
>-
>
>no notification tech defined, will not spam more about
>
>
> I am repeatedly getting these messages in my *syslog* more recently
> because I do not have *systemd* available to me on my distribution and
> also do not want to use it.
>
> Maybe the debug level for such messages could be raised to 1 instead, as
> they still seem a bit too spammy for something us, who don't use the
> *systemd*, already know. At least then we would have a way to suppress
> them...
>
> Vojtěch
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] Spammy notification-tech diagnostic message
Hello friends! With the upcoming NUT release there is one thing I would like to ask: - no notification tech defined, will not spam more about I am repeatedly getting these messages in my syslog more recently because I do not have systemd available to me on my distribution and also do not want to use it. Maybe the debug level for such messages could be raised to 1 instead, as they still seem a bit too spammy for something us, who don't use the systemd, already know. At least then we would have a way to suppress them... Vojtěch___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
