Re: A "cosmetic changes" commit that removes security fixes

[Leo Famulari]

On Mon, Apr 26, 2021 at 11:56:22PM +0200, Giovanni Biscuolo wrote:
> No, I simply misunderstood, sorry for the noise!

Okay, and thanks for asking! It's important to clarify these things;
it's not just noise :)

This kind of knowledge is something I picked up over time, but I'm not
sure it's written down anywhere. So I added a line to the manual that I
hope can make it a little more clear to anyone looking for information:

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=4de688738ce802056dadd6f785c7bdb3407dc768

Re: A "cosmetic changes" commit that removes security fixes

[Giovanni Biscuolo]

Leo Famulari  writes:

> On Mon, Apr 26, 2021 at 07:06:33PM +0200, Giovanni Biscuolo wrote:
>> Just to understand: /if/ at any point in time a user is able to afford
>> the effort to build the entire core-updates /or/ staging branch she
>> should be confident the result is state-of-the-art secure.  Am I wrong
>> with this assumption?
>
> Unfortunately your assumption is incorrect.

[...]

> If there is some documentation or messaging that suggests that anyone
> should ever use the core-updates branch, please let us know and we will
> fix that.

No, I simply misunderstood, sorry for the noise!

[...]

Thanks, Giovanni

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: Outreachy - Guix Data Service: questions about improving the data for derivation comparisons.

[Christopher Baines]

Luciana Lima Brito  writes:

> On Mon, 26 Apr 2021 09:15:37 +0100
> Christopher Baines  wrote:
>
>> So, one advantage of alists over lists is that the code is probably
>> less brittle when adding elements say, since code parsing the list
>> will probably break with a new element, but this is probably less
>> likely to happen with an alist.
>>
>> However, this will happen with an alist if match is used to pick
>> elements out. I'd suggest using assq-ref or similar to pluck elements
>> out.
>
> Ok, I changed that on the html.scm.

Great :)

Rather than writing:

  (match-lambda
((alist ...)

I'd just use

  (lambda (alist)

as I think that's equivalent right?

>> I'd consider these options first probably:
>>
>>  - Could the data coming from derivation-differences-data have vectors
>>where appropriate already? The HTML code would probably need to be
>>adjusted, but I think that's fine.
>
> I tried this for days but with no success. Maybe the only way would be
> to tweak group-to-alist, but it touches many places, and I didn't want
> to mess with it.

Maybe add another procedure that combines group-to-alist but generates
an alist with vectors as the values? (group-to-alist/vector maybe).

>>  - Could this be written in a form like:
>>
>>,@(map (lambda (name)
>>...)
>>   '(outputs inputs sources arguments))
>
> This only make sense to me inside render-json (because of the ,@), but I
> think the code would be less clean and "arguments" would appear in a
> different order. What I did was bind the result of a function similar
> to this in the let.

I think using let is OK, but I think just unpacking data-groups as
you've called it directly in to the alist is fine (so ,@data-groups),
rather than picking out the elements. JSON objects are unordered, so the
ordering isn't something that really matters.

If you do go down this route though, I'd probably add a comment saying
what things are being added to the outer most alist, just to make the
code quicker to read.


signature.asc
Description: PGP signature

Re: Best practices for writing services

[raingloom]

On Thu, 22 Apr 2021 09:19:56 +0200
Xinglu Chen  wrote:

> On Thu, Apr 22 2021, raingloom wrote:
> 
> >> One thing that I find a little annoying is that you have to
> >> specify a default value for the fields.  
> >
> > Are you sure? If you don't specify a default, won't the user just be
> > forced to write
> > (service whatever
> > (whatever-configuration
> > (mandatory-field 'bleepbloop)))
> >
> > instead of the shorter (service whatever)?  
> 
> If I write something like this
> 
> #+begin_src scheme
> (use-modules (gnu services configuration))
> (define (serialize-list field-name val) "")
> (define-configuration test-config
>   (config
>(list)
>"configuration for test"))
> #+end_src
> 
> and evaluate it, I will get an error.  I have to specify a default
> value for the ‘config’ field to make it work.
> 
> #+begin_src scheme
> (use-modules (gnu services configuration))
> (define (serialize-list field-name val) "")
> (define-configuration test-config
>   (config
>(list '())   ;default to '()
>"configuration for test"))
> #+end_src
> 

Weird. I'd consider this a bug in define-configuration.
define-record-type* does not have this limitation.

Re: A "cosmetic changes" commit that removes security fixes

[Pjotr Prins]

On Mon, Apr 26, 2021 at 07:21:14PM +0200, Ludovic Courtès wrote:
> Hi Léo,
> 
> Tobias Geerinckx-Rice  skribis:
> 
> >> https://git.sr.ht/~lle-bout/guix/commit/a045a48dd961f0c5c3d536dcc3fd21d9c08d2d50
> >> https://git.sr.ht/~lle-bout/guix/commit/6477daa338fbf1c9edacfc3690aca77cacfe0008
> >> Can you please explain what went wrong here?

To be honest, I think Leo and Raghav have been pretty clear. They made
a mistake and that can happen to all of us. Now before this thing goes
off the rails we should also recognise that everyone is different.
Which is really something to celebrate. Everyone on this thread has
made great contributions in a highly diverse environment to GNU Guix
and that is what matters, really.

We should also recognise that some people may be blunt and direct and
even personal. I don't think that is bad. It may not always be nice
and it may hurt our goals of being inclusive, but then there may be a
cultural component too. What is honest and meaningful to one may be
perceived as hurtful by another. It is somewhat unavoidable in an
international social experiment. Personally I shut up on disagreement,
as these E-mails live much too long.

Ricardo wrote a great E-mail early in this thread. I suggest we bury
the hatchet and move forward. It is clear to me that Leo and Raghav
mean well, won't make the mistake again, and this is taking too much
energy from everyone.

Pj.

Re: A "cosmetic changes" commit that removes security fixes

[Léo Le Bouter]

On Fri, 2021-04-23 at 15:18 -0400, Leo Famulari wrote:
> I have to agree with everybody in this thead.
> 
> The commits in question were problematic (especially on core-updates,
> which is not a "WIP" branch and thus cannot be rewritten to fix past
> problems). I'm not confident that the security fixes would have been
> reinstated on core-updates if Mark had not asked about them.
> 
> Léo and Raghav, you need to keep learning our workflow around
> security
> updates.  It's not okay to remove security patches and later update a
> package to a fixed version in a different commit. `git rebase` is the
> tool to learn for cases like this one.

I do not think here that Raghav and myself should somehow be framed as
people having to learn more and that would be the reason for these
issues. To talk about myself, I think the main difference here is that
Mark and myself consider different things to have value when
contributing to GNU Guix. Mark tends to consider the technicality of
contributing to GNU Guix, that the code be well tested, that every
change be made in a very rigorous way. I tend to also consider these
things but also consider other things like how people feel when they
contribute to GNU Guix, do they feel discouraged or rewarded by their
contributions, I find that it can be tiring and very discouraging to
respond back and forth to many many review comments, and at some point,
even if things have some rough edges, I tend to prefer rewarding a
contributor for their work than insist the commit history should be
perfect or something. I also stopped upholding myself to high rigorous
standards at all times, also because I think it is not good for my
mental health. I tend to move the responsability of rigorous testing
into tools, I think putting testing/checking into tools is at the same
time good for mental health and inclusive because it means also
everyone can check their own changes and correct errors. Having tools
to check things is less stressful for everyone, I discovered that
aspect after I learned Rust and I think it really is the way to go. I
think there is an aspect of contribution where people feel stressed and
doubt themselves and that's what keeps them away from contribution, if
we have tools then those problems tend to disappear because the tool
acts as a stopgap, the tool can also be collectively improved as soon
as more best practices are discovered by the community. Rust does this
with clippy lint rules, the borrow checker and the very well made
error/warning reporting of the compiler. I think relying more on tools
even if we never can do so fully and less on individual accountability
is better here.

> 
> However, Mark, you have way more experience, and you need to handle
> these things differently. If you don't trust certain Guix
> contributors,
> take it up with the maintainers — in private. The style of
> communication
> you used here is ineffective and will dissuade people from
> contributing
> to Guix. Do you want Léo and Raghav to learn and improve? Or do you
> want
> them to leave? Remember that we all begin as beginners.

Léo


signature.asc
Description: This is a digitally signed message part

Re: Outreachy - Guix Data Service: questions about improving the data for derivation comparisons.

[Luciana Lima Brito]

On Mon, 26 Apr 2021 09:15:37 +0100
Christopher Baines  wrote:

> So, one advantage of alists over lists is that the code is probably
> less brittle when adding elements say, since code parsing the list
> will probably break with a new element, but this is probably less
> likely to happen with an alist.
> 
> However, this will happen with an alist if match is used to pick
> elements out. I'd suggest using assq-ref or similar to pluck elements
> out.

Ok, I changed that on the html.scm.
 
> I'd consider these options first probably:
> 
>  - Could the data coming from derivation-differences-data have vectors
>where appropriate already? The HTML code would probably need to be
>adjusted, but I think that's fine.

I tried this for days but with no success. Maybe the only way would be
to tweak group-to-alist, but it touches many places, and I didn't want
to mess with it.

>  - Could this be written in a form like:
> 
>,@(map (lambda (name)
>...)
>   '(outputs inputs sources arguments))

This only make sense to me inside render-json (because of the ,@), but I
think the code would be less clean and "arguments" would appear in a
different order. What I did was bind the result of a function similar
to this in the let. 

Well, this way made things much shorter. I'm sending a new patch for
you to review.


-- 
Best Regards,

Luciana Lima Brito
MSc. in Computer Science
>From d0e221f5aef2892582bdcb73aceadf937b50e45f Mon Sep 17 00:00:00 2001
From: Luciana Brito 
Date: Sun, 25 Apr 2021 15:17:33 -0300
Subject: [PATCH] Change handling of queried data for derivations comparison.

comparison.scm: return query data for derivation comparison as an alist, instead of list.
html.scm: Access derivation differences data using assq-ref.
controller.scm: generalize map for outputs/inputs/sources/arguments.
---
 guix-data-service/comparison.scm | 68 
 guix-data-service/web/compare/controller.scm | 82 
 guix-data-service/web/compare/html.scm   | 53 ++---
 3 files changed, 75 insertions(+), 128 deletions(-)

diff --git a/guix-data-service/comparison.scm b/guix-data-service/comparison.scm
index e5e1955..1f47c38 100644
--- a/guix-data-service/comparison.scm
+++ b/guix-data-service/comparison.scm
@@ -158,19 +158,23 @@ GROUP BY 1, 2, 3, 4, 5"))
   (let ((parsed-derivation-ids
  (map string->number
   (parse-postgresql-array-string derivation_ids
-(list output-name
-  path
-  hash-algorithm
-  hash
-  recursive
-  (append (if (memq base-derivation-id
-parsed-derivation-ids)
-  '(base)
-  '())
-  (if (memq target-derivation-id
-parsed-derivation-ids)
-  '(target)
-  '()))
+`((output-name . ,output-name)
+  (path . ,path)
+  ,@(if (string? hash-algorithm)
+`((hash-algorithm . ,hash-algorithm))
+`((hash-algorithm . (
+  ,@(if (string? hash)
+`((hash . ,hash))
+`((hash . (
+  (recursive . ,(string=? recursive "t"))
+  ,(append (if (memq base-derivation-id
+ parsed-derivation-ids)
+   '(base)
+   '())
+   (if (memq target-derivation-id
+ parsed-derivation-ids)
+   '(target)
+   '()))
(exec-query conn query)))
 
 (define (derivation-inputs-differences-data conn
@@ -202,16 +206,16 @@ INNER JOIN derivations ON derivation_outputs.derivation_id = derivations.id
   (let ((parsed-derivation-ids
  (map string->number
   (parse-postgresql-array-string derivation_ids
-  (list derivation_file_name
-derivation_output_name
-(append (if (memq base-derivation-id
-  parsed-derivation-ids)
-'(base)
-'())
-(if (memq target-derivation-id
-  parsed-derivation-ids)
-'(target)
-'()))
+`((derivation_file_name . ,derivation_file_name)
+  (derivation_output_name . ,derivation_output_name)
+  ,(append (if (memq base-derivation-id
+ parsed-derivation-ids)
+   '(base)
+   '())
+   (if (memq target-derivation-id
+ parsed-derivation-ids)
+

Re: A "cosmetic changes" commit that removes security fixes

[Léo Le Bouter]

On Mon, 2021-04-26 at 17:23 +0200, Tobias Geerinckx-Rice wrote:
> Hi Léo,
> 
> > https://git.sr.ht/~lle-bout/guix/commit/a045a48dd961f0c5c3d536dcc3fd21d9c08d2d50
> > https://git.sr.ht/~lle-bout/guix/commit/6477daa338fbf1c9edacfc3690aca77cacfe0008
> > 
> > Can you please explain what went wrong here?
> 
> Is a reasonable question, shared by all of us, not just Mark.  The 
> constructive way forward is to answer it fully.  It's in your best 
> interest to do so.
> 
> Kind regards,
> 
> T G-R

I am sorry, I will not. It's evident nothing went wrong and Mark is not
asking questions that are beneficial to anyone here besides
contributing to public shaming of people. The fix is already pushed and
thank you to the person that made it and Mark for identifying the
issue, however I don't say thank you for trying to publicly shame
people on the mailing list, both Raghav and me. At best there was an
oversight (like there's many in various commits made everyday to GNU
Guix) where I assumed the latest version of software would contain all
security fixes (as I tend to consider GNONE software such as cairo is
well maintained upstream security-wise, seems not), I don't think
there's anything more to add. I find Mark's way of communicating about
these issues not constructive and unfriendly. I think that if Mark or
anyone else's expect me to answer I think they should not phrase
criticism in a way that they accuse me or anyone else of having made a
mistake. I don't think we should find who is responsible for mistakes,
we could however ask advice on what happened to fix the mistake in case
the person that introduced it cannot. And to ever think I would act in
bad faith towards GNU Guix security when I spent entire weeks checking
and patching CVEs full time, I don't think that would make sense.

On Mon, 2021-04-26 at 19:21 +0200, Ludovic Courtès wrote:
> Hi Léo,
> 
> Tobias Geerinckx-Rice  skribis:
> 
> > > 
https://git.sr.ht/~lle-bout/guix/commit/a045a48dd961f0c5c3d536dcc3fd21d9c08d2d50
> > > 
https://git.sr.ht/~lle-bout/guix/commit/6477daa338fbf1c9edacfc3690aca77cacfe0008
> > > Can you please explain what went wrong here?
> > 
> > Is a reasonable question, shared by all of us, not just Mark.  The
> > constructive way forward is to answer it fully.  It's in your best 
> > interest to do so.
> 
> I concur.  Please reply as soon as you can so we can understand what
> happened, restore trust, and collectively avoid such pitfalls in the
> future.
> 
> Thanks in advance,
> Ludo’.

I don't understand how trust would be lost.

Léo


signature.asc
Description: This is a digitally signed message part

Re: A "cosmetic changes" commit that removes security fixes

[Leo Famulari]

On Mon, Apr 26, 2021 at 07:06:33PM +0200, Giovanni Biscuolo wrote:
> Just to understand: /if/ at any point in time a user is able to afford
> the effort to build the entire core-updates /or/ staging branch she
> should be confident the result is state-of-the-art secure.  Am I wrong
> with this assumption?

Unfortunately your assumption is incorrect.

We do not apply security updates to the core-updates branch, except what
comes via `git merge master`, which only happens in the final stages of
the cycle.

Core-updates is not expected to be "buildable", let alone "secure",
until the end of the core-updates cycle when we start to whip it into
shape.

That branch is just a place to push updates of core packages, so that we
don't duplicate effort or lose track of updates.

Nevertheless, we should never remove security patches without a
corresponding package update, done in a single atomic commit. That's not
how we work.

If there is some documentation or messaging that suggests that anyone
should ever use the core-updates branch, please let us know and we will
fix that. The only branch you should use is the master branch, unless
you are testing something as a developer
  
> Leo Famulari  writes:
> > I do think that Mark is being hyperbolic about the wip-gnome branch. The
> > name says "work in progress" and we don't hold those branches to a high
> > standard.
> 
> I understand your point but please consider that /unless/ a wip-branch
> is private (or privately shared out-of-Guix-git) that branch it's a
> pubblic collective work in progress and sometimes (seldom? often? I
> really don't know) that work could be completed by someone else, so even
> in wip- branches committers should exercise some degree of discipline,
> especially when dealing with "commit message completeness" and more with
> security related patches.  In other words, IMHO a certain degree of
> safety must be assured also on wip- branches.
> 
> Probably the policy about wip-branches, whatever it is ("do what you
> want" or something in line with my comments above), should be documented
> in the contributing section of the Guix manual.

I did not mean to suggestthat wip-* branches should not be secure but,
again, they are only works in progress. They do not even have a stable
Git history, due to rebasing, which breaks the Guix code authentication
mechanism. So, if you try to use them, you will have to use `guix pull
--allow-downgrades` and then all bets are off in terms of security.

These branches are merely a way for developers to share their work with
each other.

> OK but please consider that /if/ Guix cannot "update GNOME in Guix" for
> whatever reason, GNOME should not be updated.

I don't understand this. It seems tautological that if we cannot update
GNOME, then GNOME should not be updated.


signature.asc
Description: PGP signature

Re: A "cosmetic changes" commit that removes security fixes

[Ludovic Courtès]

Hi Léo,

Tobias Geerinckx-Rice  skribis:

>> https://git.sr.ht/~lle-bout/guix/commit/a045a48dd961f0c5c3d536dcc3fd21d9c08d2d50
>> https://git.sr.ht/~lle-bout/guix/commit/6477daa338fbf1c9edacfc3690aca77cacfe0008
>> Can you please explain what went wrong here?
>
> Is a reasonable question, shared by all of us, not just Mark.  The
> constructive way forward is to answer it fully.  It's in your best 
> interest to do so.

I concur.  Please reply as soon as you can so we can understand what
happened, restore trust, and collectively avoid such pitfalls in the
future.

Thanks in advance,
Ludo’.

Re: Another misleading commit log (was Re: A "cosmetic changes" commit that removes security fixes)

[Ludovic Courtès]

Hi Mark,

Mark H Weaver  skribis:

> Léo Le Bouter  writes:
>
>> On Thu, 2021-04-22 at 13:40 -0400, Mark H Weaver wrote:
>>> This commit was digitally signed and pushed to the 'wip-gnome' branch
>>> by
>>> Raghav, but it's also "Signed-off-by: Léo Le Bouter", so I'm not sure
>>> who bears primary responsibility for this one.
>>
>> It seems you are more focused and spend more time sending accusations
>> here than collaboratively working to improve GNU Guix. I don't feel
>> like that's something great to do at all.
>
> I feel an obligation to protect our users, and among other things that
> means calling attention to Guix committers that are doing things like
> pushing commits with misleading commit logs (which evade proper review)
> and pushing "cosmetic changes" that remove security fixes.

That you called attention on these issues is a great service to all of
us, Mark.  But I have to agree with Ricardo: the harsh accusatory tone
towards Raghav and Léo was not warranted; please assume good faith.

Thanks,
Ludo’.

Re: A "cosmetic changes" commit that removes security fixes

[Giovanni Biscuolo]

Hello Guix,

Leo Famulari  writes:

[...]

> And in the case of GNOME, we have already fallen short of our goals
> several times, having missed multiple upgrades.

I regret not to be able to contribute more to Guix, but please nobody
should feel guilty not to be able to keep-up with upstream's upgrading
rate (whatever rate it is), better safe than up-to-date :-)

> I too have felt the temptation to cut corners with Git when I know that
> the final result will be "okay". But Guix is not just about the final
> product (a release, or a merge). We also have the --commit option to
> Guix commands, and `guix time-machine`. So the Git history is important
> too.

Yes, please this should be stressed: Guix *is* it's official (master,
core-updates...) git repo branches.

Just to understand: /if/ at any point in time a user is able to afford
the effort to build the entire core-updates /or/ staging branch she
should be confident the result is state-of-the-art secure.  Am I wrong
with this assumption?

> And I have also spent several hours at a time, focused on completing
> (after several restarts) a complicated rebase involving dozens of
> commits. And I've done that many times.

I think this is the most expensive activity of Guix maintainers, for the
very reason that Guix *is* git

> I do think that Mark is being hyperbolic about the wip-gnome branch. The
> name says "work in progress" and we don't hold those branches to a high
> standard.

I understand your point but please consider that /unless/ a wip-branch
is private (or privately shared out-of-Guix-git) that branch it's a
pubblic collective work in progress and sometimes (seldom? often? I
really don't know) that work could be completed by someone else, so even
in wip- branches committers should exercise some degree of discipline,
especially when dealing with "commit message completeness" and more with
security related patches.  In other words, IMHO a certain degree of
safety must be assured also on wip- branches.

Probably the policy about wip-branches, whatever it is ("do what you
want" or something in line with my comments above), should be documented
in the contributing section of the Guix manual.

> But what happened on core-updates *must not happen again*.

Please no.

> For a task as large as "updating GNOME in Guix", history tells me that
> it has to be a group effort. In many cases, the hardest part of a
> project is coordination and leadership, not coding. I hope that this
> current effort continues, and that more people decide to join.

OK but please consider that /if/ Guix cannot "update GNOME in Guix" for
whatever reason, GNOME should not be updated.


Thanks! Giovanni.

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: Jam: which licence is this?

[Leo Famulari]

On Sun, Apr 25, 2021 at 04:37:42PM -0400, Mark H Weaver wrote:
> However, I think that longstanding practice is orthogonal to the
> question of whether licenses covering build system components can be
> omitted from the 'license' field.
[...]
> Specifically, I'm objecting to the idea that the 'license' field need
> only describe the files present in the build outputs.  For example, if a
> hypothetical package is licensed under Expat but uses a build system
> covered by the the Q Public License (QPL), I don't think we can omit
> mention of the QPL just because those components are only used during
> the build.
> 
> Does that make sense?

I think I understand what you are suggesting.

However, there is no precedent in Guix for mentioning the licenses of
build system components in package definitions.

I'd guess that almost every single package in Guix would need several
new licenses added to its field, and that field would become useless for
conveying the license of the program itself.


signature.asc
Description: PGP signature

Re: A "cosmetic changes" commit that removes security fixes

[Tobias Geerinckx-Rice]

Hi Léo,


https://git.sr.ht/~lle-bout/guix/commit/a045a48dd961f0c5c3d536dcc3fd21d9c08d2d50
https://git.sr.ht/~lle-bout/guix/commit/6477daa338fbf1c9edacfc3690aca77cacfe0008

Can you please explain what went wrong here?


Is a reasonable question, shared by all of us, not just Mark.  The 
constructive way forward is to answer it fully.  It's in your best 
interest to do so.


Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: A "cosmetic changes" commit that removes security fixes

[Léo Le Bouter]

On Sat, 2021-04-24 at 03:46 -0400, Mark H Weaver wrote:
> Hi Léo,
> 
> Léo Le Bouter  writes:
> 
> > On Fri, 2021-04-23 at 15:18 -0400, Leo Famulari wrote:
> > > Léo and Raghav, you need to keep learning our workflow around
> > > security updates.  It's not okay to remove security patches and
> > > later
> > > update a package to a fixed version in a different commit. `git
> > > rebase` is the tool to learn for cases like this one.
> > 
> > I knew about this but I didnt feel like telling Raghav to do yet
> > another rebase. I felt like Raghav was taking on with so much
> > already.
> 
> This response is what native English speakers call a "red herring"
> ;: something that misleads
> or
> distracts from a relevant or important question.
> 
> Why do I say that?  As I pointed out elsewhere in this thread,
> 
>   https://lists.gnu.org/archive/html/guix-devel/2021-04/msg00366.html
> 
> it appears that Raghav didn't actually remove the security fixes; it
> appears that *you* did.  Therefore, I fail to see how it could have
> been
> avoided by asking Raghav to do another rebase.
> 
> From the IRC logs cited in the message above, it appears that you
> took
> the liberty of modifying Raghav's "cosmetic changes" commits to also
> remove security fixes in the re-indented packages, while claiming in
> the
> summary lines that you were "ungraft[ing]" cairo and glib.
> 
>   
> https://git.sr.ht/~lle-bout/guix/commit/a045a48dd961f0c5c3d536dcc3fd21d9c08d2d50
>   
> https://git.sr.ht/~lle-bout/guix/commit/6477daa338fbf1c9edacfc3690aca77cacfe0008
> 
> Can you please explain what went wrong here?
> 
>   Thanks,
> Mark
> 

Hello Mark,

I will not answer anything to you anymore because I feel like you do
not write messages in a constructive way.

Léo


signature.asc
Description: This is a digitally signed message part

Re: Jam: which licence is this?

[Jack Hill]

On Sun, 25 Apr 2021, Jack Hill wrote:


I have asked the FSF licensing lab about this in RT #1718940


I've also asked OSI: 
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2021-April/005139.html


Best,
Jack

Re: licensing problem with "On Lisp" and code from a github gist

[Giovanni Biscuolo]

Hi Pierre,

thank you for your heads up!

Pierre Neidhardt  writes:

> A quick search got me this:
>
> https://github.com/DalekBaldwin/on-lisp/blob/master/on-lisp.asd
>
> So it seems that the license is an informal

Yes, the same it's for Weir (bug#47943), informal non-free license

[...]

> Not sure what to make of it.
>
> I've heard of a few libraries that implement some "On Lisp" algorithms,
> but I suppose we would need to look in details.
>
> Maybe ask on r/lisp or r/common_lisp.

Or maybe better on licens...@fsf.org

Thanks! Giovanni

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: Outreachy - Guix Data Service: questions about improving the data for derivation comparisons.

[Christopher Baines]

Luciana Lima Brito  writes:

> Your advices helped me think more clearly.

Great :)

> There was no need to create or modify structures other than what I was
> already changing. I now return an alist instead of a list on the
> derivation-differences-* functions on comparison.scm (for outputs,
> inputs and sources). It helped to simplify the mapping on
> controller.scm. The changes on html.scm were minimal, basically it is
> matching on pairs, instead of single values.
>
> Two questions:
>
> 1 - The match on the html expects 5 values for "outputs", so I had to
> settle on using empty objects on the JSON, when needed, else it would
> break the match on the html. Is it ok?

So, one advantage of alists over lists is that the code is probably less
brittle when adding elements say, since code parsing the list will
probably break with a new element, but this is probably less likely to
happen with an alist.

However, this will happen with an alist if match is used to pick
elements out. I'd suggest using assq-ref or similar to pluck elements
out.

> 2 - Now on controller.scm "outputs", "inputs", "sources", and even
> "arguments" have the same structure, which is an alist of the form:
>
>   ((base . (...))
>(target . (...))
>(common . (...)))
>
> and I'm using the same map and match-lambda code to process them,
> wouldn't it be reasonable now to make it a local function?

I'd consider these options first probably:

 - Could the data coming from derivation-differences-data have vectors
   where appropriate already? The HTML code would probably need to be
   adjusted, but I think that's fine.

 - Could this be written in a form like:

   ,@(map (lambda (name)
   ...)
  '(outputs inputs sources arguments))


signature.asc
Description: PGP signature