Please SRU ghc6 in Hardy to fix correctness bug

Bug #280129 reported by Iain Lane
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
darcs (Ubuntu)
Fix Released
Undecided
Unassigned
Hardy
Invalid
Undecided
Unassigned
ghc6 (Ubuntu)
Fix Released
Undecided
Unassigned
Hardy
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: ghc6

Hello all,

The version of GHC in Hardy has an important correctness bug in the getSymbolicLinkStatus (and possibly other) functions due to a misconfiguration in the configure.ac file. We have backported a fix from upstream's current release to the version in Intrepid to deal with this issue and would like to SRU it in Hardy too. The fixed version is 6.8.2-6ubuntu2. Full details of the investigation and fix are in bug #263773. Further to this, Darcs will need to be rebuilt if and when a new GHC version hits to pick up the fix.

There are two choices:

1) Simply upload the version in Intrepid to Hardy with a suitably modified version number. There have been only bug/buildfix updates to the package between the two releases, as evidenced by the changelog:

ghc6 (6.8.2-6ubuntu2) intrepid; urgency=low

  * libraries/unix/configure.ac: Use AC_SYS_LARGEFILE, taken from
    <http://hackage.haskell.org/trac/ghc/ticket/2093>. Fixes
    accessing getSymbolicLinkStatus with the wrong offsets,
    LP: #263773.
  * Run autoreconf in libraries/unix so that the configure.ac change
    takes effect.
  * debian/control: Set Maintainer from myself to MOTU.

 -- Stefan Potyra <email address hidden> Sat, 27 Sep 2008 22:19:03 +0200

ghc6 (6.8.2-6ubuntu1) intrepid; urgency=low

  * Merge from Debian unstable (LP: #270601), remaining changes:
    + make lpia similar to i386 in debian/rules
    + add lpia to debian/ghc6_vars via debian/rules
    + add manpage for runghc

 -- Iain Lane <email address hidden> Mon, 15 Sep 2008 20:26:40 +0100

ghc6 (6.8.2-6) unstable; urgency=medium

  * New maintainer.
  * Made the perl script driver/split/ghc-split not use the obsolete $*
    var (Closes: #489157)
  * Copied libraries/unix/System/Posix/Resource.hsc and
    libraries/base/include/HsBase.h from 6.8.3 to fix issues with
    setResourceLimit. (Closes: #491909)

 -- Kari Pahula <email address hidden> Wed, 03 Sep 2008 23:41:18 +0300

ghc6 (6.8.2-5ubuntu1) intrepid; urgency=low

  * Rebase to unstable, remaining changes:
    + make lpia similar to i386 in debian/rules
      (Adam Conrad who thanked Ian Lynagh).
    + add lpia to debian/ghc6_vars via debian/rules (Adam Conrad).
    + add manpage for runghc (Efrain Valles Pulgar), referring to
      LP bug #95985. Added: debian/runghc.man, and modified
      debian/rules.
    + change Maintainer field to myself in debian/control.

 -- Stefan Potyra <email address hidden> Sat, 10 May 2008 12:19:35 +0200

ghc6 (6.8.2-5) unstable; urgency=low

  * Don't build template-haskell if we're not building GHCi.
    The package is largely useless without GHCi, and some of the buildds
    were having trouble building template-haskell. We'll need to fix
    this some other way if GHCi is to be available on every arch, though...

 -- Ian Lynagh (wibble) <email address hidden> Thu, 01 May 2008 12:32:13 +0000

ghc6 (6.8.2-4) unstable; urgency=low

  * Small wibbles to debian/watcher.sh.
  * Add a build-dep on procps (debian/watcher.sh runs ps).

 -- Ian Lynagh (wibble) <email address hidden> Wed, 26 Mar 2008 17:12:18 +0000

ghc6 (6.8.2-3) unstable; urgency=low

  * Every 10 minutes, print any "ps ux" lines that mention gcc or ghc.
    According to folks on IRC, this is standard practice. It means that
    we don't have to worry about security buildds having different
    timeouts to the normal builders.
  * Apply upstream patch:
        FIX #2073: Don't add empty lines to GHCI's history
        Ian Lynagh <email address hidden>**20080224143256
    Closes: #461170.

 -- Ian Lynagh (wibble) <email address hidden> Mon, 24 Mar 2008 22:09:02 +0000

None of these changes are intrusive and would have any unwelcome side-effects.

2) Backport the important fix from bug #263773. This is the fix that we really want as it is both a correctness bug and a performance bug in Darcs. If option 1 is unpalatable then I would urge that we at least do this. sistpoty has analysed the ABI and determined that the fix does not change it, so the chance for regressions is slim to none.

MOTU-SRU members, please determine if option 1 is appropriate, or if not then please accept option 2.

Thank you for your time,
Iain

Revision history for this message
StefanPotyra (sistpoty) wrote :

Just to add:
Personally I'm in favor of just using the current intrepid version. It has seen a round of testing now, and less changes mean less chances to break.

Some test-cases for the bugs:
TEST CASE 1, concerning bug #263773:

Test the following on an 32bit system (e.g. i386). Unfixed, it will give random results (should be: inode number)
<code>
import System.Posix.Files

main = do
  System.Posix.Files.getFileStatus "/" >>= print . System.Posix.Files.fileID
</code>

TEST CASE 2, concerning bug #270601 is listed in that bug.

For the watcher.sh/printing s.th. every 10 minutes: Most probably it won't build on sparc due to timing out (see bug #194912, prior to that change it needed manual buildd admin intervention).

Revision history for this message
StefanPotyra (sistpoty) wrote :

Hi motu-sru, any news on this one?
Cheers,
      Stefan.

Revision history for this message
StefanPotyra (sistpoty) wrote :

Oh, I've approved the hardy tasks now, as these are in fact bugs in hardy. If you don't think we should fix them, please mark as won't fix, thanks.

Changed in darcs:
status: New → Triaged
Changed in ghc6:
status: New → Triaged
Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote :

Hm, so has this fix not yet been applied to Hardy? I'm working with someone on Hardy right now, and his darcs executable, which he built himself using Hardy's version of ghc-6.8.2 is very slow...

Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote :

Hi, I'm still concerned about this issue. As far as I understand, the ghc in hardy has a bug which returns random data when asked for the inode number. This causes any darcs executable built with that ghc to run very slowly (presumably because it is trying to use a bunch of random bogus inode numbers?). Until this is fixed in Hardy, I have to ask people to be careful not to use ghc on Hardy, which raises the question of what they should do instead. If this is fixed, I can instead ask them just to upgrade to the fix.

Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote :

Wait a minute, is this the same bug as https://bugs.launchpad.net/ubuntu/+source/ghc6/+bug/263773 ? That one is marked as fix-released.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500407

Should this ticket be closed as fix-released or duplicate ?

Revision history for this message
Phillip Susi (psusi) wrote :

Hardy has reached end of life.

Changed in ghc6 (Ubuntu Hardy):
status: Triaged → Invalid
Changed in darcs (Ubuntu Hardy):
status: Triaged → Invalid
Changed in ghc6 (Ubuntu):
status: New → Fix Released
Changed in darcs (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.