From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7032253102499561472 X-Received: by 2002:a2e:9a5a:: with SMTP id k26mr4480651ljj.9.1637670263968; Tue, 23 Nov 2021 04:24:23 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:a222:: with SMTP id i2ls1585039ljm.9.gmail; Tue, 23 Nov 2021 04:24:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJzxwejnDYKlIYCo/tRbyws0QbC/rUQmFY3qBe3BVAD2zveTaezl9oSYpkqYW4DLZ3SFPnMx X-Received: by 2002:a2e:a407:: with SMTP id p7mr4429047ljn.468.1637670262635; Tue, 23 Nov 2021 04:24:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1637670262; cv=none; d=google.com; s=arc-20160816; b=g+RHNI48Pjp1RdEG2ICIeqZBEEvP4z4MfEASUqrsiv0YwfI+E7SLJD9SWZuZ0H9jG/ RxOalUPmJyQvZ0I78HIPuVocvcjNJqw5NwEwVQ72TuK/OffOz6nfZxdT/Xrb2llkNylw ddglyyac+YEXJ+0rfbB0WGUsRH+pU/Q5FLbNjW5P3B+d0TOfYqN+e3MurU2GD/Qx+CYZ THurjcGUAGkStdDwBlzNA3ZePF5oNjVwHvxQDO2GJJHZ8p3a0hbEO3GSWLGsJi05qdUJ uJDJoRAS6Zk3MHtjhhrdMn1yMJchQVGBBoembRMgEMDNnP8AdQvukHoIYwvG0Ft8yGzo H1zw== 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:date:subject:to:from; bh=OrTGpCHxfwFgCdqxyFVEeXtOAbsYSpGIDPRa2Ef9YEo=; b=ZZH6Xw45lRScZ1JFr1pkkS43VodUYHg/I3EglwFuJA2h+QW0jM+J1sOzdxRFP3ry6R qgunmIFhjdS071/JRWIIGiwTRSbB72/mzt1Jan0n4lnLUTK/fPKYEFfDiWN0m7AQPUg/ WibLL7XG5JtAZIaSlt7if8mCW/M6IiSnw+nOLw3eWCfEvmYANSeHtGZHJfUDi21eEJbF YmAs7u6eUBZLjn3gO3nAOiC6A+bHKCuE8zfibTyGeHDXceWk4thKCI88YMFVay1C/uyy OkLzdqy5UYwKaG2p8SZ0c2BgsLOaTCCevfBDDWxf9QPsSpnqEZNtHxrz38sAnATGPX4j SLNg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of ubely@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=ubely@ilbers.de Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id o25si838346lfo.9.2021.11.23.04.24.22 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Tue, 23 Nov 2021 04:24:22 -0800 (PST) Received-SPF: pass (google.com: domain of ubely@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 ubely@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=ubely@ilbers.de Received: from home.localnet (44-208-124-178-static.mgts.by [178.124.208.44] (may be forged)) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8) with ESMTPSA id 1ANCOKCr009171 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Nov 2021 13:24:21 +0100 From: Uladzimir Bely To: isar-users@googlegroups.com, Jan Kiszka Subject: Re: [PATCH v2 04/24] linux-module: Do not use shell environment Date: Tue, 23 Nov 2021 15:24:27 +0300 Message-ID: <2392353.XAFRqVoOGU@home> In-Reply-To: <1bc95be7-e603-966b-5326-962362548e2c@siemens.com> References: <20211119121333.13805-1-ubely@ilbers.de> <20211119121333.13805-5-ubely@ilbers.de> <1bc95be7-e603-966b-5326-962362548e2c@siemens.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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: 7VlMq8Zed0C4 In the email from Friday, 19 Nov 2021. 15:44:12 +03 user Jan Kiszka wrote: > On 19.11.21 13:13, Uladzimir Bely wrote: > > > +KDIR := $(shell dpkg -L $(KERNEL_DEP) | grep "/lib/modules/.*/build") > > +endif > > + > > +# With sbuild `dh clean` is called before chroot's apt database updated. > > So, +# KDIR is empty at that moment and the override causes error. Will > > skip it. +ifneq ($(KDIR),) > > > > override_dh_auto_clean: > > $(MAKE) -C $(KDIR) M=$(PWD) clean > > > > +endif > > This looks wrong, or at least fragile. Why can we live without a proper > clean on the kernel tree? > > Jan Actually, this workaround with `ifneq ($(KDIR),)` I added to the patch after the commit https://github.com/ilbers/isar/commit/248436880eb2 was applied to `next`. This change doesn't cancel a proper clean on the kernel. Here are some example logs: `next`: https://gist.github.com/WiseLord/0fb98bc036532ec03e4f763b2ba06a41 `sbuild`: https://gist.github.com/WiseLord/3c35d477efc025bcc9cd3c5cbd3dbc5d On current `next` code dh_clean (and override-related `make ... clean` on kernel code) is executed by dpkg-buildpackage. At this point KDIR is set to a proper value, so it works as expected. With sbuild dh_clean happens to be executed twice: - 1: immediately after sbuild is run, executed by sbuild itself - 2: after few stages (like downloading deps and so on), executed by dpkg- buildpackage. The issue is that at 1st execution KDIR is not set, so `make ... clean` (coming with override) produces wrong command. That's why this workaround (skip `make ... clean` in case of empty KDIR) was added. Proper cleaning is still performed, but on the second call of dh_clean. Probably, there is a way to say sbuild not to run this 'generic' dh_clean and use just one from dpkg-buildpackage later... -- Uladzimir Bely Promwad Ltd. External service provider of ilbers GmbH Maria-Merian-Str. 8 85521 Ottobrunn, Germany +49 (89) 122 67 24-0 Commercial register Munich, HRB 214197 General Manager: Baurzhan Ismagulov