Help messages were inconsistent about whether they ended with periods or
not. I chose to remove the periods from those that had them rather than
the other way around because the help messages automatically generated
by argparse do not have periods.
There are a couple related changes made here, with the intention of
making it easier to implement additional features in the future:
- Mutual exclusivity of --build-directory and app is better enforced
both through types and at runtime. The types will let type checkers
ensure that we cannot reach the run function without at least one of
them being valid. At runtime, it no longer allows both to be
specified, which could result in confusion over which takes
precedence.
- Instead of wrapping the entire program in a class, there is now only a
small class that handles validation of the arguments and holding the
data to be passed to run. This provides a better separation of
concerns, with the argument parsing now being a little less tied to
running the debugger.
-m with no argument currently results in coredumpctl_matches having a
value of "", which is exactly the same as if it weren't used at all. As
far as I can tell, allowing this does nothing useful, only making the
usage slightly less clear.
The bare tuple unpack 'executable, = re.findall(...)' raises a cryptic
ValueError if the pattern matches zero or more than one line. Replace it
with an explicit length check and a clear error message.
Also pass count=1 to str.replace() so a /newroot prefix is only stripped
once and /app/ paths are passed through unchanged.
This fixes a bug where the warning about not being a flatpaked
application was being printed for flatpaks. This was due to a
change in bwrap so that the paths no longer start with /newroot.
This fixes a warning pointed out by lgtm.com. I checked that the following
still works:
$ PAGER=more flatpak-bisect -b stable org.gnome.Builder log
Closes: #2894
Approved by: matthiasclasen
This is a debugging tool so there's no need for a strict sandbox. I
want to be able to extract backtraces from gdb using 'set logging on'
and it's not currently possible without using
--extra-flatpak-args="--filesystem=home".
Closes: #2313
Approved by: matthiasclasen
The script was using stdout=subprocess.STDOUT but the Popen
documentation does not mention this as a valid value.
An exception was being thrown when running flatpak-bisect <name> log:
OSError: [Errno 9] Bad file descriptor
The CLI is pretty similare to the `git bisect` one and works as follow:
$ flatpak-bisect org.app.App start # Update application and get the history
$ flatpak-bisect org.app.App bad # Sets current commit as first bad commit
$ flatpak-bisect org.app.App checkout GoodHash # Checkout the first known good commit
$ flatpak-bisect org.app.App good # Sets GoodHash as first good commit
... Here it starts bisection and checkouts a commit on the way, the user should launch the
app to check if the commit is good or bad and run:
$ flatpak-bisect org.app.App good # if commit is good
$ flatpak-bisect org.app.App bad # if commit is bad
flatpak-bisect will tell when the first bad commit is found.
Fixes https://github.com/flatpak/flatpak/issues/530
