group.of.nepali.translators team mailing list archive

Thread
Date

[Bug 1583128] Re: HDF5 I/O broken with integer variables

To: group.of.nepali.translators@xxxxxxxxxxxxxxxxxxx
From: Launchpad Bug Tracker <1583128@xxxxxxxxxxxxxxxxxx>
Date: Thu, 26 May 2016 21:09:06 -0000
Reply-to: Bug 1583128 <1583128@xxxxxxxxxxxxxxxxxx>
Sender: bounces@xxxxxxxxxxxxx

This bug was fixed in the package octave - 4.0.0-3ubuntu9.1

---------------
octave (4.0.0-3ubuntu9.1) xenial; urgency=medium

  * debian/patches/hdf5-io-integer.patch: Add upstream patch to fix HDF5
    integer I/O. (LP: #1583128)

 -- Elvis Stansvik <elvstone@xxxxxxxxx>  Wed, 18 May 2016 10:03:26 -0500

** Changed in: octave (Ubuntu Xenial)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1583128

Title:
  HDF5 I/O broken with integer variables

Status in octave package in Ubuntu:
  Fix Released
Status in octave source package in Wily:
  Fix Released
Status in octave source package in Xenial:
  Fix Released

Bug 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 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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/octave/+bug/1583128/+subscriptions