** Description changed: - As described in the upstream report [1], HDF I/O using load/save is + As described in the upstream report [1], HDF5 I/O using load/save is broken in 4.0.0. This is a regression with the potential for data loss (almost happened to us!). - The bug is fixed upstream with [2], and I plan on making an SRU request - with an updated octave package that includes this patch (will be my - first SRU). + The bug is fixed upstream with [2], and I plan on nominating this bug + for an SRU request and to attach a debdiff. - To reproduce: - * Extract the attached .tar.gz, which contains test_hdf5_save.m and + [Test Case] + + 1. Extract the attached .tar.gz, which contains test_hdf5_save.m and test_hdf5_load.m from the upstream report. - * Run: + 2. Run: - [Octave 3.8] + 2.1. On Octave 3.8: - octave:1> test_hdf5_save - x = 123456789 + octave:1> test_hdf5_save + x = 123456789 - [Octave 4.0.0] + 2.2. On Octave 4.0.0: - octave:1> test_hdf5_load - x = 255 + octave:1> test_hdf5_load + x = 255 - And the other way around: + 3. Run (the other way around): - [Octave 4.0.0] + 3.1. On Octave 4.0.0: - octave:2> test_hdf5_save - x = 123456789 + octave:2> test_hdf5_save + x = 123456789 - [Octave 3.8] + 3.2. Octave 3.8: - octave:1> test_hdf5_load - x = 21 + octave:1> test_hdf5_load + x = 21 As you can see, in both cases the result is wrong. + + [Regression Potential] + + There's really no risk of any regressions. The fix is small and self + contained, and the behavior before the fix is completely wrong and could + result in data loss. + + [1] http://savannah.gnu.org/bugs/?45225 [2] http://hg.savannah.gnu.org/hgweb/octave/rev/d54aa96abadf
** Description changed: As described in the upstream report [1], HDF5 I/O using load/save is broken in 4.0.0. This is a regression with the potential for data loss (almost happened to us!). The bug is fixed upstream with [2], and I plan on nominating this bug - for an SRU request and to attach a debdiff. - + for an SRU request and attach a debdiff. [Test Case] 1. Extract the attached .tar.gz, which contains test_hdf5_save.m and test_hdf5_load.m from the upstream report. 2. Run: 2.1. On Octave 3.8: - octave:1> test_hdf5_save - x = 123456789 + octave:1> test_hdf5_save + x = 123456789 2.2. On Octave 4.0.0: - octave:1> test_hdf5_load - x = 255 + octave:1> test_hdf5_load + x = 255 3. Run (the other way around): 3.1. On Octave 4.0.0: - octave:2> test_hdf5_save - x = 123456789 + octave:2> test_hdf5_save + x = 123456789 3.2. Octave 3.8: - octave:1> test_hdf5_load - x = 21 + octave:1> test_hdf5_load + x = 21 As you can see, in both cases the result is wrong. - [Regression Potential] There's really no risk of any regressions. The fix is small and self contained, and the behavior before the fix is completely wrong and could result in data loss. - [1] http://savannah.gnu.org/bugs/?45225 [2] http://hg.savannah.gnu.org/hgweb/octave/rev/d54aa96abadf -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1583128 Title: HDF5 I/O broken with integer variables To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/octave/+bug/1583128/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
