guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#26366: Building Guix from within a container


From: Ludovic Courtès
Subject: bug#26366: Building Guix from within a container
Date: Sat, 08 Apr 2017 15:54:52 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Heya,

Pjotr Prins <address@hidden> skribis:

> To be honest I think we should get rid of harmless messages - or only
> show the first or last one (perhaps state that there are more similar
> messages which can be seen in debug mode). I understand that this is a
> guile thing, but the same holds for guix with all the warnings we get
> when sylinks/files are duplicated in the store. 

So, one thing at a time.  :-)

I think this specific Guile warning makes some sense, but it’s not a
discussion for Guix here.

The “sylinks/files are duplicated in the store” thing you’re referring
to is when you have the same file multiple times in a profile and you
get a warning (“arbitrarily choosing…”) when building the profile right?

I’ve discussed a fix long ago that would raise an error when you have
real conflicts in a profile (e.g., same package twice but with different
versions), rather than having these warnings.  I haven’t gotten around
to implementing it yet.

> Irony is that sometimes we don't get warnings when we need them. Such
> as when you specify a substitute-url and if the server does not exist
> there is no indication. I have wasted many a time on figuring that
> problem out.

The idea here is that --substitute-urls="https://foo https://bar"; would
pick whichever of these servers is available, and silently ignore the
other one (for the DNS resolution and the initial HTTP request;
subsequent HTTP requests do lead to an error/warning if they fail.)
We could revisit that, but no discussion will take place if there’s not
a bug report in the first place.  :-)

> It would be nice to have a policy where we do not show all harmless
> warnings by default, but only in debug mode, as well as missing
> services etc. I am happy to run --debug when I actually face a
> problem.

“Missing services”?

I think everyone agrees on the goal.  What we need is to precise list of
these issues and discuss possible solutions for each of them.

Thanks in advance for the upcoming bug reports!  ;-)

Ludo’.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]