[15:47] <RoyK> xnox: ping?
[15:49] <xnox> RoyK: hello
[15:49] <xnox> what's up? =)
[16:01] <RoyK> xnox: just wondering about bug 1189567 - I have given enough info to reproduce it with the metadump file (linked to the bug), so I don't see why it's marked incomplete. I also disagree with this being prioritised as "medium" since a supported filesystem really should be repairable
[16:01] <ubot2> Launchpad bug 1189567 in xfsprogs (Ubuntu Quantal) "xfs_repair fails to repair filesystem" [Medium,Incomplete] https://launchpad.net/bugs/1189567
[16:05] <xnox> RoyK: 29MB binary file is hardly a reproducer. How to create corrupted filesystem that xfs fails to repair? The statuses & importance match current information. Please read the Stable Release Updates policy and the Ubuntu Bug Squad documentation.
[16:06] <xnox> RoyK: bug is fixed in Raring & saucy. And it's not clear the scope of machines affected.
[16:07] <xnox> RoyK: case in point - inibiting repairing a filesystem does not cause additional data loss. You can boot raring live-cd and repair the filesystem from the live session.
[16:20] <RoyK> uh... the dump file represents a corrupt filesystem
[16:20] <RoyK> I was under the impression that LTS was meant to be the rock stable one
[16:21] <RoyK> I got the bug confirmed by an xfs developer, as stated in the report
[16:21] <RoyK> so it's there
[16:22] <RoyK> he told me he couldn't help sort out which particular patch it was that fixed it, since his employer (redhat) wouldn't be too happy for him to help out with ubuntu bugs
[16:34] <RoyK> xnox: this is rubbish
[16:36] <xnox> RoyK: i don't deny that it's a real bug affecting precise. but at the same time I do not have time investigating on how to reproduce it (the corruption) and to identify the minimal patches needed to fix it. Please note ubuntu does not automatically upgrade packages to newer point releases for stable systems.
[16:37] <RoyK> well, if an xfs developer tells me it's real, what more should I do?
[16:37] <RoyK> I know this, well, they do, if it's a kernel
[16:37] <RoyK> so that's not completely true
[16:37] <RoyK> then find whoever's responsible for xfs and fix a backkport?
[16:39] <xnox> all packages in ubuntu are managed collectively by ubuntu-developers. If you wish this bug to be fixed in the SRU, to help this happen follow as little or as much from the: https://wiki.ubuntu.com/StableReleaseUpdates page.
[16:39] <xnox> for a full point release into -backports
[16:39] <xnox> you can follow: https://wiki.ubuntu.com/UbuntuBackports
[16:39] <xnox> or find somebody else you will do either of those.
[16:40] <xnox> backport will require testing all reverse-dependenices which includes all partitioning tools.
[16:40] <xnox> just a patch to fix that particular bug will need testing of possible regressions from that patch.
[16:41] <xnox> RoyK: do you or the xfs upstream developer know how to cause a corruption which xfs_repair was failing to fix? is there an upstream test-suite for this bug?
[16:44] <RoyK> I don't know what fixed the corruption - probably silent errors on a disk. I had issues with ext4 too after I changed to a new fs. running zfs now, so it's not a real problem for me anymore, I'm just concerned that such a bug isn't fixed
[16:44] <RoyK> how the corruption happened isn't very relevant either
[16:44] <RoyK> what's relevant is that it can't be repaired with that version of xfsprogs
[16:45] <RoyK> and that's easily reproducable with the metadump
[22:23]  * Noskcaj is away: school