Bug#910493: [Pkg-privacy-maintainers] Bug#910493: Handle transition from MAT to MAT2
jvoisin:
>> On 19-02-12 14:39:32, Georg Faerber wrote:
>>> That is: option one of the second proposal ("quickly patch together a
>>> Python 2 Nautilus extension that wraps mat2's CLI").
>>
>> Unfortunately, and sorry again for my delay working on this, there was
>> no feedback. I've poked Jonas today on IRC privately, asking if he had a
>> comment, he said "sounds good, go ahead", and so I did.
> Ouch, this is unexpected and sounds like a hack, but I guess this is the
> only way to get a useable Mat2 into Buster before the hard freeze.
>
> I took a look at your patch, and improved it a bit. Improved as in tried
> to reduce the number of modifications, and made it more Pythonic.
>
> I'm not super-duper-confident that this approach won't result in some
> weird issues, but again, I guess it's better than nothing.
>
> Thank you for taking the time to write this patch and taking care of
> mat2 in Debian ♥
Thanks a ton for working on this, Georg and Julien! Thanks to you,
there's still hope to have a working mat2 nautilus extension in Buster.
I skimmed through the patch and it looks good to me. I also did some
rough testing and at least with my test files it worked as expected.
I merged jvoisin's changes into the d/0.7.0-2 branch.
So from my side, 0.7.0-2 is ready to be uploaded.
Cheers
jonas
signature.asc
Description: OpenPGP digital signature
Bug#910493: [Pkg-privacy-maintainers] Bug#910493: Handle transition from MAT to MAT2
> On 19-02-12 14:39:32, Georg Faerber wrote:
>> That is: option one of the second proposal ("quickly patch together a
>> Python 2 Nautilus extension that wraps mat2's CLI").
>
> Unfortunately, and sorry again for my delay working on this, there was
> no feedback. I've poked Jonas today on IRC privately, asking if he had a
> comment, he said "sounds good, go ahead", and so I did.
Ouch, this is unexpected and sounds like a hack, but I guess this is the
only way to get a useable Mat2 into Buster before the hard freeze.
I took a look at your patch, and improved it a bit. Improved as in tried
to reduce the number of modifications, and made it more Pythonic.
I'm not super-duper-confident that this approach won't result in some
weird issues, but again, I guess it's better than nothing.
Thank you for taking the time to write this patch and taking care of
mat2 in Debian ♥
--- a/nautilus/mat2.py
+++ b/nautilus/mat2.py
@@ -1,5 +1,5 @@
-#!/usr/bin/env python3
-
+#!/usr/bin/env python
+# -*- coding: utf-8 -*-
"""
Because writing GUI is non-trivial (cf. https://0xacab.org/jvoisin/mat2/issues/3),
we decided to write a Nautilus extensions instead
@@ -12,34 +12,39 @@
# pylint: disable=no-name-in-module,unused-argument,no-self-use,import-error
-import queue
+import Queue as queue
import threading
-from typing import Tuple, Optional, List
-from urllib.parse import unquote
+from urlparse import unquote
import gi
gi.require_version('Nautilus', '3.0')
gi.require_version('Gtk', '3.0')
gi.require_version('GdkPixbuf', '2.0')
from gi.repository import Nautilus, GObject, Gtk, Gio, GLib, GdkPixbuf
+import subprocess
+import mimetypes
-from libmat2 import parser_factory
+def _remove_metadata(fpath):
+""" This is a simple wrapper around the mat2 cli. """
+try:
+return subprocess.check_output(['mat2', fpath])
+except subprocess.CalledProcessError, e:
+return e.output
+
+
+def _guess_mtype(fpath):
+""" Function to guess the mtype of a given file. """
+mtype, _ = mimetypes.guess_type(fpath)
+return mtype
-def _remove_metadata(fpath) -> Tuple[bool, Optional[str]]:
-""" This is a simple wrapper around libmat2, because it's
-easier and cleaner this way.
-"""
-parser, mtype = parser_factory.get_parser(fpath)
-if parser is None:
-return False, mtype
-return parser.remove_all(), mtype
class Mat2Extension(GObject.GObject, Nautilus.MenuProvider, Nautilus.LocationWidgetProvider):
""" This class adds an item to the right-clic menu in Nautilus. """
def __init__(self):
-super().__init__()
+super(Mat2Extension, self).__init__()
self.infobar_hbox = None
self.infobar = None
self.failed_items = list()
@@ -61,7 +66,7 @@
self.infobar.get_content_area().pack_start(self.infobar_hbox, True, True, 0)
self.infobar.show_all()
-def get_widget(self, uri, window) -> Gtk.Widget:
+def get_widget(self, uri, window):
""" This is the method that we have to implement (because we're
a LocationWidgetProvider) in order to show our infobar.
"""
@@ -103,7 +108,7 @@
window.show_all()
@staticmethod
-def __validate(fileinfo) -> Tuple[bool, str]:
+def __validate(fileinfo):
""" Validate if a given file FileInfo `fileinfo` can be processed.
Returns a boolean, and a textreason why"""
if fileinfo.get_uri_scheme() != "file" or fileinfo.is_directory():
@@ -112,7 +117,7 @@
return False, "Not writeable"
return True, ""
-def __create_treeview(self) -> Gtk.TreeView:
+def __create_treeview(self):
liststore = Gtk.ListStore(GdkPixbuf.Pixbuf, str, str)
treeview = Gtk.TreeView(model=liststore)
@@ -144,7 +149,7 @@
treeview.show_all()
return treeview
-def __create_progressbar(self) -> Gtk.ProgressBar:
+def __create_progressbar(self):
""" Create the progressbar used to notify that files are currently
being processed.
"""
@@ -161,11 +166,11 @@
return progressbar
-def __update_progressbar(self, processing_queue, progressbar) -> bool:
+def __update_progressbar(self, processing_queue, progressbar):
""" This method is run via `Glib.add_idle` to update the progressbar."""
try:
fname = processing_queue.get(block=False)
except queue.Empty:
return True
# `None` is the marker put in the queue to signal that every selected
@@ -186,7 +191,7 @@
self.infobar.show_all()
return True
-def __clean_files(self, files: list, processing_queue: queue.Queue) -> bool:
+def __clean_files(self, files, processing_queue):
""" This method is threaded in order to avoid blocking the GUI
while cleaning up the files.
"""
@@ -200,8 +205,9 @@
continue
fpath = unquote(fileinfo.get_uri()[7:]) # `len('file://') = 7`
-
Bug#910493: [Pkg-privacy-maintainers] Bug#910493: Handle transition from MAT to MAT2
Hi all,
(Cc:ing all the people who took part in this issue, and also Julien as
the upstream author.)
On 19-02-12 14:39:32, Georg Faerber wrote:
> That is: option one of the second proposal ("quickly patch together a
> Python 2 Nautilus extension that wraps mat2's CLI").
Unfortunately, and sorry again for my delay working on this, there was
no feedback. I've poked Jonas today on IRC privately, asking if he had a
comment, he said "sounds good, go ahead", and so I did.
Initially, I wanted to do what I wrote above, but in the end I just
patched the current Nautilus extension to make it work with
python-nautilus build against Python 2.7, as it will be shipped in
Debian buster.
The changes I needed to make weren't that intrusive:
- I've changed the interpreter and added "coding: utf-8" to overcome
utf-8 errors.
- Changed some imports to make these work with Python 2.7.
- Removed type hints. (Were this backported to 2.7?)
- Removed internal calls to libmat2, replaced by two funtions to call
the cli of mat2 (and to check the output) and to guess the mtype of a
given file.
- Furthermore, I've removed line 5 in the following code
class Mat2Extension(GObject.GObject, Nautilus.MenuProvider,
Nautilus.LocationWidgetProvider):
""" This class adds an item to the right-clic menu in Nautilus. """
def __init__(self):
super().__init__() <-
self.infobar_hbox = None
self.infobar = None
self.failed_items = list()
as otherwise I was running into
TypeError: super() takes at least 1 argument (0 given)
and I was unsure what's the cause and how to fix this.
I've tested the changes quickly with some files of different types, it
seems to be working.
I would be very happy if someone of you could review this.
I've prepared 0.7.0-2 and pushed to the branch d/0.7.0-2. The repo is
available via [1].
To ease consumption and testing, I've attached the .deb to this mail as
well, it's signed by my key. If you take this route, please note: AFAIK,
dpkg -i doesn't install recommend packages, so please install
python-nautilus manually.
Thanks in advance,
cheers,
Georg
[1] https://salsa.debian.org/pkg-privacy-team/mat2/
mat2_0.7.0-2_all.deb
Description: application/vnd.debian.binary-package
signature.asc
Description: Digital signature
Bug#910493: [Pkg-privacy-maintainers] Bug#910493: Handle transition from MAT to MAT2
Hi, On 19-01-27 22:44:24, intrigeri wrote: > To me this boils down to this question: do we feel more comfortable > with: > > a) including mat v1 in Buster (so less technical can use its GUI, > even though its Nautilus extension was broken last time I tried), > in addition to v2 > > or > > b) only including mat v2, without any GUI at all (and then add > Breaks+Replace, get mat v1 removed from testing, and add > transitional package if there's enough time to go through NEW). > > ? > > I'm personally very uncomfortable with both options :/ > But I'm leaning towards not including software when its author > says it's unsupported and has known (security relevant) issues. > > Thoughts? Both options don't sound good, but I think shipping unsupported software with known, security relevant, issues is pretty bad. I would vote to remove mat v1 and ... > Other data points & ideas: > > - Given the python-nautilus issue essentially requires a transition, >I doubt we'll find some way to provide desktop integration for mat2 >via buster-backports. > > - One could quickly patch together a Python 2 Nautilus extension that >wraps mat2's CLI, or the simplest possible Python 3 GUI that does >not depend on python-nautilus. I'm sure lots of users would be >thankful if someone did this. There's very little time left to get >this done and through NEW. But it could be an option for >buster-backports. ... I would somehow continue what I said and try to tackle option one. Also, if I'm not mistaken, adding such an extension wouldn't need to go trough NEW, and IMHO, it is quite easy to justify adding this even now within the soft freeze: The change isn't that intrusive, we could test beforehand, and it clearly targets an "isolated" issue. Any thoughts? Cheers, Georg signature.asc Description: Digital signature
Bug#910493: [Pkg-privacy-maintainers] Bug#910493: Handle transition from MAT to MAT2
Hi, On 19-01-31 14:46:55, Georg Faerber wrote: > I'll tacke this, although I might need support and of course, at least > one review. Unfortunately, this didn't worked out, as my whole time got consumed by Schleuder. :( Sorry for this. Cheers, Georg signature.asc Description: Digital signature
Bug#910493: [Pkg-privacy-maintainers] Bug#910493: Handle transition from MAT to MAT2
Hi intrigeri, thanks for picking up the discussion about mat/mat2 in Buster! intrigeri: > Daniel Kahn Gillmor: >> On Sun 2018-10-07 10:31:13 +0200, intrigeri wrote: >>> intrigeri: What matters to me is the users' perspective. I think we should provide a clear, unambiguous transition path and avoid leaking technical details to users. So once MAT2 reaches feature parity with MAT (I think the only real blocker is the lack of a Nautilus extension; MAT v1's seems to be broken on sid currently but it has a GUI which mitigates that problem) I think we should: >>> - Have mat2 conflicts+replaces mat, remove mat from testing+sid, and ship a transitional package called mat that pulls mat2 in. >>> >>> IMO we should do that as soon as mat2 installs the Nautilus extension >>> (#910491). >>> >>> Does this make sense to you? Is there a better way to handle this? > >> this all looks reasonable to me as well. > > As Jonas reported on #910491, it's unlikely that mat2's Nautilus > extension is in Buster. Ouch! There's still a chance to get it in: if we craft a patch for nautilus-python that introduces a new package python3-nautilus which is co-installable (and doesn't conflict) with python-nautilus, then the nautilus-python maintainer already said that he would consider to accept it in time for Buster. [1] That basically means that we have to copy libpython-nautilus.c to libpython3-nautilus.c, introduce a new extension include path for it (probably /usr/share/python3-nautilus/extensions/) and patch the build system to build libpython-nautilus.c only for python2 and libpython3-nautilus.c only for python3. Unfortunately I'm unsure whether I find time to work on such a patch within the next week (which probably would be necessary to get the package into the archive in time, since it has to pass NEW). If anybody wants to pick up the work, here's my related PR (which doesn't do what I explained above yet, but should be a starting point): https://salsa.debian.org/gnome-team/nautilus-python/merge_requests/1 In mat2, all we would have to do is install the nautilus extension to the special include path (/usr/share/python3-nautilus/extensions/) instead of the default one. [1] In any case, this would be an intermediate solution for Buster. After buster, the Gnome team plans to start the proper transition from python-nautilus to python3-nautilus, effectively making all packages that don't work with python3-nautilus release-critical. > So it's time to think about contingency > plans here. > > To me this boils down to this question: do we feel more comfortable > with: > > a) including mat v1 in Buster (so less technical can use its GUI, > even though its Nautilus extension was broken last time I tried), > in addition to v2 > > or > > b) only including mat v2, without any GUI at all (and then add > Breaks+Replace, get mat v1 removed from testing, and add > transitional package if there's enough time to go through NEW). > > ? > > I'm personally very uncomfortable with both options :/ > But I'm leaning towards not including software when its author > says it's unsupported and has known (security relevant) issues. I totally agree here. I think that we should file a RM bugreport for mat v1 *now* and introduce a transitional package in mat2 regardless whether we get the nautilus extension for mat2 working in time for Buster. > Other data points & ideas: > > - Given the python-nautilus issue essentially requires a transition, >I doubt we'll find some way to provide desktop integration for mat2 >via buster-backports. See above. > - One could quickly patch together a Python 2 Nautilus extension that >wraps mat2's CLI, or the simplest possible Python 3 GUI that does >not depend on python-nautilus. I'm sure lots of users would be >thankful if someone did this. There's very little time left to get >this done and through NEW. But it could be an option for >buster-backports. I think the better solution would be to get a working python3-nautilus into Buster, which *is* possible. signature.asc Description: OpenPGP digital signature
Bug#910493: [Pkg-privacy-maintainers] Bug#910493: Handle transition from MAT to MAT2
On Sun 2018-10-07 10:31:13 +0200, intrigeri wrote: > intrigeri: >> What matters to me is the users' perspective. I think we should >> provide a clear, unambiguous transition path and avoid leaking >> technical details to users. So once MAT2 reaches feature parity with >> MAT (I think the only real blocker is the lack of a Nautilus >> extension; MAT v1's seems to be broken on sid currently but it has >> a GUI which mitigates that problem) I think we should: > >> - Have mat2 conflicts+replaces mat, remove mat from testing+sid, >>and ship a transitional package called mat that pulls mat2 in. > > IMO we should do that as soon as mat2 installs the Nautilus extension > (#910491). > > Does this make sense to you? Is there a better way to handle this? this all looks reasonable to me as well. thanks for staying on top of it. --dkg
