Merge lp://staging/~xnox/ubuntu/quantal/mdadm/merge into lp://staging/~xnox/ubuntu/quantal/mdadm/quantal

I had to create relevant UDD branches myself due to import failures. But this is the easiest way to inspect ubuntudiff against previous ubuntu revision, and debdiff (which is minimised) against last merged debian revision.

There is updated debian release, but it is RC-buggy, pending on a new upstream release.

There is more work to do in the initramfs hooks, but that will wait until RAID/Architecture doc is ready.

--- debian/mdadm-udeb.dirs 2010-09-30 17:46:19 +0000
+++ debian/mdadm-udeb.dirs 2012-05-21 23:36:55 +0000
@@ -1,4 +1,3 @@
 sbin
-usr/share/lintian/overrides
-etc/udev/rules.d
+lib/udev/rules.d
 lib/partman

The function of dh_installdirs is to create empty directories that will be shipped in packages. You don't need to list lib/udev/rules.d here, any more than you need to list the others that you dropped - as you can see from the existing udeb package, /lib/udev/rules.d/64-md-raid.rules already installs fine without setting the directory here.

(This is a very old and difficult to eradicate bit of cargo-culting, which has been circulating since at least 2001 in Debian... :)

The one behavior change I notice between the previous Ubuntu rules and the upstream rules is that upstream has this:

ENV{ID_FS_TYPE}=="ddf_raid_member|isw_raid_member|linux_raid_member", GOTO="md_inc"
[...]
ACTION=="add", RUN+="/sbin/mdadm --incremental $tempnode"

where Ubuntu had this:

SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_FS_TYPE}=="linux_raid*", \
        RUN+="/sbin/mdadm --incremental $env{DEVNAME}"

Do we know what ddf_raid_member and isw_raid_member are, and what effect this change will have?

Otherwise, I agree with the analysis that the upstream rules are already doing what we want and we should drop the delta from upstream.

--- debian/initramfs/hook 2010-09-30 17:46:19 +0000
+++ debian/initramfs/hook 2012-05-29 21:24:34 +0000
@@ -52,7 +52,7 @@
 copy_exec /sbin/mdadm /sbin

 # copy the udev rules
-for rules in 65-mdadm-blkid.rules 85-mdadm.rules; do
+for rules in 64-md-raid.rules; do
        cp -p /lib/udev/rules.d/$rules ${DESTDIR}/lib/udev/rules.d
 done

It's interesting how much divergence there is from Debian in the initramfs hook. Anyway, I think this particular bit is better written:

  cp /lib/udev/rules.d/64-md-raid.rules $DESTDIR/lib/udev/rules.d/

Further minimizing the delta from Debian is left as an exercise for the reader.

Otherwise, this looks good to me.

On 30/05/12 00:14, Steve Langasek wrote:
> --- debian/mdadm-udeb.dirs 2010-09-30 17:46:19 +0000
> +++ debian/mdadm-udeb.dirs 2012-05-21 23:36:55 +0000
> @@ -1,4 +1,3 @@
> sbin
> -usr/share/lintian/overrides
> -etc/udev/rules.d
> +lib/udev/rules.d
> lib/partman
>
> The function of dh_installdirs is to create empty directories that will be shipped in packages. You don't need to list lib/udev/rules.d here, any more than you need to list the others that you dropped - as you can see from the existing udeb package, /lib/udev/rules.d/64-md-raid.rules already installs fine without setting the directory here.
>

True and I know that =). We previously did have one spurious rules.d
file installed into etc/ in the udeb. After removing it, I was confused
where the empty directory comes from now?! I have been submitting
clean-up patches to debian. I'll do it there.

> (This is a very old and difficult to eradicate bit of cargo-culting, which has been circulating since at least 2001 in Debian... :)
>

To me this reminds of RPM spec files, where you have to explicitly list
which folders and files are 'owned' by which package.

> The one behavior change I notice between the previous Ubuntu rules and the upstream rules is that upstream has this:
>

Yes =)))

> ENV{ID_FS_TYPE}=="ddf_raid_member|isw_raid_member|linux_raid_member", GOTO="md_inc"
> [...]
> ACTION=="add", RUN+="/sbin/mdadm --incremental $tempnode"
>
> where Ubuntu had this:
>
> SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_FS_TYPE}=="linux_raid*", \
> RUN+="/sbin/mdadm --incremental $env{DEVNAME}"
>
> Do we know what ddf_raid_member and isw_raid_member are, and what effect this change will have?
>

ddf_raid_members seems to be Common RAID Disk Data Format specification.
isw_raid_members is advertised as simply "Interl(r) RAID" aka Intel
Matrix Raid.

Both of these require mdmon utility and it has been requested to be
added in:
https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/957494/comments/2

It will enable assembling these two additional RAID data formats.

> Otherwise, I agree with the analysis that the upstream rules are already doing what we want and we should drop the delta from upstream.
>
> --- debian/initramfs/hook 2010-09-30 17:46:19 +0000
> +++ debian/initramfs/hook 2012-05-29 21:24:34 +0000
> @@ -52,7 +52,7 @@
> copy_exec /sbin/mdadm /sbin
>
> # copy the udev rules
> -for rules in 65-mdadm-blkid.rules 85-mdadm.rules; do
> +for rules in 64-md-raid.rules; do
> cp -p /lib/udev/rules.d/$rules ${DESTDIR}/lib/udev/rules.d
> done
>
> It's interesting how much divergence there is from Debian in the initramfs hook. Anyway, I think this particular bit is better written:
>

We actually have white space divergence for most of it (tab vs space)

> cp /lib/udev/rules.d/64-md-raid.rules $DESTDIR/lib/udev/rules.d/
>

ok =)

> Further minimizing the delta from Debian is left as an exercise for the reader.
>

I started and gave up for this patch.

> Otherwise, this looks good to me.
>

Ok thanks.

Let me push some updates.

Regards,

Dmitrijs.

On 30/05/12 00:14, Steve Langasek wrote:
> --- debian/mdadm-udeb.dirs 2010-09-30 17:46:19 +0000
> +++ debian/mdadm-udeb.dirs 2012-05-21 23:36:55 +0000
> @@ -1,4 +1,3 @@
> sbin
> -usr/share/lintian/overrides
> -etc/udev/rules.d
> +lib/udev/rules.d
> lib/partman
>

Actually spoke too soon. Currently it FTBFS without it =)

In Debian,

debian/rules:
> install -m0644 udev-md-raid.rules $(DESTDIR_UDEB)/lib/udev/rules.d/64-md-raid.rules

Assumes the the directory exists already. I was trying to minimise diff
against debian/upstream hence added the dirs stanza & above installation.

It should be using `install -D`, cause dh_install still cannot rename
files...

Extra delta against debian vs extra lines in .dirs...
I pick the latter.

Regards,
Dmitrijs

> It should be using `install -D`, cause dh_install still cannot rename
> files...

You can do this using dh-exec, fwiw.

On 30/05/12 18:57, Steve Langasek wrote:
>> It should be using `install -D`, cause dh_install still cannot rename
>> files...
>
> You can do this using dh-exec, fwiw.
>

Today I learned: dh-exec

Literary blew my mind away =)

/me off to convert my debian packages to multiarch