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.
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.)
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.
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.
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/config. c 2011-12-15 04:13:08.000000000 +0000 2.5/config. c 2012-05-18 07:10:03.000000000 +0000
load_conffile( );
+++ mdadm-3.
@@ -921,19 +921,19 @@
* else 'yes'.
*/
struct dev_policy *p;
- int no=0, found_auto=0;
+ int no=0, found_homehost=0;
pol = pol_find(pol, pol_auto);
pol_for_ each(p, pol, version) {
return 1;
no = 1;
return 1;
return 0;
if (strcmp(p->value, "yes") == 0)
- if (strcmp(p->value, "auto") == 0)
- found_auto = 1;
+ if (strcmp(p->value, "homehost") == 0)
+ found_homehost = 1;
if (strcmp(p->value, "no") == 0)
}
- if (is_homehost && found_auto)
+ if (is_homehost && found_homehost)
if (no)
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/SecurityTea m/UpdatePrepara tion#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 2.5/debian/ checkarray 2012-06-15 09:42:28.000000000 +0000
+++ mdadm-3.
@@ -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 2.5/debian/ mdadm.logcheck. ignore. server 2012-06-15 09:42:28.000000000 +0000
+++ mdadm-3.
@@ -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 2.5/debian/ rules 2012-06-15 10:54:50.000000000 +0000
dh_installdirs
PACKAGE= mdadm-udeb debian/install-rc check.d UDEB)/sbin/ mdadm mdadm.mdadm- blkid.udev \ UDEB)/etc/ udev/rules. d/65-mdadm- blkid.rules
+++ mdadm-3.
@@ -75,10 +63,8 @@
chmod +x debian/install-rc
- install -m0755 mdadm $(DESTDIR)/sbin
- install -m0755 mdadm.udeb $(DESTDIR_
- install -m0644 debian/
- $(DESTDIR_
+
+ $(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 2.5/debian/ source_ mdadm.py 2012-06-15 11:33:14.000000000 +0000
+++ mdadm-3.
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
case O(BUILD, BitmapChunk) :
case O(CREATE, BitmapChunk) : /* bitmap chunksize */
bitmap_ chunk = parse_size(optarg);
bitmap_ chunk & (bitmap_chunk - 1)) {
fprintf( stderr,
Name ": invalid bitmap chunksize: %s\n",
optarg) ;
exit( 2);
}
continue;
+++ mdadm-3.2.5/mdadm.c 2012-05-18 07:10:03.000000000 +0000
@@ -1046,15 +1064,14 @@
- if (bitmap_chunk < 0 ||
+ if (bitmap_chunk <= 0 ||
- /* convert sectors to B, chunk of 0 means 512B */
- bitmap_chunk = bitmap_chunk ? bitmap_chunk * 512 : 512;
+ bitmap_chunk = bitmap_chunk * 512;
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.