| 2016-05-18 11:25:59 |
Elvis Stansvik |
bug |
|
|
added bug |
| 2016-05-18 11:25:59 |
Elvis Stansvik |
attachment added |
|
Test case for saving/loading HDF5 with integer data https://bugs.launchpad.net/bugs/1583128/+attachment/4665399/+files/test_hdf5.tar.gz |
|
| 2016-05-18 11:54:06 |
Elvis Stansvik |
description |
As described in the upstream report [1], HDF 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).
To reproduce:
* Extract the attached .tar.gz, which contains test_hdf5_save.m and test_hdf5_load.m from the upstream report.
* Run:
[Octave 3.8]
octave:1> test_hdf5_save
x = 123456789
[Octave 4.0.0]
octave:1> test_hdf5_load
x = 255
And the other way around:
[Octave 4.0.0]
octave:2> test_hdf5_save
x = 123456789
[Octave 3.8]
octave:1> test_hdf5_load
x = 21
As you can see, in both cases the result is wrong.
[1] http://savannah.gnu.org/bugs/?45225
[2] http://hg.savannah.gnu.org/hgweb/octave/rev/d54aa96abadf |
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.
[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
2.2. On Octave 4.0.0:
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
3.2. Octave 3.8:
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 |
|
| 2016-05-18 11:55:52 |
Elvis Stansvik |
description |
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.
[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
2.2. On Octave 4.0.0:
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
3.2. Octave 3.8:
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 |
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 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
2.2. On Octave 4.0.0:
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
3.2. Octave 3.8:
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 |
|
| 2016-05-18 12:27:21 |
Elvis Stansvik |
description |
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 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
2.2. On Octave 4.0.0:
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
3.2. Octave 3.8:
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 |
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 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
2.2. On Octave 4.0.0:
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
3.2. Octave 3.8:
octave:1> test_hdf5_load
x = 21
As you can see, in both cases the result is wrong.
With the updated package installed, which includes the patch, the result is instead
octave:1> test_hdf5_save
x = 123456789
octave:1> test_hdf5_load
x = 123456789
in both directions (3.8 -> 4.0.0 and 4.0.0 -> 3.8), as expected.
[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 |
|
| 2016-05-18 12:27:50 |
Elvis Stansvik |
attachment removed |
Test case for saving/loading HDF5 with integer data https://bugs.launchpad.net/ubuntu/+source/octave/+bug/1583128/+attachment/4665399/+files/test_hdf5.tar.gz |
|
|
| 2016-05-18 12:28:23 |
Elvis Stansvik |
attachment added |
|
Test case for saving/loading HDF5 with integer data https://bugs.launchpad.net/ubuntu/+source/octave/+bug/1583128/+attachment/4665441/+files/test_hdf5.tar.gz |
|
| 2016-05-18 12:50:41 |
Elvis Stansvik |
attachment added |
|
debdiff for octave_4.0.0-3ubuntu9 source package https://bugs.launchpad.net/ubuntu/+source/octave/+bug/1583128/+attachment/4665484/+files/octave_4.0.0-3ubuntu10.debdiff |
|
| 2016-05-18 12:52:30 |
Elvis Stansvik |
description |
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 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
2.2. On Octave 4.0.0:
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
3.2. Octave 3.8:
octave:1> test_hdf5_load
x = 21
As you can see, in both cases the result is wrong.
With the updated package installed, which includes the patch, the result is instead
octave:1> test_hdf5_save
x = 123456789
octave:1> test_hdf5_load
x = 123456789
in both directions (3.8 -> 4.0.0 and 4.0.0 -> 3.8), as expected.
[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 |
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 asking for an SRU nomination.
[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
2.2. On Octave 4.0.0:
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
3.2. Octave 3.8:
octave:1> test_hdf5_load
x = 21
As you can see, in both cases the result is wrong.
With the updated package installed (see attached debdiff), the result is instead
octave:1> test_hdf5_save
x = 123456789
octave:1> test_hdf5_load
x = 123456789
in both directions (3.8 -> 4.0.0 and 4.0.0 -> 3.8), as expected.
[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 |
|
| 2016-05-18 13:20:14 |
Chris J Arges |
nominated for series |
|
Ubuntu Xenial |
|
| 2016-05-18 13:20:14 |
Chris J Arges |
bug task added |
|
octave (Ubuntu Xenial) |
|
| 2016-05-18 15:03:10 |
Chris J Arges |
octave (Ubuntu): status |
New |
Fix Released |
|
| 2016-05-18 17:31:44 |
Chris J Arges |
nominated for series |
|
Ubuntu Wily |
|
| 2016-05-18 17:31:44 |
Chris J Arges |
bug task added |
|
octave (Ubuntu Wily) |
|
| 2016-05-18 17:41:14 |
Elvis Stansvik |
attachment added |
|
debdiff for the wily package https://bugs.launchpad.net/ubuntu/+source/octave/+bug/1583128/+attachment/4665708/+files/octave_4.0.0-3ubuntu6.debdiff |
|
| 2016-05-18 18:07:06 |
Gianfranco Costamagna |
bug |
|
|
added subscriber LocutusOfBorg |
| 2016-05-18 18:45:56 |
Amr Ibrahim |
bug |
|
|
added subscriber Amr Ibrahim |
| 2016-05-19 08:02:59 |
Martin Pitt |
octave (Ubuntu Xenial): status |
New |
Fix Committed |
|
| 2016-05-19 08:03:01 |
Martin Pitt |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2016-05-19 08:03:02 |
Martin Pitt |
bug |
|
|
added subscriber SRU Verification |
| 2016-05-19 08:03:05 |
Martin Pitt |
tags |
|
verification-needed |
|
| 2016-05-19 11:33:50 |
Elvis Stansvik |
tags |
verification-needed |
verification-done |
|
| 2016-05-19 18:56:41 |
Elvis Stansvik |
tags |
verification-done |
verification-done-xenial verification-needed |
|
| 2016-05-19 20:24:06 |
Brian Murray |
octave (Ubuntu Wily): status |
New |
Fix Committed |
|
| 2016-05-20 17:19:25 |
Elvis Stansvik |
tags |
verification-done-xenial verification-needed |
verification-done |
|
| 2016-05-26 21:08:20 |
Launchpad Janitor |
octave (Ubuntu Wily): status |
Fix Committed |
Fix Released |
|
| 2016-05-26 21:08:26 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2016-05-26 21:09:06 |
Launchpad Janitor |
octave (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
