unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Florian Paul Schmidt <mista.tapas@gmx.net>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 22078@debbugs.gnu.org
Subject: bug#22078: failed builds due to exceeding max-silent-time not marked as failed in db
Date: Mon, 14 Dec 2015 09:39:02 +0100	[thread overview]
Message-ID: <566E8026.6070903@gmx.net> (raw)
In-Reply-To: <87a8peuep0.fsf@gnu.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 14.12.2015 00:11, Ludovic Courtès wrote:

> OK.  I’m unsure whether it makes sense to cache failures due to
> timeout because, by definition, they’re non-deterministic.

Except for cases where they are deterministic (Consider a buggy
package that has a testcase that reduces to while (true) { } that is
not optimized away). They very seldom are though. Ayways: I'm not
proposing to make any of this the default.

> Another problem is that clients can choose what the timeout is
> (both max-silent-time and absolute max-time), so it’d be easy for a
> client to force a timeout failure; on a multi-user system, that
> would amount to a DoS attack.

You mean a user just builds all packages with a timeout that's
impossible to fulfill? And consequently all their failures will be
cached and if then another user tries to build them they just get the
cached failure? That points out another (though more contrived) flaw
indeed:

Even without caching failures a package might be nondeterministic for
some reason (bugs always happen). A user who knows how to trigger the
failure (assuming it's depending on something under the user's
control) then could DOS that particular build.

In general it would probably be good to have a way of resetting the
cached failures in the db. Maybe --check does almost this: If a failed
derivation gets built again with --check will the subsequent success
overwrite the failed one and remove the entry from the FailedPaths
table? Or will --check just happily report that the build is
nondeterministic?

> 
> I’m not sure how to address these issues, so I’m rather in favor of
> the status quo.

I found that the changes I made don't seem to work correctly anyways.
So LNGTMUAC (let's not get that merged under any circumstances).

Flo

- -- 
https://fps.io
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWboAmAAoJEA5f4Coltk8Zhe4H/2B8jFpvjyTCn87eRoPCVjYV
3bHgjl/WXByrei93l65q+TY+IxFxA66p1Q9GV/cBoj7k/gkFxylUamaqw0wbQEbm
yohD0G7YnKpywXCLp1pwJeFeBUGmAe/F0Fw4G45OGcAeIQ7AbDZRHmYq4KRe9x1q
i0n96plAirsy5zvBY88bdZU8Fbc4c8pm1Mw2e8B9i3EEWjwcXh8UWeuerTKHhMK4
KNtxgX+Wnx05ZmzOnM3yJKOM8qgujW4peYhVJl3SRAMv/5kLFVCOOUC3XbsijdMM
8ny68tXgE5pNtfHsGko/rqwBT/LQ0C94zO+ggkitd51sgLFKXMRdt+j9pmDLfS0=
=ZFzw
-----END PGP SIGNATURE-----

  reply	other threads:[~2015-12-14  8:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-02 22:03 bug#22078: failed builds due to exceeding max-silent-time not marked as failed in db Florian Paul Schmidt
2015-12-04 22:40 ` Florian Paul Schmidt
2015-12-09 19:57   ` Leo Famulari
2015-12-13 23:11   ` Ludovic Courtès
2015-12-14  8:39     ` Florian Paul Schmidt [this message]
2015-12-14 16:40       ` Ludovic Courtès

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=566E8026.6070903@gmx.net \
    --to=mista.tapas@gmx.net \
    --cc=22078@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    /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).