[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#31307] [PATCH] Add MAT, the Metadata Anonymisation Toolkit from Bou
From: |
Chris Marusich |
Subject: |
[bug#31307] [PATCH] Add MAT, the Metadata Anonymisation Toolkit from Boum |
Date: |
Sat, 28 Apr 2018 20:09:52 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) |
Nils Gillmann <address@hidden> writes:
>> In addition, I notice that the license is GPL 2, but it seems the author
>> did not specify whether "any later version" can be used. Therefore, I
>> have listed this as gpl2, instead of gpl2+.
>
> The tails people (iirc it is a tails project, who are hosted on boum.org
> infra)
> are generally okay with questions, I think you should ask about wether
> it's GPL2 or GPL2+.
>
> We could also ask them about the state of MAT, as once upon a time they used
> to
> include it in Tails. No idea if they stil do.
I've sent an email to address@hidden I Cc'd you on it. I wasn't
sure if the people of the address@hidden email list would appreciate
it if I arranged for their replies to automatically be recorded in our
bug tracker, so I opted not to Cc this bug report on the email.
We'll see what they say!
>> +;; TODO: Add inputs for PDF support (e.g., Poppler, python-pdfrw).
>> +;; TODO: Add inputs for GUI support (e.g., gi).
>> +;; TODO: Fix some hard-coded paths. For example, get_datafile_path embeds
>> +;; paths like "/usr/local/share/mat", which we should probably rewrite so
>> that
>> +;; they point to mat's output directory in the store. This specific example
>> +;; causes "mat --list" to fail with an exception.
>
> I'm all for making it less hard for a package to get initially into Guix, but
> shouldn't at least hardcoded paths that make an often used function(?) be
> fixed
> first? On the other hand it is functional as you wrote.
I've fixed this in the latest patch version (see attached)!
While testing, I also discovered that the -b feature of the CLI tool
does not work because of what appears to be a simple bug in MAT. I
suppose I will report that upstream if they get back to me and they're
still maintaining it.
>> +(define-public python2-mat
>> + (package
>> + (name "python2-mat")
>
> Since people will expect this as "MAT" or "mat" and not "python2-mat", and to
> my
> knowledge there is no python3 variant, we should name it just mat.
On this topic, the precedent goes both ways, and I haven't seen any
guidance yet on the email lists or in the manual. For example, see
packages like awscli, python2-s3cmd, jupyter, and python-ansi2html.
I think that if a package provides only an application, it makes sense
to give it a name without the "python" or "python2" prefix. However, if
the package provides a library, or it provides a library in addition to
an application, then I think it's better to refer to it using the
"python" or "python2" prefix, as described in the section titled "Python
Modules" in the Guix manual. I also think this aligns with Guix's trend
towards (usually) keeping libraries in the default "out" output of a
package, rather than putting libraries in a separate "lib" output or a
separate "devel" package.
--
Chris
0001-gnu-Add-python2-mat.patch
Description: Text Data
signature.asc
Description: PGP signature