From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6901236327051689984 X-Received: by 2002:a2e:9842:: with SMTP id e2mr1579339ljj.373.1606837233022; Tue, 01 Dec 2020 07:40:33 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a19:d0e:: with SMTP id 14ls1893299lfn.0.gmail; Tue, 01 Dec 2020 07:40:32 -0800 (PST) X-Google-Smtp-Source: ABdhPJxi9qhz/dzyFRtX1W8rB/T8oyxuAjlyLGOlzeOVrV4djhzLWwTvPd82wUeONwL9+tN+RFhO X-Received: by 2002:a19:4b0a:: with SMTP id y10mr1446796lfa.570.1606837231901; Tue, 01 Dec 2020 07:40:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606837231; cv=none; d=google.com; s=arc-20160816; b=Unrk6R3JLTWAdvDKFUax+rDWa5hsxAKrgjGs1WFm7cvMyFPm2GarBxcpqc7D9buDQD l2HomJQq1asXQRoNbjMtO1/vKsaL/9Nuel5WEguVCrT4lmgWIZt2cPv70aw5ID5GgT3T SETwuxY5CqUqgvlor7Ip2b+XttQH0etE6FVBunbaXk8PqlddP5UUO0wYW/RbaYXq9t6M vQtGDnOAMvlOXzBxxAKsYLrIn/mgbk7PneHlJLqHMbAUPVTzWVPnkEKVSABL7tm2KjX8 3gb+F/Wi04oPQf2nvsUoXpQRzQSfoch5aQIf07I8+QN7IrrlUU3DyrZaDpkLvZUAyShG gH8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date; bh=tX6VI58v02PgziBQp1REQsrZmYtXYZw4zkkNsEPTQ/o=; b=AXxv5KYynOwJ/hFkDjNEDdr8/uWgYZ3X48ifJGRbmrVp44Na6ZL+APif+e98fLOuya 5GAkduu4nobmy3l0MgediEyoiqabFRY4IROt4x9htmC1uiG2su4UbShjPbVZNT6v5f0d peXY2cOJ5nIkl7kRNQShoQxsU9ilgURVYkr0/bb/5+6ZtKdOnS137oEOx1QVyZh2aIV5 6iDmbtfgFsSjB2gYFZisFZkw4oaHBzhctaOHs+L6WPwodsYoJ/p6iVUwQwdNxKW3iOzi re/DjbVEHUWnvXUTIwo+J7/wYhWzm440uFqMv0/vlimy14pjknrZ2pvURmSPOZ8VVfId S4fQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from lizzard.sbs.de (lizzard.sbs.de. [194.138.37.39]) by gmr-mx.google.com with ESMTPS id s15si71037ljo.2.2020.12.01.07.40.31 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Dec 2020 07:40:31 -0800 (PST) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.39 as permitted sender) client-ip=194.138.37.39; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id 0B1FeVV1016856 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 1 Dec 2020 16:40:31 +0100 Received: from md1za8fc.ad001.siemens.net ([139.22.122.36]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 0B1FeUrd017472; Tue, 1 Dec 2020 16:40:30 +0100 Date: Tue, 1 Dec 2020 16:40:29 +0100 From: Henning Schild To: "[ext] Jan Kiszka" Cc: "[ext] Raphael Lisicki" , isar-users@googlegroups.com Subject: Re: do_adjust_git in dpkg-base.bbclass not working for gitsm fetcher Message-ID: <20201201164029.00af5bd5@md1za8fc.ad001.siemens.net> In-Reply-To: References: X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: Bw5V1ohQB1HM Am Tue, 1 Dec 2020 12:41:08 +0100 schrieb "[ext] Jan Kiszka" : > On 01.12.20 11:41, [ext] Raphael Lisicki wrote: > > Hi, > > > > the function do_adjust_git does not work if the fetcher has been > > set to "gitsm" which is required if the project contains git > > submodules. > > > > See > > https://github.com/siemens/isar/blob/master/meta/classes/dpkg-base.bbclass#L26 > > > > > > This will cause the .git/objects/info/alternates remain unmodified, > > which in turn breaks git from inside the buildchroot. > > From > https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#gitsm-fetcher: > > "The Git Submodules fetcher is not a complete fetcher implementation. > The fetcher has known issues where it does not use the normal source > mirroring infrastructure properly. [...]" > > For that reason already, I would strongly discourage the use of this > fetcher. And that's why it was never tested with Isar (to my best > knowledge). I have seen people use git submodules in isar recipes. But they are hairy indeed. A big issue is whether those submodules are absolute or relative to their main repo. Relative is your best bet, absolute will break authentication since you might find yourself wanting to clone with ssh and gitsm contains absolute https links. If you control that main repo, you might want to switch to relative ... if you can. Doing that breaks the "forking workflow" ... now every contributor needs to fork all, or switch to absolute before working. The worst case would be nested submodules ... I found it best to switch over to repeating the submodule stuff in the recipe, naming all modules with their shas and where they should be cloned. Hard to maintain ... but you can write helper scripts writing ".inc" files containing the bits and using a clone with initialized modules as input. SRC_URI = "gitsm://foo.git;destsuffix=${P}" SRCREV = "0815" becomes SRC_URI = "git://foo.git;destsuffix=${P};name=main SRCREV_main = "0815" SRC_URI += "git://bar.git;destsuffix=${P}/modules/bar;name=module1 SRC_URI += "git://baz.git;destsuffix=${P}/mod/baz;name=module2 SRCREV_module1 = "1234" SRCREV_module2 = "abcd" Those last 4 lines can be generated from ".gitmodules" and "git ls-tree " and stored in an include. Henning > In general, git submodules are hairy. And specifically in the context > of distro (like Debian), their presence indicate that you rather want > them as "Build-Depends" and properly packaged. > > Jan >