[Top][All Lists]

[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 
> 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.


Attachment: 0001-gnu-Add-python2-mat.patch
Description: Text Data

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]