Re: [Proposal] The Formal Methods in GNU Guix Working Group

[Amin Bandali]

Hello Guix!

Thank you Brett for taking initiative and putting this awesome proposal
together on all our behalves, and to everyone else for chiming in and
expressing your interest and support!

To share some of my (scattered) thoughts on this, as a researcher I
think reproducible and verifiable research is a crucially important
topic, yet traditionally and often a neglected one.  Throughout my
graduate studies, too many times I stumbled on papers with interesting
claims that I sadly could not reproduce or easily verify for myself.
And I think this is especially ironic and painful for those of us doing
research in formal methods, computing science, and software engineering;
and is where projects like GNU Guix with their awesome efforts in
reproducibility could act as role models and show what's possible.

For instance, for better or worse many of the tools I have worked with
over the last few years are primarily implemented in Java, often in form
Eclipse plugins.  Suffice to say that release management, bundling, and
distribution practices of most of these tools leave a lot to be desired.
As part of the Formal Methods in GNU Guix Working Group, I'd love for us
to try and get in touch with the developers of these tools and offer to
work with them to challenge and improve the status quo, resulting
ultimately in more readily and easily accessible tools, greatly useful
for verifying and reproducing existing literature.

As Brett and I alluded to, there's a large variety of tasks in all
shapes and sizes that could use your help, from more "researchy" work
like writing a bootstrapping SML '97 compiler, or exploring synthesis
and verification for GNU Guile and GNU Guix, to less researchy ones like
packaging (even more) formal methods-related software and helping their
developers improve their release and package qualities.

We would love to hear more from you about this in trying to gradually
put together actionable plans.  If you'd like to chat with us, please
come say hi to us in the #guix IRC channel on freenode.  My nick there
is bandali, and Brett is brettgilio.

Best,
amin


signature.asc
Description: PGP signature

Re: extending the documentation of the Scheme API

[Jesse Gibbons]

On Fri, 2019-12-20 at 23:17 +0100, Ricardo Wurmus wrote:
> Hi Guix,
> 
> we have lots of nice macros and procedures in Guix that aren’t
> documented beyond their docstrings.
> 
> Should we snarf the docstrings and add them to the manual?
> 
> --
> Ricardo
> 
> 
I don't care where it goes, but is there maybe a better place than the guix
manual?

Am I alone in thinking it makes sense to produce a "guix api reference
manual"? The guix manual is already fairly large. We can treat the guix
manual as a manual for setting up guix and using it from a shell, the guix
api reference manual as a reference for `guix repl` and more complex package
and service production.

This is just something I think we should consider.

Re: extending the documentation of the Scheme API

[John Soo]

Hi Ricardo,

Yes! I think that would really emphasize the hackability of Guix. 

- John

Re: Authenticating Git checkouts: step #1

[zimoun]

Hi Ludo,

To be honest, I do not clearly understand what the issue is concretely
about. So I am probably out-of-scope and/or irrelevant.

One milestone could be to have Git tags and "guix pull" would 'jump'
between these tags. For an end-user like me, tags ease:
 a. the commit range specification (#1)
 b. memorize what I have already verified (#6)

Moreover, it would feed a variant of OPAM path or Qubes path as you
summarized here [1] or mitigate attacks if I understand the answers
there [2] or [3].

[1] https://issues.guix.info/issue/22883#12
[2] https://issues.guix.info/issue/22883#15
[3] https://issues.guix.info/issue/22883#26


Thank you for all this work.

All the best,
simon

Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

[zimoun]

Hi Arne,

First, do not take me wrong, I am not "fighting" or not going to an
"heated debate".
I am fine and I hope you are also fine.
As I said my opinion in other emails, I am not repeating here. Well, I
am not convinced it is the good one, but as I trust collective power,
I am sure Guix will find the best consensus. I am even calling since
the very beginning of this discussion to collect opinions from the
other fellow hackers.


Expressing the feelings is better than bitterness. Therefore I express
mines. :-)
I could send that privately because I am not sure it deserves to be
public. But let wash the laundry in family (translation from French
expression ;-))


On Sat, 21 Dec 2019 at 00:02, Arne Babenhauserheide  wrote:

> > Konrad's example. So, nothing new on the table; except you are
> > starting to throw "feelings" with the "traumatic change" words.
>
> I do not see this as feelings, but as strategy. That’s what the article
> is about: Many small breakages add up, and repeated changes to
> best-practices also add up.

Just to be on the same wavelength, traumatic means in the Collins
Dictionnary: "A 'traumatic' experience is very shocking and upsetting,
and may cause psychological damage."

https://www.collinsdictionary.com/dictionary/english/traumatic

Well, to me it could make sense in the context of the mentioned blog.
Even if I feel this very opinionated. Not to say it could hurt me; bah
I am a big boy, that's ok.

Again, to be on the same wavelength, the blog says: "The result has
been hugely divisive and intimately familiar to anyone who works with
Python, creating massive rifts in the community and wasting millions
of hours of engineer time addressing. This kind of “strong” trauma is
fairly easy to spot in advance."

Well, I understand when speaking about Python. Are we comparing the
number of Guix users with the number of Python users? Are we comparing
the number of changes between Python 2 and 3 with the change of the
default "guix environment foo"? And not all the "guix environment"
behaviour, only a specific case.

Ok, maybe we are talking about the other trauma. The blog explains:
"Since nothing has actually broken with this change, the effects are
more subtle than with strong traumatic changes." and then "The
opportunity to solve this problem by rewriting with asyncio in mind,
however, also presents me a chance to rewrite in anything else, and
reevaluate my choice of Python for the project entirely."

I am sorry, I do not understand. I am probably too dumb. On one hand,
the issue of "guix environment" is the very backward compatibility so
are we really talking about this second "trauma"? On the other hand,
because "guix environment" will be better and users probably need to
rethink how they use Guix, then they will fully drop Guix.


Maybe "feelings" (quoting, in citation quoted too) is not the right
word. My point is all is vague. Example: I have the feeling that my
students(*) do not like Scheme; do I need to switch next year to
another language? Then do I make my decision based on my feelings?
based on the feelings of the students who are retaking the year (could
be shocked)? Me, I will make my decision based on: how many students
failed? what do they understand? what could be better for all the
students? what could be a better language? what is the ratio between
the new student vs the retaking ones? how many length the Scheme
textbook is? etc. Well, analogy is just analogy.


Well, that's it. I expressed what it appears to me a trail going
nowhere. Let move forward and put energy in "backward compatibility"
discussion: does Guix want? what does it imply? which level? etc. for
example, your interesting input "GUIX_ENVIRONMENT_STABLE=1".

All the best,
simon

(*) hypothetical, I do not have real students, even if I teach a bit.
And we use Python as introduction to implemented algorithms after 1
year fighting to switch from C. Whatever! :-)

Re: Ansible and GuixOps questions

[rchar01]

Thanks.

When I wrote 'GuixOps', I meant tools that could replace Ansible.
I am aware of 'guix deploy'. Is Guix currently providing other
tools that could help?

"
- would it be possible to generate a guile script (for GuixOps)
from Ansible?
- would it be possible to change the Ansible to talk to the Guix
(or GuixOps) system?
"

I meant the ability to generate a script for the Guix system
configuration and / or guix deploy from existing Ansible
configurations.
Do you think that creating an intermediate program that converts
Ansible configuration to Guix will be problematic?

A few words of explanation.
I would like to transfer my current infrastructure (configurations
in Ansible) to Guix and I was wondering about the possibilities.

Thanks for all the answers.

Regards,
Robert.


‐‐‐ Original Message ‐‐‐
On Thursday, December 19, 2019 10:13 PM, Thompson, David 
 wrote:

> Hello Robert,
>
> On Mon, Dec 16, 2019 at 6:57 AM rchar01 rcha...@protonmail.com wrote:
>
> > Probably many admins / DevOps are heavily using Ansible. I also use this 
> > solution to configure systems and services (on Debian and CentOS).
> > I would like to transfer infrastructure to the Guix System and some 
> > questions arose:
> >
> > -   is there any way to combine Ansible and GuixOps?
>
> In short, no. I'm assuming that "GuixOps" means 'guix deploy', which
> is its own special tool that would take the place of Ansible if you
> choose to use it.
>
> > -   is there any way to continue using Ansible to configure Guix (some in 
> > guile script and some in ansible)?
>
> In the past I've used Chef (very similar to Ansible) to install Guix
> on Ubuntu machines. You could do the same with Ansible. If you wish
> to deploy systems running Guix System proper, I think that's possible,
> too, but you'd have to do some work on your own. You would have to
> build yourself a base image of a barebones Guix system and run your
> Ansible scripts from that base. I imagine that Ansible would be
> little more than a thin layer for running 'guix system reconfigure
> system.scm' on a remote machine at that point.
>
> > -   would it be possible to generate a guile script (for GuixOps) from 
> > Ansible?
>
> Sorry, I don't quite understand this. Maybe?
>
> > -   would it be possible to change the Ansible to talk to the Guix (or 
> > GuixOps) system?
>
> Need more clarity here as well. Seems like a duplicate of your second
> question??
>
> > Rewriting to Guile (Guix config files):
> >
> > -   Against:
> > ** time consuming
> > ** may require new skills
> > ** only for Guix, Ansible can configure other GNU / Linux systems
> >
>
> If you're already using Ansible for everything, then yes it would be a
> hard sell to switch to something Guix specific, but Guix tools offer
> features that no mainstream tools could ever hope to offer. As I said
> earlier, though, you could make a Guix + Ansible mix work if you want.
>
> > -   What might the benefits be?
>
> One of the big benefits is getting to use the Guix tooling and
> libraries for system deployment in addition to packaging and system
> configuration which many people already use. For people who are used
> to Guix, it's relatively easy to use 'guix deploy' whereas it would be
> very difficult to use something else. Another reason is that Ansible
> is, frankly, not a very good tool from our point of view. Ansible's
> model is "start from a base image and mutate it into the system you
> want." If you're into reproducibility, this isn't great. How was the
> base image created? Will running the same Ansible scripts a day from
> now produce the exact same image, bit for bit? Almost certainly not.
> Ansible is already mostly redundant with 'guix system' because that
> tool takes care of all the configuration management chores. What is
> not covered by 'guix system' is remote system management, thus 'guix
> deploy' was created. It takes things further by helping you deploy the
> same system configurations you use with 'guix system' to many remote
> systems. 'guix deploy' is still very new and doesn't have a lot of
> features, but it's built on the right foundation to avoid the big
> issues with mainstream devops tools.
>
> Hope this helps,
>
> -   Dave

Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

[Arne Babenhauserheide]

Hi zimoun,

zimoun  writes:
> Konrad's example. So, nothing new on the table; except you are
> starting to throw "feelings" with the "traumatic change" words.

I do not see this as feelings, but as strategy. That’s what the article
is about: Many small breakages add up, and repeated changes to
best-practices also add up.

The volatile software article describes that software differs in how
much work it is to keep using it. The traumatic change article discusses
one aspect why people stop using projects.

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: [Outreachy GSoC] 2020 round

[Christopher Baines]

Gábor Boskovits  writes:

> Outreachy
>
> Applications for the May to August 2020 round will open on January 22 16:00 
> UTC.
>
> As far as I know prospective applicants for Outreachy should file
> their initial application well before the projects are announced.
>
> Also, I believe we have four proposals two of them in great shape from
> the previous round:
> 1. Guix Data Service internationalization support
> 2. netlink wrapper in guile, and a better static networking service for guix
>
> There were also two ideas:
> 1. Exporting metrics from cuirass and the guix daemon for monitoring,
> and for possible use by the data service.
> 2. Guix installer accessibility improvements.
> ---
> GSoC
>
> According to the GSoC timeline:
> Mentoring organizations begin on Jan. 14. 19:00 UTC.
> And the mentoring organization application deadline is: Feb. 5. 19:00 UTC.
> https://developers.google.com/open-source/gsoc/timeline
>
> As earlier, Guix intends to participate under the GNU umbrella.
>
> We have this GSoC ideas page:
> https://libreplanet.org/wiki/Group:Guix/GSoC-2019
> 
>
> Could someone help me clarify what project ideas are still alive and
> have a prospective mentor?

Internationalization support in the Guix Data Service is something that
still needs doing, and I'm still available and interested in mentoring
for this (or something else Guix Data Service related) in either
Outreachy or GSoC.


signature.asc
Description: PGP signature

extending the documentation of the Scheme API

[Ricardo Wurmus]

Hi Guix,

we have lots of nice macros and procedures in Guix that aren’t
documented beyond their docstrings.

Should we snarf the docstrings and add them to the manual?

--
Ricardo

Authenticating Git checkouts: step #1

[Ludovic Courtès]

Hello Guix!

It’s high time for us to provide a means to authenticate Git checkouts.
It’s not clear what the perfect solution will be, so in the meantime I
think we need to have reasonable milestones that incrementally improve
the situation.

To begin with, I propose the attached script: when given a commit range,
it authenticates each commit, meaning that it ensures commits have a
valid signature and that that signature was made by one of the
authorized keys.  Sample session:

--8<---cut here---start->8---
$ time ./pre-inst-env guile -e git-authenticate build-aux/git-authenticate.scm 
d68de958b60426798ed62797ff7c96c327a672ac 
099ce5d4901706dc2c5be888a5c8cbf8fcd0d576
Authenticating d68de95 to 099ce5d (7938 commits)...
Signing statistics:
  BCA689B636553801C3C62150197A5888235FACAC   1454
  3CE464558A84FDC69DB40CFB090B11993D9AEBB5   1025
  BBB02DDF2CEAF6A80D1DE643A2A06DF2A33A54FA941

[...]

real2m21.272s
user1m38.741s
sys 0m59.546s
--8<---cut here---end--->8---

Limitations:

  1. People (developers) have to run it manually, there’s no suitable
 Git hook; ‘guix pull’ doesn’t run it.

  2. The list of authorized keys is hard-coded.

  3. It’s relatively slow (but faster than a shell script).

  4. It lazily populates a keyring (under
 ~/.config/guix/keyrings/channels/guix.kbx) by fetching keys from
 key servers, which may or may not have the keys.

  5. It doesn’t address roll-back attacks and other attacks described in
 
.

  6. It doesn’t memorize which commits have already been verified.

  7. I haven’t checked whether the hard-coded ‘%committers’ lists works
 for commits before v1.0.1—help welcome!

It should be possible to address #2 by adding the list in the repo
itself, though we’d need to check the cost of accessing that list at
every commit.

#3 can probably be addressed by using a Scheme implementation of the
OpenPGP bits we need, such as that of Industria.

#4 can be addressed by storing the keys in the repo itself, either as
files directly or with a trick like
.

#6 could be addressed by storing Git notes maybe.

#5 is hard IMO, but it’s one of the things we discussed at the R-B
summit, so there’s hope.

I’d like to commit this script under build-aux/ as a first step.

Thoughts?

Thanks,
Ludo’.

PS: See  for context.

;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2019 Ludovic Courtès 
;;;
;;; This file is part of GNU Guix.
;;;
;;; GNU Guix is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; GNU Guix is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Guix.  If not, see .

;;;
;;; Authenticate a range of commits.
;;;

(use-modules (git)
 (guix git)
 (guix gnupg)
 (guix utils)
 (guix i18n)
 (guix progress)
 (srfi srfi-1)
 (srfi srfi-11)
 (srfi srfi-26)
 (srfi srfi-34)
 (srfi srfi-35)
 (ice-9 match)
 (ice-9 format)
 (ice-9 vlist))


(define %committers
  ;; List of committers.  These are the user names found on
  ;;  along with
  ;; the fingerprint of the signing (sub)key.
  ;;
  ;; TODO: Replace this statically-defined list by an in-repo list.
  '(("andreas"
 "AD17 A21E F8AE D8F1 CC02  DBD9 F7D5 C9BF 765C 61E3")
("ajgrf"
 "2A39 3FFF 68F4 EF7A 3D29  12AF 6F51 20A0 22FB B2D5")
("alexvong1995"
 "306F CB8F 2C01 C25D 29D3  0556 61EF 502E F602 52F2")
("alezost"
 "4FB9 9F49 2B12 A365 7997  E664 8246 0C08 2A0E E98F")
("ambrevar"
 "50F3 3E2E 5B0C 3D90 0424  ABE8 9BDC F497 A4BB CC7F")
("apteryx"
 "27D5 86A4 F890 0854 329F  F09F 1260 E464 82E6 3562")
("arunisaac"
 "7F73 0343 F2F0 9F3C 77BF  79D3 2E25 EE8B 6180 2BB3")
("atheia"
 "3B12 9196 AE30 0C3C 0E90  A26F A715 5567 3271 9948")
("bavier"
 ;; primary: "34FF 38BC D151 25A6 E340  A0B5 3453 2F9F AFCA 8B8E"
 "A0C5 E352 2EF8 EF5C 64CD  B7F0 FD73 CAC7 19D3 2566")
("beffa"
 "3774 8024 880F D3FF DCA2  C9AB 5893 6E0E 2F1B 5A4C")
("benwoodcroft"
 "BCF8 F737 2CED 080A 67EB  592D 2A6A D9F4 AAC2 0DF6")
("biscuolo"
 

Accommodation for Guix Days

[Joshua Wirtz]

Dear all,

I am currently searching for accommodation for my first attendance to 
the Guix Days. As Pjort pointed out, there is the possibility to stay at 
the ICAB (http://www.icab.be/b_and_b_programme.php). Because I am still 
a student I would like to ask if there is someone interested in sharing 
a double bed room there, so we could share the costs?


With best regards,
Joshua Wirtz

[Outreachy GSoC] 2020 round

[Gábor Boskovits]

Outreachy

Applications for the May to August 2020 round will open on January 22 16:00 UTC.

As far as I know prospective applicants for Outreachy should file
their initial application well before the projects are announced.

Also, I believe we have four proposals two of them in great shape from
the previous round:
1. Guix Data Service internationalization support
2. netlink wrapper in guile, and a better static networking service for guix

There were also two ideas:
1. Exporting metrics from cuirass and the guix daemon for monitoring,
and for possible use by the data service.
2. Guix installer accessibility improvements.
---
GSoC

According to the GSoC timeline:
Mentoring organizations begin on Jan. 14. 19:00 UTC.
And the mentoring organization application deadline is: Feb. 5. 19:00 UTC.
https://developers.google.com/open-source/gsoc/timeline

As earlier, Guix intends to participate under the GNU umbrella.

We have this GSoC ideas page:
https://libreplanet.org/wiki/Group:Guix/GSoC-2019


Could someone help me clarify what project ideas are still alive and
have a prospective mentor?

Also is there any other idea we should take into consideration? Or
should we move any of the proposals between the internships?

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

[Ricardo Wurmus]

Konrad Hinsen  writes:

>> Maybe I miss a point. It is not: "watch out, this will do something
>> else in the future" but "watch out, this was doing something else in
>> the past and the change happened the  in ".
>
> Concrete example: I am writing a tutorial about using Guix for
> reproducible research. It shows several uses of "guix environment", some
> of them without '–add-hoc' or '–inputs-of'. I know my examples will
> cease to work in a few months. What am I supposed to do about this?

I wonder if we should simply bump the version number to indicate that
this is a breaking change?

Another more difficult option would be to do what responsible API
developers on the web do: to version their API and to make the API
version selectable.  I don’t know *how* to do this elegantly, and
there’s a real maintenance cost (it seems small in this case), but
configuration files can be used for changing new defaults.

--
Ricardo

Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

[Ricardo Wurmus]

zimoun  writes:

>  - I propose the name "guix shell"

This is not a bad idea, especially considering that “guix environment”
was meant to get shebang support, so that you could use it as the
interpreter in a script that handles the environment configuration.

It is also shorter.

--
Ricardo

Re: Ansible and GuixOps questions

[Pjotr Prins]

On Thu, Dec 19, 2019 at 04:13:18PM -0500, Thompson, David wrote:
> tool takes care of all the configuration management chores.  What is
> *not* covered by 'guix system' is remote system management, thus 'guix
> deploy' was created. It takes things further by helping you deploy the
> same system configurations you use with 'guix system' to many remote
> systems.  'guix deploy' is still very new and doesn't have a lot of
> features, but it's built on the right foundation to avoid the big
> issues with mainstream devops tools.

I am currently exploring how we can transition one package at a time
from existing deployment systems to 'guix system', i.e. a partial
deploy from a machine specification:

  http://git.genenetwork.org/pjotrp/guix-notes/src/branch/master/DEPLOY.org

I think I am close :). X-mas project.

Pj.

Re: qtwenengine anybody?

[mike . rosset]

Pierre Neidhardt  writes:

> Hmm... On second though, I just navigated GNU.org, which might not
> require GL acceleration.  I think I should try with a proper GL test website.


For me the GL issues will cause issues regardless of the website. For
example you can not scroll the page. But the symptoms may changed
depending on video drivers. Let know how this turns out.

Mike

Re: qtwenengine anybody?

[mike . rosset]

Pierre Neidhardt  writes:

> No problem on my end with an AMD RX 580.

This is surprising but good news none the less. Also I've mailed a
second in the series patch that fixes pulseaudio and address your
comments in the bug tracker. A substitute should be provided for this as
well.

Mike

Re: Bioconductor package flowPeaks license Artistic 1.0?

[Ricardo Wurmus]

zimoun  writes:

> This fix -- reuse all the free available code and replace the non-free
> one -- do not scale.
> So the question is: What is the scale we are talking about? How many
> packages in Bioconductor?
> If it is, say, a couple then it is doable. Or see with the people
> managing Bioconductor.
> If it is more, then the option is lobbying. :-)

In my experience tt happens rarely enough that it appears to scale just
fine.  Every time it happens is a drag, of course, but only a small
percentage of CRAN and Bioconductor packages suffers from problems like
that.  That’s still an estimated dozens of packages, but it’s not quite
as bad as it may seem.

--
Ricardo

Re: Guix and Bioconductor.

[Ricardo Wurmus]

Giovanni Biscuolo  writes:

> To all Guix interested in Bioconductor,
>
> forgive me if I raise this question here and not to "upstream", but IMHO
> this issue should escalate to Bioconductor and Guix community could do
> better than single package maintainers, zimoun in this case
>
> I'm not a user of Bioconductor packages so I have no "weight" on this
> matter, but I guess in Guix community there are **many** (potential?)
> users of Bioconductor packages: could you please organize a "pressure
> group" to convince Bioconductor be strict in their package acceptance
> rules?
>
> I fear flowPeacks will not be the last package with this kind licensing
> problems

It sure isn’t.  In the past I have tried to do a mass import from
Bioconductor and what slows me down the most is incorrect or non-free
licensing.  There are some packages that declare to be licensed under
Artistic 2.0, but then actually they contain data from databases that
do not permit commercial use.  Or they contain a copy of non-free tools,
or only work when those tools are present (e.g. kent tools, of which we
provide a package containing the few free tools).

It’s a pretty frustrating process to weed out these packages.

> Since «Bioconductor is committed to open source, collaborative,
> distributed software development and literate, reproducible research.» [1]

CRAN appears to be stricter about licenses (even though “strict” is
probably much too strong a word…).  Bioconductor people appear to care a
little less.

--
Ricardo

Re: Deprecating ‘guix environment’?

[zimoun]

Hi Konrad,


On Fri, 20 Dec 2019 at 12:18, Konrad Hinsen  wrote:

> My point of view (long form:
> https://hal.archives-ouvertes.fr/hal-02117588)
> is that software projects should adopt a backwards compatibility policy
> early on, state it clearly in their documentation, and stick to it. That
> prevents misunderstandings, bad surprises, and heated debates.

Thank you for the pointer. I have not read yet.
I agree with the compatibility policy and this argument has been
raises in the "heated" debate with Arne. :-)


> As for what that policy should be for Guix, that's a more difficult
> story. For projects with versioned releases, I like the principles

The first idea which comes in mind is to introduce a pledge. Maybe in
the introduction.

"The Guix project pledges to keep backward compatibility... blabla".

However, the real question is at which level.
At the CLI level? At the exported scheme functions? All modules or
specific ones?


> of semantic versioning, but Guix is more of a rolling-release
> project. (Test question: does anyone know what the current Guix version
> number is? Does anyone care?) I am not aware of any good precedents
> in terms of policy for such projects.

I agree.

I proposed [1] to add "tags" in the meaning of "git tag". Initially,
to ease the navigation through the history when searching for
packages.
Re-hashing this "guix tag" or "guix pull --tag" proposal, one idea
could be to introduce tags, say v1.1, v1.2, v1.3 etc bumping the
version every X months, or after each core-update merge, or after
, then by default "guix pull" would update to the tags.
This adds "stability" because we could tag commits that we know are
stable (no "guix pull" break, etc.)

[1] https://lists.gnu.org/archive/html/guix-devel/2019-11/msg00513.html


> > The hard question then becomes: what do we call it?  I vote against
> > abbreviations.  :-)
> >
> > Also, what other goals would we set for that command?  How would we
> > frame it in the set of commands?
>
> I vote for discussing the second point before the first one. Names
> should reflect the functionality behind them.

The starting point seems:
 - https://lists.gnu.org/archive/html/guix-devel/2017-08/msg00300.html
 - what do you feel missing about "guix environment"?

Considering my use-case, I am mostly aligned with "The future of 'guix
environment'".



All the best,
simon

Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

[zimoun]

Hi Konrad,

On Fri, 20 Dec 2019 at 12:24, Konrad Hinsen  wrote:

> The problem is scripts circulating in public repositories, tutorials,
> etc. New users will find them and use them for inspiration. It's very
> discouraging to see examples from tutorials fail or do something weird.

As I said, I am not convinced because it lacks concrete examples.
Personally, I do not know Guix ressource outside the Guix ecosystem.


> The main precedent is the Python 2->3 transition. There are tons of
> GitHub repositories with Python code but no indication if it's 2, 3, or
> both. I even had to use one that executed with either 2 or 3, but gave
> different results. It takes a lot of motivation to persist.

Except that "guix environment" will raise warnings.
Whatever.


> For guix, there's the additional issue that we use the reproducibility
> of builds as an argument. Non-reproducible examples are then a bit of a
> credibility problem.

I agree.
I do not want to fight about "backward compatibility".


As I said, talking about "guix environment", my opinion is that the
cost of the change is low.
However, we cannot know this cost, only probe and estimate: using my
probings, I estimate the cost is low.

IMHO, in this case, there is 2 ways to make a decision:
 - more probings to estimate more precisely;
or
 - say: "no backward compatibility breakage"

I am fine with both. :-)
 - I report my use-case: no cost at all
 - I propose the name "guix shell"


However, I feel I have spent enough time and energy on this topic and
I feel a blocking situation so I will move forward to another topic.
:-)

All the best,
simon

Guix and Bioconductor.

[Giovanni Biscuolo]

To all Guix interested in Bioconductor,

forgive me if I raise this question here and not to "upstream", but IMHO
this issue should escalate to Bioconductor and Guix community could do
better than single package maintainers, zimoun in this case

I'm not a user of Bioconductor packages so I have no "weight" on this
matter, but I guess in Guix community there are **many** (potential?)
users of Bioconductor packages: could you please organize a "pressure
group" to convince Bioconductor be strict in their package acceptance
rules?

I fear flowPeacks will not be the last package with this kind licensing
problems

Tobias Geerinckx-Rice  writes:

> Zimoun,

[...]

>> The issue is that upstream has disappeared, as usual in scientific
>> software. Someone writes a piece of code then publishes a paper and
>> sometimes the requirement for publication is to be pushed in
>> mainstream collection of packages (Bioconductor in this case). But
>> the copyright holder does not maintain the code and instead write
>> another piece of code, try to publish a paper, etc.. Well the
>> Reproducibility of Science crisis.
>
> That is a shame.  And that while other scientists (like you) are 
> working hard to make research more ‘open’ and reproducible.

Since «Bioconductor is committed to open source, collaborative,
distributed software development and literate, reproducible research.» [1]

The main point here is that legal aspects are an **integral part** of
reproducible research and the freedom of the developer to choose the
"open source" license he prefer should be _guided_ so he does not
involuntary harm the Bioconductor commitment to reproducible research
(redistribution is part of reproducibility).

In short: since "Clarifies Artistic License" aka "Artistic License
(Perl) 1.0" [2] (FSF approved) exists since long ago *and* since
"Artistic License v1" is not FSF approved, Biocounductor team should not
accept provide a list of accepted licenses that allows all free software
distributions to redistribute the packages (we have one if they wish :-)
)

...and yes, this means that Bioconductor does not accept an OSI approved
"Open Source" license [3], one of the **very few** cases (the only one)
in wich OSI and FSF disagrees on licenses.

To be clear, I'm pretty **sure** that an author generally does not
understand the difference between "Artistic License v1" and "Artistic
License (Perl) 1.0" and all he wants is his package will be freely
redistributable. He should be guided, in this case by Bioconductor.

WDYT?

Thanks. Gio'

[...]

[1] https://bioconductor.org/about/

[2] https://opensource.org/licenses/Artistic-Perl-1.0

to be clear, the "diff" from Artistic License v1 is this clause
«8.Aggregation of this Package with a commercial distribution is
always permitted provided that the use of this Package is embedded;
that is, when no overt attempt is made to make this Package's
interfaces visible to the end user of the commercial
distribution. Such use shall not be construed as a distribution of
this Package.»

[3] Artistic License v.1 is OSI approved 
https://opensource.org/licenses/Artistic-1.0

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

[zimoun]

Hi Arne,


On Fri, 20 Dec 2019 at 02:37, Arne Babenhauserheide  wrote:

> > Or are you (maybe a bit) "overreacting" about the backward compatibility?
>
> I don’t think so. I am definitely reacting strongly, but that’s because
> breakages in Guix have already cost me the evenings of several weeks
> this year.
>
> But before I write anything more, I’d like to ask you to take a step
> back to breathe.
>
> We’re discussing a change in software. We disagree on the way forward,
> but I’m not attacking you as a person, and I hope it does not feel that
> way to you.
>
> If it does: This is not my intention. Please take a moment to sigh
> deeply, shake your head, relax, and smile — because that actually helps.
> It’s what I try to do when discussions get vexing.
>
> I am grateful that you’re taking up improvements in Guix, and there are
> situations where viewpoints are different. That is OK.


I am fine. :-)
Life is about managing disagreements.
And I am probably a typical grouchy French. ;-)

Well, if we go back in time, the story is:
 - the original author of "guix environment" is not happy with the
current behaviour and proposes a change (see "The future of 'guix
environment'").
 - life happens (v1.0) but not this change.
 - I am not happy with the current behaviour and other on IRC neither.
 - a plan to change is opened for discussions.

The first concern by Ludo is about the compatibility.
Then Konrad raises concrete examples.

At this point, my personal opinion is: the cost is low so the change can happen.
However, I agree with the "backward compatibility" issue and even I
propose a name for this "new" command: "guix shell".

Then you ask one question: "Should Guix be volatile software?" with
the subtitle "Software developers should avoid traumatic changes".
Nothing more.
Well, I answer you by trying to fill the gap. Note that "volatile
software" is the same argument than the Ludo's concern and the
Konrad's example. So, nothing new on the table; except you are
starting to throw "feelings" with the "traumatic change" words.

Then, your following answer is more about your feelings than concrete
examples. It is hard to know in advance how many scripts or use-cases
would be broken -- i.e., estimate the cost -- and a way is to probe;
say: "it will break X of my scripts" or "in my institute, X people use
"guix environment blabla" daily, so it is not an option", etc.
Otherwise, it is unproductive.

Well, instead of arguing about feelings because it is going nowhere or
at better a flame war about "backward compatibility", I prefer going
to spend my time elsewhere (still about Guix :-)).
I mean, I proposed, I said my opinion and I called to collect more
opinions. I feel I did my best on this front and other fronts deserve
proposals and fixes.


Kind regards,
simon

ps:
Note that I did a proposal which could be a path to reduce the burden
of "guix pull" breakage: adding tags. Feel free to comment.

https://lists.gnu.org/archive/html/guix-devel/2019-11/msg00513.html

Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

[Konrad Hinsen]

Hi Simon,

> Assuming "guix environment" would stay and following the proposed
> plan, you would need to add GUIX_ENVIRONMENT_DEPRECATED=1 on the top
> of your script. In this would not be a problem for travelling back in
> time.

The problem is not how I update my scripts - I can manage that, no
matter what it takes.

The problem is scripts circulating in public repositories, tutorials,
etc. New users will find them and use them for inspiration. It's very
discouraging to see examples from tutorials fail or do something weird.

The main precedent is the Python 2->3 transition. There are tons of
GitHub repositories with Python code but no indication if it's 2, 3, or
both. I even had to use one that executed with either 2 or 3, but gave
different results. It takes a lot of motivation to persist.

For guix, there's the additional issue that we use the reproducibility
of builds as an argument. Non-reproducible examples are then a bit of a
credibility problem.

Cheers,
  Konrad.

Re: Deprecating ‘guix environment’?

[Konrad Hinsen]

Hi Ludo,

> Clearly there’s a tension between that and keeping Guix open to changes.

That's indeed the main problem and here as elsewhere, it is often a
topic of heated arguments.

My point of view (long form:
https://hal.archives-ouvertes.fr/hal-02117588)
is that software projects should adopt a backwards compatibility policy
early on, state it clearly in their documentation, and stick to it. That
prevents misunderstandings, bad surprises, and heated debates.

As for what that policy should be for Guix, that's a more difficult
story. For projects with versioned releases, I like the principles
of semantic versioning, but Guix is more of a rolling-release
project. (Test question: does anyone know what the current Guix version
number is? Does anyone care?) I am not aware of any good precedents
in terms of policy for such projects.

> The hard question then becomes: what do we call it?  I vote against
> abbreviations.  :-)
>
> Also, what other goals would we set for that command?  How would we
> frame it in the set of commands?

I vote for discussing the second point before the first one. Names
should reflect the functionality behind them.

How about a unified command for constructing environments and profiles
declaratively? In other words, combine "guix environment" and the
declarative parts of "guix package". We could probably get rid of
the somewhat obscure "guix environment -r" in the process.

Cheers,
  Konrad.

Re: qtwenengine anybody?

[Pierre Neidhardt]

mike.ros...@gmail.com writes:

> I have a simple CPP for testing it can be found
> here. https://github.com/mrosset/testqt.
>
> for testing I use this enviroment.
>
> --8<---cut here---start->8---
> ./pre-inst-env guix environment  --ad-hoc qtbase qtwebengine qtdeclarative 
> qtwebchannel coreutils gcc-toolchain nss-certs
> --8<---cut here---end--->8---
>
> and then I test with
>
> --8<---cut here---start->8---
> cd testqt
> qmake
> make
> ./main
> --8<---cut here---end--->8---

This worked for me.

> or there are hardware acceleration problems
>
> --8<---cut here---start->8---
> QT_XCB_FORCE_SOFTWARE_OPENGL=1 ./main
> --8<---cut here---end--->8---

No problem on my end with an AMD RX 580.

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: Bioconductor package flowPeaks license Artistic 1.0?

[zimoun]

Hi Giovanni,


On Fri, 20 Dec 2019 at 10:28, Giovanni Biscuolo  wrote:

> zimoun  writes:
>
> [...]
>
> > The issue is really to be able to contact the author. And I am not
> > sure this person is even the copyright holder. (In some country, the
> > company/institute own the copyright even the code is not written in
> > office's hours.)
> >
> >
> > For example, 2 files contains:
>
> [...]
>
> > The most of the files claim:
>
> [...]
>
> > For example, how many packages in Bioconductor use the Artistic 1.0?
>
> Sorry you have to struggle with this tedious work of sorting out YALM
> (Yet Another Licensing Mess), but the first thing to do in this case is
> to have a list of licenses for each file/folder and see if there is a
> way to **workaround** the disappearing of upstream and if needed do some
> sort of _soft_ forking just to fix the missing licensing-bits
>
> If we are lucky enough maybe the 95% of this package is free and the
> remainging 5% easily replaceable with a free rewrite

1.
This is my hope for the package flowPeak. Because it blocks my workflow at work.
Now, this package is in a personal channel but nothing provides a
guarantee that this channel would not disappear so the paper I am
working on would not be easily reproducible (in theory and
principles).
Be in the Guix tree affords more chance.

2.
This fix -- reuse all the free available code and replace the non-free
one -- do not scale.
So the question is: What is the scale we are talking about? How many
packages in Bioconductor?
If it is, say, a couple then it is doable. Or see with the people
managing Bioconductor.
If it is more, then the option is lobbying. :-)




> P.S.: like Tobias, I suggest you not to spend time trying to appeal FSF
> on the Artistic Licence v.1 ;-)

I have used frenchy bad faith rhetoric argument. ;-)

As I said, if a couple on Bioconductor are Artistic 1.0, that's ok.
Otherwise, it is an issue.
Right now, there is too much *if*. :-)


Thanks,
simon

Perl modules dual licensing (was Re: Bioconductor package flowPeaks license Artistic 1.0?)

[Giovanni Biscuolo]

Hi zimoun

zimoun  writes:

[...]

> Where is the License of Perl 5 and below explicitly  defined? There is
> no pointer...

Ricardo pointed you to https://dev.perl.org/licenses/, that is a web
version of this 
https://perl5.git.perl.org/perl5.git/blob/HEAD:/README

Perl is dual licensed at least since 1994-10-17 (see the README history
[1]

> What I understand is: when the License of Perl 5

There is no "License of Perl 5", it is Perl 5 that is dual licensed

The same dual license scheme is usually (usually?!?) adopted by Perl
modules, at least those on CPAN
http://www.cpan.org/misc/cpan-faq.html#How_is_Perl_licensed

> and below is used, then the copyright holder chooses either the
> Artistic 1.0, either the GPL.  Then the License of Perl 5 and below is
> free but non-copyleft.

Since there is no "License of Perl 5" that license cannot be qualified
:-)

> Well, it appears to me a hack. I guess that there is a lot of Perl
> packages under Artistic 1.0 which seems an issue.

I don't know how many packages/modules are distributed only using
Artistic License 1.0, but please consider that as I said above that
*many* are dual licensed.

The fact that Perl modules are (must?) commonly dual licensed is
somewhat a mystery to me, but I do not care :-D

> So let create this License of Perl 5 and below saying: choose between
> Artistic 1.0 or GPL. And because you have this choice, everything is
> fine.
>
> I probably misread

No, you do not misread: dual licensing is used in many situation and is
non a "hack", it's the decision of the copyright holder to allow
different legal uses of the software

In this particular case, **fortunately** the dual licensing was adopted
"since the beginning" to fix the problems with Artistic License

[...]

Last things about names: since Oct 2019 [2] Perl 5 is Perl (Perl 4 is
gone long ago) and Perl 6 is Raku, so finally there is no more need to
say "Perl 5" :-)

Ciao! Gio'


[1] https://perl5.git.perl.org/perl5.git/history/HEAD:/README

[2] https://lwn.net/Articles/802329/

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: Bioconductor package flowPeaks license Artistic 1.0?

[Giovanni Biscuolo]

Hello zimoun,

zimoun  writes:

[...]

> The issue is really to be able to contact the author. And I am not
> sure this person is even the copyright holder. (In some country, the
> company/institute own the copyright even the code is not written in
> office's hours.)
>
>
> For example, 2 files contains:

[...]

> The most of the files claim:

[...]

> For example, how many packages in Bioconductor use the Artistic 1.0?

Sorry you have to struggle with this tedious work of sorting out YALM
(Yet Another Licensing Mess), but the first thing to do in this case is
to have a list of licenses for each file/folder and see if there is a
way to **workaround** the disappearing of upstream and if needed do some
sort of _soft_ forking just to fix the missing licensing-bits

If we are lucky enough maybe the 95% of this package is free and the
remainging 5% easily replaceable with a free rewrite

WDYT?

Sorry I cannot help you sorting out the licenses in this package (next
year I'm going to refactor my timetable for Guix... but this is another
story)

Thanks! Gio'

[...]

P.S.: like Tobias, I suggest you not to spend time trying to appeal FSF
on the Artistic Licence v.1 ;-)

-- 
Giovanni Biscuolo

Xelera IT Infrastructures