> It seems that version 3.0.0 is out for two months. I will try to
> update this first, then have a look at reproducibility. Wdyt?
I have a patch updating postgis as well as many other packages in
geo.scm. Please see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38149
signature.asc
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 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
zimoun writes:
> 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
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
When the target machine has no signing keys (generated with “guix
archive --generate-key”) the source machine issuing “guix offload test”
will print this confusing error message:
guix offload: error: implementation cannot deal with > 32-bit integers
--
Ricardo
Ivan Vilata i Balaguer (2019-12-19 11:51:55 -0500) wrote:
> Efraim Flashner (2019-12-19 15:03:11 +0200) wrote:
>
> > I merged the two patches together, made sure all the phases returned #t
> > and flushed out the commit message some more.
>
> Thanks a lot! Comparing your final patch against
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
>
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 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 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 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
14 matches
Mail list logo
