+++ This bug was initially created as a clone of Bug #725542 +++

Description of problem:

Installing updated rpm does not upgrade instances.

Version-Release number of selected component (if applicable):

389-ds-base-1.2.9.0-1.fc15.i686

Steps to Reproduce:
1.
2.
3.
1. yum install ipa-server
2. ipa-server-install
3. kinit admin
4. yum -y --enablerepo=updates-testing update 389-ds-base
5. ipa user-add --first=test --last=user testuser
ipa: ERROR: attribute "entryusn" not allowed 
  
Actual results:

The upgrade seems to be silently erroring out:

# service dirsrv stop
# /usr/sbin/setup-ds.pl -u -s General.UpdateMode=offline
Integer overflow in hexadecimal number at /usr/share/dirsrv/updates/50fixNsState.pl line 51.
Integer overflow in hexadecimal number at /usr/share/dirsrv/updates/50fixNsState.pl line 58.
Invalid type 'Q' in unpack at /usr/share/dirsrv/updates/50fixNsState.pl line 48.

--- Additional comment from nhosoi on 2011-07-25 16:01:00 EDT ---

I could reproduce the problem on my 32-bit laptop.

It may not be very accurate, but this diff works around the problem...
# diff  /tmp/50fixNsState.pl.orig  50fixNsState.pl 
51c51
<     my $tssecs = ($ts - 0x01B21DD213814000) / 10000000;
---
>     my $tssecs = $ts / 1000000 - 455204129;

--- Additional comment from nhosoi on 2011-07-25 17:10:20 EDT ---

Igmore my previous comment...
0x01B21DD213814000 = 122192928000000000
0x01B21DD213814000 / 10000000 = 12219292800

So, the work around would be:
     my $tssecs = $ts / 1000000 - 12219292800;
or
     my $tssecs = $ts / 1000000 - 0x2D8539C80;

--- Additional comment from rmeggins on 2011-07-26 13:12:13 EDT ---

Just great - rhel5 32-bit perl is not built with support for long long :-(

--- Additional comment from nhosoi on 2011-07-26 13:27:57 EDT ---

(In reply to comment #3)
> Just great - rhel5 32-bit perl is not built with support for long long :-(

Are we filing a bug against 32-bit perl?  I think it's a serious bug for perl users...

--- Additional comment from rmeggins on 2011-07-26 13:32:46 EDT ---

(In reply to comment #4)
> (In reply to comment #3)
> > Just great - rhel5 32-bit perl is not built with support for long long :-(
> 
> Are we filing a bug against 32-bit perl?  I think it's a serious bug for perl
> users...

I'll try to find out.  But we may not have a choice - we may have to find a workaround for 32-bit perl

--- Additional comment from rmeggins on 2011-07-26 19:04:37 EDT ---

Created attachment 515383 [details]
0001-Bug-725542-Instance-upgrade-fails-when-upgrading-389.patch

--- Additional comment from rmeggins on 2011-07-26 19:06:59 EDT ---

Created attachment 515384 [details]
0001-Bug-725542-Instance-upgrade-fails-when-upgrading-389.patch

--- Additional comment from rmeggins on 2011-07-26 19:45:21 EDT ---

To ssh://git.fedorahosted.org/git/389/ds.git
   c5bd907..077544c  master -> master
commit 077544cad896413ec32801b565fbe220c91bc04e
Author: Rich Megginson <rmeggins>
Date:   Tue Jul 26 14:46:05 2011 -0600
    Reviewed by: nhosoi (Thanks!)
    Branch: master
    Fix Description: On 32-bit platforms, the pack 'Q' format specifier is not
    available unless perl is explicitly compiled with 64-bit long long support.
    Unfortunately, on RHEL/Fedora platforms, it is not.  Same with native suppor
t
    for 64-bit values - fortunately, the bigint package is available, so we use
    it.
    Additionally, the format flags '>' and '<' for little/big endianness are not
    available on perl 5.8 and earlier, so they are not very portable.  Finally,
    the way we write the 32-bit unique id generator state is simply not usable.
    We already skip it if going from 32-bit to 64-bit, so just ignore it if
    going from 32-bit to 32-bit.  The fix is to unpack the 64-bit integer
    values using two 32-bit values, using 'V' first, then 'N' if we think the
    value might be big-endian (e.g. sparc).  For short values, 'v' or 'n'.
    The 64-bit values are stored with the low part first, followed by the high
    part.  We convert these two 32-bit values to a native 64-bit value to
    perform computations with it, then convert it back to two 32-bit values.
    Then pack the values using the format for the current platform -
    unfortunately we do not use a platform independent way to store the
    nsState values.
    Platforms tested: RHEL6 x86_64 and RHEL5 i386
    Flag Day: no
    Doc impact: no