From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Cl=C3=A9ment?= Lassieur Subject: bug#32575: [Cuirass] Filter results by architecture Date: Thu, 30 Aug 2018 14:50:45 +0200 Message-ID: <877ek8m316.fsf@lassieur.org> References: <87a7p5b7x3.fsf@elephly.net> <20180830114135.3226977f@scratchpost.org> <87efegxd9s.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50751) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fvMXP-00048Y-CU for bug-guix@gnu.org; Thu, 30 Aug 2018 08:59:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fvMPe-0001mk-My for bug-guix@gnu.org; Thu, 30 Aug 2018 08:51:08 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:33017) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fvMPe-0001mg-JQ for bug-guix@gnu.org; Thu, 30 Aug 2018 08:51:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fvMPe-0006qt-Aq for bug-guix@gnu.org; Thu, 30 Aug 2018 08:51:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-reply-to: <87efegxd9s.fsf@gnu.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 32575@debbugs.gnu.org Ludovic Court=C3=A8s writes: > Hi Danny & all, > > Danny Milosavljevic skribis: > >> I think that for a portable package, the architecture it runs on is >> an implementation detail - it should build on all of them. If it doesn'= t, >> that should show up as an error. >> >> So I had >> >> hello [x86_64-checkbox-log] [armhf-checkbox-log] [aarch64-checkbo= x-log] >> >> and not >> >> hello.x86_64 [checkbox-log] >> hello.armhf [checkbox-log] >> hello.aarch64 [checkbox-log] >> >> The latter looks more like these are different packages with different p= urposes - >> which they really aren't from a user standpoint. > > The difficulty is that, from Cuirass=E2=80=99 viewpoint, =E2=80=9Chello.x= 86_64-linux=E2=80=9D > and =E2=80=9Chello.armhf-linux=E2=80=9D are just two different unrelated = jobs. > > Perhaps what we would need is to internally change how jobs are > represented in the database: we could have one job, =E2=80=9Chello=E2=80= =9D, connected > to one or more =E2=80=9Cbuilds=E2=80=9D, each with its own system. > > I think it would amount to splitting the =E2=80=9CBuilds=E2=80=9D table i= nto two tables: > =E2=80=9CBuilds=E2=80=9D and =E2=80=9CJobs=E2=80=9D. Cl=C3=A9ment, does = that make sense? The 'job' word already has a meaning in Cuirass: it is the thing that is returned from the evaluation. For example, if Cuirass builds foo and bar for x86_64 and i686, there will be exactly 4 jobs produced at each evaluation : - foo.x86_64-linux=20=20=20=20=20 - foo.i686-linux=20=20=20=20=20=20=20 - bar.x86_64-linux=20=20=20=20=20 - bar.i686-linux=20=20=20=20=20=20=20 (10 evaluations means 40 jobs produced, etc.) (Most of them have a derivation file associated that already exists, so they won't be added in the Build table.) I don't think we should change that meaning because it will make everything more difficult to understand. But the Builds table looks like this: CREATE TABLE Builds ( derivation TEXT NOT NULL PRIMARY KEY, evaluation INTEGER NOT NULL, job_name TEXT NOT NULL, system TEXT NOT NULL, nix_name TEXT NOT NULL, log TEXT NOT NULL, status INTEGER NOT NULL, timestamp INTEGER NOT NULL, starttime INTEGER NOT NULL, stoptime INTEGER NOT NULL, FOREIGN KEY (evaluation) REFERENCES Evaluations (id) ); We even have the 'system' column, so to me we have everything we need, and we could display on one line all the builds that have the same 'nix_name' for a given evaluation. Does it make sense? Cl=C3=A9ment