ui: 'package->recutils' serializes the source field.

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

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?
  

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.
  

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?
  

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?
  

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.
  

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... ;-)
  

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

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.
  

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.
  

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.  :)
  

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?
  

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.
  

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

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

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
  

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.
  

> 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 ;-)
  

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
  

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.
  

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

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

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.
  

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
  

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

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
  

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

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
  

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

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
  

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.
  

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
  

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
  

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
  

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
  

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

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)
  

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.
  

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
  

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
  

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.
  

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

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

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.
  

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

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.
  

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 :-)