From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7117657722680508416 X-Received: by 2002:a05:6512:158e:b0:489:de26:9ea with SMTP id bp14-20020a056512158e00b00489de2609eamr4720233lfb.190.1657786977870; Thu, 14 Jul 2022 01:22:57 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a19:e34d:0:b0:489:dd8c:5436 with SMTP id c13-20020a19e34d000000b00489dd8c5436ls519235lfk.1.gmail; Thu, 14 Jul 2022 01:22:56 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sSObhgHymPR5MEHILR7FkWNd3rUsuccOk/e6uFHeFT323vcofVnFhiXSAb4KDj3XE7TbLk X-Received: by 2002:a05:6512:2185:b0:482:b4f0:f23 with SMTP id b5-20020a056512218500b00482b4f00f23mr4760758lft.31.1657786976751; Thu, 14 Jul 2022 01:22:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657786976; cv=none; d=google.com; s=arc-20160816; b=ur2H2IMuVD5fB8o/ac2XN92bCEN3JO6TZmoSrBanv8nddNzgES4bewDD5OTRyL3ok1 OQ6PjCO7w83wcvL5YnY5AVhe1gGrC5j4NIIzbXZfleZCB3x8d/l1tjD+VAZ692arnOjE n/aUNs5ZDieWgzIs+limHAm3ano24FMzxegUPrds7LJqxjp7Efq+7ck1Kb7dFagjrTFj /oGddoqrLy0v3gDQb9SjGCspXWWwrjajl/O8gNBnIPNi+i1URlEBVE3rNRKI728Cp40L KMLvuXVcUpFrBcY300m3Zb/6JapDM78hwZ95fepgemqhNwpoOYno6Ohyvco3UD0ra45/ oHTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:cc:references:to :content-language:subject:user-agent:mime-version:date:message-id; bh=TLN3RGuvtDh6g+SSLm+1jkX9oRd9xvTGhnFEy1tAFbo=; b=gAAdyfCrpU1ea/6KgYtP7V0KDx624517lI/TCgWr5yCYQcN/PeXQuNaUF4YGAXBHZc 0t4n7g1zMNEkjl5RtHkUmQTLcwCl0do6Oysvgvl4MlmcZz7szi6OgSOstDQHfqg+5vde yXPf0zkhwvkTA6nkpltQD1wD0E46m3nVXek0SWcp3sTtt220hGkA0guh8FDvVBEgKnhF faLWP9nGCX4bPjIcD0u3wKNHfyRNWk5e24aqdV6bFjvXryx6UaWyl5MX1vq0+txAIOS2 +yjHHVqYa3axjgeXsMfy5YYY8VAfwVQKYA9nDiblkT0ZiikKVll1JNR6d935gldy9Sca Kgtw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of amikan@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=amikan@ilbers.de Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id s1-20020a056512214100b0048960e41f73si40564lfr.0.2022.07.14.01.22.56 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 14 Jul 2022 01:22:56 -0700 (PDT) Received-SPF: pass (google.com: domain of amikan@ilbers.de designates 85.214.156.166 as permitted sender) client-ip=85.214.156.166; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of amikan@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=amikan@ilbers.de Received: from [127.0.0.1] (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+deb9u1) with ESMTPSA id 26E8MsDs022126 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 14 Jul 2022 10:22:55 +0200 Message-ID: <23cb0f3a-8a71-895d-26bd-1920fabbc247@ilbers.de> Date: Thu, 14 Jul 2022 11:22:53 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH 1/2] linux-module: create S if not existing Content-Language: en-US To: isar-users@googlegroups.com, Felix Moessbauer References: <20220707154634.3860434-1-felix.moessbauer@siemens.com> <20220707180014.77c03a53@md1za8fc.ad001.siemens.net> <2f9332c2-ac3b-719c-e92f-466992e03d36@siemens.com> Cc: Baurzhan Ismagulov From: Anton Mikanovich In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: FKIuDwtinqCa 08.07.2022 17:31, Moessbauer, Felix wrote: >> -----Original Message----- >> From: Kiszka, Jan (T CED) >> Sent: Thursday, July 7, 2022 6:54 PM >> To: Schild, Henning (T CED SES-DE) ; >> Moessbauer, Felix (T CED SES-DE) >> Cc: isar-users@googlegroups.com >> Subject: Re: [PATCH 1/2] linux-module: create S if not existing >> >> On 07.07.22 18:00, Henning Schild wrote: >>> Am Thu, 7 Jul 2022 17:46:33 +0200 >>> schrieb Felix Moessbauer : >>> >>>> We copy the debian folder into S, but at do_prepare_build time S >>>> might not have been created yet. >>>> This patch makes sure that the directory is created if it does not >>>> exist. >>>> >>>> Signed-off-by: Felix Moessbauer >>>> --- >>>> meta/recipes-kernel/linux-module/module.inc | 1 + >>>> 1 file changed, 1 insertion(+) >>>> >>>> diff --git a/meta/recipes-kernel/linux-module/module.inc >>>> b/meta/recipes-kernel/linux-module/module.inc index >>>> 50acfe14..97eff294 100644 --- >>>> a/meta/recipes-kernel/linux-module/module.inc +++ >>>> b/meta/recipes-kernel/linux-module/module.inc @@ -28,6 +28,7 @@ >>>> TEMPLATE_FILES = "debian/control.tmpl \ debian/rules.tmpl" >>>> TEMPLATE_VARS += "KERNEL_NAME KERNEL_TYPE KERNEL_IMAGE_PKG >>>> KERNEL_HEADERS_PKG PN" >>>> +do_prepare_build[dirs] += "${S}" >>>> do_prepare_build() { >>>> cp -r ${WORKDIR}/debian ${S}/ >>> A little weird but i know the module you write that for is weird on >>> its own ... nvidia. But what we do here is put packaging metadata into >>> the code, which should be there after unpack ... everything else is "weird" >>> ... no code no packaging needed. >>> >>> But hey it does not hurt. >> It is definitely weird and will lead to new error patterns when folks specify a >> wrong S value - did you check that? > Well, not really. > The module.inc already copies the Debian folder to S, so at worst in S will only be the Debian folder. > Prior to this patch, this lead to an error message that the Debian folder could not be copied. > >> If a broken S will not silently generate a nop-recipe now, we can take this, but I >> would like to see more reasoning of the case where S is filled with code AFTER >> do_prepare_build. > Yes, it might lead to a nop recipe, but we need a way to manually extract and move-around the artifacts that are downloaded to WORKDIR. > Prior to this patch S has only been created by the do_unpack task when unpacking things into S. > > Having non-filled S is not so uncommon. > Esp. in case the sources are provided by a Debian-binary package like "nvidia-kernel-source" which is added as a build dependency. > > Felix > >> Jan >> >> -- >> Siemens AG, Technology >> Competence Center Embedded Linux Can you provide recipe example for that case? I think those weird recipes should be fixed by placing do_prepare_build[dirs] += "${S}" in downsteam recipe itself, but not in Isar. Having incorrect ${S} is probably much more common case during development, so we can't just allow it to be masked.