unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Pjotr Prins <pjotr.public12@thebird.nl>
Cc: 26366@debbugs.gnu.org, "Clément Lassieur" <clement@lassieur.org>
Subject: bug#26366: Building Guix from within a container
Date: Sat, 08 Apr 2017 15:54:52 +0200	[thread overview]
Message-ID: <87d1cnovgz.fsf@gnu.org> (raw)
In-Reply-To: <20170408125746.GA14578@mail.thebird.nl> (Pjotr Prins's message of "Sat, 8 Apr 2017 12:57:46 +0000")

Heya,

Pjotr Prins <pjotr.public12@thebird.nl> 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	other threads:[~2017-04-08 13:56 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-05  7:48 bug#26366: Building Guix from within a container Clément Lassieur
2017-04-05  7:49 ` bug#26366: [PATCH] doc: Specify that Guix should be built " Clément Lassieur
2017-04-08 12:40   ` Ludovic Courtès
2017-04-13 16:29     ` Clément Lassieur
2017-04-13 21:23       ` Ludovic Courtès
2017-04-13 21:32         ` Clément Lassieur
2017-04-14  7:54           ` Ludovic Courtès
2017-04-05 12:26 ` bug#26366: Building Guix " Clément Lassieur
2017-04-06 15:10   ` Clément Lassieur
2017-04-13 16:45     ` Clément Lassieur
2017-04-13 21:24       ` Ludovic Courtès
2017-04-13 21:27         ` Clément Lassieur
2017-04-08 12:38 ` Ludovic Courtès
2017-04-08 12:57   ` Pjotr Prins
2017-04-08 13:54     ` Ludovic Courtès [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d1cnovgz.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=26366@debbugs.gnu.org \
    --cc=clement@lassieur.org \
    --cc=pjotr.public12@thebird.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).