unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* How to get the package metadata as structured data?
@ 2016-08-04 18:37 Philippe Ombredanne
  0 siblings, 0 replies; 61+ messages in thread
From: Philippe Ombredanne @ 2016-08-04 18:37 UTC (permalink / raw)
  To: guix-devel

Is there a way to get all the package metadata as pure
data beside the html page [1] or the Guile sources [2]?
Like some JSON of sorts or similar?

That would be somewhat needed to audit the licenses
asserted in the metadata and compare them with actually
detected licenses.

 [1] https://www.gnu.org/software/guix/packages/
 [2] http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/linux.scm

-- 
Cordially
Philippe Ombredanne

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: How to get the package metadata as structured data?
@ 2016-08-04 20:49 David Craven
  2016-08-04 21:08 ` Ludovic Courtès
  0 siblings, 1 reply; 61+ messages in thread
From: David Craven @ 2016-08-04 20:49 UTC (permalink / raw)
  To: guix-devel

Hi Philippe,

Thank you for your interest in guix =)

All package metadata can be accessed easily through scheme. There is
no way to export this data currently, although it probably wouldn't be
too hard to implement.

The approach I was planning on taking is the following:
Take a package, remove all build-phases except unpack, add a phase to
run scancode and add the output json to the store.

This way guix already takes care of fetching and unpacking the package
and caching the result. Unless a build input changes, for example
scancode (an input to the scancode phase) is updated, or a scanned
package is updated, running a tool that I'll call `guix license` for
now will work of the json file that was already generated. This means
that improving the reporting or postprocessing the results doesn't
require rescanning a dependency.

Maybe someone else has other/better ;-) thoughts on this?

Cheers
David

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: How to get the package metadata as structured data?
  2016-08-04 20:49 How to get the package metadata as structured data? David Craven
@ 2016-08-04 21:08 ` Ludovic Courtès
  2016-08-04 22:03   ` Cook, Malcolm
  0 siblings, 1 reply; 61+ messages in thread
From: Ludovic Courtès @ 2016-08-04 21:08 UTC (permalink / raw)
  To: Philippe Ombredanne, David Craven; +Cc: guix-devel

Hi!

David Craven <david@craven.ch> skribis:

> All package metadata can be accessed easily through scheme. There is
> no way to export this data currently, although it probably wouldn't be
> too hard to implement.

One way is:

  guix package -s .

which returns a recutils database¹, which is essentially plain text.

Alternately we could write a snippet to export it as JSON if you prefer.

Ludo’.

¹ https://gnu.org/s/recutils/manual/html_node/The-Rec-Format.html

^ permalink raw reply	[flat|nested] 61+ messages in thread

* RE: How to get the package metadata as structured data?
  2016-08-04 21:08 ` Ludovic Courtès
@ 2016-08-04 22:03   ` Cook, Malcolm
  2016-08-05 10:17     ` David Craven
  0 siblings, 1 reply; 61+ messages in thread
From: Cook, Malcolm @ 2016-08-04 22:03 UTC (permalink / raw)
  To: 'Ludovic Courtès', 'Philippe Ombredanne',
	'David Craven'
  Cc: 'guix-devel'

Hi,

Could the guix project please make available the results of `guix package -s .` that would list all available packages in recutils format for those who do not (yet) have fully functioning guix install?

Thanks?


 > -----Original Message-----
 > From: Guix-devel [mailto:guix-devel-bounces+mec=stowers.org@gnu.org]
 > On Behalf Of Ludovic Courtès
 > Sent: Thursday, August 04, 2016 4:09 PM
 > To: Philippe Ombredanne <pombredanne@nexb.com>; David Craven
 > <david@craven.ch>
 > Cc: guix-devel <guix-devel@gnu.org>
 > Subject: Re: How to get the package metadata as structured data?
 > 
 > Hi!
 > 
 > David Craven <david@craven.ch> skribis:
 > 
 > > All package metadata can be accessed easily through scheme. There is
 > > no way to export this data currently, although it probably wouldn't be
 > > too hard to implement.
 > 
 > One way is:
 > 
 >   guix package -s .
 > 
 > which returns a recutils database¹, which is essentially plain text.
 > 
 > Alternately we could write a snippet to export it as JSON if you prefer.
 > 
 > Ludo’.
 > 
 > ¹ https://gnu.org/s/recutils/manual/html_node/The-Rec-Format.html


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: How to get the package metadata as structured data?
  2016-08-04 22:03   ` Cook, Malcolm
@ 2016-08-05 10:17     ` David Craven
  2016-08-05 11:04       ` David Craven
  0 siblings, 1 reply; 61+ messages in thread
From: David Craven @ 2016-08-05 10:17 UTC (permalink / raw)
  To: Cook, Malcolm; +Cc: guix-devel

This should works, but it's pretty slow...

guix package --list-available | grep -o --regex "^[a-zA-Z0-9-]*" |
xargs -n1 guix package -s 1> guix-metadata.txt

time sh -c "guix package -s guix &> /dev/null"
sh -c "guix package -s guix &> /dev/null"  2.42s user 0.07s system
113% cpu 2.203 total

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: How to get the package metadata as structured data?
  2016-08-05 10:17     ` David Craven
@ 2016-08-05 11:04       ` David Craven
  2016-08-05 12:40         ` Aljosha Papsch
  2016-08-05 14:50         ` Philippe Ombredanne
  0 siblings, 2 replies; 61+ messages in thread
From: David Craven @ 2016-08-05 11:04 UTC (permalink / raw)
  To: Cook, Malcolm; +Cc: guix-devel

I aborted, since I realised that guix package -s doesn't include the
source url and hash, which would be important for a testsuite...

Some interesting measurements:
guix package --list-available | grep -o --regex "^[a-zA-Z0-9-]*" | wc -l
3797

cat guix-metadata.txt | grep --regex "^name: .*$" | wc -l
13949

looks like we have many package variants?

and an example of what guix package -s guix exports

guix package -s guix
name: guix
version: 0.10.0
outputs: out
systems: x86_64-linux i686-linux armhf-linux mips64el-linux
dependencies: bzip2-1.0.6 emacs-magit-popup-2.7.0 emacs-minimal-24.5
geiser-0.8.1
+ gnutls-3.5.2 guile-2.0.11 guile-json-0.5.0 gzip-1.8 libgcrypt-1.7.0
pkg-config-0.29
+ sqlite-3.12.2 zlib-1.2.8
location: gnu/packages/package-management.scm:71:2
homepage: http://www.gnu.org/software/guix
license: GPL 3+
synopsis: Functional package manager for installed software packages
and versions
description: GNU Guix is a functional package manager for the GNU
system, and is also
+ a distribution thereof.  It includes a virtual machine image.
Besides the usual
+ package management features, it also supports transactional upgrades
and roll-backs,
+ per-user profiles, and much more.  It is based on the Nix package manager.

name: guix
version: 0.10.0-1.97c8
outputs: out
systems: x86_64-linux i686-linux armhf-linux mips64el-linux
dependencies: autoconf-wrapper-2.69 automake-1.15 bzip2-1.0.6
emacs-magit-popup-2.7.0
+ emacs-minimal-24.5 geiser-0.8.1 gettext-0.19.8 gnutls-3.5.2 graphviz-2.38.0
+ guile-2.0.11 guile-json-0.5.0 gzip-1.8 help2man-1.47.4 libgcrypt-1.7.0
+ pkg-config-0.29 sqlite-3.12.2 texinfo-6.1 zlib-1.2.8
location: gnu/packages/package-management.scm:216:4
homepage: http://www.gnu.org/software/guix
license: GPL 3+
synopsis: Functional package manager for installed software packages
and versions
description: GNU Guix is a functional package manager for the GNU
system, and is also
+ a distribution thereof.  It includes a virtual machine image.
Besides the usual
+ package management features, it also supports transactional upgrades
and roll-backs,
+ per-user profiles, and much more.  It is based on the Nix package manager.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: How to get the package metadata as structured data?
  2016-08-05 11:04       ` David Craven
@ 2016-08-05 12:40         ` Aljosha Papsch
  2016-08-05 14:50         ` Philippe Ombredanne
  1 sibling, 0 replies; 61+ messages in thread
From: Aljosha Papsch @ 2016-08-05 12:40 UTC (permalink / raw)
  To: David Craven, Cook, Malcolm; +Cc: guix-devel

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

guix package prints its output in rec format. You can use recutils to process the output.

Am 5. August 2016 13:04:49 MESZ, schrieb David Craven <david@craven.ch>:
>I aborted, since I realised that guix package -s doesn't include the
>source url and hash, which would be important for a testsuite...
>
>Some interesting measurements:
>guix package --list-available | grep -o --regex "^[a-zA-Z0-9-]*" | wc
>-l
>3797
>
>cat guix-metadata.txt | grep --regex "^name: .*$" | wc -l
>13949
>
>looks like we have many package variants?
>
>and an example of what guix package -s guix exports
>
>guix package -s guix
>name: guix
>version: 0.10.0
>outputs: out
>systems: x86_64-linux i686-linux armhf-linux mips64el-linux
>dependencies: bzip2-1.0.6 emacs-magit-popup-2.7.0 emacs-minimal-24.5
>geiser-0.8.1
>+ gnutls-3.5.2 guile-2.0.11 guile-json-0.5.0 gzip-1.8 libgcrypt-1.7.0
>pkg-config-0.29
>+ sqlite-3.12.2 zlib-1.2.8
>location: gnu/packages/package-management.scm:71:2
>homepage: http://www.gnu.org/software/guix
>license: GPL 3+
>synopsis: Functional package manager for installed software packages
>and versions
>description: GNU Guix is a functional package manager for the GNU
>system, and is also
>+ a distribution thereof.  It includes a virtual machine image.
>Besides the usual
>+ package management features, it also supports transactional upgrades
>and roll-backs,
>+ per-user profiles, and much more.  It is based on the Nix package
>manager.
>
>name: guix
>version: 0.10.0-1.97c8
>outputs: out
>systems: x86_64-linux i686-linux armhf-linux mips64el-linux
>dependencies: autoconf-wrapper-2.69 automake-1.15 bzip2-1.0.6
>emacs-magit-popup-2.7.0
>+ emacs-minimal-24.5 geiser-0.8.1 gettext-0.19.8 gnutls-3.5.2
>graphviz-2.38.0
>+ guile-2.0.11 guile-json-0.5.0 gzip-1.8 help2man-1.47.4
>libgcrypt-1.7.0
>+ pkg-config-0.29 sqlite-3.12.2 texinfo-6.1 zlib-1.2.8
>location: gnu/packages/package-management.scm:216:4
>homepage: http://www.gnu.org/software/guix
>license: GPL 3+
>synopsis: Functional package manager for installed software packages
>and versions
>description: GNU Guix is a functional package manager for the GNU
>system, and is also
>+ a distribution thereof.  It includes a virtual machine image.
>Besides the usual
>+ package management features, it also supports transactional upgrades
>and roll-backs,
>+ per-user profiles, and much more.  It is based on the Nix package
>manager.

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

[-- Attachment #2: Type: text/html, Size: 3068 bytes --]

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: How to get the package metadata as structured data?
  2016-08-05 11:04       ` David Craven
  2016-08-05 12:40         ` Aljosha Papsch
@ 2016-08-05 14:50         ` Philippe Ombredanne
  2016-08-05 14:58           ` [PATCH] ui: 'package->recutils' serializes the source field David Craven
  2016-08-10 11:46           ` How to get the package metadata as structured data? Ricardo Wurmus
  1 sibling, 2 replies; 61+ messages in thread
From: Philippe Ombredanne @ 2016-08-05 14:50 UTC (permalink / raw)
  To: guix-devel

David Craven <david@craven.ch> wrote:
> I aborted, since I realised that guix package -s doesn't include the
> source url and hash, which would be important for a testsuite...

IMHO, if the rec data is the only way to get to the packages data, the
source url would be rather essential to get in.

-- 
Cordially
Philippe Ombredanne

^ permalink raw reply	[flat|nested] 61+ messages in thread

* [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-05 14:50         ` Philippe Ombredanne
@ 2016-08-05 14:58           ` David Craven
  2016-08-06 12:35             ` Alex Kost
  2016-08-10 11:46           ` How to get the package metadata as structured data? Ricardo Wurmus
  1 sibling, 1 reply; 61+ messages in thread
From: David Craven @ 2016-08-05 14:58 UTC (permalink / raw)
  To: guix-devel; +Cc: David Craven

* guix/ui.scm (package->recutils): Format origin.
---
 guix/ui.scm | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/guix/ui.scm b/guix/ui.scm
index 4d1b65c..e232548 100644
--- a/guix/ui.scm
+++ b/guix/ui.scm
@@ -26,6 +26,7 @@
 (define-module (guix ui)
   #:use-module (guix utils)
   #:use-module (guix store)
+  #:use-module (guix base32)
   #:use-module (guix config)
   #:use-module (guix packages)
   #:use-module (guix profiles)
@@ -33,6 +34,7 @@
   #:use-module (guix combinators)
   #:use-module (guix build-system)
   #:use-module (guix serialization)
+  #:use-module (guix git-download)
   #:use-module ((guix build utils) #:select (mkdir-p))
   #:use-module ((guix licenses) #:select (license? license-name))
   #:use-module ((guix build syscalls) #:select (terminal-columns))
@@ -878,6 +880,22 @@ WIDTH columns."
   ;; Note: Don't i18n field names so that people can post-process it.
   (format port "name: ~a~%" (package-name p))
   (format port "version: ~a~%" (package-version p))
+
+  (let ((uri (origin-uri (package-source p))))
+    (cond
+      ((git-reference? uri)
+        (begin
+          (format port "source-git-url: ~a~%"
+                       (git-reference-url uri))
+          (format port "source-git-commit: ~a~%"
+                       (git-reference-commit uri))
+          (format port "source-git-recursive: ~a~%"
+                       (git-reference-recursive? uri))))
+      (#t
+        (format port "source-uri: ~a~%" uri))))
+
+  (format port "source-hash: ~a~%" (bytevector->base32-string
+                                      (origin-sha256 (package-source p))))
   (format port "outputs: ~a~%" (string-join (package-outputs p)))
   (format port "systems: ~a~%"
           (string-join (package-transitive-supported-systems p)))
-- 
2.9.0

^ permalink raw reply related	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-05 14:58           ` [PATCH] ui: 'package->recutils' serializes the source field David Craven
@ 2016-08-06 12:35             ` Alex Kost
  2016-08-06 12:46               ` David Craven
  2016-08-06 15:00               ` Mathieu Lirzin
  0 siblings, 2 replies; 61+ messages in thread
From: Alex Kost @ 2016-08-06 12:35 UTC (permalink / raw)
  To: David Craven; +Cc: guix-devel

David Craven (2016-08-05 17:58 +0300) wrote:

> * guix/ui.scm (package->recutils): Format origin.
> ---
>  guix/ui.scm | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
>
>
> diff --git a/guix/ui.scm b/guix/ui.scm
> index 4d1b65c..e232548 100644
> --- a/guix/ui.scm
> +++ b/guix/ui.scm
> @@ -26,6 +26,7 @@
>  (define-module (guix ui)
>    #:use-module (guix utils)
>    #:use-module (guix store)
> +  #:use-module (guix base32)
>    #:use-module (guix config)
>    #:use-module (guix packages)
>    #:use-module (guix profiles)
> @@ -33,6 +34,7 @@
>    #:use-module (guix combinators)
>    #:use-module (guix build-system)
>    #:use-module (guix serialization)
> +  #:use-module (guix git-download)
>    #:use-module ((guix build utils) #:select (mkdir-p))
>    #:use-module ((guix licenses) #:select (license? license-name))
>    #:use-module ((guix build syscalls) #:select (terminal-columns))
> @@ -878,6 +880,22 @@ WIDTH columns."
>    ;; Note: Don't i18n field names so that people can post-process it.
>    (format port "name: ~a~%" (package-name p))
>    (format port "version: ~a~%" (package-version p))
> +
> +  (let ((uri (origin-uri (package-source p))))

This will fail for some packages (for example, for 'gcc-toolchain')
because the source value can be #f, and (origin-uri #f) errors.

> +    (cond
> +      ((git-reference? uri)
> +        (begin

'begin' is not needed here.

> +          (format port "source-git-url: ~a~%"
> +                       (git-reference-url uri))
> +          (format port "source-git-commit: ~a~%"
> +                       (git-reference-commit uri))
> +          (format port "source-git-recursive: ~a~%"
> +                       (git-reference-recursive? uri))))
> +      (#t

I think using 'else' here would be more Schemey than '#t'.

> +        (format port "source-uri: ~a~%" uri))))
> +
> +  (format port "source-hash: ~a~%" (bytevector->base32-string
> +                                      (origin-sha256 (package-source p))))
>    (format port "outputs: ~a~%" (string-join (package-outputs p)))
>    (format port "systems: ~a~%"
>            (string-join (package-transitive-supported-systems p)))

After all I would write it like this:

  (let ((source (package-source p)))
    (when (origin? source)
      (let ((uri (origin-uri source)))
        (cond
         ((git-reference? uri)
          (format port "source-git-url: ~a~%"
                  (git-reference-url uri))
          (format port "source-git-commit: ~a~%"
                  (git-reference-commit uri))
          (format port "source-git-recursive: ~a~%"
                  (git-reference-recursive? uri)))
         (else
          (format port "source-uri: ~a~%" uri))))
      (format port "source-hash: ~a~%"
              (bytevector->base32-string (origin-sha256 source)))))

However, I'm not sure whether all these source things are needed to be
in the output, I would wait for other opinions.

(I agree with you though and I would like to add the same info for Emacs
interface :-))

Also note that packages may have multiple sources.  For example, for
'sudo' package, the output will be:

  source-uri: (https://www.sudo.ws/sudo/dist/sudo-1.8.17p1.tar.gz ftp://ftp.sudo.ws/pub/sudo/OLD/sudo-1.8.17p1.tar.gz)

I'm not sure if this is a desired formatting, WDYT?

-- 
Alex

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-06 12:35             ` Alex Kost
@ 2016-08-06 12:46               ` David Craven
  2016-08-06 15:00               ` Mathieu Lirzin
  1 sibling, 0 replies; 61+ messages in thread
From: David Craven @ 2016-08-06 12:46 UTC (permalink / raw)
  To: Alex Kost; +Cc: guix-devel

Hi Alex,

> I'm not sure if this is a desired formatting, WDYT?

No that's not a desired formatting, it should be space separated like
the systems list IMO.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-06 12:35             ` Alex Kost
  2016-08-06 12:46               ` David Craven
@ 2016-08-06 15:00               ` Mathieu Lirzin
  2016-08-07 10:26                 ` David Craven
  1 sibling, 1 reply; 61+ messages in thread
From: Mathieu Lirzin @ 2016-08-06 15:00 UTC (permalink / raw)
  To: Alex Kost; +Cc: guix-devel, David Craven

Alex Kost <alezost@gmail.com> writes:

> David Craven (2016-08-05 17:58 +0300) wrote:
>
>> * guix/ui.scm (package->recutils): Format origin.
>> ---
>>  guix/ui.scm | 18 ++++++++++++++++++
>>  1 file changed, 18 insertions(+)
>>
>>
>> diff --git a/guix/ui.scm b/guix/ui.scm
>> index 4d1b65c..e232548 100644
>> --- a/guix/ui.scm
>> +++ b/guix/ui.scm
>> @@ -26,6 +26,7 @@
>>  (define-module (guix ui)
>>    #:use-module (guix utils)
>>    #:use-module (guix store)
>> +  #:use-module (guix base32)
>>    #:use-module (guix config)
>>    #:use-module (guix packages)
>>    #:use-module (guix profiles)
>> @@ -33,6 +34,7 @@
>>    #:use-module (guix combinators)
>>    #:use-module (guix build-system)
>>    #:use-module (guix serialization)
>> +  #:use-module (guix git-download)
>>    #:use-module ((guix build utils) #:select (mkdir-p))
>>    #:use-module ((guix licenses) #:select (license? license-name))
>>    #:use-module ((guix build syscalls) #:select (terminal-columns))
>> @@ -878,6 +880,22 @@ WIDTH columns."
>>    ;; Note: Don't i18n field names so that people can post-process it.
>>    (format port "name: ~a~%" (package-name p))
>>    (format port "version: ~a~%" (package-version p))
>> +
>> +  (let ((uri (origin-uri (package-source p))))
>
> This will fail for some packages (for example, for 'gcc-toolchain')
> because the source value can be #f, and (origin-uri #f) errors.
>
>> +    (cond
>> +      ((git-reference? uri)
>> +        (begin
>
> 'begin' is not needed here.
>
>> +          (format port "source-git-url: ~a~%"
>> +                       (git-reference-url uri))
>> +          (format port "source-git-commit: ~a~%"
>> +                       (git-reference-commit uri))
>> +          (format port "source-git-recursive: ~a~%"
>> +                       (git-reference-recursive? uri))))
>> +      (#t
>
> I think using 'else' here would be more Schemey than '#t'.
>
>> +        (format port "source-uri: ~a~%" uri))))
>> +
>> +  (format port "source-hash: ~a~%" (bytevector->base32-string
>> +                                      (origin-sha256 (package-source p))))
>>    (format port "outputs: ~a~%" (string-join (package-outputs p)))
>>    (format port "systems: ~a~%"
>>            (string-join (package-transitive-supported-systems p)))
>
> After all I would write it like this:
>
>   (let ((source (package-source p)))
>     (when (origin? source)
>       (let ((uri (origin-uri source)))
>         (cond
>          ((git-reference? uri)
>           (format port "source-git-url: ~a~%"
>                   (git-reference-url uri))
>           (format port "source-git-commit: ~a~%"
>                   (git-reference-commit uri))
>           (format port "source-git-recursive: ~a~%"
>                   (git-reference-recursive? uri)))
>          (else
>           (format port "source-uri: ~a~%" uri))))
>       (format port "source-hash: ~a~%"
>               (bytevector->base32-string (origin-sha256 source)))))
>
> However, I'm not sure whether all these source things are needed to be
> in the output, I would wait for other opinions.
>
> (I agree with you though and I would like to add the same info for Emacs
> interface :-))
>
> Also note that packages may have multiple sources.  For example, for
> 'sudo' package, the output will be:
>
>   source-uri: (https://www.sudo.ws/sudo/dist/sudo-1.8.17p1.tar.gz ftp://ftp.sudo.ws/pub/sudo/OLD/sudo-1.8.17p1.tar.gz)

I don't have an opinion on what should be displayed or not (at least not
yet).  However I think there is an issue with FSDG compliance here, when
upstream includes non-free stuff for the same reason that 'guix build
--source PACKAGE' is required by FSDG to provide a cleaned version of the
tarball.

"source-uris" should point to the same thing that 'guix build -S
PACKAGE' provides however in our current infrastructure this is not
possible.

For the same reason I think Emacs interface should not display the
origin URL of those packages.  I Don't know how to achieve this, maybe
displaying only the URL when there is no snippet part would work even if
it will remove more package source URLs than needed.

WDYT?

-- 
Mathieu Lirzin

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-06 15:00               ` Mathieu Lirzin
@ 2016-08-07 10:26                 ` David Craven
  2016-08-07 11:15                   ` Mathieu Lirzin
  0 siblings, 1 reply; 61+ messages in thread
From: David Craven @ 2016-08-07 10:26 UTC (permalink / raw)
  To: Mathieu Lirzin; +Cc: guix-devel, Alex Kost

If I understand you correctly, you are saying the following:

We shouldn't display an url to a tarball that may contain unfree
software, because a user might run `guix package -s` download the
tarball from the source-uris field and build and run the code, and
accidentally run nonfree software on his computer?

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-07 10:26                 ` David Craven
@ 2016-08-07 11:15                   ` Mathieu Lirzin
  2016-08-07 11:19                     ` David Craven
  0 siblings, 1 reply; 61+ messages in thread
From: Mathieu Lirzin @ 2016-08-07 11:15 UTC (permalink / raw)
  To: David Craven; +Cc: guix-devel, Alex Kost

David Craven <david@craven.ch> writes:

> If I understand you correctly, you are saying the following:
>
> We shouldn't display an url to a tarball that may contain unfree
> software, because a user might run `guix package -s` download the
> tarball from the source-uris field and build and run the code, and
> accidentally run nonfree software on his computer?

No, this is not what I am saying.

'guix build -S' does already provide a patched version of the tarball
without the non-free stuff.  So the user can't install non-free code
accidentally.  IIRC This behavior was introduced to comply with FSDG in
order to make GuixSD a fully free distro.

My point is that if we are giving a direct link to the non-patched
source in our UI, the FSDG issue is the same.

Sorry if I was unclear.

-- 
Mathieu Lirzin

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-07 11:15                   ` Mathieu Lirzin
@ 2016-08-07 11:19                     ` David Craven
  2016-08-07 12:12                       ` David Craven
  2016-08-07 13:27                       ` Mathieu Lirzin
  0 siblings, 2 replies; 61+ messages in thread
From: David Craven @ 2016-08-07 11:19 UTC (permalink / raw)
  To: Mathieu Lirzin; +Cc: guix-devel, Alex Kost

I meant the little -s flag...

-s, --search=REGEXP    search in synopsis and description using REGEXP

and I meant download, build and run manually outside of guix.

It still sounds like that's what you are saying... ;-)

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-07 11:19                     ` David Craven
@ 2016-08-07 12:12                       ` David Craven
  2016-08-07 13:27                       ` Mathieu Lirzin
  1 sibling, 0 replies; 61+ messages in thread
From: David Craven @ 2016-08-07 12:12 UTC (permalink / raw)
  To: Mathieu Lirzin; +Cc: guix-devel, Alex Kost

> My point is that if we are giving a direct link to the non-patched
> source in our UI, the FSDG issue is the same.

Just because I can't understand the concern, doesn't necessarily
mean that it isn't a valid one...

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-07 11:19                     ` David Craven
  2016-08-07 12:12                       ` David Craven
@ 2016-08-07 13:27                       ` Mathieu Lirzin
  2016-08-07 21:33                         ` David Craven
  1 sibling, 1 reply; 61+ messages in thread
From: Mathieu Lirzin @ 2016-08-07 13:27 UTC (permalink / raw)
  To: David Craven; +Cc: guix-devel, Alex Kost

David Craven <david@craven.ch> writes:

> I meant the little -s flag...
>
> -s, --search=REGEXP    search in synopsis and description using REGEXP
>
> and I meant download, build and run manually outside of guix.
>
> It still sounds like that's what you are saying... ;-)

oops my bad.  So your summary of what I was saying was indeed correct.

-- 
Mathieu Lirzin

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-07 13:27                       ` Mathieu Lirzin
@ 2016-08-07 21:33                         ` David Craven
  2016-08-08  0:15                           ` Mathieu Lirzin
  0 siblings, 1 reply; 61+ messages in thread
From: David Craven @ 2016-08-07 21:33 UTC (permalink / raw)
  To: Mathieu Lirzin; +Cc: guix-devel, Alex Kost

Quoting FSDG:
A free system distribution must not steer users towards obtaining any
nonfree information for practical use, or encourage them to do so.

We are not steering or encouraging users to do any thing by displaying
the source url of the tarball, we are merely providing factual
non-opinionated information. But I guess we aren't telling the full
story and should tell the user that we made post download
modifications to the tarball to comply with the free software
distribution guidelines.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-07 21:33                         ` David Craven
@ 2016-08-08  0:15                           ` Mathieu Lirzin
  2016-08-08 11:20                             ` David Craven
  2016-08-11 10:15                             ` Mark H Weaver
  0 siblings, 2 replies; 61+ messages in thread
From: Mathieu Lirzin @ 2016-08-08  0:15 UTC (permalink / raw)
  To: David Craven; +Cc: guix-devel, Alex Kost

David Craven <david@craven.ch> writes:

> Quoting FSDG:
> A free system distribution must not steer users towards obtaining any
> nonfree information for practical use, or encourage them to do so.
>
> We are not steering or encouraging users to do any thing by displaying
> the source url of the tarball, 

That's an interpretation of it.  I think that point deserves a
discussion on <gnu-linux-libre@nongnu.org> mailing list, before
including such change in Guix UI.

For some background on the 'guix build --source' issue, Please read the
full thread on
https://lists.nongnu.org/archive/html/gnu-linux-libre/2013-09/msg00001.html.

>we are merely providing factual non-opinionated information.

IMO, Distributing software is always opinionated.  :)

-- 
Mathieu Lirzin

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-08  0:15                           ` Mathieu Lirzin
@ 2016-08-08 11:20                             ` David Craven
  2016-08-08 17:53                               ` Mathieu Lirzin
  2016-08-11 10:15                             ` Mark H Weaver
  1 sibling, 1 reply; 61+ messages in thread
From: David Craven @ 2016-08-08 11:20 UTC (permalink / raw)
  To: Mathieu Lirzin; +Cc: guix-devel, Alex Kost

Quoting Ludo from the thread you mentioned:

> (Besides, our package meta-data would probably still refer to the “real”
> home page of the package, from which it’s trivial to get the unmodified
> tarball.)

The discussion only applies to 'guix build --source' and I can't see any
indication from reading the thread that displaying the original source url
would be in any way problematic. Can you quote something from that
thread that would indicate otherwise?

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-08 11:20                             ` David Craven
@ 2016-08-08 17:53                               ` Mathieu Lirzin
  2016-08-08 18:12                                 ` David Craven
  2016-08-08 19:07                                 ` Alex Kost
  0 siblings, 2 replies; 61+ messages in thread
From: Mathieu Lirzin @ 2016-08-08 17:53 UTC (permalink / raw)
  To: David Craven; +Cc: guix-devel, Alex Kost

David Craven <david@craven.ch> writes:

> Quoting Ludo from the thread you mentioned:
>
>> (Besides, our package meta-data would probably still refer to the “real”
>> home page of the package, from which it’s trivial to get the unmodified
>> tarball.)
>
> The discussion only applies to 'guix build --source' and I can't see any
> indication from reading the thread that displaying the original source url
> would be in any way problematic. Can you quote something from that
> thread that would indicate otherwise?

I don't need to quote anything to think that:

- Providing a user tool to fetch a tarball
- Displaying a direct link to a tarball in our UI

... have the same "steer users" effect.  

Feel free to disagree, however when doubt emerges about FSDG compliance,
a consensus needs to be reached on <gnu-linux-libre@nongnu.org>.  If you
want your change to be included in Guix, please start a discussion on
that mailing list explaining what you are proposing and ask if other
people thinks this is OK in regards of the FSDG.

-- 
Mathieu Lirzin

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-08 17:53                               ` Mathieu Lirzin
@ 2016-08-08 18:12                                 ` David Craven
  2016-08-08 19:07                                 ` Alex Kost
  1 sibling, 0 replies; 61+ messages in thread
From: David Craven @ 2016-08-08 18:12 UTC (permalink / raw)
  To: Mathieu Lirzin; +Cc: guix-devel, Alex Kost

> Feel free to disagree, however when doubt emerges about FSDG compliance,
> a consensus needs to be reached on <gnu-linux-libre@nongnu.org>.  If you
> want your change to be included in Guix, please start a discussion on
> that mailing list explaining what you are proposing and ask if other
> people thinks this is OK in regards of the FSDG.

I am not going to do that, since I don't have the time to start
pointless discussions
just to be able to say I told you so.

I hope you can appreciate my restraint in this reply.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-08 17:53                               ` Mathieu Lirzin
  2016-08-08 18:12                                 ` David Craven
@ 2016-08-08 19:07                                 ` Alex Kost
  2016-08-08 21:09                                   ` Mathieu Lirzin
  1 sibling, 1 reply; 61+ messages in thread
From: Alex Kost @ 2016-08-08 19:07 UTC (permalink / raw)
  To: Mathieu Lirzin; +Cc: guix-devel, David Craven

Mathieu Lirzin (2016-08-08 20:53 +0300) wrote:

> David Craven <david@craven.ch> writes:
>
>> Quoting Ludo from the thread you mentioned:
>>
>>> (Besides, our package meta-data would probably still refer to the “real”
>>> home page of the package, from which it’s trivial to get the unmodified
>>> tarball.)
>>
>> The discussion only applies to 'guix build --source' and I can't see any
>> indication from reading the thread that displaying the original source url
>> would be in any way problematic. Can you quote something from that
>> thread that would indicate otherwise?
>
> I don't need to quote anything to think that:
>
> - Providing a user tool to fetch a tarball
> - Displaying a direct link to a tarball in our UI

But a user already can look at any package info (including the source
URL) using "guix edit" command, so I don't see a reason why "guix
package --show" can't display the same info.

-- 
Alex

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-08 19:07                                 ` Alex Kost
@ 2016-08-08 21:09                                   ` Mathieu Lirzin
  2016-08-08 22:58                                     ` David Craven
  0 siblings, 1 reply; 61+ messages in thread
From: Mathieu Lirzin @ 2016-08-08 21:09 UTC (permalink / raw)
  To: Alex Kost; +Cc: guix-devel, David Craven

Alex Kost <alezost@gmail.com> writes:

> Mathieu Lirzin (2016-08-08 20:53 +0300) wrote:
>
>> David Craven <david@craven.ch> writes:
>>
>>> Quoting Ludo from the thread you mentioned:
>>>
>>>> (Besides, our package meta-data would probably still refer to the “real”
>>>> home page of the package, from which it’s trivial to get the unmodified
>>>> tarball.)
>>>
>>> The discussion only applies to 'guix build --source' and I can't see any
>>> indication from reading the thread that displaying the original source url
>>> would be in any way problematic. Can you quote something from that
>>> thread that would indicate otherwise?
>>
>> I don't need to quote anything to think that:
>>
>> - Providing a user tool to fetch a tarball
>> - Displaying a direct link to a tarball in our UI
>
> But a user already can look at any package info (including the source
> URL) using "guix edit" command, so I don't see a reason why "guix
> package --show" can't display the same info.

I am just claiming that the two things above are equivalent and that as
a consequence we can't refuse one and accept the other.  I am not
discussing the "why", only applying logic.

-- 
Mathieu Lirzin

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-08 21:09                                   ` Mathieu Lirzin
@ 2016-08-08 22:58                                     ` David Craven
  2016-08-08 23:56                                       ` Mathieu Lirzin
  0 siblings, 1 reply; 61+ messages in thread
From: David Craven @ 2016-08-08 22:58 UTC (permalink / raw)
  To: Mathieu Lirzin, Alex Kost, guix-devel

Hi Mathieu,

Sometimes it's hard to admit when you are wrong, but I think in
practice people barely take notice if you quickly admit you are
wrong and move on. If you drag it out, people are definitively
going to remember.

Claiming that you applied logic to arrive at the conclusion that

- Providing a user tool to fetch a tarball
- Displaying a direct link to a tarball in our UI

are the same thing is nonsense.

Asking me to start a discussion on the linux-libre mailing list over
this is an unreasonable request.

The only way I can see these two things being equal is if you
say:

class Thing
class UserTool extends Thing
class DirectLink extends Thing

typeof UserTool == typeof DirectLink ;-)

I had a class on java - which I didn't attend - and passed
an exam - but I never wrote a single line of java. Pretty
interesting what will pass as a java programmer don't you
think? =P

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-08 22:58                                     ` David Craven
@ 2016-08-08 23:56                                       ` Mathieu Lirzin
  2016-08-09  0:18                                         ` David Craven
  0 siblings, 1 reply; 61+ messages in thread
From: Mathieu Lirzin @ 2016-08-08 23:56 UTC (permalink / raw)
  To: David Craven; +Cc: guix-devel, Alex Kost

David Craven <david@craven.ch> writes:

> Sometimes it's hard to admit when you are wrong, but I think in
> practice people barely take notice if you quickly admit you are
> wrong and move on. If you drag it out, people are definitively
> going to remember.
>
> Claiming that you applied logic to arrive at the conclusion that
>
> - Providing a user tool to fetch a tarball
> - Displaying a direct link to a tarball in our UI
>
> are the same thing is nonsense.

If I disagree with you doesn't mean I am wrong.  Please don't act as if
you were in a position to decide who is wrong.  Trying to persuade me
that it would be better for my reputation to agree with you won't work.

> Asking me to start a discussion on the linux-libre mailing list over
> this is an unreasonable request.

Being careful about FSDG compliance is not unreasonable.

> The only way I can see these two things being equal is if you
> say:
>
> class Thing
> class UserTool extends Thing
> class DirectLink extends Thing
>
> typeof UserTool == typeof DirectLink ;-)
>
> I had a class on java - which I didn't attend - and passed
> an exam - but I never wrote a single line of java. Pretty
> interesting what will pass as a java programmer don't you
> think? =P

Sorry, but I don't understand what you are trying to say.

-- 
Mathieu Lirzin

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-08 23:56                                       ` Mathieu Lirzin
@ 2016-08-09  0:18                                         ` David Craven
  2016-08-10 10:12                                           ` David Craven
  0 siblings, 1 reply; 61+ messages in thread
From: David Craven @ 2016-08-09  0:18 UTC (permalink / raw)
  To: Mathieu Lirzin; +Cc: guix-devel, Alex Kost

> If I disagree with you doesn't mean I am wrong. Please don't act as if
> you were in a position to decide who is wrong.

You voiced your concern, I tried to find common ground.

You referred to the FSDG. I read it to understand.

You told me it was just my opinion of what is says, and referred me
to a mailing list thread. I read the thread and asked how it relates.

You told me you did not have to provide an answer and I had to
go on some mailing list to start a discussion, so that other people
can argue for you.

I haven't heard you provide an argument other that repeating
it's an FSDG issue, it's an FSDG issue.

That sounds to me like someone who's out of ammo but not willing
to admit it.

> Trying to persuade me that it would be better for my reputation to agree with you won't work.

One can try.

> Sorry, but I don't understand what you are trying to say.

Trying to change the subject and end the mail with a smiley. Not that
I'm particularly skilled at it ;-)

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-09  0:18                                         ` David Craven
@ 2016-08-10 10:12                                           ` David Craven
  2016-08-10 11:30                                             ` Mathieu Lirzin
  0 siblings, 1 reply; 61+ messages in thread
From: David Craven @ 2016-08-10 10:12 UTC (permalink / raw)
  To: Mathieu Lirzin; +Cc: guix-devel, Alex Kost

Hi Mathieu,

> No that's not a desired formatting, it should be space separated like
> the systems list IMO.

> But I guess we aren't telling the full
> story and should tell the user that we made post download
> modifications to the tarball to comply with the free software
> distribution guidelines.

Can we move forward on this then if we incorporate Alex's changes and
these suggestions?



I'll provide a few pointers for a stronger argument for the next one
you have (if you don't mind) ;-)

You made the statement that the FSDG wasn't clear enough on the
subject to make a decision and was open for interpretation. Then you
made use of "case law" referring to the guix package -S thread.

You also made the statement:
> I am just claiming that the two things above are equivalent and that as
> a consequence we can't refuse one and accept the other.  I am not
> discussing the "why", only applying logic.

I would have expected you to provide a compelling argument for why
these things are equivalent, since it wasn't obvious to me. Making use
of case law is a valid argument, but you'd have to explain why and how
it applies to cast reasonable doubt that this is a FSDG issue. IMO you
did not do so sufficiently to merit escalating the discussion to a
different mailing list.

David

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-10 10:12                                           ` David Craven
@ 2016-08-10 11:30                                             ` Mathieu Lirzin
  2016-08-10 11:38                                               ` David Craven
  0 siblings, 1 reply; 61+ messages in thread
From: Mathieu Lirzin @ 2016-08-10 11:30 UTC (permalink / raw)
  To: David Craven; +Cc: guix-devel, Alex Kost

David Craven <david@craven.ch> writes:

> Hi Mathieu,
>
>> No that's not a desired formatting, it should be space separated like
>> the systems list IMO.
>
>> But I guess we aren't telling the full
>> story and should tell the user that we made post download
>> modifications to the tarball to comply with the free software
>> distribution guidelines.
>
> Can we move forward on this then if we incorporate Alex's changes and
> these suggestions?
>
> I'll provide a few pointers for a stronger argument for the next one
> you have (if you don't mind) ;-)
>
> You made the statement that the FSDG wasn't clear enough on the
> subject to make a decision and was open for interpretation. Then you
> made use of "case law" referring to the guix package -S thread.
>
> You also made the statement:
>> I am just claiming that the two things above are equivalent and that as
>> a consequence we can't refuse one and accept the other.  I am not
>> discussing the "why", only applying logic.
>
> I would have expected you to provide a compelling argument for why
> these things are equivalent, since it wasn't obvious to me. Making use
> of case law is a valid argument, but you'd have to explain why and how
> it applies to cast reasonable doubt that this is a FSDG issue. IMO you
> did not do so sufficiently to merit escalating the discussion to a
> different mailing list.

When someone wants to introduce some change, it is up to him to convince
others to accept this change, not the other way.

This discussion is already escalating in a way where you are waisting
your energy (and mine too), Guix-devel is not the relevant place for
talking about FSDG compliance.  I have already explain my reasons and I
will not repeat myself.  If you don't want to take the time to discuss
this on the relevant mailing list, then nothing will move unless you
convince the Guix maintainers that my doubt are not legitimate.

-- 
Mathieu Lirzin

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-10 11:30                                             ` Mathieu Lirzin
@ 2016-08-10 11:38                                               ` David Craven
  2016-08-10 11:46                                                 ` David Craven
  2016-08-10 12:06                                                 ` Mathieu Lirzin
  0 siblings, 2 replies; 61+ messages in thread
From: David Craven @ 2016-08-10 11:38 UTC (permalink / raw)
  To: Mathieu Lirzin; +Cc: guix-devel, Alex Kost

> unless you convince the Guix maintainers that my doubt are not legitimate

I'm sorry but I haven't heard anyone except you express doubt. I made
several arguments to which you did not respond. Who else except you do
you think I have to convince? You made no effort on your part as I
explained in the previous mail. I don't know what exactly why you are
against this change, but I'm doubting that it has anything to do with
FSDG compliance.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: How to get the package metadata as structured data?
  2016-08-05 14:50         ` Philippe Ombredanne
  2016-08-05 14:58           ` [PATCH] ui: 'package->recutils' serializes the source field David Craven
@ 2016-08-10 11:46           ` Ricardo Wurmus
  2016-08-10 12:14             ` Catonano
  1 sibling, 1 reply; 61+ messages in thread
From: Ricardo Wurmus @ 2016-08-10 11:46 UTC (permalink / raw)
  To: Philippe Ombredanne; +Cc: guix-devel


Philippe Ombredanne <pombredanne@nexb.com> writes:

> David Craven <david@craven.ch> wrote:
>> I aborted, since I realised that guix package -s doesn't include the
>> source url and hash, which would be important for a testsuite...
>
> IMHO, if the rec data is the only way to get to the packages data, the
> source url would be rather essential to get in.

The recutils output is not the *only* way to access the package data.
All packages in Guix are just Scheme variables.  Package data are
available as S-expressions and can be read by Scheme programs or parsed
by external applications.  The recutils output is just an additional
format used when interacting with Guix on the command line.

(Personally, I’m not enthusiastic about adding a serialised form of the
source field to the recutils output.)

~~ Ricardo

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-10 11:38                                               ` David Craven
@ 2016-08-10 11:46                                                 ` David Craven
  2016-08-10 12:06                                                 ` Mathieu Lirzin
  1 sibling, 0 replies; 61+ messages in thread
From: David Craven @ 2016-08-10 11:46 UTC (permalink / raw)
  To: Mathieu Lirzin; +Cc: guix-devel, Alex Kost

Either you don't have a case or you are incapable of making one.
Either way don't be a sore looser.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-10 11:38                                               ` David Craven
  2016-08-10 11:46                                                 ` David Craven
@ 2016-08-10 12:06                                                 ` Mathieu Lirzin
  2016-08-10 12:15                                                   ` Ben Woodcroft
  1 sibling, 1 reply; 61+ messages in thread
From: Mathieu Lirzin @ 2016-08-10 12:06 UTC (permalink / raw)
  To: David Craven; +Cc: guix-devel, Alex Kost

David Craven <david@craven.ch> writes:

>> unless you convince the Guix maintainers that my doubt are not legitimate
>
> I'm sorry but I haven't heard anyone except you express doubt. I made
> several arguments to which you did not respond. Who else except you do
> you think I have to convince? 

I have already express my point.  Please address your arguments to
<gnu-linux-libre@nongnu.org> not to me.

> You made no effort on your part as I explained in the previous mail. I
> don't know what exactly why you are against this change, but I'm
> doubting that it has anything to do with FSDG compliance.

This is your version of the story.  I have tried to explain to you how
the change you have proposed is likely to be related to the "guix build
--source" FSDG issue.  Claiming that I have not made any effort because
you are not convinced is unfair.

-- 
Mathieu Lirzin

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: How to get the package metadata as structured data?
  2016-08-10 11:46           ` How to get the package metadata as structured data? Ricardo Wurmus
@ 2016-08-10 12:14             ` Catonano
  2016-08-10 12:52               ` Ricardo Wurmus
  0 siblings, 1 reply; 61+ messages in thread
From: Catonano @ 2016-08-10 12:14 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: guix-devel

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

2016-08-10 13:46 GMT+02:00 Ricardo Wurmus <rekado@elephly.net>:

>
> Philippe Ombredanne <pombredanne@nexb.com> writes:
>
> > David Craven <david@craven.ch> wrote:
> >> I aborted, since I realised that guix package -s doesn't include the
> >> source url and hash, which would be important for a testsuite...
> >
> > IMHO, if the rec data is the only way to get to the packages data, the
> > source url would be rather essential to get in.
>
> The recutils output is not the *only* way to access the package data.
> All packages in Guix are just Scheme variables.  Package data are
> available as S-expressions and can be read by Scheme programs or parsed
> by external applications.  The recutils output is just an additional
> format used when interacting with Guix on the command line.
>
> (Personally, I’m not enthusiastic about adding a serialised form of the
> source field to the recutils output.)
>
> ~~ Ricardo
>
>
>
Not so long ago, someone posted a script that produced a web page with the
results of linting all the packages

That's an example

One could produce an xml file to be imported in Gephi, just to make another
example.

Or a SQL text file to be imported in some relational db, or a different
format to be imported in some not relational db...

[-- Attachment #2: Type: text/html, Size: 1978 bytes --]

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-10 12:06                                                 ` Mathieu Lirzin
@ 2016-08-10 12:15                                                   ` Ben Woodcroft
  2016-08-10 12:27                                                     ` David Craven
  2016-08-10 17:56                                                     ` Leo Famulari
  0 siblings, 2 replies; 61+ messages in thread
From: Ben Woodcroft @ 2016-08-10 12:15 UTC (permalink / raw)
  To: Mathieu Lirzin, David Craven; +Cc: guix-devel, Alex Kost

Hi,


On 10/08/16 22:06, Mathieu Lirzin wrote:
> David Craven <david@craven.ch> writes:

I don't have anything to to contribute beyond psuedo-quoting Ludo: let's 
not lose our hair over this!

ben

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-10 12:15                                                   ` Ben Woodcroft
@ 2016-08-10 12:27                                                     ` David Craven
  2016-08-10 12:53                                                       ` Ben Woodcroft
  2016-08-10 17:56                                                     ` Leo Famulari
  1 sibling, 1 reply; 61+ messages in thread
From: David Craven @ 2016-08-10 12:27 UTC (permalink / raw)
  To: Ben Woodcroft; +Cc: guix-devel, Alex Kost

>> David Craven <david@craven.ch> writes:

> I don't have anything to to contribute beyond psuedo-quoting Ludo: let's not lose our hair over this!

I'll let the fact that that could interpreted as being insulting slide.

So you are telling me that I'm being a jerk? That may well be. If you
want to provide an outline of how to better handle this situation than
I did I'm all ears.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: How to get the package metadata as structured data?
  2016-08-10 12:14             ` Catonano
@ 2016-08-10 12:52               ` Ricardo Wurmus
  2016-08-10 23:40                 ` Catonano
  0 siblings, 1 reply; 61+ messages in thread
From: Ricardo Wurmus @ 2016-08-10 12:52 UTC (permalink / raw)
  To: Catonano; +Cc: guix-devel


Catonano <catonano@gmail.com> writes:

> 2016-08-10 13:46 GMT+02:00 Ricardo Wurmus <rekado@elephly.net>:
>
>>
>> Philippe Ombredanne <pombredanne@nexb.com> writes:
>>
>> > David Craven <david@craven.ch> wrote:
>> >> I aborted, since I realised that guix package -s doesn't include the
>> >> source url and hash, which would be important for a testsuite...
>> >
>> > IMHO, if the rec data is the only way to get to the packages data, the
>> > source url would be rather essential to get in.
>>
>> The recutils output is not the *only* way to access the package data.
>> All packages in Guix are just Scheme variables.  Package data are
>> available as S-expressions and can be read by Scheme programs or parsed
>> by external applications.  The recutils output is just an additional
>> format used when interacting with Guix on the command line.
>>
>> (Personally, I’m not enthusiastic about adding a serialised form of the
>> source field to the recutils output.)
>>
>> ~~ Ricardo
>>
>>
>>
> Not so long ago, someone posted a script that produced a web page with the
> results of linting all the packages
>
> That's an example
>
> One could produce an xml file to be imported in Gephi, just to make another
> example.
>
> Or a SQL text file to be imported in some relational db, or a different
> format to be imported in some not relational db...

I understand that it may be useful.  I just think that the
representation as a Guile Scheme expression/value is *already* much more
useful.  That’s what made “guix web” possible, a web interface like this
one:

    http://guix.mdc-berlin.de

Producing other formats (such as XML files) is also quite simple.  The
package expression itself is *executable*.  By overriding the meaning of
the executable parts one could easily evaluate the expression such that
it generates some other format.

~~ Ricardo

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-10 12:27                                                     ` David Craven
@ 2016-08-10 12:53                                                       ` Ben Woodcroft
  2016-08-10 13:23                                                         ` David Craven
  2016-08-10 13:42                                                         ` Ricardo Wurmus
  0 siblings, 2 replies; 61+ messages in thread
From: Ben Woodcroft @ 2016-08-10 12:53 UTC (permalink / raw)
  To: David Craven; +Cc: guix-devel, Alex Kost



On 10/08/16 22:27, David Craven wrote:
>> I don't have anything to to contribute beyond psuedo-quoting Ludo: let's not lose our hair over this!
> I'll let the fact that that could interpreted as being insulting slide.
>

Oh, no that wasn't my intended meaning. I just saw this thread getting a 
bit heated in general and I wanted to help it in the reverse direction, 
for all concerned. That's all.

I think it would be good to get further opinions on the technical issue 
at hand, but I'm afraid I don't respect my own enough to contribute it.
ben

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-10 12:53                                                       ` Ben Woodcroft
@ 2016-08-10 13:23                                                         ` David Craven
  2016-08-10 13:42                                                         ` Ricardo Wurmus
  1 sibling, 0 replies; 61+ messages in thread
From: David Craven @ 2016-08-10 13:23 UTC (permalink / raw)
  To: Ben Woodcroft; +Cc: guix-devel, Alex Kost

> the technical issue at hand

I disagree that it's a technical issue. Technical issues can be
reasoned about and can be fixed. This issue isn't technical.

> I think it would be good to get further opinions on the technical issue at hand

How do we get further opinions on the issue?

> I'm afraid I don't respect my own enough to contribute it

I think this contradicts the first part of the sentence. If no one is
willing to contribute their opinion this issue will get stale.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-10 12:53                                                       ` Ben Woodcroft
  2016-08-10 13:23                                                         ` David Craven
@ 2016-08-10 13:42                                                         ` Ricardo Wurmus
  2016-08-10 14:13                                                           ` David Craven
  2016-08-10 14:25                                                           ` Thompson, David
  1 sibling, 2 replies; 61+ messages in thread
From: Ricardo Wurmus @ 2016-08-10 13:42 UTC (permalink / raw)
  To: Ben Woodcroft; +Cc: guix-devel, Alex Kost, David Craven


Ben Woodcroft <b.woodcroft@uq.edu.au> writes:

> On 10/08/16 22:27, David Craven wrote:
>>> I don't have anything to to contribute beyond psuedo-quoting Ludo: let's not lose our hair over this!
>> I'll let the fact that that could interpreted as being insulting slide.
>>
>
> Oh, no that wasn't my intended meaning. I just saw this thread getting a 
> bit heated in general and I wanted to help it in the reverse direction, 
> for all concerned. That's all.

I agree, let’s cool it a bit please.

Aside from the possible FDSG issue (which I need to think about before
forming an opinion, although I’m leaning towards not seeing it as a
problem), I’m not yet convinced that all fields need to be printed in
recutils format.

For programmatic access to packages we recommend using the Scheme values
directly as they also hold additional information about the location of
a value in the dependency graph (package expressions are code, not plain
meta-data).  I always understood the recutils output to be just a user
interface for the command line, which is why it doesn’t need to and
probably shouldn’t print *all* fields.

I think it is not desirable to show that much more information in the
output, because it is not a programming interface but primarily a user
interface.

Even so, if one insisted on using the recutils output in a programmatic
fashion (e.g. in a bash script), it would be best to run “guix build
--source” on the package names to obtain the actual source tarballs that
are used by Guix.  What would be the point of printing a URL that is not
necessarily used by Guix directly?  “guix build --source” (which can be
used in bash scripts) already provides the *actual* tarball (patched and
with snippets applied), so this would be more meaningful than an
upstream URL, in my opinion.

What do others think?

~~ Ricardo

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-10 13:42                                                         ` Ricardo Wurmus
@ 2016-08-10 14:13                                                           ` David Craven
  2016-08-11 14:38                                                             ` Alex Kost
  2016-08-10 14:25                                                           ` Thompson, David
  1 sibling, 1 reply; 61+ messages in thread
From: David Craven @ 2016-08-10 14:13 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: guix-devel, Alex Kost

> Even so, if one insisted on using the recutils output in a programmatic
> fashion (e.g. in a bash script), it would be best to run “guix build
> --source” on the package names to obtain the actual source tarballs that
> are used by Guix.

I don't disagree. Alex what do you think?

This is a technical reason to drop the patch. I can live with this no problem.
I just don't like it when I feel someone is serving me BS. But I'm sorry for
getting upset and overreacting.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-10 13:42                                                         ` Ricardo Wurmus
  2016-08-10 14:13                                                           ` David Craven
@ 2016-08-10 14:25                                                           ` Thompson, David
  1 sibling, 0 replies; 61+ messages in thread
From: Thompson, David @ 2016-08-10 14:25 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: guix-devel, Alex Kost, David Craven

On Wed, Aug 10, 2016 at 9:42 AM, Ricardo Wurmus <rekado@elephly.net> wrote:
>
> Ben Woodcroft <b.woodcroft@uq.edu.au> writes:
>
>> On 10/08/16 22:27, David Craven wrote:
>>>> I don't have anything to to contribute beyond psuedo-quoting Ludo: let's not lose our hair over this!
>>> I'll let the fact that that could interpreted as being insulting slide.
>>>
>>
>> Oh, no that wasn't my intended meaning. I just saw this thread getting a
>> bit heated in general and I wanted to help it in the reverse direction,
>> for all concerned. That's all.
>
> I agree, let’s cool it a bit please.
>
> Aside from the possible FDSG issue (which I need to think about before
> forming an opinion, although I’m leaning towards not seeing it as a
> problem), I’m not yet convinced that all fields need to be printed in
> recutils format.
>
> For programmatic access to packages we recommend using the Scheme values
> directly as they also hold additional information about the location of
> a value in the dependency graph (package expressions are code, not plain
> meta-data).  I always understood the recutils output to be just a user
> interface for the command line, which is why it doesn’t need to and
> probably shouldn’t print *all* fields.
>
> I think it is not desirable to show that much more information in the
> output, because it is not a programming interface but primarily a user
> interface.
>
> Even so, if one insisted on using the recutils output in a programmatic
> fashion (e.g. in a bash script), it would be best to run “guix build
> --source” on the package names to obtain the actual source tarballs that
> are used by Guix.  What would be the point of printing a URL that is not
> necessarily used by Guix directly?  “guix build --source” (which can be
> used in bash scripts) already provides the *actual* tarball (patched and
> with snippets applied), so this would be more meaningful than an
> upstream URL, in my opinion.
>
> What do others think?

+1

- Dave

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-10 12:15                                                   ` Ben Woodcroft
  2016-08-10 12:27                                                     ` David Craven
@ 2016-08-10 17:56                                                     ` Leo Famulari
  1 sibling, 0 replies; 61+ messages in thread
From: Leo Famulari @ 2016-08-10 17:56 UTC (permalink / raw)
  To: Ben Woodcroft; +Cc: guix-devel, Alex Kost, David Craven

On Wed, Aug 10, 2016 at 10:15:52PM +1000, Ben Woodcroft wrote:
> I don't have anything to to contribute beyond psuedo-quoting Ludo: let's not
> lose our hair over this!

+1

I think our presence on this mailing list shows that we all have a
common goal: the creation and continued improvement of a free software
distribution and operating system.

For practical reasons, I think that we need to try our best to interpret
each others' messages charitably.

Communicating tone and emotion through the English language is hard
enough for those of us who learned it as our first language. There are a
handful of professional writers who have mastered this art, and they
earn a lot of money for it.

The rest of us, myself included, have to accept that we will sometimes
be misinterpreted, and that we will sometimes misinterpret others. So, I
hope we can remember our common goal, give the benefit of the doubt, and
try to let perceived slights slide, since they may not have even been
intended in the first place. Like I said, communicating tone effectively
through written language is very hard, at least with English.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: How to get the package metadata as structured data?
  2016-08-10 12:52               ` Ricardo Wurmus
@ 2016-08-10 23:40                 ` Catonano
  0 siblings, 0 replies; 61+ messages in thread
From: Catonano @ 2016-08-10 23:40 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: guix-devel

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

2016-08-10 14:52 GMT+02:00 Ricardo Wurmus <rekado@elephly.net>:

>
> Catonano <catonano@gmail.com> writes:
>
> > 2016-08-10 13:46 GMT+02:00 Ricardo Wurmus <rekado@elephly.net>:
> >
> >>
> >> Philippe Ombredanne <pombredanne@nexb.com> writes:
> >>
> >> > David Craven <david@craven.ch> wrote:
> >> >> I aborted, since I realised that guix package -s doesn't include the
> >> >> source url and hash, which would be important for a testsuite...
> >> >
> >> > IMHO, if the rec data is the only way to get to the packages data, the
> >> > source url would be rather essential to get in.
> >>
> >> The recutils output is not the *only* way to access the package data.
> >> All packages in Guix are just Scheme variables.  Package data are
> >> available as S-expressions and can be read by Scheme programs or parsed
> >> by external applications.  The recutils output is just an additional
> >> format used when interacting with Guix on the command line.
> >>
> >> (Personally, I’m not enthusiastic about adding a serialised form of the
> >> source field to the recutils output.)
> >>
> >> ~~ Ricardo
> >>
> >>
> >>
> > Not so long ago, someone posted a script that produced a web page with
> the
> > results of linting all the packages
> >
> > That's an example
> >
> > One could produce an xml file to be imported in Gephi, just to make
> another
> > example.
> >
> > Or a SQL text file to be imported in some relational db, or a different
> > format to be imported in some not relational db...
>
> I understand that it may be useful.  I just think that the
> representation as a Guile Scheme expression/value is *already* much more
> useful.  That’s what made “guix web” possible, a web interface like this
> one:
>
>     http://guix.mdc-berlin.de



Yes, Ricardo, I was not disagreeing with you. I was just trying to offer
Philippe some more perspective.

In fact I believe that the approach you envisioned (a cycle through the
packages values, leaving only the decompress phase and adding a phase that
calls Philippe's tool) has its merits.

Only, if I was Philippe, I would regret storing the output in the store

I'd prefer to be able to store the output in the regular file system

In this regard, I think that the threads about pipelines (for reproducible
science), some time ago, were quite interesting

[-- Attachment #2: Type: text/html, Size: 3353 bytes --]

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-08  0:15                           ` Mathieu Lirzin
  2016-08-08 11:20                             ` David Craven
@ 2016-08-11 10:15                             ` Mark H Weaver
  2016-08-11 10:21                               ` Mark H Weaver
  1 sibling, 1 reply; 61+ messages in thread
From: Mark H Weaver @ 2016-08-11 10:15 UTC (permalink / raw)
  To: Mathieu Lirzin; +Cc: guix-devel, Alex Kost, David Craven

Mathieu Lirzin <mthl@gnu.org> writes:

> David Craven <david@craven.ch> writes:
>
>> Quoting FSDG:
>> A free system distribution must not steer users towards obtaining any
>> nonfree information for practical use, or encourage them to do so.
>>
>> We are not steering or encouraging users to do any thing by displaying
>> the source url of the tarball, 
>
> That's an interpretation of it.  I think that point deserves a
> discussion on <gnu-linux-libre@nongnu.org> mailing list, before
> including such change in Guix UI.

I agree with Mathieu.  Having the Guix UI display a source URI that
contains non-free software is arguably steering users towards obtaining
nonfree information for practical use.

We will need to ask for input from <gnu-linux-libre@nongnu.org> before
considering this.

> Asking me to start a discussion on the linux-libre mailing list over
> this is an unreasonable request.

I'm sorry that you feel that way, but I'm afraid I must block this
proposed change until that discussion occurs.

       Mark

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-11 10:15                             ` Mark H Weaver
@ 2016-08-11 10:21                               ` Mark H Weaver
  2016-08-11 11:06                                 ` David Craven
  0 siblings, 1 reply; 61+ messages in thread
From: Mark H Weaver @ 2016-08-11 10:21 UTC (permalink / raw)
  To: Mathieu Lirzin; +Cc: guix-devel, Alex Kost, David Craven

Mark H Weaver <mhw@netris.org> writes:

> Mathieu Lirzin <mthl@gnu.org> writes:
>
>> David Craven <david@craven.ch> writes:
>>
>>> Quoting FSDG:
>>> A free system distribution must not steer users towards obtaining any
>>> nonfree information for practical use, or encourage them to do so.
>>>
>>> We are not steering or encouraging users to do any thing by displaying
>>> the source url of the tarball, 
>>
>> That's an interpretation of it.  I think that point deserves a
>> discussion on <gnu-linux-libre@nongnu.org> mailing list, before
>> including such change in Guix UI.
>
> I agree with Mathieu.  Having the Guix UI display a source URI that
> contains non-free software is arguably steering users towards obtaining
> nonfree information for practical use.
>
> We will need to ask for input from <gnu-linux-libre@nongnu.org> before
> considering this.

Sorry, I made a quoting error in my previous message.  The next two
lines were actually written by David, although my quoting made them
appear to be from Mathieu:

>> Asking me to start a discussion on the linux-libre mailing list over
>> this is an unreasonable request.
>
> I'm sorry that you feel that way, but I'm afraid I must block this
> proposed change until that discussion occurs.
>
>        Mark

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-11 10:21                               ` Mark H Weaver
@ 2016-08-11 11:06                                 ` David Craven
  2016-08-11 11:41                                   ` Mark H Weaver
  2016-08-11 11:46                                   ` David Craven
  0 siblings, 2 replies; 61+ messages in thread
From: David Craven @ 2016-08-11 11:06 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: guix-devel, Alex Kost

Hi Mark,

We already agreed to drop the patch. I don't understand why you'd want
to pick a fight that no one is fighting. Besides where the tarball
came from is a fact.

Since this is a point of disagreement I think this is a discussion
that should be had.

I'll provide a couple of word definitions from the English dictionary
before providing my argument so that it is clear what I'm talking
about.

Fact:
1. a thing that is known or proved to be true.
2. information used as evidence or as part of a report or news article.
3. used to refer to a particular situation under discussion.
4. the truth about events as opposed to interpretation.

Inform:
1. give (someone) facts or information
2. give an essential or formative principle or quality to

Steer:
1. guide or control the movement of (a vehicle, vessel, or aircraft),
for example by turning a wheel or operating a rudder.

Are you saying that the source-uri of a package isn't a fact?

If we agree that it is a fact, it can per definition only inform users
actions, being a truth, but not steer them.

The only way that this could be considered steering is as I stated
earlier, if we censor some facts and display others. This causes facts
to show a distorted picture. I provided a solution to this, by
agreeing that we weren't providing all information.

David

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-11 11:06                                 ` David Craven
@ 2016-08-11 11:41                                   ` Mark H Weaver
  2016-08-11 11:46                                   ` David Craven
  1 sibling, 0 replies; 61+ messages in thread
From: Mark H Weaver @ 2016-08-11 11:41 UTC (permalink / raw)
  To: David Craven; +Cc: guix-devel, Alex Kost

David Craven <david@craven.ch> writes:
> We already agreed to drop the patch.

I didn't know that when I wrote my message, because I hadn't finished
reading the thread.

> Since this is a point of disagreement I think this is a discussion
> that should be had.

Having now read the entire thread, I'd prefer not to discuss this
further with you, but if you insist, please raise it on
<gnu-linux-libre@nongnu.org>, not here.

      Mark

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-11 11:06                                 ` David Craven
  2016-08-11 11:41                                   ` Mark H Weaver
@ 2016-08-11 11:46                                   ` David Craven
  1 sibling, 0 replies; 61+ messages in thread
From: David Craven @ 2016-08-11 11:46 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: guix-devel, Alex Kost

I expect someone to calmly and rationally reply to my argument and
take it seriously, I don't think it's to big of an ask. I want this
discussion to find a resolution.

>> Asking me to start a discussion on the linux-libre mailing list over
>> this is an unreasonable request.

> I'm sorry that you feel that way, but I'm afraid I must block this
> proposed change until that discussion occurs.

I agreed to contribute to guix, participate constructively in
discussions and actively try to find agreement.

What I did not sign up for is recognizing a third party authority like
the <gnu-linux-libre@nongnu.org> and asking them for permission for
small changes. Who made them the FSDG police? (This is a calm question
even if it may not sound that way...)

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-10 14:13                                                           ` David Craven
@ 2016-08-11 14:38                                                             ` Alex Kost
  2016-08-11 16:19                                                               ` David Craven
  2016-08-11 16:42                                                               ` Ricardo Wurmus
  0 siblings, 2 replies; 61+ messages in thread
From: Alex Kost @ 2016-08-11 14:38 UTC (permalink / raw)
  To: David Craven; +Cc: guix-devel

David Craven (2016-08-10 17:13 +0300) wrote:

>> Even so, if one insisted on using the recutils output in a programmatic
>> fashion (e.g. in a bash script), it would be best to run “guix build
>> --source” on the package names to obtain the actual source tarballs that
>> are used by Guix.
>
> I don't disagree. Alex what do you think?

Do you mean about your original proposal?  I am for it: I don't
comprehend why the source URL can't be displayed (especially since a
user can easily find it anyway), but I don't understand FSDG well enough
to judge, so I prefer not to participate in this discussion.

(I hope this thread will not tear Guix contributors apart)

-- 
Alex

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-11 14:38                                                             ` Alex Kost
@ 2016-08-11 16:19                                                               ` David Craven
  2016-08-11 18:15                                                                 ` Ricardo Wurmus
  2016-08-12  8:22                                                                 ` Alex Kost
  2016-08-11 16:42                                                               ` Ricardo Wurmus
  1 sibling, 2 replies; 61+ messages in thread
From: David Craven @ 2016-08-11 16:19 UTC (permalink / raw)
  To: Alex Kost; +Cc: guix-devel

How invested are you in this patch? I decided that I wasn't that
invested and it isn't worth the trouble. Some things are not meant to
be.

I hate giving Mathieu the satisfaction, since it opens the door to
raising an FSDG issue on any patch, either because you dislike the
patch or the author.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-11 14:38                                                             ` Alex Kost
  2016-08-11 16:19                                                               ` David Craven
@ 2016-08-11 16:42                                                               ` Ricardo Wurmus
  2016-08-12  8:33                                                                 ` Alex Kost
  1 sibling, 1 reply; 61+ messages in thread
From: Ricardo Wurmus @ 2016-08-11 16:42 UTC (permalink / raw)
  To: Alex Kost; +Cc: guix-devel, David Craven


Alex Kost <alezost@gmail.com> writes:

> David Craven (2016-08-10 17:13 +0300) wrote:
>
>>> Even so, if one insisted on using the recutils output in a programmatic
>>> fashion (e.g. in a bash script), it would be best to run “guix build
>>> --source” on the package names to obtain the actual source tarballs that
>>> are used by Guix.
>>
>> I don't disagree. Alex what do you think?
>
> Do you mean about your original proposal?  I am for it: I don't
> comprehend why the source URL can't be displayed (especially since a
> user can easily find it anyway), but I don't understand FSDG well enough
> to judge, so I prefer not to participate in this discussion.

I have previously stated that I’m not convinced that we really need a
serialisation of the “source” field in the user-facing recutils output.
The patch was a welcome demonstration of how this feature would look
like.

As to the question about whether printing the plain upstream source URLs
has FSDG implications I suggest that those who think that this change
would be an improvement bring it up for discussion on the
gnu-linux-libre mailing list, as we don’t want to ignore the concerns
brought up by Mathieu and Mark.

> (I hope this thread will not tear Guix contributors apart)

It won’t :)  I think it’s obvious that there has been some
miscommunication in this thread.  We may be able to avoid this in the
future if everyone made a conscious effort at being courteous when
writing and tolerant when reading.  It is easy to miscommunicate in a
textual medium.

~~ Ricardo

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-11 16:19                                                               ` David Craven
@ 2016-08-11 18:15                                                                 ` Ricardo Wurmus
  2016-08-12  8:22                                                                 ` Alex Kost
  1 sibling, 0 replies; 61+ messages in thread
From: Ricardo Wurmus @ 2016-08-11 18:15 UTC (permalink / raw)
  To: David Craven; +Cc: guix-devel, Alex Kost


David Craven <david@craven.ch> writes:

> I hate giving Mathieu the satisfaction, since it opens the door to
> raising an FSDG issue on any patch, either because you dislike the
> patch or the author.

Please don’t do this.  This is not constructive.

~~ Ricardo

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-11 16:19                                                               ` David Craven
  2016-08-11 18:15                                                                 ` Ricardo Wurmus
@ 2016-08-12  8:22                                                                 ` Alex Kost
  1 sibling, 0 replies; 61+ messages in thread
From: Alex Kost @ 2016-08-12  8:22 UTC (permalink / raw)
  To: David Craven; +Cc: guix-devel

David Craven (2016-08-11 19:19 +0300) wrote:

> How invested are you in this patch? I decided that I wasn't that
> invested and it isn't worth the trouble. Some things are not meant to
> be.

Invested?  Sorry, I don't understand.  Do you mean how much I need this
patch?  Well, I don't need it at all, since I never use "guix package
--show".  I just don't see a problem in accepting this patch as I don't
understand Mathieu's and Mark's concerns about FSDG compliance, but I'm
not competent in this area, so I let other people judge.

-- 
Alex

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-11 16:42                                                               ` Ricardo Wurmus
@ 2016-08-12  8:33                                                                 ` Alex Kost
  2016-08-12  8:41                                                                   ` Ricardo Wurmus
  0 siblings, 1 reply; 61+ messages in thread
From: Alex Kost @ 2016-08-12  8:33 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: guix-devel, David Craven

Ricardo Wurmus (2016-08-11 19:42 +0300) wrote:

> Alex Kost <alezost@gmail.com> writes:
>
>> David Craven (2016-08-10 17:13 +0300) wrote:
>>
>>>> Even so, if one insisted on using the recutils output in a programmatic
>>>> fashion (e.g. in a bash script), it would be best to run “guix build
>>>> --source” on the package names to obtain the actual source tarballs that
>>>> are used by Guix.
>>>
>>> I don't disagree. Alex what do you think?
>>
>> Do you mean about your original proposal?  I am for it: I don't
>> comprehend why the source URL can't be displayed (especially since a
>> user can easily find it anyway), but I don't understand FSDG well enough
>> to judge, so I prefer not to participate in this discussion.
>
> I have previously stated that I’m not convinced that we really need a
> serialisation of the “source” field in the user-facing recutils output.
> The patch was a welcome demonstration of how this feature would look
> like.

Yes, I agree that it's a good demonstration of using Scheme API to get
any package info you need.  But many (probably most) people do not know
Guile and this Guix package API well enough, and for them it may be much
easier to operate on the recutils output of "guix package --show" in
their scripts.  If I understand correctly, that's why David suggested
that patch.

P.S.  I don't want to raise another wave of messages in this thread :-)
If I understand it right, everyone agreed on not merging the patch.

-- 
Alex

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-12  8:33                                                                 ` Alex Kost
@ 2016-08-12  8:41                                                                   ` Ricardo Wurmus
  2016-08-12 10:05                                                                     ` David Craven
  0 siblings, 1 reply; 61+ messages in thread
From: Ricardo Wurmus @ 2016-08-12  8:41 UTC (permalink / raw)
  To: Alex Kost; +Cc: guix-devel, David Craven


Alex Kost <alezost@gmail.com> writes:

> Yes, I agree that it's a good demonstration of using Scheme API to get
> any package info you need.  But many (probably most) people do not know
> Guile and this Guix package API well enough, and for them it may be much
> easier to operate on the recutils output of "guix package --show" in
> their scripts.  If I understand correctly, that's why David suggested
> that patch.

Yes, the recutils output could be used in scripts.  My recommendation
when dealing with source tarballs, however, is to call “guix build -S”
on the package name that recutils provides — this gives the user the
actual corresponding source.  This seems to be sufficient for shell
scripting purposes.

~~ Ricardo

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-12  8:41                                                                   ` Ricardo Wurmus
@ 2016-08-12 10:05                                                                     ` David Craven
  2016-08-13  7:46                                                                       ` Alex Kost
  0 siblings, 1 reply; 61+ messages in thread
From: David Craven @ 2016-08-12 10:05 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: guix-devel, Alex Kost

> Invested?  Sorry, I don't understand.

One definition of invest is:
devote (one's time, effort, or energy) to a particular undertaking
with the expectation of a worthwhile result.

I just thought that you had invested some time and energy with this
issue, and don't know what your expectation of a worthwhile result is.
The question was mainly intended to say - I can't be bothered to start
a discussion on a different mailing list, but I'll offer my support if
you think it's worthwhile...

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-12 10:05                                                                     ` David Craven
@ 2016-08-13  7:46                                                                       ` Alex Kost
  2016-08-13 13:00                                                                         ` David Craven
  0 siblings, 1 reply; 61+ messages in thread
From: Alex Kost @ 2016-08-13  7:46 UTC (permalink / raw)
  To: David Craven; +Cc: guix-devel

David Craven (2016-08-12 13:05 +0300) wrote:

>> Invested?  Sorry, I don't understand.
>
> One definition of invest is:
> devote (one's time, effort, or energy) to a particular undertaking
> with the expectation of a worthwhile result.

Ah, OK, then I'm not invested at all :-)

> I just thought that you had invested some time and energy with this
> issue, and don't know what your expectation of a worthwhile result is.
> The question was mainly intended to say - I can't be bothered to start
> a discussion on a different mailing list, but I'll offer my support if
> you think it's worthwhile...

Thanks, but I wouldn't like to participate in such a discussion.

-- 
Alex

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-13  7:46                                                                       ` Alex Kost
@ 2016-08-13 13:00                                                                         ` David Craven
  2016-08-13 13:18                                                                           ` Leo Famulari
  0 siblings, 1 reply; 61+ messages in thread
From: David Craven @ 2016-08-13 13:00 UTC (permalink / raw)
  To: Alex Kost; +Cc: guix-devel

> Thanks, but I wouldn't like to participate in such a discussion.

Yeah, I get the feeling that no one does. That's why saying something
is an FSDG issue is like saying "we won't accept your patch and won't
discuss with you why".

> I just don't see a problem in accepting this patch as I don't
> understand Mathieu's and Mark's concerns about FSDG compliance, but I'm
> not competent in this area, so I let other people judge.

Can you please explain why you don't feel competent? It's written in plain
English, not AES encrypted English, so I have difficulty understanding
why people think they can't read it and form an opinion about it (not this
issue in particular, but more general any issue that comes up), and I don't
just mean you either, but a few people have said this...

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-13 13:00                                                                         ` David Craven
@ 2016-08-13 13:18                                                                           ` Leo Famulari
  2016-08-14 16:00                                                                             ` Alex Kost
  0 siblings, 1 reply; 61+ messages in thread
From: Leo Famulari @ 2016-08-13 13:18 UTC (permalink / raw)
  To: David Craven; +Cc: guix-devel, Alex Kost

On Sat, Aug 13, 2016 at 03:00:42PM +0200, David Craven wrote:
> Can you please explain why you don't feel competent? It's written in plain
> English, not AES encrypted English, so I have difficulty understanding
> why people think they can't read it and form an opinion about it (not this
> issue in particular, but more general any issue that comes up), and I don't
> just mean you either, but a few people have said this...

Personally, after having read it the first time, I wouldn't have
expected web browsers to be excluded from a free distribution due to
their recommendation of non-free "add-ons". I don't disagree with this
interpretation; it simply would not have occurred to me. It requires
some imagination and some time thinking about the issues and the
particularities of the software we use.

So, I think the language of the text and its interpretation are actually
not obvious. And in this case, the point of the patch in question can be
achieved by another method, so I personally didn't want to spend time
interpreting the FSDG when I could spend it on something else.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] ui: 'package->recutils' serializes the source field.
  2016-08-13 13:18                                                                           ` Leo Famulari
@ 2016-08-14 16:00                                                                             ` Alex Kost
  0 siblings, 0 replies; 61+ messages in thread
From: Alex Kost @ 2016-08-14 16:00 UTC (permalink / raw)
  To: Leo Famulari; +Cc: guix-devel, David Craven

Leo Famulari (2016-08-13 16:18 +0300) wrote:

> On Sat, Aug 13, 2016 at 03:00:42PM +0200, David Craven wrote:
>> Can you please explain why you don't feel competent? It's written in plain
>> English, not AES encrypted English, so I have difficulty understanding
>> why people think they can't read it and form an opinion about it (not this
>> issue in particular, but more general any issue that comes up), and I don't
>> just mean you either, but a few people have said this...
>
> Personally, after having read it the first time, I wouldn't have
> expected web browsers to be excluded from a free distribution due to
> their recommendation of non-free "add-ons". I don't disagree with this
> interpretation; it simply would not have occurred to me. It requires
> some imagination and some time thinking about the issues and the
> particularities of the software we use.
>
> So, I think the language of the text and its interpretation are actually
> not obvious. And in this case, the point of the patch in question can be
> achieved by another method, so I personally didn't want to spend time
> interpreting the FSDG when I could spend it on something else.

Oof, thanks for this message!  I have a similar point.  I always find it
hard to read and understand such (long and boring) guidelines, licenses,
etc.  I realize they are important, but I just don't like to spend my
time on them.

TBH I stopped reading after "These guidelines are not complete" phrase :-)

-- 
Alex

^ permalink raw reply	[flat|nested] 61+ messages in thread

end of thread, other threads:[~2016-08-14 16:00 UTC | newest]

Thread overview: 61+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-08-04 20:49 How to get the package metadata as structured data? David Craven
2016-08-04 21:08 ` Ludovic Courtès
2016-08-04 22:03   ` Cook, Malcolm
2016-08-05 10:17     ` David Craven
2016-08-05 11:04       ` David Craven
2016-08-05 12:40         ` Aljosha Papsch
2016-08-05 14:50         ` Philippe Ombredanne
2016-08-05 14:58           ` [PATCH] ui: 'package->recutils' serializes the source field David Craven
2016-08-06 12:35             ` Alex Kost
2016-08-06 12:46               ` David Craven
2016-08-06 15:00               ` Mathieu Lirzin
2016-08-07 10:26                 ` David Craven
2016-08-07 11:15                   ` Mathieu Lirzin
2016-08-07 11:19                     ` David Craven
2016-08-07 12:12                       ` David Craven
2016-08-07 13:27                       ` Mathieu Lirzin
2016-08-07 21:33                         ` David Craven
2016-08-08  0:15                           ` Mathieu Lirzin
2016-08-08 11:20                             ` David Craven
2016-08-08 17:53                               ` Mathieu Lirzin
2016-08-08 18:12                                 ` David Craven
2016-08-08 19:07                                 ` Alex Kost
2016-08-08 21:09                                   ` Mathieu Lirzin
2016-08-08 22:58                                     ` David Craven
2016-08-08 23:56                                       ` Mathieu Lirzin
2016-08-09  0:18                                         ` David Craven
2016-08-10 10:12                                           ` David Craven
2016-08-10 11:30                                             ` Mathieu Lirzin
2016-08-10 11:38                                               ` David Craven
2016-08-10 11:46                                                 ` David Craven
2016-08-10 12:06                                                 ` Mathieu Lirzin
2016-08-10 12:15                                                   ` Ben Woodcroft
2016-08-10 12:27                                                     ` David Craven
2016-08-10 12:53                                                       ` Ben Woodcroft
2016-08-10 13:23                                                         ` David Craven
2016-08-10 13:42                                                         ` Ricardo Wurmus
2016-08-10 14:13                                                           ` David Craven
2016-08-11 14:38                                                             ` Alex Kost
2016-08-11 16:19                                                               ` David Craven
2016-08-11 18:15                                                                 ` Ricardo Wurmus
2016-08-12  8:22                                                                 ` Alex Kost
2016-08-11 16:42                                                               ` Ricardo Wurmus
2016-08-12  8:33                                                                 ` Alex Kost
2016-08-12  8:41                                                                   ` Ricardo Wurmus
2016-08-12 10:05                                                                     ` David Craven
2016-08-13  7:46                                                                       ` Alex Kost
2016-08-13 13:00                                                                         ` David Craven
2016-08-13 13:18                                                                           ` Leo Famulari
2016-08-14 16:00                                                                             ` Alex Kost
2016-08-10 14:25                                                           ` Thompson, David
2016-08-10 17:56                                                     ` Leo Famulari
2016-08-11 10:15                             ` Mark H Weaver
2016-08-11 10:21                               ` Mark H Weaver
2016-08-11 11:06                                 ` David Craven
2016-08-11 11:41                                   ` Mark H Weaver
2016-08-11 11:46                                   ` David Craven
2016-08-10 11:46           ` How to get the package metadata as structured data? Ricardo Wurmus
2016-08-10 12:14             ` Catonano
2016-08-10 12:52               ` Ricardo Wurmus
2016-08-10 23:40                 ` Catonano
  -- strict thread matches above, loose matches on Subject: below --
2016-08-04 18:37 Philippe Ombredanne

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).