[Nut-upsdev] Scheduling a 2.2.1 release

Kjell Claesson kjell.claesson at epost.tidanet.se
Sat Sep 8 14:40:22 UTC 2007

Den Saturday 08 September 2007 14.59.28 skrev Kjell Claesson:
> Hi Arnaud,
> Den Saturday 08 September 2007 12.41.45 skrev Arnaud Quette:
> > I'm preparing to release 2.2.1 this week, so if you have some fixes to
> > backport on Testing, considering announcing it and doing asap.
> >
> > As always, compatibilities update and bugfixes only!
> There is a bugfix in bcmxcp.c regarding shutdown delay.
> So the bcmxcp from trunk should go into testing.
> I try to fix this a.s.a.p.

Hmm. This seems not to be backported to Testing
Wed Aug  8 21:35:59 UTC 2007 / Arjen de Korte <arjen at de-korte.org>

 * drivers/dstate.c:
   - Removed stuff to prepend ALARM to 'ups.status', which wasn't
     really useful (see below). Now it no longer complains that
     'ups.status' parameter is not set when calling alarm_commit().
 * drivers/bcmxcp.c, drivers/gamatronic.c:
   - Call alarm_commit() when we're done with setting alarms. There
     is no need to wait for status_commit(). The status_init()
     function will take care of prepending ALARM, as long as we
     call it after alarm_commit().

Arjen is it possible to backport the changes in dstate ?

Looks like this is the only thing that can cause trouble.
Otherwise it is only to copy bcmxcp.c and bcmxcp_usb.c to Testing.


More information about the Nut-upsdev mailing list