Package: release.debian.org User: release.debian....@packages.debian.org Usertags: unblock Severity: normal
Please unblock package python-btrfs Hi release team, In between the turbulence of the Buster release, I'm going to distract you with my first unblock request ever. This is about the src:python-btrfs package, which provides a python3 library together with a collection of examples that show how to explore an online btrfs filesystem to learn about the internal structure of the filesystem and show a lot of fun information about it. The to-be-unblocked package version, 11-2 is in unstable now and solves two bugs in the category "program needlessly explodes with ugly stack trace, while just using them as advertised". One of them also affects functionality in a related package that uses this library, which is btrfs-heatmap: https://bugs.debian.org/925267 https://bugs.debian.org/925271 Both were reported about a week ago, and were the result of an oversight during regression testing a while earlier. To fix all of it, I had to remove two underscores that were in the wrong place, and increment some number on two other lines of code, so that's pretty trivial and non-invasive. FYI, I'm both upstream author and maintainer of the Debian packages (with mentor for uploads, in Cc). Q: Why do I think it would be better to have 11-2 in Buster over 11-1? (since problem descriptions and patch commit messages are quite technical...) A: Simply put... the end user experience. It's in the interest of the end user to not be greeted by an ugly crash that makes no sense, be frustrated and waste time instead of having fun exploring and learning new things. Especially not if the fixes turn out to be able to be this small. Source debdiff between 11-1 and 11-2 is attached. Thanks a lot, Hans van Kranenburg
diff -Nru python-btrfs-11/debian/changelog python-btrfs-11/debian/changelog --- python-btrfs-11/debian/changelog 2019-02-28 19:42:36.000000000 +0100 +++ python-btrfs-11/debian/changelog 2019-03-22 01:12:12.000000000 +0100 @@ -1,3 +1,11 @@ +python-btrfs (11-2) unstable; urgency=medium + + * d/patches: Fix crash because of stray underscores (Closes: #925267) + * d/patches: space-calculator: quickfix crash when using raid5 + (Closes: #925271) + + -- Hans van Kranenburg <h...@knorrie.org> Fri, 22 Mar 2019 01:12:12 +0100 + python-btrfs (11-1) unstable; urgency=medium * New release v11 diff -Nru python-btrfs-11/debian/patches/ctree-Fix-crash-because-of-stray-underscores.patch python-btrfs-11/debian/patches/ctree-Fix-crash-because-of-stray-underscores.patch --- python-btrfs-11/debian/patches/ctree-Fix-crash-because-of-stray-underscores.patch 1970-01-01 01:00:00.000000000 +0100 +++ python-btrfs-11/debian/patches/ctree-Fix-crash-because-of-stray-underscores.patch 2019-03-22 00:54:21.000000000 +0100 @@ -0,0 +1,51 @@ +From 3bcc064fe9fef7748b371c95e2cdddfe6e30e305 Mon Sep 17 00:00:00 2001 +From: Hans van Kranenburg <h...@knorrie.org> +Date: Fri, 1 Mar 2019 20:04:53 +0100 +Subject: [PATCH] ctree: Fix crash because of stray underscores + +The tree_block_refs and shared_block_refs attributes of the MetaDataItem +class are of type list. This means they have an append function, and not +_append. + +So hitting these lines of code crash a program with "AttributeError: +'list' object has no attribute '_append'" + +This made me find out that both of the filesystems that I use for +regression testing before doing a release were originally created using +Debian Jessie, and they were never converted to enable the +skinny_metadata feature, which introduces the usage of these +MetaDataItem objects. + +Unfortunately this means that working with metadata related information +from the extent tree is pretty much broken for any recently created +filesystem. Also affected is the btrfs-heatmap program, which will crash +while generating pictures on extent level of metadata block groups. + +Andrei Borzenkov reported this bug, and found it by using the +show_metadata_tree_sizes example. + +Fixes: 899fdf4c52 "ctree: hide internal ref item helpers" +Closes: https://github.com/knorrie/python-btrfs/issues/17 +--- + btrfs/ctree.py | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/btrfs/ctree.py b/btrfs/ctree.py +index 30c04e8..6aef8d7 100644 +--- a/btrfs/ctree.py ++++ b/btrfs/ctree.py +@@ -1438,9 +1438,9 @@ class MetaDataItem(ItemData): + inline_ref_type, inline_ref_offset = \ + ExtentItem._extent_inline_ref.unpack_from(data, pos) + if inline_ref_type == TREE_BLOCK_REF_KEY: +- self.tree_block_refs._append(InlineTreeBlockRef(inline_ref_offset)) ++ self.tree_block_refs.append(InlineTreeBlockRef(inline_ref_offset)) + elif inline_ref_type == SHARED_BLOCK_REF_KEY: +- self.shared_block_refs._append(InlineSharedBlockRef(inline_ref_offset)) ++ self.shared_block_refs.append(InlineSharedBlockRef(inline_ref_offset)) + else: + raise Exception("BUG: expected inline TREE_BLOCK_REF or SHARED_BLOCK_REF_KEY " + "in METADATA_ITEM {}, but got inline_ref_type {}" +-- +2.20.1 + diff -Nru python-btrfs-11/debian/patches/series python-btrfs-11/debian/patches/series --- python-btrfs-11/debian/patches/series 1970-01-01 01:00:00.000000000 +0100 +++ python-btrfs-11/debian/patches/series 2019-03-22 01:11:35.000000000 +0100 @@ -0,0 +1,2 @@ +ctree-Fix-crash-because-of-stray-underscores.patch +space-calculator-quickfix-crash-when-using-raid5.patch diff -Nru python-btrfs-11/debian/patches/space-calculator-quickfix-crash-when-using-raid5.patch python-btrfs-11/debian/patches/space-calculator-quickfix-crash-when-using-raid5.patch --- python-btrfs-11/debian/patches/space-calculator-quickfix-crash-when-using-raid5.patch 1970-01-01 01:00:00.000000000 +0100 +++ python-btrfs-11/debian/patches/space-calculator-quickfix-crash-when-using-raid5.patch 2019-03-22 01:11:35.000000000 +0100 @@ -0,0 +1,54 @@ +From c27e4e80aab97eeb786d3c6ee6403074d3ffb147 Mon Sep 17 00:00:00 2001 +From: Hans van Kranenburg <h...@knorrie.org> +Date: Fri, 22 Mar 2019 00:03:20 +0100 +Subject: [PATCH] space-calculator: quickfix crash when using raid5 + +Andrei Borzenkov reported that when using raid5 in the options, the +program crashes: + + File "/home/bor/src/python-btrfs/bin/btrfs/volumes.py", line 192, + in chunk_length_to_dev_extent_length + dev_extent_length = raw_data_bytes // num_data_stripes +ZeroDivisionError: integer division or modulo by zero + +The way this space calculator works is a little bit naughty. By +constructing some fake replacements for the official Chunk, Stripe etc +classes, we fool the usage report module and have it believe it's +looking at an actual filesystem. + +In order to do so, we need to present at least one fake chunk of each +chosen profile (for data, metadata etc) to it, so it can take over from +there and do a simulation filling up the rest of the raw space. + +The FakeChunk had num_stripes = 1 hardcoded, which obviously is fragile. +In the specific case of RAID5, it crashes because the nparity is +subtracted from num_stripes, which makes it 0. + +---- >8 ---- + +Newer python-btrfs code gets a proper fix that's >120 lines of changes +and is more future-proof. However, to just make the functionality work +with minimal changes, we can increase num_stripes a bit so that it will +never hit zero when subtracting nparity. +--- + bin/btrfs-space-calculator | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/bin/btrfs-space-calculator b/bin/btrfs-space-calculator +index cb7f8f6..7586c7d 100755 +--- a/bin/btrfs-space-calculator ++++ b/bin/btrfs-space-calculator +@@ -54,8 +54,8 @@ class FakeChunk(object): + def __init__(self, flags): + self.type = flags + self.length = 1 +- self.stripes = [FakeStripe()] +- self.num_stripes = 1 ++ self.stripes = [FakeStripe()] * 4 ++ self.num_stripes = 4 + + + class FakeFileSystem(object): +-- +2.11.0 +
