Merge ~kissiel/checkbox-support:fix-1625926-pactl-db-missing into checkbox-support:master

Proposed by Maciej Kisielewski
Status: Merged
Approved by: Sylvain Pineau
Approved revision: b57d46623217e4b803dce680e78688a251b754e9
Merged at revision: bb54e6df53f117e27035fc0d9a95c11d2c803066
Proposed branch: ~kissiel/checkbox-support:fix-1625926-pactl-db-missing
Merge into: checkbox-support:master
Diff against target: 15 lines (+2/-2)
1 file modified
checkbox_support/parsers/pactl.py (+2/-2)
Reviewer Review Type Date Requested Status
Paul Larson Approve
Maciej Kisielewski Needs Resubmitting
Review via email: mp+325481@code.launchpad.net

Description of the change

Fix jobs observing pactl output on systems that do not report volume in decibels.

TESTING:
On most systems nothing should change, so to verify that I used .*plug-detection jobs from plainbox-provider-checkbox with checkbox-support from venv.
`checkbox-cli run .*plug-detection`
To verify if the patch fixes this problem I used this somerville’s pactl_list_sinks.log [1] to mock the subprocess’s output in pulse-active-port-change bin of p-p-c (:71).

[1] https://bugs.launchpad.net/plainbox-provider-checkbox/+bug/1625926/+attachment/4764731/+files/pactl_list_sinks.log

To post a comment you must log in.
Revision history for this message
Maciej Kisielewski (kissiel) wrote :

Oh, and should you be comparing the raw pyparsing output, keep in mind that value returned contains dicts, which can, and probably will differ in ordering, making the diff report irregularities.

Revision history for this message
Paul Larson (pwlars) wrote :

A couple of questions. I haven't looked exactly where/how this gets used yet, but I did a dumb test of the regex against your example and the groups returned look something like this:
('front-right: 31008 / 47% / -19.50 dB', ' / -19.50 dB', '19.50')
I'm not sure that second group would be very useful.

My first thought on looking at this though, made me wonder - "how much are we doing with pactl list sinks output that we need an entire parser for that!?"

It's perhaps outside the scope of this patch, and perhaps we really do need a parser for it, but if they don't keep the output consistent enough, then debugging and fixing stuff like this gets harder to trace.

review: Needs Information
Revision history for this message
Maciej Kisielewski (kissiel) wrote :

> how much are we doing with pactl list sinks output that we need an entire parser for that!?

Apparently not much, as the patch I proposed here messed up grouping (the optional group was not non-capturing) and it still worked.

I would like to propose "The Three Strikes" rule for those quite-complex-but-probably-not-needed solutions.

Oh, and BTW. I just amended the fix with making the group non-capturing.

review: Needs Resubmitting
Revision history for this message
Paul Larson (pwlars) wrote :

That looks better to me when I test with re.search in an interpreter at least. lgtm, +1

review: Approve

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1diff --git a/checkbox_support/parsers/pactl.py b/checkbox_support/parsers/pactl.py
2index 4459100..c4193f6 100644
3--- a/checkbox_support/parsers/pactl.py
4+++ b/checkbox_support/parsers/pactl.py
5@@ -367,8 +367,8 @@ VolumeAttributeValue = (
6 ]),
7 p.Or([
8 p.Literal("(invalid)"),
9- p.Regex("([\w\-]+: [0-9]+ / +[0-9]+% /"
10- " +-?([0-9]+\.[0-9]+|inf) dB,? *)+")
11+ p.Regex("([\w\-]+: [0-9]+ / +[0-9]+%(?: /"
12+ " +-?([0-9]+\.[0-9]+|inf) dB)?,? *)+")
13 ])
14 ])
15 + p.LineEnd()

Subscribers

People subscribed via source and target branches