From d6217526e0f66dce62cecb560479776d31d9abdb Mon Sep 17 00:00:00 2001 From: distix ticketing system Date: Sat, 9 Feb 2019 05:12:08 +0000 Subject: imported mails --- .../Maildir/new/1549689128.M421623P4381Q1.koom | 112 +++++++++++++++++++++ 1 file changed, 112 insertions(+) create mode 100644 tickets/7503b896b90049d3a89ad5a7f4ed021d/Maildir/new/1549689128.M421623P4381Q1.koom diff --git a/tickets/7503b896b90049d3a89ad5a7f4ed021d/Maildir/new/1549689128.M421623P4381Q1.koom b/tickets/7503b896b90049d3a89ad5a7f4ed021d/Maildir/new/1549689128.M421623P4381Q1.koom new file mode 100644 index 0000000..5abcfd1 --- /dev/null +++ b/tickets/7503b896b90049d3a89ad5a7f4ed021d/Maildir/new/1549689128.M421623P4381Q1.koom @@ -0,0 +1,112 @@ +Return-Path: +X-Original-To: distix@pieni.net +Delivered-To: distix@pieni.net +Received: from yaffle.pepperfish.net (yaffle.pepperfish.net [88.99.213.221]) + by pieni.net (Postfix) with ESMTPS id 71D0043D43 + for ; Sat, 9 Feb 2019 05:11:34 +0000 (UTC) +Received: from platypus.pepperfish.net (unknown [10.112.101.20]) + by yaffle.pepperfish.net (Postfix) with ESMTP id 421C941123 + for ; Sat, 9 Feb 2019 05:11:34 +0000 (GMT) +Received: from ip6-localhost.nat ([::1] helo=platypus.pepperfish.net) + by platypus.pepperfish.net with esmtp (Exim 4.80 #2 (Debian)) + id 1gsKvO-0005Pb-6f; Sat, 09 Feb 2019 05:11:34 +0000 +Received: from [10.112.101.104] (helo=mx4.pepperfish.net) + by platypus.pepperfish.net with esmtps (Exim 4.80 #2 (Debian)) + id 1gsKvN-0005PI-HG + for ; Sat, 09 Feb 2019 05:11:33 +0000 +Received: from mail.steve.org.uk ([176.9.183.102] helo=ssh.steve.org.uk) + by mx4.pepperfish.net with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) + (Exim 4.89) (envelope-from ) id 1gsKvJ-0004YT-Sc + for ick-discuss@ick.liw.fi; Sat, 09 Feb 2019 05:11:32 +0000 +DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; + d=steve.org.uk; s=20150726; h=References:In-Reply-To:Message-ID:Date:Subject: + From:To:Sender:Reply-To:Cc:MIME-Version:Content-Type: + Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: + Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: + List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; + bh=m1i47aSPFG4FuSMWk/eB35KNatqT8n+iV0+cGfJlMSg=; b=l3nIUq+xMBrtsP4nvSGhI68gU + hl8j82c0MfDrAeIkkDnKrKV/iBAbjFNyW33mtxBbzGkS+JQudcZ9s9EhOKhBfCVJ0QwZ6/VFKdMQA + TfmWg9xTu+01P6jwZjVI6CA5ahu7F1AvO8qQ/meDqBC9Q2goJocsJjrGXV9bAXwCAdl40=; +Received: from steve by ssh.steve.org.uk with local (Exim 4.89) + (envelope-from ) id 1gsKvB-000148-OB + for ick-discuss@ick.liw.fi; Sat, 09 Feb 2019 05:11:21 +0000 +To: ick-discuss@ick.liw.fi +From: Steve Kemp +Date: Sat, 09 Feb 2019 05:07:55 +0000 +Message-ID: <1549688875.1308.1@ssh.steve.org.uk> +In-Reply-To: <5e2b278847b76dd0311d5050b3455b12b4dd3077.camel@liw.fi> +References: <5e2b278847b76dd0311d5050b3455b12b4dd3077.camel@liw.fi> +X-added-header: steve.org.uk +X-Pepperfish-Transaction: d941-f1af-588d-7a08 +X-Spam-Score: -0.2 +X-Spam-Score-int: -1 +X-Spam-Bar: / +X-Scanned-By: pepperfish.net, Sat, 09 Feb 2019 05:11:32 +0000 +X-Spam-Report: Content analysis details: (-0.2 points) + pts rule name description + ---- ---------------------- -------------------------------------------------- + -0.0 BAYES_20 BODY: Bayes spam probability is 5 to 20% + [score: 0.1998] + -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from + envelope-from domain + -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from + author's domain + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily + valid +X-ACL-Warn: message may be spam +X-Scan-Signature: bdc2be5dc634686df142fe367da3f314 +Subject: Re: Plan for using Muck for the Ick controller +X-BeenThere: ick-discuss@ick.liw.fi +X-Mailman-Version: 2.1.5 +Precedence: list +List-Id: discussions about the ick CI system +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +Sender: ick-discuss-bounces@ick.liw.fi +Errors-To: ick-discuss-bounces@ick.liw.fi + +> * The controller will reconstruct the whole build log when it's +> requested for a complete log, by fetching all log objects that refer +> to the specified build, and catenating the log output snippets in +> order of the sequence number. + + Assume you're building a kernel, which might spit out 400,000 lines + of build-log. Assume each new update, due to buffering, or sizing, + is 10 lines. + + To get the whole build-log you're going to need to: + + * Get the first piece. + * Get the next child. + * Get the next child. + * Get the next child, 39,997 times more. + + That seems like it will scale terrible. The only potential win I can + see here is imagining that you might want to view the output via a + brower and you'll probably only care about the LAST 100 lines, not the + FIRST. (i.e. The bit which will typically contain "built blah", or + "build failed".) + + I'd be tempted to write the log locally, then upload as one massive + object when complete. Sure it might be big, but it's more efficient + to stream a 1Mb HTTP transfer than to keep repeating HTTP-calls to + get the next bit. + + (For a web-case you can use AJAX to stream on-scroll. But for email + output you'll want the whole thing to send..) + + +Steve +-- +https://www.steve.org.uk/ + +_______________________________________________ +ick-discuss mailing list +ick-discuss@ick.liw.fi +https://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/ick-discuss-ick.liw.fi -- cgit v1.2.1