Re: [Nut-upsdev] Roadmap to 2.7.3
FYI on the added delay 2015-04-16 16:54 GMT+02:00 Arnaud Quette arnaud.que...@gmail.com: 2015-04-16 14:34 GMT+02:00 Charles Lepple clep...@gmail.com: On Apr 16, 2015, at 5:46 AM, Arnaud Quette arnaud.que...@gmail.com wrote: 2015-04-15 15:05 GMT+02:00 Charles Lepple clep...@gmail.com: On Apr 15, 2015, at 5:00 AM, Arnaud Quette arnaud.que...@gmail.com wrote: Hi Charles, 2015-04-13 15:09 GMT+02:00 Charles Lepple clep...@gmail.com: On Apr 13, 2015, at 4:28 AM, Arnaud Quette arnaud.que...@gmail.com wrote: cool (bis), I'll check over the day to complete as per my latest merges and possibly (if time permits) to publish 2.7.3. We should probably add a release checklist to the developer documentation, but for now: the maintainer guide [1] (not distributed) is more suitable. • update version to 2.7.3 in nut/configure.ac done • create a GPG-signed tag v2.7.3 done + a non-signed one (not sure it's worth!) Yeah, I guess I meant that we should have a signed tag (v2.7.3) but it doesn't need -signed in the name. We only had to do that last time because there was already an unsigned v2.7.2 tag. • make dist done • maybe update nut/configure.ac version to 2.7.3.1 or .5? not sure to get why .5... it's what we did last time :-) the history log is also saying so... but still failing to understand the jump to .5 anyway, it's probably too hot here (almost jumped from winter to summer) ;) My main reason was to create a different name for the tarball in the Buildbot snapshot builder. After 2.7.3 is released, I plan to go back to the previous way of injecting the Buildbot build number and Git hash into the tarball name. (The long filenames in the Java package were preventing us from doing this before.) so should I really update configure.ac to 2.7.3.1 or? Yes, since I don't know how long it will take to reconfigure Buildbot. (I would also like to get it to automatically build the website - currently that needs to be triggered manually.) done to 2.7.3.1 • push commits and tag done • update nut/ and ddl/ submodules in nut-website/ (this should update the website's version as well) WIP, however we should detail the process here: either - a generic git submodule foreach git pull origin master (I did that one) - Vs pulling the matching tags (here 2.7.3 from NUT for ex...), better and more stable I suppose we could tag the DDL repository as well. done, and will also do for -website I've also updated the -website submodules (ddl and nut) using the v2.7.3 tags • add download hashes for tarball for hashes and sig: make dist-sig make dist-hash WIP, however access to my Gandi PaaS is underway at Eaton (forgot to request that one :-/) so a bit more delay in the release publication I once started to create a publication script, but... hem can't find it back. more to resume ;) After the new version is tagged, I'll update my Ubuntu PPA. cool! shouldn't we add it to the Download page? It's really more of a temporary solution. Now that our primary Debian maintainer is back, all of the packages will be up-to-date, right? /me ducks woow, cool, our beloved DD is back?! 8-) need a bit more time for that too, slowly ramping up on all (of the many) dimensions ;) :-) access to my hosted PaaS still blocked... the access to my PaaS hosting NUT is now opened. While doing a final check, before pushing the release, I realized that I forgot to rename the link to the previous GPG (1K) key. I thus had to recreate the 2.7.3 tag, and go again through the release process. 2.7.3 will be online in a few minutes now... cheers, Arno -- Eaton Data Center Automation - Opensource Leader NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.fr ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Roadmap to 2.7.3
2015-04-15 15:05 GMT+02:00 Charles Lepple clep...@gmail.com: On Apr 15, 2015, at 5:00 AM, Arnaud Quette arnaud.que...@gmail.com wrote: Hi Charles, 2015-04-13 15:09 GMT+02:00 Charles Lepple clep...@gmail.com: On Apr 13, 2015, at 4:28 AM, Arnaud Quette arnaud.que...@gmail.com wrote: cool (bis), I'll check over the day to complete as per my latest merges and possibly (if time permits) to publish 2.7.3. We should probably add a release checklist to the developer documentation, but for now: the maintainer guide [1] (not distributed) is more suitable. • update version to 2.7.3 in nut/configure.ac done • create a GPG-signed tag v2.7.3 done + a non-signed one (not sure it's worth!) • make dist done • maybe update nut/configure.ac version to 2.7.3.1 or .5? not sure to get why .5... it's what we did last time :-) the history log is also saying so... but still failing to understand the jump to .5 anyway, it's probably too hot here (almost jumped from winter to summer) ;) My main reason was to create a different name for the tarball in the Buildbot snapshot builder. After 2.7.3 is released, I plan to go back to the previous way of injecting the Buildbot build number and Git hash into the tarball name. (The long filenames in the Java package were preventing us from doing this before.) so should I really update configure.ac to 2.7.3.1 or? • push commits and tag done • update nut/ and ddl/ submodules in nut-website/ (this should update the website's version as well) WIP, however we should detail the process here: either - a generic git submodule foreach git pull origin master (I did that one) - Vs pulling the matching tags (here 2.7.3 from NUT for ex...), better and more stable • add download hashes for tarball for hashes and sig: make dist-sig make dist-hash WIP, however access to my Gandi PaaS is underway at Eaton (forgot to request that one :-/) so a bit more delay in the release publication I once started to create a publication script, but... hem can't find it back. more to resume ;) After the new version is tagged, I'll update my Ubuntu PPA. cool! shouldn't we add it to the Download page? It's really more of a temporary solution. Now that our primary Debian maintainer is back, all of the packages will be up-to-date, right? /me ducks woow, cool, our beloved DD is back?! 8-) need a bit more time for that too, slowly ramping up on all (of the many) dimensions ;) cheers, Arno -- Eaton Data Center Automation - Opensource Leader NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.fr ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Roadmap to 2.7.3
On Apr 16, 2015, at 5:46 AM, Arnaud Quette arnaud.que...@gmail.com wrote: 2015-04-15 15:05 GMT+02:00 Charles Lepple clep...@gmail.com: On Apr 15, 2015, at 5:00 AM, Arnaud Quette arnaud.que...@gmail.com wrote: Hi Charles, 2015-04-13 15:09 GMT+02:00 Charles Lepple clep...@gmail.com: On Apr 13, 2015, at 4:28 AM, Arnaud Quette arnaud.que...@gmail.com wrote: cool (bis), I'll check over the day to complete as per my latest merges and possibly (if time permits) to publish 2.7.3. We should probably add a release checklist to the developer documentation, but for now: the maintainer guide [1] (not distributed) is more suitable. • update version to 2.7.3 in nut/configure.ac done • create a GPG-signed tag v2.7.3 done + a non-signed one (not sure it's worth!) Yeah, I guess I meant that we should have a signed tag (v2.7.3) but it doesn't need -signed in the name. We only had to do that last time because there was already an unsigned v2.7.2 tag. • make dist done • maybe update nut/configure.ac version to 2.7.3.1 or .5? not sure to get why .5... it's what we did last time :-) the history log is also saying so... but still failing to understand the jump to .5 anyway, it's probably too hot here (almost jumped from winter to summer) ;) My main reason was to create a different name for the tarball in the Buildbot snapshot builder. After 2.7.3 is released, I plan to go back to the previous way of injecting the Buildbot build number and Git hash into the tarball name. (The long filenames in the Java package were preventing us from doing this before.) so should I really update configure.ac to 2.7.3.1 or? Yes, since I don't know how long it will take to reconfigure Buildbot. (I would also like to get it to automatically build the website - currently that needs to be triggered manually.) • push commits and tag done • update nut/ and ddl/ submodules in nut-website/ (this should update the website's version as well) WIP, however we should detail the process here: either - a generic git submodule foreach git pull origin master (I did that one) - Vs pulling the matching tags (here 2.7.3 from NUT for ex...), better and more stable I suppose we could tag the DDL repository as well. • add download hashes for tarball for hashes and sig: make dist-sig make dist-hash WIP, however access to my Gandi PaaS is underway at Eaton (forgot to request that one :-/) so a bit more delay in the release publication I once started to create a publication script, but... hem can't find it back. more to resume ;) After the new version is tagged, I'll update my Ubuntu PPA. cool! shouldn't we add it to the Download page? It's really more of a temporary solution. Now that our primary Debian maintainer is back, all of the packages will be up-to-date, right? /me ducks woow, cool, our beloved DD is back?! 8-) need a bit more time for that too, slowly ramping up on all (of the many) dimensions ;) :-) -- Charles Lepple clepple@gmail ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Roadmap to 2.7.3
2015-04-16 14:34 GMT+02:00 Charles Lepple clep...@gmail.com: On Apr 16, 2015, at 5:46 AM, Arnaud Quette arnaud.que...@gmail.com wrote: 2015-04-15 15:05 GMT+02:00 Charles Lepple clep...@gmail.com: On Apr 15, 2015, at 5:00 AM, Arnaud Quette arnaud.que...@gmail.com wrote: Hi Charles, 2015-04-13 15:09 GMT+02:00 Charles Lepple clep...@gmail.com: On Apr 13, 2015, at 4:28 AM, Arnaud Quette arnaud.que...@gmail.com wrote: cool (bis), I'll check over the day to complete as per my latest merges and possibly (if time permits) to publish 2.7.3. We should probably add a release checklist to the developer documentation, but for now: the maintainer guide [1] (not distributed) is more suitable. • update version to 2.7.3 in nut/configure.ac done • create a GPG-signed tag v2.7.3 done + a non-signed one (not sure it's worth!) Yeah, I guess I meant that we should have a signed tag (v2.7.3) but it doesn't need -signed in the name. We only had to do that last time because there was already an unsigned v2.7.2 tag. • make dist done • maybe update nut/configure.ac version to 2.7.3.1 or .5? not sure to get why .5... it's what we did last time :-) the history log is also saying so... but still failing to understand the jump to .5 anyway, it's probably too hot here (almost jumped from winter to summer) ;) My main reason was to create a different name for the tarball in the Buildbot snapshot builder. After 2.7.3 is released, I plan to go back to the previous way of injecting the Buildbot build number and Git hash into the tarball name. (The long filenames in the Java package were preventing us from doing this before.) so should I really update configure.ac to 2.7.3.1 or? Yes, since I don't know how long it will take to reconfigure Buildbot. (I would also like to get it to automatically build the website - currently that needs to be triggered manually.) done to 2.7.3.1 • push commits and tag done • update nut/ and ddl/ submodules in nut-website/ (this should update the website's version as well) WIP, however we should detail the process here: either - a generic git submodule foreach git pull origin master (I did that one) - Vs pulling the matching tags (here 2.7.3 from NUT for ex...), better and more stable I suppose we could tag the DDL repository as well. done, and will also do for -website I've also updated the -website submodules (ddl and nut) using the v2.7.3 tags • add download hashes for tarball for hashes and sig: make dist-sig make dist-hash WIP, however access to my Gandi PaaS is underway at Eaton (forgot to request that one :-/) so a bit more delay in the release publication I once started to create a publication script, but... hem can't find it back. more to resume ;) After the new version is tagged, I'll update my Ubuntu PPA. cool! shouldn't we add it to the Download page? It's really more of a temporary solution. Now that our primary Debian maintainer is back, all of the packages will be up-to-date, right? /me ducks woow, cool, our beloved DD is back?! 8-) need a bit more time for that too, slowly ramping up on all (of the many) dimensions ;) :-) access to my hosted PaaS still blocked... cheers, Arno -- Eaton Data Center Automation - Opensource Leader NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.fr ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Roadmap to 2.7.3
On Apr 15, 2015, at 5:00 AM, Arnaud Quette arnaud.que...@gmail.com wrote: Hi Charles, 2015-04-13 15:09 GMT+02:00 Charles Lepple clep...@gmail.com: On Apr 13, 2015, at 4:28 AM, Arnaud Quette arnaud.que...@gmail.com wrote: cool (bis), I'll check over the day to complete as per my latest merges and possibly (if time permits) to publish 2.7.3. We should probably add a release checklist to the developer documentation, but for now: the maintainer guide [1] (not distributed) is more suitable. • update version to 2.7.3 in nut/configure.ac • create a GPG-signed tag v2.7.3 • make dist • maybe update nut/configure.ac version to 2.7.3.1 or .5? not sure to get why .5... it's what we did last time :-) My main reason was to create a different name for the tarball in the Buildbot snapshot builder. After 2.7.3 is released, I plan to go back to the previous way of injecting the Buildbot build number and Git hash into the tarball name. (The long filenames in the Java package were preventing us from doing this before.) • push commits and tag • update nut/ and ddl/ submodules in nut-website/ (this should update the website's version as well) • add download hashes for tarball for hashes and sig: make dist-sig make dist-hash I once started to create a publication script, but... hem can't find it back. more to resume ;) After the new version is tagged, I'll update my Ubuntu PPA. cool! shouldn't we add it to the Download page? It's really more of a temporary solution. Now that our primary Debian maintainer is back, all of the packages will be up-to-date, right? /me ducks -- Charles Lepple clepple@gmail ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Roadmap to 2.7.3
Hi Charles, 2015-04-13 15:09 GMT+02:00 Charles Lepple clep...@gmail.com: On Apr 13, 2015, at 4:28 AM, Arnaud Quette arnaud.que...@gmail.com wrote: cool (bis), I'll check over the day to complete as per my latest merges and possibly (if time permits) to publish 2.7.3. We should probably add a release checklist to the developer documentation, but for now: the maintainer guide [1] (not distributed) is more suitable. • update version to 2.7.3 in nut/configure.ac • create a GPG-signed tag v2.7.3 • make dist • maybe update nut/configure.ac version to 2.7.3.1 or .5? not sure to get why .5... • push commits and tag • update nut/ and ddl/ submodules in nut-website/ (this should update the website's version as well) • add download hashes for tarball for hashes and sig: make dist-sig make dist-hash I once started to create a publication script, but... hem can't find it back. more to resume ;) After the new version is tagged, I'll update my Ubuntu PPA. cool! shouldn't we add it to the Download page? cheers, Arno -- [1] https://github.com/networkupstools/nut/blob/master/docs/maintainer-guide.txt -- Eaton Data Center Automation - Opensource Leader NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.fr ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Roadmap to 2.7.3
Hi Charles, 2015-04-11 21:22 GMT+02:00 Charles Lepple clep...@gmail.com: On Apr 8, 2015, at 9:44 AM, Arnaud Quette arnaud.que...@gmail.com wrote: - #190: upsd: NSS SSL only working in debug mode = NEED TESTING before merging Emilien has made a fix and PR (#199: Initialize SSL after deamonize and downgrade to user.) The user (Melkor Lord) has ack'ed the fix. The fix is indeed trivial but I want to ensure that there is no regression for OpenSSL now (though theoretically, there shouldn't be). Testing welcome, while waiting to discuss with Emilien to see if he did some non-reg testing too. Thanks a lot to Emilien for his work on this! Just tested Emilien's fix against OpenSSL on Linux Mint 17 - no issues there. I did notice an issue when trying to test against OpenSSL 1.0.2a on OS X: upsd[27047]: Unknown return value from SSL_accept: Resource temporarily unavailable However, this happens on master as well as the #199 branch, so it is technically not a regression. As with the previous bug, it fails safe, and does not crop up if SSL is not enabled. I'll file a bug, but I really don't want to tackle that until we fix the logging in the SSL code. Merged. cool, thx! let's see that #202 for 2.7.4. Note that I've started the tickets triaging for 2.7.4. Feel free to add the ones you think are worth for it. Now, there just remain the Release things, such as NEWS and the like... NEWS and UPGRADING should be up to-to-date, except possibly for your latest merges. I added UPGRADING notes for the NSS SSL issue. cool (bis), I'll check over the day to complete as per my latest merges and possibly (if time permits) to publish 2.7.3. thanks and cheers, Arno -- Eaton Data Center Automation - Opensource Leader NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.fr ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Roadmap to 2.7.3
On Apr 13, 2015, at 4:28 AM, Arnaud Quette arnaud.que...@gmail.com wrote: cool (bis), I'll check over the day to complete as per my latest merges and possibly (if time permits) to publish 2.7.3. We should probably add a release checklist to the developer documentation, but for now: • update version to 2.7.3 in nut/configure.ac • create a GPG-signed tag v2.7.3 • make dist • maybe update nut/configure.ac version to 2.7.3.1 or .5? • push commits and tag • update nut/ and ddl/ submodules in nut-website/ (this should update the website's version as well) • add download hashes for tarball After the new version is tagged, I'll update my Ubuntu PPA. -- Charles Lepple clepple@gmail ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Roadmap to 2.7.3
On Apr 8, 2015, at 9:44 AM, Arnaud Quette arnaud.que...@gmail.com wrote: - #190: upsd: NSS SSL only working in debug mode = NEED TESTING before merging Emilien has made a fix and PR (#199: Initialize SSL after deamonize and downgrade to user.) The user (Melkor Lord) has ack'ed the fix. The fix is indeed trivial but I want to ensure that there is no regression for OpenSSL now (though theoretically, there shouldn't be). Testing welcome, while waiting to discuss with Emilien to see if he did some non-reg testing too. Thanks a lot to Emilien for his work on this! Just tested Emilien's fix against OpenSSL on Linux Mint 17 - no issues there. I did notice an issue when trying to test against OpenSSL 1.0.2a on OS X: upsd[27047]: Unknown return value from SSL_accept: Resource temporarily unavailable However, this happens on master as well as the #199 branch, so it is technically not a regression. As with the previous bug, it fails safe, and does not crop up if SSL is not enabled. I'll file a bug, but I really don't want to tackle that until we fix the logging in the SSL code. Merged. Now, there just remain the Release things, such as NEWS and the like... NEWS and UPGRADING should be up to-to-date, except possibly for your latest merges. I added UPGRADING notes for the NSS SSL issue. -- Charles Lepple clepple@gmail ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Roadmap to 2.7.3
Hi Charles and the list here is an update on 2.7.3 2015-03-20 3:33 GMT+01:00 Charles Lepple clep...@gmail.com: On Mar 19, 2015, at 2:00 PM, Arnaud Quette arnaud.que...@gmail.com wrote: * #158: the branch has been collapsed into one commit, but additional documentation (nut-names.txt) is needed: https://github.com/networkupstools/nut/commit/00b8c8383a2614fc0bc8df190402b2dc885848a2 branch updated for nut-names.txt + few minor updates. I've also rebased on master, but will need another round (following the 2 branches pushed below) I'm still lagging behind the HW tests, so if you can, let's move on... otherwise, I'll do, but not today. I'll check whenever possible, but Igor's feedback seems good to me, until proven the opposite. Arno, I saw your commit, but I did not realize it wasn't merged. I think Igor has done sufficient testing, so do you want to merge it? Beside from the known list of tickets for 2.7.3, I had some late additions tied to Eaton renewed implication in NUT (ABM and Energy Saving, along with the below ePDU one). Sorry for the lag and lack of communication Charles... I'm still not in the optimal zone... The whole list of remaining things is: - #197: upsc on ePDU show ups.status only (snmp) = DONE That one is tricky: as commented, some devices (such as big ePDU) generates too much info and upsd doesn't keep up in async (default) mode. For the short run, I've added a *synchronous* flag to address this exceptional case. That doesn't touch the normal behavior when not used. Thanks to Daniele for the review and catching my errors :) Branch (nonblocking_drv) merged. - #190: upsd: NSS SSL only working in debug mode = NEED TESTING before merging Emilien has made a fix and PR (#199: Initialize SSL after deamonize and downgrade to user.) The user (Melkor Lord) has ack'ed the fix. The fix is indeed trivial but I want to ensure that there is no regression for OpenSSL now (though theoretically, there shouldn't be). Testing welcome, while waiting to discuss with Emilien to see if he did some non-reg testing too. Thanks a lot to Emilien for his work on this! - Eaton ABM (Advanced Battery Monitoring): this is something I wanted to address for ~8 years now. = almost DONE This is now done in both HID (USB and serial), XCP (USB and serial) and SNMP. Eaton XML still remains to be addressed. But I've planned an XML cleanup ticket for 2.7.4 (#201: Cleanup and complete Eaton XML v3 support / mge-xml code) I'm still completing a few things, but it's almost good (final commit pending). Now, there just remain the Release things, such as NEWS and the like... I'll be focusing on that now. So almost good for 2.7.3. The big remainder is still NSS testing WRT non-reg of OpenSSL. To me, it's good to go. But considering the previous issue, I want to be 100 % sure this time :) cheers, Arno -- Eaton Data Center Automation - Opensource Leader NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.fr ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Roadmap to 2.7.3
2015-03-20 3:31 GMT+01:00 Charles Lepple clep...@gmail.com: On Mar 19, 2015, at 2:00 PM, Arnaud Quette arnaud.que...@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: I'm still considering that, trying to get (corporate) some help from Emilien... coffee scheduled in few minutes. • 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 it sounds like a plan... I'll try to push more over the day. Let's rediscuss over the week-end, cheers, Arno -- Eaton Data Center Automation - Opensource Leader NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.fr ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Roadmap to 2.7.3
On Mar 4, 2015, at 9:04 AM, Charles Lepple wrote: We only have a few open items that I think should be resolved before releasing 2.7.3. The list grew a bit in the past week, but we'll cover that later. Here is the list: * #93: Devices Dumps Library improvements https://github.com/networkupstools/nut/issues/93 * #158: Powerware BCMXCP advanced features https://github.com/networkupstools/nut/pull/158 * #185: insecure storage of password in nut-monitor favorites file https://github.com/networkupstools/nut/issues/185 * #187: Wrong in/out voltage repported for PowerCom KIN2200APRM https://github.com/networkupstools/nut/issues/187 * #190: upsd: NSS SSL only working in debug mode https://github.com/networkupstools/nut/issues/190 * eaton_epdus branch: https://github.com/networkupstools/nut/tree/eaton-epdus Most of these are from the GitHub 2.7.3 milestone: https://github.com/networkupstools/nut/issues?q=milestone%3A2.7.3 A quick status update: * #93: most of the DDL stuff is merged; anything else can wait for 2.7.4. * #158: the branch has been collapsed into one commit, but additional documentation (nut-names.txt) is needed: https://github.com/networkupstools/nut/commit/00b8c8383a2614fc0bc8df190402b2dc885848a2 * #185: merged * #187: no update from original comment: This is a driver-specfic fix, but I haven't had time to work through the logic from the vendor driver. This is not listed on the GitHub 2.7.3 milestone - should it be? * #190: no update on NSS SSL bug. Since it fails safe, I am willing to document around it (foreground hack). Has anyone else had a chance to look at it? * eaton_epdus branch: Arnaud, you may need to refresh my memory on what there the latest code is (pushed to same branch, or another issue?), and what needs to be agreed upon for the new names? thanks, -- Charles Lepple clepple@gmail ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Roadmap to 2.7.3
Hi Charles and NUT Developers, As mentioned privately to the NUT Core team, I'm almost back, thanks to Eaton renewed involvement... That still implies to catch up my late on the many topics and the roadmap. But finally, this time, it should be for real. 2015-03-04 15:04 GMT+01:00 Charles Lepple clep...@gmail.com: We only have a few open items that I think should be resolved before releasing 2.7.3. The list grew a bit in the past week, but we'll cover that later. Here is the list: * #93: Devices Dumps Library improvements https://github.com/networkupstools/nut/issues/93 * #158: Powerware BCMXCP advanced features https://github.com/networkupstools/nut/pull/158 * #185: insecure storage of password in nut-monitor favorites file https://github.com/networkupstools/nut/issues/185 * #187: Wrong in/out voltage repported for PowerCom KIN2200APRM https://github.com/networkupstools/nut/issues/187 * #190: upsd: NSS SSL only working in debug mode https://github.com/networkupstools/nut/issues/190 * eaton_epdus branch: https://github.com/networkupstools/nut/tree/eaton-epdus Most of these are from the GitHub 2.7.3 milestone: https://github.com/networkupstools/nut/issues?q=milestone%3A2.7.3 #93: The scope of this issue is a bit broad (encompassing a Gen3 dummy-ups driver, etc) but for 2.7.3, I think we can call this closed, so long as there are no issues pushing this to www.networkupstools.org. The current auto-generated DDL is here: http://buildbot.networkupstools.org/~buildbot/cayman/docs/latest/ddl/ I've updated that one, closed the last task that makes sense, and postponed the others for now (Gen3 dummy-ups and call to massive users reports), to not block 2.7.3 more. #158: I will rebase the commits, and replace the author's email address with the GitHub username@noreply address, but if someone has additional Powerware-based UPSes to test, that would be handy. I'm checking to get a hand on these legacy Eaton devices. My current workload is a bit too crowded to however commit on being able to test for 2.7.3 before Thursday March 19th. #185: Debian patch is on a branch; I will bump the version number and merge. #187: This is a driver-specfic fix, but I haven't had time to work through the logic from the vendor driver. This is not listed on the GitHub 2.7.3 milestone - should it be? #190 is a bit more complicated. We are still in the initial investigation stage, but it seems that this may have crept past the Ubuntu automated test suite. Running in the foreground is a bit of an ugly hack, but if it works with the Ubuntu init scripts... I'll let Arno cover the eaton_epdus branch. Also driver-specific (snmp-ups), so should not affect the rest of NUT. (Is this the same as issue #188? https://github.com/networkupstools/nut/issues/188 ) there is still at least 1 RFC on a set of new variables (input.*.load, input.*.realpower, input.*.power) for ePDUs, prior to merging. Note that ePDU measure such data on the input, hence these new variables... !! we may consider the present mail as the RFC to speed up things !! Glad to hear that Arno will have more time to work on NUT again! yeah ;) thanks and cheers, Arno -- Eaton Data Center Automation - Opensource Leader NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.fr ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Roadmap to 2.7.3
Hi Charles, Baruch and NUT developers, 2015-03-05 17:06 GMT+01:00 Charles Lepple clep...@gmail.com: For reference: https://github.com/networkupstools/nut/issues/10 On Mar 5, 2015, at 1:09 AM, Baruch Even bar...@ev-en.org wrote: Hi, There is one issue that I would consider as a major issue and not fixed yet. It is the use of wall time for scheduling ups polls instead of a monotonic clock source. I provided a (partial) patch in the past and I believe there was some work on it. The bug manifests itself as a stop of monitoring with no alarm when the clock is moved backwards in time. Please consider adding this to the release. Hi Baruch, What seems to have happened is that it was assigned to an Eaton contractor, and it got tangled up in a C++ unit test framework branch that did not get fully merged before the contract apparently ended. It was also tagged in GitHub with the 2.8 milestone, probably with the understanding that there would be a few more 2.7.x incremental releases in the mean time. I staffed Vasek (Vaclav Krpec, Eaton employee at that time) on a more advanced version of the Monothonic implementation [1]. However, in the course of checking the code, prior to merging, I had to stop at ~ 95+ %, since I uncovered some non trivial issues with the time stability of the result. The code was left as is since then, and as mentioned by Charles, I affected that to milestone 2.8. That goes back ~ 2 years ago, so I would need to refresh myself on this. However, still not for the short run, sorry Baruch! The issue list I mentioned for 2.7.3 is composed of two categories: small patches with limited impact, and a larger issue that would affect a lot of people (the NSS bug). While I think that monotonic clocks are the right solution for polling timers in the long term, I would be surprised if a lot of NUT installations worry about time going backwards, since that has big implications for log traceability. I am prepared to suggest releasing 2.7.3 with the NSS bug intact, since it fails safe (although useless) and can be worked around with configuration (run upsd in foreground). Documenting the handling of non-monotonic time as a known bug (with a simple patch tested on Linux) is perhaps not equivalent, but given the developer resource constraints we have had over the past year, I think it is not out of the question. agreed. let's start with simple things, and release 2.7.3. Then consider some more point releases to relaunch the project activity. thanks and cheers, Arno -- [1] https://github.com/networkupstools/nut/issues/10 -- Eaton Data Center Automation - Opensource Leader NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.fr ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Roadmap to 2.7.3
For reference: https://github.com/networkupstools/nut/issues/10 On Mar 5, 2015, at 1:09 AM, Baruch Even bar...@ev-en.org wrote: Hi, There is one issue that I would consider as a major issue and not fixed yet. It is the use of wall time for scheduling ups polls instead of a monotonic clock source. I provided a (partial) patch in the past and I believe there was some work on it. The bug manifests itself as a stop of monitoring with no alarm when the clock is moved backwards in time. Please consider adding this to the release. Hi Baruch, What seems to have happened is that it was assigned to an Eaton contractor, and it got tangled up in a C++ unit test framework branch that did not get fully merged before the contract apparently ended. It was also tagged in GitHub with the 2.8 milestone, probably with the understanding that there would be a few more 2.7.x incremental releases in the mean time. The issue list I mentioned for 2.7.3 is composed of two categories: small patches with limited impact, and a larger issue that would affect a lot of people (the NSS bug). While I think that monotonic clocks are the right solution for polling timers in the long term, I would be surprised if a lot of NUT installations worry about time going backwards, since that has big implications for log traceability. I am prepared to suggest releasing 2.7.3 with the NSS bug intact, since it fails safe (although useless) and can be worked around with configuration (run upsd in foreground). Documenting the handling of non-monotonic time as a known bug (with a simple patch tested on Linux) is perhaps not equivalent, but given the developer resource constraints we have had over the past year, I think it is not out of the question. -- Charles Lepple clepple@gmail ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Re: [Nut-upsdev] Roadmap to 2.7.3
Hi, There is one issue that I would consider as a major issue and not fixed yet. It is the use of wall time for scheduling ups polls instead of a monotonic clock source. I provided a (partial) patch in the past and I believe there was some work on it. The bug manifests itself as a stop of monitoring with no alarm when the clock is moved backwards in time. Please consider adding this to the release. Cheers, Baruch On Wed, Mar 4, 2015 at 4:04 PM, Charles Lepple clep...@gmail.com wrote: We only have a few open items that I think should be resolved before releasing 2.7.3. The list grew a bit in the past week, but we'll cover that later. Here is the list: * #93: Devices Dumps Library improvements https://github.com/networkupstools/nut/issues/93 * #158: Powerware BCMXCP advanced features https://github.com/networkupstools/nut/pull/158 * #185: insecure storage of password in nut-monitor favorites file https://github.com/networkupstools/nut/issues/185 * #187: Wrong in/out voltage repported for PowerCom KIN2200APRM https://github.com/networkupstools/nut/issues/187 * #190: upsd: NSS SSL only working in debug mode https://github.com/networkupstools/nut/issues/190 * eaton_epdus branch: https://github.com/networkupstools/nut/tree/eaton-epdus Most of these are from the GitHub 2.7.3 milestone: https://github.com/networkupstools/nut/issues?q=milestone%3A2.7.3 #93: The scope of this issue is a bit broad (encompassing a Gen3 dummy-ups driver, etc) but for 2.7.3, I think we can call this closed, so long as there are no issues pushing this to www.networkupstools.org. The current auto-generated DDL is here: http://buildbot.networkupstools.org/~buildbot/cayman/docs/latest/ddl/ #158: I will rebase the commits, and replace the author's email address with the GitHub username@noreply address, but if someone has additional Powerware-based UPSes to test, that would be handy. #185: Debian patch is on a branch; I will bump the version number and merge. #187: This is a driver-specfic fix, but I haven't had time to work through the logic from the vendor driver. This is not listed on the GitHub 2.7.3 milestone - should it be? #190 is a bit more complicated. We are still in the initial investigation stage, but it seems that this may have crept past the Ubuntu automated test suite. Running in the foreground is a bit of an ugly hack, but if it works with the Ubuntu init scripts... I'll let Arno cover the eaton_epdus branch. Also driver-specific (snmp-ups), so should not affect the rest of NUT. (Is this the same as issue #188? https://github.com/networkupstools/nut/issues/188 ) Glad to hear that Arno will have more time to work on NUT again! -- Charles Lepple clepple@gmail ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev ___ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
