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

[Arne Babenhauserheide]

zimoun  writes:
> First, have you read the proposal?

Yes.

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

>> This is taking this a bit too easy. If I can no longer pull, because
>> that breaks my Emacs or Gnome, then Guix is broken for me: I can no
>> longer update my system without first adjusting my config.
>
> So you expect that we would push a patch changing "guix environment"
> and in the same time break "guix pull, isn't it?

No, this is an example which shows that being able to roll back does not
mean that there is no problem with breaking the way forward. Using only
old versions is often not an option. Just imagine running audio software
from 5 years ago on a system that only provides pulseaudio (or whatever
will come after it). Imagine using an old KDE DCOP-based automation
workflow on a dbus-system. You need to update the libraries you use to
get it working at all.

>> > Hum? I am not convinced that the cost would be high... Because 1. the
>> > number of people using Guix is not so high (yet!), so 2. I am almost
>> > sure we can name the people using "guix environment" in scripts ;-).
>>
>> I’m not so sure. Guix is already used in scientific workflows, and there
>> is existing third-party documentation about using `guix environment`.
>
> Please point me where.
> It will save me time instead of reinventing the wheel.

It was mentioned on this list.

For the scientific workflows, see https://hpc.guix.info/

>> And can you name the people using `guix environment` by searching
>> backwards in their bash history?
>
> So what would break?
> Your workflow: spending 5 minutes to read the warning message and then 
> pressing:
> C-a GUIX_ENVIRONMENT_DEPRACATED=1 guix environment 
> 
>
> (unfair and bitter; sorry!)

I’m sorry that this makes you bitter. This is not my intention.

I’ll answer without bitterness: The original environment does not spawn
instantly. It takes many minutes until it is ready. If I then have to go
back, find the warning (it’s likely that I’d miss it, because these are
things that work, and suddenly they break, which I’m likely to only
figure out when the followup steps don’t work) and run it again, that
often means that I’m out of time to do what I actually wanted to do.

Despite that: Yes, this is a viable way. It is one of the less painful
ones. Maybe avoid calling it "DEPRECATED" and instead give it a more
descriptive name that does not imply that it will go away.

Mercurial uses HGPLAIN=1 to say "I want the version which will never
change established API". Best practice is to always use that in scripts
— and that is a stable best practice. But this is also slow to receive
new features.

If the old way to use guix environment is intended to actually be legacy
only, then it could be a way forward to also provide
GUIX_ENVIRONMENT_STABLE=1 which gives an API that is guaranteed to never
change the meaning of options again *after the change that’s been
started to brew in 2017*.

That would be a purely append-only API then, and while it would break
once, it would prevent such changes for the future.

For PR it might be possible to state that with this change, guix
environment as a tool reaches version 0.99 (to be updated to 1.0 after
sufficient testing).

>> > And 3. the time to figure out what changed is really low -- especially
>> > with warnings and hints -- and "guix environment foo -- make" would
>> > return an error because of dependencies missing.
>>
>> It took me days to figure out the exact guix environment invocation that
>> allows me to build the tools for a paper I’m still working on. If that
>> breaks, that causes massive anxiety, because I then don’t know whether
>> I’ll find the time to fix it before I run into deadlines.
>
> Do you mean add GUIX_ENVIRONMENT_DEPRECATED=1 at the top of your script?

Yes, at every script. And remember to add it to every command I still
have in history.

>> > Other said, I do not see myself use-cases where the scripts using
>> > "guix environment" need to be robust for time-travelling -- the same
>> > script used with current, past and future Guix versions -- because as
>> > it was said elsewhere: "environment" can be seen like "temporary
>> > profile". And temporary means... well temporary. ;-)
>>
>> The 

Re: qtwenengine anybody?

[mike . rosset]

Pierre Neidhardt  writes:

> Sorry, still no substitute for me for the patch you've sent yesterday.

I tested with a couple of machines and it does server substitutes. maybe
now the substitute cache will have invalidated. or you can manual purge
/var/guix/substitutes.  Hopefully this resolves it self. If not I'm
going to have a new build soon that fixs pulseaudio and the other issues
you mentioned on the bug tracker.

>> --8<---cut here---start->8---
>> guix archive --export -r qtwebengine | ssh server guix archive --import
>> --8<---cut here---end--->8---
>
> Err... What do you mean with the above?  Did you paste the right
> command? 

I was not quite clear here. For me it's easier to build on
workstation. And then I'd like to export to my publish server. But
simply exporting and importing does cause the publish to server the
build as a substitute. Maybe this is not feasible or I misunderstand how
to do this.

>> If this passes make sure you have
>> #AF73C7321F90EA89AD29BBA14069EB8EF8F6410325E479F93DE4612F26478726#
>>
>> in
>> --8<---cut here---start->8---
>> /etc/guix/acl
>> --8<---cut here---end--->8---
>
> I do!
>
> I tried building it myself anyways, and it fails with
>
> [11690/14276] CXX 
> obj/third_party/blink/renderer/core/animation/animation/animation_jumbo_2.o
> FAILED: 
> obj/third_party/blink/renderer/core/animation/animation/animation_jumbo_2.o
> /gnu/store/x3jx25cd3q363mr7nbgzrhrv1vza6cf7-gcc-7.4.0/bin/g++ -MMD -MF 
> obj/third_party/blink/renderer/core/animation/animation/animation_jumbo_2.o.d 
> -DV8_DEPRECATION_WARNINGS -DUSE_UDEV -DUSE_AURA=1 -DUSE_NSS_CERTS=1 
> -DUSE_OZONE=1 -DNO_TCMALLOC -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD 
> -DSAFE_BROWSING_DB_LOCAL -DOFFICIAL_BUILD -DCHROMIUM_BUILD 
> -DFIELDTRIAL_TESTING_ENABLED -DTOOLKIT_QT -D_FILE_OFFSET_BITS=64 
> -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D__STDC_CONSTANT_MACROS 
> -D__STDC_FORMAT_MACROS -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 
> -DBLINK_CORE_IMPLEMENTATION=1 -DGL_GLEXT_PROTOTYPES -DUSE_GLX -DUSE_EGL 
> -DBLINK_IMPLEMENTATION=1 -DINSIDE_BLINK -DUSING_SYSTEM_ICU=1 
> -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_STATIC -DGOOGLE_PROTOBUF_NO_RTTI 
> -DGOOGLE_PROTOBUF_NO_STATIC_INITIALIZER -DHAVE_PTHREAD 
> -DSK_IGNORE_LINEONLY_AA_CONVEX_PATH_OPTS -DSK_HAS_PNG_LIBRARY 
> -DSK_HAS_WEBP_LIBRARY -DSK_HAS_JPEG_LIBRARY -DSK_SUPPORT_GPU=1 
> -DSK_GPU_WORKAROUNDS_HEADER=\"gpu/config/gpu_driver_bug_workaround_autogen.h\"
>  -DWTF_USE_WEBAUDIO_FFMPEG=1 -DSUPPORT_WEBGL2_COMPUTE_CONTEXT=1 
> -DWTF_USE_DEFAULT_RENDER_THEME=1 -DUSE_SYSTEM_LIBJPEG -DUSING_SYSTEM_ICU=1 
> -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_STATIC 
> -DWEBRTC_NON_STATIC_TRACE_EVENT_HANDLERS=0 -DGTEST_RELATIVE_PATH 
> -DWEBRTC_CHROMIUM_BUILD -DWEBRTC_POSIX -DWEBRTC_LINUX 
> -DABSL_ALLOCATOR_NOTHROW=1 -DNO_MAIN_THREAD_WRAPPING -DLIBXSLT_STATIC 
> -DUSE_SYSTEM_ZLIB=1 -I. -Igen -I../../3rdparty/chromium -Igen -Igen -Igen 
> -Igen -Igen -Igen -I../../3rdparty/chromium/third_party/khronos 
> -I../../3rdparty/chromium/gpu 
> -I../../3rdparty/chromium/third_party/libyuv/include -Igen -Igen -Igen -Igen 
> -Igen -Igen -Igen -I../../3rdparty/chromium/third_party/ced/src 
> -I../../3rdparty/chromium/third_party/protobuf/src 
> -I../../3rdparty/chromium/third_party/protobuf/src -Igen/protoc_out 
> -I../../3rdparty/chromium/third_party/boringssl/src/include 
> -I../../3rdparty/chromium/skia/config -I../../3rdparty/chromium/skia/ext 
> -I../../3rdparty/chromium/third_party/skia/include/c 
> -I../../3rdparty/chromium/third_party/skia/include/config 
> -I../../3rdparty/chromium/third_party/skia/include/core 
> -I../../3rdparty/chromium/third_party/skia/include/effects 
> -I../../3rdparty/chromium/third_party/skia/include/encode 
> -I../../3rdparty/chromium/third_party/skia/include/gpu 
> -I../../3rdparty/chromium/third_party/skia/include/images 
> -I../../3rdparty/chromium/third_party/skia/include/lazy 
> -I../../3rdparty/chromium/third_party/skia/include/pathops 
> -I../../3rdparty/chromium/third_party/skia/include/pdf 
> -I../../3rdparty/chromium/third_party/skia/include/pipe 
> -I../../3rdparty/chromium/third_party/skia/include/ports 
> -I../../3rdparty/chromium/third_party/skia/include/utils 
> -I../../3rdparty/chromium/third_party/skia/src/gpu 
> -I../../3rdparty/chromium/third_party/skia/src/sksl 
> -I../../3rdparty/chromium/third_party/angle/include 
> -I../../3rdparty/chromium/third_party/angle/src/common/third_party/base 
> -Igen/angle -I../../3rdparty/chromium/v8/include -Igen/v8/include 
> -I../../3rdparty/chromium/third_party/webrtc_overrides 
> -I../../3rdparty/chromium/third_party/webrtc 
> -I../../3rdparty/chromium/third_party/iccjpeg 
> -I../../3rdparty/chromium/third_party/ots/include 
> -I../../3rdparty/chromium/v8/include -Igen/v8/include 
> -I../../3rdparty/chromium/third_party/libxml/src/include 
> 

Re: Deprecating ‘guix environment’?

[zimoun]

On Thu, 19 Dec 2019 at 17:31, Ludovic Courtès  wrote:

> The hard question then becomes: what do we call it?  I vote against
> abbreviations.  :-)

"guix shell"?



Cheers,
simon

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

[zimoun]

Hi Arne,

First, have you read the proposal?
Or are you (maybe a bit) "overreacting" about the backward compatibility?


On Thu, 19 Dec 2019 at 22:39, Arne Babenhauserheide  wrote:

> zimoun  writes:

> > Guix is not a volatile software and will never be. Because it is
> > rooted in time-travelling.
> > The tools "guix pull --commit=", "guix  --manifest=", "guix
> > time-machine" or the "--roll-back" avoid to break what is currently
> > working.
>
> This is taking this a bit too easy. If I can no longer pull, because
> that breaks my Emacs or Gnome, then Guix is broken for me: I can no
> longer update my system without first adjusting my config.

So you expect that we would push a patch changing "guix environment"
and in the same time break "guix pull, isn't it?
Otherwise I do not see your argument.


> > Hum? I am not convinced that the cost would be high... Because 1. the
> > number of people using Guix is not so high (yet!), so 2. I am almost
> > sure we can name the people using "guix environment" in scripts ;-).
>
> I’m not so sure. Guix is already used in scientific workflows, and there
> is existing third-party documentation about using `guix environment`.

Please point me where.
It will save me time instead of reinventing the wheel.


> And can you name the people using `guix environment` by searching
> backwards in their bash history?

So what would break?
Your workflow: spending 5 minutes to read the warning message and then pressing:
C-a GUIX_ENVIRONMENT_DEPRACATED=1 guix environment 

(unfair and bitter; sorry!)


> > And 3. the time to figure out what changed is really low -- especially
> > with warnings and hints -- and "guix environment foo -- make" would
> > return an error because of dependencies missing.
>
> It took me days to figure out the exact guix environment invocation that
> allows me to build the tools for a paper I’m still working on. If that
> breaks, that causes massive anxiety, because I then don’t know whether
> I’ll find the time to fix it before I run into deadlines.

Do you mean add GUIX_ENVIRONMENT_DEPRECATED=1 at the top of your script?


> > Other said, I do not see myself use-cases where the scripts using
> > "guix environment" need to be robust for time-travelling -- the same
> > script used with current, past and future Guix versions -- because as
> > it was said elsewhere: "environment" can be seen like "temporary
> > profile". And temporary means... well temporary. ;-)
>
> The same script must always work with future versions. Otherwise the
> software is volatile.

Here is the real argument.

It is a point of view. I would like to ear the one of others.
If I understand well, Konrad agrees with you.

I am fine with: the same script must always work with future versions.

It is a strong statement and if the Guix project agrees then it must
be documented. For example in this section [1].

What do you think?


[1] 
http://guix.gnu.org/manual/devel/en/html_node/Managing-Software-the-Guix-Way.html#Managing-Software-the-Guix-Way


> You don’t need to be able to go back in time, but the path forward must
> be without breakage.

Talking about Reproducible Science, going back in time is the core
issue. If one is able to go back in time and to run again the (almost)
exact same version, then the future is not the issue.

Correct me if I misunderstand your point.
Today, I write a script using X tools at time T. In the future, I want
to re-run this script so all the X tools must have a path forward
without any breakage. It is your point, right? But this never happens,
there is always a breakage somewhere; and generally for good reasons.
Instead in this future, if I am able to restore the exact same X tools
as they were at time T, my script still works.

Well, this is another story.



> > Last, "volatile" vs "stable" is mitigated by "The future of 'guix
> > environment'" [1] which really predates the 1.0. ;-)
>
> Yepp, but we’re after 1.0 now. This might have been a blocker for 1.0,
> but it wasn’t.

So if the version bump, it is not an issue then, isn't it?


> >> Also: Software developers should avoid traumatic changes
> >>   https://drewdevault.com/2019/11/26/Avoid-traumatic-changes.html
> >
> > "Traumatic changes"? Maybe a bit extreme for the change we are talking 
> > about...
>
> I don’t think so. There’s the strong version where it’s obvious: It
> leads people to leave a project instantly.

Yes, me!


> There’s the weaker version which is less obvious: That’s where people
> who invested efford to follow best practices suddenly find their project
> to be written in legacy style, because the best practices changed.

Best practise depends on a lot of parameters. I did not know it was frozen.



Well, I withdraw my investment. I am not interested anymore to not
tell that I am traumatized.


Regards,
simon

Re: Bioconductor package flowPeaks license Artistic 1.0?

[zimoun]

Hi Tobias,

On Thu, 19 Dec 2019 at 21:24, Tobias Geerinckx-Rice  wrote:

[...]

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

Here 'open' is not enough. ;-)


> However, even if they don't maintain the code they can still
> relicence it with no effort on their part.  We can still hope.

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 author of this software is Steven Fortune.  Copyright (c) 1994 by AT
* Bell Laboratories.
* Permission to use, copy, modify, and distribute this software for any
[...]
* This code was originally written by Stephan Fortune in C code.  I,
Shane O'Sullivan,
* have since modified it, encapsulating it in a C++ class and, fixing
memory leaks and
* adding accessors to the Voronoi Edges.
* Permission to use, copy, modify, and distribute this software for any
[...]
>>

The most of the files claim:

<<
* The author of this software is Yongchao Ge.
* Permission to use, copy, modify, and distribute this software for any
* purpose without fee is hereby granted, provided that this entire notice
* is included in all copies of any software which is or includes a copy
* or modification of this software and in all copies of the supporting
* documentation for such software.
* THIS SOFTWARE IS BEING PROVIDED "AS IS", WITHOUT ANY EXPRESS OR IMPLIED
* WARRANTY.  IN PARTICULAR, THE AUTHOR DOES NOT MAKE ANY
* REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE MERCHANTABILITY
* OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR PURPOSE.
>>


Well, the only mention of the Artistic 1.0 license is these 3 files:
README, DESCRIPTION and vignettes/flowPeaks-guide.Rnw.


Does that mean I am allowed to reuse almost everything and repack in
another repo licensing with a "good" license?


[...]

> If I'm still not making myself clear, I apologise & capitulate.

I got it. Yes it is clear!


> > So I will appeal to FSF/GNU. ;-)
>
> I admire your tenacity.  Good luck!

Before I need to assembling the file. :-)
For example, how many packages in Bioconductor use the Artistic 1.0?


Thank for all your explanation and your time.

All the best,
simon

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

[Arne Babenhauserheide]

Hi zimoun,

zimoun  writes:

>>  Should Guix be volatile software?
>>  http://stevelosh.com/blog/2012/04/volatile-software/
>
> Guix is not a volatile software and will never be. Because it is
> rooted in time-travelling.
> The tools "guix pull --commit=", "guix  --manifest=", "guix
> time-machine" or the "--roll-back" avoid to break what is currently
> working.

This is taking this a bit too easy. If I can no longer pull, because
that breaks my Emacs or Gnome, then Guix is broken for me: I can no
longer update my system without first adjusting my config.

> Number of people Time it takes each person
> using that part of   X   to figure out what changed
> the program  and how to fix it
>
> Hum? I am not convinced that the cost would be high... Because 1. the
> number of people using Guix is not so high (yet!), so 2. I am almost
> sure we can name the people using "guix environment" in scripts ;-).

I’m not so sure. Guix is already used in scientific workflows, and there
is existing third-party documentation about using `guix environment`.

And can you name the people using `guix environment` by searching
backwards in their bash history?

> And 3. the time to figure out what changed is really low -- especially
> with warnings and hints -- and "guix environment foo -- make" would
> return an error because of dependencies missing.

It took me days to figure out the exact guix environment invocation that
allows me to build the tools for a paper I’m still working on. If that
breaks, that causes massive anxiety, because I then don’t know whether
I’ll find the time to fix it before I run into deadlines.

> Other said, I do not see myself use-cases where the scripts using
> "guix environment" need to be robust for time-travelling -- the same
> script used with current, past and future Guix versions -- because as
> it was said elsewhere: "environment" can be seen like "temporary
> profile". And temporary means... well temporary. ;-)

The same script must always work with future versions. Otherwise the
software is volatile.

You don’t need to be able to go back in time, but the path forward must
be without breakage.

> Then, the section "The Tradeoff" advices "from newmodule import
> new_foo as foo" and IMO it is what the plan proposes with the variable
> GUIX_ENVIRONMENT_DEPRECATED (tricky point #4).

No, that’s the opposite: from newmodule import new_foo as foo means,
that you allow users to define an environment variable called
`GUIX_ENVIRONMENT_MODERN`.

> Last, "volatile" vs "stable" is mitigated by "The future of 'guix
> environment'" [1] which really predates the 1.0. ;-)

Yepp, but we’re after 1.0 now. This might have been a blocker for 1.0,
but it wasn’t.

>> Also: Software developers should avoid traumatic changes
>>   https://drewdevault.com/2019/11/26/Avoid-traumatic-changes.html
>
> "Traumatic changes"? Maybe a bit extreme for the change we are talking 
> about...

I don’t think so. There’s the strong version where it’s obvious: It
leads people to leave a project instantly.

There’s the weaker version which is less obvious: That’s where people
who invested efford to follow best practices suddenly find their project
to be written in legacy style, because the best practices changed.

> Well, at the end, what is explicitly your personal opinion?
>  a. Change the behaviour of "guix environment" using the proposed plan?
> or
>  b. Add a new command? Which one? "guix shell", "guix env" or "guix
> "?

I would opt for b. And then for changing guix to give the most common
commands when called without argument (as `guix`) — excluding
guix environment.

That would not avoid the slow version of traumatic changes, but if
guix environment would keep working and both guix env/guix shell/… and
guix environment used the same backend (just with different options),
then they would be minimized, because guix environment would not become
a second-class citizen.

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


signature.asc
Description: PGP signature

Re: Bioconductor package flowPeaks license Artistic 1.0?

[zimoun]

Hi Ricardo,

On Thu, 19 Dec 2019 at 21:13, Ricardo Wurmus  wrote:

> This is a misunderstanding.  The Perl license says[1]:

Thank you for the pointer and the explanation.
All is clear and I am fine. :-)

Cheers,
simon

Re: Ansible and GuixOps questions

[Thompson, David]

Hello Robert,

On Mon, Dec 16, 2019 at 6:57 AM rchar01  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: Document GUIX_LOAD_PATH?

[zimoun]

Hi,

On Thu, 19 Dec 2019 at 18:04, Pierre Neidhardt  wrote:

> So the question is: shall we add --load-path to all commands instead?
> (If not already the case.)

Please comment patches #38678.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38678


All the best,
simon

Re: qtwenengine anybody?

[Pierre Neidhardt]

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

> This should be resolved now. I had to upgrade the vps to avoid OOM
> issues. But as I've now it should serve this substitute.

Sorry, still no substitute for me for the patch you've sent yesterday.

> you can test with.
>
> --8<---cut here---start->8---
> guix archive --export -r qtwebengine | ssh server guix archive --import
> --8<---cut here---end--->8---

Err... What do you mean with the above?  Did you paste the right
command? 

> If this passes make sure you have
> #AF73C7321F90EA89AD29BBA14069EB8EF8F6410325E479F93DE4612F26478726#
>
> in
> --8<---cut here---start->8---
> /etc/guix/acl
> --8<---cut here---end--->8---

I do!

I tried building it myself anyways, and it fails with

--8<---cut here---start->8---
[11690/14276] CXX 
obj/third_party/blink/renderer/core/animation/animation/animation_jumbo_2.o
FAILED: 
obj/third_party/blink/renderer/core/animation/animation/animation_jumbo_2.o
/gnu/store/x3jx25cd3q363mr7nbgzrhrv1vza6cf7-gcc-7.4.0/bin/g++ -MMD -MF 
obj/third_party/blink/renderer/core/animation/animation/animation_jumbo_2.o.d 
-DV8_DEPRECATION_WARNINGS -DUSE_UDEV -DUSE_AURA=1 -DUSE_NSS_CERTS=1 
-DUSE_OZONE=1 -DNO_TCMALLOC -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD 
-DSAFE_BROWSING_DB_LOCAL -DOFFICIAL_BUILD -DCHROMIUM_BUILD 
-DFIELDTRIAL_TESTING_ENABLED -DTOOLKIT_QT -D_FILE_OFFSET_BITS=64 
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 
-DBLINK_CORE_IMPLEMENTATION=1 -DGL_GLEXT_PROTOTYPES -DUSE_GLX -DUSE_EGL 
-DBLINK_IMPLEMENTATION=1 -DINSIDE_BLINK -DUSING_SYSTEM_ICU=1 
-DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_STATIC -DGOOGLE_PROTOBUF_NO_RTTI 
-DGOOGLE_PROTOBUF_NO_STATIC_INITIALIZER -DHAVE_PTHREAD 
-DSK_IGNORE_LINEONLY_AA_CONVEX_PATH_OPTS -DSK_HAS_PNG_LIBRARY 
-DSK_HAS_WEBP_LIBRARY -DSK_HAS_JPEG_LIBRARY -DSK_SUPPORT_GPU=1 
-DSK_GPU_WORKAROUNDS_HEADER=\"gpu/config/gpu_driver_bug_workaround_autogen.h\" 
-DWTF_USE_WEBAUDIO_FFMPEG=1 -DSUPPORT_WEBGL2_COMPUTE_CONTEXT=1 
-DWTF_USE_DEFAULT_RENDER_THEME=1 -DUSE_SYSTEM_LIBJPEG -DUSING_SYSTEM_ICU=1 
-DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_STATIC 
-DWEBRTC_NON_STATIC_TRACE_EVENT_HANDLERS=0 -DGTEST_RELATIVE_PATH 
-DWEBRTC_CHROMIUM_BUILD -DWEBRTC_POSIX -DWEBRTC_LINUX 
-DABSL_ALLOCATOR_NOTHROW=1 -DNO_MAIN_THREAD_WRAPPING -DLIBXSLT_STATIC 
-DUSE_SYSTEM_ZLIB=1 -I. -Igen -I../../3rdparty/chromium -Igen -Igen -Igen -Igen 
-Igen -Igen -I../../3rdparty/chromium/third_party/khronos 
-I../../3rdparty/chromium/gpu 
-I../../3rdparty/chromium/third_party/libyuv/include -Igen -Igen -Igen -Igen 
-Igen -Igen -Igen -I../../3rdparty/chromium/third_party/ced/src 
-I../../3rdparty/chromium/third_party/protobuf/src 
-I../../3rdparty/chromium/third_party/protobuf/src -Igen/protoc_out 
-I../../3rdparty/chromium/third_party/boringssl/src/include 
-I../../3rdparty/chromium/skia/config -I../../3rdparty/chromium/skia/ext 
-I../../3rdparty/chromium/third_party/skia/include/c 
-I../../3rdparty/chromium/third_party/skia/include/config 
-I../../3rdparty/chromium/third_party/skia/include/core 
-I../../3rdparty/chromium/third_party/skia/include/effects 
-I../../3rdparty/chromium/third_party/skia/include/encode 
-I../../3rdparty/chromium/third_party/skia/include/gpu 
-I../../3rdparty/chromium/third_party/skia/include/images 
-I../../3rdparty/chromium/third_party/skia/include/lazy 
-I../../3rdparty/chromium/third_party/skia/include/pathops 
-I../../3rdparty/chromium/third_party/skia/include/pdf 
-I../../3rdparty/chromium/third_party/skia/include/pipe 
-I../../3rdparty/chromium/third_party/skia/include/ports 
-I../../3rdparty/chromium/third_party/skia/include/utils 
-I../../3rdparty/chromium/third_party/skia/src/gpu 
-I../../3rdparty/chromium/third_party/skia/src/sksl 
-I../../3rdparty/chromium/third_party/angle/include 
-I../../3rdparty/chromium/third_party/angle/src/common/third_party/base 
-Igen/angle -I../../3rdparty/chromium/v8/include -Igen/v8/include 
-I../../3rdparty/chromium/third_party/webrtc_overrides 
-I../../3rdparty/chromium/third_party/webrtc 
-I../../3rdparty/chromium/third_party/iccjpeg 
-I../../3rdparty/chromium/third_party/ots/include 
-I../../3rdparty/chromium/v8/include -Igen/v8/include 
-I../../3rdparty/chromium/third_party/libxml/src/include 
-I../../3rdparty/chromium/third_party/libxml/linux/include 
-I../../3rdparty/chromium/third_party/libxslt/src -fno-strict-aliasing 
--param=ssp-buffer-size=4 -fstack-protector -funwind-tables -fPIC -pipe 
-pthread -m64 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 
-Wno-unused-local-typedefs -Wno-maybe-uninitialized 
-Wno-deprecated-declarations -fno-delete-null-pointer-checks -Wno-comments 
-Wno-dangling-else -Wno-packed-not-aligned -Wno-missing-field-initializers 
-Wno-unused-parameter -fno-omit-frame-pointer -fvisibility=hidden -O2 

Re: Bioconductor package flowPeaks license Artistic 1.0?

[Tobias Geerinckx-Rice]

Zimoun,

zimoun 写道：
On Thu, 19 Dec 2019 at 18:18, Tobias Geerinckx-Rice 
 wrote:
Thank you for fighting for this package in Guix.  I hope 
upstream

sees the light and Clarifies things.


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.


However, even if they don't maintain the code they can still 
relicence it with no effort on their part.  We can still hope.



zimoun 写道：



‘Non-copyleft’ does not mean ‘non-free’.  All packages in Guix
must be free.  The Artistic 1.0 licence is *not free*.[0]


It is not my point.


I think au fond it is.  Because your point was:


Artistic 1.0 is free and non-copyleft when applied to Perl.

 

This just isn't true, and that's what I wanted to make clear 
above.


*Perl* is free, only because it is licenced under the GPL.  If 
Perl were licenced only under the Artistic 1.0 licence, it would 
not be in Guix.  I promise.


So Perl is really not relevant to this discussion at all.

If I'm still not making myself clear, I apologise & capitulate. 
We agree on all important points:



The FSF's legal counsel has decided that the Clarified version
does in fact ‘correct the vagueness of of the Artistic License
1.0’[2].


I understand. And I disagree. So I appeal. :-)


Hehe.  Even the FSF agrees that the Clarified version does only 
the *bare minimum* to not completely suck.  They certainly don't 
recommend it.



Well, I understand you are defending the official GNU position.
And currently Artisitic 1.0 will not be included in GNU Guix 
because

currently GNU claims that Artistic 1.0 is non-free.
I am fine with that. :-)


Correct.  It's only the comparison with Perl that's bogus, not 
your opinions on the Artistic 1.0 licence itself.



So I will appeal to FSF/GNU. ;-)


I admire your tenacity.  Good luck!

Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: Bioconductor package flowPeaks license Artistic 1.0?

[Ricardo Wurmus]

zimoun  writes:

> I already know these statements. And I disagree. Currently, the
> [artistic] license [1.0] is considered free when applied to Perl but non-free
> otherwise. It does not make sense.

This is a misunderstanding.  The Perl license says[1]:

It is free software; you can redistribute it and/or modify it under the 
terms of either:

a) the GNU General Public License as published by the Free Software
   Foundation; either version 1, or (at your option) any later version,
   or
b) the "Artistic License". […]

We choose the first one when redistributing Perl, so Perl is under the
GPLv1+.  The Artistic License (1.0) does not come into play at all
because we are fine with GPLv1+.

If Perl was *only* available under the Artistic License 1.0 we could not
in fact redistribute it with Guix and that would be catastrophic.
Luckily, the license allows the distribution under the terms of the GPL,
so we’re fine.

[1]: https://dev.perl.org/licenses/

--
Ricardo

Re: qtwenengine anybody?

[mike . rosset]

Pierre Neidhardt  writes:

> The substitution does not apply for me on master.


This should be resolved now. I had to upgrade the vps to avoid OOM
issues. But as I've now it should serve this substitute.

you can test with.

--8<---cut here---start->8---
guix archive --export -r qtwebengine | ssh server guix archive --import
--8<---cut here---end--->8---


If this passes make sure you have
#AF73C7321F90EA89AD29BBA14069EB8EF8F6410325E479F93DE4612F26478726#

in
--8<---cut here---start->8---
/etc/guix/acl
--8<---cut here---end--->8---


Mike

Re: Bioconductor package flowPeaks license Artistic 1.0?

[zimoun]

Hi Tobias, again :-)

On Thu, 19 Dec 2019 at 18:18, Tobias Geerinckx-Rice  wrote:

> zimoun 写道：

> > Especially when this
> > very Artistic 1.0 "qualifies as a free software license, but it
> > may
> > not be a real copyleft" [1].
>
> …but that's not this very licence, it's a completely different
> one: the (disjunct) combination of the Artistic 1.0 licence *and
> the GPL*, i.e. ‘choose one’.  The result is only free because you
> can *ignore* the Artistic 1.0 part.


Maybe I misread. And I would like to avoid any confusion.
So I have also read the French translation. Then again the English version.

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

What I understand is: when the License of Perl 5 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.

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. 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 and because it is not Guix related, I would like to
ask to GNU or FSF. Do you know where can I post an email?


All the best,
simon

Re: Bioconductor package flowPeaks license Artistic 1.0?

[zimoun]

Hi Tobias,

Thank you for the clarification.


On Thu, 19 Dec 2019 at 18:29, Tobias Geerinckx-Rice  wrote:
>
> Tobias Geerinckx-Rice 写道：
> > zimoun 写道：
> >> Other said, calling Artistic 1.0 non-free in this Bioconductor
> >> case
> >> is more a flavour of taste than a real legal issue.
> >
> > No, it's a very real legal issue.  :-(
>
> I should clarify: when the FSF calls the Artistic 1.0 licence
> ‘vague’, that's not an aesthetic criticism.
>
> It means that the licence is broken and fails to do what it claims
> to do: give you the licence (=freedom) to do something that would
> not otherwise be allowed by copyright law.  It means that you
> can't prove, in court, that the licence says what you thought it
> said.  It's not merely ugly, it's defective and potentially
> dangerous.

I agree.
It is what I tried to express in my other email.
You explained here better than I did elsewhere. :-)

> This always happens when programmers think they can write their
> own licence.  It starts with a punny name (‘artistic licence’,
> ‘WTFPL’, ha ha -_-) and the result is a useless buggy mess.

I am on the same wavelength.


All the best,
simon

Re: Bioconductor package flowPeaks license Artistic 1.0?

[Tobias Geerinckx-Rice]

Tobias Geerinckx-Rice 写道：

zimoun 写道：
Other said, calling Artistic 1.0 non-free in this Bioconductor 
case

is more a flavour of taste than a real legal issue.


No, it's a very real legal issue.  :-(


I should clarify: when the FSF calls the Artistic 1.0 licence 
‘vague’, that's not an aesthetic criticism.


It means that the licence is broken and fails to do what it claims 
to do: give you the licence (=freedom) to do something that would 
not otherwise be allowed by copyright law.  It means that you 
can't prove, in court, that the licence says what you thought it 
said.  It's not merely ugly, it's defective and potentially 
dangerous.


This always happens when programmers think they can write their 
own licence.  It starts with a punny name (‘artistic licence’, 
‘WTFPL’, ha ha -_-) and the result is a useless buggy mess.


Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: Bioconductor package flowPeaks license Artistic 1.0?

[zimoun]

Hi Tobias,

Thank you for the explanations. I agree, almost. ;-)

On Thu, 19 Dec 2019 at 18:18, Tobias Geerinckx-Rice  wrote:

> Thank you for fighting for this package in Guix.  I hope upstream
> sees the light and Clarifies things.

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.


> zimoun 写道：

> ‘Non-copyleft’ does not mean ‘non-free’.  All packages in Guix
> must be free.  The Artistic 1.0 licence is *not free*.[0]

It is not my point.

Artistic 1.0 is free and non-copyleft when applied to Perl. And it
does not make sense. A license is free or not, independently to what
it is applied to.


> I do understand your frustration & hacker instinct to ‘fix’ the
> problem in some clever way, but that's not how licences work.  The
> Artistic 1.0 story really ends here.

As I said, saying that Artistic 1.0 is non-free is really a flavour of taste.




> I'm not trying to demotivate you.  I just don't want you to waste
> your time & effort in this dead-end direction.  Bugging upstream
> until they respond is the only solution.

They will not, sadly.



> > Well, I have read both licenses and the Clarified one does not
> > appear
> > me clearer; they are both doomed!
>
> I hope you'll understand that I'm also not trying to be rude when
> I say (y)our personal opinions are entirely valid and absolutely
> irrelevant :-)

My point is: claiming that Clarified Artistic 1.0 is free and Artistic
1.0 is not is a flavour of taste.
What does it mean "free"? Well, it is defined by some GNU documents.
Then, someone reads this definition and sees if the license is
compliant with the definition. And there is an interpretation. That's
why GNU considers some license free and Debian not (or the contrary).

Well, I disagree to say Clarified Artistic 1.0 is free and Artistic
1.0 is not. They are both free or both non-free.


> The FSF's legal counsel has decided that the Clarified version
> does in fact ‘correct the vagueness of of the Artistic License
> 1.0’[2].

I understand. And I disagree. So I appeal. :-)


> > Other said, calling Artistic 1.0 non-free in this Bioconductor
> > case is
> > more a flavour of taste than a real legal issue.
>
> No, it's a very real legal issue.  :-(

Yes it is.
Because the main purpose of a license is to manage what happens in Court.



Well, I understand you are defending the official GNU position.
And currently Artisitic 1.0 will not be included in GNU Guix because
currently GNU claims that Artistic 1.0 is non-free.
I am fine with that. :-)
And I understand you block my hacky proposal of non-copyleft.
I am also fine with that. :-)

So I will appeal to FSF/GNU. ;-)


All the best,
simon

Re: Bioconductor package flowPeaks license Artistic 1.0?

[zimoun]

Hi Ricardo,

Thank you for the quick feedback.

On Thu, 19 Dec 2019 at 18:18, Ricardo Wurmus  wrote:

> zimoun  writes:
>
> > The file guix/licenses.scm contains "non-copyleft" therefore why do
> > not put the licenses Artistic 1.0 under this label? It will allow the
> > inclusion of this package -- and probable others from Bioconductor.
>
> That wouldn’t be correct.  non-copyleft is for free licenses only, and
> the Artistic 1.0 does not qualify.

The Perl License section says:

<<
This license is the disjunction of the Artistic License 1.0 and the
GNU GPL—in other words, you can choose either of those two licenses.
It qualifies as a free software license, but it may not be a real
copyleft. It is compatible with the GNU GPL because the GNU GPL is one
of the alternatives.

We recommend you use this license for any Perl 4 or Perl 5 package you
write, to promote coherence and uniformity in Perl programming.
Outside of Perl, we urge you not to use this license; it is better to
use just the GNU GPL.
>>

https://www.gnu.org/licenses/license-list.en.html#PerlLicense


I read "It qualifies as a free software license, but it may not be a
real copyleft." therefore it means non-copyleft.



> https://www.gnu.org/licenses/license-list.en.html#ArtisticLicense says:
>
> “We cannot say that this is a free software license because it is
>  too vague; some passages are too clever for their own good, and
>  their meaning is not clear. We urge you to avoid using it, except
>  as part of the disjunctive license of Perl.”
>
> However:
>
> https://www.gnu.org/licenses/license-list.en.html#ClarifiedArtistic
>
> “This license is a free software license, compatible with the
>  GPL. It is the minimal set of changes needed to correct the
>  vagueness of the Artistic License 1.0.”
>

I already know these statements. And I disagree. Currently, the
license is considered free when applied to Perl but non-free
otherwise. It does not make sense.


Well, if I understand well, as GNU Guix maintainer, you will have the
official GNU position, right?
So let discuss this official GNU position. :-)
Do you know in which mailing list can I post?


Cheers,
simon

Re: Overhauling the cargo-build-system

[John Soo]

Hi all,

I am working on ripgrep and I was wondering if we could add a key to inputs for 
cargo inputs instead of using the arguments field.  Is there a downside to 
saying something like 

`(inputs
(("rust-loom" ,rust-loom-0.2 #rust-build)
 ("rust-quickcheck" ,rust-quickcheck-0.9 #rust-dev))

Just a thought I had so I could be wrong. I certainly see the downside of not 
using the inputs fields the way they work everywhere else.

Thanks,

John

Re: Bioconductor package flowPeaks license Artistic 1.0?

[Tobias Geerinckx-Rice]

Zimoun,

Thank you for fighting for this package in Guix.  I hope upstream 
sees the light and Clarifies things.


zimoun 写道：

 Ricardo Wurmus  wrote:
It would be great if they could use the Clarified Artistic 
License
instead.  It’s really close to the Artistic 1.0, so unless they 
really
want the non-free interpretation of Artistic 1.0 it should be 
no trouble

for them to switch.


This is the only solution.  Any other licence in licenses.scm is 
fine too.


The file guix/licenses.scm contains "non-copyleft" therefore why 
do
not put the licenses Artistic 1.0 under this label? It will 
allow the
inclusion of this package -- and probable others from 
Bioconductor.


‘Non-copyleft’ does not mean ‘non-free’.  All packages in Guix 
must be free.  The Artistic 1.0 licence is *not free*.[0]


I do understand your frustration & hacker instinct to ‘fix’ the 
problem in some clever way, but that's not how licences work.  The 
Artistic 1.0 story really ends here.


I'm not trying to demotivate you.  I just don't want you to waste 
your time & effort in this dead-end direction.  Bugging upstream 
until they respond is the only solution.


Well, I have read both licenses and the Clarified one does not 
appear

me clearer; they are both doomed!


I hope you'll understand that I'm also not trying to be rude when 
I say (y)our personal opinions are entirely valid and absolutely 
irrelevant :-)


The FSF's legal counsel has decided that the Clarified version 
does in fact ‘correct the vagueness of of the Artistic License 
1.0’[2].


Other said, calling Artistic 1.0 non-free in this Bioconductor 
case is

more a flavour of taste than a real legal issue.


No, it's a very real legal issue.  :-(


Especially when this
very Artistic 1.0 "qualifies as a free software license, but it 
may

not be a real copyleft" [1].


…but that's not this very licence, it's a completely different 
one: the (disjunct) combination of the Artistic 1.0 licence *and 
the GPL*, i.e. ‘choose one’.  The result is only free because you 
can *ignore* the Artistic 1.0 part.


Kind regards,

T G-R

[0]: 
https://www.gnu.org/licenses/license-list.en.html#ArtisticLicense

[1]: https://www.gnu.org/licenses/license-list.en.html#PerlLicense
[2]: 
https://www.gnu.org/licenses/license-list.en.html#ClarifiedArtistic


signature.asc
Description: PGP signature

Re: Store channel specification in profile

[zimoun]

Hi!

On Thu, 19 Dec 2019 at 17:12, Ludovic Courtès  wrote:

> > You have right. It is a bug.
>
> D’oh!  Could you file it?

Done in #38673.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38673


Cheers,
simon

Re: Bioconductor package flowPeaks license Artistic 1.0?

[Ricardo Wurmus]

zimoun  writes:

> The file guix/licenses.scm contains "non-copyleft" therefore why do
> not put the licenses Artistic 1.0 under this label? It will allow the
> inclusion of this package -- and probable others from Bioconductor.

That wouldn’t be correct.  non-copyleft is for free licenses only, and
the Artistic 1.0 does not qualify.

> Well, I have read both licenses and the Clarified one does not appear
> me clearer; they are both doomed!
> Other said, calling Artistic 1.0 non-free in this Bioconductor case is
> more a flavour of taste than a real legal issue. Especially when this
> very Artistic 1.0 "qualifies as a free software license, but it may
> not be a real copyleft" [1].
>
>
> [1] https://www.gnu.org/licenses/license-list.en.html#PerlLicense

https://www.gnu.org/licenses/license-list.en.html#ArtisticLicense says:

“We cannot say that this is a free software license because it is
 too vague; some passages are too clever for their own good, and
 their meaning is not clear. We urge you to avoid using it, except
 as part of the disjunctive license of Perl.”

However:

https://www.gnu.org/licenses/license-list.en.html#ClarifiedArtistic

“This license is a free software license, compatible with the
 GPL. It is the minimal set of changes needed to correct the
 vagueness of the Artistic License 1.0.”

--
Ricardo

Re: Document GUIX_LOAD_PATH?

[Pierre Neidhardt]

zimoun  writes:

> Do you have in mind commands where the option --load-path is still missing?
> Maybe "guix graph"?

Yes.

> Maybe "guix edit"?

Yes.

Also:

- guix size (this one has annoyed me for a long time!)

- Maybe guix import?  What if a channel / local repo specifies a new
  importer?

- guix refresh

I think that would be it.

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


signature.asc
Description: PGP signature

Re: Document GUIX_LOAD_PATH?

[zimoun]

On Thu, 19 Dec 2019 at 18:04, Pierre Neidhardt  wrote:

> So the question is: shall we add --load-path to all commands instead?
> (If not already the case.)

Only commands that need it. :-)

Do you have in mind commands where the option --load-path is still missing?
Maybe "guix graph"?
Maybe "guix edit"?

Re: Document GUIX_LOAD_PATH?

[Pierre Neidhardt]

The reason this came up was because the --load-path command line
argument was missing from some command.  Then Clément argued that it was
not necessary anyways, we could set GUIX_PACKAGE_PATH (I didn't know
that it was effectively the same as --load-path, but for all commands).

So the question is: shall we add --load-path to all commands instead?
(If not already the case.)

Side question: Can we really do everything without using GUIX_PACKAGE_PATH?

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


signature.asc
Description: PGP signature

Re: Document GUIX_LOAD_PATH?

[Ludovic Courtès]

Also, GUIX_PACKAGE_PATH is not “recommended”—channels FTW!

Ludo’.

Re: Report from the 2019 Reproducible Builds Summit

[Ludovic Courtès]

Hi!

Pierre Neidhardt  skribis:

> As usual I've learned a lot from this great read!

:-)

> Out of curiosity, why is "janneke" spelled without a capital? :)

Good question; I think that’s how [Jj]anneke writes “janneke”, but what
does janneke think?  :-)

Ludo’.

Re: [ANN] Gash 0.2.0 released

[Ludovic Courtès]

Hi Timothy,

Timothy Sample  skribis:

> I am very pleased to announce that Gash version 0.2.0 has been released.
> It represents 58 commits from two authors over the course of about six
> months.

Yay, congrats!

> The big news for this release is that Gash can now replace Bash in
> building all of the packages used in Guix’s “Reduced Binary Seed
> Bootstrap” .
> Whereas the previous release could build Bash itself, this release can
> build everything from Mes to GCC and then build Bash.

Woohoo, that’s quite an achievement.

Thanks for all the work!

Ludo’.

Re: Cross-compilation broken on canonical packages.

[Ludovic Courtès]

Hi Mathieu,

Mathieu Othacehe  skribis:

> Small mistake sorry. This fails:
>
> guix build --target=aarch64-linux-gnu -e "((@ (gnu packages base) 
> canonical-package) (@ (gnu packages base) grep))"
>
>
> while this succeeds:
>
> guix build -e "((@ (gnu packages base) canonical-package) (@ (gnu packages 
> base) grep))"

This is expected: packages in ‘%final-inputs’ (those returned by
‘canonical-package’) are rooted in the bootstrap graph and cannot be
cross-compiled.

Perhaps ‘%base-packages’ should use packages form (gnu packages base)
instead?  The reason it uses ‘canonical-package’ is just to avoid
introducing redundant packages in the system, but I don’t think it makes
that much sense.

Thanks,
Ludo’.

Re: Guix mirror: sourceware discussion report

[Ludovic Courtès]

Hi!

Tobias Geerinckx-Rice  skribis:

> Something akin to
>
>  (channel
>(name 'guix)
>(url (list "https://savannah…;
>   "https://sourceware…;))
>…)
>
> ?
>
> I'd like to see that added to the channels.scm format for selfish
> reasons.

Yup, that’d be nice.

> However, I'd still like the first or second URL to start with
> ‘guix.gnu.org’.  I have nothing against Sourceware, but guix.gnu.org
> has been pretty solid (AFAIK) and, more importantly, does not require
> users to trust yet another party by default.
>
> [‘Trustable Guix pull’ rears its head again :-) …]

Yeah…  I discussed this a bit with an in-toto/TUF person at the R-B
Summit and I’m wrapping my head again around it now, because clearly,
this is the main showstopper here.

Once this is addressed, at least to some level, we can happily mirror on
all the hosting sites we can think of.

Anyway, thank you zimoun for contacting the Sourceware folks, and thanks
Tobias & Ricardo for setting up the mirror on berlin!

Ludo’.

Re: Bioconductor package flowPeaks license Artistic 1.0?

[zimoun]

Hi Ricardo,


On Thu, 25 Jul 2019 at 14:47, Ricardo Wurmus  wrote:

> > On Wed, 24 Jul 2019 at 23:16, Ricardo Wurmus  wrote:

> >> That’s because version 1.0 is considered non-free.  “licenses.scm” also
> >> contains “clarified-artistic”, which is essentially the same as version
> >> 1.0 but with a few clarifications of those points that could be
> >> interpreted as conditions making the software non-free.

> It would be great if they could use the Clarified Artistic License
> instead.  It’s really close to the Artistic 1.0, so unless they really
> want the non-free interpretation of Artistic 1.0 it should be no trouble
> for them to switch.

I have no news from the flowPeak's maintainer and I think the package
is still in Bioconductor 3.10 but without any recent updates.

The file guix/licenses.scm contains "non-copyleft" therefore why do
not put the licenses Artistic 1.0 under this label? It will allow the
inclusion of this package -- and probable others from Bioconductor.

Well, I have read both licenses and the Clarified one does not appear
me clearer; they are both doomed!
Other said, calling Artistic 1.0 non-free in this Bioconductor case is
more a flavour of taste than a real legal issue. Especially when this
very Artistic 1.0 "qualifies as a free software license, but it may
not be a real copyleft" [1].


[1] https://www.gnu.org/licenses/license-list.en.html#PerlLicense

All the best,
simon

Re: NLNet grant "Next Generation Internet -- Search & discovery": I'm in!

[Ludovic Courtès]

Hello!

Congrats, Pierre!  That’s really great news!

Arun Isaac  skribis:

>> 1. Parameterized packages
>>(Previous discussion: 
>> https://lists.gnu.org/archive/html/guix-devel/2019-05/msg00285.html)
>
> I've been looking for something like this. I want to run a more minimal
> system like I used to with Parabola GNU/Linux. I often find Guix's
> packages to be too heavy and hard to modify without a lot of
> effort. Package inheritance is itself easy to accomplish with Guile code
> but getting the modified package to build successfully is sometimes
> difficult. It would certainly help if Guix had pre-parameterized
> packages that one could modify easily. However, this can enormously
> increase the burden on Guix packagers. However, we can discuss that
> later when we have more specific proposals.

Yes, I’m very much on the same line of thought: it sounds both exciting
from a user viewpoint (colleagues of mine in HPC would love it) and
scary from a maintainer viewpoint (the configuration space could
explode, how do we ensure we ship packages that actually work?).

Let’s see!

>> 2. File search
>>(Previous discussion: 
>> https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00236.html)
>
> This feature would be very nice too. Currently, I fall back to one of my
> Parabola GNU/Linux installations, and run pkgfile there to get an
> approximate idea of what Guix package a certain file might be in.

That’d be great to have.

Thanks,
Ludo’.

Deprecating ‘guix environment’?

[Ludovic Courtès]

Hi Konrad,

Konrad Hinsen  skribis:

> On 16/12/2019 23:09, Ludovic Courtès wrote:
>> So in a more algorithmic manner:
>>> 1. if ad-hoc and inputs-of is present at the same invocation: fail
>>> hard. (With an error like incompatible options present)
>>> 2. if only ad-hoc is present, then print a deprecation warning (yes,
>>> we could make this suspendable with an environment variable, like you
>>> described)
>>> 3. if only inputs-of present, then do the new behaviour.
>>> 4. if neither ad-hoc nor inputs-of present then
>>>a. if GUIX_ENVIRONMENT_DEPRECATED is 1: do the current behaviour,
>>>b. if GUIX_ENVIRONMENT_DEPRECATED is undefined, or is not 1: do the
>>> new behaviour.
>> That sounds like a good plan to me.
>>
>> #4 is the trickiest, and I think it’d be good to give users a bit of
>> time so they can start adjusting before deprecation is in effect.
>
> #4 is trickiest for another reason: there is no future-proof use of
> "guix environment" that works right now and will continue to work. Nor
> is there any way to see, when looking at a command line, whether it's
> old-style or new-style, if neither --ad-hoc nor --inputs-of are
> present. This means that all existing documentation (tutorials etc.)
> will become misleading in the future. Worse, even documentation
> written today, in full awareness of a coming change, can't do better
> than saying "watch out, this will do something else in the future".
>
> The first rule of backwards-compatibility is: never change the meaning
> of an existing valid command/API. Add new valid syntax, deprecate old
> valid syntax, but don't change the meaning of something that was and
> will be valid.

Yeah.

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

> How about a more drastic measure: deprecate "guix environment" and
> introduce a new subcommand with the desired new behaviour?

That has the advantage of avoiding the problem you mention altogether
while also allowing for further changes.

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?

Thanks,
Ludo’.

Re: Checking in, and an announcement!

[Ludovic Courtès]

Hi Brett,

Brett Gilio  skribis:

> At risk of being lampooned by RMS if he is reading this mailing list,
> my wife and I had our first baby delivered last evening! We are very
> excited, and quite exhausted.

Woow, congratulations, and welcome to your child!  :-)

> Unfortunately, I do not think I can anticipate participating in Guix
> Days / FOSDEM2020. But I am so thrilled to be a more integral member
> of the Guix project, and I hope you all are mostly satisfied with my
> work so far. I use Guix at my job, so it is nice getting paid (in a
> way) to play around with Guix.

Nice!  I’d be curious to hear about the bits of Guix that are the most
useful for your job, and also areas that would need improvements.

Anyway, enjoy this moment with your family, and let’s talk to each other
online as time permits!

Cheers,
Ludo’.

Re: wrap-program –> wrap-script

[Ludovic Courtès]

Hello!

Ricardo Wurmus  skribis:

> I’ve just pushed a change to use wrap-script in one package.  The
> purpose of wrap-script is to wrap an executable without having to create
> a separate wrapper shell script.  It does this by prepending a Guile
> script to the top of the file, which sets the environment variables and
> then re-executes itself with the target interpreter (e.g. Python).

Neat!

> I noticed two things:
>
> 1) wrap-script does not automatically pull in Guile as a dependency, so
> if Guile isn’t among the inputs it will create a bad shebang.  This
> should be fixed on core-updates.

Or we could say that it’s not different from other shebangs: it’s up to
the packager to provide all the necessary dependencies.

> 2) we aren’t using wrap-script anywhere.  I think a good use case would
> be the Python build system’s “wrap” phase where we currently use
> wrap-program.  Most of the time we’d be dealing with Python scripts, so
> using wrap-script would be more appropriate here.

The would immediately reach hundreds of packages, so it’s a good idea!

Thanks,
Ludo’.

Re: guix gc doesn't seem to clean old guix revision

[Ludovic Courtès]

Hi,

YOANN P  skribis:

>> Hi Yoann,
>
> Hi Ludo,
>
>> I had not understood that.  I guess the patch below fixes it, I’ll push
>> t shortly.
>
>> Thanks,
>> Ludo’.
>
> Look great, but IMO, your addition, "(passwd:name (getpwuid (getuid",
> should be the only way to get the username since $USER and $LOGNAME
> could be overridden or unset.

It’s precisely because they can be overridden that they should take
precedence.  :-)

Ludo’.

Re: Store channel specification in profile

[Ludovic Courtès]

Hi,

zimoun  skribis:

> On Thu, 12 Dec 2019 at 23:35, Pierre Neidhardt  wrote:
>>
>> I've seen the "provenance" field mentioned a couple of times before, but
>> I can't see any "provenance" in my $PROFILE/manifest file.  Am I missing
>> something?
>>
>> I install profiles with manifests.
>
> You have right. It is a bug.

D’oh!  Could you file it?

Thanks,
Ludo’.

Re: Overhauling the cargo-build-system

[Ludovic Courtès]

Hi Chris,

Chris Marusich  skribis:

> Ludovic Courtès  writes:
>
>> What I would have liked is to somehow replace the #:cargo-inputs
>> argument (which is build-system-specific and thus “opaque”) with regular
>> ‘native-inputs’ or ‘inputs’ field.
>
> That would be nice.  However, it doesn't seem possible to express
> Cargo's "dependencies" and "dev-dependencies" concepts using Guix's
> current package DSL.
>
> Consider the proc-macro2 and quote crates.  We added these two crates in
> commit 2444abd9c124cc55f8f19a0462e06a2094f25a9d, in the same patch
> series where we added #:cargo-inputs and #:cargo-development-inputs:
>
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35318
>
> Here is the Cargo.toml file for proc-macro2:
>
>   https://github.com/alexcrichton/proc-macro2/blob/master/Cargo.toml
>
>   [dev-dependencies]
>   quote = { version = "1.0", default_features = false }
>
> And here is the Cargo.toml file for quote:
>
>   https://github.com/dtolnay/quote/blob/master/Cargo.toml
>
>   [dependencies]
>   proc-macro2 = { version = "1.0", default-features = false }
>
> Here is a diagram of their dependency relationship:
>
>   +---+
>   | quote | <+
>   +---+  |
> ||
> | dependencies   | dev-dependencies
> v|
>   +---+  |
>   |  proc-macro2  | -+
>   +---+
>
> To Cargo, this cycle is not a problem, since "dev-dependencies" are
> treated differently from "dependencies":
>
>   https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html
>
>   "Dev-dependencies are not used when compiling a package for building,
>   but are used for compiling tests, examples, and benchmarks.
>
>   These dependencies are not propagated to other packages which depend
>   on this package."
>
> The reason proc-macro2 declares a "dev-dependency" on quote is because
> proc-macro2 uses quote in its doc tests:
>
>   
> https://github.com/alexcrichton/proc-macro2/blob/e82e8571460a0a0e00f52f011a74a5e0359acf3e/src/lib.rs#L785

I see.

> This relationship between proc-macro2 and quote cannot be readily
> expressed using the current package DSL in Guix.  If you try to model
> "dependencies" and "dev-dependencies" as "inputs" (or "native-inputs",
> or some combination of the two), Guix will fail due to the cycle.

True, but we have the same problem with many non-Rust packages, which we
address in various way—e.g., via an intermediate “-minimal” variant.

> Presumably, proc-macro2 just needs the source of quote (and the source
> of proc-macro2's other dependency, unicode-xid).  When Cargo builds
> proc-macro2, it will take care of building quote and making it available
> during proc-macro2's tests.  Guix "just" needs to provide proc-macro2
> with the quote source.  You might think this poses a bootstrapping
> problem for Cargo, but I guess it doesn't.  As long as Cargo has the
> source for proc-macro2, quote, and unicode-xid, I guess it can build
> proc-macro2 and quote in any order.

In that case, would it work to turn “dev-dependencies” into dependencies
on the source rather than on the package?

> Unless we missed something in our discussion of patch 35318, there is no
> easy way to express the relationship between proc-macro2 and quote
> without changing (or mis-using) the existing package DSL.  In the same
> way that the package DSL introduced "native-inputs" and "inputs" as
> concepts to facilitate cross-compilation, one way to solve this problem
> might be to introduce a new concept to the package DSL that would make
> it possible for Guix to express this kind of relationship correctly.
>
> However, in the discussion of patch 35318, everyone (myself included)
> seemed opposed to changing the package DSL if we didn't have to.  For
> example, in response to an earlier version of the patch series in which
> we tried to map "dependencies" and "dev-dependencies" onto the "inputs"
> and "native-inputs" concepts (which was probably an abuse of the package
> DSL, since "native-inputs" is a cross-compilation concept), you said: "I
> don't understand yet why you change the role of 'inputs' compared to how
> it is in the rest of Guix."  Ultimately, we decided not to modify the
> package DSL or the meaning of "inputs".  Instead, we decided to encode
> the necessary information about dependencies in the cargo-build-system's
> arguments.  That is how we arrived at #:cargo-inputs and
> #:cargo-development-inputs.

OK, thanks for the reminder.  :-)

I’d be curious to hear what Ivan and others think of
 in hindsight.

> By introducing #:cargo-inputs and #:cargo-development-inputs as package
> arguments to the cargo-build-system, we were able to solve the cyclic
> dependency problem in one specific way.  Perhaps there are better ways.
> I agree it would be nice if it were integrated into the package DSL.  I
> think that changing the package DSL to suit our needs might work, but
> I'm not sure how to 

Re: Overhauling the cargo-build-system

[Ludovic Courtès]

Hi Martin,

Martin Becze  skribis:

> Also see patch 38465
> (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38465) for a complete
> example. I would like too know if there is an problem with this patch
> to, before I start packaging the other rust programs this way.

It’d be great if the people in Cc: could comment.  :-)

Ludo’.

Optimized and portable Open MPI packaging

[Ludovic Courtès]

Hello Guix!

For the HPC folks among us, here’s the story of getting Open MPI to
perform well with a variety of high-performance interconnects:

  https://hpc.guix.info/blog/2019/12/optimized-and-portable-open-mpi-packaging/

Most of the changes in that area landed in ‘master’ last month.

Feedback welcome!

Ludo’.

Anyone attending Chaos Communication Congress this year?

[David Dashyan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


Hello guix!

Is anyone going to be at 36c3?

There is going to be NixOS assembly this year. And workshops.
Great chance to meet together

Regards,
David
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEERmd3RaRNN7cv7WgKXWGXeP1hGZIFAl37dEEACgkQXWGXeP1h
GZINvA//X0O35UBOAI2FKXj9s4LLXJa+fcVMdJz7VM04j2JMOh+BpYNbSDExPmiG
UFnfXqAWIeHrxBFCAnmnhP+MKtmU5cz1HbIt2QLLBc8MRzBSOyvBoNqDbTCMwzJ8
7kmC8SZXwHztkQtLTDK4oJ5uOWviOt1+x38u5n7vBWaIlx168LLrM9KbuvvDwr03
kT1mubWR2HE6ZBSEvIX5n6fXQzZqkRA2iYYQMI2BokcYXoU/Tf4BsGzPs/BFvPbC
tKGFylb/uJCEGran256rdVq+V30uusswmUsLWloBFk6cOi/7iH/uoXrISWxF5ptx
k+yJnwERmAwk0572w649kuLpj48fW3bCNIVFHCgqrDV9whrZcZI8kHktIgxbQWpm
Q+CEYX7P18OMHyt4BykH3Ac5u4JaGeONiC18rjyO+xn3FV/uqpaudt3yzMTa3qhC
QcXy6ENcObn4DVagytPlU4OvxS430XjDLm8yWcFEsQFUavP8hwSqiFUupB1oPm8a
JP2VjdMmRKJ81gADs+5LD/efsCCKdCIMLnjSuaOuyunH4AB7m0Ik3gr4OHGk3BuA
yCz46lvmJzLS2p4mbOsSSdOfyt/qST5LRNgjEw+2a1wDwpHY+bV7sZIkYHtC9hae
+7NIGINCqd7IMSQzKR01H7QntxD6fA75ksrFSVDFHBXujsQg9FU=
=HggO
-END PGP SIGNATURE-

Re: Ansible and GuixOps questions

[rchar01]

An interesting project, thanks for sharing.
In my case I will definitely be able to use it.

Do you think using Guix will allow full replacement of Ansible
(on Guix System or other like Debian)?

Robert.


‐‐‐ Original Message ‐‐‐
On Monday, December 16, 2019 8:35 PM, Pjotr Prins

> Hi Richard,
>
> As it happens I am working on partial deploy to replace the likes of
> Ansible. If you want to help we can make this a killer system. See
>
> http://git.genenetwork.org/pjotrp/guix-notes/src/branch/master/DEPLOY.org
>
> I am planning to post this to mailing list as soon I got machine
> configuration cracked from a package definition.
>
> My X-mas project ;)
>
> Pj.
>
> On Mon, Dec 16, 2019 at 11:57:02AM +, rchar01 wrote:
>
> > Hello,
> > 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?
> > -   is there any way to continue using Ansible to configure Guix (some in
> > guile script and some in ansible)?
> > -   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?
> >
> > Rewriting to Guile (Guix config files):
> > -  Against:
> > ** time consuming
> > ** may require new skills
> > ** only for Guix, Ansible can configure other GNU / Linux systems
> > -  What might the benefits be?
> >
> > Such integration would probably help to transfer from other systems to
> > Guix and enlarge the community.
> > What do you think?
> > Regards,
> > Robert.

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

[zimoun]

Hi Arne,

Thank you for the pointers.


On Wed, 18 Dec 2019 at 21:55, Arne Babenhauserheide  wrote:

> 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?
>
> This is the point where we need to ask ourselves:
>
>  Should Guix be volatile software?
>  http://stevelosh.com/blog/2012/04/volatile-software/

Guix is not a volatile software and will never be. Because it is
rooted in time-travelling.
The tools "guix pull --commit=", "guix  --manifest=", "guix
time-machine" or the "--roll-back" avoid to break what is currently
working.
Well, the section "The situation" just cannot(*) happen with Guix.
That's why Guix is awesome! ;-)

(*) well if one correctly uses Guix which is another story ;-)
and it is not perfect yet... see all the discussion about manifest. :-)


Now, let recall the formula (already discussed in this thread :-))

Number of people Time it takes each person
using that part of   X   to figure out what changed
the program  and how to fix it

Hum? I am not convinced that the cost would be high... Because 1. the
number of people using Guix is not so high (yet!), so 2. I am almost
sure we can name the people using "guix environment" in scripts ;-).
And 3. the time to figure out what changed is really low -- especially
with warnings and hints -- and "guix environment foo -- make" would
return an error because of dependencies missing.

Other said, I do not see myself use-cases where the scripts using
"guix environment" need to be robust for time-travelling -- the same
script used with current, past and future Guix versions -- because as
it was said elsewhere: "environment" can be seen like "temporary
profile". And temporary means... well temporary. ;-)

Then, the section "The Tradeoff" advices "from newmodule import
new_foo as foo" and IMO it is what the plan proposes with the variable
GUIX_ENVIRONMENT_DEPRECATED (tricky point #4).

Last, "volatile" vs "stable" is mitigated by "The future of 'guix
environment'" [1] which really predates the 1.0. ;-)

[1] https://lists.gnu.org/archive/html/guix-devel/2017-08/msg00300.html


As I said, I am not convinced by the argument: everything would be
broken, too much time to fix the break, etc. and this proposal would
lead to disaster for the end-user. But it is my opinion based on my
restricted personal experience.


> Also: Software developers should avoid traumatic changes
>   https://drewdevault.com/2019/11/26/Avoid-traumatic-changes.html

"Traumatic changes"? Maybe a bit extreme for the change we are talking about...



Well, at the end, what is explicitly your personal opinion?
 a. Change the behaviour of "guix environment" using the proposed plan?
or
 b. Add a new command? Which one? "guix shell", "guix env" or "guix
"?


All the best,
simon

Re: Document GUIX_LOAD_PATH?

[Pierre Neidhardt]

Hahaha, sorry for the noise then!

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


signature.asc
Description: PGP signature

Re: Document GUIX_LOAD_PATH?

[Clément Lassieur]

zimoun  writes:

> Hi Pierre,
>
> On Wed, 18 Dec 2019 at 12:28, Pierre Neidhardt  wrote:
>
>> Today I learned about the existence of GUIX_LOAD_PATH.  It does not seem
>> to be documented in the manual.  Is it anywhere in the doc?  Shall we
>> document it?
>
> It can be documented in devel pages., maybe Contributing.
>
> But IMHO, the normal use should be via the --load-path option and the
> GUIX_LOAD_PATH should be less and less used; stay here for historical
> reason and/or backward compatibility and/or some devel use-case.
>
> Well, for discoverability, it appears to me easier to list an option
> with "guix  --help" than list environment variables.

Hi Simon and Pierre,

It was me who talked to you about it, and...  It's not GUIX_LOAD_PATH,
it's GUIX_PACKAGE_PATH, sorry!!

(And it's documented :))

See you soon!
Clément

Documenting Cuirass features (was: List of failing packages)

[Clément Lassieur]

Ricardo Wurmus  writes:

> Roel Janssen  writes:
>
>> With Hydra, when clicking on a failed build you could see
>> previous builds of that same package and its success or failure of
>> them.  I found that very useful.
>
> For previous builds you can use a query like
>
>icecat spec:guix-master system:x86_64-linux
>
> and it will show you all past builds for icecat on the given system and
> matching the given specification name (here: the master branch).

Hi Ricardo,

Is it documented somewhere?  If it isn't, could you please write some
minimal documentation in cuirass.texi on how we can use the search bar?
That would be incredibly useful.

Thank you in advance,
Clément