Re: [directory-discuss] guix tags that could be automatically extracted

Re: [directory-discuss] guix tags that could be automatically extracted

[Tobias Geerinckx-Rice]

[-- Attachment #1.1: Type: text/plain, Size: 2925 bytes --]

Quiliro,

[Not-cross-posting this to guix-devel.]

On 16/07/17 03:35, Quiliro Ordonez Baca wrote:
> Using:
> 'guix package --show=emacs'
> for example, it is possible to get a lot of information from a
> package. It could be used to include in the Directory. Or it could be
> the other way around: guix could extract information from the Directory
> in order to define packages.

This might make an interesting option to ‘guix import’, if only to give
packagers something to start with. I'm not sure if it would result in
enough useful hits to make it worthwhile. On the other hand, there's
only one way to find out.

I'll paste what I wrote in #guix, though:

  “I wonder what the copyright situation would be for that. If the
   descriptions are copyrightable, the individual contributors retain
   their copyright. On the other hand, the vast majority of
   descriptions are straight from the home page, Wikipedia, or both.”

I'm not a lawyer nor do I play one on TV, but assume this would apply in
both directions.

> Although it would be easier the former way.

From my limited experience with MediaWiki, I'd bet the opposite. I know
there's a machine-readable dump of the Directory database somewhere,
that's updated at least semi-regularly. I don't know if it's
comprehensive. The directory-discuss archives might.

Kind regards,

T G-R

> The output of the above command is:
> name: emacs
> version: 25.2
> outputs: out
> systems: x86_64-linux i686-linux armhf-linux aarch64-linux mips64el-linux
> dependencies: acl-2.2.52 alsa-lib-1.1.3 dbus-1.10.18 giflib-5.1.4
> + gnutls-3.5.9 gtk+-3.22.15 imagemagick-6.9.8-10 libice-1.0.9 libjpeg-8d
> + libotf-0.9.13 libpng-1.6.28 librsvg-2.40.16 libsm-1.2.2 libtiff-4.0.7
> + libx11-1.6.5 libxft-2.3.2 libxml2-2.9.4 libxpm-3.5.12 m17n-lib-1.7.0
> + ncurses-6.0 pkg-config-0.29.1 texinfo-6.3 zlib-1.2.11
> location: gnu/packages/emacs.scm:102:2
> homepage: https://www.gnu.org/software/emacs/
> license: GPL 3+
> synopsis: The extensible, customizable, self-documenting text editor  
> description: GNU Emacs is an extensible and highly customizable text
> + editor.  It is based on an Emacs Lisp interpreter with extensions for text
> + editing.  Emacs has been extended in essentially all areas of computing,
> + giving rise to a vast array of packages supporting, e.g., email, IRC and
> + XMPP messaging, spreadsheets, remote server editing, and much more.  Emacs
> + includes extensive documentation on all aspects of the system, from basic
> + editing to writing large Lisp programs.  It has full Unicode support for
> + nearly all human languages.
> 
> There are many ways to select each tag and filter by each tag. So it
> could be useful for the Directory.
> 
> I am a newbie with Guix. So I bet some Guix hackers on this list could
> supplement this idea. On the other hand, I learn quickly!


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 504 bytes --]

Re: [directory-discuss] guix tags that could be automatically extracted

[ng0]

[-- Attachment #1: Type: text/plain, Size: 3919 bytes --]

Tobias Geerinckx-Rice transcribed 4.2K bytes:
> Quiliro,
> 
> [Not-cross-posting this to guix-devel.]
> 
> On 16/07/17 03:35, Quiliro Ordonez Baca wrote:
> > Using:
> > 'guix package --show=emacs'
> > for example, it is possible to get a lot of information from a
> > package. It could be used to include in the Directory. Or it could be
> > the other way around: guix could extract information from the Directory
> > in order to define packages.
> 
> This might make an interesting option to ‘guix import’, if only to give
> packagers something to start with. I'm not sure if it would result in
> enough useful hits to make it worthwhile. On the other hand, there's
> only one way to find out.

What I expressed last night:

I don't want any additions to the connections made without the consent
of people using guix.
What exactly does this mean?
Everything should be within Guix. The default should be to *not* call
some mediawiki for more information. If we even have the option to query
this mediawiki and the information doesn't have to be present in guix
like translations, I want it to be optional and you have to opt-in to
(receiving) these (informations).

Please discuss this either on guix-devel or on the other list, but don't
CC me into one of the famous gnu.org cross-posting discussions. Thanks
for your consideration.

> 
> I'll paste what I wrote in #guix, though:
> 
>   “I wonder what the copyright situation would be for that. If the
>    descriptions are copyrightable, the individual contributors retain
>    their copyright. On the other hand, the vast majority of
>    descriptions are straight from the home page, Wikipedia, or both.”
> 
> I'm not a lawyer nor do I play one on TV, but assume this would apply in
> both directions.
> 
> > Although it would be easier the former way.
> 
> From my limited experience with MediaWiki, I'd bet the opposite. I know
> there's a machine-readable dump of the Directory database somewhere,
> that's updated at least semi-regularly. I don't know if it's
> comprehensive. The directory-discuss archives might.
> 
> Kind regards,
> 
> T G-R
> 
> > The output of the above command is:
> > name: emacs
> > version: 25.2
> > outputs: out
> > systems: x86_64-linux i686-linux armhf-linux aarch64-linux mips64el-linux
> > dependencies: acl-2.2.52 alsa-lib-1.1.3 dbus-1.10.18 giflib-5.1.4
> > + gnutls-3.5.9 gtk+-3.22.15 imagemagick-6.9.8-10 libice-1.0.9 libjpeg-8d
> > + libotf-0.9.13 libpng-1.6.28 librsvg-2.40.16 libsm-1.2.2 libtiff-4.0.7
> > + libx11-1.6.5 libxft-2.3.2 libxml2-2.9.4 libxpm-3.5.12 m17n-lib-1.7.0
> > + ncurses-6.0 pkg-config-0.29.1 texinfo-6.3 zlib-1.2.11
> > location: gnu/packages/emacs.scm:102:2
> > homepage: https://www.gnu.org/software/emacs/
> > license: GPL 3+
> > synopsis: The extensible, customizable, self-documenting text editor  
> > description: GNU Emacs is an extensible and highly customizable text
> > + editor.  It is based on an Emacs Lisp interpreter with extensions for text
> > + editing.  Emacs has been extended in essentially all areas of computing,
> > + giving rise to a vast array of packages supporting, e.g., email, IRC and
> > + XMPP messaging, spreadsheets, remote server editing, and much more.  Emacs
> > + includes extensive documentation on all aspects of the system, from basic
> > + editing to writing large Lisp programs.  It has full Unicode support for
> > + nearly all human languages.
> > 
> > There are many ways to select each tag and filter by each tag. So it
> > could be useful for the Directory.
> > 
> > I am a newbie with Guix. So I bet some Guix hackers on this list could
> > supplement this idea. On the other hand, I learn quickly!
> 




-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://n0is.noblogs.org/my-keys
https://www.infotropique.org https://krosos.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [directory-discuss] guix tags that could be automatically extracted

[Tobias Geerinckx-Rice]

[-- Attachment #1.1: Type: text/plain, Size: 1801 bytes --]

ng0,

On 16/07/17 14:07, ng0 wrote:
> What I expressed last night:
> 
> I don't want any additions to the connections made without the 
> consent of people using guix.

The proposal then was using Guix to ‘feed’ the Directory, not the other
way round. We as a project can't prohibit others to export data from
their Guix checkout to their wiki if they'd so desire.

However, individual authors probably have some sort of copyright over
the data in some jurisdiction, which is why I don't see it happening.

> What exactly does this mean? Everything should be within Guix. The 
> default should be to *not* call some mediawiki for more information. 
> If we even have the option to query this mediawiki and the 
> information doesn't have to be present in guix like translations, I 
> want it to be optional and you have to opt-in to (receiving) these 
> (informations).

A sentiment which I support in general, but which makes no sense when
discussing ‘guix import’, whose entire purpose in this life is to query
external sources. What's so different about this one?

(I'm not personally advocating adding *this particular one* — I have
nothing against the project, but do think our descriptions are slightly
better on average. Quiliro's proposal seemed interesting enough to
discuss here: they're obviously eager to contribute, and this would be a
relatively easy importer to write :-)

> Please discuss this either on guix-devel or on the other list, but 
> don't CC me into one of the famous gnu.org cross-posting
> discussions. Thanks for your consideration.

What?

I don't think this proposal will be going anywhere because of licencing
hurdles alone, anyway, so you'll not be disturbed by any more replies
from me.

Kind regards,

T G-R


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 504 bytes --]

Re: [directory-discuss] guix tags that could be automatically extracted

[ng0]

[-- Attachment #1: Type: text/plain, Size: 3860 bytes --]

Tobias Geerinckx-Rice transcribed 3.3K bytes:
> ng0,
> 
> On 16/07/17 14:07, ng0 wrote:
> > What I expressed last night:
> > 
> > I don't want any additions to the connections made without the 
> > consent of people using guix.
> 
> The proposal then was using Guix to ‘feed’ the Directory, not the other
> way round. We as a project can't prohibit others to export data from

Okay, then it's all good for me and I did not understand Quiliro.

> their Guix checkout to their wiki if they'd so desire.
> 
> However, individual authors probably have some sort of copyright over
> the data in some jurisdiction, which is why I don't see it happening.

Yep.

> > What exactly does this mean? Everything should be within Guix. The 
> > default should be to *not* call some mediawiki for more information. 
> > If we even have the option to query this mediawiki and the 
> > information doesn't have to be present in guix like translations, I 
> > want it to be optional and you have to opt-in to (receiving) these 
> > (informations).
> 
> A sentiment which I support in general, but which makes no sense when
> discussing ‘guix import’, whose entire purpose in this life is to query
> external sources. What's so different about this one?

I did not read the full initial post. I responded to what Quiliro wrote in
IRC before I left yesterday night.
As we already established that I did not understand it correctly and now
do, let me explain how I understood the proposal on IRC.
I though the function would be to have some sort of mechanism in guix
package etc which sends a QUERY to the mediawiki of fsf to receive data
like categories (tags).
If this would
happen without the ability to reject this I would have vetoed against
it.
I'm not viewing this from a developer perspective but from users who
want to be in control over the connections. There's more to it, but I'm
not motivated to explain entire scenarios today.

> (I'm not personally advocating adding *this particular one* — I have
> nothing against the project, but do think our descriptions are slightly
> better on average. 

Yes, I think the fsf wiki is not really good. Really really not good.
Maybe mediawiki/wikidata of wikipedia might have better resources.

> Quiliro's proposal seemed interesting enough to
> discuss here: they're obviously eager to contribute, and this would be a
> relatively easy importer to write :-)

Okay, I think I still don't understand it. Why an importer when it
should be the other way around as you explained earlier?
At first I understood Quiliro this way:
FSF MW -> Guix.
After the first part of your email it was this:
Guix -> FSF MW.
And now an importer... for descriptions which are worse than ours?
Help me out here as I really don't know what the point of such an
importer would be, unless I got lost in the explanation.

> 
> > Please discuss this either on guix-devel or on the other list, but 
> > don't CC me into one of the famous gnu.org cross-posting
> > discussions. Thanks for your consideration.
> 
> What?
> 
> I don't think this proposal will be going anywhere because of licencing
> hurdles alone, anyway, so you'll not be disturbed by any more replies
> from me.

This wasn't directed at you specifically, I just want discussion to
happen on one list. gnu.org has the tendency to spread certain
discussions to at least 2 lists "because reasons". Crossposting is
never a good idea, and I just wanted to discourage it for anyone
replying to this, to not take some other list back into the CC.
(I know you just posted this to guix-devel, which is good :))

> Kind regards,
> 
> T G-R
> 




-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://n0is.noblogs.org/my-keys
https://www.infotropique.org https://krosos.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [directory-discuss] guix tags that could be automatically extracted

[Adonay Felipe Nogueira]

As I explained in directory-discuss, in the same thread that started
this one: I'm in favor of:

Guix → FSF MW.

But I don't think the other way around is good, as it might also imply
losing the auto-sufficiency described in the first sections of the GNU
FSDG.

As far as I know, Quiliro's intention was to do the first (Guix → FSF
MW).

-- 
- [[https://libreplanet.org/wiki/User:Adfeno]]
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre, por isso não uso. Iguais a ele prefiro
  GNU Ring, ou Tox. Quer outras formas de contato? Adicione o vCard
  que está no endereço acima aos teus contatos.
- Pretende me enviar arquivos .doc, .ppt, .cdr, ou .mp3? OK, eu
  aceito, mas não repasso. Entrego apenas em formatos favoráveis ao
  /software/ livre. Favor entrar em contato em caso de dúvida.

Re: [directory-discuss] guix tags that could be automatically extracted

[Ludovic Courtès]

Hello,

Adonay Felipe Nogueira <adfeno@openmailbox.org> skribis:

> As I explained in directory-discuss, in the same thread that started
> this one: I'm in favor of:
>
> Guix → FSF MW.
>
> But I don't think the other way around is good, as it might also imply
> losing the auto-sufficiency described in the first sections of the GNU
> FSDG.
>
> As far as I know, Quiliro's intention was to do the first (Guix → FSF
> MW).

That’s something that should be easily done, maybe without even a single
change on the Guix side: the output is in the GNU recutils format, so
perhaps it can be directly entered in the MediaWiki database somehow?

Anyway thanks for looking into this.  I think it’s good to share efforts
among peers!

Ludo’.

Re: [directory-discuss] guix tags that could be automatically extracted

[Adonay Felipe Nogueira]

ng0,

As was mentioned by Tobias, there was a small communication noise:
[[https://lists.gnu.org/archive/html/directory-discuss/2017-07/msg00003.html]].

His original intention with that message was to discuss the potential
"MediaWiki -> GuixSD" importer only in guix-devel. And also the inverse
only in directory-discuss. However, as he said, he failed to make it
clear in the first time.

Re: [directory-discuss] guix tags that could be automatically extracted

[Adonay Felipe Nogueira]

Interesting...

Thanks for the information, I just posted a related note on the related
thread/topic on the directory-discuss list. :)