--- mdadm-3.2.3/config.c        2011-12-15 04:13:08.000000000 +0000
+++ mdadm-3.2.5/config.c        2012-05-18 07:10:03.000000000 +0000
@@ -921,19 +921,19 @@
         * else 'yes'.
         */
        struct dev_policy *p;
-       int no=0, found_auto=0;
+       int no=0, found_homehost=0;
        load_conffile();
 
        pol = pol_find(pol, pol_auto);
        pol_for_each(p, pol, version) {
                if (strcmp(p->value, "yes") == 0)
                        return 1;
-               if (strcmp(p->value, "auto") == 0)
-                       found_auto = 1;
+               if (strcmp(p->value, "homehost") == 0)
+                       found_homehost = 1;
                if (strcmp(p->value, "no") == 0)
                        no = 1;
        }
-       if (is_homehost && found_auto)
+       if (is_homehost && found_homehost)
                return 1;
        if (no)
                return 0;

This appears to be an interface change.  Why is this appropriate for an SRU?

+mdadm (3.2.5-1ubuntu2~12.04.1) precise-proposed; urgency=low

This is not the preferred numbering convention, as documented at <https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging>.  Please use 3.2.5-1ubuntu0.1 as the version number here.  Please also consolidate all the relevant information into a single changelog entry, which is the convention for SRUs.  Bug #920324, for instance, has nothing to do with the SRU, and so should not be referenced in the changelog.

--- mdadm-3.2.3/debian/checkarray       2012-01-29 05:36:30.000000000 +0000
+++ mdadm-3.2.5/debian/checkarray       2012-06-15 09:42:28.000000000 +0000
@@ -175,6 +175,21 @@

The only reference in the changelog for this change is a Debian bug report.  If this change is relevant for SRUing, it should get a separate bug report in Launchpad for tracking (targeted to precise); otherwise the change should be omitted from the SRU.  (My recommendation is to omit the change.)

Likewise for this change:

--- mdadm-3.2.3/debian/mdadm.logcheck.ignore.server     2012-01-29 05:36:30.000000000 +0000
+++ mdadm-3.2.5/debian/mdadm.logcheck.ignore.server     2012-06-15 09:42:28.000000000 +0000
@@ -10,7 +10,7 @@

For bug #1002357, please provide an explicit test case related to the functionality of the udev rules so that we are verifying the empirical correctness of the behavior, and not just the contents of the package.

--- mdadm-3.2.3/debian/rules    2012-02-10 00:11:11.000000000 +0000
+++ mdadm-3.2.5/debian/rules    2012-06-15 10:54:50.000000000 +0000
@@ -75,10 +63,8 @@
        dh_installdirs
        chmod +x debian/install-rc
        PACKAGE=mdadm-udeb debian/install-rc check.d
-       install -m0755 mdadm $(DESTDIR)/sbin
-       install -m0755 mdadm.udeb $(DESTDIR_UDEB)/sbin/mdadm
-       install -m0644 debian/mdadm.mdadm-blkid.udev \
-               $(DESTDIR_UDEB)/etc/udev/rules.d/65-mdadm-blkid.rules
+
+       $(MAKE) install DESTDIR=$(DESTDIR)
 
        install -m0755 debian/initramfs/hook \
                $(DESTDIR)/usr/share/initramfs-tools/hooks/mdadm

Build system changes are not normally appropriate for SRU.  Either these changes should be reverted / reduced to a minimal necessary change, or the test case for this SRU needs to include an explicit check that the contents of the binary packages have not changed.

--- mdadm-3.2.3/debian/source_mdadm.py  2011-03-18 15:58:15.000000000 +0000
+++ mdadm-3.2.5/debian/source_mdadm.py  2012-06-15 11:33:14.000000000 +0000

These changes are not required by or appropriate for SRU, and the risk of regression is not entirely 0.  Please drop this part of the delta.

--- mdadm-3.2.3/Grow.c  2011-12-23 03:10:01.000000000 +0000
+++ mdadm-3.2.5/Grow.c  2012-05-18 07:10:03.000000000 +0000
@@ -424,8 +424,8 @@

These upstream changes are quite extensive.  I think they're only acceptable in SRU on the grounds that this is not an operation one performs on a RAID array as part of the normal operations; so while there's risk of new bugs introduced here, the impact of any such bugs that have escaped upstream QA is quite small, and the benefit of the added sanity checks on resize operations is substantial.

--- mdadm-3.2.3/mdadm.c 2011-12-22 20:17:28.000000000 +0000
+++ mdadm-3.2.5/mdadm.c 2012-05-18 07:10:03.000000000 +0000
@@ -1046,15 +1064,14 @@
                case O(BUILD,BitmapChunk):
                case O(CREATE,BitmapChunk): /* bitmap chunksize */
                        bitmap_chunk = parse_size(optarg);
-                       if (bitmap_chunk < 0 ||
+                       if (bitmap_chunk <= 0 ||
                            bitmap_chunk & (bitmap_chunk - 1)) {
                                fprintf(stderr,
                                        Name ": invalid bitmap chunksize: %s\n",
                                        optarg);
                                exit(2);
                        }
-                       /* convert sectors to B, chunk of 0 means 512B */
-                       bitmap_chunk = bitmap_chunk ? bitmap_chunk * 512 : 512;
+                       bitmap_chunk = bitmap_chunk * 512;
                        continue;
 
                case O(GROW, WriteBehind):

This is a backwards-incompatible behavior change that doesn't seem to make sense in an SRU.  Perhaps it should be dropped.

Rejecting this package from the queue since a reupload is needed for some of the above issues.