> You self-identified an apparent defect in a particular software package,
> when in fact that package was working normally and as designed.

Fact: it "worked" before jaunty, with jaunty it's broken.

> It's often better to *not* jump directly to the source as you did; had
> you filed a more generic bug, our QA team would have been able to triage
> it far more effectively and identify the real problem.

You are just denying what the real problem is.

> Right, so blkid behaves the same. 

THIS version of blkid behaves the same broken way as vol_id. Previous versions of blkid reported a UUID.

> For every person that authoratively asserts, as you just did, that X is
> always preferred over Y - I can find you somebody who asserts the exact
> opposite.

Yeah, I've read that one before. The perfect excuse for never fixing anything.

BULLSHIT.

I _demonstrated_ that if you have both a LUKS header and a swap header on a partition, it means that cryptsetup was run after mkswap. So that partition is _supposed_ to be a LUKS partition. An in fact it is way more likely to be a LUKS partition than a swap partition. If it were a swap partition with a stale LUKS signature it would mean that the owner of the system took unusual steps (e.g. running cryptsetup, reverting to regular swap but not running mkswap again).

Now find me someone that will assert and demonstrate the reverse.

> The better solution is to ensure that there is never a case of
> conflicting meta-data on a block device.

That's correct, but that's another problem. Yes you can use migration scripts to remove the stale signature. It's going to be more complicated to implement and test than just FIXING udev to report ANY UUID (as blkid used to do before).

> Because it isn't a bug.

Yes it is.

> The software is working exactly as designed.

Probably not. Even then, if there is a design goal that states "when there are two possible UUID do not report ANY" that design goal is plain wrong and must go. 

> If you'd like to complain about the design of the software, upstream is
> a far better place to do that - we're just a distro. 

I am going to do that too. But in the interim, or if upstream fails to understand that, that can, and should, be patched at the distro level.

---

Now some words about the way YOU, Mr. Scott James Remnant, handled the issue:
- failed to realize that this is a migration problem that is going to impact actual users
- marked bug as "invalid" two times before thinking about it, suggesting an alternative (cryptsetup), and marked as "won't fix" even before evaluating the effort in the alternative vs. the effort in udev
- still fails to realize that the easiest short-term solution for the distro is to fix udev.

And this is how a sensible bug supervisor (like most supervisors actually are) would have done it:
- ask for details (mark bug "new", "incomplete" or "triaged") ; are there actually two signatures on the partition? how did that happen?
- add "cryptsetup" to the bug so they can think about erasing some known signatures (esp. swap) when initalizing a LUKS partition
- mark the bug as "confirmed" because not reporting any UUID in this case is just nonsense.
- eventually report the problem upstream (or ask the reporter do do so), and wait for upstream reaction before taking a decision (implement upstream fix, won't fix, patch in distro).

Think about it. And please improve your own way of dealing with bugs. Thanks.