From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6727118917296193536 X-Received: by 2002:a5d:6b84:: with SMTP id n4mr8456168wrx.118.1566299116415; Tue, 20 Aug 2019 04:05:16 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:4e0c:: with SMTP id g12ls827543wmh.4.gmail; Tue, 20 Aug 2019 04:05:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqxw78Lzwbab2ZG7e07COgiQEN9uk2h7inCgyh2suWPyF1PP/Tl6z8J9o8D/6sYK0jNv4lMj X-Received: by 2002:a7b:c198:: with SMTP id y24mr25052947wmi.131.1566299115164; Tue, 20 Aug 2019 04:05:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566299115; cv=none; d=google.com; s=arc-20160816; b=n+rwu8Ll4zU7XMjmVd/LGL88Hj+NpmpMHffw7YqRSSZzmycj0MfX6kno1+RKx+19AM E1EG+bIo2TEwaq02lITZ2KSRx0fZs9Jpn4iHgyIBCdYn2MKkswD56GGStnjARs+2IGrd g+WQlWGvF69PCXAA2ZeWtJxXBFIPlpky1uTRKv0eC+XU5KcKwprOwUAh3K+kFVDRz4Cu DrZDYBvj4uhrpkadFpyj743K7gBO9vl4wsjW+K7E6tRCFVFIdan27rOHMyQaYw56A65s yuQnhvL/kf/bBNsWPB9IVGcFmlFScn62nBBQG3rMxQACFw0ty1ZcFWfVBOI7Z/AAxrap sPZg== 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=aLOEBotlNCCb3wX0V7C8lXJhrOBc8sE+Ct51D/rNw+o=; b=hx7RSnTe5XFfsSgZxgB+2Jso8vbHWT/yBeVxpI0HBmU3g8lmYIlnu1dBDu3ncQffq8 NpSVkQUquPy5qvS/hxaucgs06GHasihp/yl0tsOxJvuCiOrRr4OFlW+QKhTJGw455GYX uJuvCct13KVL0PX1LM89EknWgG1uZZo1jmf5ZBKTellA43hafF+dqH5opJLO0gKRoYvA Y+YX1Aj9JEm7O6qt+pVr3nOGjJXiayzZmLtXPpG0JjHbfccNZavSSDDtOayVNftjaMCD CdJYBeT9qw20dJGeMvKaWsEN7oQy/f1397E/Md0GfFBCN0A74GZ98ueENyxrH1hgyG21 BmqQ== 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 o4si937633wrp.4.2019.08.20.04.05.15 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 20 Aug 2019 04:05:15 -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 (host-80-81-17-52.static.customer.m-online.net [80.81.17.52]) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8) with ESMTPSA id x7KB5DXm011457 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 20 Aug 2019 13:05:14 +0200 Date: Tue, 20 Aug 2019 13:05:13 +0200 From: Baurzhan Ismagulov To: isar-users@googlegroups.com Subject: Re: Sporadic build failure of next Message-ID: <20190820110513.GJ3412@yssyq.m.ilbers.de> Mail-Followup-To: isar-users@googlegroups.com References: <1caa3be8-d9c7-0f31-7cb7-4ee3ad43af27@siemens.com> <20190820103140.GI3412@yssyq.m.ilbers.de> <2d9c8c0c-f087-6940-89f2-72679405b886@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2d9c8c0c-f087-6940-89f2-72679405b886@siemens.com> User-Agent: Mutt/1.10.1 (2018-07-13) 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: r6u3AVUtq6ir On Tue, Aug 20, 2019 at 12:40:16PM +0200, Jan Kiszka wrote: > > Apparently, we instruct multiconfig to run the same task twice for the same > > DISTRO and DISTRO_ARCH in the same directory, and they happen to run in > > parallel. If this is the case, we should ideally build once; not sure whether > > this is desirable for all packages, though (e.g., two boards building the > > kernel from the same source and revision, but with different configs, etc.). > > That usually happens when we feed in a variable into the build that makes > the package different - without adjusting its name. Ok, so this use case is solved. Although Debian does change the binary package name, which I find better, since those are different binary packages. > > Could we force building of the packages at the same time in CI? Ideas welcome. > > In this way, we could perform regression testing for concurrency. > > I suspect we can when we first build multiple multiconf targets up to the > level needed to build that package and then request to build it for all > those multiconf targets. That sounds promising. Maybe it could require manual tailoring if there were multiple candidates for building after the first stage, but at least we could test it. > > IIRC, the kernel or PREEMPT_RT has a static checker that can detect potential > > deadlocks. That would be a nice addition to bitbake (although I doubt it is > > implementable today, since it would require recipe introspection w.r.t. e.g. > > build directory, etc.). > > Maybe evaluating the stamps after a build helps. There should be different > pattern of a recipe was built multiple times for the same distro-arch. Ok, that might catch it at least when the critical section is violated (depending on the point in time where the stamps are created). > BTW, I'm about to adopt the OE layout for the stamps folder. Let's see what > that brings (beside visual alignment). Brings and hopefully not takes :) . We need that anyway to prevent *-* from matching pkg-1.0 and pkg-abc-1.0 discussed recently. FWIW, Debian solved that by using pkg_1.0 and pkg-abc_1.0. With kind regards, Baurzhan.