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
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
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
Hi Ricardo,
Yes! I think that would really emphasize the hackability of Guix.
- John
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
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
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
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
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
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
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
>
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
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
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
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
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
>
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
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
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
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
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
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
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
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
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
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
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
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
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
29 matches
Mail list logo
