GNU bug report logs - #31307
[PATCH] Add MAT, the Metadata Anonymisation Toolkit from Boum

Previous Next

Full log

Message #11 received at 31307 <at> debbugs.gnu.org (full text, mbox):

From: Chris Marusich <cmmarusich <at> gmail.com>
To: Nils Gillmann <ng0 <at> n0.is>
Cc: 31307 <at> debbugs.gnu.org
Subject: Re: [bug#31307] [PATCH] Add MAT,
 the Metadata Anonymisation Toolkit from Boum
Date: Sat, 28 Apr 2018 20:09:52 -0700

[Message part 1 (text/plain, inline)]

Nils Gillmann <ng0 <at> n0.is> 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 tails-dev <at> boum.org.  I Cc'd you on it.  I wasn't
sure if the people of the tails-dev <at> boum.org 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 (text/x-patch, attachment)]

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.