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 befo
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 se
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
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
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 r
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-
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
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:
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
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---
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 t
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 redistr
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 ar
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
>
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,
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
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 scientif
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 -
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
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 th
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
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,
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?
-
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
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:
Also, GUIX_PACKAGE_PATH is not “recommended”—channels FTW!
Ludo’.
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’.
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 o
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 pac
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'
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
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 u
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 de
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
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 env
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
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 h
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 p
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
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
-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
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 Rich
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 cha
Hahaha, sorry for the noise then!
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
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., m
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 s
46 matches
Mail list logo
