Merge lp://qastaging/~yuningdodo/ubuntu/trusty/util-linux/util-linux.backport-wipefs-partition-table-erasing-support into lp://qastaging/ubuntu/trusty-updates/util-linux

I think this was workarounded in usb-creator instead, am I wrong? With the reasoning that this new feature backport would be a little too heavy in a core part like util-linux.

The latest usb-creator in 14.04 LTS is this https://launchpad.net/ubuntu/+source/usb-creator/0.2.56.3

So I'd mark this as rejected, please re-open if you think this should still be targeted towards trusty.

To be noted though for any core dev considering this, this version of the backport is much less invasive than the previous one https://code.launchpad.net/~yuningdodo/ubuntu/trusty/util-linux/util-linux.backport-utopic-2.25-8ubuntu1/+merge/232848

Hmm, reopening. As noted on the bug, the disk utility program would still need this.

How does this affect https://launchpad.net/bugs/1046665? Have you also tested that this bug isn't regressed by these cherry-picks? What packages might be broken by the changes to libblkid?

It also seems to me like some of these commits probably aren't strictly required to support the changes to wipefs, since that's what is at stake here. Do you have a deep enough understanding of the changes here to know exactly why each of these commits are required? It looks to me like only a subset of these changes might be required to fix the targetted bug, but I only looked really quickly.

For example, it seems to me like the fix should work without the last three commits, and just the addition of blkid_do_wipe in libblkid/src/probe.c from 2b89be6c802bdbdf6830dbd060c96e33f179b135.

Thanks for the review.

I checked the ubuntu branch, lp:ubuntu/util-linux, bug #1046665 was firstly fixed in rev90 by retrying the operation several times. Later in rev110 the code was entirely merged with debian experimental, and the previous retry was now implemented by calling blkid_do_probe() multiple times until it returns false. What I proposed to do for the trusty branch is similar, first retire the previous retrying logic then introduce the new implementation, so I believe it will not regress bug #1046665. About libblkid, here is a summary of what have been changed:

* new flag: BLKID_PARTS_MAGIC.
* new public method blkid_probe_wipe().
* declaration of blkid_probe_set_magic() is moved to libblkid/src/blkid.h from libblkid/src/superblocks/superblocks.h, so it will become a public method.

Besides these API changes, there are also some internal changes. I think they won't break the API backward compatibility of libblkid.

About the picked patches, I can't say I have a deep enough understanding about the patches, actually I picked them based on the test results of this simple testcase:

dd if=/dev/zero of=data bs=1M count=4
parted data --script -- mklabel msdos
parted data --script -- mkpart primary fat16 0 -0
wipefs -a data # it's expected to output "2 bytes were erased at offset 0x000001fe (dos): 55 aa"

With the first two patches it's not enough to erase the "55aa" signature. In fact the key patch is the last one, 44765fdd841fb1369cf68f360131ed076f3a2771, the other 4 patches are just its dependences. If we want to only pick the key patch, we may have to modify it a lot and causes future conflicts when other patches are being backported.

Any updates on this?