From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6739560601010307072 X-Received: by 2002:ac2:5965:: with SMTP id h5mr8467470lfp.129.1569769029929; Sun, 29 Sep 2019 07:57:09 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a19:f613:: with SMTP id x19ls870887lfe.16.gmail; Sun, 29 Sep 2019 07:57:09 -0700 (PDT) X-Google-Smtp-Source: APXvYqxDeAXIKQQesGZ6nxiCKtnTzS0zXb5t2CL++GxwZQNY9+paahVTrbtpTaRsIG6uHliDimyl X-Received: by 2002:a19:4a10:: with SMTP id x16mr9243583lfa.126.1569769029270; Sun, 29 Sep 2019 07:57:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569769029; cv=none; d=google.com; s=arc-20160816; b=rEMSM37j7IHWvhZUmUMKush2ZcBmUo7e8OCBMOZ6lAJmoonGkAhLnourO/tNBVrl0R PybIm72lAWWP5yasTtawqQT6z0r7uc0h4hQszuk6wFGWsah4i58boesCJhyv7uzqkQ6i mW/BRA/UlIBYMd3tKBrj8VHF5d3W7YvM1vxirXd3rs+kFnWaWphMFUopxgJWtWGDpVhB 8QGJUz1nLvH9i1hbnMWiVRbhNoywlYS/XxRPisq/lz1ROViXfOuSf3jm/8Nzb6Q/9tVB 7rjesXnDNAV8UGRvzD8bvH8m030FOtm3uDqg1rdkGIwq8blSRmGSxP/jbgVJ0HPmsaDM Psig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date; bh=d5Jts3efQ3VMC1eEhMaLJdEwvaat7YLD2IOCqLD/uUo=; b=Kp7u7zKg4AxwkHf86D8bUVwT31cLhMgdHyy5iNO/xMapSOsTswZMtEiPKABiFl2k2s Q/6aU8LK285m+PpjK0z4UdKvgZmf9aNDUFR3y+W+T+aTZ35vYyop9zGdv6P2Ske2bbjI OggqtWvNbWbpkQdOW9QaM6PmOr7u3oddSg1NOV0oIMDd7A32vwIhlZUEX2DwRmlDDPeV I1FUb8UuXqoMkrZyTsGKriZ/ne98v2ALlvhX2UCWYJK2LiSsbay30JwO6u0libvM5QkS WhVRRVd5pHuG+nrY2yxBZrp43vwbDpmv/sHOkcW9XOOPNvzq1tbhCqWT1TnQk9SVgI7G gCDQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id q25si435028ljg.5.2019.09.29.07.57.08 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 29 Sep 2019 07:57:08 -0700 (PDT) Received-SPF: neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) client-ip=85.214.156.166; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Received: from yssyq.m.ilbers.de (ip-109-41-194-81.web.vodafone.de [109.41.194.81]) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8) with ESMTPSA id x8TEv6hW002244 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sun, 29 Sep 2019 16:57:07 +0200 Date: Sun, 29 Sep 2019 16:57:01 +0200 From: Baurzhan Ismagulov To: isar-users Subject: Re: [PATCH v6 12/27] Detect false sharing of recipes Message-ID: <20190929145700.ads3zbq7hz77olcw@yssyq.m.ilbers.de> Mail-Followup-To: isar-users References: <5a2e329b881ec0b392d0f1abd116f1deeee0f66f.1569176231.git.jan.kiszka@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-TUID: Kj/EG3O6hvHH On Tue, Sep 24, 2019 at 08:02:26PM +0200, Jan Kiszka wrote: > When a task is run more than once per build, this indicates a bug, > usually (though not only) related to incorrect multiconfig use. Do I understand correctly: 1. Multiple isar-bootstrap executions (apart from the fact that they are unnecessary) could fail because some steps after debootstrap (which was locked) were not using the lock and could overwrite each other's results? The background is to understand the specific failure mode, because you wrote that this locking didn't actually protect from races. 2. Multiple isar-bootstrap executions do not occur now because the same tasks that should not be executed twice have the right PF? > This adds a very simple but effective check for such re-run scenarios > by putting a "once." stamp file into each workdir during a > build. If such a file already exists, an error is thrown. The workdirs > are purged after the parsing phase on the beginning of each build so > that no false positives are raised. The task stamp is also deleted after > failures so that no (serialized) retries can cause warnings. 3. Where does this delete the once.* file w.r.t. e.g. do_dpkg_build for different multiconfigs? With kind regards, Baurzhan.