From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6901236327051689984 X-Received: by 2002:a7b:c385:: with SMTP id s5mr3540505wmj.170.1606841098686; Tue, 01 Dec 2020 08:44:58 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:6000:145:: with SMTP id r5ls1060086wrx.0.gmail; Tue, 01 Dec 2020 08:44:57 -0800 (PST) X-Google-Smtp-Source: ABdhPJzEIMXXVSVZCHKTYrZ3Zu15kOsfYgfftkRXPnnV3hoqEBca58AU/O6eFJQbm2CSAvhg7pVI X-Received: by 2002:a5d:510d:: with SMTP id s13mr4975807wrt.380.1606841097695; Tue, 01 Dec 2020 08:44:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606841097; cv=none; d=google.com; s=arc-20160816; b=Ha5DF2kYBRqBuW/GJQ+HyvViI3UulHqosocEEkg9TLuLQhPdc0pKOOnphssKD0IHO6 kkigWHUA8C1aLFlXFkahmJcRT9eDbjGBcCpZXNa6gg3wEPADBgrjwdflkwdwa/3pC6I/ MaA6euoGB9svEdGMf7ZT32SFuzk7fr1hFacyVLhBuVPS+bfrv62iHf/VTwanfcpQzqnv YOPwPr0o3eWo3H+YcC7ah9UHGHt+Xt4x66XxJbrvLG57NUlgLfvfU9D9kOLWHVDY5tez STmranIsRIaAWHzmb+Hsz8QuqNv1cqYXMvdz7RCjicHhdmbhaAdHHGWDrIgqWsQQZvaL jgqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject; bh=tGmuQOyevDipVnX+Z0U3IdxSg6IZjdIr5Y6dq7mCi+0=; b=Q9aE9Pg9rsY7HuUCFTYVpVLANxI2fSNQlFvUWXdeT9ZnuiSNJQGwHo0GKb5QafuvIJ cU5KjW0qOWSqlZCQ0SyA8LFR9A371fNO0wBioGd2F5fFNwP41f6m0zBipE6nODaBT6tB pLRKLn/Ywalbz3TeQszO+edtrnrD15h/L+UXckJgTTLj4SVxxMwWoYt2Ow+zCxDHx875 f3OMUlC0hP9+rTC39e1FdgzIFlhhMEyM8GZKJeZ0DBJP2Nie7QYd4lf0Urp4gHWVNT+q G1sSeP6hfKCKxUdKp7mdz/zQ9fLuH3G0UKzou/FluGi7QruqGWrAYx56bnjCMkB+bE5p 6+dg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=jan.kiszka@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 h20si6229wrb.0.2020.12.01.08.44.57 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Dec 2020 08:44:57 -0800 (PST) Received-SPF: pass (google.com: domain of jan.kiszka@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 jan.kiszka@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=jan.kiszka@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 0B1Givts000794 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 1 Dec 2020 17:44:57 +0100 Received: from [167.87.33.175] ([167.87.33.175]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 0B1GiuGX003596; Tue, 1 Dec 2020 17:44:57 +0100 Subject: Re: do_adjust_git in dpkg-base.bbclass not working for gitsm fetcher To: Henning Schild Cc: "[ext] Raphael Lisicki" , isar-users@googlegroups.com References: <20201201164029.00af5bd5@md1za8fc.ad001.siemens.net> From: Jan Kiszka Message-ID: <2f933d46-71cc-c24f-515f-3b94a9634049@siemens.com> Date: Tue, 1 Dec 2020 17:44:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20201201164029.00af5bd5@md1za8fc.ad001.siemens.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: r3XxeJlIdNAa On 01.12.20 16:40, Henning Schild wrote: > 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. > That's a better pattern, indeed. Maybe someone wants to hack up some scripts/unroll-gitsm.sh to spit out those lines for a given recipe. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux